I am using PAC Display’s window pop feature to change a window in the event of an alarm sent by the PAC Controller. I’ve set up the window pop to trigger on change of discrete state from 0 to 1 for a bit on an integer. When an alarm condition occurs, the bit is set for 1 second and then cleared by the PAC Control software. I’m finding that in some cases, the PAC Display software misses the 1 second trigger and does not pop the window. I see the pop window bit being set by the debugger’s Watch in PAC Control, so I know that the Controller is doing what it is supposed to do.
To guarantee Window Pop triggering, I believe that the better way to code would be to set the bit and wait for the PAC Display software to tell the PAC Controller that it has completed changing the window, but I don’t see this feedback feature of PAC Display. Is there a way that the PAC Display software can modify a variable upon launching a window, such as a window pop event, that the controller can subsequently read to know that the trigger was received?
Thanks for your quick response. I gave it a try and it seems to work nicely. I’ll do some more testing with it and see if it catches the window pop every time. I guess the only case where it might not catch the trigger would be if the display software gets the alarm and clears the window pop trigger before the window pop is initiated (asynchronous alarm clear with window pop). Not sure that this is even possible, depending on the lower-level PAC Display software architecture.
I can confirm that using the Display Software’s alarm clearing feature does NOT guarantee window pop every time. There were a handful of instances where the window pop flag was cleared by the alarm handling of the Display Software before the window got a chance to pop.
My question remains: Is there any way to have the Display Software acknowledge that the window has popped so that I can use this action to clear the window pop flag? Or is there any way that I can prioritize the window pop over anything else that the Display Software is doing? Or is there anything I can do to make the Window Pop react faster?
I took some time to ponder this and implemented a solution based off of your idea of clearing the pop window flag when the popped window is closed by the user. This seems to be our best bet, as it does flow with our UI design and typical use cases. It also provides the display software sufficient time to detect the pop flag and pop the window (essentially infinite time until the user closes the window). We’ll go with this solution for now and do some extensive testing to ensure that this works all of the time.
I’m still surprised that there is no “window state change” or “window open” event that the display software can use to clear the pop flag to prep for the next window pop event. Most GUI languages have something like this.
Anyway, thanks for your help, Philip. I appreciate it.
