Leaderboard

I have made public a document detailing an old internal feature of LabVIEW that will be of great interest to those of you deploying Packed Project Libraries. Until recent conversations with a customer, I never considered that this would have much utility. The problem this solves: First, you build a packed project library (PPL) from source. Then, you write a VI that calls that PPL. It works fine. But now you load the caller VI under a different target in your project. The caller VI breaks because it tries to load the PPL, and the PPL refuses because it isn't built for the new target. Packed project libraries are compiled for one and only one specific target. How can you write ONE caller VI that will load DIFFERENT libraries depending upon the target without adding Conditional Disable structure complications? https://forums.ni.com/t5/Community-Documents/Resolution-of-Pseudopaths-in-LabVIEW-Per-Target-Invocation-of/ta-p/4087124

From what we have discussed so far, the Messenger Library certainly seems to be a perfect fit. It'll provide you with the infrastructure to run any number (and type) of workers and communicate with them in a command-like fashion. It is, however, a much more advanced framework than the simple message handler from my examples. As such, it will take more time to learn and use properly. As someone who enjoys the company of technicians who get scared by things like "classes" (not to mention inheritance 🙄), I strongly suggest to evaluate the skill levels of your maintainers before going too deep into advanced topics. If nobody has the skills to maintain the solution, you could just as well do it in C++. Perhaps you can include them in the development process? This will make the transition much easier and they know what is coming for them. If they also do some programming, they have nobody to blame 😉 @drjdpowell already mentioned his videos on YouTube. I really suggest you watch them in order to understand the capabilities of the Messenger Library Here is also a link with more information for the message handler in my examples (sorry no video, +1 for the Messenger Library): http://www.ni.com/tutorial/53391/en/

Remember that you are a User, and you only look at User Interface. When you "open a class" a cluster UI widget is loaded to represent the class data. But that widget is not the actual cluster. When you "open a subVI", the corresponding front panel is loaded with UI widgets to correspond to the block diagram terminals. But for most subVIs, that front panel is never loaded if it is not opened. This is unfortunately counter intuitive, as every subVI has a User Interface (Front Panel) a new programmer will think that is significant, while an experienced LabVIEW programmer will intuitively understand that the front panel of most subVIs doesn't really exist at runtime.

All my applications are developed with a package I wrote several years ago called "Messenger Library": https://labviewwiki.org/wiki/Messenger_Library There are a few YouTube videos linked from that wiki that go through an actual example application. It's motivated by the Actor Model, and so I take inspiration from frameworks like Erlang, Akka or the C++ Actor Framework. The core concept is "messaging" to gain the benefits you list.

You do use the same "normal" controls in the class private data as you would in your GUI. This is 100% ok and you can use whatever you like as they will never be visible at runtime, they are just a visual representation of your data types. What you choose to show on the GUI is totally unrelated to what data you choose to have in the classes.

Didn't not read the full conversation, but thought I'd point out to the OP that it is a common mistake for programmers coming into LabVIEW to mistakenly identify LabVIEW's UI Widgets (Controls/Indicators) as being "variables", and Control References (actually references to the UI widgets) as being "data references". They also confuse the UI Widgets with the data that the Widget is acting as a UI for (which I suspect the OP has done when they talked about having many data copies in using "Arrays" and "Clusters"). Performant data-handling code will not utilize the User Interface at all, and if a "reference" were to be needed, it would probably be a DVR.