Event Driven Periodic Task

Have you ever implemented an event driven periodic task in CLX? How'd you go about it? I have a task that needs to be executed at least every 20mS, but it only needs to be executed for 2 to 10 seconds approximately every 10 minutes (but variable based on the event). I currently have it running periodically at the 20mS rate, but it is an unnecessary burden on the processor. I also need it to accurately run every 20mS, so a conditional timed JSR wouldn't seem the correct route.

I would set it up as an ordinary Periodic Task, but Inhibit the task so it doesn't normally run and take up bandwidth from the controller OS.

You can programmatically inhibit and un-inhibit Tasks using an SSV instruction.

Ken Roach said:

I would set it up as an ordinary Periodic Task, but Inhibit the task so it doesn't normally run and take up bandwidth from the controller OS.

You can programmatically inhibit and un-inhibit Tasks using an SSV instruction.

Click to expand...

I believe that will work just fine, Thanks Ken!

One question I do have, when I inhibit the task, will the outputs remain in their last state?

Yes, outputs will remain in their last commanded state if the only thing driving them was routines in that Task.

I haven't had to deal with this exactly, but I would recommend taking the approach that your Task-Inhibiting logic also GSV's the Task Object to confirm it's been Inhibited, then writes the Outputs to their desired state.

An alternative to programmatically inhibiting the periodic task is to just code it so the first thing it does is decide if it needs to run or not. If not, JMP to the end of the routine. This should take the load off unless it's really doing something. The simpler you make the test, the less idle load you will have.

I don't mind having extra code in the continuous task, but there are other periodic task that I don't want to put a damper on by calling this one unnecessarily.

I am needing an output turned on and off during a very specific and (usually) fast amount of time, but the amount of time needs to be calculated using time, hence the need for the periodic task. Fortunately, the exact beginning of this period is not as critical as the duration of it. My current code allows for easy testing to MOV a 0 or 1 into the SSV tag. I suspect the initial turning on of the output will have a small delay compared to before, but that is okay.

I am sure I made this much more difficult than it needs to be. I am simply modifying an existing system to accommodate a new process being added to it.

Ken Roach said:

Yes, outputs will remain in their last commanded state if the only thing driving them was routines in that Task.

I haven't had to deal with this exactly, but I would recommend taking the approach that your Task-Inhibiting logic also GSV's the Task Object to confirm it's been Inhibited, then writes the Outputs to their desired state.

Click to expand...

This is pretty simple, but logic wise it doesn't work well to me. So, I have it setup to unconditionally SSV the InhibitTask. Then, I simply move a 1 or 0 into the Source tag to inhibit the task. Could probably use an OTE and a bit instead of a MOV, but either way you could set the output(s) at the instance of moving a non-zero value into the Source tag.

I have the logic set where the output will be in the desired state whenever the task is inhibited either way, but I am all for preventing unforeseen errors.

I have another instance where this output appears in the continuous task. Will it simply appearing on a conditional rung turn the output off, if it was on when the task was inhibited? Seems like a silly question, but I am not yet a guru

As I was typing that, I realized I messed up by putting multiple OTEs for the output. Correcting logic now..

RatherBeFishing said:

As I was typing that, I realized I messed up by putting multiple OTEs for the output. Correcting logic now..

Click to expand...

This brings to question, the duplicate destructive bit. I think I'm getting DCS just thinking about it.

If I put an unlatch in the rung that writes a 1 to the source tag for the Inhibit Task, will I be okay as to avoiding "who was scanned last" scenario? That way it only writes a "0" to the output, whenever the OTE rung for the tag is not currently being scanned?