MAX cannot configure cameras properly
in [LabView]
|
From: RichLamb on 25 Jul 2008 03:10 Hi, having a few issues with MAX while trying to setup attributes and test a GigE camera at lower bandwidth. Note that when running on a GigE link this camera works beautifully with no issues. For reference, the camera is a Prosilica, which I mention as it should have excellent compatibility with MAX and LV. Yes, I know most of the docco says a GigE camera needs a GigE link, jumbo frames, etc. But in theory this is not the case - if you tune down the ROI, pixel depth, and more importantly the streaming rate the cam should work fine on 100Mb ethernet. It's a sliding scale. I've tried this in the Prosilica viewing utility and it works fine. Problem is when using MAX - I think there are bugs here. Firstly, MAX is smart enough to recognise the 100Mb link, and the "StreamBytesPerSecond" attribute is given an upper limit of about 12.3M (which is 100Mb/s). As you adjust this, MAX adjusts the corresponding FrameRateLimit, based on the number of bytes you have chosen in your frame. This all makes sense and seems perfectly OK. But when you try to snap an image or save the settings yo get the really annoying "Error 0xBFF69012 Attribute value is out of range". This error message is a bug in itself. It's not informative. If you know an attribute is out of range you could at least let the user know which one, but I digress... I found and ran the CameraValidator.exe with the /ATTRIBUTES flag and it gives me errors in one or more of the FrameRateLimits. It seems MAX does not want to go with the maximum limit it has calculated based on the available bandwidth and frame size, but still has a current value based on GigE. It does not appear to be updating the attributes. It does not let me save the attributes as long as it thinks there's an error, but I can't correct the error until it saves the file! I'm going to try and get MAX to reset the camera database - hopefully without doing anything to agricultural - and maybe then it will recognise the correct FrameRateLimit. Other than that I have no idea how to get MAX to work properly in this regard. Any help appreciated Lamb
From: muks on 31 Jul 2008 09:40 Have you gone through <a href="http://forums.ni.com/ni/board/message?board.id=200&message.id=16300&requireLogin=False" target="_blank">this</a> thread
From: RichLamb on 4 Aug 2008 21:40 I don't think that thread is of much use to me - my problem is not based on old firmware or incorrect settings on the PC. I've dug into it and it has more to do with how the attributes are stored and used by MAX. I know the "main" database used by MAX is at ...\Documents..\All Users\Application Data\National Instruments\MAX, and I cannot delete this even if I wanted to as it appears to be locked by something. I doubt this would solve the problem anyway, and it's dangerous. There is some more camera-specific data in ...\Documents..\All Users\Shared Documents\NI-IMAQdx\Data. This includes a file called <camera-name>.icd which is a text-based list of camera attributes generated when you configure the camera in MAX. It is regenerated if you delete it. It appears to be somewhat based on an XML definition file stored in the XML subfolder - this seems to be some sort of builder for the MAX camera configuration screen (ie. it describes what all the fields are, default values and such). The real problem I have is that the .icd file created for the camera is only a subset of all the attributes. Somehow MAX is getting some additional attributes from somewhere I can't find, that describe all the non-configurable items. This appears to include the FrameRateLimit which effectively means it's hardcoded for a 1Gb/s value. So when I run CameraValidator it always gives an error for this attribute. ie. when I configure the camera's bandwidth, MAX calculates a FrameRateLimit of say 5 fps, but it still complains there is an attribute out of range because there's a hardcoded value of 20 fps somewhere (some of the attributes seem to be redundant). I can't find where the system is storing this value though. If I knew where MAX was getting ALL the attribute values it uses, or how it was calculating this 20 fps value, I would "adjust" it and theoretically the camera would then work fine on a slower link.
From: Vivek_N on 6 Aug 2008 10:10 Hello RichLamb,It looks like you have done quite a bit of troubleshooting already. I would check if you have taken all of the following measures:1) Uninstall any third-party driver/software that interfaces with the camera. This includes any Prosilica drivers that are used to view images using their utility.2) Turn off the windows firewall and any third-party firewall software that you may have.3) Ensure that your camera has the latest firmware on it.4) Try deleting the camera file from the \Documents and Settings\All Users\Documents\National Instruments\NI-IMAQdx\Data folder, disconnecting the camera and then connecting it back again. This generates an new camera file.If the problem still persists after trying all these steps out, could you attach screenshots of your camera configuration in MAX? Also, it would be great if you could attach the camera file generated as well. I hope this helps!
From: RichLamb on 7 Aug 2008 22:40 Hmmm. This is not helpful. As I mentioned, the problem is not related to the issues you mention and I've either tried these long ago or they don't apply. Can I suggest you read the issue as described? I know it's complex, but that's the fact of the NI camera configuration model. There's no way I can simplify it, particularly since I only understand about half of it (so far). To help clarify things I've included both the camera file (.icd file - renamed to txt for inclusion here) and the Validator report which shows the error. I assume this is the same conflict being reported by MAX, as MAX does not give sufficient detail in it's error dialog. If you wade through the camera file you'll see the following things of interest (and loads that aren't): 1) The image format, 970 x 1024 x mono12, which MAX calculates to give a payload size of 1986560. Correct. 2) The streambytespersecond figure of 71946322 which represents about 545 Mb/s. This value is not actually used, since when I bring up MAX with the 100Mb/s link it allows me to configure a value much lower, like 10730832, but I can't save this due to the error. If I manually write this value into the camera file it makes no difference. 3) There's a DesiredPeakBandwidth value set to 1000, which looks interesting. I've tried changing it but it does nothing. It doesn't appear in the MAX configuration screens. When MAX is opened, I can configure the streambytespersecond to a "sensible" value of 10730832 (about 80Mb/s). MAX correctly calculates the AquisitionFrameRateLimit in this case to be about 5. Clearly it uses the payload size and bandwidth to do this. But then it fails to either work or save the file, because of an attribute out of range (which it gives no detail on). Now look at the Validator report. The error seems to be in the AquisitionFrameRateLimit, where the calculated value of about 5 is less than some value it's dug up from god-knows-where: 20.065. I don't know where it's getting this value. I *suspect* it's based on some assumption that the maximum bandwidth is 1000Mb/s somewhere, but I need somebody who knows this camera stuff to look at this and let me know how it works. Seems like it's doing a lot more checking than it needs to; I told it the bandwidth, and the payload size, that should be enough. regards, RichLamb Prosilica GC1350M (02-2130A) (#F31008573).icd.txt: http://forums.ni.com/attachments/ni/170/347731/1/Prosilica GC1350M (02-2130A) (#F31008573).icd.txt Prosilica GC1350M (02-2130A) Attributes Debug1.txt: http://forums.ni.com/attachments/ni/170/347731/2/Prosilica GC1350M (02-2130A) Attributes Debug1.txt
|
Next
|
Last
Pages: 1 2 Prev: Re : Re: Re : Re: Problem with TDMS in Matlab Next: CWGraph3d show z axis color ramp |