Suggest adding a Chart Timer in all your charts (assuming they are looping around). This will allow you to specify how fast you want your chart to run in addition to seeing if the chart is overrunning.
Have a tag assigned as MAIN_LOOP_TDSP (Time Delay Setpoint) - set its value at 0.2 (200msec)
MAIN_LOOP_TIME = MAIN_LOOP_TIMER;
At the end of the chart have a DelaySec command based on the difference between the loop time setpoint (MAIN_LOOP_TDSP) and the current loop timer (MAIN_LOOP_TIMER) value. At this point you can also record the value of the Loop Timer with another float tag to see your actual chart processing time (or add to a float table so you can monitor over a period of time).
Once the delay is done (or immediately if the actual loop timer exceeds the setpoint) the chart loops back to the Timer Block and repeats the chart instructions. Decrease MAIN_LOOP_TDSP to speed up the chart and increase it to slow things down. It can be done sexier (for better loop timing) but you get the general idea.
With this approach non-critical calculations and control can be slowed down while more critical control can be sped up.
On our gas turbine fuel control application (using a PAC-R) we have Speed Control / Monitor loops running at 50msec, Controller Loops at 100msec, and Supervisory Loops running at 200msec. We even have some applications that need to operate a valve controller motor directly (pulsing the motor) in which our IO scan time (encoder feedback in to digital out) is less than 10msec to maintain motor/valve position.
This application may have 12 or so charts running simultaneously and continuously (again on a PAC-R), so by allocating our timing as needed, we are able to increase the total functionality of the controller as a whole.
The other trick is to decouple your IO from the logic so you only read / write the necessary IO points once per scan time. No sense reading the same digital input multiple times in a 100msec chart if you can wait until the next scan time to re-evaluate how you want to proceed with that point. Most applications (there are always exceptions) work fine with this approach.
Also as per Philip’s previous suggestion setting up your PACDisplay to read an internal variable verse directly from the IO will also relieve some of the processing burden on a PAC-R controller.
The PAC-R ability to have control at the IO level is a very powerful tool (verses a centralized controller) for fast process control loops. Use it when speed is necessary verses a PAC-S having to read/write an IO brain.