Repeat Scans Using DAQmx Read/Write

[Mcdan · Accepted solution]

Alfredo,

I've rearranged your DAQmx code a bit, though I can't test it, but it should show what I have in mind.

Dan

[AlfredoT]

Thank you Dan!

It works perfectly. I'll study the little changes you made in order to understand them and keep them in mind next time I'm programming something similar.

[Mcdan]

Jeff,

I remember why I've grown used to using a shift register with DAQmx tasks... The pesky for loop which iterates zero times.  If I remember correctly output terminals from such a for loop place default data on the wires... not good if you had a task with reserved resources wired into the loop!  However this is unnecessary in this case, as a while loop was used. Your point about the additional overhead incurred in this case is a good one!

Dan

[Mcdan]

Alfredo,

One quick correction to the VI I posted.  I think you'll want to change "ai/sampleClock" string constant to read "ai/startTrigger".

Dan

[AlfredoT]

I noticed that too but don't know what difference it will make.

[AlfredoT]

Dan:

I just made the change and tested it but I get an error message and the scan gets hung up. I'll leave it at sampleClock because it is working that way.

Alfredo

[Mcdan]

Alfredo,

In your case, the fix would start the AO task just a bit sooner.  I'm not sure what hardware you're running this with, but what typically happens is the following:

1) Start trigger is issued in DAQmx Start Task for your analog input task.

2) A short delay occurs.

3) A sample clock is issued to begin the acquisition of the 1st sample.

Explanation of Step 2:

For most devices (assuming E Series, M Series, X Series or S Series), the short delay (step 2) is by default two ticks of a 20 MHz (or for X Series, 100 MHz) timebase.  However, users can increase this delay pragmatically via the DAQmx Trigger->Start->More->Delay property.  This would increase the amount of time between the AI Start Trigger and the first sample clock.

I suspect your goal is to start AI and AO at the same time.  With my original VI (ai/sampleClock), the signal which triggered your analog output would be the first sample clock.  This signal is subject to the delay I described above.  When you specify ai/StartTrigger, your analog input task will export the start pulse which will not be delayed as described above.

I hope that explanation is clear.  Please let me know if you have additional questions.

Dan

[Mcdan]

Alfredo,

Out of curiosity, what error did you see when you used ai/startTrigger?

Dan

[JÞB]

---

@Mcdan wrote:

Jeff,

I remember why I've grown used to using a shift register with DAQmx tasks... The pesky for loop which iterates zero times.  If I remember correctly output terminals from such a for loop place default data on the wires... not good if you had a task with reserved resources wired into the loop!  However this is unnecessary in this case, as a while loop was used. Your point about the additional overhead incurred in this case is a good one!

Dan

---

Well reasoned- And valid although, while loops must iterate at least once if you can reproduce the benchmarks posted later in the "Sean" thread I would be interested- there were a lot of background processes on the machine I used and the results were not difinitive.  

[Mcdan]

Jeff,

Are you referring to the benchmark VI you posted here?  If so, I'll have a go at it when I get a free moment or two.  If you have another benchmark in mind, please point me to it.

Thanks,

Dan