what does IMAQ Start do?

[sdmadman]

Hi all

What does IMAQ Start do? On my camera eval station, it fails under certain circumstances, and I'm trying to isolate the cause.

Background: This is an evaluation system provided to me by CMOSIS. When I use it as they delivered it, it works great. But of course, I need it to perform very differently from CMOSIS' design, and that's where the trouble starts.

System is a Lenovo ThinkCentre running Windows 7 Pro SP 1 64-bit.

NI-1433 PCIe framegrabber, both Camera Link cables running to the eval board.

LabVIEW version 2010 32-bit,

NI-MAX version 5.5.0f0,

NI-IMAQ version 4.7.3,

Camera File Generator 3.0.1

The eval system was originally designed as a 4-tap, CL Medium. To demonstrate a concept we're developing, I want to run 8-tap CL Full (really, I want 10-bit 8 tap, but that's another discussion). I used CFG to edit the original icd file and saved it as a new file. When I use NI-Max to switch to this new camera file, the program fails when IMAQ Start is called, error -1074397153 is returned; "NI-IMAQ: Cannot detect recognizable video source".  I'll attach both icd files.

I can think of two possible culprits:

1) IMAQ Start is reading registers on the camera and finding something imcompatible with the settings in icd file

2) Items within the bad icd file contradict each other

Since this is a Sunday, I don't expect to get an answer very quickly, so I'll keep looking for my own solution for a while. If I solve this myself (overly positive attitude), I'll post the solution.

Thanks!

MADman

[BruceAmmons]

IMAQ Start just starts the acquisition.  You have to do all the camera setup before that.  I am pretty sure all the settings in the ICD file are sent during the camera setup, not when you run IMAQ Start.

I suspect it is having exactly the problem the error suggests.  For some reason or other, it isn't getting a valid signal from the camera when it starts the acquisition.  Either the camera isn't sending data, or the data is not the correct format.

Bruce

[sdmadman]

Thanks for the reply, Bruce.

The thing is, the camera isn't sending data yet, and it isn't expected to. After IMAQ Start, my app sends a series of bytes over the CL SerialTC link - those bytes tell the FPGA on the camera to start a snap.

The lower level VI that throws the error is imgSessionAcquire, basically the last step in IMAQ Start.  imgSession Acquire simply writes to a Library Function Node (I'm guessing to a DLL); it writes the session ID, a single Boolean bit called 'Async?' (set to True), and an integer zero ('callback').

The only thing I'm changing is the icd file.  Sometimes I forget to set the FPGA to send the right data format, but since we don't get around to sending data (I set a break point at the beginning of IMAQ Start so I could step to where the error occurs), I'm don't see why that would matter - it might be another problem I still have to solve, after I fix this one.

Still, you've given me ideas. I'm going to try putting scope probes on some test points and see if something behaves differently between the two scenarios.

Cheers!

MADman

[BlueCheese]

I don't have too much to add, except I don't think it matters that the camera isn't sending images when you call Start. If that were the case, it would fail with triggered acquisitions as well. I think all that matters is that it sees pixel clocks coming from the camera so that it can lock to it. I think the camera is supposed to always output this signal.

[sdmadman · Accepted solution]

Exactly, Cheese.  And what was the real problem?

ding ding ding ding ding!

No Z clock (or data, for that matter).  It appears someone (blush) forgot to un-comment the lines in the FPGA constraint file that assign the Z channel pins.

The moral of the story: don't even bother the Forum until you look on the 'scope.

Cheers!

MADman

The other moral: framegrabbers check for a clock before they try to acquire.

[sdmadman]

And thanks for your guidance!

MADman