Vision client locking up

We have one of our Ignition Vision clients locking up about once a day. The operators keep notifying us that it happens, but there does not seem to be any evidence that it happens. The lockup just happened a few minutes ago, and seemed to be locked up for some time. Unfortunately I did not have much time to troubleshoot, so I just rebooted the terminal.

During the lockup, I did not see the message that shows when the client loses connection to the gateway. Originally I thought it might be a network issue. Now I am not sure.

Anyone have any ideas why the client would lock up for several minutes? I don't hing we ever messed with the client memory allocation. Would not having enough client memory cause this?

By locking up, I mean it was not updating values, and we could not navigate to another screen. The button would indicate that it was pressed, but did not change screens.

It is most likely a long running/blocking script running on the EDT (event dispatch thread, or the thread that renders the interface). The client running out of memory would give you a specific out of memory error.

Try to see if you can narrow the timing down to something specific, like a form being entered or operators performing an interaction.

There should also be a 'non responsive EDT' dump in the log files on the client device if it was due to a blocking script on the EDT. Also, it's probably a good idea to check the logs anyways.

3 Likes

When looking through the gateway status screen for that client, there are no log entries, however, I am not sure if that needs to be set up to display client logs. I will look for the logs on the client machine when I get the chance.

The non-responsive EDT logs only show in the client machine's filesystem, one file per event.

3 Likes

Got some more info the second time around. There was a script error that was not reported to us. Saw the error the second time. Turns out someone messed up the tag that the button was trying to set.

We have been getting brief lockups (stale screen data) for awhile, but have not been able to track that down. Still have not looked at the log files. I will be doing that here in a bit. However, we are thinking that PLC edits may be the culprit now.

Logix? IA's driver does stall on PLC changes if automatic rebrowsing is enabled, particularly on large projects.

(My alternate driver uses a different algorithm to avoid similar stalls.)

We turned off browsing, was reluctant to do that since we are still adding tags, but the operators were getting frustrated. Will see how that goes.

Is your alternate driver available to try out? If I remember correctly, you were also trying to make the driver work mor efficiently as well.

All of my non-free modules honor Ignition's two-hour trial mode.

For logix, you would simply disable and rename the existing logix driver, then create an instance of my client driver using the original name. Your tags pointing at that name will just start working with my driver.

You can flip back and forth fairly quickly with disable/rename/rename/enable sequences.

Here is a stupid question, now that I have disabled discovery on the CLX driver, how do I force a refresh? I know it say it will reloads tags on connect/disconnect, and there used to be a tag db refresh on the connection (i think) I do not see a reconnect button. Not sure if an enable/reenable will work.

Simply edit the device and save with no changes. You can also use system.device.restart(...).

Thank you! Feel like their should be a button for that