Exact time for digital output

[boto]

Hi All,

I am trying to write this VI that acquires analog input signals continuously until the user hits the "trigger" button. At that moment, the VI will save X number of pretriggered samples and issue a TTL signal at the same time to one of the digital output lines to trigger another device. I also want to display the analog input signal in realtime so that the user can decide when to trigger. I have ended up with the VI in the attachment.

However, it seems there is an unknown delay between when the "trigger" button is pressed and when the digital output TTL is issued. I have the acquisition run in a while loop until the user hits the trigger button, then the operation will exit the while loop and issue the TTL. I wonder if this is an inefficient way of doing things, and would like to ask if anyone has a better idea to do this task. Alternatively, if there is a way to know the precise delay between the timing of the last pre-triggered sample and the time the TTL is issued, it would be OK too.

Thank you very much!!!

[johnsold]

It is better to keep things in one place. I posted a duplicate thread message in your other thread to keep the discussion here. Posting on Friday evening U.S time and then again Saturday morning does not allow much time for many of the participants on the Forums (who volunteer some of their time while working) to respond. Please try to be patient.

The problems you are having are more general LV than specific to the DAQ.

First, you will never get precise timing on a Windows OS (or any other desktop OS). To do that you need some type of real-time OS.

However, you may be able to get "good enough" timing by changing some things. You did not specify what "good enough" would be. You need to get rid of the sequencee structures and local variables.  They break dataflow and make it difficult to manage the behavior of the program.  Look at the Design Patterns for Producer/Consumer and for State Machines. One or a combination of both will be much better suited to what you are trying to do.  Nested loops and nested sequence structures are clear indications that you do not understand the dataflow paradigm on which LV is based. In particular the Write to Measurement File VI needs to be in a parallel loop so that OS file timing does not disrupt your program.

Next, let's look at the inner while loop - the one which monitors the analog signals and the user input to the Trigger button. There is no Wait or delay in that loop so it will run as fast as possible and hog the CPU. Such loops are called greedy loops and should generally be avoided. Use the event structure in a parallel loop to monitor the buttons. The user cannot respond in much less than 0.1 seconds so reading data at about that rate or slightly faster is sufficient. Also the monitor is updated typically less than 100 times per second. Writing data to indicators faster than that is completely wasted.  Repeated use of Array Subset and Insert into Array inside a loop will likely cause repeated memory re-allocations which are slow and may eventually generate an out of memory error. Replace Array Subset is more memory-friendly. You may need to add a shift register to keep track of the index to be replaced next.  Index Array can often do what Array Subset is doing, especially with length = 1.  I did not try to figure out exactly what you are doing with all the array functions but I am pretty sure that it can be simplified quite a lot.

As mentioned above the OS may introduce an uncertain delay between a button press on the screen and the generation of the DO signal. The use of the event structure to capture the button press will help. Although you may not be able to control the timing, if you have an unused analog input channel, you can wire the digital pulse to that channel and measure it. The timing measurement will havea resolution equal to your analog sample period. The default values in your VI make that 4 us.

Lynn

[boto]

Hi Lynn,

Thanks for the explanation. I am new to LabView and my previous programming experience in non-parallel programming doesn't help much.

Do you think an external trigger would work better in this case? (the external trigger goes to both a digital line on the NI box and this other device I want to trigger.) I would need close to 1ms precision. The other device is a high speed video camera operating at 700-1000 frames/second.

Could you recommend some resources for the dataflow on which LV is based so that I can try to read more?

Thanks again.

[johnsold]

I recommend that you start with the on-line tutorials for LabVIEW if you have not already done so. I am not sure how much they talk about dataflow but that is the place to start.  Search the LV help and NI whitepaper for dataflow. There should be some information out there.

I am not sure how a digital trigger would work for you. What determines when it should fire? Can you automate the detection of whatever it is that the user is  looking for while waiting to press the button?

Lynn

[boto]

Thanks Lynn. I am thinking about using the DAQmx trigger VI and set it to reference to an external (so there will be a separate small box that delivers 5V TTL when the user presses a physical button on that box). The output of this box will also go to the camera I want to trigger.

[johnsold]

That will eliminate the OS latencies from your system. Now all you need to do is make sure the user does not blink!

Lynn