RSLogix 5000 string datatype LEN field

We recently have experienced an unusual phenomenon in a Logix5000 controller which I'm trying to understand better and am hoping someone can explain.

We discovered the issue after we updated the IGS driver on our iFix SCADA v3.5 server from 7.25f to 7.25i, but we're absolutely mystified as to how that could have caused this issue to show up (and maybe it isn't the cause).

Here's what is happening (sorry for the verbosity, but it's a bit complicated)

We write our batch number from the SCADA server using a TX block to a String data type in the PLC. The IGS driver address is
AI700_PCS.AI700_PCS.CIP_BATCH_NUMBER.DATA/82@STRING

We write just to the .DATA field of the string. The .LEN field of the target String in the PLC updates correctly to match the length of the entered string.

In our PLC code we have a COP statement that copies the batch number to the batch number buffer. The statement is COP CIP_BATCH_NUMBER.DATA[0] CIP_BATCH_NUMBER_BUFFER.DATA[0] 82
i.e. we just copy the .DATA and copy all 82 character fields. However in this case the .LEN field of the BUFFER string DOES NOT update to match the length of the BATCH_NUMBER string. The values in the BUFFER .DATA fields do update, so the string is there.
Later in our batch we read the BUFFER back into our SCADA using a TX block with address AI700_PCS.AI700_PCS.CIP_BATCH_NUMBER_BUFFER.DATA/82@STRING

but the string that gets read by the BUFFER in the SCADA only reads as long as the .LEN. Because the LEN is not updating properly, we have not been getting the correct BUFFER string back into the SCADA (i.e. if .LEN is 0, then the BUFFER string will be empty in the SCADA even though the BUFFER .DATA fields in the PLC have values.)

If I manually change the BUFFER string in the PLC, then the LEN updates properly, but when the string gets updated by the COP statement then the .LEN DOES NOT update.

Has anyone seen this before? What is really strange to us is that this code worked fine just 2 days ago, and again, the only change has been an update to the iFix IGS driver, we have not touched the PLC at all.

Any help is greatly appreciated,

Regards,

Greg Krueger

To the best of my knowledge the CLX operating system doesn't automatically maintain the .LEN field in a string data type. The .LEN field is modified by string instructions when they operate and by devices that write to the string data type. If you copy from one string to another and only copy the .DATA elements the .LEN field in the destination string will not be updated correctly.

My guess is that the old driver didn't use the .LEN field when it read the strings. It probably read the string contents until it encountered a null character (00h) and then called that the end of the string. The new driver probably uses the .LEN value so now the problem appears.

I would try to move the .LEN field from the source string to the destination string and see if that does the trick.

Keith

Thanks...

Keith,

I appreciate the quick response. Your explanation of how the driver may have changed definitely makes sense. We were already considering the .LEN copy in addtion to the .DATA, but we wanted to try to understand the issue more before we applied that fix, just in case there was something else going on here.

Regards,

Greg K.

By the way, if you do a COP specifying the String Tagname without the DATA member and array index, the PLC will copy over the LEN field as well. (I think Keith was basically saying this).

You need to do COP to STRING.DATA and MOV to STRING.LEN

single COP will work only if your source has .LEN field and it is in DINT format

This Helped me solve my issue so I thought I would clarify for the Google lurkers. I have a 3rd party device that has 8 ascii ints pulled over from an AOI. I needed to move this array of ints into a string for SQL.

so I used a copy from AsciiIntArray[0] to StringArray[0] with a length of 8. I had the same issue as the guy above. My StringArray.len was stuck at a weird number.

I did a cross reference and realized there was a test value I was still writing to my StringArray that was 3 digits long, which was the reason for the stuck length. After that I added a Mov 8 to StringArray.len and everything worked as intended.

Thanks for the help Google bots!