continuous write no longer works after upgrade

[RbCs]

Hello,

After upgrading a computer motherboard, OS (XP to Win7), and NIDAQmx (9.40 to 9.80) simultaneously the Labview 2011 32-bit vi we use to run our lab bus control system no longer works (the two most pertinent vi's are included here).  My next move is to go back to the older NIDAQmx, but this would mean no upgrade possibility to Labview 2013.  The card is rather old (NI DIO-32HS) but is supported according to the documentation in NIDAQmx 9.80 and passes all self-tests.  I have also tested the outputs with a voltmeter and the test panel in NI MAX.

For large amounts of data to write, the DAQmx Start Task vi executes and throws the following error:

Error -200293 occurred at Dequeue and write out elements.vi
Possible reason(s):
The generation is not yet started, and not enough space is available in the buffer.
Configure a larger buffer, or start the generation before writing more data than will fit in the buffer.

The buffer is not too small.  If I delay the Start Task vi the buffer will fill up more and just crash later.  For small amounts of written data (400000 points or so) there is no problem.  The output executes perfectly.

I realize that this is no longer the recommended clock timing, but:

1.  When I try to use a pipelined sample clock I get the following error:

Requested value is not a supported value for this property. The property value may be invalid because it conflicts with another property.

Property: SampTimingType
Requested Value: Pipelined Sample Clock
You Can Select: On Demand, Sample Clock, Handshake, Burst Handshake, Change Detection
  I have tried changing many other properties and looked at the NIDAQmx 9.80 included example for pipelined clock and do not see the problem.

2.  The normal Sample Clock used to work just fine for generating output while writing to the buffer and I have found an example program on ni.com using this method   https://decibel.ni.com/content/docs/DOC-12402

[RbCs]

I rolled back to NIDAQmx 9.40.  This did not seem to make much difference.  I am still not allowed to select pipelined clock.  To remove the issue of writing to buffer while generating, I temporarily moved the start task vi after the writes (latest version attached)

The buffer in the previous program was actually too small, which I fixed.  I do not understand why this did not matter in the previous installation.  However, now there is a new issue in that the generation stops suddenly at random times.  For a 2 second long stream of data (2E6 points) it makes it entirely to the end only once out of 25 times or so.  When the generation ends, the SpaceAvail property of the DAQmx Write vi goes to zero.  Not sure if this is significant.

It does not seem to matter if I use continuous or finite samples in the clock configuration.

I have also tried switching PCI slots and also tried a backup card.  Same behavior always.

[RbCs]

I tested the new system with the continuous write example included with NIDAQmx 9.40 (included here).  It seems to work fine at my clock freq (1E6).

[RbCs]

Oh dear.  It appears other users have also had underflow problems with this card when upgrading to faster computers.

http://forums.ni.com/t5/Digital-I-O/PCI-DIO-32HS-PCI-6533-setup-problem/m-p/169934?query.id=98188#M2...

Whenever I generate, a random amount of data (rarely all of it) gets generated and I get:

Error -200621
Possible reason(s):
Onboard device memory underflow. Because of system and/or bus-bandwidth limitations, the driver could not write data to the device fast enough to keep up with the device output rate.
Reduce your sample rate. If your data transfer method is interrupts, try using DMA or USB Bulk. You can also reduce the number of programs your computer is executing concurrently.

Perhaps it has something to do with the fact that this card has no onboard memory.

[RbCs]

Reducing the clock rate from 1MHz to 500kHz (32bit) makes everything work again, but I do not understand why this should be necessary for a faster computer.

Benchmarks with ancient computers give much faster maximum transfer rates for this card.

http://digital.ni.com/public.nsf/allkb/4FCA248D888831C386256D8900563E45

Other labs at the university here use this same card at 2MHz (32 bits) successfully.

The NIDAQmxexample VI is also having problems now at 1MHz.

[CoffeeBreak]

Hi RbCs,

Thank you for providing the information above to help with troubleshooting. Since you have made some progress on the issue at hand from post to post I think I may need some help defining exactly where we are at this point.

What NI DAQmx driver version are you currently using (still NI DAQmx 9.4)?

You said the NI DAQmx Example is having problems at 1 MHz, is this still the Cont Write Dig Port-Ext Clk-Non Regeneration.vi? What exact error you seeing with this example?

What is your external clock input pin?

What is your external clock source?

[RbCs]

Hi Sam,

Thanks for having a look-see.  I used NIDAQmx 9.4 for all of the tests above.  Since then I went back to our old XP computer which it turned out actually had NIDAQmx 9.6.2 (not 9.40) and Labview 11 SP 1.  The version of the test program is included here.  I modified the channels vi to "one channel for all lines" which doesn't really seem to make a difference.  I have the channel set to dev1/port0_32 with the onboard clock at 1MHz.  It throws the following error:

Error -200621 occurred at Cont Write Dig Port-Ext Clk-Non Regeneration.vi
Possible reason(s):
Onboard device memory underflow. Because of system and/or bus-bandwidth limitations, the driver could not write data to the device fast enough to keep up with the device output rate.
Reduce your sample rate. If your data transfer method is interrupts, try using DMA or USB Bulk. You can also reduce the number of programs your computer is executing concurrently.

It does not get stable until I reduce the clock speed to 100kHz!  And then even crashes sometimes if I run other programs.  Which is strange because my lab bus program on this old computer uses 1MHz just fine again, with on board or external clock.  The CPU load shoots up with this test VI a lot when you go from 100 to 200kHz.  In general this example VI uses much more CPU than my bus program because it is constantly writing to buffer.  Loading my buffer in the bus program only takes 1sec or so.  I have also changed my bus driver program to use finite instead of continous samples.  The bus program craps out at around 1.1MHz clock.

Speaking with other people at the University (4 different groups), it seems that the speed one gets is dependent on the motherboard and DMA somehow.  Some computers just seem to give faster rates than others.   The overall speed/modernity of the computer and the OS seem to be irrelevant.  The others use traditional NIDAQ drivers and the C++ API, but I have not tried that yet, as it would require a recode.  Some of them run faster than mine, some slower.  We have tried disabling other PCI bus devices and changing the slots.  We have also tried various bios versions.

Another thing I noticed, is that the card ALWAYS regenerates, regardless of how the mode is set.

Have a nice evening.