Soft Pac consuming PC CPU resources


#1

We have recently started updating our systems to Windows 7. Yes, I know it’s almost obsolete.
The newer systems we have are running the SoftPac virtual controller and as soon as you start the project, ie… put pac control into debug mode, it immediately consumes roughly 70 to 80% of CPU resources.
When we start runtime it goes up to about 85% of CPU resources. It only gets worse from there to the point that communication between the softpac and the I/O becomes intermittent causing all manner of mayhem.

If you attempt to open Opto Control with the runtime running, things get ugly real fast with all 4 cores railed at 100%.

Softpac is running the latest “firmware” (9.4c) , Brain is flashed up (9.5a) , Pac Control is the latest version. (9.5000-302)

Our other Opto projects NOT running softpac, but running the exact smae project don’t even break 1 to 2% of CPU usage.
PC’s are new and very good systems with Corei5 Processors and 16gb RAM.

Is anyone else experiencing this? We have started going through and putting in waits all over the place to slow things down but that’s only made a very minimal impact on the performance overall.


#2

Get a call/email into support@opto22.com as soon as you can.
It should not be doing this. (We have a bunch of people - myself included - running SoftPAC on a bunch of PC’s here in the Opto 22 building with no issues).


#3

Hello, was this issue every resolved?
I am experiencing the same problem with one of my clients where SoftPac is consuming over 95% of the PC’s CPU power.
Please help.


#4

I’m not sure of the original post outcome, but I do know for a fact that you MUST put delays in your charts when running SoftPAC.
I have run several tests personally and can confirm that if you do not put any delays in the charts, then SoftPAC will use high amounts of system CPU, as soon as you put a delay in each loop/part of each chart, the CPU drops to around 1-2% (and the chart runs just as fast, if not faster than with no delays).
It is important that EVERY chart has a delay. You cant skip any loop or part of the chart.


#5

Thank you, Ben. How long a delay would suffice? What amount did you use?
I will add some delays into our charts and report back.
Keep up the great work!


#6

Use delays that are appropriate for the process.
For example, a room temperature would be fine at 250msec (or much longer), a machine control might only be able to manage 10msec, a button press from an operator would be Ok at 150msec, but no longer.

Roughly, 5msec is better than none, and go up from there.

The point is, with no delays the code that runs SoftPAC does not release the system CPU, as soon as the chart hits any delay command, SoftPAC lets go of the CPU and you will see it drop. This is why it is important that every single loop (condition check) in every single chart has a delay of some type. Even if you have a straight ‘fall through’ chart, it should have a delay statement in its flow.


#7

I am very happy to report that the delays have made a MASSIVE difference.
Thank you!


#8

Sweet. Thanks for getting back to us and letting us know.

I have a saying here, that we repeat many times during the 3 day training course. People look at me a bit odd when I say it…but here goes…

“Adding delays speeds things up”.

Often, its not until you do it do you believe it because it sounds so counter intuitive. (Wow, that was a mangled sentence).