I am throwing down my gauntlet!

[gnunesjr]

One of the fun things about working with LabVIEW is the power of these discussion forums.  Whenever I have a problem, I can always count on finding someone who knows waaaaay more than me for help, either from an old post or, when I am unusually clueless, a direct answer to my question.

This is the first time I have posted and gotten zero replies! 

But I am desperate.  A very large project, costing in the seven figures, just got brought to its knees by my inability to get the NI 1429 to trigger my linescan camera at every line (and at the maximum line rate of the camera). 

I just got off the phone with a competing company that can tell me how to do it with their  frame grabber. So, if you want to defend the honor of NI and LabVIEW, now is the time to speak up.  On the other hand, if you want to pick up a frame grabber, cheap, say nothing, because my NI 1429 is going to be on ebay next week!

Quoted previous post (without the example attached.  Search "Have you triggered a Dalsa linescan camera" if you want it.)--

Greetings all-

I would love to hear from anyone who has successfully triggered a Dalsa linescan camera using LabView and an NI frame grabber.  I've cruised the forums, and tried the suggestions (like modifying the example LL Triggered Ring without Timeout).  It is clear to me that in all cases, the camera is NOT being triggered at the externally supplied rate.  This is most obvious if I put the camera in Exposure Mode 4 so that the exposure time is set by the external trigger.  It's all just not working.  So far I have been unable to figure out exactly what it is doing....

I'll append the various details below, but it you need to look at them, then you are probably not the person to answer my question.  The right person will know the solution immediately because of the agony they endured working it out!!

Camera:  Dalsa P3-87-12k40
Frame Grabber:  NI 1429
Triggering method:  Sync output from a signal generator connected to the SMB on the frame grabber.
LabVIEW: 8.5
OS:  Windows XP

An example program that doesn't do the right thing is attached.  This is the NI example LL Triggered Ring without Timeout, modified per an old discussion (search this forum for "Why does triggering not work for line scan cameras?" to see why I started here) to supposedly trigger each line.  I've also added controls to easily change the camera exposure mode and a timer to tell me how long it takes per frame

[BruceAmmons]

You asked for help for a specific camera.  I have never used one of them, so I ignored the rest of your question.

It sounds like you have a problem with either the camera or the frame grabber.  Is the camera actually triggering every line?  If the camera is actually acquiring every line and the frame grabber is missing some lines, then you need to figure out what the problem is.  In most cases, it would be the frame grabber is not ready for the next line in time.

I would try writing a program that tells me what my line rate is.  I would probably set up each frame to be 100 lines or so, then measure the time between frames (or multiple frames).  You could come up with a pretty good measurement of how many lines per second are being acquired.  I would start running the program and gradually increase the frequency on your signal generator.  At some point, the line rate will most likely drop to half the signal generator frequency.  The next step is to figure out if it is the camera or the frame grabber that is missing the lines.  I'm not sure how you would determine this, unfortunately.  You would need to measure another signal from the camera that indicates the line rate.  The camera may have a register or something that indicates the current frequency of the lines.  Another possibility is to configure the camera to capture lines at a fixed rate slightly above the critical rate (no triggering).  See if the frame grabber can capture them at the correct rate.

It may be possible that the camera can't run at the maximum rate when using triggering.  It could be that the frame grabber needs to have some parameters adjusted to acquire at faster rates.  It is hard to say without doing some troubleshooting with the hardware.

Bruce

[Wes_P]

Hi gnunesjr,

Since this post is identical to another post, let's go ahead and finish this out on this thread.  I took a look at the user manual, but the nature of the problem still seems a little vague.  I understand that you are having trouble triggering the line acquisition at the correct rate, but this is difficult to troubleshoot without knowing your configuration, steps you have tried etc.  What are your settings/programs that you are using on the IMAQ side of things?  One thing I did notice in this manual is that in mode 4, you will need to pay attention to both the rising and falling edges of the EXSYNC signal.  Do you have your PCIe1429 configured to recognize both rising and falling edges?

[gnunesjr]

Wes-

You are right.  Things are a little vague.  A major component of my frustration is figuring out what the @#%#*() LabVIEW is doing.  Documentation is sparse.

For now, let's ignore camera mode 4.  My application is probably better served by camera mode 6, which de-couples the spatial part of the problem from the intensity part of the problem.

When I run the example VI that I sent with the camera set to camera mode 2, a line rate of 23500 Hz, and a fixed exposure time of 42 microseconds, I get an image from the camera about every .2 seconds.  (In MAX, I set up the camera to download the central 8192 pixels from the sensor, and build up images that are 4096 lines tall.)

The IMAQ command in the example to trigger every line has no effect if I select camera mode 2.

If I select camera mode 6 and feed a 23.5 kHz TTL square wave into the SMB connector on the frame grabber, my expectation is that the behavior ought to be more or less identical:  I should trigger every line of the camera at 23.5 kHz, so I should still get an image every 0.2 seconds.  Instead, I get an image every 0.5 seconds (roughly).  It is clear that I am not, in fact, triggering every line, because if I drop the signal generator all the way down to 1 kHz, it should take 4 sec to accumulate a 4096 line image.  Instead, I get an image every 0.8 seconds.  As I drop the frequency from 23.5 kHz to 1 kHz, the frame rate follows, but I have not bothered to see if it is linear.

[BruceAmmons]

One thing I noticed is that in mode 2, the camera automatically adjusts the exposure time to give you the line rate you want.  If you set the exposure first and then the line rate, the exposure will be shortened.  You might want to check what the actual exposure is while the acquisition is running.

