I am using the PCI-1422 to acquire frames from an LVDS camera. We've been having issues with some acquisition software written by someone else, where there will be a 2-3 second delay between when something moves in front of the camera, and the movement is reflected on the screen/in the data. Once the delay starts, it stays constant and doesn't go away until acquisition is stopped and started again (ie, the software is closed and opened).
To try to get around this and other issues, we've written our own software for specific measurement tasks (in C). Last week, I performed a measurement that stored 400 files, each of which had 320 frames of size 320x256. At some point in the measurement, data seems to have shifted. I was able to reproduce this yesterday with the same software. I could also see the effect in the display of the IMAQ "Ring" example, compiled in c#. Unplugging the LVDS cable and plugging it back in did not fix the issue. However, when using "Ring.exe" (the IMAQ example), stopping acquisition and starting it again gets rid of the shift. I wonder if this is related to the delay issue we've seen in our vendor's software.
I've attached some some images of the frame output. The first photo is what the frame should look like, the second photo is a capture of the first bad frame, and the third photo is what all of the rest of the frames look like (shifted upwards from what it should be). Below is the code where buffers are locked from the ring in our storage software.
Any ideas as to what the issue is would be appreciated
What camera are you using? And how was the vendor's software written (ie, did you have access to the code, or was it just a compiled exe you were running?). How do you have the acquisition configured (triggered or free running, frame rate, etc.)? Are the frame rates within spec for the camera? It sounds like the vendor's software may have been a slower triggered method, while you are now using a free running mode. You may also confirm that you have the correct camera file generated, by viewing this knowledgebase article: http://digital.ni.com/public.nsf/allkb/05DCE3868362783586256FC8004F123C
Also, I was wondering about the bad frame. Are there other frames like this, or is that the only one, and then from that point forward all the other frames are shifted down? Or does this happen many times, with a gradual shift? Any information you could provide would be helpful.
Hi D Smith,
We're using a Cedip Cirrus MCT camera. The vendor's software is compiled and sold as a product along with the camera for viewing and storing camera data (the vendor in this case integrates the Cedip camera to some custom hardware, so Cedip did not write this software).
For the vendor's software, the camera is in free-run mode, and it limits framerate input to the maximum framerate of the camera (100 fps). We generally use ~75 fps for our measurements. I am pretty confident that we are using the correct camera file.
Our software (modified C code from the Ring example) operates in both triggered mode (external triggering from a stepper motor) and free running mode, operating at 75 fps in both cases. In both cases, we've seen the shift as in the screenshots that I've uploaded.
I looked closer at the data that we stored, and it looks like that "FirstBad.png" frame is seen once more in the collection of files from the measurement. The first appearance is the 177th file (of 400) - the first frame. The second is the 188th file. All files are 51,200kb (320 frames * 320 * 256 points * 2bytes/pixel), but 177 is 37,102kb (232 frames), and 188 is 4,230kb (27 frames).
Considering that the only way we have of looking at the output of the camera at this time is through the PCI-1422, it's difficult to say whether the hiccup originates in the camera output or the framegrabber. The thing that confuses me is that the framegrabber continues to report shifted frames until acquisition is stopped and started again. NI is taking care of the buffers and giving me pointers to them when I ask for them, so I'm not reading data from some shifted buffer position - though that would explain why the shift is only in the y-axis. I've seen data shifted in the x-axis from bad triggering or a loose connection, but this doesn't seem to be what's going on. Could these issues be symptoms of the framegrabber not keeping up with camera output?
Thanks for your help
Based on the calculations you gave, you should be well within the limits of the frame grabber. You seem to need a pixel clock of just 8 MHz, and the grabber can handle 50 MHz. Can you confirm the wiring for your device ( http://www.ni.com/pdf/manuals/372158d.pdf page 20). What control signals (or RS232 signals) are you using? Do you have any documentation for the camera? I tried searching for that model--while I can find the company, I can't find the model. Based on the information you provided, it is hard to say for sure where the fault lies. If you had another camera or another frame grabber, that would help out immensely, but it sounds like you do not have either. Get back to me after you have confirmed your wiring, and we'll see if we can come up with some troubleshooting steps to try which do not involve a different camera or grabber.
Unfortunately I don't have access to a manual or pinout for the camera. The camera and frame grabber are sold as a package from the company that integrates the camera with a spectrograph. The camera had been working fine, but the delay and shift issues started happening within the past few months. I wonder if perhaps there is a fault somewhere in the frame grabber.
Either way, the camera and framegrabber has been sent back to the manufacturer, and hopefully they will be able to reproduce and pinpoint the issues. If I hear that there was an issue with the NI board or programming, I'll post information here.
Thanks for your help