CJ1 CPU12 ?

[aboon78 0]

Hi All, Hav anyone experienced with Omron CJ1 CPU12 that giving strange result as screen captured in the above? Instruction move #95 from lower byte of D5006 to upper byte of D121, but it becomes #96. This is my second strange incident with CJ1 CPU12, as previous I saw one of the timer didn't stop increment though it's supposed to elasped. It's back to normal after cyclepower. Is this Omron CJ1 bug? Never hav this experience with NAiS, ControlLogix, Mitsubishi, Siemens, GeFanuc... I might change my mind in next project of PLC selection.

[beegee 7]

I have never had such basic errors in Omron, are you sure you dont use D121 anywhere else, or that D5006 was not 96 when the function was executed(since it is only rising edge)? try omitting the @, then you can see it real time, and not the result of the one shot. Beegee Edited 18 Apr 2008 by beegee

[aboon78 0]

No elsewhere. I wrote the program in a state sequence way and it works for last few months. And 96 is not within the range data of D5006 that it's defiened.

[Andy_P 7]

I cannot reproduce this error, it works as expected for me. I would have to agree with beegee that the most likely explanation is that D121 is being referenced elsewhere and changing the value. Is it possible that D121 is being indirectly referenced? One test I can think of trying is to @MOV the value of D121 to a definitely unused address immediately after the @MOVD instruction. That way you can see exactly what MOVD is producing with the knowledge that nothing else can alter it. If this new address contains #9550, then there is no bug and something else is altering the value of D121. If it contains #9650 then there is indeed a bug. Hope that helps. Andy.

[scottmurphy 1]

I also could not replicate this error, perhaps if you post your complete code, then we all could see if we can replicate it. One thing I did notice, and may be worth looking into, is the value of the MOVD result empty before you perform the MOVD command? It looks like something else may be writing to the same address though.

[beegee 7]

One thing I can still think of, since it is a one shot execution, is that if there is an HMI connected, the HMI changes it afterwards... Have you tried it without the @ to see whether it works the way it should? Beegee

[aboon78 0]

Hi All, Thanks for you guys' input. Actually this data comes from the V600 RFID data carrier. It's programmed to store 95, 65, 54 in a specific address. In the above case, the data carrier of the pallet should be 95. I checked the data carrier of the pallet when this happened, it's confirmed 95. So, possibility 96 come from data source is eliminated. Next possibility is D121 is overwritten somewhere else, but I couldn't find out D121 is used in other area within the program. That's why I called it strange. May be I am wrong, may look into the code again when free.