Studio 5000 Latch Coil does signal pass thru

[cidchase]

from Loxix Instruction Helpfor OTL:

if Rung-condition-in is false
Set Rung-condition-out to Rung-condition-in.

if Rung-condition-in is true
Set Rung-condition-out to Rung-condition-in.
The data bit is set to true.

So, being a latched coil has no effect on the flow, and it should work as you have stated.

 

[Cheeseface]

It looks like you are using the Process Library PowerFlex add-on instruction.

Process Library AOIs all have the same interface: you latch the command and the AOI clears.

In short, use OTL instead of OTE -- your ladder here is just fighting with the AOI. If you put a CTU on that PCmd_Stop bit you'll see it going nuts.

Another option would be to move your XIO(xxx.Sts_Stopped) next to the OTL(xxx.PCmd_Stop)

 

[JTCat]

Rule out the OTL and see if it still works.
You aren't using any AFI in this program are you?

 

[Operaghost]

How does that rightmost AND work?? Wouldn't that not turn on the coil?

This is referencing the graphic originally included on post #11 and included again here. Starting on the left with the top of the branch. Let's sound out how this would be scanned.

IF Wrk_PermRunOK = OFF/OPEN AND IF Cfg_VFD.Sts_Stopped = OFF/OPEN THEN Cfg_VFD.PCmd_Stop = ON

OR (Now we move to the lower level of the branch)

IF Cfg_HasDownstream = ON/CLOSED AND IF Inp_DownstreamConvRunning = OFF/OPEN AND IF InpConvPE.Sts_Blocked = ON/CLOSED THEN Wrk_RunupStop = ON AND [/COLOR][B]Cfg_VFD.PCmd_Stop[/B] = ON

So, if the top portion of the rung is true, the OTE energizes and the OTL takes no action. It doesn't turn on or off. It is left in its current state. If the bottom portion of the branch is true, then the OTL will energize and then the OTE will also energize.

Now, a bit off the topic, but we know people refer to these posts years down the track, I would disagree ever so slightly with the comment I_Automation made that Logix 5000 scans all instructions. That is a little misleading. Let me explain....

Let's assume that the top rung is true. The bottom portion does not get scanned. Not in a 5, not the 500, nor in a 5000. I taught all of these controllers for Rockwell for 20+ years. If I am mistaken, please show me where this is documented. Wouldn't be the first time I was wrong.

Now, let's assume that the first instruction on the top branch is false. We then stop scanning that branch. BUT, and this is a BIG BUT, only because there is no output to the right within the left and right legs of the branch. There is one further to the right, but it is outside the branch legs.

Now, let's just say that there WAS an output inside the branch, just like on the bottom branch level. If that was the case, when the scan determines that the left most instruction is false, that sets the rung state to false, and we continue to the right to the next instruction. When it reaches that second instruction it will not take the time to evaluate whether the instruction is true. Instead it executes it as false and continues to the right where our new output would be. It would then set that output to a false state. It must continue scanning through that false logic in order to set the output to false.

Next lets go back to assuming the logic is as written and that top level is false. But let's assume that the first instruction in the bottom branch is false while the other inputs are true. As the scan moves from left to right, here is how I describe it. "False, don't care, don't care, set the OTL to false". Even though the first instruction was false, it must continue scanning the instructions so it can set the OTL to false and then exit the branch and also set the OTE to false.

All of this true for the 5, 500, and the 5000. The difference of course being that the 5/500 models don't support series outputs.

OG

 

[I_Automation]

Let's assume that the top rung is true. The bottom portion does not get scanned. Not in a 5, not the 500, nor in a 5000. I taught all of these controllers for Rockwell for 20+ years. If I am mistaken, please show me where this is documented. Wouldn't be the first time I was wrong.

OG

So on the OP example, if all 5 checks are true you are saying the OTL will NOT be processed?


The processing of SLC's vs CLX came up before and I ran some test programs in a SLC5/05 (to get the instant time read) and a -L73 using ver 32.



If the top branch was true in the SLC the scan time of 500 identical rungs was significantly reduced as the second branch was not scanned.


