Multiple Camera (1394) experience

[Mike Ashe]

Has anyone had a good experience in optimizing applications that use multiple Firewire (1394) cameras?

I have an application that needs to use 4 (or in the future 5) cameras at 15 FPS each, do some simple sizing and color detection on a single computer.

Doing the application and the functional architecture is not the hard part. Squeezing the last bit of efficiency out to get the speed up and consistent is the challenge. :headbang:

I am thinking of using the multiple buffers in the 1394 driver from NI. I am also wondering about how much to separate things out into different threads.

Tips tricks and examples are appreciated.

[cao_flex]

Hi Michael ,

I know someone can help you , He works for NI and has a lot experience in Firewire Cameras.

Please , send a email to Nestor.Sanchez@ni.com with your question.

Christian.

[MichaelS]

I have never been able to squeeze all the bandwidth out of NI 1394 driver. With max capacity of 400 mbps, performance becomes intermittent as you approach ca. 300 mbps of bandwidth (driver version current as of beginning of 2004, two Sony 1394 cameras, 8 bit 1024x768, 15 fps max, used).

[Mike Ashe]

I seem to be losing the IMAQ driver for 1394 (Firewire) B&W cameras on Windows restart. The cameras are Basler 601f black & whites. We are using the NI-IMAQ1394 driver and are doing our acquisitions using an external trigger from a conveyor, waiting on 1394 occurances to get our image(s). So far, so good.

We had the cameras (4) setup in NI-MAX as: cam0 ... cam3. When we shut down Windows and restarted we found that the cameras were "gone" and in both NI-MAX and Windows Hardware Manager the cameras were listed as a generic consumer firewire camera. When we tried to run the LabVIEW application software we got errors which we traced to the above problem. We can get the cameras back on line by going into MAX, selecting each camera and from the popup menu select to use the NI IMAQ-1394 driver again.

While this works as a work-around we obviously don't want the customer to have to go through this each time they shutdown and restart the machine. Hopefully I'm doing something simple, wrong, stupid, etc. I am troubleshooting from the customer's site.

Has anyone else seen this behavior and if so do you have a clean programmatic fix?

I will check back here a couple of times a day, but just in case the LAVA site is down or inaccessible from here please CC directly to me at:

michael.ashe@imaginatics.net

Thanks in advance everyone.

[MichaelS]

I seem to be losing the IMAQ driver for 1394 (Firewire) B&W cameras on Windows restart. The cameras are Basler 601f black & whites. We are using the NI-IMAQ1394 driver and are doing our acquisitions using an external trigger from a conveyor, waiting on 1394 occurances to get our image(s). So far, so good.

We had the cameras (4) setup in NI-MAX as: cam0 ... cam3.  When we shut down Windows and restarted we found that the cameras were "gone" and in both NI-MAX and Windows Hardware Manager the cameras were listed as a generic consumer firewire camera. When we tried to run the LabVIEW application software we got errors which we traced to the above problem. We can get the cameras back on line by going into MAX, selecting each camera and from the popup menu select to use the NI IMAQ-1394 driver again.

While this works as a work-around we obviously don't want the customer to have to go through this each time they shutdown and restart the machine. Hopefully I'm doing something simple, wrong, stupid, etc. I am troubleshooting from the customer's site.

Has anyone else seen this behavior and if so do you have a clean programmatic fix?

I will check back here a couple of times a day, but just in case the LAVA site is down or inaccessible from here please CC directly to me at:

michael.ashe@imaginatics.net

Thanks in advance everyone.

3811[/snapback]

I had very similar problem with two cameras. I think it is the driver bug. The way we tried to go around it was to use default camera names and "attach" them to the cameras (that is, cam0 was always doing triggered acquisition, cam1 is in free run etc). Note that if you would remove one out of four cameras, the settings will become invalid as the cameras will be renamed.

NI 1394 driver is not the best thing on Earth, to be honest. I think, they would rather sell you something like 1422 or at least 1409, not the driver.

Michael

[Mike Ashe]

... The way we tried to go around it was to use default camera names and "attach" them to the cameras (that is, cam0 was always doing triggered acquisition, cam1 is in free run etc). Note that if you would remove one out of four cameras, the settings will become invalid as the cameras will be renamed.

NI 1394 driver is not the best thing on Earth, to be honest. I think, they would rather sell you something like 1422 or at least 1409, not the driver.

3817[/snapback]

Hmm, another engineer I am working with just discovered a little more about the problem. We have been trying to use a Firewire Extension cable from SewellDirect.com since the computer needs to be further that 4.5 meters (14.7 feet) from the cameras. When we connect with just a regular 4.5 meter Firewire cable we do not get the problem on restart of Windows. But with the extension cable we do. It seems that the extension cable has some type of repeater chip at the end to boost up the signal so you can go longer than the 4.5 meters per the Firewire spec. This works okay, we are getting the images through the longer cable length, but on restart we have to reassign the NI-1394 drivers.

We have some powered hubs coming in Fedex. I am wondering if they will show the same problems, showing up as a generic on startup.

I guess the real issue is, is there a way to programmatically, through NI-MAX or LabVIEW make the devices use the NI-1394 driver.

[JohannS]

I have never been able to squeeze all the bandwidth out of <!--WORD2URL-01--><!--END WORD2URL-01-->NI<!--WORD2URL-02--><!--END WORD2URL-02--> 1394 driver. With max capacity of 400 mbps, performance becomes intermittent as you approach ca. 300 mbps of bandwidth (driver version current as of beginning of 2004, two Sony 1394 cameras, 8 bit 1024x768, 15 fps max, used).

3395[/snapback]

The bandwidth limitation is imposed by the 1394-1995 specification. Isochronous resources are limited to 80% of the total 400Mbps. Asynchronous resource use the remaining 20% of the bandwidth. The NI driver uses isochronous resources to transmit video data and asynchronous resources to control the camera.

[Mike Ashe]

Followup. I found out from NI that MAX does not allow programmatic access/setting of the driver/camera designation and probably will not for the next version either. They are making a couple of improvements that will be beneficial in the next version, but this problem likely won't be solved, so if you try to connect using anything other than a single cable (ie, extension cables or through a hub) you run the risk of losing the MAX setup/names of cameras each time you power down the PC.