does a UDT improve comm efficiency?

If I have arrays of 20 Real, 20 Dint and 20 Int to transfer between a compactlogix PLC and a contrologix PLC at a constant rate.

Am I correct that placing them all in a single UDT would make the communications far more efficient?
Is there a downside?

It should, especially if the 20 INTs are placed adjacent to each other for the best packing.

except for the need to use 3 messages to transfer the separate formats vs. one for the UDT, which is good by itself, are you saying UDT will pack the ints together in the "packet" ?
In the real world, is it worth the effort if speed is not critical?
In other words, while I find the idea good and interesting and want to implement it, will my successor find it more difficult to manage? Like using a nested loop could.

If you define the UDT in this way

REAL, DINT, INT
REAL, DINT, INT
REAL, DINT, INT etc

Then it will use 60 'DINT sized (32bit) words (the INTs each taking up a DINT sized space)

But if you define it as

REAL, REAL, REAL - 20 times
DINT, DINT, DINT - 20 times
INT, INT, INT - 20 times

then the INTs will only take up 10 DINT sized spaces. it will pack them 2 INTs to one DINT sized space.

It will pack them in the order you define (don't be confused when monitoring the values in a tag window, the internals of the UDT are shown alphabetically.)

I usually make a UDT with an array of reals and an array of DINTS. I use some of the DINTS for the booleans. I name the UDT's the same on both sides to help tracing bits as they bounce around.

I would say that packing them into a UDT is the way to go, as you reduce the messages from 3 to 1 (or 6 to 2 if you are doing read and write).

However, I would go the whole hog and use produce/consume on the UDT tags, and not have to worry about timed messages at all.

bernie_carlton said:

It will pack them in the order you define (don't be confused when monitoring the values in a tag window, the internals of the UDT are shown alphabetically.)

Click to expand...

The monitor will show them in the order they are defined in the UDT unless you choose to display them alphabetically (this option became available in version 19, or thereabouts). The pics are from V19

Thanks Daba

Haven't done Prod/Consume yet, perhaps its time.

TheWaterboy said:

Haven't done Prod/Consume yet, perhaps its time.

Click to expand...

It's much easier than messaging.

Have a go, and if you get stuck, just shout.

but more of a bandwidth hog yes?

Trade-off i'd say...

Message instructions use logic memory and have impact on scan times, they still have to transport the data, but you can schedule that with a timer, but that's more logic and scan time. The Produce/Consume RPI can be set up to 536870.911 mS, anyway.

Produce/Consume is just another I/O connection, that's how I/O modules transport their data, using the same Prod/Consume protocol on the network, so adding a Produce/Consume tag or two will not have a great effect unless you've got a maxed-out I/O network. In most cases you'd think nothing of adding a new I/O module into a system, but that's effectively what you are doing by adding a Produced/Consumed tag, the producer controller is acting like in Input module to serve up the Produced tag's data to the consumer controller.

The latest revisions of firmware also allow you to include the "Connection Status" as the first part of the Consumed tag, in that you can directly see whether the connection is valid, without having to monitor the messages with watchdog timers etc.

One other advantage of Produce/Consume is that the data is transferred even if one or both controllers are in Program mode, and the remote processor's mode is flagged-up in the Connection Status data that you can add to the tag.