How to convert structural data between Labview and TIA Portal(siemens s7)

[Harris Hu]

Through Siemens' S7 communication, I got some byte type data, but I didn't know how to convert these data into the corresponding structure data of labview.

It is well known that the bool of struct in TIA occupies one bit, but the bool of struct in labview occupies one byte.

Has anyone dealt with it?

[Bobillier]

you can't , I think, directly access the whole structure all at once. You must access each of its elements individually and rebuild your structure. Don't forget that your DB containing your structure must not have optimized memory access (see DB attributes).

Like this each element will have an address to be accessed.

 

[JKSH]

I don't have experience with S7 myself, but have you seen this toolkit? https://www.ni.com/en-us/support/downloads/tools-network/download.sp7-toolkit-for-labview.html

[gulshan212]

Hello this is Gulshan Negi

Well, I did search it on Google and I found that it seems that the user is facing a challenge in converting byte type data obtained through Siemens' S7 communication into the corresponding structure data in LabVIEW. When communicating with Siemens' S7 PLC, the byte data received needs to be properly formatted and converted to the corresponding LabVIEW data type. 

Thanks 

[Harris Hu]

Yes,I can parse basic types like int, real, string,etc.

But when I wanted to do the conversion of the struct directly, I ran into difficulties

[Bobillier]

Like I said before, it's not possible because In TIA struct (Like array) is a decorative declaration. It's just to facilitate the visualisation of a group of few data types in a same entity in TIA. But there is no sens of that in PLC, where struct datas  are stored sequentially without adding information about the struct itself.

And like with S7 communication you can only accedd to memory, you can only acceed to few bytes list and define from this adress to this adress it's one int or one real. no information about struct it's self in memory. You need to collect each data type and recreate struct after like in my image.

Edited May 11 by Bobillier

[Rolf Kalbermatter]

7 hours ago, Bobillier said:

Like I said before, it's not possible because In TIA struct (Like array) is a decorative declaration. It's just to facilitate the visualisation of a group of few data types in a same entity in TIA. But there is no sens of that in PLC, where struct datas  are stored sequentially without adding information about the struct itself.

And like with S7 communication you can only accedd to memory, you can only acceed to few bytes list and define from this adress to this adress it's one int or one real. no information about struct it's self in memory. You need to collect each data type and recreate struct after like in my image.

It's not impossible but it is also not something the typical toolkits support. The low level functions used underneath are based on requesting a number of bytes from a certain address in a certain DB element, then convert this as binary data to the actual LabVIEW datatype. For the standard scalar data types, all the S7 toolkits out there provide ready made functions that convert the actual bytes to and from floating point data, integers, timestamps, and even strings but so called complex data types are not something they can support out of the box without a lot of extra work.

But it is your responsibility to make sure that the DB address you specify for an actual read or write access is actually the datatype you used according to the VI. If you use a Read Float64 function for a specific address but the PLC has a boolean or something stored there, you simply read crap.

To support structured data we can not have ready made VIs that would provide an out of the box functionality. For one there are really an indefinite amount of possible combinations of data types when you add complex (struct type) data types to the recipe. And it is obvious that nobody can create a library with an indefinite amount of premade VIs.

So we would have to do some dynamic data parsing but that is not trivial. It could be done with Variant parsing code in LabVIEW where we try to map a specific LabVIEW cluster to a structured data type in the PLC memory. But this is quite involved and still leaves the problem of the user needing to be able to actually determine the correct cluster elements and order to map nicely to the PLC memory structure. A can of worms and a complete support nightmare as there will be lots and lots of support requests in the form of "It doesn't work!!!!!" 

The static S7 protocol as "documented" by the various libraries out there does not support datatype discovery from the PLC from a remote site. Siemens introduced a new memory model with TIA 13 or so that supports so called compressed DB elements with symbolic naming. Here the various data elements do not have a fixed address anymore but are aligned in memory to be optimally filling things. To be able to still read and write such elements, Siemens added a new protocol layer that allows to enumerate the actual elements in the DBs, retrieve their current dynamic address (a variable can end up at a different address every time you make any changes to the PLC program and deploy it) and then access it. This protocol extension, as the entire S7 protocol actually, has not been officially documented by Siemens for external users. Some commercial libraries have tried to support it, such as Accon AG-Link but I'm not sure if they did reverse engineering or if they have an NDA with Siemens to get that information. I'm not aware of any other 3rd party library that would support this and definitely none of the Open Source ones have ever tried to go there.

 

 

Edited May 11 by Rolf Kalbermatter

[Harris Hu]

As far as I know, if LABIEW and Siemens PLC transmit data through OPC, the structure can also be read. Maybe I need to understand how OPC does it.

[Rolf Kalbermatter]

40 minutes ago, Harris Hu said:

As far as I know, if LABIEW and Siemens PLC transmit data through OPC, the structure can also be read. Maybe I need to understand how OPC does it.

That's simple. OPC is a completely different protocol layer. You need an OPC capable server (which last time I checked was an additional licensed component) in your PLC to do that. Part of the OPC UA protocol is to enumerate all the available resources on a system. That includes data items and their data type. And the NI OPC library has an extensive part that converts between the OPC wire data and the actual LabVIEW data in a seemingly transparent way.

Snap7 (and all the other S7 Toolkits out there) communicate through the Siemens S7 protocol, which is based on ISO on TCP as basis protocol, and while the ISO protocol is an officially documented protocol, it is only the container frame in which Siemens then packs its own S7 protocol elements. And those S7 protocol features were never officially documented by Siemens, but the original protocol that only addresses fixed DB, EB, AB, MK elements was reverse engineered by projects like libnodave and then Snap7. No such reverse engineering has happened for the extended protocol elements present in the 1200 and 1500 series that support accessing "compressed" elements.

 

Edited May 16 by Rolf Kalbermatter