Hardware not acquiring data

[wpolk]

So here's my problem:

I am using an NI PCI-6259 M series card with 2 SCB-68 connector blocks.

The VI I am developing has to switch often between finite and continuous acquisition. When it is in in finite mode, it needs to run quickly, so I use the Control Task VI to commit the settings to the hardware.

My problem comes from, I believe, switching back and forth between the two acquisition modes. When I switch modes, I unreserve (I commit only when running in finite acquisition). Every once in awhile, when changing states, the hardware enters this... funky... state, where it doesn't receive any data anymore. I cannot just re-initalize all the parameters, instead I have to restart the VI (usually 2 or 3 times to get it to work again).

Any idea why this happens? Do I need to wait between commit and unreserve actions?

Thanks!
Wade

[devchander]

If possible do attach the vi you have developed.

We might be able to suggest better after seeing it

Are you clearing the Task ( DAQmx clear Task) after you are through with each acquisition??

Message Edited by devchander on 04-04-2007 01:20 AM

[wpolk]

Rather sheepishly I admit fixing my problem by adding in a 25 ms wait after the VI unreserves the hardware but before it commits again.

A side note... anyone know if loading all the iterations of the polymorphic DAQmx vi's into memory is a problem? If you use the App.AllVIs property node after you start your DAQmx VIs, you'll see that there's a few hundered in memory... I'm guessing it's because it's a polymorphic re-entrant dll call... I started to get around it by using property notes once my task was created, but it seemed a bit excessive.

Any thoughts?

[wildcat_600]

Hello,

It is normal for a polymorphic VI to load all of its instances into memory.  This is not exclusive to just the DAQmx VIs.  When it loads the polymorphic VI it checks to make sure that none of its instances are broken.  In LabVIEW when you build an executable you have the option to remove unused polymorphic VI instances.  But to simply answer your question this is an expected behavior.  Please let me know if you have any other questions.

Have a good day,

Brian P.
Applications Engineer