how to calculate multiple periodic task timing

[waterboy 7]

I'm taking a CLX class and the topic at the moment is periodic tasks of different priorities combined with a continuous task. We would set the watchdog and interval of various tasks and watch the watchdog eventually trip under the combination of the 2 periodic tasks forcing the continious task to exceed the watchdog. I understand the principle where the combination of these events will cause this but there was a calculation presented in the materials that the instructor couldn't explain and no one understood how it worked. It started by using the watchdog setting and subtracting the scan times of the tasks and factored in the number of times a task could run within the watchdog time allotment. The solution to the excersize was to decrease the interval at which the periodic task would run but that left as many questions as it answered. I can envision how we didnt solve the problem but merely extended the time it will take before the combination will cause the watchdog to trip again. Can someone explain how to account for this ripple effect when using multiple periodic tasks and a continious one?

[Guest]

well, maybe ... but adjusting the watchdog timers leads into another area of discussion – not so much connected with the "priorities" that you're really trying to explore ... here's another plan of attack to demonstrate "Priorities" which I've used with excellent results in the Boot Camp style classes that I teach ... disclaimer: although this is highly instructive material, it is intended for TRAINING PURPOSES ONLY! ... the techniques demonstrated here are NOT intended to be used in production machinery ... (we're going to slow down the processor as it scans its program – which is NOT a good thing to do when actual machinery is being controlled) ... first wire up a suitable field output (a large noisy contactor is best) ... set up an alias for the output and name it "COIL" for discussion purposes ... demonstrate that this field output can be toggled ON and OFF by manually toggling the appropriate bit/box ... make a new task named tsk_Big_And_Slow ... make this a periodic task with a period of 1000 ms ... leave the priority set for the default value of 10 ... leave the watchdog at its default setting of 500 ms ... in the tsk_Big_And_Slow task, make a new program named prg_Big_And_Slow ... in the prg_Big_And_Slow program, make a new routine named rtn_Big_And_Slow ... configure the system to scan this new routine as the "Main" routine of the program ... in the rtn_Big_And_Slow routine, enter the three rungs shown below ... make a new task named tsk_Short_And_Fast ... make this a periodic task with a period of 100 ms ... leave the priority set for the default value of 10 ... leave the watchdog at its default setting of 500 ms ... in the tsk_Short_And_Fast task, make a new program named prg_Short_And_Fast ... in the prg_Short_And_Fast program, make a new routine named rtn_Short_And_Fast ... configure the system to scan this new routine as the "Main" routine of the program ... in the rtn_Short_And_Fast routine, enter the single rung shown below ... discuss what you THINK will happen when the system is put into the Run mode ... specifically, how will the contactor in the field react? ... now put the system into the Run mode ... you should hear the contactor happily clunk-clunk-clunking away as its output changes state every 100 ms ... this next indication can vary with different communication links – but in most cases, the Delay_Timer will APPEAR to be "stuck" with its Accumulator frozen at 400 – and with its Done bit frozen in a status of ONE ... but ... if you manually type a lower number into the Accumulator, you'll see it rapidly change back to a value of 400 ... this indicates that the timer IS indeed still "running" ... here's what's happening: once each second, the task tsk_Big_And_Slow gets triggered into execution ... as soon as it starts its execution, it gets "hung in a loop" for 400 ms before it can finish its execution ... (think: "scantime hog") ... meanwhile ... ten times each second, the task tsk_Short_And_Fast gets triggered into execution ... each time it executes its single rung, the contactor COIL gets flip-flopped from ON to OFF – or vice versa – from OFF to ON ... this "proper" operation is somewhat surprising when you really think about it – because how can the processor be accurately flip-flopping the contactor - if said processor is busy chasing its tail around in that 400 ms loop? ... answer: since the two tasks have the same (equal) priority, they are "time-sharing" and the processor is dividing its time between both tasks ... one ms for one task – then one ms for the other – and so on ... by switching back and forth this way, the machinery being controlled by BOTH of the tasks will continue to work the way it was intended to work ... so ... the sun is shining ... the birds are singing ... life is lovely ... and MOST important, the boss is happy to be making money – as he listens to his machinery busily clunk-clunk-clunking away ... now here comes Little Johnnie the junior programmer ... (so who's supposed to be watching him today?) ... suppose that Little Johnnie (working without "adult supervision") is piddling around with the code for the Big_And_Slow machinery ... (specifically, Little Johnnie isn't even aware of our Short_And_Fast machinery successfully working away on the other side of the plant) ... so Little Johnnie thinks to himself: "Suppose I could improve the operation of this Big_And_Slow machinery. Maybe I could get a bonus for speeding it up." ... so he starts poking around in the program - until he finally stumbles upon the "Priority" setting for the Big_And_Slow task ... he notices the legend that a "Lower Number Yields a Higher Priority" ... now THAT sounds interesting ... the Priority is currently set for 10 ... (can you see it coming?) ... so Little Johnnie (bless his little heart) makes sure no one is watching, and changes the Priority setting to 9 – and then Applies the changes ... suddenly "bad stuff" starts happening to the Short_And_Fast machinery ... the rhythmic clunk-clunk-clunking sound that the boss expects to hear is now very ragged and rough ... (think: "negative impact to the plant's bottom line") ... suppose that you're the lucky technician who gets called upon to go forth and troubleshoot and repair that malfunctioning equipment ... MAJOR POINT: where do you start looking for the problem? ... think about it ... NOTHING – absolutely NOTHING – has been changed in YOUR Short_And_Fast part of the program ... and suppose that instead of having just ONE rung – suppose that you have HUNDREDS – if not THOUSANDS – of rungs to search through looking for the problem ... meanwhile the boss is breathing heavily down your neck demanding to know when he's going to start hearing the familiar clunk-clunk-clunking of money being made ... meanwhile - back on the other side of the plant ... Little Johnnie doesn't notice ANY change whatsoever in "his" Big_And_Slow machinery ... but he thinks to himself: "Well, maybe after running for a full day or so we'll find out that our production really has been increased – quality has been enhanced - moral has improved – my acne has cleared up. Surely SOMETHING good is BOUND to come from having a higher priority." ... so Little Johnnie just leaves the Priority for Big_And_Slow at the new 9 setting – and runs off to piddle with something else for a while ... side trip: NO, folks, I do NOT "make this stuff up" ... I don't have this much imagination ... anyway ... by playing around for a while, your class should be able to squeeze quite a bit of educational juice out of the program features that I've outlined here ... for a few suggestions, try increasing the Preset of the Delay_Timer to something higher than the various watchdog settings ... try putting something like the flip-flop contactor control into the Continuous task and see what happens ... or just insert a simple ADD rung in the Continous task to increment a DINT value once per scan ... see how many scans it counts when the Delay_Timer's preset is changed from one value to another ... there's a LOT more to be learned by going back to the Properties for the various tasks – and especially by checking the Monitor tab ... anyway – I'm out of typing time for now ... incidentally, if your instructor is interested in more along these lines, have him give me a call ... this week is good ... next week is not ... party on ... Edited 22 Sep 2010 by Ron Beaufort

[waterboy 7]

Ron, Thank you for the alternative explaination. I can see how the timesharing would occur with identical priorities. I can also see how the tasks with different priorities would interefere with each other. What I am looking for is a formula that can take all the scan times of the various tasks and show me that they wouldnt interfere with each other. Something that I could use as a design tool rather than trial and error. Perhaps there is no such thing?

[Guest]

can you make that calculation available to us? ... maybe we can come up with something that will help you based on that approach ... there's also a "Task Monitor" tool available that came on the CD with RSLogix5000 ... to be honest I've never worked with it ... I've got it loaded on one computer which is at work right now ... if I have time when I get to the lab tomorrow I'll poke around and see if it looks like it might be useful to you ... in the meantime, maybe some of our other members have some experience with this particular tool? ... anybody? ... you've only mentioned the "scan time" and the "watchdog" values so far – but have you already looked at the information available in the "Monitor" section of the task's Properties feature? ...

[waterboy 7]

Verbatim... Note the Watchdog timer value 450ms subtract the required time for the continuous task: 450 - 300 = 150 subtract the time the existing periodic task takes: 150 - 90 = 60 90 ms comes from the following calculation: Executes every 50 ms or 9 times in 450 ms 9 times executed * 10ms each time = 90 ms Divide the time remining by the time it takes the second periodic task to execute: 60 / 20 = 3 Divide the total time allowed by the number of times you want the second task to execute. 450 / 3 = 150 Does this seem complete to you?

[Guest]

well, remember that I'm coming into this pretty late in the game, but I "THINK" that the chart below shows what's intended by the calculations you gave us ... apparently this is designed to calculate a "scan time budget" ... sort of like: "how much is our monthly paycheck?" ... "how much of that do we need for the rent?" ... "how much for groceries and so on" ... and finally: "how many times can we afford to go to the movies this month?" ... the green bar A shows the total time allowed before the continuous task watchdog will "run out" and cause a fault ... in simplest terms, WHATEVER we do, we need to do it within this total time allotment – or else bad stuff will happen ... the dark blue bar B shows how much time the continuous task requires ... note that this total time can be "sliced and diced" as any OTHER tasks are being executed and thus interrupting the continuous task ... (personally I think that the word "continuous" was a poor choice of a name for something which is seldom if ever "continuous" in operation) ... the red bar C shows the amount of "left over" time NOT required by the continuous task ... in finances this might be something like a "margin" ... in simplest terms, this is all that we have left of the watchdog's total allowed time ... specifically, if we have any other tasks to be executed, then they must all be crammed into this remaining 150 ms timeframe ... the yellow bar D shows how much time our first periodic task is going to require in order to execute 9 times – all within the 450 ms "bandwidth" of the watchdog setting ... subtracting D from C gives us the gray bar E – which shows how much remaining "margin" we still have left over after we've deducted everything we've obligated our processor to do so far ... looks like we're down to just 60 ms still left in the piggybank ... the light blue bar F indicates how much time is required to execute the second periodic task ... notice that we can only shoehorn three executions of that 20 ms task into our remaining "margin" of 60 ms ... so ... final answer ... if we regroup with our original 450 ms watchdog allowance, it looks like we can execute the second periodic task as often as 150 ms and still not upset the watchdog ... I might be off in some of the details – but as near as I can tell, this is what the calculations you gave us are intended to show ... quick question for you: where did you get this material from? ... Edited 24 Sep 2010 by Ron Beaufort

[Shiner 2]

Don't forget, every time you switch from one task to another, a small increment of time is lost. If your program is large enough, with enough periodic tasks of different priority levels that cause switching, and you do not leave the proper margin your watchdog will time out. Our instructor gave us a good demonstration of this where the math and the graph like Ron shows should have worked, but once running the switching ate up so much time we timed out the WD.