Inconstant analog output

[JWJ]

Hello,

I am not sure it is a software (Labview) or hardware problem.

The desired output is a 20ms 100KHz pulse on both the 2 Analog output channels, shown as below.  The output is monitored on oscilloscope.

      The problem is that most of time the output is correct, but other times the output lasts much longer than 20 ms. 

      Both the "DAQmx Wait Until Done (VI)" or "DAQmx Is Task Done (VI)" indicates that the output should have been completed.

Any suggestions? I really appreciate. 

[GerdW]

Hi JWJ,

---

@JWJ wrote:

Any suggestions? I really appreciate. 

---

Suggestion: attach real code!

We cannot debug/edit/run images with LabVIEW!

When attaching code: make sure there are default values in all of your frontpanel controls…

[JWJ]

attached is the program. and the program interface is below.

[JWJ]

  correct and incorrect output are shown as attached image. Also, the output is to be enabled by turning on the square LED and triggered by keyboard in the  original program.

[Kevin_Price]

Many of NI's DAQ devices will maintain an analog output voltage level even after the task is stopped.  If the last sample intentionally generated by the task is at 5V, your device may maintain that 5V output indefinitely, even after stopping the task.

However, in the code you provided, the task sure appears to make sure the last few samples are at 0V.  Nothing jumped out at me to explain what you're seeing.  You're doing finite acquisition, you wait for it to complete, you don't get any errors (and are carrying your error wires through properly), and you append 0V data at the tail end of your AO data to generate. 

   Basically, I don't see what the code problem could be to explain what you see on the scope.  Despite that, I'd also say that it more likely *is* a subtle code problem (or possibly a scope setup problem) I didn't spot than a DAQ hardware problem, given the observed symptoms.

Try running a modified shipping example for finite AO multiple times, feeding it with your array of 2005 samples.   See if you can replicate the anomaly using simple trusted code that's borne up under lots of usage and scrutiny.

-Kevin P

[JWJ]

Yes, I tried the sample code "Voltage - Finite Output.vi" and modify it to 2005 samples @100KHz, it seem OK.

Also tried the assistant with 2 AO output, though the code generated is with "Analog 1D Wfm Nchan Nsamp", instead of the "Analog 2D DBL Nchan Nsamp" I originally applied, it seems the output is normal (the tail voltage is high in the generated data), but it went to wrong when I purposely switch to my data.  When I change the voltage to values other than the 5V, the voltage keeps at that value when it goes wrong. 😕So awkward. 

The board is usb 6216. Test system is win10, labview 2016.

[crossrulz]

If you don't care about being as blazing fast as possibly in your code, you could add a 20ms delay after the task is "complete".  I chose 20ms since that is the length on your pulse.

[JWJ]

The problem is same, under 20ms and 1000 ms break after the complete of output.

Another phenomenon is that once it goes wrong, the program couldn't generate any output TWICE (no error generated), then it goes back to normal. I measured the output during the TWO failures  and found the high voltage of two AOs initially would go back to 0v in either failed try. This phenomenon is repeatable though it is not clear when it goes wrong.

[Kevin_Price]

Are you *sure* there's no errors?  As presented, the only way you'd learn of one is by gracefully shutting down by clicking on your boolean "Stop" button (NOT the stop sign icon for "Abort" that's built into the LV toolbar).

I'd lay down some debug probes on things like the DAQ error wire (probably a conditional probe set to pause on error), and your delta time calculation (probably a custom chart probe to watch for trends or outliers).  What do you see in the delta time value for the runs that stay at 5V for too long?

I'd also spend more time with the apparently working shipping example, modified to generate your data set.  (Save a *copy* of it in one of your working folders, don't just save over top of the original example.)   Exercise it lots of times to try to build up justifiable confidence that the example code always works as desired while your code sometimes doesn't.  If you find that to be true, it's a  pretty strong indicator that something about your code or settings are causing the problem.

You always leave the "sample clock source" set to "OnboardClock", right?  I expect you do, but just want to make sure.

-Kevin P

[JWJ]

I'd lay down some debug probes on things like the DAQ error wire (probably a conditional probe set to pause on error), and your delta time calculation (probably a custom chart probe to watch for trends or outliers).  What do you see in the delta time value for the runs that stay at 5V for too long?

> I forget to say that the delta time is around 27 once it goes wrong the first time, the time for the following TWO failure is not consistent, between around 27-80.  while it is around 50 when the output is correct.