From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

temporary connection loss recovery for GigE

Hi, I'm trying to cover all my bases for a long running application and there is a failure condition that is difficult to detect. In particular, if you trip over a cable Imaqdx will eventually detect that the camera is gone and generate the appropriate error. However, if you trip over the cable and plug it back in fast enough (or if, as is the case for me, the clip breaks off and you quickly pull out the cable and push it back in), it simply times out...forever. Even with the camera plugged back in. In my application, the cameras are externally triggered, so a timeout is pretty meaningless. Nevertheless, I tried restarting the acquisition, which generated a different error, so thats something at least. Through trial an error, I discovered that if I attempt to call "read register2", then restart the acquisition, it recovers. If I just read the register, it continues to timeout, and as I said if I just restart I get an error. Something about that chain works.

 

My questions:

  1. Any thoughts on why this works?
  2. Do all gige cameras support the register read interface? Is this actually a safe recovery process?
  3. Is there a better/different way to detect this condition?
0 Kudos
Message 1 of 5
(2,534 Views)

Hi smithed,

 

To be clear, the cases are the following:

  1. Disconnect and reconnect camera - times out forever
  2. Case 1 + restart the acquisition - generates error
  3. Case 1 + call IMAQdx Read Register2, restart the acquisition - camera recovers
  4. Case 1 + call IMAQdx Read Register2 - continues to timeout forever

 

Is this correct? What is the error from Case 2? If you call IMAQdx Read Memory2 and restart the acquisition, does the camera also recover?

 

As long as the camera is GigE Vision compliant, it is supported by the NI-IMAQdx driver and therefore support the Read Register2 function.

Generally speaking, anything to do with quickly disconnecting and connecting hardware leading to unexpected behavior/loss of communication I would err on the side of preventing this from happening in the first place. Is it possible to get a longer cable? One with a clip perhaps to help preventing the cable from disconnecting from the camera?

 

Angela L.

0 Kudos
Message 2 of 5
(2,502 Views)

@lagelian wrote:

Generally speaking, anything to do with quickly disconnecting and connecting hardware leading to unexpected behavior/loss of communication I would err on the side of preventing this from happening in the first place. Is it possible to get a longer cable? One with a clip perhaps to help preventing the cable from disconnecting from the camera?


The updated cases are:

  1. Disconnect for >10 seconds and reconnect camera - detects missing camera
  2. Disconnect and reconnect camera - times out forever
  3. Case 2 + restart the acquisition - generates error "Error -1074360304 occurred at IMAQdx Stop Acquisition.vi Possible reason(s): Unable to set attribute."
  4. Case 2 + call IMAQdx Read Register2, restart the acquisition - camera recovers
  5. Case 2 + call IMAQdx Read Register2 - continues to timeout forever
  6. Case 4 with read memory instead of read register - camera recovers

The clip is just an example -- I have the devices connected to a target in front of me, so I'm testing different failure conditions. I think we can all agree that not having communication drops, if possible, is a good thing. However there are a ton of ways that the camera could become disconnected (or appear to be disconnected) for a short period of time from tripping over a cable to noise to a switch hiccuping. I want to make sure my application can handle this range of failures.

0 Kudos
Message 3 of 5
(2,496 Views)

Hi Smithed,

 

Thanks for the information.

 

Regarding Case 3, when a new GigE camera is detected, the XML file that contains the camera attributes is downloaded from the camera to the IMAQdx directory on your computer. Because the camera is not able to be recognized, we're not able to download the XML file to access any of the attributes, resulting in that error.

 

Is it possible for you to wait 10 seconds before connecting the camera again in the event that the camera disconnects?

 

As for the IMAQ Read Register2 or IMAQ Read Memory2 workaround, I wouldn't recommend this as a reliable solution as this is not the primary intended use case of those functions. Instead, when the camera disconnects happens and there is a timeout error, you could enter a safe state that closes out the camera reference and then reopens it again. Let me know if this option works for you.

 

Angela L.

0 Kudos
Message 4 of 5
(2,476 Views)

@lagelian wrote:

 

Is it possible for you to wait 10 seconds before connecting the camera again in the event that the camera disconnects?

 


We're talking about accidental disconnects, switch interference, etc, not a deliberate disconnect. 


@lagelian wrote:

 

Instead, when the camera disconnects happens and there is a timeout error, you could enter a safe state that closes out the camera reference and then reopens it again.


A timeout is not a valid signal for this condition, because my cameras are externally triggered. If I have to restart the camera every time I see a timeout, theres a significant portion of the time where I am not armed. I need to be able to distinguish between a timeout and the driver entering an error condition

 

 

0 Kudos
Message 5 of 5
(2,471 Views)