09-24-2010 01:24 PM
First of all, thank you for deciding to read my post! It is a detailed one, so I would really appreciate if you could read it till the (bitter!) end.
I am having problems with acquiring images at fast frame rates. I am using a hamamatsu camera (ORCA-ER), PCI1422 gramegrabber card and LabWindows/CVI 7.1 for software.
The objective is to acquire images in triggered mode. Specifically we send a pair of pulses to start and stop the acquisition of an image and we do this repetitively.
I give below the code segment for the acquisition step. The code was written many years ago by someone else in the group. I was unable to find any documentation for how this code was developed.
The problem that I have is that for exposure times >= 150 msec (image size = 128x128), the code runs fine. However, if I reduce the exposure time below 120 msec, then the code gets stuck inside the while loop in Step 5. For these exposure times I have noticed that code successfully acquires the first image, but gets stuck in the while loop in STEP 5 for the second image. Introducing a delay in step 4 avoids this problem, but this compromises my acqusition speed.
The value of the returnStatus variables is zero in all cases (including the case when the code get stuck inside the while looop).
I noticed that the commands that I am using to send the trigger pulses and to poll for the availability of new data are high-level commands. Therefore I was wondering whether there are any speed issues related to these commands or is this a problem with my framegrabber board?
As I am not sure if the problem that I am experiencing is software/code related or hardware (framegrabber) related, this query has also been posted in the hardware forum.
I welcome all suggestions and comments.
Thank you very much for reading my post!!
Sripad
09-27-2010 06:38 PM
Hello,
Are the bining settings for your camera software configurable; such that, you may achieve a frame rate of > 8.3fps? From your description, it seems as though the system, when acquiring faster than 120ms, may never be receiving the stop pulse, i.e. the minimum Exposure time is ~120ms, and your camera is still acquiring the first frame when the stop pulse is sent. Unless the stop trigger is buffered on the camera, or treated as a notifier, the device may miss the trigger in its polling sequence.
Based on the specifications for your camera, there are multiple bining options for increased frame rate. The lowest frame rate is 8.3 fps, which seems to correlate directly to the timing area of interest. While I understand, correlation != causation it may be worth exploring these settings. I'm not certain that setting the IMAQ resolution directly will enable the frame rate improvements in the camera.
I very much appreciate your time, and look forward to any additional information you may provide.
Cheers,
Patrick Corcoran
Application Engineering Specialist | Control
National Instruments
09-27-2010 07:25 PM
Hi Patrick,
Thank you very much for the reply. I forgot to mention that my binning is 2x2 and the minimum frame rate (in full frame) is ~16 fps in this binning mode. Regarding the point that you raise, yes I looked extensively into this issue and I ensured that the camera is being set properly. However, I understand what you mean by IMAQ resolution.
Also, I was wondering is there another command (preferably low-level command) that I can use instead of imgSessionStatus to do the same task? I looked through almost all the example code and so I far I did not come across any example that uses the imgSessionStatus command. This made me wonder whether I am using a command that is somewhat sub-optimal to bein with.
I would very much appreciate if you could provide some information about how the imgSessionStatus command works.
Thank you very much for your time.
Sripad
09-28-2010 05:07 PM
To eliminate hardware limitations, and focus on the code. You might try running code to continuously capture, and use a frame rate calculator; such that, you may empirically measure the acquisition speed of the system including the Windows OS.
I there is not a lower level command for imgSessionStatus, the IMAQ function help describes the functionality of this call. It truly appears as if the stop pulse is missed entirely by the camera when the execution speed is increased. Is the camera registered in Measurement and Automation Explorer? Could you provide a copy of the current camera configuration file?
Again, thank you for your time. I look forward to any additional information you might provide.
Cheers,
Patrick Corcoran
Application Engineering Specialist | Control
National Instruments
09-28-2010 08:06 PM
Hi,
Please see attachment for the camera configuration file.
Thanks.
Sripad
09-28-2010 08:08 PM
Hi Sripad,
Since this appears to be the most active thread, I have moved your identical posts (here and here) to this thread in order to consolidate and streamline our efforts and avoid repeating questions.
Here's a link to the NI-IMAQ Function Reference Help that Patrick mentioned for the imgSessionStatus. As you can see in the NI-IMAQ Functions list, there are no lower-level functions that provide the same functionality as imgSessionStatus. Let us know if you get a chance to confirm your configuration in NI Measurement and Automation Explorer.
Thanks!
- Greg J
09-28-2010 08:11 PM
Hi Greg,
Thank you very much for taking the trouble with consolidating the various posts!
Yes, the camera is registered in measurement and automation explorer and as requested by Patrick I have uploaded the camera configuration file in my previous post.
Thanks for all the help!
Regards,
Sripad
09-28-2010 08:11 PM
Hi Greg,
Thank you very much for taking the trouble with consolidating the various posts!
Yes, the camera is registered in measurement and automation explorer and as requested by Patrick I have uploaded the camera configuration file in my previous post.
Thanks for all the help!
Regards,
Sripad
09-28-2010 08:44 PM
Hi Patrick,
Regarding your previous comment about the stop pulse being entirely missed, I measured the voltage at the output of the BNC connector and when the stop pulse is sent, the correct voltage shows up in my multimeter. Of course an obvious problem with this measurement is the timing issue that is although I am getting the correct voltage it might not be getting into the camera at the right time.
So to address this issue I did another thing. I modified the while loop in Step 5 where I send a stop pulse if the code gets stuck in the while loop:
//STEP 5: Poll for new data/buffer:
tempCounter1 = 0;
returnStatus4 = imgSessionStatus(Sid, &status, &buf_num);
while(status) {
returnStatus5 = imgSessionStatus(Sid, &status, &buf_num);
if (tempCounter1 >=60000)
{
returnStatus3 = imgSessionTriggerDrive2(Sid, IMG_SIGNAL_EXTERNAL, 1, IMG_TRIG_POLAR_ACTIVEL, IMG_TRIG_DRIVE_UNASSERTED);
tempCounter1 = 0;
printf("'Stop pulse sent \n");
}
tempCounter1++;
}
When I run the program, the code still gets stuck in the while loop and it keeps printing the "Stop pulse sent" message.
Also, I forgot to mention in my previous post that my program does not use the camera configuration file. We set the camera parameters using the imgSetCameraAttributeNumeric and imgSetCameraAttributeString commands and the framegrabber is set using the imgSetAttribute command.
Regards,
Sripad
09-29-2010 09:54 PM
Looks like the camera file still reflects 1x1 bining, the file you uploaded is the file that is currently deployed correct?
I found this at the very end of the RTF. Perhaps the bining attributes are not explicitly set by above code?
Cheers,
Patrick Corcoran
Application Engineering Specialist | Control
National Instruments