Event Structure causing program to run continously

[Dhouston]

Hello all.  I have a program that is running and monitoring a life test.  As I am continuously trying to learn Labview, I used an Event Structure in this program for efficiency.  However, now when I press the STOP control on my program, the Run arrow remains black. So I have to always hit the Abort button to make the program really stop. Yet I can see that the various indicators in my program are not longer updating--that would seem to indicate to me that the program really stopped.  Before I used the Event Structure I did not have this problem.

I have attached the program for your viewing.    The Pearl program is the main one. The Measurement program is a subvi.  I know it is a big mess; I have been advised by this forum to use sub-vis to make my programs more maintainable and easier to work with.  I'm working on that; subvis are one of those things I have trouble working with  So please excuse the spaghetti you see hear.  I have put these here asking if you can see what could possibly be making the program always run.  

The program is designed to stop in three instances:

1-User presses STOP control (button labeled Program On     Program Stop)

2-Program sees a high temperature

3-Program sees an undesired voltage.

If I press STOP, the program stops the way it should (takes about 3 seconds).  However, if the program performs instance 2 or 3 mentioned above, I get the "always running" behavior.  I am sure the Event Structure is causing this, but I don't know how to fix it.

Thanks for any and all help.  We are using Labview 2010.

[RavensFan]

Your VI's didn't get attached to the message.

My guess is that you don't have events associated with items 2 and 3 and your code is waiting on one of the events that registered in the event structure before the while loop to finish.  That's speculation since we don't have the code to look at, but is a very common mistake made when working with event structures.

[Sam_Sharp]

You haven't posted your code or any screenshots, I guess you forgot the attachment.

Do you actually wire a 'True' to the while loop with the event structure in?

Have you turned on 'highlight execution' to see which parts of your code are still running when it 'hangs'?

[Dhouston]

Vis attached.  Sorry about that.

[altenbach]

I can't see anything obvious, (only looked for a few seconds), but that code contains a huge number of pure Rube Goldberg construcsts. What's up with all these little case structures that either select a true or false diagram constant based on the selector of the same flavor?

