variation of frame rate with smart cam NI 1742

[ExpertiseVision_UM]

Hello,

I have an issue with a program on a smart camera NI 1742 and VBAI 2010 or 2011.

I check a part during his rotation. I have to make the maximum of acquisitions during the rotation.

In a fisrt state, I check the part if the part is in rotation. In a second state, I calculate statistics and I display the last image in a custum UI.

To check the number of acquisitions I make on the part, I put a counter in the custum UI.

When I launch my application, for the first part, I make 39 acquisitions, but for the next I make only 33 acquisitions. I don't understand this variation!!

Thanks for your help

Regards,

Ulysse Mathelin

[Brad]

Do you have multiple acquisition steps or use previous results for any of your acquisition settings? If so, the step(s) may be using different settings (i.e. exposure time), which cause the acquisition to take longer for different settings.

The vision algorithms you use may vary based on image content (i.e. Detect Objects will take longer if there are more objects in the image to detect). If the parts you are inspecting look different or you do different image processing algorithms, this couled affect the maximum rate you can inspect at.

You may be right at the edge of your acquisition rate. For example, your image processing may finish right when a new image is done being acquired and there may be a race condition that determine if the next image you get from the acquisition step is image N or N+1.

Are you using the Immediate or Wait for Next acquisition mode? Immediate will return immediately if there's already a new image available, where as Wait for Next will look at what the current image buffer number is and wait for the next one. I would recommend immediate mode unless there's a good reason to use wait for next (i.e. your inspection moves the camera into position and you don't want to take an image until you know the camera is at the right location or you know the part is in the right position).

Are you using a trigger? Perhaps the trigger rate is different for the different parts?

Hope some of these ideas help,

Brad 

[ExpertiseVision_UM]

No, I have only one acquisition step and i don't change the acquisition settings anywhere. I use the mode "immediate" and the camera is in free run.

I use the same tools for each part, there is only one part on the image and I use a caliper and a count pixel.

Only the first image has a different frame rate!!

[Brad]

Could you send your inspection and sample image of part 1 and part 2 to help us understand what your looking at. Does the part look very different as it rotates? How do you know when you're done inspecting the part (i.e. how do you know when it has made one full revolution)...do you have a HW signal that tells you when the part has finished making one revolution? Are you sure the part takes the same amount of time to make a full revolution for the first part vs. the second part?

Thanks,

Brad

[ExpertiseVision_UM]

Sorry for the delai,

I send my inspection with two images.

I recieve a trigger (TRIG=1) when the rotation start end when the rotation stop, the trigger go down (TRIG=0).

I check only one part at the same time. I don't think that there is a so big variation of the duration betwen the first and the other parts.

Thanks for your help.

[Brad]

Thanks for the inspection. It looks like there are about 9 steps in your acquisition state and you use the IO line to determine when the rotation done. You put the IO check at the beginning of the state, but you might get more consistent results if you put it at the end, right before you check the value to determine if you should continue looping or go to a different state. Something else you could try to help debug this might be to use a data logging step at the end of your acq state to see what kind of loop rate you get while acquiring and compare the first part with subsequent parts (to help make this as little overhead as possible, only write one result to disk). You could even have multiple data logging steps writing to different files to compare how long it takes to get to different parts of the state (i.e. one at the very beginning, one after acq and one at the very end). The data logging step logs the timestamp as well as the number of milliseconds, which can be helpful to figure out how long different parts of your inspection take with a decent amount of significant digits (although due to SW latency, there may be a fair amount of jitter from one run to another). The data logging will also help see if there is much difference between first part and subsequent ones for how long the IO line is high.

It might be interesting to disable all but your acq counter/IO step to see if this gives you consistent number of buffers acquired.

Hope this helps,

Brad