Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

acquire images from 3 cameras in one shot mode with PCIe 8235

I would like to acquire images from 3 cameras starting at different times with different parameter setup with the PCIe 8235 GIGe board. With continuously acq it is possible but in one shut mode they often timeout when one of the other cameras starts acq. Is it possible with the 8235 board or do i have to have 3 separate boards (8231) ?
0 Kudos
Message 1 of 10
(5,085 Views)

Hello TOS,

 

How are you implementing the one shot mode? 

 

1.  AcquisitionMode = SingleFrame, Trigger executes when AcquisitionStart is called

2.  AcquisitionMode = Continuous, TriggerSource = Software, Trigger executes after TriggerSoftware command is executed 

 

The latter (2) is a preference as it does not stop acquisition and allows you to keep calling software triggers. 

You may also want to reduce StreamBytesPerSecond for each camera to ensure your image frame are not running into each other at the host adapter. 

 

Regards,

Paul

0 Kudos
Message 2 of 10
(5,079 Views)

Hi TOS,

 

The PCIe-8235 (quad-port Gigabit) is the perfect card for what you are doing. If each camera is connected to its own port then you don't have to worry about not having enough bandwidth for all the cameras and having to manipulate settings to allow them to share the bandwidth. Each port on that card is capable of running at full speed simultaneously. There is no difference between this setup and having 3 PCIe-8231 cards, except that the PCIe-8235 only takes 1 slot.

 

I suspect that you are running into some other problem with your application or configuration. Perhaps you are acquiring in IMAQdx's continuous mode with Get Next Buffer=true and by the time you get to the third camera the camera has stopped transmitting its images?

 

Can you post more details (such as cameras used, network configuration) as well as a snippet of your application that shows how you are doing the acquisition? Without more details it is hard to suggest what might be wrong.

 

Thanks,
Eric 

  

0 Kudos
Message 3 of 10
(5,074 Views)
Hi Thanks for the reply I am using 3 Dalsa line scan cameras (Spyder 3 GigE SG-11-01K40 1024pix).NI driver ver. 1.1.2.49158. Packet size=1500-8000. Resends Enabled, Network Bridge, Jumbo Frames=GigE Vision Only. There is enough bandwidth for the acq - no problem when the three cameras just continuously acq images. But I want to start the acq at individual time and only receive 1 image from each camera – ex. 1200 lines. Details of the implemented code: Initi: IMAQdxOpenCamera, CamLines, Exposuremode=2, AcqlineRate, ExposureTime, IMAQdxConfigAcq=OneShot or continuously doesn’t matter. Loop with the 3 cameras sessions in parallel: Trig, Delay cam1-cam3, IMAQdxStartAcq, IMAQdgGetImage, IMAQdxStopAcq, Wait for next trig.  I also tried in 3 separate loops one for each camera session. Same result. The sw works fine for the first many images then a timeout occurs and the acq restart and the next many images are fine and so on. The Timeout comes from all cameras. Is it possible to Start/stop an acq session while another session is acquiring from another camera at the same time? It works fine for a while.  Even if I stress the system with only one camera active acquiring I seldom receive a Timeout. Best regards  TOS
0 Kudos
Message 4 of 10
(5,055 Views)

TOS,

 

Could you attach your code or screenshot of it? The main thing I'm unsure about is that you say with 1 camera it works and with 3 it doesn't. The cameras should operate independently and with the same behavior as if they were alone (dependent on your code though).

 

Eric

0 Kudos
Message 5 of 10
(5,042 Views)
Hi Eric I have tried to attach a part of my test code. I the test the grab task is running in 4 separate loops. I have also tried in separate .vi’s and having the four sessions in one loop. All of them halts or timeouts, eventually. Regardless of using continuously mode or one-shot. In free run there is absolutely no problem. The next thing I am going to try is 3 separate GigE cards.  The system is an update of an old system including 3 liniscan cameras using 3 NI-1422 framegrabbers. They have been working fine for many years and we have made a number of these systems without any problems. Just change the cameras, the 8235 card and using the NI-IMAQdx drivers……. 

Best Regards TOS

 

0 Kudos
Message 6 of 10
(5,018 Views)

What version of the IMAQdx driver are you using? The version number you gave is just of the High-Performance GigE Vision driver on the network interface, not IMAQdx itself. In some older versions of IMAQdx there were some issues where if one camera timed out it could cause the other cameras to block as well in certain circumstances. It might not be the problem you are seeing but it might be helpful to make sure you are using the latest version.

 

Secondly, it sounds like you are making good progress with the Spyder3. However, there are many known problems with this camera when used in its GigE Vision-compatible mode (as opposed to using the QuickCam software shipped with it). Some of these problems show up as issues where adjusting the Dalsa Exposure Mode attribute will invalidate other features like exposure time incorrrectly. I believe Dalsa is working on an update to these camera to improve their interoperability with 3rd-party software.

 

In any case, there should be no difference between using the one 4-port 8235 and three independent cards unless for some reason the PCIe card was not linked at x4 speed (unlikely).

 

One issue I can see with your VI is that you have multiple loops all setup to wait for the "Next" buffer. This does not work so well with multiple parallel loops because the VIs will block for a minimum of one frame interval. While LabVIEW uses multiple threads automatically, at some point it runs out of threads to be blocked waiting for the "Next" image. This means that the ones waiting for an available thread will end up missing an image because by the time start waiting for the "next" image, an image has already passed by. You really want to be requesting each buffer by index (incremented each iteration) so that you get every image.

 

Another issue is that you set your continuous grab up for 1 buffer. With multiple cameras you'll probably want to set it to a larger number to make sure that you don't miss images since there's more jitter in your loop times for acquiring images from multiple cameras simultaneously.

 

Eric

0 Kudos
Message 7 of 10
(5,006 Views)

Hi Eric

 

You are correct, there is no difference using the 3 individual cards in comparison with the 8235 card. The 8235 work just as well and I have returned to the 8235.

 

I am using LabVIEW 8.6, Vision 8.6.1, IMAQdx 3.2.0 (think NI is working on 3.2.1).

 

Regarding the wait for "Next" buffer, I am not quite sure what you mean about running of of threads and waiting for next image. By using the start and stop acq I control when I want just one image consisting of a specific number of lines. Originally I wanted to do this by the one-shut configure and one buffer. It works great for some time......I have tried with one-shot - one buffer, continuously 3 buffers and many other combinations. It requires a lot of correct images for a period of time, but suddenly an acq exceeds the Timeout period 5 sec. for 100 lines, Exposuretime 1000us Linerate 5000Hz.

 

I have tried to acq by buffernumber - not sure I have done it the right way - is still fails at some time and is slower.

 

Finally I have contacted my camera supplier, regarding eventual firmware updates.

 

Best Regards TOS

 

have a nice weekend

0 Kudos
Message 8 of 10
(4,987 Views)
I have updated my Win XP SP3, with the recent auto updates by windows. This have reduced the problem considerably. I don't know exactely what specific uptade made the difference.
0 Kudos
Message 9 of 10
(4,970 Views)

Problem still occurs but now only 5 times of 20000 images.

0 Kudos
Message 10 of 10
(4,967 Views)