01-05-2014 08:22 AM
Dear all,
I am working with an NI DAQ board (PCIe 6363), and am using a waveform as analog output to control a scanning unit.
Now, I want this analog output to be synchronized with the rising edge of an external TTL signal (the *fire* output of a camera).
To do this, I used the [Cont Gen Voltage Wfm-Int Clk-Analog Start]-template with minor modifications (see attachment with some comments included). Actually, this works, but only if the output waveform is long finished when the next TTL rising edge arrives. What I want, is a rising edge trigger which arrives, say, with 100 Hz, and an almost 10 ms-long waveform which starts with this trigger. Until now, I get it working with a ca. 8 ms-long waveform. It seems to me that the loop in Labview software (see attachment) takes the rest of the time. If I increase the waveform length to 9 ms or more, the loop is too slow and kind of misses the next rising edge trigger.
Unfortunately, I cannot use [continuous sampling] as there is too much jitter in the external trigger.
Is there a way to optimize this problem? For example, is it possible to tell the DAQ board 'put out this waveform every time you receive the trigger' instead of 'put out this waveform when you receive the trigger, then be silent' ? Or is it possible to run two while loops in parallel which alternately wait for the trigger signal and both use the same output channel ? Is there another, better, simpler solution?
Thank you for any pointers,
Peter
Solved! Go to Solution.
01-06-2014 07:59 AM
Ok, I found a similar problem now:
http://forums.ni.com/t5/LabVIEW/Restarting-a-DAQ-Task-Inside-a-For-Loop/td-p/1948479
But the solution there is basically the same as mine. Is it possible that this is already the fastest solution, set aside FPGA etc?
Any help would be appreciated!
Peter
01-06-2014 08:23 AM
Question: Why not sync the camera to the sine?
01-06-2014 08:26 AM
I found a possible solution for the problem. If I use the Control Task VI to commit the task before starting, this will possibly make the re-start much faster. I hadn't though of it before because the task state diagram shows these issues incorrectly, as discussed in this thread:
http://forums.ni.com/t5/Multifunction-DAQ/How-to-query-DAQmx-task-state-in-LabVIEW/td-p/1515460
I'll check this out when I'm back on a PC with Labview.
01-06-2014 08:29 AM
Dear Henrik,
how would you do this synchronization? Can you give me a link to a thread or method which gives an example, so that I can check this out?
(For controling the camera, I'm using Andor Solis.)
Best,
Peter
01-06-2014 08:52 AM - edited 01-06-2014 08:53 AM
@PierreLunaere wrote:
I found a possible solution for the problem. If I use the Control Task VI to commit the task before starting, this will possibly make the re-start much faster. I hadn't though of it before because the task state diagram shows these issues incorrectly, as discussed in this thread:
http://forums.ni.com/t5/Multifunction-DAQ/How-to-query-DAQmx-task-state-in-LabVIEW/td-p/1515460
I'll check this out when I'm back on a PC with Labview.
Ok, this does not inhance the speed significantly. So I am still looking for a solution. I will see whether I can get the synchronization done, but I'm open to any other propositions.
Peter
01-06-2014 12:05 PM
You should use the start.retriggerable property, something like this:
Best Regards,
01-06-2014 03:04 PM
Hi John,
thanks a lot! I'll test it tomorrow.
Peter
01-07-2014 01:41 AM
@PierreLunaere wrote:
Dear Henrik,
how would you do this synchronization? Can you give me a link to a thread or method which gives an example, so that I can check this out?
(For controling the camera, I'm using Andor Solis.)
Best,
Peter
Well, these scientific cameras usually support external triggering ... and you can output a triggerpulse in sync with your AO
01-07-2014 07:20 AM
Henrik_Volkers wrote:Well, these scientific cameras usually support external triggering ... and you can output a triggerpulse in sync with your AO
Basically, yes. But the external triggering normally leads to a delay of some 100µs with a jitter of some 100µs, too. Otherwise, this would be the first choice option, I agree.