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 ...