Simultaneous Analog Output and Input while changing the Analog Output Data

[Holomo]

Hello,

I'm quite new to Labview and I started to work with our NI-6363-USB card recently. I already managed to output and input continuous samples and to output single pulses.

Now I want to create a VI that can do both in the same time which altering the output waveform. I already tried a lot and I looked through a lot of examples. This was very helpful but in the end there are still some problems left.

I added my VI below. As you can see I didn't change a lot in comparison to the original VI. The main difference is that I included a case-structure which for i=0 starts first the writing process, then  the reading. In all other cases the write and reading tasks are updated which in the reading process is only necesarry to renew the window "Measurement" (right?).

The problem is that because there are 2 "Write"-VI's" included in my VI, my VI isn't sure that there is no glitching. I read the article about glitching and tried to use the given hints. This didn't solve my problem but lead to even more questions:

1. How can I really get rid of this warning, which only pops up after stopping the VI?

2. Why won't all Input/Output rates work fine? There seems to be a connection between these values and the "Samples to Read" values and I don't get it. The default values are:

input rate: 100000,00, output rate: 100000,00 and samples to read: 4000

But if I change for example the output rate to 10000,00 Error -200279 occurs. It says increasing the input rate could be helpful. But why should I need a higher input rate if I decrease the output rate? I don't get it...

3. Same error occurs if I change the Samples to Read to for example 1000. Why? I would think that only the time span in which the data is recorded in each cycle should be reduced by the facor of 1/4.

4. If I set Samples to Read to 3900 the same error occurs after a longer time (why?) but until this error occurs the data which is recorded isn't steady as in the standard case but the sine runs through the graph all the time.

I added the VI from which I started, my altered VI and the VI "Get Terminal Name.." which you need to start the VI.

I would appreciate any kind of help or information.

Mo

[stockson]

Hi Mo,

all the errors you are refering to come from the fact, that both input and output operations are programmed in a way that they are dependent on each other.

So if you, for example, have a sample rate of 10000S/s and want to read 4000 samples in the DAQmx Read block, the program will wait for them for around 400ms. This waiting can already cause the samples in the input buffer to be overwritten in the meantime. All the different values you tried can delay the error, but as long as you will not be emptying the buffer faster than filling it, you will get it sooner or later (of course this applies only in a situation in which you are performing R/W operations sequentially).

You turn on the water which starts pouring into a bucket. If you don't empty the bucket often enought (loop iteration speed), have a bigger bowl to empty the bucket with ("samples to read" parameter) or decrease the flow of water (sampling rate) the bucket will eventually overflow, regardless of what is it's size.

Please have a look here: http://digital.ni.com/public.nsf/allkb/A224DA0551EEA073862574F60060AB6F

When it comes to the warnings, usually they can be ignored. You can change the configuration of the error handler to do that for you. 

[Holomo]

Hey stockson,

thank you for helping!

In your description it sounds like the Read and Write Buffers are the same, so they are sharing the same "bucket". I had a different understanding until then because I thought these both Buffers are different things. There is one Buffer I use to copy in the data I want to write in the future and there is another Buffer I'm filling up with the recorded data I want to save (or display,  or whatever...). Is that understanding wrong?

I would have suggested that I need to emtpy my read buffer faster than I fill it. No matter of its size because sometime it will be full anyway. So I should set the Buffer size slightly above the "samples to read"-size. How can I really change the speed of how fast I fill this Buffer? I can change the rate of reading and the "samples to read". If I decrease the "samples to read" I don't see why the speed of filling the Buffer should change as I only write in less samples in less time but I also will start writing the next samples more early.

I fear that my whole understanding isn't correct. Maybe another example can show one of my problems:

I run the programm with Input rate = Update Generation Rate = 100000,00 and Samples to Read = 5000. Works fine, I record 0,05s of my signal. And somehow I seem to record the same "portion" of the created signal all the time as the signal output is steady as long as I don't change any values. So it looks like a triggered oscilloscope. --> "constant" signal

If I change the Samples to Read to 3000 I seem to be slower in "emptying the bucket". But why? I only read less samples and so I would expect just to see a smaller outcut of my signal (but more often). Why is the Buffer running full instead? In your example you said that while i read the samples the programm will wait for the time it needs to read these samples. But if I decrease the samples to read, this waiting time should also decrease and therefor it should not be a problem.

So something in my understanding is still wrong. I also read the article you linked. There it says:

Increase the number of samples per channel to read with the DAQmx Read VI. (Reads faster)

Why does increasing the number of samples per channel mean that I read faster?

Edit: Another thing I don't get. The "Update Generation Rate" seems to have an effect on the frequency of my output signal. Why? I create the signal with the Basic Function Generator and I define the amplitude and frequency there.

Thank you again for your kind help.

A confused Mo

[stockson]

Hi!

In your description it sounds like the Read and Write Buffers are the same, so they are sharing the same "bucket".

You are right in thinking that those buffers are separate, it is not the same "bucket". However if both read and write operations are happening in one loop, they can influence on each other.

