Tasks Do Not Terminate Properly

[RBPLC]

See attached file for reference:
Tasks do not appear to terminate properly unless they are single shot, once on leading edge. In the attached, when ENTASK is ran single shot, Y1 turns on for one scan and is turned off correctly per DMD0233 and DMD0192 concerning termination logic for outs. In the attached, when testbit3 is on Y1 is on. When testbit3 is turned off Y1 stays on and does not terminate as per the help files. It does not terminate with or without the HALT. If I have missed the explanation for termination of continuous on power flow ENTASK commands please point me to that reference but I can't seem to find it. To me this appears to be a bug. If this is functioning properly, it seems as though better explanation needs to be given to differentiate the two modes of operation for the ENTASK command. 

[franji1]

"Run Continuously" ENTASK implies that it is running like normal ladder logic, so it does not "terminate" like an edge-triggered ENTASK.

For example, $t1Second runs continuously every 1 second.  You can have ladder logic in there with an OUT coil that will NOT turn off, it's just that it only gets evaluated once every 1000ms.  Continuous ENTASK can be leveraged for "normal" ladder execution, but you can tweak how frequently it runs.

So, a user task that is enabled w/ENTASK that runs continuously with 0 interval (i.e. run every PLC scan), is like a PROGRAM, so you can also have legitimate TMRs and other timing instructions.  TMR would not time properly if put in $t1Second task, since its interval to run is every 1000ms, not 0ms (i.e. every scan).

[RBPLC]

What about the HALT not terminating the Out?

[BobO]

What about the HALT not terminating the Out?

ENTASK seems to be working as intended.

HALT is an exception termination, designed to kill a hung program. It isn't really intended to be the primary method for terminating either tasks or programs. I guess a case could be made for doing termination, but for exceptions I generally feel the best plan is to stop doing anything.

[RBPLC]

A few things:

1) Franji's explanation of "Run Continuously" provides more clarification concerning how this affects Tasks. I feel more details and/or clarification needs to be added to the documentation as this is not clear (at least not to me).

2) Additional documentation providing examples of setting a task to Never Yield and setting Run Continuously to 0 ms would be beneficial as this allows for additional actions that I have not really been taking advantage of because here the details of Task settings and the ENTASK command matter and they are not really clear (again, at least not to me).

3) From DMD0148: "The HALT Program or Task (HALT) instruction is used to programmatically stop running the specified Program or Task. When the Program or Task is halted its structure will be initialized (this includes resetting the Stages, clearing internal flags, counters, etc.) in preparation for the next time it is executed. This instruction is typically used by a supervisory code-block to abnormally terminate the execution of another Program or Task. "

There are two things about this statement, the use of abnormally (as you're suggesting BoBO) and the use of supervisory. As in one of my other posts, I think there is a case to use the HALT in a supervisory sense but not necessarily just to terminate a hung program (abnormally terminate). When used in the supervisory sense for non-hung programs/tasks, the HALT can allow/disallow sections of code (and turn off all outputs) that are dependent on the supervisor code but where the sections (Programs/Tasks) are not necessarily linked to one another. This allows for one section of supervisory code that is the same for multiple Programs but also allows a Program1 to be independently disabled from Program2 without affecting the operation of Program2.

4) I contend that the HALT does not terminate a continuously enabled Task the way one would expect by reading the documentation. At a minimum I think the documentation needs to to be updated to discussion this exception.   

[BobO]

We can tweak the help.

Running HALT and ENTASK simultaneously is never right. Regardless of what the help says, my intention for HALT was to kill hung tasks or programs. The only time HALT would ever make sense with a task is if you have a loop that isn?t ending, preventing the current execution from completing, and never when ENTASK is actively enabling it. Primarily HALT was intended for programs.

[franji1]

The term "supervisory" implies that one code block (say $Main) knows more about an abnormal shut down than the 2nd code block.

EXIT is used WITHIN a codeblock for when IT knows when to terminate (e.g. a server protocol driver that processes an incoming packet, and once it's done, it can EXIT).

HALT is used OUTSIDE a codeblock to tell ANOTHER codeblock that OTHER code block needs to HALT.

Realize that EXIT is immediate, since the EXIT instruction exists INSIDE the code bock that is actually EXECUTING.  It jumps to the END of the code block IMMEDIATELY and continues with the next codeblock.

HALT is in a SEPARATE code block, e.g. $Main telling MyTask to HALT, so MyTask is currently not executing instructions (since $Main is executing instructions).  This behavior all has to do with how ladder logic is actually executed - it's still single instructions, executed one at a time, with "parallel" execution being simulated since actual I/O is only updated at the BOTTOM of the LOGIC SCAN.  So, HALT in $Main sets a flag in MyTask to quit execution, whether that's on this PLC scan (if MyTask is PASSED $Main in ladder memory) or on the NEXT PLC scan (if MyTask is BEFORE $Main in Ladder memory).

[RBPLC]

We can tweak the help.

Running HALT and ENTASK simultaneously is never right. Regardless of what the help says, my intention for HALT was to kill hung tasks or programs. The only time HALT would ever make sense with a task is if you have a loop that isn?t ending, preventing the current execution from completing, and never when ENTASK is actively enabling it. Primarily HALT was intended for programs.

In the example I provided when testbit3 is on, ENTASK should be on and HALT should be off due to the invert power flow. When testbit3 is turned off, ENTASK should be turned off and HALT should be on due to the invert power flow. I don't see how these are running at the same time.

[BobO]

We can tweak the help.

Running HALT and ENTASK simultaneously is never right. Regardless of what the help says, my intention for HALT was to kill hung tasks or programs. The only time HALT would ever make sense with a task is if you have a loop that isn?t ending, preventing the current execution from completing, and never when ENTASK is actively enabling it. Primarily HALT was intended for programs.

In the example I provided when testbit3 is on, ENTASK should be on and HALT should be off due to the invert power flow. When testbit3 is turned off, ENTASK should be turned off and HALT should be on due to the invert power flow. I don't see how these are running at the same time.

Because there is a one scan delay on termination execution. HALT is interrupting termination.

[RBPLC]

Still does not work if HALT is moved to another rung, ENTASK is turned off and then another contact is used to execute HALT. The invert power flow configuration works on the outputs in a Program using one contact. As far as I can tell, the run continuous ENTASK doesn't terminate. 

[BobO]

Still does not work if HALT is moved to another rung, ENTASK is turned off and then another contact is used to execute HALT. The invert power flow configuration works on the outputs in a Program using one contact. As far as I can tell, the run continuous ENTASK doesn't terminate.

It worked fine for me.

Remove the HALT. You don?t need it. Ever.

[RBPLC]

In the attached (running in Simulator), if C1 is turned on, Y1 comes on. If C1 is turned off, Y1 remains on. If you're seeing Y1 turn off, then this is a different issue.

[BobO]

I'm not at the office, but will try later. I see in the export that your time interval is non-zero, so that may be the difference. I'm pretty sure I took the default of zero when I tried it. From a termination standpoint it shouldn't matter if it's run recently, but that doesn't mean it's true.

[RBPLC]

Now we're getting somewhere. Only when the Interval is set at 0ms does it terminate correctly (it does terminate for me at 0ms). Anything >0ms does not terminate correctly.

[BobO]

Now we're getting somewhere. Only when the Interval is set at 0ms does it terminate correctly (it does terminate for me at 0ms). Anything >0ms does not terminate correctly.

If so, then yes, it's broken.