igor NIDAQmx tutorial? support for USB cameras?

Share icon

Hello,
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".

June 19, 2012 at 08:53 pm - Permalink

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.

June 21, 2012 at 11:51 am - Permalink

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

do
minute= stringfromlist(1, time(), ":")
if (stringmatch(prevtime, minute)!=1)        //if minute value has changed
      ////frame grabber code
endif

prevTime = minute
while(1)


Although what I posted above would be an infinite loop, you can impose conditions to stop.

June 21, 2012 at 12:31 pm - Permalink

I think it would be easier to put this in the loop:
Sleep /S 1  // Sleep for one second

June 21, 2012 at 01:00 pm - Permalink

hrodstein wrote:
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

June 21, 2012 at 07:38 pm - Permalink

jjweimer wrote:
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.


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.

A.G.
WaveMetrics, Inc.

June 22, 2012 at 11:21 am - Permalink

Igor wrote:
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.

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville

June 23, 2012 at 05:50 am - Permalink