NI-DAQmx API calls work on M-Series but on cDAQ causes -50150

[sradbil]

I have a rather large application based on the NI-DAQmx C++ API that works on M-Series (E-Series and S-Series too) devices, but fails on a CompactDAQ device (NI 9205).

The failure is that a call to DAQmxGetAnlgEdgeStartTrigSrc() returns the -50150 error:
DAQmx Error: The software has entered an unknown state - usually as a result of a cascade failure induced by an unexpected series of state inputs. The operation could not be completed as specified and you should immediately terminate all further transactions if you are able to do so.
Device: cDAQ1Mod1

Task Name: _unnamedTask<0>

Status Code: -50150

Using the standard shipped example
C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Analog In\Measure Voltage\Cont Acq-Int Clk
I've narrowed the problem down to calling 3 calls. The full program is attached, and here are the 3 lines added to ContAcq-IntClk.c:

        DAQmxErrChk (DAQmxCfgAnlgEdgeStartTrig(taskHandle, physicalChannel, DAQmx_Val_RisingSlope, 0.10));
        DAQmxErrChk (DAQmxGetStartTrigType(taskHandle, &intData) );
        DAQmxErrChk (DAQmxDisableStartTrig(taskHandle));

The value of physicalChannel is set above in the line
        char *physicalChannel = "cDAQ1Mod1/ai0";  // cDAQ device (NI 9205)
When I comment out that line and uncomment this line:
        //char *physicalChannel = "Dev1/ai0";     // M-series device (PCI-6259)
the program runs fine.

If I comment out any one of those 3 lines the failure does not occur.
The call to DAQmxCfgAnlgEdgeStartTrig does not return any error code, which leads me to believe that it is setting the Start Trigger to the values I've specified.

Adding this line before those 3
        DAQmxErrChk (DAQmxGetAnlgEdgeStartTrigSrc (taskHandle, cacheTriggerSource, sizeof(cacheTriggerSource)));

shows that by default the Analog Edge Start Trigger Souce is APFI0. But this is odd because the help specifically states that:
The NI 9205 has no APFI 0 or APFI 1 terminal. Analog input tasks using the NI 9205 can trigger off one of the analog input channels being sampled by the NI 9205.

So one would thinking that using the physical channel "cDAQ1Mod1/ai0" should work.

The questions I have are:
1. Why should calling the sequence of DAQmxCfgAnlgEdgeStartTrig(), DAQmxGetStartTrigType(), DAQmxDisableStartTrig() cause a subsequent call to DAQmxGetAnlgEdgeStartTrigSrc() to fail with -50150?
2. Why does calling DAQmxDisableStartTrig() not reset all of the values to their original, good state?
3. How to I set the Analog Edge Start Trigger withough getting a -50150?

I've read http://digital.ni.com/public.nsf/allkb/21017DE39A3F17F28625727C0081FA99 which talks about Analog Reference Trigger (not Start Trigger) but since I'm only adding 1 channel don't see that this is the same problem.

Thanks in advance,
Sherryl Radbil

[JoeFriedchicken]

Hi Sherryl,

Thanks for such a detailed post!

In this context, that error code usually means that there is another problem elsewhere that doesn't have a defined error code. This use case has been reported as bug and will investigated.

Is there a particular reason you're following this specific sequence of calls -- what other functionality do you need that the shipping example for analog triggers doesn't provide (ContAcq-IntClk-AnlgStart.c)? From the looks of things, you set up an analog edge start trigger and then disable it. You should be able to use the trigger you have configured as long as you don't make the call to disable it. Are you seeing the wrong behavior when you do?

[sradbil]

Hi Joe,
Thanks submitting the use case as a bug.
Do you have a tracking number so I can recognize it when it shows up as fixed in a future release?

Ultimately what I'm trying to acheive is to find out whether or not the device supports Analog Edge start triggering.

The assumption was that calling DAQmxCfgAnlgEdgeStartTrig() would configure the start trigger to Analog Edge.
Then we query with DAQmxGetStartTrigType() and see if the value is really DAQmx_Val_AnlgEdge.
We need to do this because when calls are made to set a property the set call always show success, even when it didn't work.
To really know if you succeeded you need to call the corresponding get. The get call will return with an error when the corresponding set failed.

I would have thought that when setting a property to a bad value the set would fail, but it doesn't work that way.

Lastly, since we're just querying the hardware for capability DAQmxDisableStartTrig() was used t reset everything to the original values.

Playing around with this I believe that I can acheive my goal with this code:

        // Cache the current start trigger type so we can reset later
        DAQmxErrChk (DAQmxGetStartTrigType(taskHandle, &cacheTriggerType) ); // 10230 is DAQmx_Val_None
        printf("After CfgAnlg: Type %d\n", cacheTriggerType);

        // Configure to Analog Edge. This always shows success (that is, the return value is always 0)
        DAQmxErrChk (DAQmxSetStartTrigType(taskHandle, DAQmx_Val_AnlgEdge));

        // Did we succeed in setting to Analog Edge? This is the call that will show an error code, namely -200265 DAQmxErrorInvalidAnalogTrigSrc
        error = DAQmxGetStartTrigType(taskHandle, &intData);

        // Reset to cached values
        DAQmxErrChk (DAQmxSetStartTrigType(taskHandle, cacheTriggerType));

So I believe that this lets me work around the problem, but really configuring the property, and all properties, to bad values should return an error code on the set. You shouldn't have to even call the get to see if the set really succeeded.

Joe, another thing. I'm surprised that the NI 9205 is telling me that it does not support analog edge triggering.
Looking at page 17 of the Operating Instructions NI 9205 it looks like it should support it.
Am I reading the manual incorrectly or do I have a error in my code?

Thanks again!

[ryannorthington]

sradbil,

The Corrective Action Request (CAR) number for the bug you are referring to is 101441.  To get updates on the issue you can email or call in to NI and ask an Engineer  to take a look at the status.

As far as the return values of the set and get methods you referred too, we will investigate and file the appropriate documentation for that issue.  Thanks for the great feedback!

When you say that the 9205 is saying it doesn’t have any Analog Triggers, what command are you referring too?  This might be due to the bug you found that Joe filled. 

It seems that DAQmxDisableStartTrig() is not correctly setting the Start Trigger back to NONE according to CAR 101441.  If you are still using this command in your program then it could be causing the behavior you are seeing. 

I would follow the documentation for 9205 while the bug is being investigated.  I hope this helps!