If it wasn’t the main page everything would open fine but when I navigated to the screen with the expressions it locked up. It would be visually there but would still have tag overlays and no data would fill in. If my main page was the screen that had the expression everything fully locked up as the client loaded. What nminchin posted though sounds exactly like what I was seeing though. Everyone’s conditions could be different based on what they have in their project and how they set it up. Thats the challenge with any issues like this that are posted. 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.įor you it may not be. 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. Try disabling them if you can and see if you still have the issue. 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). I ended up having to move the expression to regular tags and just pull in the results to the vision screen. 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. This caused the screen to lock up waiting on the expression to complete.
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.
For me I had some bindings that were using the alarm expression functions. I had this issue with one of my customers and figured it out this week.
0 kommentar(er)
