LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Front panel updating

Wondering if there are best-practices for updating the front panel in an OO message-passing application. The front panel updater will likely be a separate thread, but I'm not sure if the indicators should be updated individually upon reception of an "update" message, or if all indicators should be owned by a "GUI" object that is passed around as a message, and each thread adds its own data to it.

0 Kudos
Message 1 of 12
(1,044 Views)

You probably need to add significantly more detail than that.

0 Kudos
Message 2 of 12
(1,026 Views)

You might consider it to be part of a model-view-controller architecture, with what you are talking about being the "view".

 

There are plenty of web-based references to that architecture that do not specifically mention LabVIEW.  If you have an active SSP you should be able to watch this LabVIEW-specific one from the Center of Excellence:

 

https://education.ni.com/center-of-excellence/resources/1162/improve-your-qmh-with-principles-from-t...

 

Basically, instead of thinking of it as something that sends a message saying "please update this indicator", think of the front panel as being something that gets messages containing ALL changes to program state, relevant to the front panel or not, and then in that code module it decides what to show.

 

As a general note for best practices, whether you use this model or not, keep in mind that writing directly to an indicator terminal is as close to instantaneous as LabVIEW can get, writing to a local variable is not that fast but still pretty fast, but writing to a property node for a front panel control (value or otherwise) can be dreadfully slow (relatively on a computing level, not a human level...) because it waits for the UI thread to do a full refresh (usually 1/60th of a second or so).  So you will want to minimize use of property nodes, and if you ever do need to use them in bulk, use the "Defer updates" property of the front panel to do them all at once instead of one at a time.

0 Kudos
Message 3 of 12
(1,000 Views)

Thanks, that's helpful. Do you know if there's code to go along with this presentation?

0 Kudos
Message 4 of 12
(931 Views)

@jfalesi wrote:

Thanks, that's helpful. Do you know if there's code to go along with this presentation?


I don't think so, but did you notice that the "download" button downloads the powerpoint slides?  Might help if the video is blurry in places.

0 Kudos
Message 5 of 12
(926 Views)

The presentation is clear but I'm struggling with the architecture. For example, are the model, view and controller three different loops? I understand that the model (business logic) can be separated from the controls and indicators, but do the controls and indicators go in the same loop? If not, are there different tabs or subpanels for controller and view? Or can they be intermingled on the same panel? In other words, where do the controls and indicators live? I'm down with event handlers and message-passing between loops using queues/QMH/channel wires, but I always have trouble deciding who should live where.

0 Kudos
Message 6 of 12
(835 Views)

The presentation is clear but I'm struggling with the architecture. For example, are the model, view and controller three different loops? I understand that the model (business logic) can be separated from the controls and indicators, but do the controls and indicators go in the same loop? If not, are there different tabs or subpanels for controller and view? Or can they be intermingled on the same panel? In other words, where do the controls and indicators live? I'm down with event handlers and message-passing between loops using queues/QMH/channel wires, but I always have trouble deciding who should live where.

0 Kudos
Message 7 of 12
(888 Views)

A related question is, in the "view" loop (which I'm assuming is where all the indicators are updated), if you're using an OO message design, each message's "do" VI would just update the indicators that are part of the message. So, should the "do" VI take the entire indicator cluster as an input, replace the data in question, and then output the entire cluster? Is there an existing OO message passing framework template? I've seen the message handler/state machine examples that use queues, but I discovered channel wires and I'm never going back... can class objects be passed over channel wires?

0 Kudos
Message 8 of 12
(864 Views)

I don't know of an existing framework that implements this exactly.  The closest one is probably the MQTT broker except that it runs over TCP/IP instead of typical LabVIEW messaging, which is a bonus if you want to have several applications using it all simultaneously but also not as fast if it's just for one standalone code module.  It could be there's another framework that's closer.  MQTT uses a publish/subscribe message pattern, so your main Model code would publish everything in State data and subscribe to Controller commands, your Views would be subscription only to just the parts of the Model's state that they care about, and the Controller would publish commands and subscribe to nothing.

 

I think that for something like this architecture in LabVIEW it really depends on how big and how often what would be defined as "state data" updates as to how complex you get.  The bigger the amount of things in state data and the more they update, the more complex the architecture gets to ensure you're not rerunning the same code hundreds of times in a row that either apply the same visual changes over and over, uselessly changing nothing, and not changing your states 1000 times a second so that the View tries to update faster than a human can register.

0 Kudos
Message 9 of 12
(858 Views)

Model: essentially an abstract parent class of view. 

 

View: a Model implementation of a specific front panel.

 

Controller: dynamically dispatches View update methods

 

Ideally,  the Model will launch the View specific UI. And have a DO(nothing) method. The View specific init would return a ref to its data and FP. The controller should A) update the View private data and B) periodically push the View Private Data to the View UI at human eyeball speed.

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 12
(841 Views)