Omron Data corruption

[ngoodman 0]

Hi fairly new to omron We have 9 omron CJ2 's on an ethernet network with 4 scada stations running wonderware, the cpus are fitted with SPU modules to capture data when the network is down. each PLC has a NS10 HMI connected via ethernet. the problem we have is data corruption, it seems restricted to only the D memory area and occurs maybe once a week at random, what happens is a random number will appear normally large > 16000 or a bit that is not referenced by the plc program only addressed by the HMI will be set - this causes a machine malfunction as you can imagine that is sometimes hard to resolve! Omron have drawn a blank, wonderware say its not possible, and the machine makers have backed away from the issue as they cannot see how its happening. trying to think outside of the box could the HMI be doing this ? could it be a network issue? could the SPU devices be to blame? I dont really know enough about omron to know how when a symbol is prefixed D how this can be effected by a remote device? anyone got any ideas?

[Andy_P 7]

Might be way off the mark here, but do you have any indirect addressing operations within any of the PLC programs? If anything is wrong with this, then it can cause all sorts of strange problems by writing data or bits into addresses that were not intended. Couple this with a network, and all sorts of potential weirdness can happen that is "not possible". The value of >16000 seems suspicious too. Maybe it is actually a value of 16384? This equals hex 4000, or bit 14 being set. Perhaps an overflow of your expected data can happen in rare occasions that causes this bit to be set and upsets your indirect addressing scheme. Crucially, this will not show up in cross-reference because it is not hard-wired into the code. Search for any use of the index registers IR0 to IR15, or anywhere in the code that does something like this for example: MOV #0 @D0 or MOV #0 *D0 (Note the @ and *) This notation causes indirect addressing to be performed in either binary or BCD mode. e.g. if D0 contains a value of #0100 hex, then the first instruction will cause a zero to be moved to the address pointed at by D0 in binary mode = address D256. The second instruction would move a zero to the address pointed at by D0 in BCD mode = address D100. Might be nothing to do with it, just a thought. Good luck!

[EasyButton 0]

I would try an alternate connection for the NS screens. The polling rate is very fast with these, I think the slowest is 200ms and I have seen this cause issues with Wonderware DAS.

[lostcontrol 23]

Interesting, what sort of issues have you seen? Perhaps the DAS & NS trying to use the same port?

[EasyButton 0]

Seems to have more to do with the load on the ETN card. With an NS on 9600 and Wonderware on 9601 the update time to Wonderware was greater than 5 seconds with no delay on the NS. Removed the NS and we were back to 1 second. Note the system is fitted with managed switches.

[EasyButton 0]

Wondering how this one turned out?

[KevinDuf 0]

what is the memory that is corrupting ? if it's occur only in D area, don't forget that CPU is using some parts of the memory for Special IO card and Bus Unit D20000 ---> D29599 : Special I/o Unit 100 word / unit D30000 ---> D31599 : CPU Bus Unit 00 word / unit hope this help