Multiple monitors, duplicate user interfaces

[David-A]

---

@mikeporter wrote:

The only question would be whether the same VI can be in multiple subpanels simultaneously?

---

I just tested it, and it looks like the answer is no, so my idea doesn't work quite as well as I thought it did. Assuming the VIs on all monitors exist within the same application space, a duplicate VI would need to be created for the sub panel, which is what I imagine James is trying to avoid to begin with. Set the reentrant flag on the Open Vi Reference and you're fine.

James, regarding the QMH, you can usually safely write from multiple locations so long as you are only reading from one. Creating a startup and shutdown procedure that ensures no messages are dropped is tougher than it sounds when working with more than a single writer/reader. You may consider taking a look at the Actor Framework, though that may be overkill if you only have two or three processes you need to manage.

[James.M]

Thanks everybody, it looks like I have my solution! I will make the user interface VI's reentrant and duplicate them in to subpanels for Monitor 4. They communicate using a QMH architecture, so they should operate the rest of the application the same way without a problem.

The only pitfall I'm not sure how to avoid is the simultaneous access to a control. I will need to have each duplicate interface communicate with each other, so when one is changed, the other is updated to match. The only way I see of doing this is using a global variable. The global variable would be written to upon every value change and read from on timeout. If the timeout read differs from the controls' current values, the values are updated to match the global. This has horrible race-condition problems, but it is acceptable to tell my user not to touch both monitors at once.

[johnsold]

James,

Would your user accept a "Monitor in Charge" control/indicator? The user would push that button to acquire a semaphore and simultaneously set an indicator on the other panels showing that they did not have control. The semaphore could be released by pressing the button again or by a timeout after a certain period of inactivity. Pressing the button on the other monitor would display a request for release of control on the monitor in charge. This would be the one control and indicator which would not be mirrored between the monitors.

The semaphore should prevent the race conditions and the indicator would let the other user know what was going on. The ability to request control  might help minimize fights between users at the different monitors.

It does not seem that this would be too complicated to implement and might make a better user experience than random race conditions.

Lynn

[James.M]

Lynn,

The application is a high-risk environment. If something goes wrong, a million dollar device could be ruined, or explode for that matter. There are many e-stops around, but even so, any amount of time where the client has been relieved of control is no good. They need to feel that they are in control at all times.

I think what I'll end up doing is this:

For each duplicate user interface, there will be a different communications queue.

I will create an array of references to these queues and send new data to each queue in the array.

If one of the user interfaces generates its own new data (a user changes a value) it will send that new data to the other queues in the array other than its own.

This will still have a race condition, but at least there will never be any lost data, just overwriting data.

[johnsold]

Good luck.  Not with the programming, but with the client.

That setup sounds like a recipe for disaster.  Make sure the client understands that competing inputs can be generated and that it is not your fault if the users blow something up.

Lynn

[James.M]

Haha thanks. One of the safety precautions is a limitation on the rate at which certain controls can change. That helps with the risk of a valve being rapidly opened, or something similar that could cause a rapid failure. Either way I will definitely make sure the user knows competing inputs can be generated. Both monitors are within eyesight of each other (through a safety window), so hopefully the techs can figure out why the control they keep tapping on is getting reset 😉