synchronize two DAQmx Read task

[feilong]

Hello All,

   I try to synchronousely execute two DAQmx Read task, because there's are two PCI DAQ board collecting data. One board's sampling clock and trigger  are driven by one external signal from the third device, and the other board shares this clock and trigger by RTSI cable.

   Right now The two DAQmx Reads function in my VI seems not to sample simutaneously, and it's most likely to run one after another, although they are parellel layout in the VI. My guess is any of the DAQmx read need to wait all the sample have been collected then return the control to operation system, therefore another read task could launched by system.

So I want to know how can I lanuch these two tasks at the same time? I think it's feasible because labview could just start the tasks on two PCI DAQ board seperately and let them finish on their own.

   I noticed there's a 'how many sample per channel' option in DAQmx Read and I set it to -1, as I think the other option will lose data as it said only return what ever collected. please correct me if I am wrong. I am using finite sampling.

Thanks for any information

feilong

[jdunham]

Feilong:  It sounds like you are doing everything right.  The DAQmx Read function is reentrant, so you should be able to call two instances in parallel.

Some ideas:

1. Check the LabVIEW DAQmx examples.  There are plenty of synchronization examples
2. Don't use "auto-start" on the read functions.  make sure both tasks are configured before either task can start.  With a finite buffer it should not matter when you read, as long as the tasks start with the same timing signals.
3. Maybe you should post some test code so that we can see whether anything is amiss

[F._Schubert]

You can make one task use the reference clock of the other and share the trigger (set one task's trigger to the others start trigger, then you can use start task).
Good examples can be found here:
http://zone.ni.com/devzone/cda/tut/p/id/3615

Felix

[feilong]

Thanks guys,

    I've studied a few examples and modified my vi. as it's now attached.

    But now I found a even more fundamental problem. That is the uncertain delay between when my first sample collected and when trigger signal appears. as shown in data collected in 'engine cylinder pressure' channel. my trigger signal is the encoder z output (once per rev) and sampling clock is encoder A output (1 pulse/deg). the z signal has a fixed angular relationship about engine crankshaft. So if the sampling starts exactly after the trigger appears, the cylinder pressure data collected should always start from a fixed crankshaft angle. But the data collected in a few times show they didn't start in the same crankshaft position. I posted the result too.

The engine speed is 1000rpm, so the next sampling clock after the trigger will appear in DAQ terminal in less than 1/6 ms (one sample clock period), is it too fast for my PCI-MIO-16E-4? or even if the board couldn't response so fast, as long as it's a controllable fixed time deley it will also be acceptable.

PS: because every engine cycle event takes up to 720 degree, so there will be 2 trigger signal appears during one cycle and either one will trigger the sampling process. Thus when look at the plot data in excel, it's possible to see two pressure peak has 360 degree phase shift. But any other phase shift is wrong and that's my question. 

[feilong]

second post following last one as only 3 attachment permitted in each popst.

[jdunham]

---

@feilong wrote:

The engine speed is 1000rpm, so the next sampling clock after the trigger will appear in DAQ terminal in less than 1/6 ms (one sample clock period), is it too fast for my PCI-MIO-16E-4? or even if the board couldn't response so fast, as long as it's a controllable fixed time deley it will also be acceptable.

---

I looked briefly at the code and it seems like you are generally going in the right direction.  I would check to see if there is any difference triggering the bottom acquisision on RTSI0 rather than ai/StartTrigger from the other device.

The next step is to put breakpoints in your code, and check when the acquisition is really starting.
I would write your tasksIDs to some globals, and then make a separate VI that monitors the task's Read.Status.TotalSamplesPerChannelAcquired property in a loop.  Then you can step through your code and see when tasks are really starting to accumulate samples.

[hoffiz]

Hi Feilong,

I will like to ask you why is your second task been trigger from the VI “Get Terminal Name with Device Prefix” if what you want to do is trigger both task at the same time, why not on use the RTSI 0 as a source on the second “start trigger” since the PFI0 line is been routed to the RTSI.  The “DAQmx timing” has the source set up as “onboard” on both task so each card is been clocked with its own “onboard clock; so they are not synchronize.

You VI also have the starting and stopping the task every time your loop goes around.  so your task its been created and destroy ever 10 ms. I think you should take a look at the examples “M Series Synchronization” if you go all the way to the bottom there is a library you can download with very good examples, “Fig 5 - Multi Device M Series PCI.vi” is your best shoot.

See how the example I’m pointing you to only have one while loop around the “DAQmx read” not including the “DAQmx start.vi”. Another good suggestion is simplifying your code as much as you can so first try to gather the data (no logging) the way it is suppose to and the worry about the logging. Your “xls”  files don’t have labels can you point me where is that you see the delay?

Message Edited by Jaime F on 09-25-2007 03:21 PM

[feilong]

Hello Jaime,

   Thank you for your advice.

   The reason I use “Get Terminal Name with Device Prefix” is to make sure second (slave) task not to miss the trigger. so when the master task (top one) sense a trigger and it will output the trigger signal on its ai/trigger terminal which is the trigger source for the slave. I learned this idea from NI example. before I made such modification in my vi, I did use RTSI line as the slave task's trigger too, but I found the delay problem and that's why I start to learn the example. But it looks like neither trigger configurations could eliminate the delay problem.

feilong

[jdunham]

You can also try triggering the slave task from the AI/SampleClock of the master task.  You may get a one-sample lag between acquisitions, but you shouldn't get any spurious triggers before the master task starts.

[feilong]

Thank jdunham,

   I have a question about the ai/trigger and ai/sampleclock. are they start to output signal (trigger or sampling clock) only when the task starts, even if the real sample clock for that task is always there all the time?

Thanks

Feilong