gige three camera snap

[scoobydont]

Hi AllI'm using LV8.6 and a PCIe 8235 card with 3 GIGE cameras (Prosilica 780c) on a PC running XP sp3 with the latest vision drivers.My application requires that the PC receives an external trigger from a sensor via a PCIe 6320 card this is then used to to enter a loop. In the loop an image is captured then some processing is performed before exiting the loop to check for the trigger once again. The main point of the loop is that the image is acquired as soon as possible after the trigger is received and consistently so. When using 'continuous' configuration and `get image' as next with a frame rate of 60Hz images could be as much as 1/60s after the trigger. Using 'one shot' mode worked perfectly with a single camera but failed with 3. When running 3 with a simple vi as below a number of images would be acquired before the vi randomly encountered a delay in 'get image' of exactly 5 seconds.  I have overcome this by placing the 'configure acquisition' outside the loop with mode set to 'continuous'. I played around with lots of camera settings in MAX, including bandwidth, exposure times, packet sizes etc. to no avail. Has anyone got any ideas as to why this happens and is my solution o.k.?thanksDarren

[BlueCheese]

Hi Darren,

If I had to guess, it is because your buffer mode is set to "Next." Depending on the exact timing between when the camera starts acquiring and when the Get Image starts waiting, you will possibly be waiting for a future image instead of one that was just acquired. You likely want to request buffer 0 directly (also why are you using 10 buffers in a non-continuous acquisition if you only want to acquire 1?).

Also, you may want to restructure your application to put the configure/unconfigure outside of your triggered code and simply do a start/stop. This is much faster than a full re-configuration each time.

Eric 

[scoobydont]

Hi Eric

Thanks for the reply.

I've tried setting 'get image' to buffer mode and having config before the loop and 'stop aquisition' inside the loop, all with the same effect.

The delay always occurs in 'get image' so I'm guessing as you say the image has already been sent by the time 'get image' looks for it.

Is it therefore neccesary to introduce explicit timing into the code?

thanks

Darren

[BlueCheese]

Darren,

5 seconds sounds suspiciously like a timeout error. When you get this delay do you see an error? Are you triggering these cameras? Can you post your new code?

Eric 

[scoobydont]

Hi Eric

below is the version that works when slightly modified and iserted into a triggered loop.

Exactly 5 seconds does suggest a specific timer. I've searched all my MAX settings and those on the PCs network controller and found nothing with 5 second.

Thanks Darren

[BlueCheese · Accepted solution]

Darren,

The default timeout attribute in IMAQdx is 5000 milliseconds.

Are you triggering the cameras with a hardware trigger? You'd need to ensure you synchronize that with when you configure and start the cameras.

Eric 

[scoobydont]

Hi Eric at the moment we don't have the ability to hardware trigger the cameras although I may do this in the future.I seem to have arrived at a working solution by modifying the main Vi to a producer consumer loop with images being constantly acquired.The delay is as you say due to the time out in IMAQdx caused by not correctly synchronising the call for an image and looking to receive the image.Thanks for your help I’m off to dig deeper into NI Vision. Darren