However in the -L73 the scan time was not effected at all indicating all instructions were being processed. The same was true for a string of 10 XIC's - if the first XIC was false the SLC jumped right to the output with a significant reduction in scan time vs only the last XIC being false, where the CLX still checked and had the same scan time. If the CLX didn't process the lower branch the scan time would have dropped noticeably.

 

[drbitboy]

Let's assume that the top rung is true. The bottom portion does not get scanned. Not in a 5, not the 500, nor in a 5000. I taught all of these controllers for Rockwell for 20+ years. If I am mistaken, please show me where this is documented. Wouldn't be the first time I was wrong.

From here:

​

That does not address the branch issue directly; I will keep reading ...

 

[drbitboy]

Let's assume that the top rung is true. The bottom portion does not get scanned. Not in a 5, not the 500,

P.S. I think OG already stated or implied this, but just to be clear, the statement above is not relevant to a 500 program, because in 500 there cannot be an output before the end of a branch (before a BND or NXB) if there is an output after that BND or NXB on the rung. So if the top branch evaluates to TRUE then the state of the bottom branch is irrelevant to the state of the combined branches.

 

[Ken Moore]

It looks like you are using the Process Library PowerFlex add-on instruction.

Process Library AOIs all have the same interface: you latch the command and the AOI clears.

In short, use OTL instead of OTE -- your ladder here is just fighting with the AOI. If you put a CTU on that PCmd_Stop bit you'll see it going nuts.

Another option would be to move your XIO(xxx.Sts_Stopped) next to the OTL(xxx.PCmd_Stop)

Ding, ding, ding. We have a winner. He is correct. Once the stop cmd is processed, the AOI clears it every scan until it is started again.

 

[I_Automation]

Ding, ding, ding. We have a winner. He is correct. Once the stop cmd is processed, the AOI clears it every scan until it is started again.

So, change the OTL to OTE Set_Latch_BOOL

Then add a rung XIC Set_Latch_BOOL OTL Wrk_RunupStop


Just make sure the OTL is the last command in the AOI

 

[Operaghost]

So on the OP example, if all 5 checks are true you are saying the OTL will NOT be processed?

No. Because the lower branch has an output, that logic must be processed.

The processing of SLC's vs CLX came up before and I ran some test programs in a SLC5/05 (to get the instant time read) and a -L73 using ver 32.

If the top branch was true in the SLC the scan time of 500 identical rungs was significantly reduced as the second branch was not scanned.

However in the -L73 the scan time was not effected at all indicating all instructions were being processed. The same was true for a string of 10 XIC's - if the first XIC was false the SLC jumped right to the output with a significant reduction in scan time vs only the last XIC being false, where the CLX still checked and had the same scan time. If the CLX didn't process the lower branch the scan time would have dropped noticeably.

Can't say that I have ever seen this, but I did see a Tech Note stating that the L6x and L7x controllers were always evaluating certain instruction as if they were true. Normally, there is a true execution time and a false execution time. I referred to this in a previous post as "Don't care", meaning the controller doesn't waste time evaluating instructions when the logic ahead of them is false. This was true for the 5x series and the original CompactLogix. But apparently somewhere along the way, the 6x/7x series stopped operating this way. The 8x series is doing it correctly again. Not sure if this was a specific firmware in the 6x/7x or if it was the whole series. So yes, what you described does make sense for those two series of controllers.

OG

 

[Operaghost]

No. Because the lower branch has an output, that logic must be processed.

So I have a bit of a correction to my own comment after I_Automation's comment/question. In retrospect, in my graphic, the first branch should have been labeled as an AND instead of an OR. Since that OTL is on the bottom part of the branch, that means the scan must process the bottom level of the branch. That changes the branch logic from an OR to an AND.

I apologize for going a bit off topic. This could have been a separate thread.


OG

 

[cidchase]

Was there ever a resolution to this question?

 

[I_Automation]

Was there ever a resolution to this question?

It seems that upon executing a OTL a Process Library AOI terminates immediately with a stop command without processing any additional instructions.


The answer from Cheeseface:

Process Library AOIs all have the same interface: you latch the command and the AOI clears.