event structure and radio buttons

[James.M]

---

@David_Lieberman wrote:

I tried it and the button change fires every time but the radio buttons do not work.  I put a probe on the line from the radio button to the indicator and it never executes.

---

So then you're still doing something wrong... The timeout case will only help you if you're trying to let the loop run without waiting for an event, or you have code in the Timeout case. If you create an event for each control, then you don't need a timeout case because nothing is happening outside of those control value changes.

---

David_Lieberman wrote:

What I find puzzling is why this is required and why the inner loop was the cause of the problem.  I always thought of an event handler as a software equivalent of a hardware interrupt and the idea that a software loop could prevent interrupts from firing as bizzare. Also why is a timeout value on the event stucture required for the contents of the loop to execute at all since my "code" for the timeout case does nothing.

---

LabVIEW programming is based entirely on dataflow and parallelism. This is incredibly powerful and has lead to its success over the years (coupled with the graphical programming), but is usually one of the first things that new developers stumble over. Here's a simple resource to become more familiar with how it works. The Highlight Execution feature is a great way to watch how your application utilizes dataflow. When that inner loop is just continuously running, everything else surrounding that loop can't run until the inner loop ends. The event handler follows the same rules as the rest of LabVIEW: the event can't be handled until the code catches up to the event structure to "read" the event. The timeout is only required because you coded it in an inconsistent way. Why would you create an event case for the button but not for the radio buttons.

[David_Lieberman]

You have an infinite inner while loop. It is doing nothing but burning away CPU cycles writing the radio button value to an indicator. The event structure waits on the button.

I assumed it was rather obvious that the program I posted does nothing useful at all and was created in about 90 seconds to demonstrate what I perceived as a problem with as little extraneous detail as possible.  I guess I should not assume things.

The outer while loop won't iterate until ALL the code inside of it is done. This is a basic DATAFLOW principle. The event structure is done because it waited untilt he event was fired. But the inner while loop is not done. And it will never be because you have a False wired to the stop button.

OK I understand that now although I am puzzled by the fact the first time I press the button the event does fire but not subsequent events and why, after the first event fires the radio buttons are frozen even though, according to you, the inner while loop is still executing.

Turn on highlight execution and learn how LabVIEW works.

I have been programming in LabVIEW for the last fifteen years and been programming in every language under the sun for more that fifty.  I have succesfully developed commercial software (heart and lung sound simulation) using LabVIEW that is used by teaching hospitals all over the United States.  I don't need snarky comments.

[James.M]

---

I am puzzled by the fact the first time I press the button the event does fire but not subsequent events and why, after the first event fires the radio buttons are frozen even though, according to you, the inner while loop is still executing.

---

15 years and you don't understand how dataflow works yet?? The event structure runs the first time because the code operation order is waiting at the structure. Just sitting there. Waiting. Once it operates the first time, it would like to go back and wait again for the events, but that outside loop iteration hasn't finished yet because of the inner loop. The freezing of the front panel occurs because of a property of the event structure where it disables FP updating until events have been handled. You can disable this functionality, but then your event structure still won't operate properly when you try to press the Button again.

---

Turn on highlight execution and learn how LabVIEW works.

 I have been programming in LabVIEW for the last fifteen years and been programming in every language under the sun for more that fifty.  I have successfully developed commercial software (heart and lung sound simulation) using LabVIEW that is used by teaching hospitals all over the United States.  I don't need snarky comments.

---

 This was the best advice that could have been given and you won't follow it. Wire an input and an output wire to the event structure (just so you can see data flow stop at the structure) and you'll watch the highlight execution show you exactly what you're failing to understand.

[crossrulz]

---

@David_Lieberman wrote:

The outer while loop won't iterate until ALL the code inside of it is done. This is a basic DATAFLOW principle. The event structure is done because it waited untilt he event was fired. But the inner while loop is not done. And it will never be because you have a False wired to the stop button.

OK I understand that now although I am puzzled by the fact the first time I press the button the event does fire but not subsequent events and why, after the first event fires the radio buttons are frozen even though, according to you, the inner while loop is still executing.

---