In mode 6, the maximum line rate depends on the exposure time but it is not automatically adjusted.  I would try using a very, very short exposure time (which will give you black images but will still give you a good line rate) and see if the line rate is more linear compared to the frequency generator.  I might expect to only get one line every two cycles due to the dependence of mode 6 on both rising and falling edges, like Wes said.  Eventually you will get one line per pulse at low frequencies.  I can't explain why you got more images at 1 kHz, unless there is noise in your trigger signal.

Bruce

[PeterSilver]

I share your frustration with LabView and Dalsa Linescan cameras. I have several problems, that I have managed to find workarounds for, and some new ones which I can only presume are due to a recent upgrade from 8.5 to 8.5.1

I am using a Dalsa P2-2x-4k40 4096 linescan camera with a 1428 card.

I'll skip the tedious history and get down to the current problem.

PROBLEM #1

I open up the camera in MAX v4.4.1f0. I set it to Mode 2, which is free-run using the cameras clock. I set the line rate to 5000 lps and the exposure time to 53us. I put a LED in front of the lens so that I can see if it will work. No problems. With an acquisition window of 256 lines I get 19 to 20 fps which is correct. No problem here.

Now I set it to Mode 6, which is triggered input. I have a trigger cable connected to a TTL signal generator running at 2,000 Hz. I set the exposure time to 53us and start the camera and I get a live image but I am getting 72 fps. This is about 18,000 lps. If I change the sig-gen frequency the line rate does not change. Mmmmm.. Is something wrong with the sig-gen? I unplug the trigger cable and I still get a live image at 72 fps. The Labview default, and maximum, line rate for the camera is 18,500lps in Mode 2. Is there a connection here?

MAX appears to be faulty. Is this a known problem? Surely if there is no trigger input the camera should just wait?

PROBLEM #2

I have previously set up these cameras to run with the trigger input coming from the movement of a stage. The major problem that I have had using Labview to do this is that damned camera icd file that gets loaded when one calls "camera start". The exposure time is loaded from the icd file and overwrites any value that one may have previously loaded to the camera.

This is an issue because I want to set the exposure time to something greater than the 53us allowed by the icd file (which is set to 2-53us range). I implemented a workaround that resets the exposure time straight after the "camera start" call and then having a global "camera ready" set after this so that the stage does not move until the camera is in the correct configuration.

This worked quite well in 8.2 and 8.5 but now throws an error in 8.5.1 that the requested parameter is out of range. This despite the fact that the camera spec allows an exposure time of up to 1,000us.

I have used a Leutron PicPortPro frame grabber with these cameras controlled by a C++ program and the image capture can be performed up to the specs of the camera.

The limitation appears to be in the Labview implementation of the Dalsa cameras.

This latest problem has knobbled my previously successful workaround and threatens the viability of several millions of dollars of production machinery. I am not impressed.

I have edited the icd file and changed the Mode 6 exposure time range values. I still get the errors that the exposure time value is out of range.

QUESTIONS

Why do the icd files place such a severe restriction on the maximum exposure time? 53us when the camera can do 1,000us.

Why does editing the icd file have no effect on the maximum exposure time?

Why has the behaviour changed such that setting the exposure time after the camera has been started throws an error?

Does anyone have a useful workaround?

[PeterSilver]

I have managed to get my linescan cameras working again. I have found that I can successfully edit the icd file so that I can get the full range of exposures.

I have not checked but my experience has been that I have to reset the exposure time after the camera has been started. I will have to check this to see if it will retain the exposure setting in the modified icd file that is greater than 53us.

MAX is still a problem. It still runs in Mode 6 at 18,500 lps with or without the trigger cable. I do not think it is really in Mode 6. If I make the exposure time greater than 53us it times out. 53us or less and it grabs at 18,500 lps.

[VGA_CD-ROM]

Hi PeterSilver,
According to our compatibility report on the Piranha2 (see the support file listed for the P2-2x-04k40 on our Camera Advisor here), all the modes should be fully supported by our IMAQ drivers as tested. For Mode 6 specifically, the support file says the following:

Mode 6:  Free run is always triggered at maximum line rate.  Triggered runs at rate of trigger.  If your trigger rate is faster than your line period you will get a time out.

It sounds like, as you said before, you're getting free-running speeds. Is it possible that when you are setting the triggered acquisition parameters, you are not pressing the Save button at top to save the triggering settings and leave free-running mode?

[PeterSilver]

Hi Vijay,

The situation I am referring to occurs wholly within MAX. Without leaving MAX I use the interface to change from Mode 2 to Mode 6. I then press the "Grab" button to start the capture. I am using a sig-gen to generate the trigger signal.

I have managed to make this work within my program where I programatically set the mode and all the settings required. The only setting in MAX that I rely on is the window size. I can successfully swap between triggered and free run mode in my program.

The error I am referring to occurs within MAX. Using a signal I know works with a camera that I can show to work with my program, it does not operate correctly in Mode 6 in MAX.

Cheers,

Peter

[Robert_Eastlund]

Dear Peter,

Last year, we used the P3-80-12K40 with the PCIe-1429.  We were able to trigger the camera's line rate in LabVIEW.  We were never able to trigger the line rate in MAX.  In years of using MAX to setup various Camer Link cameras, I can not recall ever being able to perform a triggered acquisition from a Camera Link camera in MAX by simply setting the camera to a triggered mode...

-Robert