Compactlogix UDT dat corruption

Hello all.
I have a project that I am working on with a compactlogix5343 1768-L43.
I needed to expand the tags on an existing UDT.
Basically this UDT contains a mixture of REALs/Strings/INTs etc.
I added several new tags offline and downloaded to the PLC with no issues.

No other changes were made ...logic or otherwise.

Shortly after restarting...garbled data started showing up in the original tags within the UDT objects.

Seems almost like there may be memory address overruns occurring.

Does anyone have any similar experience ?

Thanks ahead of time for the replies.

What revision?

I know that if you add or modify elements if your UDT, it can wipe out and reset values.

If you modify the structure of a UDT, all the data inside it should be considered invalid. UDTs have masks and offsets that are not visible to the user and are just a way to label specific offsets inside a 32-bit memory space.

To preserve the original data, RSLogix 5000 would have to separately store each sub-element (of each instance !) in a temporary file, then deal with the possibility of re-named elements being at different locations inside the data block, then put all the data back into the previous registers and zero out all the new registers. It does not attempt to do so.

If you just add elements to the end of the UDT, typically all the previous data stays lined up, but I wouldn't bet my machine on it.

Storytime: I have a junior programmer who recently proudly delivered to me a program in which he put all of his "internal" registers into on huge UDT, and all of his "HMI" registers into another huge UDT and all of his (four axis) motion-related registers into another huge UDT.

Every time he had to create a new tag, he went offline, modified the UDT, and re-downloaded.

And, of course, he had to write a couple really big initialization routines.

And he didn't realize that the HMI has to read the entire UDT every time it accesses any of its sub-elements, which slowed the comms to a crawl.

We had a long lessons-learned discussion, which ended with glasses of beer the size and shape of a cowboy boot.

Thanks for the quick responses.

I don't have access to the revision today, but will get it Monday.

Just to clarify... I had no real interest in preserving the data contained in the UDT fields from offline to online.
These UDTs are used to carry production information from stage to stage in the assembly process and would have started "fresh" as we started the line back up empty of product.
Data is posted to them throughout the assembly process and then they are read once at the end of the production cycle by an OPC client.

Ken your point about memory construction of the UDT makes sense, and I will test again, but if my memory of the situation is that several of the elements still contained corrupt data even after having new information copied/moved to them.

This might make sense for a string but I had at least one float that contained something like 1.23455E-10 after a value like 2.34 was written to it.

Of course I was under pressure to get the line back up and had no time to experiment.

[email protected] said:

This might make sense for a string but I had at least one float that contained something like 1.23455E-10 after a value like 2.34 was written to it.

Click to expand...

Just a thought... you'll want to double check any & all COP/CPS instructions involving these modified UDTs. Anything that's copying more than one element may now be grabbing something other than what you'd expect.

Well...RonJon nailed it.
Embarrassed to admit it...but had a copy instruction copying a string re: COP stringXXX UDT.stringYYY stringXXX.LEN

Changed stringXXX.LEN to 1 and everything cleared right up of course.

Thanks for all the replies!

Been there, done that; it's why we're here. Welcome to the club!