Data Flow problem

[walter-donovan]

I have been diligently trying to understand and implement correct data flow in Labview. I have a slight problem now that I can't understand. While inside the inner loop (while loop) and the data acq is running, the program does not poll the capture button so it hangs in an endless loop. Since DAQ is set to read one sample, my logic says it should do just that and poll the button. I am running this as a simulated DAQ board at the moment, no physical board hooked up. Can that be the problem? Or is my data flow just plain wrong?

[altenbach]

You are locking the FP until the event completes (default setting), and since it can oly complete via user interaction, you are dealocked.

Go back to the event configuration and uncheck "lock panel...".

 In general, you should not have while loops inside events. There are better ways to do this.

Message Edited by altenbach on 03-07-2009 10:44 AM

[walter-donovan]

Thanks for the "almost immediate" answer. I forgot about that pesky switch. When you say "better ways", would you prefer 2 more events, both actuated by Capture button, one with true boolean, one with false? Why is the nesting bad practise? Because it blocks other events external to the while loop?

[altenbach · Accepted solution]

There are a couple of issues.

• You don't need a wait in a loop that has an event structure.
• Your timeout case is not needed, it basically just polls the return button. Better is to create an event for the return button.
• Yes, what good is an event structure if it is blocked with an inner loop from servicing events. You can use the outer loop for everything, it can spin the captures equally well via the timeout event.
• You should have logic to prevent capture until configured.

Attached is a quick draft on how you could change things. Since I don't have DAQ, I cannot test, so there are probably bugs. Still, you should be able to see the main ideas.

Let me know if you have questions. 🙂

[walter-donovan]

Interesting solution. I'll make particular note of this work flow. I especially like the way you wired the on/off button to a case and tied the return button to provide a simulataneous cancel in the event of a return. Good form in using an On/off button operation is something that has eluded me so far. Also your dynamic use of timeout values is something I've never considered. Alway thought you would normally pick an appropriate value and "set it and forget it". Thank you. I have learned a few things here.

BTW I have marked your second response as 'solution' rather than your first. The first was definitely a 'fix' but the second was a true 'solution'. I think that if I left the original nesting intact, it may have bit me with one of those unexplainable behaviors that can be hard to track down.

Message Edited by walter-donovan on 03-09-2009 09:07 AM

[altenbach]

In addition, you might want to place all the other controls inside the config event (there are only needed there) and trigger the config event whenever one of them changes. If you don't want them to be changed, you should disable them after configuration is done once.

Details really depend on the rest of your code. 🙂