I recently downloaded the trial version of NIDAQmx tools(http://www.wavemetrics.com/products/nidaqtools/nidaqtools.htm) as it made it sound like I could create code to run USB devices. I have a USB camera which I want to make a program for to do time lapse imaging.
My problem is I can't find any good tutorials on programming with the NIDAQmx. Also I'm not 100% certain about it supporting a USB camera. Does anyone know of a resource for learning how to use NIDAQmx tools for igor? The manual on the website wasn't very helpful to me.
Also am I trying to do something impossible with the NIDAQmx tools for a usb camera?
NIDAQ Tools supports D/A, A/D and digitial I/O devices, not cameras.
Igor ships with some XOPs that can control cameras. Look in "Igor Pro Folder\More Extensions\Data Acquisition\Frame Grabbers".
cool, the frame grabber works for my camera! one question, how can I program igor to do a time loop? i.e. make the frame grabber grab an image every minute?
I looked at the startMStimer function, but that just seems to only be useful for reporting times, not as a time variable in a time loop.
There is most likely a better way to do this, but this might help. Use time() to get the current time. Compare this to the last minute value you took to see if it's changed.
string prevTime="", minute
minute= stringfromlist(1, time(), ":")
if (stringmatch(prevtime, minute)!=1) //if minute value has changed
////frame grabber code
prevTime = minute
Although what I posted above would be an infinite loop, you can impose conditions to stop.
I think it would be easier to put this in the loop:
Sleep /S 1 // Sleep for one second
The cavaet here is that timing precision of the entire loop has to be tested to confirm it is within your bounds. Grabbing a frame and executing the loop statements take a finite time. So for example, suppose that while this statement sleeps for exactly 1 s, the overhead on other steps add 600 micro seconds until you return to this sleep again. By 1000 frames, you are 6 ms off step from capturing a frame at exactly 1 s increments.
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville
Actually this may be a moot point. If you test the frame grabbing time in low-end devices, you will find sufficient variability depending on the content of the image. In other words, you can't expect a constant/accurate frame rate from this arrangement.
Oh! Yes, that makes sense, either from the perspective of the variability in camera processing or the USB buffer transfer. Thanks for the info.
Back to top