Fast vs. Very, Very Fast

I have been working on a CNC controller for quite some time. I am most interested in the speed of the entire process and what it takes to increase the speed of that process. When I say speed, I am looking to decrease the scan time of a SNAP-PAC-R1. I say scan time because that is what I am use to evaluating in other brand controllers I have used in the past.

Let me explain what my current project entails.
I have 1 SNAP-PAC-R1 and 1 Touch Screen running PAC Display Runtime ( an All-In-One PC). This process involves 6 Axes (PID Loops) and about 32 inputs and 32 outputs.

The item that I have been monitoring lately is the “Loop Time” (if there is a way to monitor “scan time” I would love to hear any feedback on that). When I started investigating, my loop time was up to 300+ msec. I have condensed some things and now the process only runs 2 charts (it will never, ever be less than 2 charts) at any given time. I also reduced the amount of tags on the “Auto” screen from 210 floating point values ( with a refresh rate of 500 msec) to 130 floating point values (and a refresh rate of 2 seconds). With that said, I was able to achieve 30-100 msec loop time. This reading was taken with PAC Control in debug mode (Control Engine>Inspect). With 100 msec being the max, it usually sits between 30-50 msec.

After I achieved this, I could see increased performance of the entire system. Winning… (heh)

I then turned debug mode off in PAC Control and went to PAC Terminal (View>Status). I would monitor the Loop Time and it was at 16-45 msec (most of the time it was below 20 msec… Great.)

With all of this said, I am wondering the proper way to actually see how fast the R1 is executing the strategy. I know some controllers I have used in the past (and still use), the max scan time is 3 msec and actually run less than or equal to 1 msec. This is the value I want to see in the R1. Is this possible from some status value? Any input would be appreciated.

I would like to think about this a bit, but in my typical fashion, I’m going to answer with a spur of the moment gut feeling first :-]

  1. Don’t do any timing assessments while in PAC Control debug. (I note your not really doing this, but want to make it clear).

  2. Pac Term comm loop time is worth keeping an eye on.

  3. Look in PAC Manager → Inspect. Scroll down almost to the bottom and look for:
    0xFFFF F030 0140 Analog & High Density Digital Scanner 10.340 msec/scan
    0xFFFF F030 0144 4-Channel Digital Scanner 6.387 msec/scan
    But don’t get hung up on these times, in other words, don’t take them as ‘law’, like the pac term comm loop time, they are part of the story, not THE story.

  4. Read my post here; Off delay on DI - #30 by Beno Consider using this code in one or more of your loops or chart (I don’t know the structure of your chart(s), so cant advise the best place to put that code, but you will soon figure out the loop times you want to monitor).

  5. Add delays in your chart - EVERY loop through each part of each chart should have a delay. Adding delays speeds things up. In your case, the delays can be anything from 1 to 10msec, but be sure and have them.

  6. Try and isolate the PAC and touch screen from the rest of your network traffic. (Think broadcast packet isolation).

  7. Read this slowly. Scan time explained - old forum post

  8. If you are brave, and your application has need for it, consider off loading some ‘Event Reaction’ code from your charts to the I/O.

1 Like

Some ideas to try to squeak out more performance - will need tested in practice. FWIW, I’ve never needed anything to run at millisecond speed, so this is all hypothetical and may not work at all :wink:

Are you reading all your IO points at once or individually? Try using the MoveIoUnitToNumTable command and then performing your logic on the table, then write it back using MoveNumTableToIoUnit. This SHOULD prevent multiple context switches as your chart waits for the IO to complete reading each point.

Run four channel or less modules - these have the fastest response.

You could also try turning off reading tags directly from I/O unit in PAC Display (Configure | Runtime | I/O Unit Tags - uncheck the box). Not sure if it will make these better, worse, or no difference. (Or setup PAC Display to only read from the IO tables that you grab from the MoveIoUnitToNumTable command).

Since you have an all-in-one PC, you could run the strategy in SoftPAC and turn off the control engine in the R1, leaving the R1 to just handle the IO (a super brain of sorts). That with the Move IO unit commands and setting runtime to read from the strategy tables- you can limit your reading and writing to the R1 to just two commands per loop. If I recall correctly, SoftPAC is a couple order of magnitudes faster than an R1 so all the wait time will be from the I/O read/write commands.

1 Like

