Off the Wall Question

Hello fellow members,

Work has sent me to a couple of Rockwell classes and I had a question that didn't get answered, and it is driving me crazy. It isn't nothing real important, but may be useful one day.

Using the UID and UIE command I know you can make a set of rungs not be interupted by a Periodic or an Event task. I also know that if a periodic or an event task is called during the time the PLC is in the UID/UIE set that they will be placed in a que. My question is this: If an event task is called 4 times during the time the PLC is in the UID/UIE set, when the conditions are met to resume regular run conditions, will the Event task run itself 4 times or just once??


Like I said, nothing major, just something I was wondering.

Thanks,

It should cause what is called a "task overlap" This means the task interval has expired twice before it finished once. Overlaps can stack up, and are counted for you in the task properties box. You can see this by monitoring a task by right clicking on it. If you are seeing task overlaps you have a configuration problem. The task interval or the code needs to be changed.

I also think you will get a watchdog fault on that task. Unless you have your watchdog timer set to several times the interval + scantime.

No, it should not execute 4 times in a row. In my opinion it will execute only once. I could not find this documented anywhere though.

I have never used those instructions or seen them used in running code. I can think of several ways to avoid using them too. The instruction reference says you can even lose communications if the interupt is too long.

If you put the code that you need to never be interupted in the task with the highest priority, it will never get interupted. Much easier that way.

Sometimes I think CLX has TOO many options.

I personaly have no intention of ever using those instructions.

Maybe someone that has actually used this before can tell us more?

ControlLogix tasks and priorities and interrupts ...

Greetings just_lionel,



you asked:

If an event task is called 4 times during the time the PLC is in the UID/UIE set, when the conditions are met to resume regular run conditions, will the Event task run itself 4 times or just once??

Click to expand...

RSL was correct with the following answer to your question:

No, it should not execute 4 times in a row. In my opinion it will execute only once. I could not find this documented anywhere though.

Click to expand...

I’ll give you some techniques that will help you prove this for yourself near the end of this epic ... since you seem to already be up to speed on “tasks and priorities” feel free to just skip ahead to that part ... the majority of what I’m about to cover here is intended for our readers who might not be as familiar with these ControlLogix features as they’d like to be ... the methods I’m about to explain have worked extremely well in the “technician-level” classes that I teach ...



first suppose that we set up a simple ControlLogix program like the one shown in the next figure ...








notice that we’ve set up two new tasks ... one is called “BIG_AND_SLOW” ... this one has been given a Period of 1000 ms ... this basically means that the processor will try to execute the code in this section just once each second ... notice that the Priority setting has been left at its default value of 10 ... we’ll look at the actual code in the “DELAY_LOOP” routine in a few minutes ...



the other new task is called “SHORT_AND_FAST” ... this one has been given a Period of 100 ms ... and this basically means that the processor will try to execute the code in this section ten times each second – which is, of course, ten times as often as the execution of “BIG_AND_SLOW” ... notice that once again the Priority setting has been left at its default value of 10 ...



now let’s take a look at the code in the “FLIP_FLOP” routine of the SHORT_AND_FAST task ...








the “COIL” being used here is part of a small contactor that the students have wired up as an output of their ControlLogix system ... of course you can work with just a lamp bulb or even the LED on an output module ... personally I like to use the contactor because it’s easy to hear the “clunk-clunk-clunk” pattern of off and on cycles that make this next experiment so educational ... one thing that you should NOT try to do is to simply watch the on and off patterns on the RSLogix5000 display screen ... the screen will not update rapidly enough for this type of exercise ...



as explained in the rung comment, all that this rung does is alternate the contactor coil between the off and on states ... since the SHORT_AND_FAST task that contains this rung has a Period setting of 100 ms, the contactor should clunk about 10 times every second as it is switched between the on and the off states ... so far so good ...



the program in the “DELAY_LOOP” routine of the BIG_AND_SLOW task is a little bit harder to understand ... first of all, you need to keep in mind that this is NOT (I repeat NOT) the type of programming that you’d use on a piece of machinery in the field ... instead this is something that I use in my classes to demonstrate the answers to questions such as: “what really happens when the program scan time gets too long?” ... or “what is a watchdog fault?” ... etc. ... etc. ... basically this is a simple way to increase the program scan time without adding in a LOT of “busy-work” rungs for the processor to execute ...








