UDT Read Performance - Most Performant Logix Code?

[OwenDavid]

Using pylogix to read a UDT from a compactlogix 5370 controller there is a concern that the Logix code is not optimal.

The pylogix part has been optimised by creating the UDT of several hundred tags and thus making only one tag read request every 100ms. This is all good.

However to populate the UDT we are using a ST routine to copy the individual tags (300 reals and 300bools). The routine has a scan time of almost 1ms and we are looking for a better way.

Any thoughts on a more performant method than 600 line by line copy and pastes?

We have access to Ladder, ST, etc..

[chrisegge]

It's a bit of a pain, but I would use aliasing if it's all just a 1:1. I am kind of surprised it's taking that long though honestly.

[dmroeder]

If you used arrays at all, then using a for/loop might be appropriate. Otherwise, you might have to use brute force. If there is a pattern to the naming convention, then I'd write a script to generate the 600 lines.

[chrisegge]

I think his question is how to optimize his copying or moving tags into the UDT. I was recommending aliasing so he wouldn't have to do any of it in the program. Just uses more memory in the PLC.

[OwenDavid]

Yes, exactly so. We are trying to get data into the UDT in the most performant way.

We have found that the elements of a UDT cannot alias other tags in the controller such that,

udt.real[0] != alias tag of pressureTag_Real
etc..

and instead the controller tags would have to alias the UDT itself. Thus the 600 controller and program tags would need to be converted one at a time to be elements of the pylogix UDT, such that,

pressureTag_Real = alias tag of udt.real[0]
etc..

The other approach taken from Rockwell publication 9324-wp007_-en-p.pdf is to create a program with a single UDT tag as an input parameter.

The various controller tags can then be connected to the UDT elements. If the program is in a periodic task then all of the elements will be updated cyclically and the program would require no routines. The Rockwell pdf suggests that 80 parameters were scanned in 80 micro seconds and I believe that the connections can be updated online. This may have benefits over aliasing especially when the program xml file can be edited to make the connections (assuming both tags are already defined in the program).

<ParameterConnections Use="Context"> <ParameterConnection EndPoint1="PosnDint_1" EndPoint2="\Histv2.hd.d[3]"/> <ParameterConnection EndPoint1="PosnDint_2" EndPoint2="\Histv2.hd.d[7]"/> </ParameterConnections> </Controller>

We will give this a shot and see how much it reduces scan time.

[OwenDavid]

Thanks for the reply.

So if we have a UDT tag called pylogix comprised of [300]real and [300]bool with a structure,

pylogix.real[0]...[299]
pylogix.bool[0]...[299]

and we are copying tags into this UDT using a ST routine,

pylogix.real[0] := pressureTag_Real
pylogix.real[1] := tempTag_Real
etc...

That you are advocating the following...?

pressureTag_Real != base tag with controller scope
pressureTag_Real = alias tag of pylogix.real[0]?

Such that the ST routine would then become redundant as the data already resides in the UDT ready for pylogix to read. Is this a recognised and widely practiced approach? It is quite new to me. Could it lead to any confusion or misinterpretation for other programmers?

On closer inspection there are also a number of INT and DINT tags that are being converted into the REAL array; likely increasing the scan time further. Another possible performance improvement would be to expand the UDT structure to include a DINT array.

[chrisegge]

Aliasing just means you don't have to do any programming for it. So it just eliminates the scan time thing you were trying to optimize. The data types would have to match if you did aliasing. As for the different data types with move instructions, I don't think moving an INT into a DINT would slow anything down. If your doing a DIV with the the result going into a real that shouldn't hurt either. If you really want to get into the nitty gritty to understand the speed your logic executes you can look at Rockwells publications on their instructions. They have documentation on how long each instruction takes to execute. Either way, UDT's are always best when tags need to be accessed by an external source. How you get them in their is up to you.