This all seems to be quite fine, but for some reason the camera will be detectable and connectable, but the gardasoft controler is not. Why? both are in the correct subnet, and I can connect to the controler via the webpage (which does not work if it has the wrong subnet!). Is this a specific genicam requirement?
Hi @CvK,
The Gardasoft isn’t GigE Vision as far as I know… 10BaseT according to the manual, so that looks like the problem - IP address is fine, but it is not GigE Vision.
And it magically resolved itself after a power cycle from the gardasoft controler. Huh…
If anybody has some ideas what might have been the issue, I’d love to hear them though! Could it be that there are multiple DHCP providers perhaps? I know some camera vendors implement their own DHCP, but I never found any trace of that in CVB.
Anyhow @JonV, besides the pesky DHCP problems I encountered, using cvb + nodemaps for controling the gardasoft controler was an absolute breeze and I highly recommend it. Could’ve used the gardasoft SDK, but using CVB means one less SDK/API and does wonders for code readability and maintainability
edit: It seems like a shoddy connection is the issue. After any sort of connection issue only a reboot can reconnect the device. This is not the case for camera though, odd. Some info on how DHCP works for CVB would be helpful to bugfix this
I also updated my knowledge of Gardasoft controllers: apparently it is 10BaseT but it is GEV and should be normally discoverable. Every day is a school day! I will give that a test.
I don’t think there is a particular CVB issue here - the cameras have a ‘heartbeat’ time before they report a lost connection, maybe that is the difference?
I was also suprised by that, I have to admit that it was more luck than wisdom for me too; I kept finding 2 devices during discovery, and one of them refused to provide me with an image stream…
Hmm, perhaps… But that -is- kind of a cvb problem (or at least a genicam one?). When I look at the IP address and start sending tcp requests to the controler it works as intended. Also the webpage hosted by the controler is valid, at least indicating that the IP configuration is indeed correct.
Might indeed be that the heartbeat keeps the DHCP lease alive longer? I’ve not been able to reproduce it on my workstation and my laptop does have a bit of a shoddy ethernet connection (the RJ45 socket is a bit wobbly). But it does seem as if something in either cvb or the genicam protocol causes the effects of a unreliable connection to be magnified in DHCP mode.
