To download NI software, including the products shown below, visit ni.com/downloads.
Overview
This code show how master/slave architecture work with notifiers, and these two slave loop will run independently of each other.
Description
In this example, the Master loop continues to loop and the case structure checks whether the switch on the front panel has been pressed or not. When the button is pressed, two string notifiers are sent, "Loop 1" and "Loop 2".
Each slave loop contains a check to see if it should execute. Each loop blinks a respective LED on the front panel at a different rate.
When the application begins, nothing will be happening. Then, when you press the Switch button, the LED's will blink a set number of times, each at a different rate specified by the wait contained in the for loop in each slave loop. After the LED's have finished blinking, they will turn off, and they will again be waiting for the Switch button to be pressed. Additional slave loops can be added to this architecture as needed.
Requirements
Steps to Implement or Execute Code
Additional Information or References
VI Block Diagram
**This document has been updated to meet the current required format for the NI Code Exchange.**
Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.
This example is nice. But only useful if you do not care about lost notifications and quite random behavior.
Sometimes, Loop1 might get a notification for Loop2 (and therefore do nothing) and the other way around if not both loops are waiting for a notification at the same time. The problem becomes apparent when you click on the switch after about 9.5s...
So use with care 🙂
I know this is is an older thread that I just stumbled upon, but I believe the solution to the OP's problem is to use a Producer-Consumer design pattern, rather than a Master-Slave design, correct?
The only real way to ensure that no events are missed would be to use a queue or some structure that contains previous points, or some way of handshaking between loops. I will admit, my LabVIEW knowledge (especially for notifiers) was rather new when I created this example. It was intended to show the parallelism of loops in LabVIEW, however as mtedaldi pointed out, it will become less predictable as the program runs.