I’ve noticed this for a while, that whenever I connect remotely to a client’s network via a VPN, if I try to launch a client through the VPN, the client will freeze. It will launch the Windows, but will inevitably crash (frozen client screen, mouse clicks don’t register etc.) and the intial launch windows will load graphics but screen will freeze with tag overlays still on components. I cannot close the client by clicking close, I have to kill it via Task Manager.
The only way I can launch a client is by remote desktopping into a machin onsite (usually the gateway server itself).
I’d like to understand the reason for this, and if I can resolve this somehow? Is there a guide to building projects with client performance efficiency in mind?
Edit: Only seems to happen on Windows with a moderate to large number of component tag bindings
I’ve seen similar symptoms on occasion on clients on LAN as well as VPN over satellite. But they wouldn’t freeze immediately; they’d eventually (hours) freeze and have to be put out of their misery via Task Manager. That said, I’ve had a couple clients connected via VPN over satellite for over a week steady with no issues (a few hundred tags each). In this case the clients are on Windows 7 and servers are Windows 7 and Windows 10. All are running Ignition 7.9.13. I haven’t seen the issue on 7.9.13, though we’ve only been running it since December 9 release.
I’m not sure these will help, but setting deadbands on tags so insignificant updates are not forwarded to clients reduces the load a bit. If clients (or designers) are flogging their log files–for example, a designer opened in debug mode–, freezing up can happen pretty quick.
Hi Nick… I am experiencing the same issue on 7.9.12. This is also a remote connection via VPN. Version 7.9.9 ran clients without issue over this connection, but after upgrade to 7.9.12 the freezing, hanging, inability-to-close issues began. Launching from the designer (in either staged or published mode) is where I run into the problem, but I am able to mitigate the issue by opening a client from the native client launcher and unchecking the use bundled JRE option. Although not a fix, it is a decent workaround.
I had this issue with one of my customers and figured it out this week. For me I had some bindings that were using the alarm expression functions. I did end up on the phone with support and the best we could come up with is that the client refresh rate was faster than the expression was getting the results. This caused the screen to lock up waiting on the expression to complete. Our best guess was that the connection speed when connected to the local network was fast enough to prevent the issue from being seen but the connection over VPN caused just enough lag to cause the issue to appear. I ended up having to move the expression to regular tags and just pull in the results to the vision screen.
I’d look at what you have running on the screen that is up when it locks up to see if there are any bindings that may take longer to perform(ie… sql queries or alarm expressions). Try disabling them if you can and see if you still have the issue. For me to find it, I removed different sections of the screen until I limited down the area causing it to lock up and kept drilling in until I found the expression that caused it. From VPN though it would even lock up the screen on my designer so I had to switch back and forth between VPN and a local connection to find the issue.
However, in this case, the remote connection worked without issue when on v7.9.9, but immediately showed up after upgrade to v7.9.12. Also, it seems that if an expression were just waiting to complete, then it would be a relatively short lockup and not the total freeze seen. Plus, opening the client without the embedded JRE causes my issues to resolve, so I would assume an expression or query would not be the culprit.
For you it may not be. Thats the challenge with any issues like this that are posted. Everyone’s conditions could be different based on what they have in their project and how they set it up. What nminchin posted though sounds exactly like what I was seeing though. If my main page was the screen that had the expression everything fully locked up as the client loaded. It would be visually there but would still have tag overlays and no data would fill in. If it wasn’t the main page everything would open fine but when I navigated to the screen with the expressions it locked up.
I also agree with you that I would expect the expressions to give a relatively short lock up but thats not what it did. It may of been because of the type of expression since it was using the alarm functions but I don’t know for sure. When support looked through what was going on they could see that it was waiting on the alarm expression to complete but it was never completing. He mentioned a 250ms refresh rate on the vision client and though it was basically getting into an unending loop where it would attempt to run the alarm expression function but before it received the results it would be called to run it again causing everything to freeze up waiting. While I was troubleshooting it I was able to switch back and forth between a VPN connection and a local connection easily. When it was locked up if I switch back to the local connection the vision client would very quickly continue loading which showed it was just stuck waiting for something to complete that wasn’t allowed to complete over VPN. I don’t remember if it was a thread dump or if it was the client diagnostics but one of them also pointed to the hold up was the alarm expression.
Everybody’s issues could be different but I wanted to share what I experienced and what was found to be the culprit.
I should have come back to this, but I found the issue in my situation. It was due to using far too many runScript calls within components that ran the system.alarm.queryStatus function to check for active alarms. This completely killed the remote clients, and was also causing slow performance on the local clients as well. Seems pretty obvious now…
If you have GUI stalls when bandwidth between client and gateway is poor, it means you have used poor design in your application. Specifically, you have gateway calls running on the foreground thread. This is most commonly caused by the use of tag, database, or alarm scripting functions within runScript() bindings and/or event routines.
Use tag bindings (not the tag() function) instead of system.tag.* scripting, use Query Bindings (preferably named queries) instead of system.db.* scripting, et cetera. Anything that you must use a script to generate needs to be moved into a background thread (system.util.runAsynchronous) with proper handoff of results. (Lots of topics here on that.)