What is wrong with my Analog triggering?

[zorro]

I am using NICard E3016 to generate two analog outputs. There are two channel on the NICard.

My design is to generate 0V initially and after 5 seconds, the voltage changes to 5V so that another softerware starts to save data.

Everything is fine except there are random drops in the analog output channels. You can see them in the picture. Could anyone tell me the reason for this ridiculous random drops? Thank you very much.

[jdunham]

QUOTE (zorro @ Aug 14 2008, 02:37 PM)

I am using NICard E3016 to generate two analog outputs. There are two channel on the NICard.

My design is to generate 0V initially and after 5 seconds, the voltage changes to 5V so that another softerware starts to save data.

Everything is fine except there are random drops in the analog output channels. You can see them in the picture. Could anyone tell me the reason for this ridiculous random drops? Thank you very much.

[this should be moved to the Hardware Forum]

I think we'd need to know more about how you are generating this signal. I assume you are using an E-series National Instruments multifunction i/o card, but I couldn't find a model 3016 anywhere at ni.com.

If you are using E-series, and the DAQmx drivers, then is the task being interrupted? If you are continuously writing to the card in a software loop, then maybe you have a bug in your code which manifests itself only occasionally. Plesae post your VI which controls the analog output channel. (If you haven't encapsulated this into a subvi, now is a good time to do so!)

If you are using the E-series card in the correct way, then you should not see any dropouts.

[zorro]

QUOTE (jdunham @ Aug 14 2008, 07:56 PM)

[this should be moved to the Hardware Forum]

I think we'd need to know more about how you are generating this signal. I assume you are using an E-series National Instruments multifunction i/o card, but I couldn't find a model 3016 anywhere at ni.com.

If you are using E-series, and the DAQmx drivers, then is the task being interrupted? If you are continuously writing to the card in a software loop, then maybe you have a bug in your code which manifests itself only occasionally. Plesae post your VI which controls the analog output channel. (If you haven't encapsulated this into a subvi, now is a good time to do so!)

If you are using the E-series card in the correct way, then you should not see any dropouts.

Hi, jdunham,

Thank you for your help.

The analog triggering is not in a subvi in my main program. I can't post my main program here. It is a huge one. But I write a vi which has the same structure and setting with the triggering part in my main program. Let's call this vi as "TestTriggering".

A new problem with this TestTriggering.vi is that it always generate a strong noise, which doesn't show in my main program. I hope you can help me with this problem and the random drop.

Thank you so much.

[Tom Bress]

QUOTE (zorro @ Aug 15 2008, 11:58 AM)

Hi, jdunham,

Thank you for your help.

The analog triggering is not in a subvi in my main program. I can't post my main program here. It is a huge one. But I write a vi which has the same structure and setting with the triggering part in my main program. Let's call this vi as "TestTriggering".

A new problem with this TestTriggering.vi is that it always generate a strong noise, which doesn't show in my main program. I hope you can help me with this problem and the random drop.

Thank you so much.

I have a question about the graphs you posted. Are you plotting the output of your analog out channel directly? Or are you outputting a voltage, and then reading it in through an analog input and plotting what you read?

I have seen dropouts like the one you describe, but they were due to analog input buffer overflows, not due to analog output problems. Analog outputs should be rock solid. But analog input can be problematic if you are buffering. If you acquire data too quickly, or if your buffer is too small, you overrun the buffer and can get dropouts as seen in your graphs. Try lowering the acquisition speed or increasing buffer size and see if the problem goes away.

[zorro]

QUOTE (Tom Bress @ Aug 15 2008, 11:26 AM)

I have a question about the graphs you posted. Are you plotting the output of your analog out channel directly? Or are you outputting a voltage, and then reading it in through an analog input and plotting what you read?

I have seen dropouts like the one you describe, but they were due to analog input buffer overflows, not due to analog output problems. Analog outputs should be rock solid. But analog input can be problematic if you are buffering. If you acquire data too quickly, or if your buffer is too small, you overrun the buffer and can get dropouts as seen in your graphs. Try lowering the acquisition speed or increasing buffer size and see if the problem goes away.

Thank you Tom.

There is another hardware which receives the analog triggering from my LabVIEW program. And this hardware has a matched software that can display the signal the hardware receives. So this is how I get that graph.

I don't know if I plot my analog out channel directly since I know nothing about that hardware and its software.

Now I understand a little bit about what you mean in your second paragraph. Thank you.

[jdunham]

I looked at your VI. You are doing a continuous generation and not monitoring the error cluster. I think your DAQmx write buffer is regularly running out of samples (especially since your buffer size is one), though I only glanced at the code.

one solution: don't use buffered output at all. You should be able to output immediate non-buffered values to the analog out, though it is possible they removed this functionality when NI-DAQ turned into DAQmx a few years ago.

Second possibility: Some where in the analog output task property nodes there is an option to regenerate the analog buffer, which basically implements a circular buffer in the hardware fifo. If you have than, then having a one-sample buffer continuously generated will do what you want. Sorry I don't have time to find out the correct property today.

3rd possibility (not recommended) use a really much larger buffer and make sure that you don't fall behind. This is probably not worth the trouble since it is more programming and will still probably fail sometimes

Good luck