Very high cpu load when using analog input (VS2010 and VS2011)

[sirluke]

I'm experiencing a very high CPU load when using an analog input DAQ board (6224, or 6229).

I tested on a 8108 rt controller, both on VS2010sp3 and VS2011.

I created an empty project, with default configuration set to run at 1000Hz with only the 32 analog input channels.

The cpu load goes to about 45%, with no model or anything else running!

If I do the same test with 32 channels of analog output the load stays below 10%.

I cannot explain the difference in behaviour!

I tried changing a lot of parameters (like triggering, execution mode, hw timing) but nothing helps.

I found that the cpu load is linearly dependant on the number of analog input channels iported in VS.

There has to be sometihng wrong in the DAQ implementation.

Attached are a screenshot of the consolle and the system definition file.

[StephenB]

This is because analog output generally has one digital to analog converter per channel and your analog input boards (6224 and 6229) have 32 slow (250kS/s) multiplexed inputs.

When a DAQ multiplexed analog input device is initialized by NI VeriStand... the device itself will pick a multiplexing rate that is a balance between measurement accuracy and multiplexing speed. For 32 channels on your 6224 or 6229... if you request 1kHz (1ms step size) of the NI Veristand loop rate and all 32 analog input channels... the device will multiplex its inputs at 71,428.6 Hz. That means a conversion rate of about 14uS per channel. With 32 channels, it will take 448uS to sample all of the inputs. If your loop time is 1ms... then 44.8% of your loop is spent just digitizing your analog inputs.... which matches perfectly to your 45% cpu load.

So this is expected.

To reduce the time it takes to sample your inputs, you have a few options

• Use a simultaneously sampling DAQ board like the PXI-6358. It would sample all 16 inputs in less than a single microsecond.
• Use a DAQ device with a higher multiplexed sampling rate like the PXI-6255. At 1kHz and 32 channels, it would pick a convert rate of 90,909.1 Hz meaning a 352uS total convert time and 35.2% cpu load.
• Use the system definition setting to force the DAQ board to use its maximum convert clock rate rather than the letting the DAQ board automatically choose a balance of speed and accuracy. This setting is a drop down box on the DAQ device page in the system explorer. This will reduce your accuracy (consult the DAQ device manual to see how much) but greatly increase your conversion speed. For your 6224/6229 devices, they would instead sample at 250,000 Hz and therefore your total convert time would be 128uS and your CPU load would be 12.8%.
• Please note: Due to bug report 329328... this setting does not get applied on a DAQ device that has been designated as master on the chassis page. This is scheduled to be fixed in service pack 1 of NI VeriStand 2011. To work around this, you can designate something else as the timing master (an analog out card, an FPGA card, a DAQ board that doesn't have a bunch of multiplexed inputs, or nothing at all).

[sirluke]

What you say makes sense from a firmware point of view, but really it does not convince me from a high level software point of view.

What you say is that the M-series AI boards are totally dumb and require the os to do some work when sampling, keeping the cpu busy.

That's not true.

As a matter of fact I just tried making a simple VI using DAQ assistant to sample from all 32ch in HW timed single point at 1000Hz on the same controller and the cpu is @4%, not 45%!!!

The sampling is done on the M-series board, Veristand should just ask for samples and gather them when they are ready, not wait during the samplig process.

It's really disappointing that I'll have to make myself  a custom device to do a simple analog input in an efficient way.

It's also quite surprising that nobody has pointed this out before.

Regards.

Luca

[StephenB]

Luca,

It is important to make sure we are comparing apples to apples.

If you use a DAQ assistant in a loop, be sure you have hardware timed single point enabled as that is the sampling mode that should be used for a real time application. Using hardware timed single point phase locks your software loop to your hardware sampling clock.This ensures synchronization and minimizes latency.

Additionally, NI VeriStand uses the "polling" setting on DAQmx read instead of the default "interrupt" setting. The default interrupt setting makes it so the cpu usage is 0% until the data is ready and the polling data makes the CPU usage 100% until the data is ready. However, this has higher jitter and latency compared to the "polling" setting... so for Real-Time applications... polling is usually recommended because CPU usage doesn't matter until you have your data anyway. The reduction in jitter by using "polling" allows you to have higher loop rates.

Why is having this CPU usage a problem? Is there something else that needs to happen during the muliplexing delay that you don't have enough CPU for? The rest of the NI VeriStand loop can't do anything until the data is ready anyway... so I'm unclear why the 100% CPU usage matters why you're waiting for the data. Perhaps you have a custom device that needs the extra CPU?

If you really want to reduce the CPU usage, you can change the NIVS loop timing type on the controller page. By default this is set to automatic... which will time the NIVS loop with DAQ timing (if you have a DAQ card), wait for the sample clock to tic, and then poll for the AI data to be ready (at 100% cpu for this duration). You could change this drop down box from automatic to "daq" and then change the timing type to "sample complete". This means the NIVS loop will not wake up until all the samples have been acquired and should dramatically reduce your CPU usage. Please note however that the large 448uS muliplexing delay is still present... it just happens at the end of your NIVS loop now instead of the begining... so the CPU usage is lower but you only have 552uS of time before you need to write your analog outputs before they are late.

[StephenB]

Also, just for note... you can use the attached VI to calculate the multiplexing delays based upon cards and loop rates

[StephenB]

here is DAQmx code in LabVIEW that does hardware timed single point with polling turned on. similar to what NI VeriStand does

[sirluke]

Stephen,

I understand what you say, the point I'm triyng to make is that for some applications pipelining the acquisition instead of serializing would be more appropriate.

In automotive HIL systems the model execution loop may require a solver step time way below 1ms (200uS is sometimes required to avoid instabilities in models with high dynamics), so having the maximum available cpu time makes a big difference.

In that case it would be completely acceptable to do samplig in parallel with the model execution, thus introducing a unit delay on the sampled data (polling would not be necessary).

From what I've seen (and you confirmed) it is not possible to configure VS do act in this way.

[StephenB]

Ah I understand. Yes, I completely agree with you.

Good news is, when I said you only have 552uS left to set your analog outputs... I should have been more clear. This makes it sound like you only have 552uS for model execution... but that is not true by default.

NI VeriStand runs models in separate threads. By default NI VeriStand's "execution mode" (set on controller page) is "parallel" meaning the IO will be executed and the model will be executed in parallel.  There will be a 1 cycle delay. So if you have at least two CPU cores then your IO executes on one core and your model will execute on another core. If you have more models and you want to continue to enjoy this complete parallelism... you would need to add more cores.

You can also change the execution mode to be "low latency" which forces the NI VeriStand primary control loop (which does the IO) to wait for the model to finish. This eliminates the 1 cycle delay but also reduces the model execution time by whatever amount of time your IO takes.

This is covered in more detail inside the (just released!) NI VeriStand course: http://sine.ni.com/tacs/app/overview/p/ap/of/lang/en/ol/en/oc/us/pg/1/sn/n24:16050,n8:12380/id/1998/

Hope this helps

[StephenB]

If anyone wants to figure out the multiplexing delay of a particular card, they can use the VI attached. Just simulate the card in MAX on your local machine then run this VI with the selected channels and loop rate. There is also an option to force max convert clock to see the difference.

Note: there is a VI in a previous post that does something similar, but it has several bugs. use this VI instead