Studio 5000 Order of Execution Question

So I am trying to clean up some code from my predecessor. He had a habit of chaining instructions together in series. Which I find takes longer to read when looking though code rather than just creating a list of branches.


I am wondering if these two rungs execute in he same order? I think no, but I think they execute in the same scan so it doesn't matter. In the second screen shot with the branches I assume the rest of the top row would execute then it would go to the next row? Thoughts?

See screen shots.

From what I have read outputs in series are handled by a separate system from the main scanning CPU chip.

With 2 outputs in series it is not guaranteed the first on the rung will be processed first. Say MOV Log_Count HMI_Read_Tag followed by MOV 0 Log_Count could zero the Log_Count before the value is moved to the HMI tag.

For your first example the FLL could happen before the COP, the MOV's could happen first, etc. If I want to make certain things happen in a specific order I follow your second example and do branches in order.

I don't mind a couple instructions in series, but that many makes my teeth itch.

If I'm going to parallel instructions I've always done so at the end of the rung, so the possibility of a different operation order hasn't come up. I agree that under most circumstances it shouldn't matter. Maybe it might matter in the event a higher priority task interrupted the scan?

I_Automation said:

From what I have read outputs in series are handled by a separate system from the main scanning CPU chip.

With 2 outputs in series it is not guaranteed the first on the rung will be processed first. Say MOV Log_Count HMI_Read_Tag followed by MOV 0 Log_Count could zero the Log_Count before the value is moved to the HMI tag.

Click to expand...

I had not heard this. If true it is good to know.

I_Automation said:

From what I have read outputs in series are handled by a separate system from the main scanning CPU chip.

With 2 outputs in series it is not guaranteed the first on the rung will be processed first. Say MOV Log_Count HMI_Read_Tag followed by MOV 0 Log_Count could zero the Log_Count before the value is moved to the HMI tag.

For your first example the FLL could happen before the COP, the MOV's could happen first, etc. If I want to make certain things happen in a specific order I follow your second example and do branches in order.

Click to expand...

Wow, another violation of "left-to-right, top-to-bottom?"


I suspect the motivation to doing things in series, for the Col's predecessor, is that vertical real estate is a valuable resource, although in this case I think that the loss in readability make the in-series approach not worth the savings.

I_Automation said:

From what I have read outputs in series are handled by a separate system from the main scanning CPU chip.

With 2 outputs in series it is not guaranteed the first on the rung will be processed first. ....

Click to expand...

Please cite an authoritative reference for the statement beginning "With 2 outputs" as it pertains to programs developed in Logix/Studio 5000.

I_Automation said:

From what I have read outputs in series are handled by a separate system from the main scanning CPU chip.

With 2 outputs in series it is not guaranteed the first on the rung will be processed first. Say MOV Log_Count HMI_Read_Tag followed by MOV 0 Log_Count could zero the Log_Count before the value is moved to the HMI tag.

For your first example the FLL could happen before the COP, the MOV's could happen first, etc. If I want to make certain things happen in a specific order I follow your second example and do branches in order.

Click to expand...

I have often did things in series in the same rung, such as moving a total, then zeroing. (both output instructions) and never have I seen them not execute in order.

theColonel26 said:

So I am trying to clean up some code from my predecessor. He had a habit of chaining instructions together in series. Which I find takes longer to read when looking though code rather than just creating a list of branches.


I am wondering if these two rungs execute in he same order? I think no, but I think they execute in the same scan so it doesn't matter. In the second screen shot with the branches I assume the rest of the top row would execute then it would go to the next row? Thoughts?

See screen shots.

Click to expand...

I prefer them in series. Ensures proper order of operations.

Ken Moore said:

I have often did things in series in the same rung, such as moving a total, then zeroing. (both output instructions) and never have I seen them not execute in order.

Click to expand...

Can't agree more.

