PAC Display Runtime running very slowly - displays freezing

That’s not really the same issue. In our case, the various windows either don’t update at all, or update very slowly (like once every 15 seconds). Creating exceptions for defender for all of the directories and their files didn’t make any difference.

The thing that makes the system run “fast” is running Google Earth at the same time (even though it’s minimized).

And we just re-launch runtime as many times as it takes to get it to start updating. Usually, it only takes a try or two.

Other than that, it all runs just great on this PC. I still think it may well be an incompatibility with the video drivers.

All of the operators have just gotten used to having to do this song and dance any time the system needs to be rebooted. :slight_smile:

Wow I am very grateful for this post! The issue occurred for me first while developing at home with a Win10 Home addition after one of the infamous automatic updates. I chalked it as being an issue with not having Win 10 Pro. Our Win10 Pro controls PC’s have the Win10 Automatic updates turned off thus this week when we proceeded to update the operating system, the exact same condition occurred. I am going to contact Opto support to see if they want to create a KB and possible change their install to modify the Win Security Exploit Settings for DisplayR.pro.exe.

A possible cause for this issue is the Windows “Processor power management” setting. Depending on the version of Windows, you might find it here:

Control Panel > Power Options > Change Plan Settings > Change advanced power settings > Processor power management.

Change the “Minimum processor state” to 100%

Change the “Maximum processor state” to 100%

You might check the other settings while you’re in that dialog so that you don’t have important things going to sleep or hibernating when nobody is interacting with the computer.

Have you had an issue with the processor state causing PAC Display issues? I haven’t heard this being an issue before. Be aware that a PC at 100% CPU will consume quite a bit more power and likely be noisy, so I wouldn’t run a machine like this unless it solves an issue. It may be worth a try in Sigmo’s issue though.

Thanks, Philip. I always appreciate your forum postings! Yes, we have had customers experience this issue, but you have a good point. Perhaps see if setting both to 100% solves the issue. If it does, then you know you’re on the right track. At that point, you can adjust the values and test the results to tune the settings for your specific needs.

1 Like

I was having the same problems as above and after about 8 months of stop start messing about I have also downloaded Google Earth and let it run in the background on the problematic machine.
All is now OK, PAC Runtime is running smoothly and quickly.
Google Earth did not install correctly as the machine has no internet connection but it installed enough to get the program itself running. Because Google Earth can’t connect to its servers it couldn’t show any graphics (maps of earth, etc) but it is still running in the background however.
My post from sometime ago is here…PACProject 10.1001 Build 24 issues

We’re still running Google Earth here. I and some operators have tried running other programs in the background to achieve the same effect, but none of them accomplish “the fix” the way Earth does!

I still feel like this is somehow display adapter related, but it could also be related to some power saving feature that I haven’t yet found.

I will try the tricks mentioned in some of the above posts, but I don’t want to force 100% CPU usage for a number of reasons. Backup power run time during a power failure being one concern, of course.

Everyone is just used to launching Google Earth before firing up Optodisplay Runtime. It’s not right, but it’s working.

Still, I’d really like to get to the bottom of it all and have this operate properly. We are running a dual NIC setup with the Opto system on one, and our office network on the other with separate subnets. While that’s not perfect security, at least the opto system is not directly exposed to the internet.

But this also means we can actually use Google Earth on this computer. The whole point of this PC and the 4K TV we’re using as a monitor is to have a large amount of real estate so we can display a lot of the plant’s data all at once. It’s quite convenient.

But this also makes for an impressive display for Google Earth and GIS data when we’re looking at pipe and valve locations throughout our distribution system. So Earth is a valuable tool for us at this workstation at times.

Update:

I ran into the tags not loading on startup in PAC Display at another customer site that has upgraded to Windows 10. I narrowed the Exploit Protection Setting down to needing to turn off Randomize memory allocation (Bottom-up ASLR).

2 Likes

How did you figure that one out? wow…
I have one of our first concrete batching plants now running on the EPIC.
Many a time on Display startup a lot of tags do not load until we restart Display runtime a few times.

Thanks - I’ll give this a shot!

It was happening consistently enough at the last site, that it was easy to narrow down the options in the EPS settings. I also don’t have much hair left.

Let us know how it goes.

1 Like

This has been my experience as well, except for needing google earth/some other program running. But initial launch after reboot is super unreliable and multiple launches are needed to get the display to work/update.

The thread has gotten long, so to consolidate what I changed:

Windows Security
App & Browser Control
Exploit Protection Settings
Program Settings
Add an exception for program name DisplayR.pro.exe
Set overide to off on “Randomize memory allocation (Bottom-up ASLR)”

Or DisplayR.basic.exe if you are using Basic.

4 Likes

Thanks again phillip

None of the overrides to Windows Security did anything for our system. I performed all six, but to no avail.

So I’ve still been running Google Earth Pro in the background, and just launching PAC Display Basic over and over until it finally launches correctly. And while that is a pain, it’s been running fine once that song and dance was performed.

Now, after the most recent update to Windows 10 Pro, nothing makes it work. It takes an average of 16 seconds for each “pass” or “update” of the various indicators and charts.

At this point, replacing our “new” PC with a different new PC seems to be the only way we may get this all to work properly.