The event structure is still runs parallel to your infinate loop.  So it will react to the first event.  However, the outter loop will not iterate since that inner while loop is still running.  So when you press the button again, an event is queued up, but the event structure cannot handle it because the outter loop needs to iterate and get back to it.  And since that event is not being handled and you have the front panel locked until event case completes checked in your event, the front panel locks.

[Grant_LECO]

I like having an indicator on the outer while loop index just to make sure I'm not running too fast. I think that adding a time out to the event structure is in this case acting like having a timer on a while loop. I mean it slows execution down to a reasonable level so the core doesn't get saturated. When you have a single core machine you notice that stuff right away because your mouse doesn't even hardly move. With multi core processors sometimes it's harder to detect.

[natasftw]

I might have been a bit harsh.  It's just beyond frustrating to see someone offering valid help to get a response with a list of credentials and a complaint of snarkiness.  They were trying to help.  Up until you complained about the help, everything was respectful.

Ask your questions.  Take part in the discussion.  I'm not sure where else you were looking for clarification.  I'm assuming you understand where things were getting hung up before?  The structure ran once and the while loop never had a second iteration so it never triggered the second event.

In a parallel to text based, a hardware interrupt still must be responded to in software.  In the case of this example, the software never responded to the hardware interrupt. The Event Structure queued up the event to respond to it when it had a chance.  But, it never had that chance.  As you continued to try changing events, you continued to queue them up. 

Here's the one minute example you asked us to make to see the behavior you were seeing.  I'm not adding anything extra to it.  You can see how the event structure behaves by itself.  You can add in extra code if you'd like to see how the extra code has an impact.

[David_Lieberman]

I feel very bad.  I was in a black mood due to other things, I read the posting quickly, thought I was being mocked and lashed out.  I am genuinely sorry.

Let me explain what this is all about.  It will be very wordy and if you don't want to read it, just move on.

About 12 years ago I wrote my first Labview application.  It was a heart sound simulator.  The idea was to enable a professor at a medical or nursing school to creat a heart sound scenario for use in a lecture. I developed it under the guidance of my business partner, a cardiologist.

The front panel consisted of about 100 controls, mainly sliders and buttons.  No, not all were visible at once.  There were menu items like "create a murmur" which would bring up the controls for configuring a murmur, etc.

The program consisted of two loops.  The outer loop created the heart sound, an associated EKG, etc., using the waveform VIs, mainly sine waves, white noise, filters, shapers, etc.  The inner loop played the heart sound through speakers and displayed the wave form and EKG on a rotating graph. The inner loop played continually and only terminated when one of the controls changed, at which point the outer loop recalculated the heart sound.  

This was in labview 7.  There were no event structures, so, in the inner loop I built an array with the current values of all the 100 controls and compared it to the array from the previous time through the loop.  If they were not equal the inner loop exited.  This worked but maintenance was ugly.  When event structures appeared I thought I was going to heaven.

This model, an outer loop which calculates and an inner loop which plays sounds was a model for simulators for lung sounds, abdominal sounds, carotid artery sounds, etc.

I have used event structures successfully for many smaller projects but the big ones have a problem with the event structure being locked out by an inner loop which does not terminate, despite the fact that I have waits within the inner loop. The code I posted was just an attempt to demonstrate that.

I will post a small VI (non executable) in a follow up post which will graphically represent the above.

[crossrulz]

---

@David_Lieberman wrote:

This was in labview 7.  There were no event structures

---

Actually, the Event Structure was released in LabVIEW 6.  If you had the "base" version of LabVIEW, you could not create one.  You needed at least the "Full" version of LabVIEW.

In general for non-small programs, you want a single loop to handle GUI opperations.  All that should be in that loop is an event structure.  You can then use queues, Action Engines, global variables, etc to tell your other loops what to do when the user causes an event.  And if you want to take it a step further, use User Events to send commands/data to your GUI loop to tell it to abort or display certain data.

[Grant_LECO]

I start all my projects with the JKI state machine.   If you haven't tried it then I suggest you try it out.  Email me if you want any help with coming up to speed on it.

http://jki.net/state-machine

[David_Lieberman]

"Actually, the Event Structure was released in LabVIEW 6. If you had the "base" version of LabVIEW, you could not create one. You needed at least the "Full" version of LabVIEW."

that's not the way I remember it.  I was using the Mac version at the time.  Could the Mac and Windows releases have been out of synch at the time?