Studio5000 V32 String LEN

Hi all

I experienced a weird string LEN on studio5000 V32. I have a string with 12 characters and string.LEN = 741355570
string values seems normal '054453980325', 12 characters...

Have any of you experienced issues with strings on Studio5000 V32?

Likely being populated by a misused COP. Using 2 dissimilar data types in a COP can produce odd looking results. Thing is, your SerialNum tag is structured like a STRING, it is not, it is the data type SERIAL_NUMBER, which is not the same as a STRING

How is the tag being populated?

Yep. STRING .LEN is an INT.

The COP instruction is more complex than it may at first seem, especially when working with UDT's, even more so when working with UDT's that are arrays or nested UDT's.

First thing to know is the COP is will copy byte for byte from source to destination. The source/destination data types don't really matter. Create a STRING and a DINT array, copy the string tag into the DINT array and see what happens.

The second thing that is important to understand is the length. It's easy to get this wrong. This tells the COP how many bytes to get from the source, based on the size of the destination type. So if your destination type is 88 bytes (STRING), your length is 2, it is going to try to copy 176 bytes from the source to the destination. If you are working with nested UDT's or UDT arrays, funny stuff can happen to adjacent data if you get the length wrong.

the .LEN attribute (of a string object) is a DINT; if .LEN were an INT, it would have to be be between -32768 (or 0) and +32767.



741355570 decimal is 2C303032 hex, or "200," when interpreted as four ASCII characters, assuming LSByte-first.

JeremyM said:

Yep. STRING .LEN is an INT.

Click to expand...

My bad, it's DINT.

Hi All

Thanks in advance.

The UDT is defined as a string[12].
I get the data from a CIP msg and the result is copied to destination tag using a CPS command.

just a few times the data on .len shows discrepancies.

Regards
Jesus

When you say STRING[12], this to me suggests that it is an array of the default STRING data type. What it appears to actually be be is a custom string with 12 characters.

Are the source and destination tags the same type?

JGax said:

Hi All

Thanks in advance.

The UDT is defined as a string[12].
I get the data from a CIP msg and the result is copied to destination tag using a CPS command.

just a few times the data on .len shows discrepancies.

Regards
Jesus

Click to expand...

Is the message a CIP data table read to another processor?

If not, is it a custom message to another device's class/instance/attribute? If so, what is the expected attribute data type or format?

JGax said:

Hi all

I experienced a weird string LEN on studio5000 V32. I have a string with 12 characters and string.LEN = 741355570
string values seems normal '054453980325', 12 characters...

Have any of you experienced issues with strings on Studio5000 V32?

Click to expand...

Possible catch here...

Are you copying to the INT tag named 'Destination' instead of the 'SerialNum' destination tag?

JeremyM said:

Possible catch here...

Are you copying to the INT tag named 'Destination' instead of the 'SerialNum' destination tag?

Click to expand...

Again, it seems more than a little suspicious that the anomalous ".LEN" is a 32-bit, i.e. 4-byte, i.e. 4-ASCII-character DINT comprising the ASCII characters "200," - I think it is likely that "200," is a 4-character prefix to the serial number, and it is being copied into the .LEN attribute (DINT) of the string.

Can you show the COP instruction, or upload a PDF of the entire program? Perhaps the COP Dest parameter is the UDT itself, Pallet[14].SerialNum, and not the Pallet[14]SerialNum.DATA[0]

Hi all

After long waiting.... Talked to Rockwell and it is a bug.... they basically say we will fix in the future.

Regards