Can not press button while looping

[Brad G]

Hi all... hoping to get some design tips as I'm very, very new to LabVIEW. I've taken over a project someone else had started and I've run into a problem I don't know how to solve.

I'm using LabVIEW ver. 8.0.1, and I think my problem has to do with using DAQmx in a while loop. In "Working.vi" (includes subVI "Temp Data to CSV.vi"), I copied-and pasted the while loop into a blank VI for testing. In this VI, with nothing else, it works - slowly, but it works.

In the real VI, I can see the temperature data update every 4 seconds, so I know the program isn't frozen or anything like that. However, pressing the "Return to Main Menu" button does nothing - the button graphic doesn't show that it's being depressed, no matter how many times you click and/or click-and-hold the button. I've attached a screenshot of the while loop inside the real VI; I'd prefer not to attach the real VI (especially since it contains references to many subVI's, and it's presently not contained inside of an LLB).

Am I coding this the wrong way? I have a feeling that it might be caused by my DAQmx settings (Continuous Samples, 2 samples to read, 250 mHz). Would the very low rate be causing this? Is there a better way of having the temperature readings taken every 4 seconds (approximately)?

[RavensFan · Accepted solution]

Do you have your event cases set to "lock front panel" until complete?  If so, then no other button presses will be recognized until the currently running event case completes.

It is never a good idea to have any code in an event case that takes a long time to run.  It will make your user interface seem laggy or even non-functional.  Any time I see someone with a while loop inside of an event case, I get scared.  (By the way, I'm also concerned about all those feedback nodes hovering over your event structure?  What are they doing?  Why are some operating on default data?)

In general, events should take no longer to run then what an ordinary person might expect before they feel like the user interface is delayed.  Perhaps 1-2 seconds tops.  You should be looking at a producer/consumer design pattern with events.  Your event structure should react to user interface events, then pass commands by a way of a queue to the part of your program that does the real work.

[Brad G]

"Do you have your event cases set to "lock front panel" until complete?" -- *heavy sigh* Boy do I feel like an idiot. Did I mention I was very, very new to LabVIEW? 😞 This seems to have resolved my main issue, but I'll also address your other concerns...

"It is never a good idea to have any code in an event case that takes a long time to run.  It will make your user interface seem laggy or even non-functional." -- I didn't know how else to add this functionality. The Event case is basically handling a menu on the first page. When someone clicks "Run Profile", I want to show the page with a graph until either a) the profile ends (takes anywhere from 6+ hours) or b) they press a button to return to the menu.

"(By the way, I'm also concerned about all those feedback nodes hovering over your event structure?  What are they doing?  Why are some operating on default data?)" -- That is the way the person before me (also new to LabVIEW) designed the program. The feedback nodes transfer data from one page to the next; information is entered on one screen, and the Event Case is set such that when the pushbutton on that page is clicked, it moves to a new page, processes the data, etc.

Why are they using default data? Basically, a given node might only be used to transfer data from Page 3 to Page 6, so for the rest of the pages the node is simply unused. I know this probably wasn't the best way to do it, and if I can get this project working I might revisit this giant event case and clean it up a bit.

"Your event structure should react to user interface events, then pass commands by a way of a queue to the part of your program that does the real work." -- I'll have to find some tutorials/example VIs and whatnot that deal with that type of a command flow. I've never used queues before, but what you're saying does make a lot more sense than the way it present works.

[Brad G]

Also, is there a better way to get the DAQmx instance to only show/update the thermocouple readings every ~4 seconds?

With the low rate that I have set, I do achieve the desired results, but it causes the rest of the code to hang every 4 seconds. In other words, if I press the "stop" button as soon as the information updates, I have to wait ~4 seconds for it to actually take effect.