08-20-2013 08:30 AM
I feel stupid asking if anyone knows what an unknown error is... but anyway, if anyone has ever seen such an error with NI-IMAQdx.
It happens at "IMAQdx Start Acquisition.vi". I'm a using Dalsa GigE camera if that helps and I have LV2010 + VDM 2010SP1 and VAS August 2010.
Thanks in advance for any help
We have two ears and one mouth so that we can listen twice as much as we speak.
Epictetus
08-21-2013 02:00 PM
Does the camera work in Max?
08-28-2013 02:22 AM
I have seen this.
When a connection is first made to an unknown camera the first thing that happens is that an xml is downloaded from the camera.
the xml is generated by the camera and contains information for a client (like labview) about which features this particular camera has.
The particular camera I had reported features in the xml, that was actually not available from the interface..
hence when labview tried to enable the features, this error occurs.
Sometimes you can get the camera to work in MAX (Tools->Measurement & Acquisition eXplorer)
And then determine which attributes causes it to chrash.
Sometimes you cannot, and needs to modify the xml...
08-28-2013 06:35 AM
yes, the camera does work in MAX. It works as well in the LabVIEW app but sometimes this error appears and I'm not too sure why yet but ZcuBa's answer looks interesting, I will take a close look at the camera settings that the LabVIEW app is trying to set.
We have two ears and one mouth so that we can listen twice as much as we speak.
Epictetus
08-28-2013 11:41 AM
If your application makes configuration changes to the camera during runtime, you may need to examine how some interdependent settings are affected. Sometimes, things like changing the bit depth will cause the camera to automatically change other settings to maintain functionality. If you are unaware of these changes, and are making changes inside the program that are contrary to these, or in the wrong order, it can cause problems.
08-28-2013 03:53 PM
Thanks for bringing my attention to that, I will be carefull.
As far as I can remember there's just a handfull of settings that are controlled by the application and another thing I've noticed is that when the IMAQdx is closed the changes aren't saved, therefore when re-opening the session, the settings that were last saved in MAX will be in use.
I guess the best thing to do is to test this in MAX, and only change the settings that really need to be changed from the app.
We have two ears and one mouth so that we can listen twice as much as we speak.
Epictetus
08-28-2013 04:21 PM
Sometimes the order of operations matters when setting the properties like Width and X offset( like the range of the width is linked to the X offset). Invalid properties might not be detected until the start grab is issued.
08-29-2013 01:57 AM
@falkpl wrote:
Sometimes the order of operations matters when setting the properties like Width and X offset( like the range of the width is linked to the X offset). Invalid properties might not be detected until the start grab is issued.
Aha, that sounds like a good info that I hadn't thought of, I'll keep that in mind.
Thanks
We have two ears and one mouth so that we can listen twice as much as we speak.
Epictetus
08-29-2013 02:36 AM
That is in fact because the MAX application updates the previously mentioned xml file, when settings are saved.
if the xml file is present, available settings, and values are read from the file into max, instead of from the camera defaults...
remember to save settings in MAX, if you want them to be persistent.
Also, the xml can be copied to another machine to have the same settings on that from the beginning.