Slow cycle time for snap-shot applications

[Patrick@Vision]

Hi,

Is there something like a Get-Function in the IEEE1394 driver that doesn't require the complete setup of image aquisition and starting stopping grabbing on the camera ???

Some background:

I've juist recently I'v bought the Vision Tool with the IEEE1394 drivers, but quit experienced with Labview and a Vision in common but with a other Vision-addon (Promise). We build so called 3D Vison/Motion allignment machines with 2 or more camera, and geomertic system with 1 uptil 4 (mayby even more) cameras.

Uptil now the aquisition proces definied as;

- get image from cam1 with full bus speed (4095bytes for this camera per package)  cost approx 40ms -> start proccessing this image.

- parallel switch to cam2 and get an image from that camera with full bus speed -> proces this image.

Total cylcle approx 100ms.

If I want to do to same with the National drivers JUST selecting and starting the grab cost approx 200ms, then the ussual 40ms for getting the image, but then stopping the grabbing any cost about 50ms. In total for 2 cameras approx 400ms.

Alternative I'could assign 2048byte per camera (in 2cam application) and let them grab constantly. I that case the neede time would be 80ms per image + max 80ms per image for synchronisation, in total for 2 cams 160-320ms. This isn't an option as well.

Any help would be usefull.

Thanx

Patrick van den Akker

Philips GTD Aachen

Gemany

[BruceAmmons]

Patrick,

I think the 2048 bytes per camera option would actually work, but it would depend on your application.  Do you need to have the images taken sequentially, or would simultaneous be okay?  Does it matter which image is taken first?  Do you have to wait until after an event is complete (alignment, etc.) before taking the pictures?

When the cameras are running continuously and simultaneously, you can read either the last image taken (0 ms delay) or the next image acquired (up to 80 ms, probably less.  Should average 40 ms).  Worst case, if you have to make sure the image is taken after the event is complete, you need to wait an additional 80 ms after the event.  Still, your maximum total delay is between 80 and 160 msec with an expected average of 120 msec.  If you can setup the cameras to reset on a digital signal, you could get the wait down to 80 msec.  The key thought here is that you can process both cameras in parallel, which cuts your delay time in half.

Bruce

[JohannS]

Patrick

All acquisitions, single shot or continous, go through the exact same configuration. Most of the time in configuration is spent programming the camera. In order to program a FireWire camera the driver reads and writes several register on the camera. For historical reasons each register access is artificially delayed for 5ms. While most modern FireWire cameras can handle quick sucession of register accesses, some older FireWire cameras would lock up under these conditions. The good news is that you can remove this artificial delay if you are using a modern FireWire camera. Navigate to the registry key listed below and change the AsyncTransferDelay value from 5 to 0. Reboot the machine and the configuration time should go down.

For NI-IMAQ for IEEE 1394 2.0.x
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\imaq1394k\Parameters
AsyncTransferDelay = 0

For NI-IMAQdx 3.0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\niimaqdxk\Parameters
AsyncTransferDelay = 0

While this should significantly speed up your configuration, I would not recommend that you perform configuration in a loop. Typically you should configure your resources once and then simply grab buffers as you need them. I would configure a continuous grab acquisition for each camera. If you only have one FireWire card, then divide the resources so that each camera uses 2048 bytes (when using 2 cameras). If you need to use the entire 4096 bytes per camera, then simply add a second FireWire card and dedicate each camera to a single FireWire card. With all your cameras programmed and acquisitions resources allocated, simple call GetImage inside the loop to get images from the different cameras.

Hope this helps,

Johann

[Patrick@Vision]

Hi

Thanks for responses. 

With my allignment applications 3 or 4 images are taken from each camera each cycle (which last 800ms),  after each movement an image has to be read-out with the

current position, it should look something like:  movement -> image1/2 -> movement -> image1/2 -> movement etc....

I've tried the suggestions but regradably this doesn't sattisfy me yet.

- Using two card instead of one: should do the thing in theory -> Problem; I have to sync with the next image cost avg 20ms, but secondly and even worse I

had a lot of distortions in the images.

- AsyncTransferDelay to 0 -> this speeds up the application pretty well, still stopping/clearing a grab cost approx 43ms, this is too much.

As said before; wiht an other vision add-on (that they've canceled, that's why Imaq now !!) with simular cameras it wasn't a problem keeping the aquisitiontime under 100ms.

Regards

Patrick van den Akker

[Patrick@Vision]

Hi,

One addition, for the ones using the Marlin F131 camera (probaly also the rest of the family), don´t put the discriped registry values to 0, but set them to 1. Otherwise you will have some problems writing the camera register every now and then.

Regards,

Patrick van den Akker