This previous post from an OptoFan wanting to add some logic to an existing strategy prompted this OptoNews [URL=“http://www.opto22.com/site/optonews/2012/optonews_04112012.aspx#ttip”]Tech Tip about understanding a new-to-you strategy.
Here’s the story of another common situation:
[B]“Too Slow” [/B]
This week in class we had more OptoFans who’d inherited a system – that the bosses wanted to replace with something non-Opto because it was “too slow.” NOOO!! Looking at their hardware architecture (lots of serial and Arcnet), as well as their system design (not very modular), and software (still the old Factory Floor, not PAC Project) – we could see lots of room for improvements. But they needed something quick and easy and cheap (free would be best) to appease the bosses ASAP.
But where to start? I’d ask: what hurts most? In this case, their OptoDisplay HMI was taking up to 30 seconds to respond in some cases.
[B]Refresher on Refresh rates[/B]
We asked about refresh rates. If you haven’t already read our Performance Technote (form 1776), I strongly recommend you check it out. Here’s a relevant excerpt:
• Keep I/O tags in refresh groups that are separate from PAC Control strategy tags. Group strategy variable and table tags into refresh groups that do not have I/O tags.
• Use reasonable Refresh Group time intervals.
But what’s “reasonable”?
First have a look at the Refresh times, in Configurator under Configure > Refresh times.
By default, when adding something to the display screen it will be part of Refresh Group 0, which by default is Scanned every 1 seconds.
[B]DON’T USE THESE DEFAULTS:[/B]
The idea is to avoid hammering the controller with more requests than needed. If we always use the defaults, then as the PAC Display project gets larger, the controller(s) will get bogged down with all the requests for data that need to be met each second.
Consider how fast a particular piece of information changes. If you’re showing the total number of widgets produced, and it takes at least 10 seconds to produce another one; or you’re perhaps showing a temperature, your units for those Groups shouldn’t be in milliseconds – it should be closer to the time it takes for a change to be noticed.
[B]But what if I have hundreds of values or windows?[/B]
At first they thought I wanted them to change all their windows and items scanned. Not right off, start with the low-hanging fruit – those easy-to-change Groups.
In the case of our visitors this week with long lag times – they mentioned that some scan rates were in milliseconds. I suggested they try changing any of the under-one-second groups to be 1 second and see if it affects that lag they mentioned. With 30-second lags, they might even try 3, 5, or 7-second minimums and see how over-all lag times drop.
Another quick, free, and easy way to take some of the burden off your controller is to make sure you’re running it in Minimal Debug. The extra debug code that’s compiled into your strategy when configured for Full Debug can make a noticeable difference in how fast your commands get executed.
[B]Lots of Delays ARE GOOD![/B]
Of course, ALL your looping charts have delays in them, yes? If you’re not sure why you’d want to put a delay in a chart to make things run FASTER, check out form 1776, and these other forums posts:
Ben’s Decision Loop Example
Mary’s “Are we there yet?” analogy
Have you inherited a strategy or project? Do share!