How to synchronize an event case in a while loop from a comparison condition that is in another loop?

[edmonton]

Hi Friends,

 I need to synchronize an event case in one loop from a comparison condition that is in another loop. The event case should be executed when the condition is met.  

Attached please find two simple VIs for illustrating purpose, however, none works. The first one uses a comparison condition directly, the second one uses enqueue to pass the condition to the dequeue loop. 

The sample VI has three cases: addition, subtraction and multiple. the addition and subtraction are normal cases, the multiple case need to be synchronized when the condition is met, which is when the iteration is equal to 4.   

Could someone help with this issue?

Thanks,

Gu

[stevem181 · Accepted solution]

Hi Gu,

Attached is a modified version of your synchronization vi.

As you found, updating an indicator does not generate an Event.

However, you can generate an event on demand using Dynamic (aka User) Events.

Also your Stop button needs to be in an event case to work. 

For your understanding of LabVIEW, try to figure out why this is required.

steve

[altenbach · Accepted solution]

I recommend to go back to the tutorials, because see seem to have some serious misconceptions of event structures and dataflow principles in general. Events are not for value changes of indicators, they are for user interactions.

Synchronization.vi: Why is there a timeout event if you are not using it? (you could probably use it!) Why is the diagram and front panel window maximized to the screen? LEDs are typically indicators, not controls and for this purpose they at least should have latch mechanical action (do you know what that means?). Your LEDs are all randomly on or off and their state have nothing to do with the currently displayed result. After four seconds, your upper loop will continuously result in a true condition and the LED value will actually never change again. What's the reasoning behind that? What is so special after 4 seconds and never again?

Synchronization_enqueue.vi: Why is the diagram and front panel window maximized to the screen? Your lower loop can only go to the next iteration once all code in it has completed. This will only happen if both queues receive an element (happens every 1s) AND the event executes (timeout is infinite, so that will only happen after user interaction!) This also means that if you let this code run for a long time without user interaction, both of your queues will grow without bounds. Also note that x and y will be read at iteration start, so if you change their values while the event is waiting, the result will still be based on the stale values if you would trigger one of the events. Once the multiply is true and the event fires for whatever reason, the lower loop will stop forever while the upper loop continues ad infinitum (or until stop is pressed)

Can we go back a few steps so you can explain the actual use case you need. In this particular example, you don't need two loops. It also seems annoying to the user to constantly interfere with user interactions. For example the user might press "addition" and the code overwrites it a nanosecond later with a multiplication, confusing everyone.

The simplest way to trigger your event would be to write a a signaling property of the multiply indicator whenever the value changes, but as already said, it seems pointless do do that. You could even poll a timer in the timeout event, no second loop needed. I would recommend looking into state machine architectures.

In summary, explain what the user should experience as a function of interaction (and non-interaction) and what the purpose is of it all.

[edmonton]

Hi Stevem,

Thank you very much. The user event works well for my application. This will be my first time to use a user event  case.

Best regards,

Gu

[altenbach]

As said, writing to a signaling property would have been the only change in the upper loop to get the (misguided) functionality you were looking for. Don't over-complicate things with user events. 😄

(Note that the case structure is needed because writing a signaling property will fire the event even if the new value is the same as the old one)

[edmonton]

Hi Dr Altenbach,

Thank you for your valuable input.

The timeout event is automatically generated, I just did not delete it. I did not notice the window is maximized to the screen, actually, I do not know how to change it, it is seemed a default setting from LB.

The program is for illustration purpose, not exactly my real application that is much more complicated. The event loop is for a user interactive device, such as a motor move, each click outputs an action, turning the motor clockwise/counter clockwise. The other loop is for a data acquisition device, it sends a condition at certain time or any other parameter to the event case loop to do a special motor move.

Regards,

Gu

[stevem181]

---

@altenbach wrote:

As said, writing to a signaling property would have been the only change in the upper loop to get the (misguided) functionality you were looking for. Don't over-complicate things with user events. 😄

---

Value Signaling Property nodes are slow to execute and force a switch to the UI thread.

If you want to create subvis you have to deal with the reference. 

For demos and "all on 1 page" programs that don't need tight timing they will of course work fine.

As it turns out, the OP needs to control a motor. User Events are a better fit for this application (IMHO).

steve

[altenbach]

---

@stevem181 wrote:
As it turns out, the OP needs to control a motor. User Events are a better fit for this application (IMHO).

---

Well, who would have guessed. We are getting very relevant information one drop at a time 😉

(Still, I am not sure  if we found the correct architecture for the problem at hand .;))

[edmonton]

Hi Dr Altenbach,

Yes, the user events are the best fits.

Gu