Which design pattern to drive several instruments?

[RCE69]

Hi,
I wrote LV code to read and write on several instruments such as flowmeters, temperature and pressure regulators... It's working perfectly, but i'm sure that the code itself can be improved by using design patterns.

The code is composed of several independent loops, one for each instrument. They work the same way :

1. initialisation of the instrument (open com port, read some parameters, etc.)
2. while loop with event structure to read by default or write when there's an action from a user
3. close the communication when an error occurs, when a user pushes a button or the general stop

This general structure just works in a serial way with error structures linked with wires. One of my coworker advised me to use QDMH pattern instead. Is it a good choice as it seems quite complicated at first sight? Is there also any other improvement i can add?

Please find the vi attached, there are a lot of missing subvis, but you can get the idea.

Thanks for your help

[Blokk]

There are several problems with your code, like using more than one Event structure, Flat Sequence structure, overusing local variables, etc...

Before trying to use a advanced template like the DQMH, I strongly advice you to take the Core 1-2-3 online courses. You should first learn and become familiar with the Data Flow principle, variable types (pros and contras with the different types), State Machines, Queues, Notifiers, Producer/Consumer templates and its variations, etc...

Also worth to read the following doc: http://www.ni.com/newsletter/51735/en/ 

[Gregory]

Based solely on the text in your post, you are thinking along the right lines. It is very nice to have each instrument in its own loop so they don't hold each other up. You do have to consider how they will communicate with each other (other loops). One rigid, but easy to debug way is to have all commands go through a central handler loop. This is the only "smart" loop that can ask other loops for data or tell them to take measurements. 

I think your co-worker may have meant DQMH (delacor queued message handler). It has a lot of nice features if you want to send data using events. Most people learn to send data over queues, so this may be a new way of thinking, but once you adjust it becomes second nature.

I am personally stuck with LV 2012, so I could not use the DQMH on my last project. Instead I just used queues to send data between loops. There were a couple of instances when it would be nice to use events (like when you want to run one loop standalone, and not care if someone is on the other side to receive the message). But overall, there weren't too many drawbacks, and it's just a lot of work to create all the typedefs and VIs associated with events if you don't have the nice macros built into the DQMH toolkit.

[RCE69]

Hi Blokk,

Thanks for your reply. I don't think i'm using flat sequences, I precisely tried not to use them in order to make a more understandable code.

As for local variables, are you talking about the whole VI or for each loop?  I agree that for representing the data, these are badly used. I should use Producer/consumer pattern instead for the graphs, right? But in this code, it was not important to represent the data synchronously, but just to have an overview of what is happening, hence the time vi in each loop. About the local variables in the loops, well I can't see another way of coding, except using wires, but i guess this would be unreadable. Or maybe use clusters?

Regarding Event structure, what do you mean by using more than one?

[Blokk]

---

@RCE69 wrote:

Hi Blokk,

Thanks for your reply. I don't think i'm using flat sequences, I precisely tried not to use them in order to make a more understandable code.

Ok, but you use Stacked Sequence Structure. Learn how to use State Machines, and subVIs to have a clean and proper code.

As for local variables, are you talking about the whole VI or for each loop?  I agree that for representing the data, these are badly used. I should use Producer/consumer pattern instead for the graphs, right? But in this code, it was not important to represent the data synchronously, but just to have an overview of what is happening, hence the time vi in each loop. About the local variables in the loops, well I can't see another way of coding, except using wires, but i guess this would be unreadable. Or maybe use clusters?

Use typdef cluster wires, subVIs and proper design pattern. In this case you will not need local variables. I have some medium sized projects practically without any local variable. Still, the code is not crowded. Overusing local variables will hurt you earlier or later for sure. You will just get into nasty race conditions, etc. There are cases when local variables are totally ok to use, but always use a wire whenever you can. LabVIEW is a Data Flow language, do not try to program it like a C code...

Regarding Event structure, what do you mean by using more than one?

It is never a good idea to use more than one Event Structure in a VI. Even if it works, it can introduce problems in many cases (locking up te GUI, etc.). Anyway, a proper design need only a single Event Structure in the main VI.

As I wrote earlier, you would benefit a lot from going through the online courses.

---

[RCE69]

Thank you for this complete reply. I'm following the courses, I completed core 1, and I thought my code was good enough regarding the beginner errors. I guess I still have some improvements to make though.

Actually I was thinking about using State Machine (I already used one in the past for something totally different) for each instrument. The states would be something like "Init" "Read/Write" "Close" "Error". It could be a first way to improve the readability. Then see if i can reduce the amount of local variables.

My colleague is using a lot the QDMH pattern given by LV as default (not DQMH). He says it is easier than State Machine and more useful and could help me in the future. But I don't really see the usefulness of it, nor the simplicity, it seems quite advanced.

[Blokk · Accepted solution]

My colleague is using a lot the QDMH pattern given by LV as default (not DQMH). He says it is easier than State Machine and more useful and could help me in the future. But I don't really see the usefulness of it, nor the simplicity, it seems quite advanced.

If you mean the Queued Message Handler, usually we cite it as "QMH", not as "QDMH". It does not make any sense to compare the QMH to a State Machine, since the QMH is a specific template, the State Machine is a programmatic concept. Even better, the QMH can have one or multiple state machines when implemented for certain project requirements. Ok, actually there is a "Simple State Machine" template shipped with LabVIEW, of course you can compare the QMH to this template...

So I recommend you to continue the Core training, it will light up the things as you go on. You already have good ideas what kind of things you can improve, and this training curve will help you to get further. First get familiar with the important basics: subVIs, variable types, comm methodes (Queues, Notifiers, Dynamic User Events), state machines, type definitions, etc...

[Blokk · Accepted solution]

My colleague is using a lot the QDMH pattern given by LV as default (not DQMH). He says it is easier than State Machine and more useful and could help me in the future. But I don't really see the usefulness of it, nor the simplicity, it seems quite advanced.

If you mean the Queued Message Handler, usually we cite it as "QMH", not as "QDMH". It does not make any sense to compare the QMH to a State Machine, since the QMH is a specific template, the State Machine is a programmatic concept. Even better, the QMH can have one or multiple state machines when implemented for certain project requirements. Ok, actually there is a "Simple State Machine" template shipped with LabVIEW, of course you can compare the QMH to this template...

So I recommend you to continue the Core training, it will light up the things as you go on. You already have good ideas what kind of things you can improve, and this training curve will help you to get further. First get familiar with the important basics: subVIs, variable types, comm methodes (Queues, Notifiers, Dynamic User Events), state machines, type definitions, etc...

[RCE69]

Thanks both of you for the answers. I have a better idea of how to proceed to be more efficient writing code. I think I was going a bit too fast, I'll try to improve this step by step.

[crossrulz]

---

@RCE69 wrote:

I'm following the courses, I completed core 1,

---

I recommend getting through Core 2 (where Queues are introduced) and Core 3 (where the Queued Message Handler is discussed).