PAC Display Runtime running very slowly - displays freezing

PAC Project
1

Hello, All.

I just added a new PC to a system mainly to provide a way to drive a 4K display with PAC Display.

Up till now, I’ve been using an old PC with Win XP on it, and thus limited me as to what version of PAC Project I could run.

This new machine is running Win 10 Pro. It’s a much faster computer than the old XP machine, of course. It’s an Intel Core i5-8500 @ 3.00Ghz
8 GB of RAM
With a 1000GB NVMe PCIe 2280 M.2 SSD as the main “hard drive”.
It seems pretty speedy to me!

To start out, I’ve only got a 1080p monitor connected, but the built-in graphics will run at least one 4K monitor.

To be able to use this new PC with Win 10, I downloaded and installed the latest version of PAC PROJECT Basic. This includes:

PAC Display Configurator Basic
R10.2a Build 0004

PAC Control Basic
Version R10.2a
Build Date: Nov 27, 2018, Time: 12:23:11

I copied my existing PAC Display and PAC Control programs over from the old PC to the new machine.

I updated the firmware on all of the controllers and brains in the system with the exceptions of:

1 SNAP-B-3000ENET, which has R7.1i
1 SNAP-UP1-M64, which has R7.2i

The other controllers and brains in the system are:
1 SNAP-PAC-R2 which now has R10.0f (this is the main controller for the system)
3 G4EB2s which are also now running R10.0f

I loaded the existing PAC Control program into this new version of PAC Control, and then re-saved it. I didn’t change anything in the program. I compiled it and uploaded it to the main controller (the R2), and all went well. The system seems to run fine, just as it has been.

I loaded the existing PAC Display program into the new version of PAC Display, saved it, and am now executing the “new” runtime.

All of this works, but strangely, the version running on the new PC is very sluggish. Mouse clicks to bring up different windows are slow to respond. Even the highlighting of selections as I move the cursor over them takes several seconds.

Upon initially starting the runtime up, the windows draw slowly, taking perhaps 15 seconds to draw and populate with data.

And while I have a number of trends set to update at 1 second intervals, they respond much more slowly. I also have the real time clock data, read from the controller, displayed on several windows, and it updates at between 6 and 8 second intervals, skipping the times between.

I am also running my old version of the PAC Display runtime on the original old, slow XP machine, and it still updates every second, and responds smoothly and quickly to mouse clicks in the pull-down menus, and on buttons and controls in the MMI itself.

Shutting off the PAC Display on the old XP machine doesn’t improve the response of PAC Display running on the new PC. And other operations and programs running on the new PC run fast and smooth even while the MMI is up and running (sluggishly).

I figure there’s some new feature or setting in this years-newer version of PAC Project that I need to set up correctly, but I’m not sure what it would be.

I always appreciate everyone’s time to answer questions on here. So thanks in advance for any helpful suggestions.

Jim

1 Like
2

OK, I rebooted the PC in question, and now, with only the PAC Display Runtime running, it doesn’t update any of the windows at all…

UNLESS you do something to make it redraw the window. For example, clicking the “restore down” and then “restore” button for the entire program, so that the system has to redraw that window, causes the windows within the program window to be updated.

Additionally, it appears that the program is actually executing behind the scenes and capturing the new data at a reasonable pace because the trends and supertrends, when redrawn, show the missing data logged (graphed) correctly filled in with no missing data points.

So it seems as though PAC Display Runtime simply does not cause a refresh or redraw to the video system in this PC. I’m wondering if this might be an incompatibility with the video drivers in this particular computer. The mouse cursor moves smoothly over the windows, but things that should highlight as the “mouseover” events should be happening do NOT highlight in a timely fashion.

As an example: I move the mouse cursor up to one of the drop down menu items along the top left of the main window for PAC Display Runtime (File, View, Alarm, etc.). Normally the menu name that the mouse cursor moves over immediately highlights to indicate that the program knows where the mouse is.

But in this case, there is a noticeable lag time before the “hovered over” item highlights. And if I click on one of these items to open its drop down menu, that takes quite some time, as well. And once the menu drops down, as I move the cursor over the items within that menu, they, too, take a long time to become highlighted. And their response to being clicked is also very “laggy”.

It’s as if the program was working very very hard at something in the background, and thus taking a long time to respond. But when I check with Task Manager, PAC Display Runtime is using very little CPU time, usually showing as 0%. Further, nothing else is using much CPU time, with the total CPU time being at or below 3% at all times. The same goes for the GPU as well, Almost no usage.

Moving a window (within PAC Display Runtime) to the top causes it to redraw. Moving the entire PAC Display Runtime window to the top (when other program windows are running on the desktop) does NOT cause a refresh of the PAC Display Runtime’s windows. So using the Windows task bar to bring different programs to the top does not cause PAC Display Runtime to refresh its displays.

Thanks

3

Speaking with Opto’s tech support, it seems that there is no problem with either our PAC Display project or PAC Control Strategy with respect to the new versions of the Opto 22 software.

It all runs fast and fine on their test setup and PC.

One possibility is that this is an incompatibility between the Opto 22 PAC Display Runtime software and our particular PC’s display system or driver. Rolling the video driver back to the previous version didn’t help.

But here’s something both amusing and potentially diagnostic:

Because this fancy new system is fast and has a 55" 4K TV as one of it’s two monitors, and I was annoyed with the slow performance I was having with my old desk PC while trying to run Google Earth with a KMZ file with topo maps for the entire earth linked to it, I decided that I should install Google Earth and that KMZ link on this new system.

It’s really great to have a faster PC and a huge display for that! Handy and productive.

