Stopping multiple while loops

[LTBALAZS]

Hi,

About my project:

It's a data logger application. Inside my project there're 4 separate while loops. One is as main, others are for different instruments.

If i push START button then disable and grey it out and enable STOP button and start other instruments' while loops.

If i push STOP button then disable and grey it out and enable START button and stop other instruments' while loops.

----------------------------------------------
I tried the following methods to stop the instruments' while loops. Stopping/starting them often fails:

1) Using stop button as switch with its variables

2) Using notifiers

Both mentioned methods above (very often) leads labview to indeterminate states.

Phenomenons:

- sporadically "disable and grey it out" does not work when i pust START button. Though some while loops get started in the background

- sometimes not all while loops stops or starts,

- it varies which while loops is stopped or started,

- infrequently waveform graph freezing non refreshing, sometimes labview not responding to stop running VI.

Have you got any ideas what is the root cause of the penomenons above?

Kind regards,
Balázs

[pincpanter]

Almost certainly it's due to race conditions, that is an unexpected/improper sequence of operations in the code.

But we need to see your code to be more precise (complete vi or code snippet please, not a simple picture).

[altenbach]

---

@LTBALAZS wrote:

Have you got any ideas what is the root cause of the penomenons above?

---

Your description is way too ambiguous to tell anything, except that the code must be faulty 😉 For example, you talk about start and stop buttons without ever telling us how they are connected to the code and what they are supposed to start or stop. Vague words such as "sporadically, "sometimes", "it varies", etc. "Freezing" is very different from "not refreshing".

Please attach a simplified version of your code where e.g. instruments are replaced by a simulation (e.g. a LED or similar) so we can run it without your hardware.

How are things connected? How many local variables are there? What are the various loop rates? How are errors handled? Are there loops inside other loops? Data dependencies?

[LTBALAZS]

Hi,

I attached the Test.vi that is a simplified vi of my project.
Is there a better way to break from while loops than the way i do in Test.vi?

Kind regards,
Balázs

[GerdW]

Hi Balazs,

---

@LTBALAZS wrote:

I attached the Test.vi that is a simplified vi of my project.
Is there a better way to break from while loops than the way i do in Test.vi?

---

Surely…

You use a notifier for your "start" condition: you might also use a notifier for the "stop" condition! (This might even be the same notifier.)

Do you really need all those polling loops? Do you need to poll at 1000Hz just for calling another VI upon user action?

Why are there so many loops set to run forever? What's the point of a "stop" button then?

Why don't you use an event structure to handle all those buttons?

Why is there device communication inside your "Main loop" when all other devices got their own loops?

It seems you need to implement a better code architecture: what about a QMH architecture?

[pincpanter]

Your event detection is flawed.

Let's consider the Start. You are polling the Start value every 10 ms. So, when you press Start, a True is written into the notifier. However, 10 ms later, the button was reset and a False is written into the notifier. Are we sure that in the meantime all hearing loops read the notifier and got the True value? The answer is NO.

Now let's consider the Stop. When you press the button, the main loop iterates and as soon as possible resets the button to False. Are we sure that in the meantime all hearing loops read the notifier and got the True value? Again, the answer is NO.

Although your code may work "enough" if you slow down the Start polling loop (say to 1 second) and putting a wait before resetting the Stop button (or resetting it only after the Start, which would be a safer option but terribly ugly), this "solution" would only be a quick-and-dirty patch of a flawed architecture.

As GerdW pointed out, you may want to explore a Queued Message Handler architecture, which would be safe and prevent the program to poll button's states at so high frequency. A better architecture will spare you time and headaches when the need will come to add funcionalities to your code.

[LTBALAZS]

Hi Paolo and GerdW,

I apologize for the late reply. I thank you both for your comments, i have to re-think my code as soon as possible.

I'll look for Queued Message Handler architecture.

Kind regards,

Balázs