problem with IMAQdx and GigE Scout

[LukasM]

The system based on PC has connected 5 cameras:
2 FiWi cameras (AVT Guppy)
3 GigE cameras (Basler Scout scA1000-30gc)

the FiWi cameras are going well for long-time. But the cameras GigE make after several hours working following problem:
The captured image remains static and does not correspond with the scene before camera. I thing the image is taken from the memory of PC and maybe this could be a driver bug. I use IMAQdx 8.2.1

Is there any solution to avoid this situation?

Thank you

Lukas M.

[BlueCheese]

Hi Lukas,

I would like to get a little more information about your setup so we can try to figure out what is going on.

First, when the images appear to stop updating, are the buffer numbers on the GigE cameras continuing to update or do they remain static? Depending on how you wrote your acquisition loop it could be possible that the cameras encountered an error and stopped but your loop is not stopping on that error. Perhaps you can post a snippet/screenshot of your code for your main loop?

Approximately how many images have you acquired before this problem shows up? You mentioned the problem happens after several hours, but are you running at the max frame rate of that Scout model, or are you running it slower?

What is the firmware version of your Scout? I will try to see if we can duplicate this in-house and would like to ensure the firmware is the same. I don't have a Scout handy at the moment, but I believe the useful version numbers it exposes are in the attributes "DeviceVersion" and "DeviceFirmwareVersion". You should be able to see these reported in MAX under the Camera Attributes tab.

Thanks,
Eric G

[LukasM]

Hi Eric,

thank you for reply. I make small changes in my application (CVI). In the UIR I visualised buffer number. When I used Basler camera, the number increased very fast up to the value 4 294 967 292 and than remained. The image was static from this time.
I changed cameras (Basler-AVT) and the number is increasing much slowly.

BTW: what will happen when the buffer number reaches the limit of uInt32 (I suppose it is 4 294 967 292)? Should it count again from zero?

In my application there are running continously two separate threads:
One thread grabs the images and is driving Gain and Shutter
Second thread is recognizing objects on image

I have to drive Gain and Shutter, because the cameras are taking outside scene.

I use following code to grab images:
IMAQdxGrab (SID, myImage, 0, &n);

Basler cameras have following firmware: 103129-03;U;scA1000_30gc;V1.0-6

From Basler I have following settings for cameras:
IP-camera |   Mask   |   GateWay??   | | IP of PC ethernet device
 

192.168.10.70	255.255.255.0	192.168.10.115		192.168.10.80
192.168.11.71	255.255.255.0	192.168.11.115		192.168.11.81
192.168.12.72	255.255.255.0	192.168.12.115		192.168.12.82

So every camera has it's own subnet. I do not use DNS from cameras and nework bridge.

[BlueCheese]

Hi Lukas,

Thanks for the additional information. The buffer numbers IMAQdx returns actually roll over at 24-bits for legacy reasons, and so the number you saw (4,294,967,292, ie 0xFFFFFFFC) is actually a special number indicating there was no image returned.

This would suggest that IMAQdxGrab is returning a non-zero error (perhaps IMAQdxErrorCameraRemoved or IMAQdxErrorTimeout) that your code is probably not checking. You might want to modify your acquisition loop to examine the error values returned and take action and/or notify the user of the error that happened (you can use GetErrorString to translate the numeric error to an explanation). This error will also help determine what is causing your cameras to stop working after several hours.

Given the firmware version on your GigE Scouts, I think it is late enough that there aren't any known issues that would cause problems with IMAQdx.

One possibility is that the camera is getting removed while you are using it because the automatic GigE discovery requests or replies are being dropped due to high CPU or network utilization, which may be happening since you have 5 cameras running. One workaround would be to disable the auto-discovery and just have your application initiate a discovery once at the start. To do this you can add/change the registry key "DiscoveryTimeout" to "0" under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\niimaqdxk\Parameters, and then add a call "IMAQdxDiscoverEthernetCameras("255.255.255.255", 1000)" into your application. However, we have an upcoming maintentence release (being released very, very shortly) that should improve our automatic discovery behavior under conditions such as this so I would actually suggest not implementing this workaround just yet.

If you can determine the exact error you are getting from IMAQdxGrab we should be able to determine if the above reason is the real cause of your problem or not.

-Eric G

[LukasM]

Hi Eric,

thank you for your message. You were right - I was not checking IMAQdxError. But I have following notes:

1) the frequency of described problem was more and more often. Then the remote computer *) was restarted and the message after the OS starting was that "The operation of system was re-established after the significant error" (I do not know the standard Windows text of message in english - I have localized version). Now after the two days of work the problem has not appear yet. Till now I did not make any modification of registry key "DiscoveryTimeout" and I am waiting what will be....

2) I modified the program to check the errors. But I made a test with FiWi cameras on my local computer *). When I plugged-off the camera during the program execution the IMAQdxGrab provided IMAQdxSuccess, although the number of frame was 4,294,967,292. Just the IMAQdxSetAttribute called the error IMAQdxErrorCameraRemoved. I do not know if this should be a proper reply of IMAQdxGrab or maybe it could be a small bug, because data are not going from camera but from memory. (?)

After the problem of Basler cameras will appear on the remote machine, I will let you know.

*) My application with 3 GigE and 2 FiWi cameras is going in factory on the remote PC. But I am developing and partly testing application on my local machine.

Best regards

[LukasM]

Now the problem has appeared again: The driver returns me error: Unable to set attribute. (Everytime when I try to set attribute ES or GC).

I will try to modify registry keys according your message and we will see.

Best regards

Lukas M.

[BlueCheese]

Hi Lukas,

Thanks again for your patience. I am happy to report that our new version of Vision Acquisition 8.2.2 (including IMAQdx 3.01) has begun shipping and is available for download. It is a free upgrade for users of 8.2.1. I'm not sure if all the links have been fully propagate throughout the website, but you can directly link to it here. I would suggest upgrading to this version since it should improve the behavior you were seeing with cameras getting removed while running.

Please let me know if this corrects your problems or if you still encounter issues.

Thanks,
Eric G