Wandering Code?

Here is my situation. Had a SLC 5/04 running a machine fine for 10 years, no problems. As part of a plantwide upgrade I swapped out the 5/04 for a 5/05 about 8 months ago. It ran fine until last friday. The machine started acting silly, and when I went online with it I discovered that the lines of code had in several locations inside the main subroutine relocated themselves, appearantly at random. The problem code turned out to all have one-shots in them that no longer performed as they used to. Has any one ever heard of this happening spontaneously or do I have some one with unauthorized access mucking about, (I am getting the usual chorus of NOT ME from the manitenance staff) and given the average programming capabilities of the people involved I tend to beleive them, the program is 1400+ lines, and they are very intimidated by it. I do however have several "experts" in other locations who in theory could have gotten in via a secure internet portal........

..that the lines of code had in several locations inside the main subroutine relocated themselves, appearantly at random.

Click to expand...

I know of no standard programming method that would relocate lines of code as part of the normal routine. I have never heard of a hardware problem causing the ladder rungs to get moved, but I suppose it is possible. It is not very likely to happen though.

The most likely cause of a program getting rearranged is a two-legged nerd, with access to the program.

When you say the one-shots no longer performed as they used to, what do you mean they did instead? A one-shot can only do one thing ONE time per scan. What are they doing besides that?

Sorry Lancie,

I reread my posting and realize I could have been a little clearer.
The one-shot lines in question were moved to a point after the intended target line thus negating the one-shots effectivness.

On line editing can be the source of your problem.
You could use the checksum to find out if "things" have changed and then you can tell them that someone did make changes.

Isn't there something called "Jaochim's Razor" that states the most obvious answer is the correct answer ? My money is on one of your "experts" . Are there any files that you could check the timestamp that may give you an idea of the time that this occured ? I had an entire SCADA system just stop working (according to operators) when I checked it out the software wasn't even on the pc anymore ! But no-one had touched it. It was only by luck that about a week later (after re-installing software) I came into the control room early one day and surprised one of the operators, he quickly left the room. When I checked the SCADA Pc he had inadvertently left his porno DVD in the drive, turnms out they were watching dvd's during quiet times and then unistalling the dvd viewer when they were finished in an ttempt to cover their tracks.

Checksum sounds like the way to go. I'll drop some code in and see what turns up.

Funny you should mention this, because I had a contact disappear the other day in a routine, that among other things, controlled a safety mat (but not the logic in the in the safety PLC).

Up until that point I have never even *been* in that routine. Not even looking around.

The routine that was working in was some old logic that controlled a part of the machine that had been removed. I was removing unused tasks when the safety mat stopped inhibiting the turnover.

This was actually a good thing in that we found out that the contractor didn't have any code for the safeties in the LSP.

I fixed the missing contact problem, and went back to work on removing old code. Not long after that the sonic welder went down, I fought it for what seemed like forever, and eventually it started back up.

The next day, the Snap Press went down and I eventually gave up on trying to diagnose the problem and dumped an older copy of the program in back in.

After this had happened three times I was pretty sure where it was coming from, and just to demonstrate the problem, I added one contact to a non-functional (AFI'ed) rung. Sure enough, the Snap Press went down. Removing the contact didn't fix the problem. I ended up dumping in an older copy.

At this point I'm waiting on Maintenance to swap out the processor and Safety Partner with new ones. I hope that will clear up the problem.

Otherwise, I'll convert the program to a .L5K file and re-import it.

And the routine that is causing the problems has no ties to where the problems are happening. So I'm confident that it isn't me screwing things up.

BTW, this is a Logix 5562S and a 55LSP.

I'll post this as a new message in the forum as well.

Edit:

Just to clarify, any editing (even in non-functional rungs) in this one routine will cause other routines to **** out. Editing anything in any other routine is no problem whatsoever.

Yep - most likely your "experts".

Sorry my Bad it's not Jaochim it's..
Occam's razor (sometimes spelled Ockham's razor) is a principle attributed to the 14th-century English logician and Franciscan friar, William of Ockham. The principle states that the explanation of any phenomenon should make as few assumptions as possible, eliminating those that make no difference in the observable predictions of the explanatory hypothesis or theory. The principle is often expressed in Latin as the lex parsimoniae ("law of parsimony" or "law of succinctness"): "entia non sunt multiplicanda praeter necessitatem", roughly translated as "entities must not be multiplied beyond necessity".
This is often paraphrased as "All other things being equal, the simplest solution is the best."

Actually I thought it was impossible for the code to change with "help" but i ran into something at a customer site recently. About a year ago we had done some major upgrades to this facility, it is an ols installation and uses alot of AB remote I/O. Then this summer they added a couple of new things so i went down to make the changes and test. When I left everything was working fine. I went down about a moth later because they had some lightning hits and along with a number of devices damaged from the lighting the panelview connected via remote I/O to the main processor did not appear to be operating correctly. There was no updates but I was not getting the typical PLC communications error. The comm light was on, everything in the PLC messaging appeared to be working since I was getting no error messages. So I loaded in the version from when I was there a month earlier and everything worked. So I did a compare and found that the data register in one of my message blocks had been changed. I corrected it in the latest software and my communications was back up and running. We continued to work on some other issues but later that day I was having the same problem with the Panelview. I checked the data address in the message block that had been changed earlier and found it was now a different address then what it had changed to before. I knew I was the only one connected to the system so I corrected it again. When I got back to the office I did a knowledgebase search on the Rockwell site and found #49254 RSLogix Version 7.30.00 Anomaly Will Alter Addresses In SLC and ML Projects. Apparently in this version if you do a bit level search for an address, it will alter the addresses of the BTW, BTR and MSG instructions. The fix was to upgrade to version 7.30.10. I did the upgrade and have not had a problem since. I had upgraded to 7.30.00 earlier in 2008 so this is why it never happened during the original installation in 2007.

I was surprised Rockwell had not sent out an alert to all the RSLogix500 users on this one because I have never seen anything like this before.

Thats some good information there! So our thoughts about "PLC Programs never change themselves" could be wrong then!

Glad I am still on version 7.0!!!

OT: I began reading this thread last night after watching another episode of "The Sarah Conner Chronicles" (a continuation of the "Terminator" story). I began having visions of the rise of "Skynet" in self-modifying code appearing everywhere. Strange things are happening.

DEVO said:

..... and found #49254 RSLogix Version 7.30.00 Anomaly Will Alter Addresses In SLC and ML Projects. Apparently in this version if you do a bit level search for an address, it will alter the addresses of the BTW, BTR and MSG instructions. The fix was to upgrade to version 7.30.10. I did the upgrade and have not had a problem since. I had upgraded to 7.30.00 earlier in 2008 so this is why it never happened during the original installation in 2007.

I was surprised Rockwell had not sent out an alert to all the RSLogix500 users on this one because I have never seen anything like this before.

Click to expand...

Not Quite Self Modifying, more like undocumented enhancments. The PLC wasn't modyfying code of it's own bat it was incorrectly interpreting instructions in this case it thought "bit level search" meant "do something stupid with existing code". It still required some form of operator intervention.

Automatic Reboot on Bad RAM

And hence the reason that I always employ an EEPROM set to boot from EEPROM or Reboot on bad RAM depending on which is most desirable.

Best Regards,

Bob A.

PS. Did anyone say "Cosmic Radiation" ? I'm told that it has been shown to flip memory values.