At our company we have tested and used SoftPAC vs controllers in some rather intensive applications where there was a lot of calculating and table looping occurring. The speed of the calculation loop is truly orders of magnitude faster (with our program, at least 100x faster) – a chart that took 0.9 seconds (yes, that much involved in the calculations) ran in 2-3 milliseconds on SoftPAC.

The only reason the R1 might be more efficient in speed is if the I/O reads are faster – since it’s an on-board communication link (vs an external read/response), it would seem logical (but untested by us) that not having to communicate to another device would indicate that the reads/writes would be quicker. And since there’s PID involved, that may apply.

Hi Guys,

I have a few things to add, but first, what’s the problem we’re trying to solve here? Is this just for some kind of theoretical performance? Because there might be a better/faster way to “cure” whatever you’re trying to solve (e.g. by doing more calcs at a lower level, “edge” and all that).

But a few more questions besides the 50,000 foot view:

Is your strategy compiled for “Full Debug”? (In PAC Control config mode under the Configure menu). Changing that to Minimal Debug trims out lots of extra code.

Are you using both analog and digital on that rack? Because if you can put all your analog on one rack and all the digital on another (e.g. so you can turn off the digital scanner or analog scanner) that could eek out a little extra.

What else is hitting this? FYI - The Ethernet “task” has the highest priority of darn near anything. So if you do the stuff that Ben mentioned w/timers, etc. and see what those values look like, then compare to what they look like when the PAC is physically disconnected from the network, that would tell you something about the impact on all those externals.

Also, the charts may not always get exactly even slices of the pie. If you have a particular section of code that you want to have run as fast as possible, you can:

  1. spin through all the other charts and suspend them
  2. do the special code
  3. spin through and “continue” the lesser charts

There’s this tech note 1776 which covers some of what’s been mentioned above, I’ve been meaning to update parts of it, but might be useful, too.

How important is it that this performance be consistent? (Some customers/applications need less speed but more predictability, e.g. this must happen exactly X milliseconds after Y, but we can wait for those things to happen.) That goes back to the 50,000 foot view question I started with…

Thanks,
Mary

I appreciate all the feedback on this. My process might be running just as fast as the “other controller” I was talking about in my last post. I just wanted to see if it was moving through the code as fast as possible.

I have one 12 slot rack with 3 encoder cards, 3 analog output cards, 1 - 32pt input card, 1 - 32pt output card and 4 - 4pt output cards. Like I said before, I noticed the system was a little sluggish and wanted to investigate. Once I got the Loop time down below 100 msec, things started looking really good. There is a part in one of my charts that will have 5 axes running at the same time and while it is making all those moves it is cycling through about 735 lines of OptoScript (I currently do not have a delay during this time of this chart). During that time I only have one other chart running that takes care of limits and some safety monitoring (I always want this chart running no matter what). This 2nd chart does have some of the same code as the 735 lines in the other chart. This is because I want the PIDs updated and some calculations done when the time slice is given up to the 2nd chart.
I only have 2 charts running while the axes can move. At times I will have 3 or 4 charts running at a certain time, but never when an axis is moving. So during any motion, I will have 3 time slices to cycle through. 2 charts and the slice given up for PAC Display. In PAC Display Runtime, I make sure there is only 1 screen open at any given time. My “Auto” screen is quite busy, but the client wants to see all those values. I recently shaved some values off of this screen and raised the refresh rate and it improved the performance as well.

I have read about all the things you guys have posted and I will try to check some of it out.
Mary,
I just want to see just how fast this process is running and if I can speed it up even more.
I checked and I am using Full Debug.
I have both Digital and Analog on the rack.
And yes, I would like it to be consistent.

Thanks for all the responses.

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.
FOR EXAMPLE:
Have a tag assigned as MAIN_LOOP_TDSP (Time Delay Setpoint) - set its value at 0.2 (200msec)

MAIN_LOOP_TIME = MAIN_LOOP_TIMER;

SetUpTimerTarget(1,MAIN_LOOP_TIMER);
StartTimer(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.

1 Like

I agree with alanlevezu, if you need blazing speed, use a NUC 7i7 and and R1 as a brain and the execution will be amazing…even if it is less than optimum, will not matter…

Molex built a 25ghz cable manufacturing machine (about 75 feet long) that ended up using 2 softpac units and R1’s for brains and it was orders of magnitudes over S1’s, just not the same universe. There were 30-50 servos on the first half of the machine along with a gazillion air cylinders, Cognex cameras all over the place, it was amazing. Produced one cable in about 3 seconds or less that had inj molded ends and fully freq tested.

Hope the new Edge has as much HP as that…