Getting the status of a task waiting for a trigger

[Phatin]

Part of the code I am writing involves a task with a hardware trigger.  While running this code, I'd like to be able to show the status of the software as either "Waiting for Trigger" or "Collecting Samples".  Does anyone know if there is a way to get whether the task is waiting for the trigger or collecting samples?  And I have considered having two separate tasks (a trigger task and a data collection task), but I would prefer to keep this all as one task.

To help in describing my issue, I've attached a small vi I created to test out some of my different ideas.  In this VI, there's not much difference between the time the channel is triggered and the time the read is completed, however, in the real program, the number of samples being collected is much greater, so there is a significant time difference. (To simulate this you can increase the number of samples taken, say from 1,000 to 1,000,000, just be prepared to wait out the data collection.)  So far my efforts have focused on using properties nodes to get information about the task/trigger/read (which are in the inner most while loop), but these typically will have to wait until the read function is complete before the property outputs.

So, does anyone have any ideas?  Thanks.

{Brief explanation of the VI: I'm using a cDAQ 9178 chassis, with a 9234 in slot 1, and a 9205 in slot 3.  I have a single velocity probe attached to the first channel of both modules; essentially the 9234 is providing the excitation source for the probe, while the 9205 is the hardware trigger.  Both channels will essentially get the same velocity signal.} 

[tbob]

You could use the DAQmx Read property node called Current Read Position.  I would guess if the output is 0, then the read has not yet started and it is still waiting for a trigger.  You could also use the Read Position to display a status bar, showing the user how far along it is in the read cycle.  This would be very useful if reading lots of data.

More advice:  Don't use a stacked sequence structure.  Put all the functions inline without a sequence structure.  If an error occurs in any sequence other than the first, you will lose the error.  It doesn't matter if the code stretches out a little more.

More:  It looks like your loop will run forever, and you have to press the Abort button to stop the program.  Bad idea.  Your DAQmx Clear Task will never run, and neither will the Error Handler after the loop.  Put a stop button and use this to stop the loop.  Never use the Abort button.  It leaves code unfinished.

Mistake:  Your very inner loop will run forever.  The outer loop will begin its first iteration and wait for the inner loop to complete.  If there is no error upon beginning the outer iteration, the inner loop will never stop.  Even if an error occurs, the Status boolean in the outer loop is never read because the code inside the inner loop is running, so the inner Status local variable will never get updated.  You are stuck in an endless loop.  So the outer loop will never go to the next iteration.  Just remove the inner loop and keep the code all in one loop.  The property node will update each loop iteration.  Use the stop button to stop the loop.

[Phatin]

I'm really not too concerned with the error handling since this is just a vi for me to try out differenct possibilities and I know that everything in the stacked sequence runs without issue; in the actual program, the errors are handled appropriately.

Neither of the loops will run forever.  The outer loops only runs once since there is a constant "true" wired to the stop command.  In essence I don't even need this while loops, it is actually just a remnant from a previous version of this trial vi when I did have it repeating.  The inner loop will stop running because the local variable for "status" will change to "true" after the read completes, thereby stopping the inner loop and allowing the outer loop to finish as well.

As for using the DAQmx Read property node, as I mentioned in the original post, I've tried pretty much all of those properties; and the issue is that the property node will not output anything until the DAQmx Read completes, which negates the whole purpose of telling me if the Read is waiting for a trigger or actually reading data.

Any other ideas out there?

[tbob]

You are right.  What I missed was the status local being set to True after the DAQ read.  This stops the inner loop.  I assume that you are expecting the inner loop to run many times before the outer one is done, therefore you can see a running total of the samples being acquired.  But it doesn't work because the DAQ is being tied up by the read, so the property node does not get updated until the read is done.  I'm afraid this will happen with any property node.

I was thinking that if you could modify the DAQ read vi, and put code there to send a running count as it is happening.  However, the DAQ read vi is nothing more than a DLL function call.  I do not see any way possible to have a running total, except to modify the DLL function itself.  Without the source code, it won't happen.

So what I did was break the DAQ read into several chunks.  If wanting to read 1000 samples, I created a loop to read 10 samples only, and read them 10 times.  This results in reading 1000 samples.  By putting the DAQ read into a loop, the property node has time to update.  The loop timing is critical.  The delay time in the read loop must be larger than that of the property node loop.  Here is the main loop.  I have attached the whole vi (LV2009), but I had to make some changes in the sequence to make it run on my system, so don't use that part.

[Phatin]

I actually ended up trying that out too; almost identically, with the exception of how you used a build array on the waveforms.  Anyway, I agree that the concept does work.  There is a small sacrifice of time for the whole vi to complete using this method; despite how minor this sacrifice is, I was still hoping to avoid it.

As you say, the only real way to get my ideal program may be to have a change to the source code, but I'm certainly not going to hold my breath on that.  Unless you or someone else comes up with another possibility, I think this method of reading in smaller increments from the larger total number of samples will have to suffice.

Thanks for you input.