Error -200019

[MarkVBA]

Hello there,

I’m trying to start up a life cycle test but I’m facing one problem. After roughly 15 minutes of testing, DAQmx is getting error -200019 (ADC conversion attempted before the prior conversion was complete). The equipment I’m using is the following:

• NI cDAQ 9178
• NI 9205 (twice)
• NI 9481 (twice)

I’m reading 13 signals, single ended with my application. Signals are read with 100 Hz. I can do this with just one NI 9205, but since I’m getting the errors I thought let’s split up, so not all 13 signals have to go trough one ADC, but trough two ACS’s.

These signals are converted to actual values, temperature, current, etc. When the test is active, this data is logged and some signals are used to control the test. Something what may help, is that the program (not actual test) can run for one hour or more, when no data is logged. Maybe this is some clue?

What I’ve done to solve this problem:

I’ve searched trough the NI community but didn’t found the solution for me. I’ve also checked the information in the link below, but no solution for me.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P6CnSAK&l=nl-NL

The following I’ve done from the link below:

• Decreased sampling rate to 5 Hz
• Checked specifications of my device (NI 9205) and there OK
  • NI 9205 can sample with CompactDAQ chassis 250 kS/s. I have 13 channels, so per channel 19.23 kS/s. Since I’m running with 100 Hz and 10 samples per channel, so I think 13000 samples per second, which is way less than 19.23 kS/s with just one NI 9205. Now I split them up, so this shouldn’t be the problem.
• Timeout value for the DAQmx Read VI is increased to 1000
• Reset the NI MAX database.

Thanks in advance for helping.

[GerdW]

Hi Mark,

your VIs contain garbage data and are not readable by LabVIEW. (4 of them also have the exact same size of 2^18 bytes…)

Please attach them again!

While you do so please ZIP them into just one archive, that "Download All" button (still) doesn't like filenames with spaces in them…

[MarkVBA]

Hello GerdW,

I've attached them again. Thanks in advance.

[GerdW]

Hi Mark,

your VIs still contain rubbish!

When 5 files of 1.3MB in total size are compressed into a ZIP archive of just 3kB then they contain just ZERO bytes!

[Kevin_Price]

This sounds like a "not clean" clock signal that occasionally glitches such that the converter sees a digital edge at a time when it shouldn't (too soon after the previous conversion).

I don't really know cDAQ all that well -- are the clock signals for your module(s) generated by the chassis and delivered to the module through the rear connector?  If so, I'd be inspecting that connection.

-Kevin P

[MarkVBA]

Hello GerdW,

Youre right sorry for that. The new zip should work. If not you can download them on the link below:

https://wetransfer.com/downloads/656fb07e19626053cf8f608c7a76e35c20200319190319/e49b28e2f049a9e6bd25...

[GerdW]

Hi Mark,

no need for bogus 3rd party download websites, just attach files in the forum!

Uh-oh Rube-Goldberg alarm on first sight:

Don't use DeleteFromArray when ArraySubset is sufficient. No need to index several array elements to bundle to a cluster when there is ArrayToCluster! (Read the help for this function, please.)

The calculations inside "Convert V to Signals" can be done operation on the array (subsets) instead of separating the whole array into all its elements - LabVIEW works mostly polymorphic!

More Rube-Goldberg:

Use BuildArray to build an array - InsertIntoArray should only be used to insert somewhere in the middle of an array…

Even more Rube-Goldberg:

Very big issue:

Never place a wait function next to a DAQmxRead function reading a defined number of samples from a continuous DAQmx task!!! The DAQmxRead will wait for the samples to arrive - no need for an additional wait!

You really need to improve the whole VI and your programming style.

You don't need to wire all indices at IndexArray to index consecutive elements!

Learn about using the right array operations…

Duplicated code belongs into subVIs!

[MarkVBA]

Hello GerdW,

Thanks for looking into the code. Youre right about the Rube-Goldburg. This can be done much more effective. I will work on this.

I forgot to mention this. The wait until next multiple was deleted to try wheather or not the error was solved. This unfortunatelly didn't solve the problem.

[GerdW]

Hi Mark,

Checked specifications of my device (NI 9205) and there OK

NI 9205 can sample with CompactDAQ chassis 250 kS/s. I have 13 channels, so per channel 19.23 kS/s. Since I’m running with 100 Hz and 10 samples per channel, so I think 13000 samples per second, which is way less than 19.23 kS/s with just one NI 9205. Now I split them up, so this shouldn’t be the problem.

You are reading 13 channels at 100Hz: this gives just 1300 samples/s!

I'm using the 9205 in several cRIO targets, but read them in the FPGA. All 32 channels at 500Hz or 1kHz sample rate: no problems in years…

Can you create a small, clean test VI doing nothing else than

• setting up the DAQmx task
• reading samples as you do now
• displaying the samples in a graph (no chart please)

Run this VIs as long as possible and check for any errors.

As simple as this:

[MarkVBA]

Hello GerdW,

It's running right now. I will check each half hour for errors and update you if any errors occur.