Micrologix random bits

[Kiljoy]

Has anyone experienced this problem? We seem to have a recent problem with the MicroLogix 1500 LRP processors. Randomly, we have had unused bits go high and integer values re-write themselves. In one instance, the first 20 timer presets in the program all reset themselves to 0. We have the EEPROM set to load on memory error only and the presets should all be burnt in during commissioning.
We have had some process error bits in the program reserved for future use. They had neither OTE or OTL instructions referencing them. When they randomly go high, the customer has no way of resetting them except disconnecting the battery and forcing the EEPROM to load.
Of course the Rockwell tech people always tell you it's not them. They think it might be our Parker CTC touch screen driver. This only started showing up recently.

 

[TWControls]

Can you post your programs somewhere?

----------------------------------
TW Controls -

http://www.twcontrols.com

 

[sdb830]

One thing you may want to check is the touch screen configuration, some of them allow you to write from the touch screen on start up which means tbe register in the touch screen overwrite the PLC. Possibly the touch screen is restarting occasionally and writing bogus values. Usually you can select the option to write or not from the Touch Screen.

 

[Kiljoy]

I wish that were the case. We have been using this particular touch screen program for several years and we do not tell it to write on start.
The bits in question are not addressed in the touch screen program and they do not have trigger coils in the PLC program. In one instance, the first 20 timer's (T4:0-T4:20) presets reset to 0. We have no use or desire to even change the presets through the screen or program.
I was wondering if anyone else has experienced the phenomena of bits or presets changing without being told to. Of course when you call Rockwell tech support, the standard greeting is. "Rockwell tech support, what did you do now? It's your fault!" They tried blaming it on our touch screen since it wasn't their’s. If the problem were in our programs, it would do it on all of the machines, not just a random few. Is a batch of bad processors possible?

 

[rubha]

Why don't you just hard code the presets. Since you are not changing the presets, use a "MOV" instuction to constantly write the Presets.

 

[Kiljoy]

That's exactly what we did. The guy that actually wrote the program sometimes takes a machine gun attitude and overdoes it on the programming complexity. That's why there were several bits that did not have coils that were reserved for future machine options. They went high and were not resettable without a laptop.
That being said, the timer presets that went to 0 WERE hard coded. And why did the unused bits go high? Perhaps cosmic rays??