Multifunction DAQ

[John_P1]

Hello,

I'm running into a problem in DAQmx where the start trigger type does not properly get sent to the hardware in the following case (using X Series with DAQmx 9.5.1):

1.  Configure and run a finite counter output task with a digital start trigger (I have not tested other channel or other trigger types).

2.  Stop the task before a trigger is sent to hardware (I have not tested what happens if you do send the trigger to hardware first--in my actual application the task is retriggerable anyway).

3.  Try to configure the task to use no start trigger and start the task.

4.  Querying the trigger type in software at this point says "none", but the hardware is still configured to use the start trigger.  There doesn't seen to be any way to configure the hardware to not use the trigger at this point.

This is an annoyance for me as I would have liked to keep the same task handle around, but in order to switch between triggering and non-triggering modes I have to clear the task completely and re-initialize everything which is inconvenient for me given that in my application I have at least 2 threads capable of stopping the task and I can no longer simply provide the task handle to each thread upon launching it.

For a simple way to reproduce the problem, just try running the VI below:

You can tell the trigger is still configured because no pulse is generated and the loop does not exit until a trigger is provided on PFI0.  Reading back the trigger type using a property node you'll find that it is inconsistent with what the hardware is actually doing.

I don't really need a workaround (I should be able to come up with one myself which involves clearing the task whenever trigger properties are changed and storing task parameters myself rather than relying on DAQmx) but just wanted to report this as a bug.  The workaround is suitable for me but it adds a good deal of complexity to my application and is also inefficient since it involves unnecessarily clearing and re-creating tasks.

Best Regards,

[Kevin_Price]

I don't have suitable hw for testing, but snuck a peak under the hood of the two calls to DAQmx Start Trigger.vi

Just thinking out loud but I wonder whether things might work if you use the trigger property node directly and then specify a trigger source while setting trigger type to "None".    Actually, I'd probably try all combos of Type={Dig Start, None) with source={former source, empty terminal string} to see whether one of them might turn off triggering behavior without clearing the task.

-Kevin P

[John_P1]

Hi Kevin,

Thanks for the suggestion--I actually had tried setting the terminal to NULL already (should have probably mentioned it) but hadn't yet tried the full combination of settings.  It's an interesting observation that DAQmx Start Trigger (Digital Edge).vi sets 3 properties while DAQmx Start Trigger (None).vi just sets the 1, but writing the property nodes manually doesn't seem to affect the behavior regardless of the combination:

Trigger Type = None, Trigger source = anything.  The original trigger settings are preserved regardless of the trigger input (which I believe is ignored as I don't get an error for passing a Null terminal input).

Trigger Type = Digital Edge, Trigger source = something valid.  The new trigger source is configured and used instead.  

Trigger Type = Digital Edge, Trigger source = NULL.  Error -200797.

I have also tried using DAQmx Control Task to Abort and/or Uncommit the task and the trigger still persists.

For what it's worth I have my workaround up and running now and it's actually not too bad.  I'm completely clearing my task whenever reconfiguring (maybe adds a little bit of inefficiency but the whole clear=>configure=>start only takes about 20 ms with my PCIe X Series which is acceptable and probably not much more than it would be without the clear).  I also had to do a little OOP magic to accomodate creating tasks at runtime rather than initialization as multiple threads might be trying to access this task and I don't have anything to pass to them at initialization anymore (but this more relevant to my application architecture rather than this particular problem).

Best Regards,

[Chad_A · Accepted solution]

Hey John,

Good to hear from you.

I reproduced the problem and filed Corrective Action Request (365307) to track the issue.

Thanks.

[John_P1]

Hey Chad,

Good to hear from you as well, thanks for looking into it.

I came across another very similar problem today:

What size would you expect the array to be?  I'm getting 2 on my X Series (don't have other DAQ handy to test at the moment), but the full 1000 if I don't call start-stop in between trying to configure sample clock settings.  

Is there some other way to change the number of samples of a finite AI task?  It seems I will have to once again resort to clearing and re-creating my task.

Best Regards,

[Kevin_Price]

FWIW, under LV2010 and DAQmx 9.1.5 I get the desired size of 1000 for:

- simulated X-series

- simulated M-series

- actual E-series (PCI-MIO-16E4)

My only other idea would be to try out DAQmx Buffer property node.  I know it's needed to force a specific buffer size for continuous tasks, though it shouldn't be needed for finite where your requested # samples should be treated as an order, not a hint.  Still, who knows, perhaps it'll be a workaround?

-Kevin P

P.S.   Ok, just tried it out on this end.  Replacing the 2nd call to DAQmx Timing with a DAQmx Buffer property node caused me to get a size of 2 for all 3 cases above.  Returning to a 2nd DAQmx Timing call produced sizes of 1000 again.   Go figure...

[Chad_A]

Hmm.. the problem seems to be with passing -1 as the "samples per channel" to the DAQmx Read VI.  It looks like all 1000 samples are being acquired; if you pass 1000 to the "samples per channel" input, you get them all.

[John_P1]

Good catch--although I would have expected -1 to return all 1000 samples as well.

Best Regards,

[doug_2]

Hi John and Chad, Would you point me to the fix for the "Corrective Action Request (365307)", if there is one?

I have been fighting a similar problem. thanks, Doug

[fromm8]

Hi doug_2, the workaround for that Corrective Action Request (365307) is: clear and recreate the task, and yeah, there is a CAR.