NiDaqmxbase - Samples Not Available?

[sth]

I have a 6033 board in a system using NIDAQmxBase V3.2 / LV 8.5.1 / Mac OS X 10.5.7

I get a warning about samples not available.  In this case I am reading the data in 1 second bursts with a couple of seconds timeout.  The data is being taken continuously.  It should be available.  This code is working under LV 8.5 and Mac OS X 10.4.11.

Even when I run the NIDataLogger application I get this when I try to read 1 second of data at a time.  For example, I try to read 32 channes of data at 500 Hz, and read 500 samples.  It reads once or twice and then pauses for several seconds and tells me that I have no samples.   Say What?

If I ask for 490 samples per channel it runs fine for several minutes!  Known bug?  I couldn't find it referenced in the forums.

Message Edited by sth on 06-18-2009 03:17 PM

[aNIta B]

Hi sth,

      I think you may find this KB of interest.  While I don't think that this is a known bug, you may simply need to increase your sample rate since you're collecting samples from 32 channels.  Do you see the same problem when only reading from 1 or 2 channels?  

[sth]

That KB has all the obvious things that are not going on here.   It seems to happen when I get close to capturing 1 second of data!??  This is odd for a couple of reasons.  In the datalogger example it seems to hang for the 10 second default timeout and there should certainly be 500 samples within the 10 seconds.

In my own application setting the timeout to 10 seconds or 2 seconds doesn't matter.  It still fails!  I have another application that is taking data a 0.1 seconds and it is running fine at 2100 samples/sec in chunks of 210 samples.  The current application is running fine under LV 8.2.1 and Mac OS X 10.4.  This is an attempt to merely move it to LV 8.5.1 and Mac OS X 10.5.7 which now fails.

To me this appears to be a driver problem.  The system is waiting for the data but it just doesn't seem to show up.  THe system seems to hang for 10 seconds!  Under all possible scenarios the number of samples should be available within that time.

[aNIta B]

Hi Sth,

        We don't have anything reported as bug for that.  But I'm curious if you are using an external trigger or clock.  As well, would you mind either posting your code, or at least a picture of your block diagram?  I would like to try this out on our end.  Is there anything else different about your system setup?  As well, have you made any changes to the code since you changed software  versions and opperating systems?

[sth]

aNIta B,

You don't really want the code.  This is part of a *big* system with a half dozen parallel loops.  I have just tried moving the system from LV 8.2 where it is currently running to a newer computer running LV 8.5 and the next update of the Mac OS X.  I can strip it down but.....

However, it seems that on this computer, it happens with  the NI DataLogger.  You should have the code for that!  🙂  Or at least be able to test it with the NI DataLogger.  It seems to be related to the 6033 board and using all 32 channels for about 1 second of data.  The data logger should be simple enough acquistion system to be easy to debug.  When my application failed, I immediately went to the data logger just to confirm it as a test.  That should be able to show you the problem.

I do not use external triggering.  This is internal clock triggering.  My code uses 2500 samples per second on 32 differential channels.  It collects 1 second of data or 2500 samples each read request.  The screen shot I posted in the first message on this thread was 500 samples/sec on 32 channels and reading 500 samples each iteration.  If you back that off to 400 samples for each read it will work.  This is all with the NI supplied NIDataLogger.

I suppose I should try a beta release of NIDAQmxBase? 

-Scott

[aNIta B]

Hi Sth,

    While there's not a beta version that you could try, one last thing I would like you to check would be to create a simple task with 32 channels that reads 500 samples at 500Hz from within LabVIEW.  It would be nice to confirm that we can do this using simple code (like an example program).  Ideally, I would like to narrow down whether this is an issue that has been caused by your upgrade in opperating systems, or simply your LabVIEW upgrade.Thanks!

[sth]

Hi aNIta B,

First, check with Tom W. about a beta version.  I haven't installed it on this machine yet.

I am running the Cont Acq&Graph Voltage-Int Clk.vi from the NIDAQmxBase examples.  It runs fine with a sample rate of 500 Hz and 200 "Samples to Read" and all 32 channels.  I use Dev1/ai0:7,Dev1/ai16:23,Dev1/ai32:39,Dev1/ai48:55 as my channel list.

Now if I only change the samples read to 500.  I get a timeout after 10 seconds.  That the samples just were not available after 10 seconds.  This is a factor of 10 too long!

The only changes to the original VI is that I have made is to change the Channel list, sample rate, and the samples to read values. I widened the Physical CHannels control to show the whole string. It does not complete the first iteration and no samples are ever returned.

I haven't installed the beta yet (and I believe that nipal is updated in VISA 4.5) but this error seems to be in the NIDAQmxBase itself. Especially since it works with a smaller "Samples to Read"

Message Edited by sth on 06-29-2009 04:22 PM

[sth]

And the new nipal in VISA 4.5 (updated from VIS 4.4) did not make any difference.

[sth]

And even updating to a non-existent beta doesn't help. :-).  The problem occurs in ESeries-- AI DMA Wait for Data.vi.

NIDAQmxBase is great that one can see where it fails!!!  The number of samples available increases and then abruptly drops to zero at about 1 second of data.  It may be that the buffer allocation algorithm fails for 1 second of data collection?   Just probe the "Samples Left In Buffer" value from the first DMA read.

[aNIta B]

Hi Sth,

         Thanks for that additional information.  I'll give everything a shot here and hopefully reproduce what you're seeing.  Thanks again!