Time loops problem

[dkidw2010]

I have a complex program that uses a times loop to call other program.  I have reduced the problem to a simplified example.  The calling program has two examples:  Selecting the broken example shows how the program hangs.  Selecting (not selecting broken) shows how the program emulates a times loop and calls the underlaying VI successfully.  When successful, the counter on the main program increments.  When hung, nothing happens.

The program called does two things:

It initializes as event structure inside a while loop, waits for the initialization, calls the event structure with a trigger, which exits the while loop and returns to the main program.  I should emphasize again that this simple program is to illustrate the bug (or my lack of understanding of timed structures).  The real program is more complex but shows the same behavior.

Then called from the main program with the timed loop, the flag is never set and the other parallel tread waits causing the hang. This only happens with a timed loop as the calling entity as the other instance works fine as well as running the VI alone.  You can fix this version by placing the flag outside of the timeout event structure.  This will fix this bug BUT in a more complex program, that fix fails.  I also included the fixed version for a comparison.

For some reason, the timed loop never initializes the called event structure.  It is as if the timed loop priority takes precedence over the called program (I tried modifying that value but more bugs occurred).

Any ideas?  I emulated the timed loop in similar ways to the working case (false case in calling program - yes I should have named them working and broken rather than true and false) and can go on with the larger program but I would like to understand this bug as it may illustrate my lack of understanding of timed loops or something for NI to explore.

I am using LV19.1.

.

[RTSLVU]

Well Timed Loops are really for use with LabVIEW-RT and and the FPGA module.

While you may use a Timed Loop Structure on a non-RT system, most often it will not solve any problems better then a simple while loop with a wait inside…

Describe in detail what exactly you are trying to do here and we might be able to give you a better approach than misusing a Timed Loop structure. 

[altenbach]

No, No, Nooooo!

• Deep pyramids of structures!
• Greedy loops everywhere!
• Many more local variables than controls!
• Peppered with sequence structures, but still full of race conditions!
•  

I think at this point, the timed loop is the least of your problems. Start with some basic tutorial (e.g. listed at the top of the forum), then tell us what you want to do, now how you want to do it. 

[dkidw2010]

Thanks for the programing critique.  I will take it under advisement.

You can remove many of the loops, if you want.  I use them to illustrate a given point

However, what I want to do is understand why the timing loop breaks the calling program.

Run it and see,  As to the other concerns, we can address them later.

[RTSLVU]

---

@dkidw2010 wrote:

Thanks for the programing critique.  I will take it under advisement.

You can remove many of the loops, if you want.  I use them to illustrate a given point

However, what I want to do is understand why the timing loop breaks the calling program.

Run it and see,  As to the other concerns, we can address them later.

---

The only point I see illustrated here is:  A poorly written program performs poorly.

And that's a given, trust me I have made this point a million times myself.

[dkidw2010]

I am trying to understand timed loops.  I provided an example of making a timed loop using a wait outside of the loop.  However, I can easily rewrite it with your suggestion of a wait inside as this is a little cleaner.  These succeed with no hang.

Basically, I do not understand how the timed loop causes the subroutine to fail.  It is likely a race condition of some sort but I assumed that I could force LV to be serial processed and avoid a race condition.  It appears that the while loop that drives the event structure never gets triggered when using the timed loop calling the subVI but works great either called directly (as standalone VI) or called inside of a fixed loop.

Before finding this "bug" (I think), the original idea was to have a subVI that could either be run directly or called by another program.  The subVI would have a number of events that are triggered by buttons on the front.  However, if called by another VI, you can have a group of buttons triggered by the calling program, one group at a time.  For example, the initialize call would press buttons 1,2, &3 whereas a read call may press buttons 3,4,& 5.  Alternatively, the user could mimic these calls by pressing the buttons directly in the VI.

I did this by having each button as an event inside a while loop but to return to the calling program.  If run as a subVI, you need to terminate the while loop to return.  Thus, the independent routine that "pushes" the buttons toggles a stop flag to terminate the while loop containing the events.  However, to avoid race conditions, I need to make sure that the while loop driving the event is initialized before pushing the buttons.  Thus, the setting a flag inside the while loop and the parallel routine waiting for that flag.  Now, I understand that you could program each event as another subVI and that process may be preferable.  However, this idea should work and has an advantage of all the routines being in one subVI and allowing a user to test each button independent of the calling program.  Why, because I am building both the hardware, drivers, and high-level program at the same time in a complex system and need to see how they interact.

[dkidw2010]

Or better a poorly written program uncovers bugs in the language - which should not be present.

Thus, understanding why something fails tells you something.  Just fixing it (as I did), tells you nothing!

[johntrich1971]

---

@dkidw2010 wrote:

Thanks for the programing critique.  I will take it under advisement.

You can remove many of the loops, if you want.  I use them to illustrate a given point

However, what I want to do is understand why the timing loop breaks the calling program.

Run it and see,  As to the other concerns, we can address them later.

---

If you will deal with the other concerns it will likely fix your problem. Running your program is nearly impossible as it gets stuck in loops due to the poor programming that altenbach pointed out. 

[johntrich1971]

---

@dkidw2010 wrote:

Or better a poorly written program uncovers bugs in the language - which should not be present.

Thus, understanding why something fails tells you something.  Just fixing it (as I did), tells you nothing!

---

A poorly written program creates bugs. Race conditions can cause all sorts of odd behavior.

[RTSLVU]

---

@dkidw2010 wrote:

Or better a poorly written program uncovers bugs in the language - which should not be present.

---

Improper use of a function causing said function to perform improperly is hardly a LabVIEW bug.

IMHO: That would be the expected behavior.