PAC Display Runtime running very slowly - displays freezing

That sounds right to me, too. I did make a much simpler Display project, but running with the same control strategy, and if I recall correctly, it updated faster, but the user interface of PAC Control was still sluggish. I dumped that little project when I reloaded everything on that PC after making some updates, but it would be easy to make something similar.

Also, I have a ton of various SNAP PAC I/O modules, PAC Controllers, etc., around here, so I can easily set up something that would be a LOT easier to set up at your (or Opto’s) end, as well. When I get back in to work, I can set up a system with only a few I/O modules and a smaller strategy just to play with. I have two NICs in this PC, and I can set up this little test system on our main office network. I don’t let the network that our “real” PAC system is on talk directly to the internet, but for the test system, it doesn’t matter, so that will make it really easy to experiment.

Ideally, a small system will show at least some of the symptoms that we’re seeing in the larger one, so it can be reproduced and studied. There are so may uncontrolled variables with an issue like this that it’s almost impossible to isolate the cause on a different setup.

Between Windows, different motherboards and video systems, network differences, and of course, the exact hardware and programs on the PAC end of things, it’s not easy to narrow things down.

If I set up a small system that you can reproduce exactly, and it does show at least some of the symptoms, that will make things more efficient, for sure!

For clarification, you are experiencing sluggish performance and tag update freezing.
I’m experiencing only tag update freezing - performance has been fine. I only get tag update freezing on launch, closing and relaunching eventually works and then everything is normal.

We are both using PAC Display 10.2 (You’re on basic, I’m on pro)
We both have Windows Defender Antivirus exclusions for our supertrend/historical data log folders.
We both are running Win10 Pro build 1903 with all windows updates.
We are both running cpu integrated graphics.
We are both running on solid state storage.

Is this all correct?

That is correct.

I am running an updated version of Display Runtime that Julio pointed me to. It didn’t seem to affect things.

Running Earth Pro at the same time as Display speeds up the operation of Display Runtime. Both the update rate of the tags and the sluggishness of the UI of Display Runtime itself. However, running Earth at the same time does not 100% prevent the occasional freezing of the tag updates on launch. I have to relaunch Display Runtime to try to get it to fire up properly.

Once it launches successfully, then it seems to run fine for days. And it’s acceptably fast as long as I keep Google Earth up and running, even if minimized.

So far, there has been no issues with runtime with the above settings. If we remove the exceptions the issue comes back. Eventually I would like to isolate this down to a specific setting, I’ll test it more the next time I am on site. There are a total of six exceptions setup and I believe this is specific to the latest Win10 build (1903). Another machine with 1809 runs fine, but they are going to update it soon so I’ll see if the issue happens on that machine. It may be a month or so before I can test this out.

I performed the changes to the Exploit protection settings as you’ve described. Indeed, there are six exceptions that I needed to create here as well.

Time will tell if that keeps the program from failing to “update” on launch, because we were not having that problem very often.

However, making those changes did not affect the sluggishness of the UI and the update rate of the tag displays. It still seems to update the various tag displays at about an 8 second interval. However, as usual, if I fire up Google Earth Pro, and let it run minimized, the tag display updates speed up to normal and the UI of the program itself also loses the sluggishness.

Things highlight fast, clicking menu items gets quick response, dragging windows around doesn’t happen in slow jerks (it’s nice and smooth), etc.

So there’s still something going on with this particular PC that seems to be display driver related, and which seems to require the “tickling” provided by having another program up and running.

Odd, indeed! :slight_smile:

The behavior is still the same on this system. It often fails to begin updating on launch, so you just have to close PAC Display Runtime, and then launch it again to get it to begin updating. And you must still have some other program running (even if minimized) for it to ever update on its own.

Once you get it to launch and update, and you have some other program running, it will run fine for days or weeks until the next time you need to launch it, and then you must go through this song and dance again to get it to run.

Had this exact some problem - very slow startup, especially as my supertrends began accumulating data. I was keeping a years worth of data for quite a few supertrends as the customer had requested that. So after a year of accumulation, the startup was taking on the order of 20-30 minutes before the Runtime would begin updating.
After close to a year of battling this, we finally figured out Windows Defender was the culprit. Upon startup Windows wants to scan all the project files that Runtime might be opening - including all supertrend historical data that apparently gets touched by PAC Display Runtime when it first starts. So we made exceptions for not only all Opto 22 program files, but also ALL of the project files as well. Startup is now the snappy result that I expect. I hope this helps.

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.

3 Likes

Thanks again phillip