08-07-2008 09:47 PM
08-08-2008 02:20 PM
08-10-2008 10:51 PM
To clarify, I use a GigE camera (Prosilica GC1350) so I understand from what you say that IMAQdx applies to me rather than IMAQ.
There's no mystery as to where my camera file resides: I know where it is. I'm trying to find where it is via the installation data (registry keys) but none of these point to the right place. NI provides examples of how to use the registry keys to find and modify the camera file, but they do not seem to apply to IMAQdx.
As to why? I'm using a separate application to configure camera attributes and video metrics - these updates must persist and so it's perfectly reasonable to update the camera file which is where NI designed them to live. The alternative is that I create my own config file, write values in there from the configuration app, read them out again in the main app and then apply them. A very messy long way to duplicate the NI functionality.
If the NI functionality was complete I would happily use it. I'm beginning to think it's a bit rough-and-ready but I didn't want to assume that.
The simplest way to fix it is to write a registry hack that corrects the path to the camera file, and install this with the application. It's ugly, but as I say, the NI functionality does not appear to be very polished so I have no choice (?)
regards,
RichLamb
08-12-2008 10:39 AM
Some cameras implement additional registers that are not contained in the IIDC 1.31 or GigE Vision 1.0 specifications. These advanced camera features are not natively supported by the camera driver. To use these advanced features, you must use the low-level, register-level access tools to communicate with the camera."
The NI-IMAQdx software provides the following register-level primitives.08-12-2008 07:37 PM
Thanks Nate; that registry key will do the trick for me.
For reference, I'm definitely not planning on doing any register-level programming in the camera. I'm more than happy to use the MAX configurator and it's system of configuration data logged in files - just that it needs to be clarified (by NI) how it is implemented and how to interface to it. What exists currently is a bit messy and inconsistent, and the only examples are misleading.
The unique camera data is saved in the camera files - there's no real need to go to register-level that I can see. It's also explained in the help under how the attributes are modified in LabVIEW: you use a property node and supply the name of the attribute as well as the value; since cameras have distinct properties that cannot reasonably be coded into the property nodes. This works pretty well.
(or perhaps they could; if the LabVIEW implementation was to read an xml configuration file for the camera in question - but I digress).