Proper Bit Termination In Stages

[RBPLC]

Please confirm the following is the intended behavior of the described instructions:

1) On a Run to Program transition, only Y values are turned off when used in an OUT instruction. At current time, C values used in an OUT instruction do not turn off on a Run to Program transition.

2) Initiating a RESTART only turns off OUT's that are in a currently enabled stage. At current time, if an OUT is on in an inactive stage the OUT's will not be turned off when a RESTART is issued.   

[BobO]

Please confirm the following is the intended behavior of the described instructions:

1) On a Run to Program transition, only Y values are turned off when used in an OUT instruction. At current time, C values used in an OUT instruction do not turn off on a Run to Program transition.

2) Initiating a RESTART only turns off OUT's that are in a currently enabled stage. At current time, if an OUT is on in an inactive stage the OUT's will not be turned off when a RESTART is issued.   

Termination logic is not executed on Run to Program. An argument could be made to do so, but it currently doesn't. I/O memory is cleared, which is what clears the Ys. You also have last the scan logic that you can use to clean anything up that the engine doesn't.

RESTART just clears active stages and resets the program counter to the beginning of the block, so that sounds right.

[RBPLC]

1) Recommend adding this information to the documentation as I didn't see it concerning termination.

2) I think the termination from Run to Program should seriously be considered. What I'm running into is the following:

I'm mapping I/O from UDT's. At current time all elements within the UDT are either retentive or non-retentive. Having to choose one, I've selected to keep the UDT's retentive when actually I need some elements retentive and some non-retentive (more need to be retentive). When these retentive elements are placed in stages, if a Run to Program transition occurs, these bits maintain their current state (assume they're on). I forsee a situation where the Run to Program occurs and during the time that the controller is not running some other discrete/analog input changes value that would prevent the stage from running during transition back to Run. The controller would then be switched to Run which would not let the stage run and would essentially "hang" the mapped outputs. In order to prevent this you would have to make sure that all mapped outputs are re-initialized during the transition back to run (like with the INIT command). Incorporating the termination logic for Run to Program would prevent this.   

[BobO]

It shouldn't be difficult. We need to think about when to run it, but I see the merit in doing it.

[RBPLC]

Also, to add to this, potentially consider adding the option to the RESTART (or change its behavior) or a separate command to terminate all stages, not just those that are active. This would allow a supervisory "clean-up" of all outputs in a staged program if some event occurs. Provides a little more flexibility/control.

[BobO]

Also, to add to this, potentially consider adding the option to the RESTART (or change its behavior) or a separate command to terminate all stages, not just those that are active. This would allow a supervisory "clean-up" of all outputs in a staged program if some event occurs. Provides a little more flexibility/control.

This is more nuanced than it might seem at first, for implementational reasons I won't bore you with, but I will look at having HALT be more thorough. After thinking more about HALT's behavior, I think it is reasonable to do a full termination of all stages. We also have concerns about making too many changes to these behaviors. It may help you, but break a hundred others. We need to be very specific about what changes and why.

[BobO]

I think this is what we're going with:
1. Fixed ENTASK termination bug.
2. Added RESTART termination for tasks. Programs always did, but really tasks should too.
3. Run to Program unconditionally terminates all code.
4. HALT unconditionally terminates all code in halted task or program.
5. EXIT and RESTART terminates as before, active stages and non-stage code only.

I wasn't strongly opposed to having EXIT and RESTART do a full termination, but that could change behavior in normal operation. First, do no harm.

[RBPLC]

3. Run to Program unconditionally terminates all code.

Does unconditionally here mean that all OUTS are disabled (including bit memory locations)?

4. HALT unconditionally terminates all code in halted task or program.

Does unconditionally here mean that all OUTS are disabled (including bit memory locations)? Does "in halted task or program" mean that an additional HALT command has to be issued (program/task is currently halted) to unconditionally terminate or are you saying that upon issuing the halt the program/task is unconditionally terminated?

[BobO]

Does unconditionally here mean that all OUTS are disabled (including bit memory locations)?

Yes.

Does unconditionally here mean that all OUTS are disabled (including bit memory locations)? Does "in halted task or program" mean that an additional HALT command has to be issued (program/task is currently halted) to unconditionally terminate or are you saying that upon issuing the halt the program/task is unconditionally terminated?

I'm saying that I added termination to the normal HALT behavior. 'Unconditional' means that every stage will be terminated, regardless of whether it was previously enabled or not. The EXIT and RESTART behavior is to run termination only on previously enabled stages.

[RBPLC]

Thanks BobO. It sounds like a good compromise to keep stability by not messing with the RESTART. Items 3 and 4 should solve the potential issues I was seeing. Are these easy fixes and will they be incorporated into 2.8.3? 

[BobO]

Thanks BobO. It sounds like a good compromise to keep stability by not messing with the RESTART. Items 3 and 4 should solve the potential issues I was seeing. Are these easy fixes and will they be incorporated into 2.8.3?

They are easy and we do expect them to be in 2.8.3, out shortly. We are currently experiencing some IT issues. I'm not sure if that will slow it down, but if so, it shouldn't be more than another day or two.

[RBPLC]

Was the TIMEPROP termination adjusted in 2.8.3? 

[BobO]

Was the TIMEPROP termination adjusted in 2.8.3?

Yes.

[RBPLC]

Please look at DEBOUNCE termination as well. This appears to have same issue as TIMEPROP?

[BobO]

Please look at DEBOUNCE termination as well. This appears to have same issue as TIMEPROP?

I think the determination was made that because DEBOUNCE is an input function that we shouldn't apply termination logic. There is a note in the source code to explicitly not terminate.