If I change the Samples to Read to 3000 I seem to be slower in "emptying the bucket". But why? I only read less samples and so I would expect just to see a smaller outcut of my signal (but more often).

This assumption is correct, but the other factor is the maximum speed at which the loop can operate. It's possible that somewhere between 5000 and 3000 you would find a threshold value which would be correlated to the maximum execution speed of the loop.

What you can do is to benchmark how fast is the execution of specific parts of code. Then you will have a better understanding of what is blocking what 🙂 This is the basic structure of how benchmarking can be done: https://decibel.ni.com/content/docs/DOC-11078

Obviously you can do it also for portions of code.

Another thing that can make debugging easier is monitoring the "Available Samples Per Channel" parameter. It will tell you if the buffer is filling up quicker than you are emptying it.

Some other documents that may clear things up:

http://digital.ni.com/public.nsf/allkb/3E3D74E26B8A5B83862575CA0053E4B5

http://digital.ni.com/public.nsf/allkb/8EF7084B908ABF6686257589007C97DF

[Holomo]

Hello,

thank you. The hint with the property node "Available Samples per Channel" was very helpful. It's actually funny that exacly at 4000 Samples to Read there seems to be an imaginary line which is crossed and the Buffer starts to run full. I checked with the suggested benchmarking method that the loop cannot act faster than the 40 ms related to the 4000 Samples. So that's why at fewer samples the buffer runs full.

But now the funny thing is: if Samples to Read is not exactly 4000 or 5000 (and so on) but something in between (like 4001) the Samples to Read will again start to count up (very slowly) and the portion of the recorded signal will not be constant anymore. So the recorded signal is like a moving sine, not a standing one.

Why's that the case?

And I still don't understand why the Update Generation Rate can have an effect on the frequency of my signal. How are these 2 values connected?

Thank you so much for your help!

[stockson]

I'm not sure why this happens at 4001 etc. Does it overflow/overwrite at some point or it just "clears" to zero at some point?

When it comes to the "moving signal" - if, your generated sine wave has the frequency of 100Hz (for example), your sampling speed in 100S/s and you fetch 100 samples in each iteration,  each time you will be getting the full period of the sine (it can be shifted, but the shift will not increase/decrease). Now if you read 101 samples in each iteration, you are essentially getting one period + one more sample from the next period. So next time you read, you are "missing" the first sample of the period and then again increasing the "delay" by one sample. This is causing the "floating" effect.

The generation rate influences the signal frequency quite directly. When you are using the Basic Function Generator it is preparing a particular set of values based on the parameters you enter, including a desired sample rate. In your program you don't connect anything to the "sampling info" terminal, so it is using default values (Fs=1000, #s=1000). In this case, if the two sampling rates don't match (the Fs I mentioned and the AO update rate), the physical signal will differ from what you want to generate.

[Holomo]

Hi!

I begin with the last thing you suggested: I connected the Fs to the Update Generation Rate and the #s to the samples per channel. Now the frequency is exactly like I want to it be. THANK YOU! I tried to set Fs and #s earlier but with the wrong values and in the example nothing was connected, so I just left it like this.

While changing this, the other problems mentioned before seem to be gone. Now I can use Sample to Read > 4000 and the buffer won't fill and in addition there is no floating effect. Now that's strange because as you mentioned in your message earlier, there should be some floating if the samples to read don't match a multiple integer of the period of the signal. --> confusion again 😉 The good thing is: Now with the Fs and #s set also the overflow/overwrite-problem is gone for values like 4001.

But I've got an additional question: If I change the output values like for example the amplitude, it takes some time until I see this change. I understand that it cannot change immediatly but will need the while loop to run through one more time. But it seems to take more than this one cycle, more like 3 to 5. And: not the whole signal is updated in one step, but in 2 steps.

I already changed the AO.DataXferReqCond to "On Board Memory Empty", but that doesn't change anything. What I can't do is changing the Regeneration Mode. If I do this, nothing works anymore.

I attached my updated VI so you can see what I've added recently.

Mo

[stockson]

I will also start fromn the end 🙂

By default DAQmx is regenerating the samples that were at some point written to the buffer. This means that you will never reach an underflow error. While in most cases this is a very nice feature, sometime is causes problems. First of all, it takes some time before the new signal is physically generated (as you have observed). Another thing is that it can cause glitching when you update the signal (it is especially important if you are generating audio or if your signal is controlling some sensitive equipment). 

You can turn off regeneration by using this property, but you need to be careful. You are now in charge of supplying a proper amount of samples in every iteration.

You can find more infomation here: 

http://zone.ni.com/reference/en-XX/help/370466AC-01/mxcncpts/regen/

http://digital.ni.com/public.nsf/allkb/DD750D84BAD703E386256E6E005B41AC?OpenDocument

http://www.ni.com/tutorial/4402/en/

When it comes to the earlier questions - if I understand correctly, I would still expect the signal to be floating if you don't read the exact number of samples in one period. Maybe it is just happening much slower?