PLC inconsistencies/ errors

[DAlgie]

I am using a T100MD 16-16 to run a composites oven. I upload a new file quite often to change max temps, ramp times, etc. Lately, the plc has caused some errors, random stuff like overtemp, or not finishing it's cycle, miscount on cycle times, etc. Nothing has changed with the program really, I just change a couple of parameters in it to modify the output, and it has always been very reliable in the past years. Can the PROM become corrupt over repeated downloads? I am using Trilogi in DOS, from Windows 98, is there something in this setup that could corrupt the compiler?

[support]

You may want to conduct online monitoring to check that if your analog inputs are receiving correct data. It could be a sensor fault, an analog input hardware fault that resulted in your program acting strangely (to you that is, although the PLC could actuallly be acting correctly based on the data it receives).

The program is unlikely to be corrupted on its own and still continue to run, since every time you power on the CPU perform a checksum on the EEPROM content against a stored checksum during program transfer. If there is any corruption the CPU will halt the processor and turn on the PAUSE light to prevent executing a corrupted program.

However, when you run a DOS program inside a DOS prompt under Windows 98,  the DOS communication program may lose characters due to Windows task switching. The DOS TRiLOGI uses the FCS error check to check against such lost characters and re-transmit the message it if detects an error. But there is also a possibility of multiple byte loss resulted in a correct FCS (even though the string is wrong) and the DOS program treated it as correctly transfered. So even though  it probably got transferred correctly 99% of the time, there is still a possibility that the last transferred program may contain incorrect bytes.

You may want to start your computer in pure DOS mode to run DOS TRILOGI program  to send your DOS trilogi file to the PLC. That way it is more reliable. Or switch to using Internet TRiLOGI version 5.x to transfer your program under Windows.

You may want to re-transfer the program to the PLC to see if it eliminate the problem. If not, then most likely it is a hardware issue.

[support]

The EEPROM in the PLC can be overwritten 100,000 times, so  I don't think you have transferred your program 100,000 times in the last few years unless you are using an automated device to continue to transfer the program.

However, if you run the SAVE_EEP, or SETTIMERSV and SETCTRSV instruction very frequenty in your program, then it is possible to exceed the maximum life of the EEPROM.  If the EEPROM wears out it will affect the location that is being repeatedly written to but it may or may not also have some effect on other memory location.

If you think you could have worn out the EEPROM, it is a replaceable part. Contact us at sales@tri-plc.com to purchase a new EEPROM to replace the worn out one.

[DAlgie]

Hmm, some good info. No, I haven't written to the PROM THAT many times. The PLC is running as I write this (At 12:45am) without problems, seems the last time I sent the program it was ok. All I have checked it, I am pretty sure the data the PLC is getting is ok, because the one time it went overtemp, the LCD also showed the temp to be as it actually was, and the PLC uses this same data to control. From what you said about Windows, I have a suspicion that that may be where the problem is, and will look closer at that, like you said, start the thing up in pure DOS and download from there. Thanks!