02-04-2010 05:05 PM
Hello,
I am writing an application that needs to capture data only while a key is pressed and held. DAQ stops if the key is lifted. The DAQ code needs to execute every 66 ms.
It seems to me that an event structure is the best way to capture key-up and key-down events. Once a key is down, a boolean 'record' will turn true until the key is up, when it turns false. This works just fine (see the attached VI).
The problem is in how the DAQ code fits in. I could have it be the timeout case of the event structure, and then only execute if the record is found true. However, I understand that the timeout is the number of ms to wait after an event is done executing before executing timeout. Is there a way to make timeout occur on a ms multiple of 66 instead?
If I take the event structure out and instead use Wait ms multiple to time the DAQ loop, how would I listen for a key press and release? Could I have parallel loops, one with the event structure and the other with the DAQ code and pass record between them as a global? Since only the event structure loop will change record and the other will just read, does this avoid race conditions?
This is the most complicated thing I have ever made in LabVIEW, so I want to be sure I understand what I am doing before I dive in and make a pile of spaghetti all over my BD!
02-04-2010 05:17 PM
02-05-2010 09:04 AM
02-05-2010 11:39 AM
That solution is very close to what I need, especially for the UI events. Thank you!
There is one little problem though: I don't want a 66 ms wait inbeween the return and the next call. Unfortunately, the hardware I am working with doesn't interface directly with LV, so we have to trigger it and collect data in a C++ dll. The quickest the hardware can run is around 66 ms a period. Since it gets glitchy when running at top speed, we want to regulate how often the call is made to the DLL (every 66 ms). The call will take almost all of this time to execute and return to LV. A state machine isn't quite what I need since I need to regulate the amount of time in between one call to the next (as opposed to the amount of time between after return but before the next call) and I cannot guarantee that the call will always take the exact same amount of time.
Also, I was planning on using a producer-consumer architecture for the DAQ and the processing of the data although it is unusual for DAQ to be so slow. Would that mean that I need three loops (UI loop, DAQ loop, and processing loop) and then have the DAQ act as the consumer to the UI and the producer to the processing loop, with a separate queue for each of the two relationships?
02-05-2010 01:27 PM
This sounds reasonable
jdubb9 wrote:That solution is very close to what I need, especially for the UI events. Thank you!
There is one little problem though: I don't want a 66 ms wait inbeween the return and the next call.
Also, I was planning on using a producer-consumer architecture for the DAQ and the processing of the data although it is unusual for DAQ to be so slow. Would that mean that I need three loops (UI loop, DAQ loop, and processing loop) and then have the DAQ act as the consumer to the UI and the producer to the processing loop, with a separate queue for each of the two relationships?
A UI Event Enquing Commands to a consumer loop that has two states "Start" and "Stop" (Toss in init and exit states for fun ) Start and stop states control a timed loop that acquires data and enqueues that data for processing by yet another function.
Sounds like good encapsulation of the functions, Good modularity for expansion, great abstraction of the details..... Good work!
At CCI (Plug ahead-) I have a similar archetechure for a test main-line. GUIevents enqueue commands to a test exec. Test exec enqueues vectors to Test State machine. Test state machine enqueues results to Data Distributor. Data distrubutor tickles the test exec when results a in, places data in a file and on the GUI Display. Add bells and whistles (user permissions, dynamic breakpoints, error recovery, automated Pizza ordering, etc....) and a pretty adaptable non-LVOOP application is born.
02-05-2010 03:07 PM
02-13-2010 04:01 PM
02-14-2010 06:04 PM
Quite welcome.
Good Luck
02-15-2010 10:50 AM
Good Day,
I am new to labview and i will appreciate some help! I am trying the to run a program for 8 hours a day(24hours), i tried timed loops and sequences and so many examples. Nothing seems to work. I am using a cFP-2120 and cFP-PWM-520. i am attaching the small program that i am trying to run. I am using LabView 8.2
Waiting for your kind reply
02-15-2010 10:58 AM
Don't hijack someone else's thread. Start a new thread. Provide more description as to how it isn't working for you. What are you trying to do and how is it actually behaving.