LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Variability in execution time of a while loop

Hi All,

 

I am using LabView to control a CCD camera (Blackfly-BFS-U3-04S2C-CS). The goal is to track a particle. I have put the image acquisition sub-vi's inside a while loop. The camera is being triggered using internal software. The camera is set to 348 frames per second (fps). I expected that each loop execution time will be constant, and would be on average 1000/348 ~ 2.87 milli-seconds. To my surprise, I see significant variability in the execution time of some iteration of the while loop. Please look at the attached image. 

 

There are a significant number of instances where the time recorded between two frames is greater than 8 ms. That is not good for our applications, since we want the time duration between each frame to be as constant as possible. If the time between two frames become as large as 20 ms, we are in a bad situation. 

 

Is there a way in which we can make sure that each iteration of the while loop takes the same time to execute?

 

Thank you,

Avinash Kumar

0 Kudos
Message 1 of 8
(244 Views)

I think you're bumping right up against the timing accuracy of the operating system (Windows).  You are going to see significant jitter, especially if you are doing something that requires some significant CPU usage.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 2 of 8
(233 Views)

Windows is NOT a real time operating system, so execution times can vary due to interrupts, multitasking, and time slicing to name a few.

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 3 of 8
(222 Views)

Your loop is doing multiple things at once: trying to acquire images, save images, run DAQmx Tasks, run a Math Script node, and maybe some other things that I cannot see as the diagram is bigger than my monitor.

 

You will need to break your loop into parallel tasks, for one, saving data should be in its own loop. Also Math Script is most likely slower than native LabVIEW code.

0 Kudos
Message 4 of 8
(207 Views)

First please save it as LV2012 or 2017 or something everyone can open it.

 

8 ms is tough in Windows. 

 

What others said about multiple loops.  If you use timed loops you have a chance as then you can assign each loop to its own processor and bump up the priority for that loop.

 

Consumer producer model is something to look into.

 

Make sure that your critical loop has NOTHING that deals with a front panel interface directly as all of those things end up in the same thread.  I suspect that this means that you have to pass controls, etc. into the loop using a notifier or a queue, or maybe just have a handshake using notifiers or queues where you pass an interrupt (that has no front panel indicator) to the critical loop so that you can change camera settings, etc.

0 Kudos
Message 5 of 8
(178 Views)

@Tom_Powers wrote:

 

What others said about multiple loops.  If you use timed loops you have a chance as then you can assign each loop to its own processor and bump up the priority for that loop.


 

Don't remember where I read it, but it is my understanding that timed loops are bad on Windows systems, they are only meant for RT systems, and can make performance worse on a Win Box.

 

mcduff

0 Kudos
Message 6 of 8
(160 Views)

Obviously you are not telling us the whole story. Can you explain the hardware and software environment in detail? Since you are using LabVIEW RT/FPGA timing functions, I assume this is not windows, right? What's the hardware? CPU? # of cores? Memory? etc. 

 

As others have said, you need to separate the time critical parts (Image acquisition) from the non-critical parts (saving, displaying, etc.) and LabVIEW has all the tools to do just that. I am sure we can point you in the right direction and give more specific advice once we have all the details.

 

And yes, there is absolutely no need for any Mathscript in the inner loop!

 

What does "mapping v2" do? Why does it need these huge reshaped arrays (one never changes!) to output a few scalars?

0 Kudos
Message 7 of 8
(158 Views)

@mcduff wrote:

Don't remember where I read it, but it is my understanding that timed loops are bad on Windows systems, they are only meant for RT systems, and can make performance worse on a Win Box.


The biggest thing about Timed Loops is they serialize everything in them.  It is all a single thread.  What this means is that code in your loop cannot run in parallel with other code inside of that loop.  With a normal loop, the compiler makes "clumps" and each clump is able to run in parallel with other clumps that do not have a data dependency, which typically improves performance.

 

But Timed Loops also forces itself into a time-critical priority.  This means it is easy for it to swamp out any other process that could be running, not giving them time on the CPU.  And with Windows, this could mean the display, making it appear like nothing is happening.

 

So Timed Loops are really only for time-critical, deterministic parts of your application.  And let's face it, if you have a time-critical, deterministic piece of code, it should not be on a Windows OS; it should be on an RT system or an FPGA.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 8 of 8
(147 Views)