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!