Camera definition file restricts functionality of line scan camera

[PeterSilver]

I am trying to use a Dalsa P2-2k40 line scan camera with IMAQ and LabView with a NI-1428 card. Using MAX to test whether the camera is working there is an option to change the exposure mode to 6 - triggered input. However, there is no option, nor any information, about where this triggered input is coming from. When running in this mode it seems to run using the camera sync signal. Where is the information that will allow me to choose the input trigger signal to come from, say, Trigger0 (TTL).

Camera file excerpt:
SignalLevels {
DataLines (RS422)
EnableA (RS422, High)
EnableB (RS422, High)
EnableC (RS422, High)
EnableD (RS422, High)
MasterClock (RS422)
PGOutput (RS422)
PixelClock (RS422, High)
Trigger0 (TTL)
Trigger1 (TTL)
Trigger2 (TTL)
Trigger3 (TTL)
}

Also, why is the exposure time in Mode 6 (triggerd input) limited to 27us? In other modes it can be set to 1000us, which is the camera specification.

If I edit the camera definition file and change the maximum value from 27 to 28 and then run MAX I get the following results:

If I select an exposure time of 27us Mode 6 I get an image, again triggering from I don't know where.
If I select an exposure time of 28us Mode 6 I get a blank image. Black with no sign of data.

Name (6) {
Action (Serial) {
Command (sem 6\r)
Response ()
Delay (100)
}
Action (PG) {
Line (0) {
Start (High)
1, 200
}
Line (4) {
Start (High)
1, 50000000 / 35400
}
}
Attribute (Exposure Time) {
Value (Integer) {
Min (2)
Max (28) // original setting 27
Increment (1)
Display {
Multiplier (1.000000)
Offset (0.000000)
Precision (1)
Units (µs)
}
Default (27)
Current (27)
Action (Serial) {
Command (set %d\r)
Response ()
Delay (100)
}
}
}
}

Where is the triggering coming from?
Why does the image disappear if the exposure time is over 27us in Mode 6?
Why are these limitations and restrictions imposed in LabView/IMAQ when they do not exist in other frame-grabber/software combinations?
Is it possible to overcome these limitations or should I move to other frame-grabber/software combinations?

[Brad]

Hello Peter,

Very good questions about how camera files work with triggering. The first questions is regarding Trigger Mode 6 and where the trigger is coming from when acquiring images from MAX. When the acquisition is configured for free running (as it is in MAX or a simple continuous grab/ring example), a trigger is sent out on Control Line 0 when all other PG equations are done and on the deassert edge of the Line Valid from the camera.

A few things to note for this mode (see previous message for camera file excerpt) are that two PG (Pulse Generation) equations are used. Only Lines 0-3 actually go to the camera and lines 4-7 are used to help control the timing of lines 0-3. The rule for PG pulses is that they repeat only when all PG equations complete and then on the deassert edge of Line Sync/Frame Sync depending on if the camera is Line Scan or Area Scan (a special flag must be set earlier in the camera file for Line scan to make sure the pulse repeats after every line instead of every frame: RepeatSource (Fixed, N) where N is a number...8 for this camera file)

So in this example, there is a pulse on Control Line 0 that starts high for 1 internal timebase (50MHz) and then goes low for 200 cycles and then stays high until Control Line 4 is done and there is a deassert edge on Line Valid. I would strongly recommend installing NI Camera File Generator because the documentation for this utility explains this in more detail (and probably more clearly with timing diagrams). You can get this utility from here:

http://sine.ni.com/nips/cds/view/p/lang/en/nid/14207
I attached the documentation for NI Camera File Generator for your reference. I had to change the extention for it to attach properly, so modify the .txt extension to .chm and then you should be able to open it.

To answer your question though, you can use an external trigger signal to act as the gate instead of the falling edge of Line Valid/Frame Valid by writing code that configures the acquisition for a triggered acquisition. By default MAX is always acquiring in free run mode and using the deassert edge of Line valid/frame valid to determine when to repeat the pulse. To use an external trigger as the gate instead, you have to use a programming environment and use the IMAQ Configure Trigger function. This will allow you to specify an external trigger source and what action you want to take (Start of acquisition, trigger each buffer, start of buffer list, etc). If you choose trigger each buffer, then this mode will only send a pulse on Control Line 0 when an external trigger is recieved, and it won't repeat a trigger pulse until PG 4 completes and then there is another pulse on the External Trigger you specified.

Your second question relates to why the maximum value for exposure time for this mode is 27. If you notice later down in that section, the camera file species a serial command to be sent to the camera
Action (Serial) {
Command (set %d\r)
Delay (100)
Response ()
}
The %d means to interpret the variable the user set as a number and send that number in the serial command. I would guess that the Dalsa camera only understands serial commands in the range of "set 2" to "set 27", and you'll have to ask Dalsa why they don't support a greater range of serial command numbers for this mode.

I hope this helps give you a better understanding of how camera files work with NI IMAQ hardware. I also hope this answers all your questions.
Thanks,
Brad

[PeterSilver]

Hi Brad,

Thanks for the explanation about where MAX gets its triggering signal from. I have written a program that captures from an external trigger and it works fine, apart from other problems to do with getting a clean trigger signal.

WRT the second question, the Dalsa camera accepts the command "Set %d" for values from 2 to 1000us without a fuss. These are the documented limits of the exposure time. It is definitely not a camera problem as once the camera is running, after IMAQ Start has loaded the camera file and applied all the settings therein, I can then issue the command "set 500" and it works fine.