One of the considerations is that branches take memory. Not much, but they do take some memory. Each branch, and each branch levels consumes memory. Putting two instructions in series uses less memory than two instructions in parallel. A branch is made up of three instructions. Start Branch, Next Branch Level, and End of Branch. Two instructions in parallel is actually five instructions. Two instructions in series is just two instructions.

As for scan time, I don't know for certain, but I would guess that those branch instructions each requires a (very) small amount of scan time. Which would make the series logic more memory AND scan time efficient.

That said, I want the logic to be clear and easy to read. I'll take that any day over more efficient. If that means branches, so be it.

OG

scan time isn't an issue currently. My max scan time is 0.76mS and I am running at a 100mS interval..... so yeah....

Interesting... Here are some snapshots of the same logic in 3 different ladders and the compiled code for each. According to convention of left to right top to bottom this seems to bear out. I'm not sure about the statement of outputs being processed, I think that statement may be interpreted, By outputs does this mean physical or mapped, in original concept of PLC's the inputs were mapped to internal image at a point in the scan (usually deemed before the processing of the logic) and the outputs updated from the output image after the program scan, there were exceptions these being interrupt or immediate update of process image, it is possible in modern systems that the I/O may be updated at different times i.e. either synchronous or asynchronous.
With the advent of IEC blocks, many will have EN & ENO pins this gives the ability to link blocks together, the compiled code will depend on if the ENO is connected or not. see pics. Notice there is little difference in processing order of the move instructions with the exception of the output instruction in rungs 1 & 2, also notice that depending on the ENO being connected, will introduce different code i.e. temporary bits to give the functions an output enable if connected.
Not saying all types of PLC use this and there will be differences, however, I can say in this instance you can see the compiled code as this system allows you to display it.

I have been looking for where I read that about the CLX's. If I find it I will post it here. I looked on my laptop when I posted above, but not there.



It had something to do with the main processor and the IO scan processor being separate. As the IO is scanned and the IO map updated mid-cycle (maybe) of the main program scan the input states could change mid-scan. (EG: In the first JSR a float switch could be on, but that same float switch 10 JSR's later could be off and if the program can't handle the change it could be a problem for the programmer)


The same processor took the output instructions and processed them separately, and there was a warning that the execution of outputs in series could not happen in the order of the rung, or they might.


I will run a test online this morning and see if the CLX reacts the same as in Parky's example.


But, I still prefer branches and if I do put outputs in series I put no more than 2 per branch - it looks better.

As I said earlier, Real I/O may be updated but internal bits will update at the time of the process scan, looking at the code those output bits are internal not real I/O.

I got the same result as Parky did online.

As far as real outputs turning on not in order they would turn on within 0.006 seconds of one another and I don't see how that would make a difference and need a warning that they might turn on in the wrong order. Unless a high speed output was triggering a stepper motor or sine wave output the second one coming on first wouldn't matter in a real world application.

Problem I have only found with rung execution where you do inputs statements then outputs statements then inputs statements then outputs statements in same rung. All statements are in series.

In this case if your expecting the rung to execute the whole rung in one scan it probably wont do it. I have tracked this over the years where 95% of the rung will execute but the last(second) set of output statement would sometimes execute in the range of 70 to 95%.

Hi All,
This topic it is really interesting indeed.
Hi have a doubt that is inside this kind of questions:
RsLogix 5k V28, 1756-L73CPU value update.
I came across a ladder program with a line with something that for me is a doubtful functioning.
What do you think about this at below, this works fine?
****
The ladder line have a REAL value that is MOV to an REAL Word1, (with a MOV instruction).
In the same ladder line (so..in series), the same REAL Word1 it is CLR. (with CLR instruction).
In my opinion the value that it is moved first ''REAL value that is MOV to an REAL Word1'' never it is updated and processed in the REAL Word1, because the last instruction (CLR) will clear the content.
I mean, this lines does not nothing and the result will be always ZERO....right?
Of course that during the PLC cycle, I cannot see the value to be updated in the Real Word1.
***
What do you think?
Any tips?
Thank you gents!

3B