9205 read

[Madottati]

Hello all,

I create a simple DAQmx task, where I want to acquire differential signals using an NI 9205. As I don't know when I should read, I define a certain buffer for the data and let the unread samples overwrite:

Now, wwhen I read, I get the total nr. of samples acquired and the current read position, and I read relative to the most recent samples the -(result) number of samples.

This works, if I use a simulated 9205. But If I use a real module, a strange thing happens. The number returned by the "TotalSapmPerChanAcquired" and "CurrReadPos" seem to be returned always from the previously called read!

Is there any synchronization issue I have to take care? I have also other modules in the 9188 Chassis, but the only module I control in this case is the 9205.

[gregorelectric]

Hi,

could you upload your test VI? Also can you post a picture which visualizes the expected vs. the real result?

Thank You

[Madottati]

Sure!

meanwhile I have sent this VI to the NI support, they could reproduce the failure but they don't have any answer yet. The issue is forwarded to the eingineers in the USA. The problem comes ONLY with real hardware, with ismulated 9205 it works fine. 

Basically I just start a DAQmx task to acquire data continuously with an NI 9205. I wait 3 seconds before the first read, so there should be ~3000 samples available to read the first time. But at the first read I get 0 data. Then I read 50 ms later again (second read), and I get 3000 samples - as I would get the measurement data always from the previous read.

NI told me, it could be because of the time needed to transfer the data to the cDAQ Chassis and lauch task. But...if read the available smaples per channel property node after starting the task, and wait for at least 3000 samples instead of simply waiting 3000ms, it is working! The problem has someting to do with the driver.

I have a 9188 Ethernet cDAQ chassis, and this is the only task I use in it. I use a separate ethernet adapter for the 9188, no other ethernet device is connected. We also could reproduce this phenomen with an USB cDAQ chassis.  

Any idea would be appreciated!