Thread: Labview Slow Images Capture
View Single Post
  #14   Spotlight this post!  
Unread 22-01-2012, 10:29
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
  
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,751
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: Labview Slow Images Capture
I spotted the difference, but thought I'd introduce some new tools as part of the explanation.

If you goto Tools>>Compare, you can choose the From Scratch and From Dashboard and it will diff and explain all of the differences between the VIs. Clearly one has a big numeric, and one has some dT calculation. The key difference for performance is in the cluster's value. One image is 320x240, and the other is 640x480. If I change the scratch VI to 640, it is slow, and if I change the dashboard VI to 320 it is fast. I really mean large and small latency, but you know what I mean.

Next, I opened Tools>>Profile and ran the Performance Profiler on one of the 640 VIs. Click on the Start button, then run the VI for about five seconds, then stop the VI, then click on the Stop button on the profiler. You may also find it useful to click on the Timing Statistics checkbox, and that will tell you how many times HSL conversion was done for the time it took. It also does the min, max, and avg values. On my machine, it adds an average of 50ms to convert a 640x480 image to HSL. With data coming in every 33ms, "Houston, we have a problem". My computer has two CPUs, but the operation can only fit on one of them the way it is written, so my CPU usage is about 60% and I'm CPU limited. And indeed, the fps is about 20.

The latency is introduced because while the CPU is processing an image, 1.5 images arrive. So pretty quickly, the TCP buffers swell up and the video stream is lagging. If I drop the framerate from 30 down to say 10, the video will obviously get a bit choppier, but the latency is now something like 250ms. If you use the VIs from the robot, the one that reads the stream continuously in a parallel loop and sends the data across in a notifier buffer. This would allow the fps setting to degrade better and not introduce much lag. It didn't seem necessary for the dashboard, but can be used if you need it. Or you can drop the fps and tune it by looking at the CPU usage. Be sure to restart the VI, restarting the mjpg stream when the parameter changes.

Greg McKaskle