[Greg McKaskle]

The profiling numbers you show look suspect. I'm not saying they are wrong, but I'm saying that it would be good to verify them before making code changes.

Not having access to the code, I can't really do this independently, but I can hopefully ask some useful questions.

Are all of the timings you show above measured sequentially in the same task/thread? If they are in multiple tasks, it is easy for the OS to swap and double count an operation. In more detail, the OS commonly swaps for I/O tasks where a buffer or service may be busy. So if you measure time A, start I/O A, then the OS swaps and you measure initial time B, start I/O B, and at some point measure final time B, then the OS swaps back to measure final time A. This overlap of I/O and overlap of the A and B time intervals is very misleading as the A time includes the B time. Especially when measuring times via deltas, this can lead you to draw incorrect conclusions.

From your description, last year your images were less than 3K in size. That sounds like a pretty compressed 160x120. The sample code this year defaults to a medium sized image with low compression. This was to avoid heavy JPEG artifacts that blur the edges of the circles, and small images with big pixels also blur. You may want to look at the buffer size being written, or at the buffer size being received at the dashboard. You can also set the camera differently if you aren't intending to do cRIO processing for the target and see how the timings are affected by the image size.

Finally, you may want to look at overall cRIO processor usage. For a standard unix system, ps or tops or a similar tool will give an indication of overall CPU usage that is pretty trustworthy. For vxWorks, I believe that typing i at the terminal will give you a report with some CPU usage. I don't have one in front of me, so that may not be the command, or there may be a better one. Anyway, this can serve as a second indicator.

Finally, you may want to instrument the dashboard to see how many images you are receiving -- something like an fps number. This will give feedback not on cRIO load, but on frames being transmitted. Another parameter which may be different in the sample code than in what you used last year is the actual camera FPS setting. The LV sample code set it to 15 assuming that was fast enough for tracking. If you are processing on the cRIO, you may want to turn it up, especially if you use the small image size.

Greg McKaskle