the idea is to set up a “recursive loop” which will cause the processor to repeatedly “jump backwards” through the scan to create a “delay or pause” for a certain length of time on each pass through this section of code ... the timer preset of “400” means that we’ve added a 400 ms delay to each execution of this particular routine ... (note that if you increase the timer preset to a value close to 500 ms, then the processor will usually go into a “watchdog fault” condition ...



continued in next post ...

continued from previous post ...



now let’s see what this little experimental program can teach us about “tasks and priorities” and things like that ...








suppose that to begin with we set the LOOP_TIMER’s preset for 0 ... that means that the code in the BIG_AND_SLOW routine will execute almost instantaneously ... with this “just getting started” setup, BIG_AND_SLOW will actually still be pretty “FAST” at this point in our exercise ... each tic mark on Trace A of the figure above indicates a simple painless pass right through the BIG_AND_SLOW routine once each second ...



compare that with Trace B which shows that the task SHORT_AND_FAST executes ten times as often ... it’s important that you realize that the tic marks are NOT showing how long each scan takes to execute ... actually, each scan is almost instantaneous ... instead, the tic marks indicate how OFTEN each scan takes place ... quick analogy: it only takes me one minute to comb my hair – and I comb it ten times a day ... specifically, it does NOT take me one-tenth of a day to comb my hair ... (sorry for the painful detail – but some students have trouble with this type of stuff) ...



Trace C indicates how the contactor coil will respond to our “just getting started” setup ... basically we can hear the coil going “clunk-clunk-clunk-clunk-clunk-clunk” off-and-on-and-off-and-on with ten “clunks” per second in a very smooth and rhythmic pattern ...



now let’s go back to the DELAY_LOOP routine and change the preset value of our LOOP_TIMER to 400 ms ... the effect on the execution of the BIG_AND_SLOW task is shown by Trace D ... specifically, the routine still BEGINS executing once each second ... BUT ... now it takes 400 ms to run through its execution ... that’s because of that “recursive loop delay” that we programmed in for testing purposes ...



now a quick (but very important) question: what effect will this “scan delay” have on the action of our contactor coil? ... specifically, now that the BIG_AND_SLOW code is taking almost one-half second to complete, what will happen to the SHORT_AND_FAST code which is supposed to be executed FIVE TIMES within that same one-half second time slot? ...



and the answer is: there will be no noticeable effect on the operation of the contactor coil ... that’s right ... so far the contactor is still faithfully clunk-clunk-clunking along just like it was before ... Trace C is still a perfectly valid indication of how the contactor coil will work (so far) ...



the basic idea is that both the BIG_AND_SLOW task and the SHORT_AND_FAST task still have the SAME priority (10) ... and since the priorities are EQUAL, either task can interrupt the other task ... so even though the BIG_AND_SLOW task is trying to hog the processor’s scan time to take care of that 400 ms delay, the SHORT_AND_FAST task is still quite capable of stepping in and running its own routine once each tenth of a second ... just like clockwork ...



the official books don’t do a very good job of explaining this particular situation ... they do cover (more or less) what will happen whenever a task with a certain priority runs into another task with either a higher priority or a lower priority ... but there is very little (if anything) mentioned about what happens with competing tasks which both have the SAME/EQUAL priority ...



and now a quick summary before we proceed ... so far we have a BIG_AND_SLOW task which starts executing once each and every second ... each scan of this particular task is taking a whopping big 400 ms to complete ... we also have a SHORT_AND_FAST task which starts executing ten times during each and every second ... and even though the SHORT_AND_FAST task has exactly the same priority setting (10) as the BIG_AND_SLOW task, the SHORT_AND_FAST task can still get its “ten-times-a-second” job done - because its EQUAL priority is allowed to interrupt the BIG_AND_SLOW task ... we can tell that this “interruption” is actually taking place because the contactor coil is still faithfully “clunk-clunk-clunking” along at its same old steady “ten-clunks-a-second” rate ...



and so all is well ... the sun is shining ... the birds are singing ... life is lovely ...



now let’s throw a monkey-wrench into the works ... suppose that we go to the Configuration tab (see the first figure above) of EITHER task ... and suppose that we fool with EITHER of the Priority settings ... and suppose that we somehow give the SHORT_AND_FAST task a lower/weaker priority than the BIG_AND_SLOW task ... we could do that by either entering a HIGHER number (say 11) to give a LOWER priority to the SHORT_AND_FAST task ... or we could enter a LOWER number (say 9) to give a HIGHER priority to the BIG_AND_SLOW task ... either approach would give the same results ... specifically, now the SHORT_AND_FAST task would no longer be allowed to interrupt the BIG_AND_SLOW task ... oops! ... now listen to the contactor coil ...



the old steady “clunk-clunk-clunk” has now been replaced with a sort of rough and ragged “clunk-clunk-clunk----pause----clunk-clunk-clunk----pause----clunk-clunk-clunk” type of pattern ... you can see something like that indicated by Trace E in the figure above ...



time for a side trip ... now stop and think ... pretend you’re a technician working around a piece of machinery with a brand new ControlLogix controller on it ... everything has been working fine up until this afternoon ... now suddenly the timing of some part of the machinery has shifted out of whack ... maybe (just maybe) a junior programmer has taken a perverted notion to tinker around with the priority setting on a particular task ... (gee, I wonder what this setting does) ... worse case scenario: the setting that he messed with is not even on YOUR machine’s task at all ... maybe he fooled around with the priority setting on another completely unrelated task – but some how – some way – that other “big slow” task suddenly has the ability to keep your “short fast” task from executing with the same required regularity ... so “his” process is still working fine – but “your” machinery is suddenly acting up ... now yes, I’ll admit that this is an unlikely situation ... but still – COULD it happen? ... oh, yeah ... and wouldn’t it be “fun” to troubleshoot? ... this has all of the earmarks of one of those classic “ok-let’s-just-give-up-and-call-the-guru” type problems ...



now in an earlier post, RSL gave some excellent suggestions for taking care of situations just like this ... and I whole-heartedly agree with him ... but ... our friend just_lionel started this discussion with a question about the UID (User Interrupt Disable) instruction and the UIE (User Interrupt Enable) instruction ... so let’s go ahead and look at those next ... even if we don’t like them, and even if we never use them, we at least ought to know how they work ... if they don’t kill us, maybe they’ll make us stronger ...



before we program in the UID/UIE rungs, let’s go back and set up our test program so that the BIG_AND_SLOW task and the SHORT_AND_FAST task both have the same default Priority setting of 10 ... once that’s done, the contactor coil starts “clunk-clunk-clunking” away with its steady “ten-clunks-a-second” rate that we’ve come to love ... so things are back to normal again ...



it’s important that you understand that the only reason that everything is “normal” right now is because the SHORT_AND_FAST task is once again being allowed to “interrupt” the BIG_AND_SLOW task ... now you might have to jump through some mental hoops for this next part, but let’s just say that for some reason or other, we have decided that we do NOT want our BIG_AND_SLOW task to be interrupted ... yes, I know that’s kind of weird – because without those interruptions, the contactor will sound “ragged and rough” again ... but by doing this next experiment (just for educational purposes) we can literally hear how the system reacts to these new programming concepts – just by listening to the sound pattern that the contactor makes ... my students always love this approach because instead of listening to a dry lecture or looking at a slide show of “timing charts”, they can actually HEAR the results of the program changes that we’re making ...



continued in next post ...

continued from previous post ...



so now ... how do we go about keeping the SHORT_AND_FAST task from interrupting our BIG_AND_SLOW task? ... that’s the question before us ... we could (and probably SHOULD) carefully adjust our task priorities – and maybe correct the reason why our BIG_AND_SLOW task is big and “slow” in the first place ... but our purpose for today is to learn about the UID and UIE instructions ... so let’s program in two new UID/UIE rungs to “bracket” the “scan delay” part of our program ....








now by just manually toggling the PREVENT_INTERRUPTS bit on and off we can literally hear the effect of the UID instruction as it disables the ability of the SHORT_AND_FAST task to interrupt the execution of our BIG_AND_SLOW task ... and now the contactor coil starts clunking in the same “rough and ragged” pattern that we heard earlier ...



let’s nail this thing down ... suppose that we go back to the Configuration of the SHORT_AND_FAST task and change the Priority setting ... suppose that we give the SHORT_AND_FAST task a higher priority (lower number) than the BIG_AND_SLOW task ... suppose that we enter a new setting of 9 ...



the contactor keeps running “rough and ragged” ... specifically, even though it now has a higher priority, the SHORT_AND_FAST task is still not allowed to break in and interrupt the execution of the BIG_AND_SLOW task – as long as the UID is in operation and on guard ...



so next (just to make sure) we toggle PREVENT_INTERRUPTS off and the UID is out of the picture ... and now the delay loop can be interrupted – and the contactor runs smooth ...



but when we toggle PREVENT_INTERRUPTS on, the UID goes into operation ... and now the delay loop can NOT be interrupted – and the contactor runs rough ...



and so our “let’s use UID and UIE” mission has been accomplished ...



now for the next question ... how would you go about troubleshooting a weird “interrupt” problem? ... actually RSL mentioned the best method in his post ... if we right-click on the SHORT_AND_FAST task and then select Properties from the menu, we’ll eventually make our way to the Monitor tab ...







the “Task Overlap Count” indication on this window should ideally be at zero ... when you push the “Reset” button it should clear any numbers and start a new count ... and hopefully the new count will stay at zero ... if the count goes up, it means that the task is not getting a chance to “do its thing” as often as it’s supposed to ... you need to track down the reason for that situation and probably take some type of corrective action ...



and while we’re here, let’s take a look at some of the other values on this particular window ... notice that the “Scan Times (Elapsed Time)” has a “Max” reading of 400.324 ms ... what’s going on here? ... this looks very fishy when you remember that this is our SHORT_AND_FAST task ... all it ever has to do is control one solitary bit to flip/flop our contactor coil off or on ... certainly that shouldn’t require 400 ms of processor scan time ...



the answer, of course, is that the mammoth maximum scan time resulted when, once-upon-a-time during our experiments, the BIG_AND_SLOW task was scanned/executed (delay loop and all) during the execution of the SHORT_AND_FAST task ...



and of course, the “Interval Times (Elapsed Time Between Triggers)” got that whopping big “Max” reading of 500.141 ms in much the same way ... in “normal” operation, this setting wouldn’t be expected to go much (if any) higher than the 100 ms Period setting that we entered for this SHORT_AND_FAST task when we originally configured it ... but once-upon-a-time the 400 ms execution time of the BIG_AND_SLOW task kicked in and added itself to the expected 100 ms Interval/Period time ...



and now for our last exercise along these lines ... just_lionel says that he had a question which unfortunately wasn’t answered in a couple of classes (not mine) that he took ... specifically,

If an event task is called 4 times during the time the PLC is in the UID/UIE set, when the conditions are met to resume regular run conditions, will the Event task run itself 4 times or just once??

Click to expand...

as I said at the beginning of this epic, the simplest answer is “no” ... in other words, the tasks that are prevented from running “on schedule” will not “queue up” and then all be run later when the opportunity for execution finally presents itself ... and actually RSL had already given the correct answer to the original question ...



but now I’m going to include another little trick that will help just_lionel prove the answer for himself ... suppose that we go to the DELAY_LOOP routine and to the FLIP_FLOP routine and we add a simple “scan counter” rung to each routine ... we might get something like this ...








suppose that we set both of our “scan counters” to zero while the processor is in the “Program” mode ... then we put the processor into the “Run” mode for 60 seconds ... and then go back to “Program” mode ... if (big IF) the SHORT_AND_FAST task is allowed to interrupt the BIG_AND_SLOW task, then the values in the counters will be something along the lines of those shown in the figure ... specifically, the BIG_AND_SLOW task should have executed about 60 times during those 60 seconds ... and the SHORT_AND_FAST task should have executed approximately ten times that amount (about 600 scans) during the same 60 second period ...



so now suppose that we set both of our “scan counters” back to zero and then run the same experiment again ... but this time we use the UID/UIE instructions to prevent the SHORT_AND_FAST task from interrupting the BIG_AND_SLOW task ... when I ran this particular test for 60 seconds, the BIG_AND_SLOW task executed about 60 times during those 60 seconds ... but the SHORT_AND_FAST task got nothing close to the expected 600 scans during the same 60 second period ... instead the “scan counter” in the routine for that particular task got only about 367 scans ... in simplest terms, all of the SHORT_AND_FAST executions that didn’t get a chance to run “on schedule” did not get “saved up” and given another chance to run later ... instead, once those scheduled executions were “missed/overlapped” they were simply lost and gone forever ...



and of course there are ways to do these test/experimental operations without taking the processor out of the “Run” mode ... but we’re trying to keep things as simple as possible here ...



hopefully this has answered some basic questions for a few people ... the main thing that I’ve tried to provide is a set of “tools” to help in understanding not only the original questions posed in this thread, but also to help with many other similar questions that might pop up in the future ... the biggest things that we’ve covered were the “scan delay loop” and the “scan counters” ... these are the same types of tools and techniques that I cover in all of my classes – so I know that they can help you get “beyond the books” and even “beyond the instructors” in a lot of tricky situations ...

Wow

Thanks Ron, you answered my question better than I expected, and I learned a few other helpful hints as well. I did run into a few cases where the instructor was stumped and I had to figure it out for myself.

Once again, thanks for the response, I was hoping you would run across this question. I've been trying to get my company to get in contact with you for some classes for our maintenance team, but alas, no go so far, something about starting up a plant, and money

Thanks Ron.

I really enjoyed your detailed post. Thanks for taking the time to enlighten us.

RSL