Some tech tip advice to help keep your industrial systems running smoothly.
Whenever I say this blog title out loud to the Premium Factory Training class attendees, I get some funny looks. I'm not sure if it's the Aussie accent, or the idea of adding delays to speed up that causes the double-take chuckles.
Compute power has come a long way in the last 10 years or so, but regardless, we programmers of all things industrial still need to be mindful of optimizing our code and systems to run as smoothly as they possibly can.
Arguably, one of the biggest tips for programming in PAC Control I can share with you all is to add delays through your flow charts and OptoScript blocks.
If you’ve been a long-time reader of this blog, you may remember me discussing "the need for speed" at the end of the Deepsea Challenger blog, part 2, way back in 2015. I still retell that story in every training class to drive the point home about how running a system "flat out" is hardly ever the best way to run smooth and fast.
OK, enough with the back story. Let's dig into some details and see how adding a delay can speed up a process.
Let's take a pretty common situation—you need to check if a digital input is on (or not).
Granted, this is an over-simplified chart, but it will do nicely to illustrate the topic of this blog.
If the digital point is off, the CPU will spin as fast as it can checking that point over and over and over and over. All the other charts that might be running, all the other processes running on the controller—perhaps groov View, Ignition, Data Services, Node-RED—will be squeezed in the best that the OS (Linux kernel) can do.
What do you do when someone asks you to wait?
Well, these days, you usually pull out your phone and catch up on other tasks that you need to do. The controller is no different: by simply putting a delay in an action block out of the false condition block, the CPU can catch up with its homework, and perhaps take a nap, before checking the digital point status again.
While the digital point is off, every 100 milliseconds, the controller can breathe easy and throw its entire quad-core CPU at all its other tasks. That one small change, adding a 100 mSec delay command, has just made a massive difference to the speed of your entire process.
In the case of the Deepsea Challenger submarine, the delays we added to all the chart loops allowed the serial communications time to address each device without queuing up, and thus bogging down the sub's overall responsiveness.
We could have a long conversation—and please sound off in the comments if you have some thoughts—about just how long that delay should be. In class, I usually break it down like this: if the digital point is an operator switch, do you want the delay to be longer than 250 mSec? No, the operator will notice that "the button sometimes feels glitchy." Humans can notice interface delays longer than about 100 mSec. Does it need to be shorter than 100? No, a human will not notice if it's quicker, so why tie up the CPU for a digital input that no one will notice (but plenty of people will notice if the delay is NOT there).
What if it's a machine E-Stop?
OK, an E-stop clearly needs to be less than 100 mSec most of the time, but even an E-Stop chart can probably have a 1 mSec delay at the very least in there. Just setting the delay to its smallest unit will still help a quad-core 1 Ghz CPU breathe a little. You get the idea. If you are checking for an analog value, say an ambient air temperature, the delay, in this case, could easily be much (much) longer than 250 mSec.
Sounds great, no downsides, right? But can anyone see the "gotcha" that is lurking in the condition block or, more accurately, lurking in the chart structure?
What happens when the point turns on?
Right. The CPU will be racing around to "Do stuff" and "Do more stuff" at 100% CPU time the whole time the point is on!
Are we back to the same issue? Yes, but we know the fix. Put a delay command in either of the "stuff" action blocks.
Of course, as I mentioned in the opening, even OptoScript blocks should have a delay in them—simply adding them in any coded loops you’re using will help. It's that simple.
Every path, through every chart, must have a delay. It is really as simple as that. Well, actually, it’s as simple as "Add delays to speed up."
If you're interested in attending our groov EPIC Premium Factory Training class to learn more deep hints and tips for all things PAC Control, groov family hardware, and get a factory tour (and lots of yummy food!), then you should check out our training class schedule. We hope to see you soon!
Till next time.
Cheers Mate,
-Ben