Continuously Acquire Analog Input, Internal Clock, Pause Trigger, Multiple Device

[jon_mcbee]

Learn something new every day.  I am guessing it is very important that the fake counter output task starts before the AI DAQ task is setup and, and stops after the AI DAQ task is stopped.  Otherwise, I imagine interesting errors could be created.

[John_P1]

Actually... now that you mention it I'd start the "fake" counter task after the AI DAQ task.  I'm not 100% sure if this is necessary, but it seems like if you have the clock running upon startup that it might be possible for some devices to detect the first clock edge while others do not (if the clock edge occurs in the middle of the task starting).  Again, I'm not sure (perhaps the multi-device task has some sort of mechanism for preventing this) but to be safe I'd just start the AI task before the counter task.  You shouldn't get any errors on your X Series (although there are some other devices out there that do require an always-running clock, so your concern does make sense).

You can stop the tasks in whichever order you like.

Best Regards,

[jon_mcbee]

Sorry for the deadtime, had other fires to put out.  Attached is a mock up of this idea, I think it is working.  It is dirty, but just a proof of concept.  One question, I actually didnt expect the trigger to start DAQ as I am just simulating everything through MAX, does MAX send a square wave out on the PFI0 line by default?  I dont think I have any visibility into what is actually on that line (atleast not while simulating), how can I be 100% sure this is doing what I think it is doing?

Sample is in LV2011

[John_P1]

I believe that with simulated devices the task will start immediately regardless of whether or not you have configured a start trigger, and it won't really simulate having a pause trigger.

I guess to be 100% sure you'll need some actual hardware to run it.  What it should do is stop issuing ctr0 pulses when PFI0 goes low, which in turn will pause your analog acquisition.  Beware though that DAQmx Read is a blocking call--once the pause trigger is asserted and you are no longer receiving samples, the read call will block until the timeout is reached (once it times out it will return an error).

Best Regards,

[jon_mcbee]

I assume it will time out until the pause trigger is un-asserted, at which point it will start seeing data on the buffer and read it back in.  I will just need to filter on the timeout error.

Thanks!

[John_P1]

Yes, filtering the timeout error will work (although... your stop button would be unresponsive while the Read call is blocking, you might want to instead either poll the available samples before reading OR configure a DAQmx Every N Samples Acquired event).

Best Regards,

[jon_mcbee]

After a little more experimentation I discovered that some sloppy wiring caused me to not see an error being generated by this code.  I have attached an updated version of the proof of concept, where the error wire for the output counter daq is propagated.  This exposes error -89137:

Possible reason(s):

Specified route cannot be satisfied, because it requires resources that are currently in use by another route.

Property: RefClk.Src
Source Device: DAQ1
Source Terminal: None

Required Resources in Use by
Task Name: _unnamedTask<16>
Source Device: DAQ1
Source Terminal: PXIe_Clk100
Destination Device: DAQ1
Destination Terminal: RefClockInternal

Task Name: _unnamedTask<15>

Looks like I am back at the drawing board.

[John_P1]

I forgot to mention this, but using channel expansion is going to configure a reference clock.  You'll need to set the reference clock for any other task used by those devices to be the same source (since a device can only have one reference clock).  So in your case, you should just need to set the counter task to use PXIe_Clk100 as the reference clock.

You can set the reference clock source using a DAQmx timing property node (not on a LV computer at the moment so can't give a link).

Best Regards,

[jon_mcbee]

Sorry for taking so long to get back to you.  I have made the change you suggested and the code seems to work when run against simulated devices.  I am going to have the opportunity to test it out against real hardware this afternoon. The updated code is attached.

[jon_mcbee]

Just reading back through the thread, I must have missed it before, what do you mean by "configure a DAQmx Every N Samples Acquired event"?