MSG Instruction Type Checking of UDTs

I have some questions about MSG Type checking

1. Does a MSG instruction care if the name of the UDT type are different on each PLC as long as their member are identical?
   • Basically can I rename a UDT Type, but not the tag name on one system and not cause an issue?
2. Does a MSG instruction care if the names of the members are different as long as the type and order of members has not changed?
   • example, can I have a UDT defined as 3 DINTs called number1, number2, and number3. then import that in to another PLC and rename them huey dewey and louie? Will the MSG instruction still work?

I am wondering about this because I want to know if there is a way for my to update my communications UDTs on our customer's PLCs while that are online.. I don't want to rename the UDT type on my machine only the customer's machine that is talking to mine. Customers can't do downloads as they are continuous process, my machine is not so I do a lot of UDT and AOIs and just do a download.

theColonel26 said:

I have some questions about MSG Type checking

1. Does a MSG instruction care if the name of the UDT type are different on each PLC as long as their member are identical?
   • Basically can I rename a UDT Type, but not the tag name on one system and not cause an issue?
2. Does a MSG instruction care if the names of the members are different as long as the type and order of members has not changed?
   • example, can I have a UDT defined as 3 DINTs called number1, number2, and number3. then import that in to another PLC and rename them huey dewey and louie? Will the MSG instruction still work?

Click to expand...

Interesting question. My guess would be that it will work fine as long as the tag name specified in the MSG instruction matches and the data types are identical. if I can find a little time I'll test and see.

theColonel26 said:

...Does a MSG instruction care if the name of the UDT type are different on each PLC as long as their member are identical?

Click to expand...

The names of the UDTs themselves do not need to match.

theColonel26 said:

...Does a MSG instruction care if the names of the members are different as long as the type and order of members has not changed?

Click to expand...

That's a good question. My initial thought is that it wouldn't care about the names of each member, only the data types for each member, and as you said, the order. But I'd want to verify before I said for sure.

OG

Did some quick testing on an idle machine with copying an existing UDT and changing names then trying to do a CIP data read from the next machine over. The MSG errored in all attempts if any name was different, whether the type name or a member name. Extended error code 16#000_2107, which I've seen Ken Roach say indicates that the data types for the source and destination do not match.

plvlce said:

Did some quick testing on an idle machine with copying an existing UDT and changing names then trying to do a CIP data read from the next machine over. The MSG errored in all attempts if any name was different, whether the type name or a member name. Extended error code 16#000_2107, which I've seen Ken Roach say indicates that the data types for the source and destination do not match.

Click to expand...

Wow. I was pretty certain I've used different names for the UDT structures.

OG

Rockwell has published the algorithm used to generate the datatype CRCs that are used in UDT tag read/write operations:


https://www.rockwellautomation.com/...tion/sites/downloads/pdf/TypeEncode_CIPRW.pdf


Type names (both elemental and UDT) and member names and dimensions are included in the string fed to the CRC-16.

Was brought back to this thread by another one, and felt the need to add to add an exception of sorts to the general conclusions this thread reached.

The names of BOOL elements can be changed. This is likely why OG remembered having used different names.

The reason for this is that BOOLs are packed into either SINT (<=8 bits consecutively) or a BOOL[64] array (>8 bits). The Type Encoding String used to generate the CRC will include the SINT or BOOL array, not the individual bits. This can be seen in examples STRUCT_A & STRUCT_B on pages 9 & 10 of the document pturmel linked.

Disclaimer: I have only tested with a number of bits that would be packed into a SINT, but I have no reason to think it would work differently for the array.