But the amusing and interesting part of this boring story is that with Google Earth running on this PC, even if it’s minimized, the Opto PAC Display Runtime now runs correctly. It’s pretty fast, responsive, and the draw windows all update quickly. This makes the new system entirely satisfactory.

So I’ve just been leaving Google Earth running, but minimized, and everything is dandy.

Checking with Task Manager, when I have Earth running, Display Runtime now uses around 4% of the CPU time (as opposed to zero without Earth running). And that makes sense, because it SHOULD be using some clock cycles with all of the polling and updating of various trends, indicators and text from the PAC Controller that it SHOULD be doing.

Meanwhile, the minimized Earth uses around zero.

So something about having Earth running is either stimulating the display driver to “refresh” at a more reasonable rate, or it’s overcoming some power-saving CPU-slowing thing and letting the system rev up and run like it should.

It’s odd, but true.

I see that my posts have had quite a few “reads”, but zero responses. Either I’m boring everyone, or nobody has seen this and doesn’t have any suggestions.

Either way, I thought everyone might at least be amused by this update.

4

I think your probably have an edge case that no one else on the forums has ran into so there is nothing we can add. Thanks for keeping us updated - it is an interesting finding and hopefully will help narrow down the issue.

5

Suprise! I just ran into this exact issue with a customer. It is very strange. We can close and relaunch PAC Display and it will either work fine, or stop refreshing after about a minute of running. Seems to be a 50/50 chance on launch. This is on 10.2a. I’ll call PSG and let them know.

6

I had an issue where the runtime would stop displaying information from the strategy. It never did freeze or anything like that, but all we would see is the # where values should have been.

Our solution was windows update. Not sure if this can help any of you, but I thought I would throw it out there.

7

I suspect it is some interaction with the PAC Display and hardware/drivers. Unfortunately, this system is on the latest Win10 build 1903 and has all the updates.

8

The same is true for my system. Latest everything from Microsoft and Opto.

It sounds odd, but for no more trouble than it is, install Google Earth Pro, fire it up, minimize it and see if PAC Display Runtime then works reliably on your various systems.

If it fixes things the same way it does for my system, that’s good evidence… of something. If not, that’s good data for us, too.

By the way: Julio Jimenez was the engineer I was talking with at Opto about this. He would probably like to be in the loop on this.

It really does seem like a display driver interaction issue OR a power saving thing.

I tried updating the display driver on my PC, and Widows says it’s already the latest and best driver. I also did roll the driver back, and while that then prevented the system from seeing the second monitor, it also did not change the unwanted behavior of Opto Display Runtime. So I updated back to the latest again, and that’s when I stumbled upon the Google Earth “fix”.

The PC I see this in is an HP EliteDesk with Intel UHD 630 graphics on the motherboard, no fancy separate graphics card.

9

Not sure if you are logging any data locally from a trend or event log. If so please add an exception to Windows defender for the FOLDER your files are written too. This issue has caused me many problems:
Unfortunately the KB article ws just recently posted:
https://www.opto22.com/support/resources-tools/knowledgebase/kb87591

Windows Defender tried to scan all the files in any folder that Opto Display uses. This can make the system very slow.

10

@Sigmo If your are storing data from super trends you really need to try the fix above. I think it will solve the issue. I have had a ticket open on this since December .

11

@ Norm_Freeman1 I am storing data from a number of supertrends. It can’t possibly hurt to make sure Windows Defender has an exception for the folders where these files are stored. I’ll give it a try. Thanks

12

There was already an exception for the project folder for Windows Defender Scanning. What did change that we had set before was Windows Data Execution Protection. Typically we put an exception for this for PAC Display to prevent random crashing. It looks like this is in a different location now in newer releases of Win10 (we disabled it, but still had the issue).

There are also some other ‘Exploit Protection Settings’ that can be turned off in that section, so I made an exception for PAC Display runtime and turned off everything that was on by default. I just did that, and the issue hasn’t reproduced itself yet, but we will continue to test over the next few days.

Windows Security
App & Browser Control
Exploit Protection Settings
Program Settings
Add an exception for program name DisplayR.pro.exe
Set overide to off on all settings that are normally on

13

Yes, working with Julio. This project has a dozen strategies associated with it though, so he can’t really setup a test environment for this project.

I checked the display driver - Just Intel HD Graphics 20.19.15.4835 from 2017 or something like that (HD Graphics 4400), so this hasn’t changed.

14

By that, do you mean a dozen separate customers’ strategies, or are you referring to the many charts in my particular strategy? I can make a simple system and simple strategy and connect it to the “problem PC” at our location and see if it runs into the same issues, and send that control strategy and the associated display project if that might be of some help.

It would be interesting to see if a much simpler system runs OK on the new PC here, anyhow.

By the way, I have now had one occasion where the PAC Display Runtime came up slowly and would not update its displays at all, again, even though I had Google Earth running in the background. I had to restart the project to get it to run.

But without Google Earth running minimized, I still always observe the effect where the Display Strategy updates very slowly (perhaps once every 8 to 10 seconds) instead of almost every second with Earth running. So that’s remained constant.

I did set up exceptions for the directories where our supertrends are saving their logged data, and that doesn’t seem to have changed anything.

I have not played with the other ‘Exploit Protection Settings’ . I can try that when I am back at work on Wednesday. For now, we’re using the system with no problems (once you get it up and running successfully) with Earth running minimized.

I have not tried using any other programs running in the background to see if they affect the scanning speed the way Earth does for us.

15

Neither, it is one PAC Display project that is pulling data from several controllers/strategies.

Yeah, it would be interesting if a simpler project did the same thing. I haven’t tested that, but I wouldn’t be surprised if it works okay. I think it is a combination of the size of the project, the particular system and the windows version/settings.

16

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!

17

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?

18

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.

19

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.

20

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: