@visionmotion wrote:
Odd they don't is right, but he seemed confident:p
Good point on the features (motorized zoom, AF)-- how would these look if properly supported? Would there be additional lines on a IMAQ block allowing for adjustment of these variables?
The model for modern camera standards (like GigE Vision and USB3 Vision) is that they are based on GenICam. The cameras store an XML file that lists all their features, descriptions, and behaviorial aspects of those features (min, max, how they interact with other features, etc). This file is downloaded and used by the host driver/application (in this case IMAQdx) to build up a feature tree of both internal and camera-specific attributes that can be controlled. Most software exposes these features in a tree control UI, but they can also be controlled programatically in LabVIEW or C. The main key is that the camera dynamically defines all these features--they are not known up front by our driver.
The main item to question is whether their XML file contains all the features of the camera (that you care about). There is also a quality-of-implementation aspect as well, since it is easy to make things very buggy and hard to use in the XML file if the designer doesn't take care. I have never used one of The Imaging Source's cameras in GigE Vision mode, so I cannot comment how good the experience might be.
If you haven't ever used IMAQdx before, you may want to see if you can get a loaner from a sales person of a more popular GigE Vision/USB3 Vision camera with a known-well-working standard implementation to play around with so you can compare; if for nothing else to get a good understanding of how the cameras work in IMAQdx and LabVIEW.
