daqmx CPU issue's

[LievenD]

Hi all,

I am having some issue's with using a cDAQ chassis with the following modules:

NI cDAQ-9178

16 channel analog output module +/- 10V

32 channel 24V sourcing digital output module

32 channel 24V sinking digital input module

32 channel +/- 10 V analog input module

8 channel +/- 20 ma analog input module

8 channel +/- 20 ma analog input module

Embedded network breakout box CAN

Embedded network breakout box CAN

NI 9862 CAN interface High Speed 1 port

NI 9862 CAN interface High Speed 1 port

I am currently not using the CAN ports and only using the Analog and Digital IO.

I have created a single loop where I would like to get data from every channel at 100 Hz (period of 10ms).

I am writing my commands for the outputs in the same loop at the same time.  I am also doing some conversions in this loop and I am writing everything to a global variable for use in the rest of the program.

However when I try to run my program I can see I am getting all the correct data but the loop finishes really late.

I am doing a single point multiple channel data acquisition on every card.  I also have two other fast loops running.  (one for data logging and one for automated profiles)  These loops are slow too.  When I disable the data acquisition loop it seems that the other loops are running fine.

So from what I can see I am doing something wrong in the Data acquisition loop.  I have tried implementing the Daqmx read property node and change the wait to yield but with no good outcome.  Any suggestions would be greatly appreciated.

I have attached a screenshot of my daq loop.  If necessary I can provide screenshots of individual components too.

Thanks

Lieven

[Esteban_B]

Hi Lieven,

Can you please send us the list of the cDAQ modules that you are using? Also I would like to know the software that you have, LabVIEW version and DAQmx drivers version too.

I was able to check the picture attached, I would recommend you to use one of the example VI’s to optimize your data acquisition code, so far you are using software time but based on your description you can use the hardware timing.

Regards,

[LievenD]

Hi Steve,

thanks for your reply.  I have the following modules in the cDAQ 9178 chassis:

Digital Input NI 9425

Digital Output NI 9476

Analog Input Voltage NI 9205

Analog Input Current NI 9203

Analog Input Current NI 9203

Analog Output Voltage NI 9264

CAN NI 9862

CAN NI 9862

The CAN modules are currently not in use. 

In the mean time I have had some time to play around with the unit.  Let me quickly describe my findings:

* Initially I tried to sample every input and every output on every card (except the CAN cards) by using the sample on demand and using software based timing.

The loop was set at 50 ms and nobody really cared about the speed of the data acquisition.  Now we want to get accurate data at 10 ms interval from all cards so I tried to change to loop rate to 10 ms.  I also started looking at the actual loop timing and this went up to 300 ms.  So I started taking out cards and disconnecting all the wiring to make sure no wiring issue was present.

When I only had the Analog Input voltage card in there and I tried to do software timed acquisition (one sample on multiple channels) the loop would still take 70 ms to finish.

That's when I started wondering if the unit had a problem or if I was doing something that was not possible with this unit.

* After that we started sampling every 0.5 seconds but record 50 samples and thus still getting 10 ms resolution on the data acquisition and this seemed to work.  Loop timing would keep up and we would acquire all the data that we wanted.

* So now I am wondering if that is the way the unit works, fast on demand software timed data acquisition is not possible but hardware timed, buffered acquisition works fine.

* Also I would like to know how I set up the hardware timing so I get my data at exactly 10 ms intervals.  I guess I should use the daqmx timing vi when I setup my task and specify the rate to 100 Hz, correct?

Best regards,

Lieven

[Esteban_B]

Hi Lieven,

When you do acquisition on demand, the software will determine the timing for your acquisition, in this case it will depend on the time inside the loop, the time that it takes to excecute all the tasks in the loop and also Windows time, so for example: If you set a time loop of 10 ms but the code inside the loop will take 20ms to execute, the actual time for the loop will be 20 ms. It also depends on Windows and all the other tasks that Windows is running at the sametime.

To prevent this, we have hardware timing, it is the timing that you set to the cDAQ to acquire data. In order to get data each 10ms you need to have a loop designated for data acquisition only, further data processing or storing should be done in another loop, you can have a producer/consumer architecture for that purpose.

A couple of examples:

Using Producer/Consumer Architecture for DAQmx Read and Write to File

Producer/Consumer pattern

I hope this information is helpful for you.

Regards

[LievenD]

Hi Steve,

thanks for your suggestion.  I used hardware timed acquisition yesterday.  I set my daqmx timing vi to continuous and rate of 100 samples/second.

Then I used the read daqmx vi in my labview loop that was running at 500 ms and acquiring Nsamples of N channels with 50 datapoints per channel.

I then bundeled all these arrays into one N dimensional array and wrote this into a queue to my data logging loop.

This way I am not losing any data at all.  This way I can reach the sample rate I want.

Today I will try the writing part of it but I guess the same logic would work.

Thanks & regards,

Lieven

[LievenD]

Hi Steve,

thanks for the examples.  I was just looking at the producer consumer example for daqmx.  The way I programmed mine was similar.  The only difference I see is that I added a wait until next multiple in my producer and consumer loops.  I don't see any here.  Is the hardware timing determining the software loop timing?

Thanks & regards,

Lieven

[Esteban_B]

Hi Lieven,

That is correct, when you have a while loop with a data acquisition task, the timing of the loop will be defined by the hardware timing that you set to the task. Actually if you add a software timing (like a Wait (ms)) you can have buffer problems when running the program for a several period of time. So, for hardware timing data acquisition, no timing VI’s are required inside the loop.

Regards,

[LievenD]

Hi Steve,

As I am getting further I seem to run into a few more issues.  I am trying to read from several different cards and I am starting to wonder now if all this data is synchronized.  As I will be datalogging all this data and I am setting up different tasks for the Analog Input, Digital Input and so on I am wondering if this would create any issues.

I also wonder how reading and writing data in the same loop with queues might affect the situation.

Any insight on this? 

Thanks and regards,

Lievn

[Esteban_B]

Hi Lieven,

As long as you use the same loop for all the I/O functions and you configure the timing VI for the analog tasks in the same way, you will have data “synchronized”. Reading and writing data in the same loop won’t affect the  configuration because the tasks will run in parallel.

Regards,

[LievenD]

Hi Steve,

thanks for your reply again.  Your help has been very helpful so far.  I have used the waveform write to spreadsheet vi to verify the timestamps on the waveforms.  These are indicating that all my read functions are indeed synchronized.  Now I was wondering how do I make sure if I send a waveform to an analog output, how do I make sure I get minimum delay on the hardware.  That is because I want to datalog all outputs and inputs on the same plot.

I have created a piece of code based on the examples shipped with labview to send out 16 analog outputs on my NI 9264.  I turned of regeneration and played around a little bit with buffer size and so on.  I can see that when I send my command through the software the output is updating quite quickly but that is measuring with a multimeter.  How do I know that the timestamp I added in my code is the actual timestamp that my signal arrives at my output?

Or how do I get it at least as close as possible? 

Could you have a look at my code and see what kind of settings I would need to add to have the best way to achieve this?

Thanks & regards,

Lieven