We have many S5 PLC's on our plant site and I have had, on occasion, my programs act as if they have been corrupted after I have made an online change. I have inspected my programs around the area that I have made edits and found no errors.

The problem that I had most recently did not even involve the area of the machine that I was trying to edit. It was in another PB block entirely. The only way I have found to clear this problem was to clear the memory and download the original program back into the PLC.

What are some possible cause(s) for this program corruption?

 

The most likely cause for this is 'Auto Compress' being turned on and something else, either the program or an external HMI, directly writing to memory. You could also be doing it to yourself if you do a compress after doing online edits.

Most HMI's that read and write values from DB's in an S5 do a query on startup to get the absolute memory address of the requested DB in the PLC. Once they have that address they assume that it's not going to change, and the communications with the PLC use direct memory reads and writes. It's also possible to do this in the S5 program itself, but you'd probably know it if you were doing it - it's not a simple thing to do.

When you modify the PLC program in an S5 the new block is written to the PLC and the old one is marked as invalid. With the older S5 software that's all that happened, and eventually you wouldn't have room in the PLC to do online changes. There was a manual Compress command that would shuffle all of the blocks in memory remove the holes (like defraging your disk). This changed the absolute location of the blocks that had to be moved, AND other blocks that needed to be pushed around during the compress.

At some point Siemens added an Auto Compress feature to the software. With this turned on the system compresses the PLC memory after an online change so you don't have to. The problem comes when an HMI is expecting a DB to stay put but the compress routine moves it. If the DB was in a location that is now empty it will just look like the comms stopped with frozen values. If, on the other hand, the DB occupied a location that's now lived in by a OB, PB or FB, the HMI will write values to the middle of the block, corrupting the memory.

The solution? First, turn off the Auto Compress if it's on (and if you can with the software you are using). Second, disconnect any HMI systems when doing any online changes in the PLC that might re-arrange memory. The third trick is, when loading the PLC, transfer the DB's in first, and then transfer in the FB's, PB's and OB's. If you do it in that order the DB's shouldn't move when you edit logic, although they still can move if you edit the DB itself.

 

Kenneth,
Thanks for the help, it makes sense and should allow me from having the same errors appear again.