LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reduce processor load on PXI-8106 RT

Hi,

I am looking after a machine running LV RT.  The processors are running at about 85% load when the machine is effectively idle, and I want to reduce this.  All the DAQ, control, comms and other loops run all the time, with specific test VIs called asynchronously as required. 

I switched many of the signals from shared variables (single process) to functional global variables, as I had thought this wouuld be more efficient.  However processor loading is now up to 95% when the machine is idle. 

It is fair to say that there have been other changes in the code in the meantime, so I cannot be sure which change has caused this jump in processor loading.  So...

1. Was I correct to switch from shared varaibles to FGVs for efficiency?

2. Are there any easy ways to find out which VIs are using the most processor time?

3. There are 30 analogue channels in the system.  What is the most efficient way to get the data: collect raw voltages into the VI then apply scaling, or have the scaling defined in MAX and read the scaled value into the VI?

4. Any other general tips for RT efficiency?

 

The machine is currently running with LV 2012, due to upgrade to 2014 soon.

 

Thanks,

Ian

0 Kudos
Message 1 of 10
(3,001 Views)

@IanDeaville(ZF) wrote:

 

1. Was I correct to switch from shared varaibles to FGVs for efficiency?

2. Are there any easy ways to find out which VIs are using the most processor time?

3. There are 30 analogue channels in the system.  What is the most efficient way to get the data: collect raw voltages into the VI then apply scaling, or have the scaling defined in MAX and read the scaled value into the VI?

4. Any other general tips for RT efficiency?

 


2. Real-time execution trace toolkit. This can be very useful for that specific purpose. 

4. Avoid memory allocations when possible, especially within tight loops and for big arrays. Inline SubVIs. Don't use type cast. ... There are a lot of things to pay attention, but it all depends on the architecture, timing requirements, and other parameters of your specific implementation.

0 Kudos
Message 2 of 10
(2,977 Views)

dan_u,

 

Thanks for the tips.  I will certainly give the real-time execution trace tools a go.

 

I had noticed in a desktop trial that running a FGV with an enum as the "action" input is much slower than using a boolean.  Is that part of the type casting concern?

 

Would I be correct in thinking that inlining is not a good idea for FGVs?

0 Kudos
Message 3 of 10
(2,969 Views)

Ian,

 

using an enum as action input for the FGV seems fine, I only remember case structures take longer to execute if there are more than 2 cases. They are fast for 2 cases, and a bit slower for more. But even with an enum, no type casting should be involved. What is expensive on the RT is e.g. typecasting an integer to an enum.

 

Yes, FGVs can't be inlined, since inlining requires reentrancy.

 

There's another issue with inlining, the execution trace toolkit shows the execution time of VIs, but when inlined they disappear since they are then part of the caller. You might have to use the "TraceTool Log User Event" function to check the execution time of a code portion.

 

0 Kudos
Message 4 of 10
(2,964 Views)

Enums taking longer than boolean makes sense becuase LV has to do a "Case" isntead of a "Branch if True" type operation.

 

Switching to FGV may increase the CPU load since they can operate faster and teh thread does not have to stall invoking the less efficiant Shared variables.

 

If possible, let MAX do you scaling. It is more efficient.

 

Check any loops that you have running that do NOT have a "wait ms timer" in them. Hungry loops will gobble all CPU available. If you need your loop to run fast use a "0" wired to the "wait ms timer". That will run fast if the CPU is idle but will also allow other threads to get a crack at the CPU if they need it.

 

Tools>>> Profile >>> Peformance and Memory is useful for figuring out who is using teh CPU.

 

Ben 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 10
(2,947 Views)

We use a PXI 8106 controller for some experiments involving experiments in sound localization.  Our PXI system uses fairly old (>5 years, except for the controller) hardware, including a 96-channel DIO, a Timer/Counter, a multi-function A/D (we sample up 16 analog channels at 1KHz, but also add additional "digitally-sampled" channels, like digital encoders), and a separate D/A module.  We dedicate one core of the controller to the (single) Timed-loop, which we run at 1 KHz (because we are mixing analog and digital data, we acquire every point one at a time, then pass them out of the Timed Loop in an RT FIFO).

 

The hardware can definitely keep up with the data, at least in part because we do very little in the Timed Loop, and make heavy use of Producer/Consumer patterns.  Data are streamed (via Network Streams) to the Host PC, which displays data at 20 Hz (averaging 50 samples) and streaming all the data to disk.

 

Don't know how this compares with the data load and sampling speeds you are trying to achieve.  I will say that the original code that I "inherited" was not able to sample 12 channels at 500 Hz reliably (dropping data points), at least in part because the loops were doing "too much" (acquiring and saving, for example).

 

Bob Schor

0 Kudos
Message 6 of 10
(2,931 Views)

Folks,

 

Thanks for all your suggestions.  I have relatively limited time at that machine, but I will be pursuing the realtime execution trace toolkit with some vigour, as well as clamping down on the various loops that exist.  I will report more in due course.

 

Ian

0 Kudos
Message 7 of 10
(2,900 Views)

Folks,

The attached image is an extract from the RT Trace data.  I guess that I need to focus on the VIs that have long continuous blocks, rather than those that come & go very quickly, but I am open to your suggestions here. 

I am not sure what the Thread window is showing me to be honest.

Ian

0 Kudos
Message 8 of 10
(2,888 Views)

I'm concerned that you say "Processor is at 95% when the machine is idle".  Processor should be at 5% when idle -- if it is not, then something is very wrong, you are doing much too much inside your critical time loops (these should be doing almost nothing except feeding Queues or FIFOs if there are data present, and if there's no data, then the Consumer loops should be similarly idle).

 

I realize that your code is probably proprietary.  Maybe you could consider posting an "edited" version of your code (hiding some details, changing names, simplifying) so we can get a better idea of the structure of your RT code and can suggest ways to bring the "idle" time way down.  Alternatively, are there RT Experts in your area you could hire for a few day's consultation?

 

Bob Schor

0 Kudos
Message 9 of 10
(2,877 Views)

Bob,

 

Here is an edited ZIP file with the guts of the RT code present.  Some things I suspect might be going on:

- Analogue input scaling is not being correctly set, so all values are out of range.  This is causing the error detection & notification loop to run overtime.  When the analogue scaling works properly (or I switch to MAX tasks) this should improve.

- I have in mind to switch the Live Data function to use Network Streaming protocol, rather than pushing direct to the NSV.  Maybe also with a queue.

- DAQ here runs at 2kHz with some inline averaging to reduce noise, with controls & PID running at 1kHz below that.

- There are undoubtedly some non-critical tasks running unnecessarily in timed loops, albeit at low rates & priorities

 

I am open to all suggestions. 

 

Ian

0 Kudos
Message 10 of 10
(2,874 Views)