Error -1074360293 with USB3 Vision Camera

[Petric]

Hi erveryone,

We using a PointGrey Blackfly S USB3 Vision Camera with NI Vision Acquisition Driver. We have LabView 2016 and Vision Development 2016 and also the Vision Runtime 2016 on the Target PC.

Sometime it runs for hours and then we get the Error -1074360293 "NI-IMAQdx: (Hex 0xBFF6901B) Timeout." at IMAQdx Get Image2.vi.

Can that come due to an USB3 loose connection (the Cam is connected over an USB3 hub wer we also have an NI USB-6002)?

Or do you have an other idea?

Thanks

Patric

[Bob_Schor]

The system timed out.  It's either Hardware or Software, probably.  We don't know much about your system, such as frame rates, image specifications (size, RGB/Grayscale/# bits), etc.

• Hardware -- if speed and fidelity are important, do not use a USB Hub.
• Software -- as no VIs (and, please, don't post pictures of VIs, post the VIs, themselves) were provided, can't make any constructive comments.

Bob Schor

[Petric]

The picture size is 1280x825 and Monochrome and the frame rate is 200.

Here some VI's You maybe can find some reason;-)

With the "restart/ - initialisation" of the camera after timeout we got the pictures again.

[Bob_Schor]

Is your LabVIEW Code in a LabVIEW Project?  [It should be, if it isn't].  Is your LabVIEW Project (and its files) contained in a single Windows Project-specific Folder?  Then you can compress this file and attach the resulting .zip file (or zip it up, yourself), giving us access to all of your VIs.

Your Camera Acquisition loop needs to run at 200 Hz.  Note that the Grab function, if in a loop by itself with no other processing (and no initialization or other code, that having been done before the loop was entered) should run precisely at 200 Hz, as it is being "clocked" by the Camera hardware.  You should not be attempting to control the timing with LabVIEW Timing functions!!!

The way most hardware acquisition loops work (including this one) is that there's an Acquisition Function that runs off a device-specific hardware clock, in this case, the Camera's Frame Rate timer.  Inside the loop, the "Read" function basically takes almost no CPU time (as the hardware is doing all the work), but imposes a strict limit on how much "free time" there is to do anything else.  You want to do almost nothing else inside this loop except to "export" the data to another loop that can run "as fast as it can" and process it all.

One way to do this is called the Producer/Consumer Design Pattern.  You get your data from the Hardware and put it into a Queue (this is the Producer Loop).  You have a separate Consumer Loop, running in parallel, that takes the data off the Queue and does whatever processing you need.

When dealing with IMAQdx and images, you have a "hidden bonus" -- you do not need to put the Image (which is a 1280 x 825 U8 array) on the Queue,  but can just pass the Buffer Index from the IMAQdx driver.  When you dequeue it in the Consumer, then you can extract the image and do whatever with it.

The Producer/Consumer Design Pattern is one of the VI Templates that ships with LabVIEW.  To study it, open LabVIEW, click on File, New ... (the three dots are important), and find the Template called something like "Producer/Consumer Design Pattern (Data)".

Bob Schor

[Petric]

Hi Bob Schor,

No I Haven't al Vi' in the same folder, but exept of the error handling and the IMAQdx VI's should everything be provided in the last post, isn't it?

Thanks for the advice about the Timing Function. I will take it out. It manely slow it down at the moment (50ms --> 20Hz). Can that be a cause for a timeout?

So I have to thake out the hole Picture processing and then he only other thing in the same loop is to change attributes (and that only if some new ones are set). I do that in the same loop as I found in the Example (Grab and Basic Attributes.vi). Is that the wrong way to do it and can that cause a timeout?

Thanks Patric