NI MAX: BFF6902C: Unable to connect to the camera

[Nelson_Bridwell]

We have VBAI and MAX installed on a Windows 7 64bit PC that is connected via 3 Intel Pro/1000 PT single and dual port NICs and a Black Box lpbg724a POE Gigabit Ethernet Switch that supports 9014 byte jumbo frames to 16 Basler Ace GigE cameras.  We are running the NI high speed drivers on these NICs.

We have 10 cameras on one NIC port, using the 2.n subnet, 4 cameras on the second NIC port, using the 3.n subnet, one camera on a dedicated 4.n subnet NIC port, and one camera on a dedicated 5.n subnet NIC port.

The system has been running successfully, but yesterday two of our VBAI programs would not start up in inspection mode due to camera errrors.

We can connect to other cameras on the subnet, using the same NIC.

When we look at the 2 cameras in question via NI MAX, we see them listed, but when trying to open them, we get the error dialog:

 
      BFF6902C: Unable to connect to the camera

We can ping the cameras from our vision PC.

I can also plug my laptop onto the net and connect to all cameras, accesss all the controls, and capture images, using NI MAX on my laptop (which is using the intel universal chipset driver).

We have tried power cycling the cameras, PC, and switch multiple times.  We have checked that the Cat 6 cable connections are secure.

After a switch warm boot the cameras came back, but then dropped off again later.  And at another point, 2 other cameras would not connect.

Any hints?  Could this be a problem with the NI Max camera description files, or does this sounds more like a bad ethernet switch?

Thanks in advance...  Looking forward to getting this awesome system working!!!

[Nelson_Bridwell]

It appears that I may have identified a workaround for this camera connection problem.

The Vision PC was having problems connecting to 2 cameras on the 2.x subnet.

While testing this morning, I found that by disabling and then reenabling other network cards (3.x, 4.x, 5.x) I was able to reestablish connection to those camera on the 2.n subnet, after which all the vision processes were able to come up and run.

I also found that if I logged  the user off and logged back on without any network card changes, all the processes come up normally.

However, if I powered down the PC and rebooted, the camera reconnection problem happened again, preventing 2 requried vision processes from coming up normally.

But, if after a reboot I disable/enable the network cards and then run my VisionBuilder batch startup scritp then VBAI is happy and all processes start up normally.

It almost looks to me like there could be some type of network card driver startup timing problem where they come up too early before the system is ready, and that a disable/enable is able to reestablish a more normal state of operation.  

After several reboot tests confirming that this appears to work, I am running an image capture stress test to make sure that vision functions normally.

I plan to add steps to the very beginning of the vision startup script to disable and reenable all vision network ports for a few seconds before starting up the vision processes so that we hopefully do not see this problem again in the future.

[AgentAstronaut]

Hi Nelson,

Thanks for updating the forum post with the workaround that you found. Let us know if you find anything else. This could definitely help solve issues in the future.

Regards,

Michael Bilyk

Applications Engineer

National Instruments

[QD.Liu]

I have met the same problem,It's hard to find the true reason.I also want to know how to resolve this problem.

[cool_ranch_doRITAs]

Hi there,

Have you tried the same steps as what Nelson_Bridwell posted? If so, what was the result?

If the problem you are running into is different than the one stated above, I would encourage you to create a new post on the Machien Vision's main page, so we can keep track of different issues and their solutions better.

[BlueCheese]

What is your subnet mask on your subnets? Is it possible you have overlap that may be confusing your routing tables?

Another way to configure this (though you'd need a different switch that has management capabilities) would be to setup the switch to isolate groups of ports into different VLANs so they logically look to the cameras and NICs as discrete switches. Then you could keep the NICs and cameras all configured for link-local addressing (completely automatic on both sides, and the out-of-the-box default) and they'd all work just fine.