08-02-2010 02:31 PM
Hi,
I am using a Redlake MS4100 camera in an aerial imagery application in conjunction with an IMU to record the camera's attitudinal and positional data. The VI attached below is used to control the camera's start and stop functions,which is done numerous times while flying a site. I am by no means a pro at Labview, just learning on my own as I go, so I'm sure my VI is far from perfect.
My problem is that I am trying to trigger an IMU each time an image is acquired, but for some odd reason the number of triggers is more than the number of images acquired. From what I can tell so far, it appears that when I stop the acquisition process, the IMU occasionally receives an extra trigger pulse even though an image isn't acquired. At this point I don't know if my program is mistakenly sending the extra pulses or if the IMU is counting something that isn't really a trigger. I can also export the rising and/or falling edges of the pulses from the IMU and when I export both the numbers of each don't match either. Is there a way to accurately count the number of trigger pulses sent to the IMU to compare to the number of images acquired? Could I possibly be stopping the program in the middle of an acquisition at a point where it doesn't save an image, but still sends a trigger? I also wonder if the camera settings are wrong for the type of operations the camera is used for.
Any suggestions are more than welcome.
08-02-2010 02:55 PM - edited 08-02-2010 02:56 PM
It appears you forgot to include the actual vi in your zip file. We need the "Image Acquisition C Loop.vi" to help you.
Tell us more about what hardware you are working with. Do you have any other inputs you could use to possibly parallel the signal into an analog or digital input and just record what is being sent, to be able to compare it to your other data? This might help you narrow down your false positives.
08-02-2010 03:07 PM
How are the triggers sent? Could it be you need to better terminate the connections?
Can you look at the actual trigger signal with a fast scope? there could be artifacts and oscillations.
08-02-2010 03:08 PM
Sorry about that. It should be there now.
I am using a PCI1428 Frame Grabber Card along with a breakout cable for the trigger output. Other than that, I don't have much more information that would help. I don't know what kind of options I have through the FG Card. Maybe there is something there?
08-03-2010 01:10 PM
I agree with altenbach. In order to narrow down the source of your false positives (unexplained triggers) it would help you to get a good look at the trigger signal you are sending out. Can you hook it up to a decent oscilloscope and get an idea of what you're actually sending as a trigger? I have found that a lot of times false triggers can be problems in your cabling and hardware hookup so be sure to hook the oscilloscope in parallel with your system so you are testing your cabling as well. Are you using shielded wires with the drain grounded properly?