Storing data in omron

[Guest Jerry Desaulniers]

I came across a situation in my learning of Omron. It appears that when you download a program from Syswin 3.4 to a processor and tick CLEAR MEMORY all usable data is erased and no data file travels along with the .swp file. This seems odd and means that only a qualified programmer could reload a program in the field, otherwise many maintenance guys would make a big mistake. I say this because when a maintenance mechanic is troubleshooting a machine he has many steps he will follow, one of the last is to reload a known working copy of the the program. This will do no good if one of the data areas has been corrupted. Anyways I've come up with a cumbersome way around this and I hope someone can show me the light. My solution. Have a series of move statements that are activated by first scan. These statements will move a hex number into their proper DM words. I hope your answers are way better than mine! As a matter of fact I hope your laughing right now and saying he didn't know " (fill in the blank) " .                                Thanks                                 Jerry

[JayA 1]

This is a common misunderstanding about which memory gets cleared when you tick Clear Memory during the download program dialog.  The memory to which they refer is the UM(user memory- which is ladder code only.)  All other Data Retentive areas of memory (DM - Data Memory, HR - Holding Relay, and AR - Auxilary Relay) are battery backed and will not be cleared by a program download.   I know that some other manufacturers include, along with a program download, additional files which represent data settings in areas other than program memory.  It is a seperate procedure using Syswin 3.4 and involves invoking the Data Display Editor (Editors|Data Display Editor), loading a .ddm file and downloading the file to the PLC with a separate download dialog. Regarding using move statements actuated by first scan flag:  this is a very appropriate way to hardcode DM's to a preset value.  The rub comes when your ladder code modifies these data locations due to changes in the process or by programmer innovation.  Some programmers have devised unique methods to control this, such as setting an HR after the first scan, so that subsequent restarts do not destroy the data.  Others compare a certain location to zero, and  if a code has been set there, then the move statements are not executed.  Obviously, the onus is on the programmer to make these decisions. :)