Corrupted Strategy - old forum post


Joined on 02-16-2004
Posts 3
Corrupted Strategy

Hi there! I’m running a M4SENET-100. I ran into a problem where the Strategy program went corrupt on the PLC. The problem was found easily and resolved quickly by simply downloading a backup copy of the strategy to the PLC, but I need to know why the software went corrupt. Has anybody experienced a similar problem before? Any ideas?
02-17-2004, 4:17 AM

Joined on 12-01-2003
Optomation Systems, Madrid, Spain
Posts 153
Re: Corrupted Strategy

It would be nice to know how you define corrupt. Often people believe that “corrupt” is that the program does not reply to the Ethernet host port which is quite another problem. If this is a repeatable problem, it could indicate a hardware problem. Without a definition of exactly you saw, its quite difficult to answer this one on a forum. Here are just some of my favourites, although I am sure there are many more and needless to say none are obvious!

  1. On completion of download, the stategy is error checked with a checksum. If this does not match that of the strategy, the program is regarded as corrupted and will be erased for safety. Check communication quality and configured packet size (UltimateIO)

  2. If you have done multiple and repeated changes in Online mode, there is a possibility that the controller looses track of all the changes and regards the strategy as corrupted if you do not switch back to CONFIG mode.

  3. You did not mention which controller you are using. FactoryFloor controllers have battery backed RAM that on low battery can will loss of program after a power loss if the program is corrupted.

  4. Sometimes deleting persistent variables and renaming variables to the same names can confuse the controller, causing it to consider the database as corrupted when it is not.

  5. Like any system, with a little advanced knowledge, it is technically possible to write to areas in the controller that you should not write to, but this is usually a problem for beginners.

  6. Its not a good idea to write to flash while developing the program. It is possible to damage the flash by continually writing to it, which would cause program corruption.

  7. OptoDisplay stores display tables in the controller to optimize display update. These reference tables created for every window take up space, so in a large program you could actually use up the available memory with project display requirements. You can also cause a similar corruption by not synchronizing display projects on different PC’s. driving the controller crazy.

  8. Running an M4SENET on an M4 or M4RTU may also require a memory expansion for your application. How much free memory do you have. Are you archiving to the controller or not. This uses memory.

  9. The object database created by OptoControl and ioControl occasionally can get corrupted by constant changes. Try CTL-R over the controller in configuration mode to organize a re-sort of the database. If unorganized uncompiled code is downloaded to the controller, it could cause problems later.

  10. Modifying subroutines and their defined parameters can sometimes cause corruption in the subroutine that may not be complied correctly. Until the subroutine is called, the full effects may not be appreciated. In these cases its better to rewrite the offending subroutine.

  11. If you are using the controller to talk to other devices via RS232/RS485 it is possible to create buffer overflow in the comms ports especially when using Opto as the slave device. Saturation of the buffers may cause overwriting of the program area corrupting the program.

  12. As with any industrial equipment, Opto22 equipment does not like interference from XRays, Microwaves, Radio RF, power lines etc. Without considering installation and suitable cabinetry, it is possible to corrupt the memory of the controllers due to external interferences.

  13. There were a couple of older software levels that could occasionally cause corruption in the controller, if it was communicating on serial lines when the power was lost. This was fixed some time ago, but you may like to check with product support.

  14. Upgrading source code from one level to another of OptoControl or IOControl can cause problems. You should carefully check messages that are given in the error log when upgrading OptoControl.

I would suggest talking to product support at Opto, who can help you diagnose in more detail what happened, although if not reproducible its pretty near impossible. Oh and on a slightly humorous note! While Opto22 controllers can suitably replace the functionality of PLC’s, I am sure you are aware that their capabilities are far beyond that offered by PLC’s. Opto22 Controllers usually get quite very upset when they hear themselves referred to as “PLCs”, though I am fairly sure this is not the cause of your problem.