VI Execution time longer than sum of subVIs' execution times.

[Thomas444]

Hello,

struggling with optimisation here. I run data acquisition on cRIO 9057 with five 9232 modules on max S/s (15ch @ 102400 S/s) and with this setup I get weird behavior of LabVIEW.

• I have a loop that gets data from DMA FIFO and writes them in RT FIFO (chunks of 10 ms, set for 7 seconds of data) to process in a separate loop. 
• There is a loop that processes the data and saves them to file in real-time. This can run for a loong time (like 180 s or so) as long as the RT FIFO does not overflow.

The steps of processing, designed into separate subVIs, are:

• Reading the FIFO and creating a data reference (1D array) (0,6 ms)
• Reading this reference and checking for data continuity (through an additional incrementing channel) (0,4 ms)
• Reading this reference again and deleting it, decimating the array into separate channels, creating a new data reference (2D array) (1 ms)
• Writing the 2D array to TDMS file and deleting the 2D array data reference (~5 ms)

The times are taken from Performance and memory tool. The data is coming from the first loop every 10 ms, so there should be enough time left. But if I measure execution time of the series of the VIs, I get 15-30 ms and therefore RT FIFO overflows.

I tried:

• elevating the VIs priorities to time-critical
• wrapping the complete loop in VI and elevating its priority
• changing the loop to timed loop

without success. Upper VI:

Nothing special in the subVIs. They really take no time to execute.

Any ideas why this is happening?

T

 

[Thomas444]

One more thing, I noticed this behavior earlier when I had custom probes running, but i got rid of them and also minimized the number of generic ones.

[billko]

Probes of ANY kind are great ways of slowing your code to a crawl.

[dkfire]

One thing to notice, your timing is not forced by execution of the vi's 
You need to make sure that the time is taken at the correct place in the execution. Force it by using data flow of the wires. 

Save to file will also have a different timing, depending on the size of the file.  

[Thomas444]

Sorry, I missed the point to what you are writing. Can you be more specific? How is my timing not forced by the VIs in the loop? The loop does not simply pause for a while, the execution time of an operation is a sum of its serial operations times, right? If not, how to force it to happen?

[dkfire]

The first 2 vi's will run in parallel. 

Make sure that the time vi will run before the vi you want to measure. 

For the last time vi, I did not look correct at it. You have a wire running under it from right to left, this can hide the data flow. 

[JÞB · Accepted solution]

---

@dkfire wrote:

The first 2 vi's will run in parallel. 

Make sure that the time vi will run before the vi you want to measure. 

For the last time vi, I did not look correct at it. You have a wire running under it from right to left, this can hide the data flow. 

---

EDIT: NICE catch on the backward wire to error in 

And, that is only 1 problem...  I think that the OpenG functionality is to do NOTHING with error in TRUE. (Somebody please check me on that!) 

Essentially your benchmarking is the problem. 

Try using Stall Dataflow.vim and turn off automatic debugging on the vi

[UliB]

---

@JÞB wrote:

---

And, that is only 1 problem...  I think that the OpenG functionality is to do NOTHING with error in TRUE. (Somebody please check me on that!) 

---

In the OpenG VI the 'Error In' and 'Error Out' are directly connected, just feed through. No Case Structure. The VI will always return a valid tick count no matter what value 'Error In' is.

[Thomas444]

Allow debugging was the culprit here - turning it off caused the execution time to drop rapidly. Thank you for your advices. The Tick count VIs were just quickly placed without cosmetics, so it might be confusing for others. Thank you.