Error -200022 from two Ai modules in a cDAQ 9172

[jaustin_UF]

After working on a problem reading data from a 9205 and a 9219 in a cDAQ 9172 chassis, I’m hoping someone here can explain the bizarre error pattern I’m seeing.

In the attached zip, 9219&9205.vi is very simple yet shows the error pattern plainly. Neither configure vi gives an error, but the two reads ‘throw’ -200022 errors randomly, one then the other then both. When Start Task VIs are added (as suggested by Support), the second Start is an error source and its Read give the same error as in the VI without the Start Tasks.

I've checked the hardware as much as I can: clean the chassis connectors remove the unused modules, move these two modules to different positions, but still see the same errors.

Has anyone see anything similar or have suggestions for further tests?

Jim

[Dennis_Knutson]

This error has been repeatedly mentioned. It is not at all bizarre. Have you done a search for it?

The cDAQ chassis you have is a legacy one and it only has a single timing engine. You simply cannot create two separate tasks. You have to have a single task that uses both channels from the two devices. So, wire your second Create Channel to the task output of the first, have a single DAQmx Read, and change it to NChan.

[jaustin_UF]

Thanks Dennis,

I have searched the NI Knowledgebase as well as talking to Support twice, and am now waiting on an answer to my third message. I gather the problem has been ‘repeatedly mentioned’ here on the forum, although I didn’t find an answer clearly related to my problem (as yours does).

Unfortunately my application is far more complex (requiring AI, CO, DO, and DI on different timing schedules) than that simple test VI, so looks like this hardware is not suitable for this project. I do find it odd that NI would have made an 8-slot chassis through which all I/O must be combined into one task?! Thanks again for the information; it helps point me in the right direction.

Jim

[RCampbell]

Hi Jim,

That the cDAQ-9172 only has a single timing engine isn't entirely accurate.  It has a single timing engine per subsystem (AI, AO, DI, DO).  So all of your analog input has to be in one task, all of your analog output in one task, and so on.  Also, the DI and DO subsystems are not capable of generating their own sample clocks.  For an example of how to correlate your DI and DO tasks with one of the 9172's counters, see the DAQmx examples "Correlated Dig Read With Counter.vi" and "Correlated Dig Write With Counter.vi".

Regards,

[jaustin_UF]

Ryan,

I was confused by that earlier post, as I have had a CO task running at the same time without error. I appreciate your info as it makes the situation clearer.

It does bring up one question: does my CO task (continuous pulses on one line of a 9401) run on the DO subsystem timing, precluding a DO task (on the same 9401?

Jim

[RCampbell · Accepted solution]

Hi Jim,

Running CO on your 9401 will not prevent you from also running a DO task on the 9401.  For the use case you mentioned above, you can do the following for each type of task:

AI:  All the AI channels will have to be in the same task, and therefore running at the same sampling rate.

CO:  Run on 9401, as you mentioned you already are.

DI/DO:  You still have one more counter available, so you can use that counter to generate the sample clock for your DI or DO task.  See the example VIs I mentioned above for correlating your digital input or digital output with a counter.  

Since both the counters have already been used, you will need another way to generate the sample clock for the other digital task.  You have a few options here.

First, you can setup a dummy AO task (assuming you have an AO module and that you're not already using it for something else), and set the sample clock source to "cDAQ1/ao/SampleClock", replacing "cDAQ1" with the name of your chassis.  This is somewhat wasteful, since you wouldn't really be doing anything useful with the AO module.  

Another option would be to use the sample clock from the AI or the other digital task, or the output from your CO task.  This assumes that you can run one of the digital tasks at the same rate as any of the other tasks.  If that's not desirable, you could always resample the digital data at the desired sample rate.

The last options is to use software timing for one of your tasks, assuming that is at all possible.

I hope this helps you out.

Regards,