Logix5K can I pack/unpack REALs in a DINT array?

Hey guys,

For sending data back and forth between Control/CompactLogix PLCs, I've always created four MSG blocks, two read and two write; one is for BOOLs and DINTs packed into a DINT array, and the other is for REALs packed into a REAL array.

I always assumed that it would be a bad idea to pack REALs into a DINT array, but now that I've gotten to thinking about it, I wonder if it would be OK to do so; at this point I don't have any AB PLCs laying around and I'm not going to change the existing code I created, but for future projects I wonder if I could simplify my MSGs by packing REALs into a DINT array and just having one MSG for read, and one for write.

Yes, you should be good. This only becomes a concern when exchanging data between devices with different endianness.

Instead create UDTs and configure the data you need. Mix REALs, DINTs and BOOLs together as needed.

If the logic that "packs" the REAL data isn't interrupted by a change in the REAL data, and if the MSG logic doesn't inadvertently run while the packing logic is in between elements (or the data doesn't arrive while the unpacking logic is in between elements) then you're OK.

The Copy Synchronous (CPS) command, instead of the COP command, helps prevent data from being changed in the middle of an array copy instruction.

But if you make a mistake or something happens (one time out of millions) just because an event overlapped in the controller OS while you were copying data between dissimilar datatypes, you're going to have a bad day.

Packing REALs into integers is a big enough headache when I'm forced to do it by Modbus devices. You have the ability to keep your datatypes separate, and I recommend doing so.

jkerekes said:

Instead create UDTs and configure the data you need. Mix REALs, DINTs and BOOLs together as needed.

Click to expand...

Hmm, this is an interesting concept. Your thought is, if you figure out how big your data messages are you could create a UDT that would fit that, and then you'd just copy the UDT from PLC to PLC...am I picking that up right?

Some of my larger messages are literally over 150 length DINT arrays...so if you ever needed to add something you'd have to modify the UDT on both sides. Would you think this method would work with the scale of data I'm dealing with?

Ken Roach said:

If the logic that "packs" the REAL data isn't interrupted by a change in the REAL data, and if the MSG logic doesn't inadvertently run while the packing logic is in between elements (or the data doesn't arrive while the unpacking logic is in between elements) then you're OK.

The Copy Synchronous (CPS) command, instead of the COP command, helps prevent data from being changed in the middle of an array copy instruction.

But if you make a mistake or something happens (one time out of millions) just because an event overlapped in the controller OS while you were copying data between dissimilar datatypes, you're going to have a bad day.

Packing REALs into integers is a big enough headache when I'm forced to do it by Modbus devices. You have the ability to keep your datatypes separate, and I recommend doing so.

Click to expand...

Very interesting info Ken, thanks for sharing. Would you still use CPS when copying like datatypes, or is that not an issue since you're sticking with like datatypes?

defcon.klaxon said:

Hmm, this is an interesting concept. Your thought is, if you figure out how big your data messages are you could create a UDT that would fit that, and then you'd just copy the UDT from PLC to PLC...am I picking that up right?

Some of my larger messages are literally over 150 length DINT arrays...so if you ever needed to add something you'd have to modify the UDT on both sides. Would you think this method would work with the scale of data I'm dealing with?

Click to expand...

It depends how you are "sharing" the data.

There is no limit to the size of a UDT when using messaging, the system just chops it up into xxx byte chunks, and the MSG instruction reports DN when the whole of the data has been transferred. The message could take several scans of your logic to complete. This could have consequences if the data being sent is changed between initiating the MSG, and when the MSG completes.

Produced/Consumed tags are transferred in their entirety, but there is a 500 byte limit to the size of a Produced/Consumed UDT tag. This fits into a CIP "packet" of 512 bytes, so is transferred in one hit.

500 bytes is 500 SINTs, or 250 INTs, or 125 DINTs or REALs, or a corresponding mix.

When building UDTs, minimise the tag size by ordering the elements by size... grouping all BOOLs, then SINTs, then INTs, then DINTs and REALS. You can even do this in reverse order. The system will allocate into the 32-bit memory architecture efficiently.

daba said:

When building UDTs, minimise the tag size by ordering the elements by size... grouping all BOOLs, then SINTs, then INTs, then DINTs and REALS. You can even do this in reverse order. The system will allocate into the 32-bit memory architecture efficiently.

Click to expand...

This is definitely a best practice, especially if you're producing/consuming UDT's. But if it's a large UDT and restricted to the processor (a base tag), screw memory consumption and define the members alphanumerically. That's just my $.02, but the individuals following you will appreciate it.

AutoMax said:

This is definitely a best practice, especially if you're producing/consuming UDT's. But if it's a large UDT and restricted to the processor (a base tag), screw memory consumption and define the members alphanumerically. That's just my $.02, but the individuals following you will appreciate it.

Click to expand...

Having the members of a UDT in alphanum order is not necessary, and can be extremely costly, especially if you create large arrays of that UDT.

Logix/Studio5000 allows you to view the members of tags alphanum if you want to, but there is absolutely no need to create the data structures that way.