what happens to the state of bits outside of a JSR

[TheWaterboy]

Is there a difference of behavior between the PLC5 and the Logix series when it comes to JSR behavior?

Assuming I do nothing to this bit elsewhere, If I set a bit in a rung that is called by a JSR and then I stop calling the JSR.. what happens to the state of that bit?

I saw this recently in a Logix program and the bit cleared when I stopped calling the JSR. In a PLC5 the bit remains set when I stop calling the JSR.

I would expect the PLC-5 like behavior so the Logix behavior surprised me.

Can anyone confirm this behavior change between platforms or do I need to look harder for some other reason?

 

[OkiePC]

If the JSR is not called, then it stops affecting the bit. If the bit still changes then something else is affecting it whether it is other logic or a remote device. This is true for any PLC that I am aware of.

 

[TheWaterboy]

OK good, that's what I thought as well. I'll start hunting tomorrow.

 

[plvlce]

Is there a difference of behavior between the PLC5 and the Logix series when it comes to JSR behavior?

Assuming I do nothing to this bit elsewhere, If I set a bit in a rung that is called by a JSR and then I stop calling the JSR.. what happens to the state of that bit?

Per this post by Ron Beaufort, if you completely delete all JSR for a routine in Control/CompactLogix (as opposed to simply rendering the rung false) then the prescan will *not* run through the routine in question setting OTE bits to 0.

I saw this recently in a Logix program and the bit cleared when I stopped calling the JSR. In a PLC5 the bit remains set when I stop calling the JSR.

I would expect the PLC-5 like behavior so the Logix behavior surprised me.

Can anyone confirm this behavior change between platforms or do I need to look harder for some other reason?

What Ron describes could not cause this, only the opposite (Logix stays set through prescan, PLC5 would not), so while it answers your question of 'is there a difference' it does not explain the specific behaviour you are seeing.

Additionally it would only affect systems when they leave and re-enter run mode.

 

[drbitboy]

If the JSR is not called, then it stops affecting the bit.

I'll go even further: if the JSR does execute, but the JSR-called routine ("Program File") executes a RETurn* instruction before executing the rung that affects the bit, then neither that rung, nor the routine it is in**, should affect that bit.

* to return to the routine that called it with the JSR
** Possible caveat: I wonder if one exception could be on First Pass i.e. pre-scan?

 

[TheWaterboy]

that makes sense but not the case here. There are 3 simple JSRs that are used to change the sequencing for 3 pumps so that first pump that is called to run alternates.

i.e.
JSR 1
XIC 1stPumpCall OTE P1Run
XIC 2ndPumpCall OTE P2Run
XIC 3rdPumpCall OTE P3Run

JSR 2
XIC 1stPumpCall OTE P2Run
XIC 2ndPumpCall OTE P3Run
XIC 3rdPumpCall OTE P1Run

JSR 3
XIC 1stPumpCall OTE P3Run
XIC 2ndPumpCall OTE P1Run
XIC 3rdPumpCall OTE P2Run


The Runs go to IO and the Calls are from pressure levels

The sequencer logic determine which JSR is called and which pump is driven. Oddly this works, no pumps remain running when no JRS are being called. and there is nothing that resets them... that I have found yet.

 

[alan_505]

If you have OTE P1Run in each Sub Routine it will evaluate true in the routine that calls for it to be on but will be turned off when the other routines are called.

 

[plvlce]

First Pass i.e. pre-scan?

First Pass and pre-scan are separate and mostly unrelated.

First Pass is the initial scan of the program during which logic is executed; pre-scan happens before that and program logic is not executed.

 

[drbitboy]

First Pass and pre-scan are separate and mostly unrelated.

First Pass is the initial scan of the program during which logic is executed; pre-scan happens before that and program logic is not executed.

Whoops, yup, I got careless there. I meant pre-scan.

 

[TheWaterboy]

Alan_505
I agree but once pressure is satisfied none of the routines are called any longer yet the bit still clears.

Perhaps it's just good timing - perhaps the call bit clears one scan before the routine stops being called. That would certainly work.... Thats gotta be it.

 

[drbitboy]

Alan_505
I agree but once pressure is satisfied none of the routines are called any longer yet the bit still clears.

Perhaps it's just good timing - perhaps the call bit clears one scan before the routine stops being called. That would certainly work.... Thats gotta be it.

Sounds possible.


But if the *Call bits are cleared, and the JSRs no longer executed, from the logic detecting that the pressure is satisfied, then how can the former affect the latter if the latter are no longer called after the last *Call bits are cleared?



Can you post the code?

Could this be an effect of asynchronous vs. synchronous IO wrt the scan cycle? I am pretty sure one or both of CompactLogix and ControlLogix are asynchronous; how do PLC5s run their IO scans?

 

[TheWaterboy]

Hence my confusion.
I wont be looking at it again till tomorrow but the Call bits clearing a scan ahead of the JSR call makes the most sense. And sounds a little bit to fragile to depend on.

I believe the IO is async in all these. But none of these bits are touching IO, that is a separate ladder.

 

[I_Automation]

I do something that might be what's happening here - but for Christmas lights on my home automation.


When I no longer call a JSR (usually for a mode segment change or the running time ends of the light show) I run through the subroutine one last scan turning off all the outputs then set a Skip_Bit on the last rung if the routine isn't enabled.


EDIT: Change Rung 4 to XIO the enable bit

 

[drbitboy]

According to this the I/O image table updates are synchronous with the program scan in PLC-5, even though any remote I/O scanning is asynchronous.

the Call bits clearing a scan ahead of the JSR call makes the most sense

So the pressure logic would need to

1. clear the last of the *Call bit(s),
2. then execute one of the JSRs, which is where the P*Run bits are all turned off,
3. then finally set some state the prevents the JSRs from executing as long as the pressure is satisfied.

and in that specific order.

 

[OkiePC]

This is an example of why it is unwise to use conditional routines for controlling real I/O. Scan the logic all the time and add a few more instructions and branches to the call bits for the three pumps. An ugly rung is not as bad as an unreliable rung.