Edit to add:

I swiped a different PC from our office, and swapped it in for the one we were using. Unfortunately, it’s very similar to the one we were using. These are all HP Elitedesk systems. What we really need is a completely different PC, I think.

Nonetheless, it was running a different revision of Win 10, and although I did let it update itself, it seems to be working at least as well as our other one did before it updated. This “new” one is now running 10.0.18363.

I’m running Google Earth Pro in the background, and I’ve set all of the exceptions as well as setting windows security to ignore the three directories that hold our OptoDisplay projects, our OptoControl projects, and the one folder I created to hold various log files.

At some point, when the plant is not operating, I’ll try running it without Google Earth Pro running to see if it works properly without it.

Another update:

I wasn’t there, but overnight, Google Earth apparently crashed, and that made Optodisplay stop, as well.

Texting back and forth with the operator at the plant, I had him completely power the PC down, and power back up, at which point he tried to launch Earth, and it would not run, presenting him with an error, and eventually with a menu of things to try to “repair” it. At this point, he had Optodisplay Runtime running, and it was, again, running slowly.

When he finally got Earth to run, Optodisplay suddenly started updating fast again. So running Google Earth concurrently seems to be what is needed to “prod” the system into updating the display at a reasonable pace.

We aren’t getting display freezing but more of a snapshot in time. It is talking to the controllers fine. When we initially launch the display does not update. When we click on a different display it shows full failed state. If we go back to the home display the home display is at default state. When we click back to the previous different display it shows a snap shot in time of the data from that controllers.

Now get this: We have a flashing button when we click it. I can click it but the button doesn’t flash. If we switch to the home display and back the button is gone because it is in the flash off state. If we switch again the button reappears still in the flash state but in the show point. Its like we keep catching it in different points of the flash. All the data for our displays are like this. And the home display never updates to the accurate data.

We are runing PAC Pro 9.6 and can’t upgrade at this time. Controllers are on R9.5

More info here: PAC 9.6 Pro Display Runtime Not Updating

I had the same issue as @tmurray recently when working on a project where my customer is on 9.6. The 9.6 display would no longer update on my dev machine. The 9.6h patch from the ftp site fixed it as described in the linked thread.

Hi all
Long time lurker of this thread. Thanks for all the great help. I’ve had my fair share of Display Runtime gremlins and sluggish performance on several of our Windows 10 PAC systems over the last couple of years and have routinely had to go in and re-apply some of the great fixes mentioned in here regarding Windows Defender, working directory exceptions and exploit protection changes, some of which every now and then revert back to default settings. I’m guessing this occurs when the machines, which are normally run off-line, get a sniff of internet from time to time when certain “helpful” techs unknowingly mess about with network settings in the field and good old Windows Update enters the mix.

Anyway, I’ve stumbled across another culprit for poor Display Runtime performance and that is when more than 1 user is logged into Windows 10 at any one time. Typically our machine-control PCs have had 2 user accounts: 1 admin user for supervisor access and then 1 general purpose user that everybody should be using for day to day interaction with the GUI. I have the systems limited where operators/techs do not have access to the C:<Strategy Location> folder without being logged in as the Admin user to limit unauthorised code tinkering etc. So in times where some tweaking in the field has actually been legit and necessary, the idea was that a supervisor would log in to perform the necessary strategy/PAC Configurator changes then once up and running again would log back into the non-Admin user again and get on with operations. The issue arises when they sometimes have not actually “logged out” to get back to the non-Admin user and also may have inadvertently opened Runtime in both accounts. ie, Windows start menu showing there are 2 users logged in = Poor tag update performance and sluggish control system.

Whilst I don’t fully understand the details of how the back end tag scanner system works for PAC systems and how it interacts with Windows User profiles, I do know that more often than not the best way to make it run nicely again is just to first properly log the users out and explicitly log back in as a single non-Admin user.

The discovery of this has made me a little suspicious that some of the results of the many performance related tweaks have been blurred by the fact we may or may not have had multiple users logged in simultaneously during the troubleshooting exercises without knowing. Now at least I know the first thing I should check if any of our techs complain about sudden drops in system performance.

Has anyone else experience this?

We experienced the same issue like a year ago, this created a mess after we updated a PC from win 7 to 10 and at the end we ended up disabling PAC control so no one mess with the strategy. I did not figured what was the issue at the very same moment but knew was related to having multiple users created.

We are experiencing the same issue on a new Windows 11 machine with version 10.5 of the Pac Display Basic runtime. We have disabled at both the program and system level every exploit protection we can find, have exempted both our project files and the executable files from Windows Defender, and we’ve tried running Google Earth in the background.

Results are still not great. More often than not, tags don’t update without a manual change of window. Sometimes, they do update, but sluggishly. Sometimes (this is least common) everything works the way it is supposed to. This definitely feels like Windows being difficult, as everything runs just fine on our Windows 10 machines.

I have been dealing with this for a long time, and yes, no matter if you take all the suggestions in the tech note from Opto, I had recently caught defender still using a fair amount of resources when have the problems.

One thing I tried recently, is to exclude defender exploits using C:. This prevents the exploit engine from doing anything, I think it works.

Why hasn’t Opto addressed this with Microsoft?