NI DAQmxBaseReadAnalogF64() has conflict with Linux Inter-Process Communication (IPC).

[scstop]

Dear Sir,

  I find that a problem that NI DAQmxBaseReadAnalogF64() has conflict with Linux Inter-Process Communication (IPC).

  DAQmxbase 3.2 on Mandriva 2007. Hardware USB 6218.

(1) Description

  I need one process to read analogue data and send them to another process. Based on the sample program contAcquireNChan.c (provided in DAQmxbase examples), I add a few lines to enable one process (CLIENT) to receive Linux queue message from another process(SERVER). That is, SERVER sends out a message at a fixed speed, CLIENT wait for the message, and call DAQmxBaseReadAnalogF64() to get the analogue data. A very simple idea, but we need it for our project.

//SERVER

  While(1){

Send one message

Sleep(DELAY)

  }

//CLIENT

  While(1){

     Receive the message

     Call DAQmxBaseReadAnalogF64() and print the result.

  }

(2) Problem

  Without the linux IPC, the contAcquireNChan works very well.

  Once the linux IPC is involved, the converted analogue data is totally incorrect. I tested two situations.

i.                     If the delay in SERVER is 1s, the converted data seems to keeps at the initial value, which may change a little bit (just a few mV), but cannot follow the change of the input voltage.

ii.                   If the delay in SERVER is 10ms, the converted data sometime can follow the input voltage, but sometimes is incorrect. That is, I fixed the input voltage and test. For the first few seconds, the converted data are correct, but after a few seconds, the output will change dramatically, which is incorrect. But after another few seconds, the data restore to the correct values. And such process, correct -> incorrect -> correct -> incorrect, goes on and on.

  Is there possible that the NI DAQmxbase conflicts with Linux IPC?

  Would you please give me a sample on how to implement such IPC function together with NI DAQ?

Message Edited by scstop on 08-01-2008 03:21 AM

[scstop]

Here is my code

steps to run
(1)gcc -o send send.c
(2)make
(3)./send
(4)./contAcqurieNchan



Message Edited by scstop on 08-01-2008 03:34 AM

[Bueller]

Hi,

I was able to recreate the first case when the delay in the SERVER in 1s, but when the delay is 10ms , it worked fine.

Can u please double check the connections, and if I may ask why are you using this SERVER approach to transfer data?

Regards,

Faris

[scstop]

Dear Faris,

  Thank you for your reply.

  The acquired data varied on my side even the delay is 10ms in the server. I am sure that the connection is correct.

  At first, I plan to implement TCP/IP  sever and client on different and let the server get the acquire data from ethernet. However, I met the same problem using TCP/IP sockets. So I simplify the problem by just implementing linux message queue rather than socket. But the problem is the same when the delay is 1s.

  I have contact NI AE in Singapore. He suggested that I should set DAQmxBaseCfgSampClkTiming() to DAQmx_Val_FiniteSamps instead of DAQmx_Val_ContSamps, because my application acquires finite samples. However I tried so and get an error. I believe that I need to set the configuration of my application carefully. I tried some ways but have not got a correct configuration.
 
  Thank you for your help!

[Bueller]

Have you tried writing the data to file, and then read that file over the ethernet.

A side note, if you can use LabVIEW, you can use a shared variable.

Regards,

Faris

[scstop]

I have solved the previous issue. As James suggested, I configure the card to acquire finite sample. However I find that I need to start the task when acquiring data,  and stop the task after acquiring finishes. Now this method works fine.