NI-PXI-6733 cause test computer freeze

[ziyasen]

We are using PXI-6733 for several years and do not have any problem.

But last week  our test computer  start to freeze (do not respond to any command) whenever we call  "DAQmxWriteAnalogF64()" function  at our labwindows project to apply desired waveform. After calling this function CPU utilization suddenly increase to %100  and never decrease again.

Only way to unfreeze the computer is giving it a hard reset by pressing the power button.

We suspect from out 6733 board and change it with a spare one , but  problem continues.

Do you have any idea about how can we solve the problem?

[McQuillan]

If you're sure nothing has changed on your PC to cause this issue, then I would recommend reinstalling your DAQmx drivers. If that fails to change anything, then it is probably a corrupt OS. When was the last time you reimaged your PC? 

[ziyasen]

Actually , test computers HDD broke down and we replace it with a new one. Then we install the image of previous HDD to this new one.

I will try to remove and re-install DAQ-MX drivers as you advise.  But I could not understand how installing image of operating system  results in such an error?

[McQuillan]

Your driver will constantly be making requests to your OS, so if there was a corruption in either your OS or driver your computer is likely to become unresponsive or even BSOD.

Did you take a direct carbon copy from your old HDD to your new one? Is it possible that copy included the *thing* that caused the issue....?

[ziyasen]

By using "attached interactive code" at labwindows , we detect that increasing "SampClkRate" results in %100 CPU utilization. 

When we increase SampClkRate to get 20KHz  Sinus waveform  our CPU get %100 utilization, when we decrase SampClkRate , cpu utilization also decreases.

What can be relation with CPU and our 6733 SampClkRate ?

CPU just sents commands to 6733 and  6733 genarate waveform on it own, isnt it?

[Kevin_Price]

The code looks incomplete.  I'm a LabVIEW-only guy so I can't break down specifics about the text API arguments, but I would expect the Write to be followed by a Start and then a loop that keeps calling Write to deliver a continuous data stream to the board.

Consequently, I start to suspect one of the following:

1.  (This one strikes me as likely.)  You're configured to allow regeneration in the "conventional" way, i.e., the driver keeps repeatedly delivering blocks of data from the task buffer to the board on its own in the bayckground.  This can use CPU.

2.  (This one seems unlikely.)   You're configured for on-board generation, which normally requires explicit configuration steps and isn't supported on all boards.  The 6733's are old enough that I wouldn't count on support for on-board regen though I don't know that for a fact.

Further, and probably more importantly, you've chosen a very small task buffer of 50 samples.  Your sample rate is 1 MHz to produce a smooth 20 kHz sine wave.  So your buffer is only 50 microseconds long.  That means that the driver has to move small chunks of data from the task buffer to the board at a very high iteration rate, i.e., faster than 20 kHz.  That's a lot to ask.

A much better approach would be to define the buffer to hold, say, 1.0 seconds worth of the same sine wave.  That'll exactly fit an integer # cycles for any integer frequency.  So write 20000 full cycles of your 20 kHz sine wave before starting the task.  Then the driver can deliver larger chunks less often, which is likely to greatly relieve your CPU.

-Kevin P

[ebalci]

Hello Kevin,

Orginal poster (ziyasen) is my colleague and we are working on the problem together.
The file he posted was kind of a pseudo-code (it is possible to interactively create and run such a group of code in CVI), that's why it looked incomplete. But it included all the necessary components.

The CPU load is directly related to the signal frequency.

I am very surprised by your explanation (which is consistant with the symptoms). I never thought that CPU has to re-send the waveform buffer to the 6733 card for each waveform cycle.

I have always thought that, the buffer is transfered only once and 6733 "plays" it infinitely with automatically re-winding to the first sample. I cannot think of a good reason for the 6733 to re-request the buffer, after each cycle.

(Note: There is no Start after Write because there is a parameter in Write which auto-starts the Task)

(Additional Note: This problem arose after changing the HDD for trying to recover from a nipalk.sys BSOD error. We copied a recent image of the previous HDD, with which we never observed this CPU load problem during its 10+ years of service. BSOD is göne after HDD change but this new issue started )

[Kevin_Price]

Specs for the 6733 make it appear that it *can* support on-board regeneration for a small-ish # samples (see spec for "FIFO size").

I'm accustomed to a default behavior where regeneration is done the way I described -- the driver keeps moving subsets of the same data in system RAM across the PCI bus to the board.   This mode of operation is supported for almost any buffer size on just about any output board so it makes a safe default mode. 

    There should be a way to explicitly configure the task to do on-board regeneration  instead and take the CPU right out of the picture.  In LabVIEW, you do it with a "DAQmx Channel property node."

Is it possible there's been a DAQmx driver upgrade since the system was working?  It's conceivable (though unlikely) that different versions of DAQmx make different assumptions about whether to do regeneration on-board vs. doing it with lots of data movement over PCI.   

    I very recently struggled through some troubleshooting of a new task error that I was eventually able to attribute solely to a DAQmx version upgrade.  It was a rarely-explored corner case that we hadn't encountered for two years after doing the DAQmx driver upgrade.  The old version of DAQmx silenty auto-ranged a parameter to its legal limits and allowed code to function properly.  The new version no longer auto-ranged and threw an error that prevented the code from running.  The *need* for auto-ranging only came up very rarely, when the user set certain config parameters to kinda-unreasonable but technically legal values.

   Anyway, the point is that I've found such incompatibilities to be quite rare in DAQmx, but not quite entirely unprecedented.  It's a long shot, but still worth asking.

-Kevin P