Generate staircase-shape SIN waveform

[RavensFan]

---

@Pavel_47 wrote:

1. ... In other words, the time it takes to generate the next packet of waveform may be adding timing between the end of the last one going out and the start of the first sample of the newly generated waveform going out. Anyway the neighborrow steps (within the packet of 1000 samples) aren't affected by this case. My measures in BOTTOM loop show that even neighborrow steps aren't equal. Ok, I will change acquiring mode to see the difference. Unfortunately with my oscilloscope it's quite difficult to do such measurement on hardware.
2. ... The problem with your bottom loop is your are just acquiring 1 sample at a time, so it you now back to just software timing of your acquired data. Have you an explaination why meausrements with INP Waveform chart differ from mesurements obtained with the staff located in the top part of the BOTTOM loop ... after all, the "input" for both is the same. Moreover, the measurement staff requires division by 2 (or my measurement staff isn't correct ?)

What about issue with STOP button. Is my supposition correct ?

Thanks

---

You can't rely on anything from your bottom loop.  You've turned it into software timing.

Think of the top loop sending cars down the highway at a regular interval.  Think of the bottom loop as someone standing by the side of the road watching those cars.  If you tell him to wait for a car to go past and then do something like write down the color, then go back and wait for the next car, he might miss 2 or 3 other cars that go past while he wasn't paying attention.  That is software timing.  If you tell him to watch 100 cars at a time, don't look away, then write down how many of each color he saw, he is not going to miss any.

Your mean of 80 might be from the bottom loop sitting there seeing all zeroes before the top loop has a chance to spit out the first packet of data on an analog write.  Hard to say what it might be.  When I can't trust the bottom acquisition, there is no way I can trust anything that is derived from that acquisitioni.

As for your stop button, does the top loop never stop, or just take a long time?  It is possible what you supposed is the answer.  I don't know, without hardware to play with, I can't experiment to be sure.

But you've got the hardware.  You also need to look at the DAQmx examples.  There are numerous ones and some apply more to your situation than others.  Often, those examples show timing configuration functions.  Continuous vs. finite.  Regen vs. Non-Regen.  Your code doesn't show any of that and it might be needed.  It often as functions to check the status of the DAQmx output.  Your code doesn't show that.  Often they will put a DAQmx stop task inside the loop.

It's up to you now.

[Pavel_47]

Ok, here is the version, where waveform is generated outside of while loop, so all timing issues should disappear, isn't it ?

The image that follows - screenshot from oscilloscope. As you can see, the step duration is still more than 100ms.

Here is screenshot of the running VI ... as before generated waveform (TOP graph) demonstrates perfect timing (100ms), whereas acquired waveform measures slightly less than 100ms (80 ... 90).

I've also tried with "packet acquiring", but it didn't change the things.

Well, the std. deviation is quite small, but anyway is it possible (in principle) to generate high-precision (in timing sense) signals without having to address to FPGA solutions ?

Thanks

Pavel

P.S. Here is the last version of VI:

[RavensFan]

You're not listening.

Did you read my last message?  Did you look at any DAQmx examples?

Your bottom loop is still only acquiring 1 sample at a time which means you are acquiring data only as fast as the software allows it.

[Pavel_47]

Yes, I'm listening

I've mentionned in my previous message that I've also tried with "packet acquiring".... although in this case all my measurement staff becomes useless.

Here is screenshot  - in this version time measurements are less easy, but anyway one can see that time step isn't constant.

And here is VI

Did you look at any DAQmx examples?

You mean this link:

http://www.ni.com/product-documentation/2835/en/

If so, YES, I had a look on it.

Regards

Pavel

[RavensFan]

That is a good link, but that isn't what I was talking about.

Help >> Example Finder  search for DAQmx

Many of those examples have functions for clock timing in there and things like continuous acquisition and regenerateion for analog outputs.  Your images show none of that.

[Pavel_47]

I had a look on examples.

Indeed, their number is quite impressive (typing generation/acquisition return more than 1500 examples)

I've tried some of them.

Perfect timing performance is observed in examples, where there is no while loop, i.e. channel is configured for continuos generation ("Continuous Samples" option).

But in such case abother problem rises (related to particularities of the testbend):

1. generated signal is applied to DUT (device under test)
2. output of the DUT is applied to the analog input
3. once a particular condition occurs on the input, output value must be frozen (or at least recovered from a device buffer)

Without while loop, there is no permenent control on the output.