PCI-DIO-32HS with Dell Latitude D600 Docking Station Problem

[Philipp Spitzer]

Hello!

I have written a C++ Application that outputs one big buffer with a rate of 1.2 MHz while reading about 200 times data into smaller buffers (one by one, triggered) with 5 MHz using a PCI-DIO-32HS card. Everything works fine with all desktop PCs I have tried it.

To make the system more transportable we have bought a Dell Latitude D600 Notebook with a doking station that offers a PCI slot. The output works as it should but at about 1% of the input buffers the sampling seems to make a small pause: The buffer is written completely and no NI-DAQ error occurs but it looks like someone has cut out a piece of the data (for example right after sample #100 comes the sequence that should be about sample #350 - [these number are only examples]).

Has anyone observed a similar problem or does anyone know a solution for this?

Thank you!
Philipp Spitzer

[Sebastian N]

Dear Phillip,

there is a link (Performance Benchmarks For The High-Speed Digital I/O - NI 653x).

http://digital.ni.com/public.nsf/websearch/4FCA248D888831C386256D8900563E45?OpenDocument

I have one question, which NI-DAQ driver is installed on your Dell Laptop?

Hope the link help.

Best regards.

SebastianN

[Philipp Spitzer]

Dear Sebastian!

Thank you for your answer. My transfer rates are not beyond the the maximum ones from the document you mentioned (but sure, they are high and input and output is done at the same time).

I would "understand" if the rates are too high for the connection between the Laptop and the docking station or the laptop itself but the thing is: I get no error* and everythink seems to behave as it sould. But it seems as the card would "sleep**" a few µs during the input operation and continues then without an error (but misses the samples during "sleeping"). The buffer is filled completely with input.

* Maybe I haven't done enougth to get an error in these cases: I started the triggered, asynchronous transfer (with DIG_Block_In) and let me notify I it ends through a callback routine (configured with Config_DAQ_Event_Message):
in_callback(HWND handle, UINT message, WPARAM wParam, LPARAM lParam) {...}
Within the callback routine I compare lParam (the number of read samples) with my inbuffer size. If they are the same, I suppose that the transfer was done without an error.

** The "sleeping" is just a model of the problem - I can't tell what's realy going on. The problem is, that observation is difficult, because it happens seldom.

I had NI-DAQ Version 7.2.0f1. Today, I updated to 7.3.1 but the same happens with that version.


Thank you,
Philipp Spitzer

[Sebastian N]

Dear Phillip,


The problem seems not to be a driver problem. My Idea is, to test the board in MAX, if you can work in MAX without the "sleeping mode". I think it is a programming problem. If it works in Max like your application we must find a solution for the problem.
It is is difficult to measure that the board sleep for a few µs, hope you could test these.

Let me know whats happend.

Best regards

SebastianN
NI Germany