LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Front panel updating

Here's an example of the sort of unintended consequences I was afraid of: I wanted to extend the MVC example here https://forums.ni.com/t5/Example-Code/Model-View-Controller-in-LVOOP/ta-p/3530480 with channel wires, and a helper loop to update the waveform graph.

 

The problem as indicated on the block diagram is that to do anything useful, the message "Execute.VI" methods need access to the state data for the loop they're executed in. So if you want to use helper loops, either ALL messages need ALL state data from ALL loops, or you need a different message type for each loop. What am I missing?

0 Kudos
Message 11 of 12
(237 Views)

MVC is difficult to implement in LabVIEW when using parallel action execution of any kind.  In my applications that use this pattern I create a single "Model" state machine that does everything, and if there's anything that needs to happen in parallel then I stick that all in the one state and manually manage the state data integrity on a per-state basis.  If you need or want to make code that's more modular, then it gets more difficult.

 

Anything that's in the "Model" needs to have write access to the state data, so if you want to have two or more bits of code that can run at the same time that are both in the "Model" sections of your code then you need to have a form of shared write access.  Since LabVIEW doesn't usually use by-reference objects in its OOP implementations, this means that you have to get creative if you need parallel Model operations.

 

If that's the difficulty you're encountering, then you can consider implementing a "Singleton" pattern for your objects, where every object of a certain class may look different on the surface but when using accessors to get to their class data they all internally access just one copy of the object held in a common application-wide location in a way that ensures race conditions cannot occur.  Alternately, if you do need to have multiple different instances of the same object, you could consider making the objects DVRs instead, since when you use the in-place structure on their data it has a built-in locking mechanism to prevent other changes from happening in parallel.

0 Kudos
Message 12 of 12
(227 Views)