IGonza

Yes, this is exactly what I did. As addition, I added the code that makes sure the command will be reset after full scan. I need this in case HMI sends command to PLC. but PLC is not ready to accept it (logically). Thanks.

Yes, and he assigns it to 0 at the end. So the command will be just ignored/skipped/lost. This is the problem i'm trying to solve.

Thanks for your answer, Ken.   How old AB processors are you referencing to? 5 years ago? 10 or 15? Also, I'm not sure that understand your logic. You have CMD := 0 and HMI_CMD := CMD; that will clean HMI_CMD on every scan and it can face the same problem.   What I did for now is : // CMD - tag that is used in logic if (CMD == 1) then DO_SOME_LOGIC1; CMD := 0; ..... .... if (CMD == 2) then DO_SOME_LOGIC2; CMD := 0; ...... ...... ..... if (CMD > 0 and FULL_SCAN_COMPLETE) then CMD := 0; FULL_SCAN_COMPLETE := 0; if (CMD > 0 and not FULL_SCAN_COMPLETE) then FULL_SCAN_COMPLETE := 1;        

Hello, I'm new to AB+RSLinx configuration and we use GE rx3i + OPC Driver + Cimplicity. I'm trying to port GE program to AB PLC and got some problems. GE does synchronization with OPC server (Proficy Driver Server) between the scans. So it runs the code from the start to the end and then update the points - send/receive to/from OPC/HMI. Looks like for AB it works in different way. Here is and example of pseudo code that works in GE fine  and not well in AB: // CMD - point that is set in HMI if (CMD == 1) then DO_SOME_LOGIC1 ..... .... if (CMD == 2) then DO_SOME_LOGIC2 ...... ...... ..... CMD = 0 In AB sometime CMD is set to 0 without checking on previous lines. So it means it comes to PLC in the middle of the program execution. (I know how to fix this issue by changing the code)   My question is : Is this configurable? Can the communication run in the same way as GE controllers do?