Number of sample and sampling rate

[JCArifin]

Thank you, Andy, Kevin, and Henrik!

Now my VI is working as intended :). And yes, using chart is better for me.

-Jane

[arienai]

thank you so much, also Kevin for the valuable help.

How to modify this vi in order to work also with "finite samples" rather than continuous.

For example, the output signal can be generated by Ao0, and with a trigger to synchronize Ao0 with Ai0:2. 

Should the sample clock be placed inside the while loop to regenerate the Ao0 for each value of x (it is a kind of for loop on x that I like a lot) ?

With continuous mode (clock), the initial value of the signal is random. 

In the case that the output signal has finite period and number of sampling (I mean the array size is fixed by user), the READ of Ai1:2 should start at the initial value of the Ao0. 

(in the posted vi, as it deals with continuous output waveform, it does not matter). 

By the way, the data file that is recorded contains 0-1 only, but not the data in txt. I don't really understand why since number to string conversion is operated as well as time string. 

[Kevin_Price]

I don't think I fully understand what you need, but the main thing for you to learn about is the use of a "shared sample clock" to sync your AI and AO tasks.

Here's one example I posted that generates such a clock with a counter.  And here's another where the AI task is configured to "borrow" the AO sample clock directly and use it as its own sample clock.  Both keep the tasks in sync because they share the same signal to act as their sample clocks.  (And the tasks are carefully started in the appropriate sequence to make sure their 1st samples happen at the same time.)

-Kevin P

[arienai]

thank you Kevin. 

I tried to run the vi in the second link, but I got an error -200284. 

The most important for me was to understand your vi. It is an advanced vi, especially the usage of clock implicit was not easy to understand. But I have understood that you are using a pulse function on the DAQ that mimics a trigger. So you sent a pulse train to the PFI0 that will synchronize all the output Ao0 and Ao1. 

The daq control task set to commit is less intuitive to me as a beginner with DAQ. 

I noticed also that you start task of the pulse AFTER starting the Ao0:1. 

Also it deals with finite sample measurement, but the pulse is continuous. 

OK. So now, I will post my vi that has problems with the READ data. I think that it comes from the fact that I made this example with an array of DBL rather than a waveform that includes time. 

Also I still did not implement the clock on "finite samples" (what I need) but it is on "continuous". 

After thinking a little bit more, I found that high speed measurements is not necessary here. I am not trying to push the limit of the DAQ in term of mega samples per seconds. Rather, I just need to measure enough data at each amplitude of my triangle waveform. So probably I might need to convert the triangle in a triangle with stepwises, each steps having 100 or 1000 replicated amplitude. Then measure at each sample : this might be an alternative to an increase sampling time and rate on the clock if I consider the initial triangle wave (without stepwise). I am not really sure about this. 

Maybe I should also start measuring the input BEFORE starting the OUTPUT, so that I am sure to get the first value of the output Ao0 in any situation. 

My initial triangle waveform is defined by a max, min and period. The period is typically 100sec. The number of samples in this initial triangle is about 100 or 1000 values. 

For each of those values, I need to read Ai0:2 several times in order to get mean + error bar. That means the triangle is becoming a kind of stepwise form, with replicate amplitude during period/nb of sample = 100sec / 1000 points = 0.1 sec. So having a clock every 1msec (100us)  will give me 100 (1000) data for each amplitude. 

Then I need to repeat this measurement over the period of 100sec let's say 10 times. 

Here, I am wondering if I should initially create  10 basic triangles as a initial waveform, or if I can create a for loop for this (in this case, I guess I need to run again the output signal for each loop). 

How to make things simple and efficient ?  

[Kevin_Price]

I'm now realizing I'm discussing the same app with you in two different threads.  Let's shift the discussion over to the other one, where I think there's more detail laid out more clearly.

To briefly address your latest post here though:

- the 2 bits of code I linked to weren't meant to be exact versions of what you need.  They were just meant to illustrate how to share a sample clock between tasks.  However, by cross-referencing that other thread, I realize that you wan't *sync* but you don't want the same sample rate between your AO and AI tasks.  Bottom line: there's no point troubleshooting that -200284 error.

- I can't open the code you posted b/c I'm not using LV2019 yet.  Please back-save to LV2016 or earlier (menu choice: File-->Save For Previous Version) and post to that other thread.

-Kevin P

[arienai]

Inspired by a vi made by someone else (sorry, I do not remind from whom), this is typically what I would like to achieve. 

Excepted that the recorded data does not follow the waveform of the triangle, because it starts recording at random amplitude. But one can see that there are many data for each amplitude. 

I cannot master well the definition of the READ period. The read data period is 4msec, but my triangle waveform is intended to cover a period of 1sec. 

So I would like my data also to have a total period of 1sec, with many data on each step (defined by user). This is my dream with this DAQ !  

So I believed that I should set the clock with a high rate (500 000) and a number of sample per channel of 2000. That is why I got 4msec period rather than 1sec. 

I though that by defining a high rate, the DAQ will give a small dt for recording, thence leading to a large amount of data for each output amplitude. But this is not the case : the clock is modifying the period of the output waveform.