Ask Your Question
0

sliderPy - GetMapString doesn't work in PSSE34

asked 2019-05-06 07:31:15 -0500

Peter81 gravatar image

I want to extract line data (From Bus, To Bus and ID) in a Python script after selecting a line in the SLD and then running the script. It works as intended in PSSE 33 but not in PSSE 34. I am using sliderPy and GetMapString, se script below.

Python script:

import sliderPy

mydoc = sliderPy.GetActiveDocument()
mydiagram = mydoc.GetDiagram()
mycomponents = mydiagram.GetComponents()

for mycomponent in mycomponents:
    if mycomponent.IsSelected() == True:
        try:
            print 'Type: {0}'.format(mycomponent.GetComponentType())
            print 'MapString: {0}'.format(mycomponent.GetMapString())
        except:
            pass

For example, lets use savnw.sav and savnw.sld in both PSSE 33 and PSSE 34. When selecting the line between bus 3006 and bus 153 the result will be as follows:

In PSSE 33:

Type: Link
MapString: LI    153   3006 1

In PSSE 34 (klicking the mid point):

Type: Symbol

In PSSE 34 (Klicking on the line next to the mid point):

Type: Symbol
Type: Link
MapString:

Do observe that if you right click on the line in the SLD and select "item Properties -> Map String..." you can see that the Map String is shown as intended in PSSE 34:

LII    153   3006 1
  • Why can't I use "GetMapString" from sliderPy in PSSE34?
  • Is there a new updated command for this or is this a bug in PSSE 34?
  • If there is another way, how do I extract the Map String in PSSE 34?
edit retag flag offensive close merge delete

Comments

This seems to be a bug to be reported to Siemens-PTI.

perolofl gravatar imageperolofl ( 2019-05-06 09:58:40 -0500 )edit

I agree that it looks like a bug. For that I am not suprise since I found some API functions for getting indution machine data are not implemented and always return 'None'.

drsgao gravatar imagedrsgao ( 2019-05-08 04:38:51 -0500 )edit

Thanks for your comments! I have created an account on the new Siemens PTI Customer Care portal and will add a "Support Ticket" regarding this. As soon as I get an answer from them I will tell you.

Peter81 gravatar imagePeter81 ( 2019-05-09 05:55:36 -0500 )edit

2 answers

Sort by ยป oldest newest most voted
0

answered 2019-05-26 14:31:36 -0500

drsgao gravatar image

updated 2019-05-26 14:34:31 -0500

Firstly, I would like to thank the OP for posting Siemens answer back.

Secondly, I would like to point out the documentation for the 'struct' module in Python is : https://docs.python.org/2/library/str...

Now, though Siemens has provided an answer, but I think is not complete, for the following reasons:

  1. The byte order is from the least significant byte to the most significant byte (in plain speak, right to left) or from the most significant byte to the least significant byte (left to right)? This affects the unpack format hugely. (I could guess the order when they say "last 16 bytes" for DC lines and FACTS, BUT, god, what do they mean by "last"?)
  2. To unpack, it would be useful to know (and easier to debug) if all the byte types and length are known. Siemens has provided all byte lenght, but not all byte types. For example, what exactly is "1 byte copy id"? What is the data type? Is a double? A 1 byte string or 1 byte pad byte? Similarly, what is the byte type for the reserved bytes?
  3. Endianness of the packed bytes. Assuming it is native?

From Siemens' answer, I could make some guesses. But they are guesses at best, I don't know whether they would work due to the points mentioned above.

Here we go.

import sliderPy

import struct

# this is the format to unpack, I am gussing it from Siemens' answer
# assuming Siemens means most significant to least significant
# int (i),
# int (i),
# copy id assumed unsigned long long (Q),
# 3 bytes reserved assumed 3 pad bytes (3x),
# int (i),
# int (i),
# int (i),
# 2 bytes ID assumed a single 2-byte string (2s)
# 1 byte OPF branch flow ID (s)
# 1 byte reserved assumed 1 pad byte (x)
CONST_STR_FMT = 'iiQ3xiii2ssx'

# just a simple wrapper to make debugging easier
# you could also use decorator instead
def unpackMapStr(mapStr, str_fmt=CONST_STR_FMT):
    '''
    Just a simple wrapper to make debugging easier.

    Parameter
    ---------
    mapStr : byte
        The map string byte returned from PSSE34.

    str_fmt : string
        The format for byte unpacking. 

        Default = CONST_STR_FMT

    Return
    ---------
    Tuple of the unpacked byte.

    Example
    ---------

    .. code:: python

        # pack a float into the double format bytes
        mapStr = struct.pack('d', 12.34)

        print(unpackMapStr(mapStr, 'd'))

        # note that the return is a tuple
        # you have to get the individual elements to make sense of it
        >>> (12.34,)
    '''

    return struct.unpack(str_fmt, mapStr)

if __name__ == '__main__':

    mydoc = sliderPy.GetActiveDocument()

    mydiagram = mydoc.GetDiagram()

    mycomponents = mydiagram.GetComponents()

    for mycomponent in mycomponents:

        if mycomponent.IsSelected() == True:

            try:

                print('Type : ' + str(mycomponent.GetComponentType()))

                # get the map string bytes
                byte_temp = mycomponent.GetMapString()

                str_temp = str(unpackMapStr(byte_temp))

                # if I guess right and it works, then you should see a tuple
                print('Map String : ' + str_temp)

                # Also note that the strings returned are in bytes
                # you may want to use the "decode" to convert them into 
                # something like 'utf-8'

            except:

                pass

Hope that you could get some idea from it. I don't know whether the code would work or not ... (more)

edit flag offensive delete link more
0

answered 2019-05-24 02:53:41 -0500

Peter81 gravatar image

The answer I got from Siemens PTI was the following:


The mapstring representation has changed in PSSE 34 where maptring values are an encoded 28 byte structure. When calling GetMapString() via the sliderPy Python module, the returned result is now this byte encoded string. When using PSSE interactively, this still holds true but the value is translated into something similar to: LII 153 3006 1

You can translate these new values programmatically. The bytes returned are in this order after calling mycomponent.GetMapString():

int (4 bytes) struct size
int (4 bytes) type
1 byte copy id
3 bytes reserved
int (4 bytes) bus number / from bus number
int (4 bytes) to bus number
int (4 bytes) last bus number
char (2 bytes) ID
char (1 byte) OPF Branch Flow ID
1 byte reserved

Alternatively, for DC lines and FACTS devices, the last 16 bytes are the name of the device instead of the bus numbers and IDs.


I don't know how to translate these new values. If anyone here know how to do this, please add an answer to this thread.

Siemens also informed me that they have a new module which is still a work in progress. The new module is called pssetag and would allow you to translate the byte encoded mapstring into a format similar to PSSE 33. I will return with more information regarding this when I have tested the new module.

edit flag offensive delete link more

Comments

Interesting that Siemens decided to use struct for simple thing like map string. It looks like it offers more details, but with added complication. Python has a 'struct' module designed to deal with pack binary data. I will write an answer for some suggestions.

drsgao gravatar imagedrsgao ( 2019-05-26 13:21:21 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

[hide preview]

Question Tools

1 follower

Stats

Asked: 2019-05-06 07:31:15 -0500

Seen: 877 times

Last updated: May 26 '19