03-07-2011 04:53 PM - edited 03-07-2011 04:53 PM
I have a problem using a Pixelink camera (FireWire IEEE1394 port) to capture images. When I try to grab the live images in MAX/LabVIEW, the image on the screen does not always show properly and the bottom part of the image is fluctuating (See attachments). I have tried the “ignore first frame” option and different ROI, frame rates, but the problem still exists.
This system worked fine before I switched to a new computer. The new computer does not have an onboard FireWire port and a PCIe card is used instead. The software and the OS (Windows XP, 32-bit) are the same in both computers.
When I use the company provided software and driver to grab the images in the new computer, the images show properly.
Software and the version shown in MAX
IMAQ 1394 2.0.3
Please advise. Thank you.
03-08-2011 03:43 PM
Are you using the Legacy IMAQ for 1394 driver?
Also, do you get the same result for every image or just some?
What happens if you do a snap?
Also, what frame rate are you running at?
Sorry for all of the questions. I'm just trying to get a better idea of your setup.
03-08-2011 05:16 PM
Thank you for your reply.
When I go to the Device Manager and do the “update driver” procedure on the camera, it shows the driver as “NI-IMAQ IEEE 1394 IIDC Digital Camera”. This driver (version 2.0.3) is come with the Vision Acquisition Software 8.2.
When I try to capture images using the Grab.vi in the IMAQ example folder, the images are shifting between the good and the bad. These bad images show up roughly every 1 to 2 seconds and the object in the images looks “shaking” in the vertical direction due to these bad images. The problem gets worse when I use the mouse to do the front panel activity. I also notice that the frame rate suddenly drops when these bad images show up. The frame rate is set to 30 frame/sec. The meter in Grab.vi shows around 28. When these bad images show up, the meter suddenly drops to 10 and then bounces back to 28.
I haven’t tried the snap feature, but the images I provided earlier are captured using the “right click - save as” from the live images on the screen.
03-08-2011 06:06 PM - edited 03-08-2011 06:07 PM
This is a symptom of packet loss on the firewire interface. Most 1394 chipsets have very little buffer memory and so they need to be able to DMA the data into host memory immediately or it is lost and you see symptoms like you are seeing. This is really a hardware issue and there is not much the driver can do to fix it. My initial guess is that with the PixelLink software a different packet size or speed is being used and causing a data transmission pattern that is more reliable on your given setup. You should compare settings between the two setups as a first step.
It could also be a symptom of a bad cable or connector.
03-09-2011 03:04 PM
Thank you for your reply. But I don’t understand why the camera and the labVIEW program works properly in the old computer, but not in the new one.
When I use the Pixelink software to view the images, it works properly and so I assume the cable and the firewire card are still in good condition. That software allows users to change settings such as brightness, gain, ROI, exposure time,… but it does not have the packet size option. I use the same setting in MAX as in the Pixelink software.
I found out that the bad image/data loss mainly occurs when I use the mouse to do activity (drawing a ROI in the image on the captured image/clicking the buttons on the front panel/dragging a window). But I need the LabVIEW front panel as the interface to do the work.
03-09-2011 11:23 PM
Point Grey has a really good article that outlines a lot of the things that can cause this behavior and some ways to go about correcting them:
03-11-2011 09:28 AM
Thank you for your information and finally my problem was solved. I followed the Tech Note and used the utility to disable the “Enhanced Halt State” of the CPU. Now, the images show on the screen are clear and not torn.
Thanks a lot.
07-19-2012 12:00 PM
Eric's comment made my day:
Facing one PC that produces frequent timeouts with a AVT Pike 505C whereas a completely different PC does not expose this behaviour I found the link to the PointGrey document which outlines that "Power-Saving Features on Host Systems" might be the reason. Actually disabling all CPU C States (not just the C1E Enhanced Halt State) seems to fix the timeout issue: No timeouts have been observed within the recent hour.
(I disabled all C States to save some time. Maybe, disabling just the C1E might have been sufficient.)