Best practice on waiting for a function in a parallel loop to finish?

[Basjong53]

Hello, I have a question regarding a best practice. For my project I have a light sensor and a lamp. I must control the lamp and measure the resulting voltage of the light sensor. Because I want the code to be modular, I have mande two main loops: one to measure the voltage from the light sensor and a second to control the lamp. I have a queued message state machine to control the hardware.

The code to turn on the lamp takes some time. When I press the start button, I send a message to the lamp loop to turn it on, then I have to wait for this function to execute before starting to measure, I don't know exactly how long the turning on takes, so I cannot use a wait function. Of course, I can make a notifier, after sending the "turn-on lamp" message, wait for the notify, and put a send notifier after the function of turning on the lamp. But this seems clunky, I would have to make a new notifier for each lamp function, and if I make more loops (to control more hardware) I'll have to make even more notifiers.

The less clunky, but also less modular way is to simply put the function to turn the lamp on in the same loop as the voltage reading, this makes the program serial, and doesn't seem like a best practise to me.

How can I make a good code here without making it clunky by creating lots of synchronization references?

[GerdW]

Hi Basjong,

---

@Basjong53 wrote:

The code to turn on the lamp takes some time. When I press the start button, I send a message to the lamp loop to turn it on, then I have to wait for this function to execute before starting to measure,

simply put the function to turn the lamp on in the same loop as the voltage reading, this makes the program serial,

---

So your code should run in a serial sequence manner, but you don't want to serialize your code?

Why not employ simple DATAFLOW to execute one subVI first, followed by the next one?

[Basjong53]

Hi GerdW, 

You are right that using dataflow is the easiest way for this example. But, I'm trying to learn to make better, more scalable code, too many times I've had to rewrite a program because I had to add features that were not easy to implement. In this case let's say that in the future I want to add an option for the user to control the lamp while the voltage is being measured. Now the lamp should be in a parallel loop so as to not be delayed by the voltage measuring. So before having to rewrite all the serial code again, I want to think ahead and make it more modular.

[BertMcMahan]

Couple options I can think of. If your lamp is in a parallel loop doing its own thing, you're talking to it with some kind of message structure. You could have that structure set up to send a message back to your main loop when the lamp turns on, or you could have the main loop periodically poll the other loop with an "Are you on?" message, responding via your method of choice.

I think I'd recommend creating a user event for "Lamp status" and register it in your main loop. When the lamp loop turns on or off, it can fire that user event to tell the main loop "I'm on" or "I'm off".

[XM43]

Hi Basjong,

1) Assuming that you would anyway would have to make some changes to the code when adding more hardware. Easiest way I could think of it creating one "Functional global variable" for all the controls you want (I would say would be good idea for small scale). It could be of boolean, numeric or enum. It will be a simple block, easily scalable, you can place is easily in different pieces of code.

Use the output values of the FGV to control cases in any parallel loop need.

2) There is also a way to create a modular & scalable queuing system like JKI state machine. Using which you can not only send a message but data to any loop or VI. You can have multiple VI's running in parallel (idling) but can start processing as soon as you tell them, you can also find some instructional videos.

Not sure how exactly you applied your current queuing system. If you could provide any more information it would be better to provide suggestions.

Hope this helps.

[Basjong53]

---

@BertMcMahan wrote:

Couple options I can think of. If your lamp is in a parallel loop doing its own thing, you're talking to it with some kind of message structure. You could have that structure set up to send a message back to your main loop when the lamp turns on, or you could have the main loop periodically poll the other loop with an "Are you on?" message, responding via your method of choice.

I think I'd recommend creating a user event for "Lamp status" and register it in your main loop. When the lamp loop turns on or off, it can fire that user event to tell the main loop "I'm on" or "I'm off".

---

Having a while loop that polls a global variable (for example) seems like a good idea!

Why would you recommend a user event for something that is not a user event? Wouldn't a message queue do the same job here?

@XM43 wrote:

Hi Basjong,

1) Assuming that you would anyway would have to make some changes to the code when adding more hardware. Easiest way I could think of it creating one "Functional global variable" for all the controls you want (I would say would be good idea for small scale). It could be of boolean, numeric or enum. It will be a simple block, easily scalable, you can place is easily in different pieces of code.

Use the output values of the FGV to control cases in any parallel loop need.

2) There is also a way to create a modular & scalable queuing system like JKI state machine. Using which you can not only send a message but data to any loop or VI. You can have multiple VI's running in parallel (idling) but can start processing as soon as you tell them, you can also find some instructional videos.

Not sure how exactly you applied your current queuing system. If you could provide any more information it would be better to provide suggestions.

Hope this helps.

---

1) I'm not sure how I would implement an FGV to control cases in my example, could you elaborate?

2) I've already been using the JKI state machine for some time now, but I believe there is no functionality built-in that can control multiple loops. I could be wrong though 😅

I've attached a quickly made example of my program's architecture. Don't mind the functionality for now, this is only the structure. 

[crossrulz]

---

@Basjong53 wrote:

Why would you recommend a user event for something that is not a user event? Wouldn't a message queue do the same job here? 

---

It is a poorly named feature, much like the "local variable".  A User Event is just like a message queue except it uses the event queue for each Event Structure registered for the event.  User Events are a great choice for GUI updates coming from parallel loops since it keeps all of your GUI code in a single loop (using an Event Structure) without the need for polling.