We have an Ignition system running v8.1.4 with a Perspective client running in a Firefox window in Kiosk mode on a keyboardless, touch screen running Windows 10.
The system runs fine most of the time, however, something is happening that is causing the Perspective application to not work 100%. The symptoms vary but include at least one of the following in each instance:
buttons that normally cause a popup to be displayed won’t work
page navigation doesn’t work
objects showing bad comms even though server is not online i.e. it is not coming back online
In each instance, if I remote in to the PC and close Firefox and relaunch, everything comes good.
I’ve just gone through and added logging to all the buttons that I’ve observed not working, so at least I should be able to see via the Gateway logging whether the buttons are executing (perhaps).
An example of the script associated with a button that stops working is shown in pics below:
I suspect that the issues occur when there’s some sort of interruption to the comms between the IPC running the Perspective application and the Ignition Gateway. This is hard to determine, and I am working to work out a way to determine if that is happening.
I’m fairly new to Ignition and am taking over support for this system from an engineer who’s leaving. It is hard to tell how long these problems have been occurring. No real changes have been made for some time so they could have been happening for a while. We don’t always get feedback of issues until we find out that the operators have been cycling power to the entire board just to get the IPC to reboot.
I thought I’d post this to see if anyone can suggest anything. I guess my questions would be:
Has anyone seen these type of issues before and if so, how’d they get around them?
Does anyone have any suggestions for how I could add something like a button to close the browser / respawn the Perspective page? i.e. I’d like to give the operators a means to recover, other than turning it - the whole board - off and on.
Is Firefox a good browser to use? I’ve heard that more recent Perspective releases have their own Browser - is this any better? (I am trying to find out if the site paid for support so I could upgrade to latest anyway in hopes fixes issues).
Any suggestions as to how I could determine if the Perspective session is losing its connection to the Gateway? I’ve had a bit of a poke around the Gateway status but haven’t found anything just yet.
Hi, Thanks for your response. I don’t know why the onActionPerformed event was used - good pickup and thanks for looking at the pics! - I will see if that is used on all the objects. I might make another page or add some extra buttons to the Overview where instead of onActionPerformed we try and do the same thing with onClick. No doubt the problem will occur again, so I might be able to determine if there’s a difference in this situation. Thanks again - I shall report back if I find anything. Cheers
While I can’t explain the issues you’re seeing, there are several concerns I have just from what I’ve seen in the supplied code:
That onActionPerformed script is more complicated than it needs to be.
If you’re putting in logging in order to capture failures, you should do that logging BEFORE you execute any code which could fail.
I don’t know the full use-case behind tracking ids of open popups, but I can tell you I haven’t heard of a good use-case yet.
To refresh the Perspective Page, you could always invoke system.perspective.refresh() (docs)
We have every expectation that Perspective should function 100% on Firefox, though we do recommend always using a reasonably recent version. We only test back so many releases, so if you’re on a very old version there is the potential it could be a problem - however unlikely.
For determining the connection status, you would need access to either the browser in use by the session, or you could use the Gateway to check the session based off of the Session’s ID. If you only have access to the “running” session but not the browser in use then a disconnection banner should be present across the top of the session. The absence of that banner should mean everything is fine.
Just as an aside. One good reason to use actionPerformed instead of onClick, if you use one shot buttons and you require confirmation, if you use an OnClick event the script will run without the confirmation being pressed. OnActionPerformed is requires the user to confirm the action first if you want it to.
There are multiple reasons to use onActionPerformed over onClick:
only executes on confirmation for components which might require confirmation.
only executes if component is also enabled, whereas onClick will execute even if the component is disabled.
I think there might also be some differences in how some mobile devices register events, and so onClick might not work on mobile device “X”, because you’re actually getting an onTouch event. Regardless of which event triggers the button, the onActionPerformed event will execute.
Thanks for your response. Some comments in response to your comments:
Not sure which aspect you’re referring to regarding complexity. If you can let us know what aspect(s) you’re referring to that might help. The behaviour that was wanted for the popups was to be able to pass in the equipment ID and have that parameterise standard popups for that equipment type. Apart from this issue we’re having it seems to work OK.
Yeah you’re right - I whacked that logging statement in as a first attempt at determining if this event was firing. I will add one prior to the .openPopup call.
From talking to the engineer who developed the project a while ago, my understanding of the reason for tracking the ids of open popups was to assist in closing the popups when navigating to a different page. This project was developed a few years ago, and I recall at the time he was having some issue with closing what were like child windows of the page and / or popups. Maybe there’s a better way now or even then. I haven’t looked too hard at that, except to check that it wasn’t involved in preventing the popups being displayed. Your comment re disabled objects still receiving clicks makes me think that that could have been the reason - at that time - that he went with the onActionPerformed button.
I had a look at the refresh function. I’ll add a button to do that to the main page. If it works for the operators to recover that would be great. I think when I Teamviewered in, I may have tried pressing F5, but definitely navigated to other pages etc. From reading that help, sounds like it would make a completely new connection to the server which would probably do the trick.
I am pretty sure I updated Firefox to latest shortly after the first time this happened, but I will confirm.
OK - yeah I haven’t seen the banner when these problems are happening. At least on the last time, when I was called, it was connected, and data on the pages was changing, but the popups weren’t popping. My theory was that possibly there was some connection issue at some point and that’s when it partially broke. Just a theory.
Thanks again for your response. I’ll add that Refresh button and let the operators know to try that next time. I’d obviously still like to resolve whatever is going on, but at least if there’s a workaround will save a bit of time / might help resolve.
