Flat secquence, second frame running before first stops.

[nlis12]

First of all, I know that flat sequence structuring is generally not used, but I was advised to build upon this code and not rewrite it. (originally written with flat sequence structure)

The main problem is that the second frame is executing before the first frame ends.
ie: While loop 1 finishes, then I intend to use while loop 2 to allow the user to initiate the next frame by terminating while loop 2.  But while loop 3 is actually running while the code is stuck in while loop 2.  Once the user has terminated while loop 2 and supposedly initializes the second frame, you can already see that while loop 3 had already started to run previously.

Any thoughts as to why this is happening and how to fix it?

Attached is a print screen for reference.

[Blokk · Accepted solution]

This is a real spaghetti monster. I would say you should have attached the whole VI, but I am not sure if I want my LabVIEW open it! 😄

What I can see based on the screenshot, the execution should not move to the next frame from the While loop at step 2. Are you really sure that this happen? I guess something else fools you to think the while loop 3 started already before the while loop 2 stopped.

By the way, you created a greedy while loop (while loop "2")! This burns your CPU as fast as it can run. Put some mseconds Wait there inside!!!

Plus you should really not remove labels from controls/indicators. There is no label on that Boolean button!

[altenbach · Accepted solution]

I am sure you are imagining things/. What is the evidence that things execute out of defined order?

What is the mechanical action of the boolean in the greedy loop #2? (see also). Could it be that it is still true from an earlier run of the sequence?

What is the point of these FOR loops? Why can't you just autoidenx on the concatenated boolean array (eliminating index array wired to [i]) and autoindex at the output tunnel to form the string array? (Eliminating all that "empty array constant/shift register/insert into array/... etc" stuff that is completely unnecessary). The various frames contain a huge amount of near duplicate code. Wouldn't one instance be sufficient?

[nlis12]

I know that while loop 3 is running because when I terminate while loop 2, the "reach temp timer" indicators do not start at zero.  They are something greater than zero.  Since these indicators are wired to the while loop iteration count, it suggests that the loop has already gone through some iterations.

thanks for the suggestion for while loop 2

[Blokk]

---

@nlis12 wrote:

I know that while loop 3 is running because when I terminate while loop 2, the "reach temp timer" indicators do not start at zero.  They are something greater than zero.  Since these indicators are wired to the while loop iteration count, it suggests that the loop has already gone through some iterations.

thanks for the suggestion for while loop 2

---

Since you did not attach your VI, we can only guess what is wrong here...

[nlis12]

I am sure that while loop 3 has already done some iterations because the "reach temp timer" indicators, connected to the iteration count, always starts at number larger than zero when frame 2 executes.  This suggests that iterations have already begun.

The Boolean is just a toggle switch on the front panel.  I have run the code in highlight mode and can physically see that the code is stuck in while loop 2, so I know that while loop 2 is stalling as I intended.

thanks for the suggestion on the for loops.

Also what is a good alternative for the "greedy loop"  I have in place? 

[RavensFan · Accepted solution]

---

@nlis12 wrote:

I know that while loop 3 is running because when I terminate while loop 2, the "reach temp timer" indicators do not start at zero.  They are something greater than zero.  Since these indicators are wired to the while loop iteration count, it suggests that the loop has already gone through some iterations.

---

Do you reset those "reach temp timers" back to zero when your code starts?  When they are not zero before you hit the loop2 stop button, are they actually incrementing, or are they just steady at that non-zero value?

If your code runs and you have a number shown in that indicator, that number will persist when you stop your code.  If you restart your VI, that same number will be there until some code goes and writes a new value to its terminal, a local variable, or a value property node for that indicator.

Put a small wait function in that greedy loop.  It will slow it down and allow the CPU time to do other activities, but with a small wait, it will still seem like an instant response to the user. You can also use an event structure so that instead of polling the stop button, it actually waits for the event.  But that is probably overkill here.

I guarantee that the second frame is not running before the first stops.

[nlis12]

These numbers are actually incrementing as if the loop was running.
I can count how long I sit inside while loop 2 and terminate it.  Then the second frame starts and the indicators immediately show a value approximately equal to what I counted. 

Thanks for responding.

[nlis12]

trust me, you probably wouldn't want to see the whole VI.

But thanks for responding!

[billko]

---

@nlis12 wrote:

trust me, you probably wouldn't want to see the whole VI.

But thanks for responding!

---

Just FYI - a VI that you "probably wouldn't want to see" because it is too big and/or messy is developing bad LabVIEW programming habits for the following reasons:

"Too big" is like placing all your code in main().  For the same reasons you would break your code up into functions in a text-based language, you would break it up into subVIs in LabVIEW.  Additionally, LabVIEW block diagrams that are larger than one screen is discouraged because it is hard to navigate.  Sometimes you CAN'T adhere to that practice - but maybe you can keep it to either one screen height or width - that way you only need to scroll on one axis.

"Too messy" is like using random indents in a text-based language.  The compiler doesn't care, but anyone who had to work on your code would likely hunt you down and kill you (and I would just look the other way while it was happening).

Try to keep these points in mind when creating LabVIEW code moving forward.  (And if you have the time and resources, revisit old code, too.)