Multiple loops or multiple VI's?

[David99999]

I've got a general question about program structure/architecture. The way I've been doing it is having 1 main VI, and the only time I create and use another VI is when I make subVI's for little basic functions to clean up my code.

But all my main processes are separated into their own loops in my main VI. For example, here are the loops in the current project I'm working on:

1. Communication with a BMS (battery management system) via modbus TCP to read values

2. Communication with an inverter via modbus TCP to read and set values

3. Communication with the onboard FPGA for sensor values

4. Setting parameters within the system

5. Communication with an MPPT solar charge controller, reading and setting values

6. Communication with a transfer switch via modbus rs485

A couple of these loops haven't been implemented yet, but will be. I mean, that's 6 loops, some slower some faster, and there will be more when integrating multiple inverters and multiple BMSs'.

Should I be doing that many loops? I don't think I really have a choice when it comes to communicating with separate modbus devices. But should I be doing more "procedural" type programming where things are just called one after the other in one loop like you would with a basic microcontroller? (To do that I'm guessing I would separate things out into their own VI's and call upon each one in a while loop)

Hopefully I have expressed my question well enough. 

[GerdW]

Hi David,

---

@David99999 wrote:

The way I've been doing it is having 1 main VI, and the only time I create and use another VI is when I make subVI's for little basic functions to clean up my code.

...

Should I be doing that many loops?

---

So your main VI gets bigger and bigger?

Yes, you should do "that many" loops! (I don't consider 6 loops as "many"...)

And I recommend to place each "loop" into its own VI(s) to handle each device in its own routine!

Before you start to implement those "loops" you should take the time to think about a program design for your overall application: how to handle each device, how to communicate between those loops, how to communicate with your main VI, how to organize data handling inside your program, and so on...

[Terry_ALE]

More loops require more communications mechanisms for sharing data and status. Has this been considered?

You can put things into less loops so long as things are not blocking and buffers will not overflow.

Generally it is good to spend some up front time reviewing this. I have seen cases with too many loops where the developer was in over their head with regards to communications. When I took over this particular project we realized that the extra loops weren't needed.

Before getting to this I would want to confirm that each of the actions you mention have their own test bench to confirm functionality. Otherwise no matter how many or few loops, this will be very complex.

[David99999]

---

@GerdW wrote:

Yes, you should do "that many" loops! (I don't consider 6 loops as "many"...)

And I recommend to place each "loop" into its own VI(s) to handle each device in its own routine!

---

Thank you Gerd. Do you know where I can find an example of placing loops in their own VI? I haven't seen this done yet.

Before you start to implement those "loops" you should take the time to think about a program design for your overall application: how to handle each device, how to communicate between those loops, how to communicate with your main VI, how to organize data handling inside your program, and so on...

---

For sure, but we move quick in R&D and I'm usually having to figure things out on the fly with zero prep time 😥

[Gregory]

You can put as many loops as you want, but it will get very hard to debug if they are all in one main VI. Larger applications often have a separate VI for each process (1 or a couple of loops), and the VIs communicate by some means, like queues or events.

I will often have 1 VI for each instrument or subset of the system. For example: a camera gets its own VI. An XY stage, while composed of 2 stages, often needs to be coordinated together, so that gets a VI. Even something that doesn't contain an instrument, but needs to be running during the whole application will get its own VI / process. For example, an error handler is needed for every application, and a data logger for many applications.

There are some well known and proven architectures and templates for creating the VIs and handling inter-VI communications. The most popular ones are DQMH and Actor Framework. 

[David99999]

---

@Terry_ALE wrote:

You can put things into less loops so long as things are not blocking and buffers will not overflow.

Generally it is good to spend some up front time reviewing this. I have seen cases with too many loops where the developer was in over their head with regards to communications. When I took over this particular project we realized that the extra loops weren't needed.

Before getting to this I would want to confirm that each of the actions you mention have their own test bench to confirm functionality. Otherwise no matter how many or few loops, this will be very complex.

---

Thank you for the insight! I do confirm each device's functionality with just some scratch "sandbox" code.

---

@Terry_ALE wrote:

More loops require more communications mechanisms for sharing data and status. Has this been considered?

---

I guess I'm a little confused on this. More loops require more communication mechanisms? Are you referring to the fact that I will have to be establishing multiple modbus node connections? If so, yes it's definitely been considered (and mostly implemented).

Generally it is good to spend some up front time reviewing this. I have seen cases with too many loops where the developer was in over their head with regards to communications. When I took over this particular project we realized that the extra loops weren't needed.

---

This is good to know, thank you. I've never done multiple connections to separate nodes in one loop, but it's good to know that if I have to go that route that it can be done 🙂

[David99999]

---

@Gregory wrote:

You can put as many loops as you want, but it will get very hard to debug if they are all in one main VI. Larger applications often have a separate VI for each process (1 or a couple of loops), and the VIs communicate by some means, like queues or events.

I will often have 1 VI for each instrument or subset of the system. For example: a camera gets its own VI. An XY stage, while composed of 2 stages, often needs to be coordinated together, so that gets a VI. Even something that doesn't contain an instrument, but needs to be running during the whole application will get its own VI / process. For example, an error handler is needed for every application, and a data logger for many applications.

There are some well known and proven architectures and templates for creating the VIs and handling inter-VI communications. The most popular ones are DQMH and Actor Framework. 

---

Ok so it sounds like I'm doing exactly what you do, only instead of separating them with their own files, I'm just putting them in their own loops within one VI, and using shared variables to communicate between loops where needed. Sounds like my method is the "ugly" way.

Are you telling me that if I search "DQMH" or "Actor Framework" that I will find examples from NI? I've never seen a loop in it's own VI, where that VI is being called from a main VI.

[Gregory]

Yes, but it's not only ugly. For a modest sized product it becomes inefficient to navigate the main VI, and impossible to test components in isolation.
The Actor Framework is from NI, but DQMH was created by Delacor and now supported by the DQMH Consortium. It is designed to look familiar to someone who has used NI's QMH template. Personally, I think the DQMH would be easier to pick up.
https://dqmh.org/

[David99999]

---

@Gregory wrote:
Yes, but it's not only ugly. For a modest sized product it becomes inefficient to navigate the main VI, and impossible to test components in isolation.

---

Ahhhh yes. You are so right about the isolation thing! Now I'm excited haha

The Actor Framework is from NI, but DQMH was created by Delacor and now supported by the DQMH Consortium. It is designed to look familiar to someone who has used NI's QMH template. Personally, I think the DQMH would be easier to pick up.
https://dqmh.org/

---

Excellent, thank you

[Mark_Yedinak]

I wish I only had 6 loops in my code. I use a publish/subscribe architecture with many components being started and stopped dynamically. I would easiest guess that the application has close to if not more than 100 loops running at any point in time.

You did ask about the need to have more communications in the application. The comment was not referring to communicating with external devices but rather the mechanism for communicating between the loops/components in your application. I would avoid using shared variables as your means of communications. Shared variables are not that reliable for a variety of reasons. Better methods of communicating between application components are to use queues, user events, notifiers or channel wires. More complex systems like the ones I use will have more advanced communication mechanisms such as the publish/subscribe messaging system.

You should also avoid putting everything in one VI because it is possible for it to become too large (LabVIEW has a limited size for a block diagram based on the number of pixels required to draw it) and you can run into strange issues when you get close to this limit.