VBAI IMAQdx Acquire initialization sometimes fails and ruins my groove

[Photon_Dan]

I have a GigE camera (FLIR A325) from which I am acquiring images in VBAI.  I have multiple inspections saved and I am using the Inspection Selection step to automatically switch between them based on a Shared Variable.  I am noticing that there is an initialization performed upon each transition from one inspection to another.  On occasion (actually about 25% of the time) the initialization fails.  The error is always related to the attributes of the camera (could not read or verify... something like that).  The thing is that if I force the initialization to repeat by manually opening an inspection, it usually works.  The issue is that once there is a failure to initialize, VBAI gives up and stops the inspection.

Is there a way to force VBAI to repeat the initialization upon an error?  Of course, it would be great if I didn't get the error at all, but I fear that is going to be a finger pointing match between us, NI, and FLIR.

The main concern here is that when VBAI is running in an automated mode, there needs to be a method to recover from errors like that.  When the inspection is stopped, the system is just sitting there idle and helpless.

Thanks,

Dan Press

PrimeTest Automation

[JeffL]

Hi Dan,

Can you please tell me what version of VBAI, IMAQdx, your OS (and if it's 64 or 32 bit), and attach a screenshot of the error you are getting?

[Photon_Dan]

Thanks for the reply!

VBAI 3.6.1, Vision Acquisition 8.6, Windows XP Pro 32-bit

I'll request a screenshot.  The machine is being installed in a production facility right now.  I should be able to get a screenshot today though.

[Brad · Accepted solution]

Hey Dan,

Unfortunately it sounds like the camera doesn't handle setting attributes correctly (I guess I'll start the finger pointing). Are you changing any camera attributes during the inspection? Do you have multiple inspection with different settings? If so, the camera could be in a different state then when you started, and when we close and try to apply the new settings for the acquisition step in the new inspection, the camera doesn't allow some attributes to be set because the current mode isn't valid, and they have an issue with the order of setting things. A debugging tool that will help identify the trouble attributes is WindDbg

http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx#a

After installing this, you can add an entry to your regitry that will turn on all the driver read/writes regarding attributes with status information:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\niimaqdxk\Parameters

Add "AttributeTraceFlags" as a DWORD

The attribute is a mask with the following values:

//--------------------------------------------------------------------------

// Attribute operations we can trace

//--------------------------------------------------------------------------

TraceOperationMask = 0x000F,

TraceGet = 0x0001,

TraceSet = 0x0002,

TraceValidate = 0x0004,

//--------------------------------------------------------------------------

// Status codes to trace

//--------------------------------------------------------------------------

TraceSuccessMask = 0x00F0,

TraceSuccess = 0x0010,

TraceFailure = 0x0020,

TraceWarning = 0x0040,

//--------------------------------------------------------------------------

// Trace destinations to output to

//--------------------------------------------------------------------------

TraceDestMask = 0x0F00,

TraceDebugger = 0x0100,

TraceFile = 0x0200,

So just set it to 0x01ff to see it in the debugger. Once you find out what the problem attribute is, you can talk with FLIR to find out if they can fix their XML file, or try to make sure the attribute is in a good state before closing...I would recommend talking with FLIR so everyone can benefit...FLIR can get in touch with NI and we can also help them make sure their XML is valid if they need help.

Hope this helps,

Brad

[BlueCheese]

Sorry, but for Brad's instructions you probably want to get DebugView (http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx) rather than Windbg. This will allow you to see the output to the debugger much easier than attaching Windbg to the process.

Eric 

[Photon_Dan]

Brad, Eric, and Jeff,

Thanks for the response!

We are not changing any attribute values from inspection to inspection.  I just went through a multi-week debug session with the FLIR folks after they shipped us a new camera that wouldn't initialize at all.  (See SRQ# 7244404)  They finally admitted to a firmware bug and provided an update.  It was difficult to lobby them and even more difficult to get them to replicate the bug since it only affected new camera hardware with new camera firmware.  Their in-house sample units had slightly older hardware guts that somehow would not show the bad behaviour with the new firmware.  Now I've got this new one for them, but it is intermittent unlike the previous issue.

The camera is no longer at our facility as the customer rushed the machine out the door.  They are living with the intermittent issue now.  In order to properly debug this, I need someone to champion the cause at FLIR.  Since they are an Alliance Member I would expect that they have VBAI and can test this out.  However, the reality is that the people I deal with there generally do not have the latest version of VBAI and often do not have access to the latest hardware and firmware.  The camera in question (A325) is made in Sweden.  The only contact that the US support engineers have with Sweden is their online support portal.

So if any of you guys have contact with FLIR, I'd suggest requesting that they wire up a NEW A325 to VBAI and just switch inspections a bunch of times.  The US folks there are genuinely trying to help, but I fear that the urgency doesn't translate "across the pond."

Thanks again!

Message Edited by Photon Dan on 07-09-2009 01:58 PM

[Brad]

Just wanted to give you an update....We met with Jason Styron from FLIR at NI Week and our engineers will be working with theirs to update the camera XML/firmware to correct this problem. Apparently setting the CurrentCase # can fail if it's in the middle of a NUK. Anyway, we will be working on a solution for this with them.

Thanks,

Brad

[Photon_Dan]

Brad,

Thanks for the heads-up.  Jason at FLIR has been keeping me up to date as well.  The struggle on their end is that the camera is built in Sweden and it is difficult to get the development group over there to pay attention to issues like these (long European vacations).  I am very happy that you and the others at NI have been able to provide detailed feedback for them to address the problem.  I do not understand why the camera has trouble with the Current Case setting or why everything must grind to a halt during an NUC (Non Uniformity Correction).

Thanks again,

Dan