Are you sure all loops interate at a reasonable rate? (some seem to have delay loops of "on/offtime*4*250ms". The default times are 30, so it will take 30 seconds for the loop to go to the next iteration and have a chance to read the local variable again.

[Dhouston]

@RavensFan

-I did put events for the two items, but as I am a novice with event structures, the fact that there are other While Loops using controls that affect those items, there could be a problem.

@Sam-Sharp

-I know it will look crazy, but I am sure I did this.

@altenbach

-Oh dear, you are over my head now.  I don't even know what a Rube Goldberg construct is.

-The multiple case structures.  The program monitors and individually operates 6 units. The program is designed to be able to stop any unit and keep the remaining units operating.  As you can see, I have 3 While Loops that all involve the six switch controls.  The user can stop a unit from operating by using the associated switch.  So I had to have each switch in all 3 While Loops.  That issue alone accounts for the 20+ case statements you see.  The counting loop has its own plethora of case statements due to the boolean operation that shows a count.

-Loop rate.  Let's see.  Here is a breakdown:

1.  The Main Loop operates on a 1 second timer based on the On Time/Off Time controls.

     a.  The loop inside the main loop operates the blue indicator bars.  This loop also operates on a 1 second timer based on the On Time/Off Time controls.

2.  The Temperature Read loop operates on a 100ms multiple time (using Wait until Next ms Multiple)

3.  The Voltage Read loop operates on a 250ms multiple time (using Wait until Next ms Multiple)

4.  The Cycle Count loop operates on a 1 second timer based on the On Time/Off Time controls.

5.  The Print Screen Loop has the Event Structure.  I did not put a timer in it as I thought the event structure would prevent that loop from calling CPU cycles until needed.

This seems to work will enough.

[altenbach]

---

@Dhouston wrote:

@altenbach

-Oh dear, you are over my head now.  I don't even know what a Rube Goldberg construct is.

---

Rube Goldberg was a cartoonist, often showing showing machines that do simple tasks in very complicated ways.

We have a thread about LabVIEW examples here. Study it!

Your contribution is shown below. The inner case structure serves no purpose and equivaled code is shown below. Arguably simpler. 😄 There are many more instances in your program. According to thids, the event loop stops if the temperature loop is stopped, making any later event to not being able to fire. Since they are set to lock the front panel until the event completes (and they can never complete because the event loop s already done!), your program locks irreversibly and needs to be aborted.

 

---

Dhouston wrote:

1.  The Main Loop operates on a 1 second timer based on the On Time/Off Time controls.

     a.  The loop inside the main loop operates the blue indicator bars.  This loop also operates on a 1 second timer based on the On Time/Off Time controls.

2.  The Temperature Read loop operates on a 100ms multiple time (using Wait until Next ms Multiple)

3.  The Voltage Read loop operates on a 250ms multiple time (using Wait until Next ms Multiple)

4.  The Cycle Count loop operates on a 1 second timer based on the On Time/Off Time controls.

5.  The Print Screen Loop has the Event Structure.  I did not put a timer in it as I thought the event structure would prevent that loop from calling CPU cycles until needed.

---

Look again. Some of these loops have inner FOR loops based on stale stop values that stall the outer loops. See image for more details.

[Dhouston]

Well, my novicity (is that word?) blossoms into quite a mustard tree.  I'll keep looking at that thread too, altenbach. Thanks for that.  There are some qutie interesting icosahedron code replicas in there.  I see I am not quite alone.

Since the Event Structure is causing a program lockup, I can remove it altogether.  I initially did not use the event structure due to this very reason, but I wanted to try again.  Alas, perhaps I'll back off from it and go back to the original code, which is quite ugly, but at least functional.

As for the inner for loops with stale stop values, I was using these to allow me to stop the while loops manually.  The situation you mention about the for loop causing the while loops to stall for up to 30 seconds is exactly what I was encountering before using those For Loops.  When all I had was the Wait timers, the user could hit the STOP control and the program would take 30+ seconds to stop.  When I put the For Loops in the program, that time was reduced to about 3 seconds.  I did not even know about the For Loop with stop terminal capability until it was suggested by someone.  So that shows you where I am as far as Labview know-how.

Most if not all of my programs use these methods shown if you follow other posts I have given.  My usual situation is a while loop that runs the main part of the program, a second while loop that counts cycles (along with arithmetic operations and file storage), and a third while loop that measures temperatures.  I figure I might could reduce the complexity by using arrays or clusters to group the functionality of parts of my programs, but I worry about memory usage when it comes to arrays, and I always have issues when using clusters.  The Bundling and Unbundling tend to have hiccups because I tend to bundle in one loop, unbundle in a different loop, then do a bunch of comparisons and arithmetic operations with the bundles and unbundles.  I like using clusters since they allow grouping of indicators.

Can you all come up with a way I could reduce the complexity here?  I want to try, but it overwhelms me every time.

[altenbach]

---

Dhouston wrote:

Since the Event Structure is causing a program lockup, I can remove it altogether.  I initially did not use the event structure due to this very reason, but I wanted to try again.  Alas, perhaps I'll back off from it and go back to the original code, which is quite ugly, but at least functional.

---

You can leave the event structure, but make sure that the event loop does not stop unless you want to stop the entire program.

If the inner FOR loop should be able to react right away to changes in the stop button, the local variable reading the stop button needs to be inside the FOR loop. It needs to be read freshly with each iteration. Of course overuse of local variables make the code hard to debug, force additional data copies in memory, and potentially create race conditions. There are better ways.

Have a look at the established desing patterns. Do a clean state machine with several flat independent loops (don't do while loops inside while loops).  If parts need to go idle in a certain loop, use a big case structure that bypasses the code while keeping the loop running at a resonable pace.

[Dhouston]

Ok, let me take this one piece at a time.  I am misunderstanding Event Structure functionality here.  Using your advice:

". . .the event loop stops if the temperature loop is stopped, making any later event to not being able to fire. Since they are set to lock the front panel until the event completes (and they can never complete because the event loop s already done!), your program locks irreversibly and needs to be aborted."

When you say "later event"  do you mean the other event cases?  So somehow I need to make it where if the temperature loop stops, the program will know to shut down all other running items?  This sounds like a flat sequence structure, or else put a copy of each stop button inside each "loop stop" event.  As an example, I would put a local variable of the Main Loop stop and Voltage Read stop in the Temperature Loop stop event, set the two buttons to true, merge all three booleans into one value, and send that out to the while loop stop terminal that houses the Event structure.

". . .make sure that the event loop does not stop unless you want to stop the entire program."

I thought by using the event structure, the event would cause the loop associated with the event to stop as well.  So when the temperature loop event turns true, it would stop the event loop.  Then since the temperature loop contains a stop for the main program and the voltage read loops, I thought they would stop as well.  So is it that event structures do not act like a local variable?  Events in the event structure do not connect with controls/indicators/terminals that the event structure is based on?  So should I see event structures as a separate entity and not connected with whatever it was based upon?

I've never used a state machine, and they look REALLY complex to me.  I'll have to ask about them later.