Tradional NI-DAQ, DAQmx and RT Error

[RGSchmidt]

I have an RT application that uses Traditional NI-DAQ (have too due to having 4 AMUX-64T's in the system) and DAQmx for non-AMUX HW. The application works fine when it is downloaded from the LV 8.2 environment.

I created an executable of the application and placed in the rtstartup directory. Since I built with debug On, I have found that the AI Read call returns a warning code 10800 (timeout). I have changed the timeout default from -1 (LV calculates based on sample rate and number of samples to read) to 5 seconds and still get the timeout. When I look at samples read it is always 0 as is backlog.

I have built a lot of real-time applications and never seen this happen before. It appears that one or more files built into the application are different than those that get downloaded by LV.

Any ideas would be greatly appreciated.

I am using LV 8.2, Tradional NI-DAQ 7.4.1 and DAQmx 8.3 on a PXI-8186 embedded controller.

[David L.]

Hi RGSchmidt,

Thank you for contacting National Instruments. I believe this knowledgebase KB 3JSH9ISU will help you with your problem. Although this KB is for DAQmx, I believe the solution will carry to traditional DAQ as well.

[RGSchmidt]

Hi,

There is a 5 second delay at startup before making DAQ (Traditional or DAQmx). The DAQmx works fine as does the rest of application (TCP, UDP, queued state machine, etc.). The Traditional DAQ init calls work as expected, only getting an error on AI Read.

There are no references to any front panel controls.

Also, I am not referencing same HW with both DAQ drivers. All AI is through Traditional and all AO and DIO (all separate cards) through DAQmx

[Jonathan_Brumley]

I may be barking up the wrong tree here, but what is the first NI-DAQmx VI that runs in your startup executable? 
The NI-DAQmx 7.4 fix waits for devices to finish initializing when you call the first DAQmx function/VI; however, not all DAQmx functions were fixed and whether your app works may depend on which NI-DAQmx VI you first call in your program.  If you are using a VI like DAQmx Create Channel which creates a task, DAQmx will wait until all devices have finished initializing.  However, some of the more esoteric DAQmx functions (like the DAQmx System Property Node) do not wait. 

In a later release of NI-DAQmx, we fixed more of the NI-DAQmx VI's to correctly wait until devices are finished initializing.  (If you use the latest driver, currently NI-DAQmx 8.3.1, you will get these fixes).

---

The reason I may be barking up the wrong tree is that your symptoms don't seem like the typical startup app problem.

[RGSchmidt]

I am using DAQmx create Channel as the first call. Does Traditional NI-DAQ have the same issues (since error is AI Read and that chain)?

Thanks.

[Jonathan_Brumley]

OK, since you are using DAQmx Create Channel VI as the first call, the DAQmx driver should be fully initialized.

I am unsure why you are getting a timeout error with Traditional DAQ.   Here is something to try: are you calling the Traditional "Device Reset.vi" as the first VI before calling any other Traditional DAQ function?  Device Reset shouldn't be required (as far as I know); however, if the driver or device is in a bad state when it first boots up, a good Device Reset may "correct" the problem. 

Another thing to try is to add an insanely long delay (maybe 1 minute?) before using any Traditional DAQ function.  If there is a problem with Traditional DAQ on startup, this would be a way to confirm it. 

Is it possible your code has a race condition that is showing up when run at boot time?  One difference for boot time is that the processor and driver take a while to "warm up" (e.g. to make sure all code is loaded and all caches are populated).  The slower execution could be exposing a race condition in your code. 

[David L.]

RGSchmidt,

What hardware do you have in your PXI chassis besides the 8186 controller? Are you using DAQmx and Traditional DAQ on the same device or different devices? If different devices, are the Traditional DAQ and DAQmx code running in parallel or does the DAQmx code run, then the traditional DAQ code?

Does an Analog Input Traditional DAQ shipping example run OK on the RT target or does it give you the same error? Does the code continue to timeout or does it only timeout for the first couple reads?