So my question still is: Why does dicking with the camera file cause the whole house of IMAQ cards to fall down? If I edit the camera file to make the maximum value of SET to be 28 and then I choose 28 in MAX capture fails (black screen). If I edit the camera file and remove the SET commands from the modes then my NI-IMAQ program fails to capture (black screen - fail in IMAQ Copy).

My issue is this. When I call IMAQ Start I want the image capture process to begin. Instead, IMAQ Start first loads the camera file and sends commands to the camera. These commands are sent via the Camera Link serial bus and require the camera to respond. It has to set the mode (sem 6) and it has to set the exposure time (set 27). I then have to make another call to set the exposure to the correct setting (set 150). All this takes time, about 1 second. That is an extra second every capture cycle. Now, the mode and the exposure time are stored in the camera. They do not have to be set every time capture is started for the camera to work. They only have to be set once when the program starts.

However, my experience has been that if I edit the camera file capture ceases to work. Why the limit of 27 in the camera file?

Also, a suggestion for the people who wrote MAX. How about a means to issue camera commands via the CameraLink serial connection?

Cheers,

Peter

[Brad]

Hey Peter,

Glad to hear you got the triggering acquisition working. As for the serial command for setting the exposure time in mode 6, I found out that the maximum value was set by experimentation and finding the same results that you did that it works for anything less than 28 in mode 6. The fact that you can set it to something greater than 28 after the acquisition is going makes me think there is something strange in how the Dalsa camera behaves. We currently have to impose a 100ms-300ms delay after every serial command because the Dalsa camera doesn't respond to our serial commands and if we send the commands too quickly, it gets confused. For most cameras, they send a response, so we can have the camera file wait for the correct response before sending the next serial command, so everything works out and the timing is as fast as the camera can handle. With Dalsa, we played around with the delay to make it as small as possible, but we saw some weird behavior if we made it to small so 100-300ms was a safe value, but it makes it take a long time to send all the serial commands. So perhaps with mode 6 when setting the exposure time there needs to be more delay or something for the camera to handle it correctly. To avoid these unnecessary delays, you can configure the camera how you want and save the settings so it always is configured in that mode when you turn it on and then just set the flag in the camera file for: SerialDisabled (Yes) This is in the InterfaceInfo section under Serial at the top of the file. This will tell the framegrabber not do any of the serial commands (or waits), and you can still send your own serial commands programmatically to change things on the fly, but you won't have the long start up time when IMAQ Start is called.

Hope this helps,
Brad

[PeterSilver]

Hi Brad,

That is the bit of information I was looking for ( SerialDisabled(Yes) )! Thanks, I shall try it out.

I have also noticed the length of time it takes for the serial command to respond in the Dalsa. I usually wait for the OK to come back and put in a time out value which is different for every command. Some, like SET for the exposure, only take 300ms but WPC, to save coefficients, can take five seconds.

I believe I know why the 27us limit is on the Mode 6 in the camera file. It has to do with the interaction between the exposure time, SET, and the line rate setting, SSF. The maximum line rate is 35,560Hz which translates to a maximum exposure time of 28us. The point is that if one sets the exposure time to, say, 200us and then sets the mode to Mode 2 (free run) where the line rate is, say, 10,000Hz then there is a conflict that, if I remember correctly, is resolved in favour of the line rate. This means that the exposure time is not what one thought it was. The solution is to set the line rate and then ALWAYS follow that with a command to set the exposure time. If the exposure time conflicts with the line rate an error is returned from the camera.

Still, if one is setting the mode to 6 (triggered capture) in the camera file then this restriction does not need to apply. I have used this camera with another frame grabber and so I know that this is not a restriction imposed by the camera so I can only assume that it is the way that LabView interprets the camera file.

Cheers,

Peter

[Dr. Hamid]

Hi Peter, Brad;
I was reading this topic and found out that I need help!
Peter, you are right that the line rate is the dominating factor, I have also observed this behaviour by the camera. My question is how can I prgramatically change the line rate? (Using Labview and IMAQ)?
I need to communicate via camera link ofcourse.

Here is my problem: I set all my parameters in Max, then close max and go to my LV application,
It seems to me that everything goes back to its default!??
In order to avoid any problem, I would like to do all the set up in LV.

Can I change the settings of the camera in Labview?

Brad your help is always required !:)

Hamid

[TylerS]

When you set your settings in MAX, do you hit the "Save" button at the top of the screen? This should save those images without reverting back to default values. But if you really would rather do it programmatically, take a look at this knowledgebase from our website:

http://digital.ni.com/public.nsf/websearch/CCC5BB5990AA416786256C23006E687C?OpenDocument

good luck!

[Mang]

Hi Peter,
   I'm using the same camera,grabber and software platform. I wonder how to trigger the camera with an encoder. Could you please give me an LV example of yours?

Regards,
Mang

[PeterSilver]

Hi Mang,

Sorry for the delay in replying. I won't give you an example of my code because I am still having problems getting it to work properly. As I have said, I have used this camera with a different framegrabber programmed in C++ and I am able to get it working in a completely flexible manner. The Labview implementation is so constricted and frustrating that I would not recommend using this camera configuration in a Labview environment. I still can not get the camera to start without loading the camera file. If I implement SerialDisabled(Yes) in the camera file the camera just does not work. At the end of the day there is only so much time that I can spend trying to debug undocumented features of Labview or implementing workarounds to a flawed implementation.

My present problem is that IMAG Copy Aquired Buffer vi gets slower and slower to the point where it takes two and a half minutes to transfer an image. It is only 13MB that is involved!

If you manage to get it working please send me an example of your code. Maybe I will be able to see where I have gone wrong. If you strike the same limitations as I have please let me know. I am hoping that you are able to find a way through the forest without my misleading map. Or maybe you just can't get there from here!

Cheers,

Peter