Seeing two exposure pulses on control line

[Ken Pietrzak]

We're using an SVS285 12-bit digital camera with a 1428 camera link board. I've attached the camera file for this camera.

We're using this camera in external exposure mode meaning that the 1428 provides the exposure pulse for the camera on Control Line 0. We're using some low level snap vi's and we're finding that for long exposures (greater than 100 ms) that our acquisition time is actually shorter than the pulse width. We decided to investigate by adding a break out connector to the camera link board so that we could actually observe the exposure pulse signal. What we found was quite interesting. For each snap there are two exposure pulses always seperated by about 200 ms no matter what the pulse width is set to. The actual pulse widths are exactly what they are supposed to be except that there are two of them. This occurs regardless of whether we use low level snap vis or IMAQ Snap. So I believe that either there is a flaw in the board or the camera file. Can anybody explain what is going on here?

[Dan_Quinn]

Ken,

I have attached the camera file that is supplied by SVS and we have known to work here. I noticed some discrepancies between this one and the one you are using. Give this one a shot!

Regards

Dan
National Instruments

[Ken Pietrzak]

Dan,

We tried out your file and found that an IMAQ Snap initializes a continuous series of pulses on the control line. If we remove the RepeatSource(fixed,1000) command, we find that it goes back to a double pulse on the control line, just as before with our file. Also, with your camera file, we are limited to a maximum exposure control pulse of 130 ms.

Thanks,
Ken

[Dan_Quinn]

Hi Ken,

What happens if you try to do a low level triggered snap? Do you still see the two pulses even if you are triggering the acquisition?

Regards,

Dan
National Instruments

[Ken Pietrzak]

Dan,

I'm not sure I follow you. Are you suggesting sending an external trigger signal to the camera via one of the external lines of the digital I/O connector of the 1428? The camera's EXSYNC signal can come from either CC1 on the camera link connector or via TTL input on another connector. It's the same signal however. So even if I hook up the TTL signal, you would still have the double pulse on CC1 which would trigger the camera to snap an image. We verified this with LL Pulse Generation.vi. This vi managed to snap an image without hooking up the TTL signal since the EXSYNC pulse also came in on CC1. LL Triggered Snap requires a trigger input on an external control line to start the acquisition. Why would this make any difference to the signal on CC1? I would still expect to see two pulses generated on the CC1 line when we executed the trigger. Is this what you want us to try? I guess we could hook up a mechanical switch.

Ken

[Dan_Quinn]

Hi Ken,

What I was trying to get at is whether or not you see a difference in results if you were to provide the pulse externally. All in all, I'm trying to look at the big picture- Are these two pulses causing problems with your acquisition? For that matter, I wanted to see if an externally supplied single pulse resulted in a different outcome for you.

Regards,

Dan
National Instruments

[Ken Pietrzak]

I'm still not sure whether you want me to supply the external pulse to the frame grabber or the camera. If it's to the camera, then I will need a new camera file so that the exposure pulse does not also go out on CC1.

[Dan_Quinn]

I was just referring to doing so to the board so that we could see if you get the same behavior.

[Ken Pietrzak]

Dan,

We see exactly the same behaviour if we trigger the acquisition and use low-level IMAQ vis. We still get two exposure pulses on CC1.

We think the following happens. When the camera gets the first exposure pulse it does the acquisition and the data is read out of the camera's buffer. When it gets the second pulse it does an acquisition - however the data is not read out since the frame grabber has only called for one acquisition. When our application calls for a second acquisition, it reads the data in from the camera that it acquired in that second pulse from the last acquisition. That's why the acquisition time for that second acquisition time is less than the exposure pulse. We believe that the MAX Snap behaves the same way.

I was mistaken when I said before that we see the same behaviour with IMAQ Snap. We see two pulses on CC1 when using the MAX Snap. However with the IMAQ Snap vi we only see one pulse. With IMAQ Snap, CC1 starts low, then goes high, then goes to an intermediate level for the exposure pulse, then goes high, then goes low. When we do our low-level acquisition, we simply call imgSessionAcquire.vi and then IMAQ Get Buffer.vi. Everything else that is typically done in IMAQ Snap, we do in an init vi that is called in the beginning of application. CC1 is always high except during the exposure pulse.

So if we use the regular IMAQ Snap, we don't have a problem in terms of seeing two pulses. However, the acquisition times are too long. We'd rather use our low level snap. The question is: what is causing the two exposure pulses on CC1 and how do we fix that?

Thanks,
Ken Pietrzak

[MarcoPolo5]

Ken,

An upgrade to the latest NI-IMAQ driver (3.1.1 is the latest release) should fix this "double pulse" problem - it seems from your camera file, you are using NI-IMAQ 3.0 (NOTE: the "CameraFile(x.x0)" line at the top of a camera file refers to which version of NI-IMAQ the camera file is compatible with - 5.10 corresponds with NI-IMAQ 3.1.1).

Previous to the 3.1 release, a glitch on the control lines would sometimes happen when initializing the IMAQ board - this was due to enabling the control line before driving it to the default state. Since the control lines are tri-state (high, low, or floating), enabling the line in a floating state before driving it low/high would sometimes cause a glitch.

This would also explain why you are seeing differing behavior from the MAX snap and the IMAQ Snap.vi. In MAX, each time you snap, the board is initialized, whereas in LabVIEW, you only initialize the board once before calling each IMAQ Snap.vi.

This irregularity in the control line has caused problems on very few cameras - but perhaps it is what is causing the problem with yours.

I hope this helps out.