Organising parallel while loops

[Mylonit]

In my company, a typical LV application will consist of several parallel while loops running in the same VI. Each loop has a specific function e.g. DAQ, state machine, logging data, user interface etc. SubVIs are used but only for calculations inside while loops.

For large applications, it's tedious having to use the scroll bars to navigate the VI and it can get messy. I appreciate the general advice will be to use subVIs to organise the code, but as a novice I'm not sure how best to pass data between them. One advantage of the current layout is that it's so easy to use local variables to read and write to variables in different loops. What's the more professional way of doing it? Would be grateful for any examples.

[altenbach]

As someone said long ago:

"If your LabVIEW problem can be solved by getting a bigger monitor, the problem is elsewhere."

Sounds like a nightmare. Clearly, you identified the shortcomings of the current design, so that's a great first step. Generally, local variables are a poor choice to shuffle data between loops because of the dangers of race conditions. There are plenty of ways to pass data (locals, channel wires, queues, notifiers, action engines, etc. etc.) and the choice depends on many factors.

What is your function? Maintaining existing code ( (patching, fix bugs, add minor features) or create new applications? Does the current code work well? If so, I would not mess with it, especially as a novice. Too many landmines! Are there other programmers? Does the company have design guidelines?

Sorry, your question is way too generic to give specific advice. Hopefully some other ca chime in....

[Bob_Schor]

My advice would be to open Word (or whatever you use for Documentation) and "Write (some) Documentation First".  Specifically, think about what you want your LabVIEW program to do, and largely ignore (for now) the "How am I going to do that?".  When you look at the "what" from a distance, you can often see patterns that suggest design strategies.  Are you "controlling a process"?  "Doing long-term data acquisition and monitoring"?  "Analyzing and modeling existing data"?

Does what you want to do "fit" into a framework such as a State Machine, a Queued Message Handler, possibly the Actor Framework or the DQMH?

To the extent that it is practical, using sub-VIs to "hide the messy details" can lead to top-level VIs that fit on a conventional Laptop screen (which typically is a State Machine or some other Framework model).

Bob (been there, done that) Schor

[santo_13]

---

@Mylonit wrote:

In my company, a typical LV application will consist of several parallel while loops running in the same VI. Each loop has a specific function e.g. DAQ, state machine, logging data, user interface etc. SubVIs are used but only for calculations inside while loops.

For large applications, it's tedious having to use the scroll bars to navigate the VI and it can get messy. I appreciate the general advice will be to use subVIs to organise the code, but as a novice I'm not sure how best to pass data between them. One advantage of the current layout is that it's so easy to use local variables to read and write to variables in different loops. What's the more professional way of doing it? Would be grateful for any examples.

---

Given you're a novice, it is better to get a LabVIEW consultant to architect your application so your application will be robust and last longer. If you're limited in the budget other than your own time, there will be a large learning curve and a bunch of mistakes and reworks/rearchitect along the way.

[crossrulz]

Here are some general comments for what I like to do.

Every loop is its own VI.  This helps a lot with focusing on a specific task when developing and debugging.  Further, each loop should have its own library (lvlib) to segregate the messaging VIs and the library's main VI.  This also forces modularization, making the libraries more portable and reusable between projects.

I find myself using classes more and more for handling the messages being sent to loops.

A single loop should be used for the User Interface (UI) and it generally should only have an Event Structure inside of it.  Use User Events to send messages to this loop that can then be used to update indicators, etc.