G_DeMark

Interlaced MOV Instruction

7 posts in this topic

How can I ensure that the MOV instructions are complete before taking a follow up action.  Initially I was guessing that if I simply put an output energize (OTE) instruction after the MOV instructions I could just wait for the OTE to go high.  However, I do not believe that instruction is correct.  Could anyone comment on this assumption as well as offer a recommendation to achieve my objective.  Thanks

 

Share this post


Link to post
Share on other sites

Do a compare in the next rung.

Some might say to use a CPS.  The CPS must complete before advancing.

Edited by pcmccartney1

Share this post


Link to post
Share on other sites

I would prefer not to use a compare instruction because in my real application I am using a great many MOV and COP instructions and I would hate to couple a compare instruction with each of them.  That seems very inefficient if you are working in bulk.  However, I am interested to learn more about the CPS.  I will need to do some research as I am not clear on how that one works.  Thanks very much

Share this post


Link to post
Share on other sites

If this is RS500, the OTE does not energize the actual output until the end of the scan.  RS5000 can be any time.

Share this post


Link to post
Share on other sites

Execution of a "MOV" instruction occurs immediately the rung is scanned (the rung must be true of course).

You can take action on the very next rung or a branch below the "MOV" instruction.

Share this post


Link to post
Share on other sites

By the way guys, I am talking about Logix 5000, not 500.  Thanks

Share this post


Link to post
Share on other sites

MOV, COP, and CPS are all completed before the ladder routine (or structured text routine) moves on to the next branch or next rung.

The issue that I suspect you're working on is that COP is an array instruction, and the operating system moves data in 32-bit chunks from the source to the destination.    While the RLL or ST routine execution does not move on to the next instruction, rung, branch, or line until the COP is complete, the OS can interrupt the copying of data to service another higher-priority feature.

Usually the problem appears when that interrupt is an I/O update.    The Input data might be written over in the middle of the COP, or the Output data might be grabbed and sent out to the network subsystem before all the data was copied into it.

That's why the Copy Synchronous (CPS) instruction was created (it wasn't part of the original ControlLogix OS).   It locks the source and destination from being affected by interrupts until all the data gets copied.    Doing that lock and unlock process in memory takes a few microseconds, so I only use CPS when I'm handling I/O data.

Because MOV doesn't operate on arrays or on data types that are bigger than 32 bits, it doesn't have the same vulnerability to interrupts as COP does.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now