NI IMAQ 1074397153 and 1074396907 (cannot detect recognizable video source; requires external HSYNC to lock signal)

[blueberryfreckle]

Hi,

For NI reps, please refer to #7319303.

I am receiving intermittent NI IMAQ errors:

- Error 1074397153 NI IMAQ cannot detect recognizable video source

- Error 1074396907 NI IMAQ the current video signal requires an external HSYNC to be used to lock the signal

Using:

- LabVIEW 8.5.1 RTE (program is executable)

- NI IMAQ is 3.7.1

- Video capture card is PCI-1410 (similar on 1409)

Troubleshooting so far:

- Measurement & Automation operates fine (Meas & Auto faster, more responsive, and smoother than in the code)

- Passed Meas & Auto self test

- Adjusted Black and White settings in Meas & Auto for contrast (set to see only silhouettes of items in camera image)

- HL Grab VI works fine

- Updated rs170 (1410).icd file with "Coast(Yes)"

- VHDCI, video signal, video power cables were swapped

- Computer and 1410 capture card were swapped

- Camera was swapped

Can the code be changed so a non-continuous video signal is not required and the LabView code can continue to run?  Essentially making the code more robust against drops in signal or lock failures.  This needs to occur automatically without user intervention as it is typical for the test fixture is used to cycle mechanical devices overnight.

In the code, basic VIs I am using are IMAQ Grab Setup, IMAQ Grab Acquire, IMAQ DrawText, and IMAQ Stop.  Error occurs at IMAQ Grab Setup and Acquire (see attachment).

Thanks,

Steven

[Chris_1890]

How often do these errors occur and do they always occur under similar circumstances?  It might be a data flow issue, especially since you're using nested while loops.  I would recommend removing the exterior while loop (especially since it only executes once.)  All of the VI's will execute in the same order without the while loop, but there might be a race condition of some sort occurring because of the two loops.  You can also run the code with highlight execution on to check for this.

As far as changing the code to not need a continuous video feed, the IMAQ Snap.VI takes a single frame rather than continuous video.  Using this VI you would snap a single frame each iteration of the while loop.  You could also ignore these two errors and continue executing the code.  This would be done using the General Error Handler.VI and wiring a constant containing the error code into the exception input and choosing to cancel on match.  If you did this however it would throw off your image count because a loop iteration would still be recorded, so this might not be the best course of action.  

On a side note, you will probably get a better response from the NI community if you repost this question to the Machine Vision Forum.  Users on this forum are much more familiar with our vision products and might have run into issues in their own applications.

[blueberryfreckle]

Hi Chris,

Thank you for your reply.

The errors occur randomly.  At times, it will occur overnight while the test fixture is cycling a mechanism with no user intervention.  Other times, the user will be performing calibrations and measurements.  In either case, the same sub-VI (attached in my initial post) is used.

To recover, the user closes and restarts LabView; sometimes a PC reboot is necessary.  Yet the problem could still persist even after a LabView or PC reboot, at which point the user repeats the process or allows the test fixture to sit.  Eventually, it resolves itself.  There are even several occasions where the error occurs and disappears after closing and restarting LabView just once.

Frequency I estimate to be about 1-2 incidences a week with even a difficult recovery counted as 1 incidence.

I'll investigate the IMAQ Snap.VI.  I apologize I don't fully understand what you mean by the image count being thrown off.  Can you elaborate please?

Thanks for the suggestion to post on the Machine Vision Forum.  I did wonder why there were so few replies.  Hopefully there will be other suggestions I could try.

Thanks,

Steven

[Chris_1890]

Steven,

Sorry for being vague in my earlier post.  When I said the image count would be thrown off, I was referring to the portion of your code in which the iterations of the while loop are determined by a variable named "Pictures."  It appears that you acquire a pre-determined number of images, and so if you get an error and ignore it using the General Error Handler and move on to the next loop iteration, you will have acquired one less image than there are loop iterations.  This could cause problems if you require a certain number of images elsewhere in the program.

I just wanted to make you aware of possible problems that could arise from ignoring the error and moving on.  In general this is can be a dangerous practice, but I wanted to offer it up as a solution just in case it would work in your specific application.  Let me know if you continue to experience these problems after updating your code with the IMAQ Snap.VI and removing the exterior while loop and we'll look into it further.

[blueberryfreckle]

Hi Chris,

I believe the while loop performs the following functions:

- Run the loop at least once

- Run until mean value reaches threshold

Is there a better way to do this without the while loop?

Thanks,

Steven

[Chris_1890]

Steven,

The current conditions you have wired into the stop terminal of the outer while loop are:

Stop Executing IF(Mean Value is less than 230 OR Number of Iterations (i) is greater than 0)

With these conditions, the outer loop will always execute once and then stop.  This is because the iteration count begins at 0.  So after one iteration, the logic will read as follows:

i = 1 » 1 > 0 = True » Stop Execution

If you are wanting to take a certain number of images and then check the mean value, a much better architecture would be to replace the inner while loop with a for loop (you can do this by right clicking the boundary and choosing Replace with For Loop.)  Then you can specify a loop count by wiring a constant into the N terminal.  This will also determine the number of images you acquire within the for loop.  This should give you the same functionality as you have currently.  Try this out and let me know if you run into any issues or have any more questions.

[blueberryfreckle]

Hi Chris,

You're right!  The two conditions are connected to an OR.  I incorrectly interpreted it as an AND.  I'll try your suggestion and see if that improves the situation.

Unfortunately, because this is inherited code, I am just beginning to understand the design intent.

Thanks,

Steven