PAC Display stuck at "attempting to connect to IO scanners"

Hello,

So I’m having trouble getting PAC display to start up on a particular computer. It is a Windows 10 computer. PAC Display configurator version is 10.3b. So what happens is that we usually have the Runtime in a start up folder so when the computer starts up, it just starts the runtime. However it gets stuck. None of the information loads, but it doesn’t turn everything red as if the display can’t communicate with the controller. So I’ve tried restarting the computer, going into the task manager, stopping the runtime and starting it again using the configurator but I don’t get far. When I try to do that, it gets stuck at “attempting to connect to IO scanner.” I can ping the controller it’s trying to connect to so it’s not a networking issue. Let me know if someone has an idea.

Freddie,
Does your PAC Display project open properly by executing the *.UUI file?
We do something very similar to your approach. We are also running Windows 10 touchscreen pc’s. Basically we create a shortcut of the ‘yyy.UUI’ file from our \Display folder. We also add a 10 second delay before it executes the opening of the 'yyy.UUI file. This tends to give time for other processes to open.
We copy this shortcut, once it is verified that it opens PAC Display without errors, to the ‘shell:startup’ folder. This is accessed by clicking the Windows ‘Start’ symbol in the lower left corner of the Task Bar, type in ‘Run’, enter ‘shell:startup’ in the ‘Open’ field. Paste in your shortcut. Close all programs, shutdown the pc, power back up. Does PAC Display open?
We have had success with this approach, am not sure of your ‘IO Scanner’ portion, that may have to do with something in PAC Display itself.

Example of the ‘Target’ path in the shortcut properties:
“C:\Program Files (x86)\Opto22\PAC Project 9.0\DisplayR.pro.exe” C:\xxxxx\Display\yyyy.UUI 10
[ xxxxx = user folder, if used ] [ yyyy = name of your PAC Display project ]

Example of the ‘shell:startup’ path from using the ‘Run’ command:
C:\Users\zzzzz\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
[ zzzzz = folder of the current user account ]

We just figured it out, turns out we had to restart the controller… we’ve had to do this in the past so I don’t know if the controller needs replacing. We put our runtime in the common startup folder, so when the computer boots up it just runs. This normally works well in many places, for some reason in this particular place we just have this issue.

Sounds Good, we use ‘common startup’ on some pcs as well.
Glad it was a simple solution.
Dave

Before replacing the controller, check the power supply and make sure it is doing what it is supposed to be doing.

This sort of thing always rises an orange caution flag for me… If an application cant connect and restarting the controller gets it connected again, I always wonder if there is a bit of strategy code that is not handling comm errors or time outs correctly.
In other words, all the controllers connections are busy or locked and so it cant accept any new connections. Rebooting clears all those and away you go again.

(And of course what @philip said).