Generate 2 sine waves, different period, same # of samples

[MichaelBalzer · Accepted solution]

Hi Jeff,

In the shipping example Kevin mentioned, the RegenMode property of the DAQmx task is set to Do Not Allow Regeneration. This is required to allow new waveforms to be output (else it will reuse the same waveform in the output buffer). There might also be an issue continuously setting the DAQmx Sample Clock before every write. This only needs to be set once outside the while loop.

[Kevin_Price]

Fully agree with both things MichaelBalzer mentioned.  I also noticed that your initial DAQmx Write sends in waveforms with dt=0.  That may be setting up an error condition.   Further, your DAQmx Write code depends on the Timeout event which might be setting up further issues.

Have you tried running the shipping example as-is (other than changing the sine wave parameters to match your needs)?  I think that might be the best next step -- we've identified several little things that are troublesome in the code you posted, and there might be more.  To try out the basic *concept* of continuously feeding data to an AO task, I think the quicker thing is to start from the known-good shipping example.

-Kevin P

P.S.  This is all in the interest of learning new approaches.  I continue to think your current application should stick with the 1-minute buffer and regeneration.

[Bob_Schor]

---

@Kevin_Price wrote:

P.S.  This is all in the interest of learning new approaches.  I continue to think your current application should stick with the 1-minute buffer and regeneration.

---

I've used (and like) this approach -- the only "downside" is that you can't easily "stop in the middle" -- when you push the "Stop" button to end the DAQmx Write loop, you will (on average) need to wait 30" for the 1-minute buffer to play out ...

Bob Schor

[Kevin_Price]

---

@Bob_Schor wrote:

---

I've used (and like) this approach -- the only "downside" is that you can't easily "stop in the middle" -- when you push the "Stop" button to end the DAQmx Write loop, you will (on average) need to wait 30" for the 1-minute buffer to play out ...

---

I don't think I follow.  With the regeneration approach, there is no more "DAQmx Write loop".  You write just once before starting the task and never again.  The driver handles all the dirty work after that.   When you want to stop your app, you just go ahead and stop the task.  There's no *DAQmx* need to wait for anything.

But if you're thinking of an app-specific desire to run a buffer to completion before stopping (such as to make sure all the sinusoid outputs return to 0 output values), well, I guess I *still* don't follow.  You wouldn't be able to time the loop stop to coincide exactly with the end of the buffer in a continuous AO task anyway.

The simple approach that's often ok is to stop the AO task and then just write 0 values directly.  If the system would be disturbed by such a step function, some more elaborate method would be needed.  In such scenarios, I'd be more inclined to avoid regeneration and do the continuous loop & feed approach.

Or did I misunderstand your point?  It wouldn't be the first time I responded to the scenario I was reminded of instead of the one being described...

-Kevin P

[Bob_Schor]

Kevin,

     I suspect the problem was my mis-understanding of how AO/Regeneration worked.  I know (or thought I knew -- now that I think about it, I never explicitly tested this behavior) that you write into the Buffer, Start the AO, and in the While Loop, write into the Buffer again, with the Write "blocking" until the previous buffer empties and it is time to write again.  Ah, I think I see my stupidity -- if it is doing regeneration, you don't need to do another Write inside a While Loop!  Sorry about that -- need to Engage Brain before Fingers and wear my Scientist Hat more prominently ("Do the Experiment" ...).

Bob Schor

P.S. -- I was also subtly misled by my own experience generating a Sum-of-Sines (more than 20 years ago).  We typically had 8 relatively-prime harmonics of our very low (from 0.001 to 0.02 Hz) Sinusoid and were doing "on-line" binning of the data to see the responses at the 8 stimulus frequencies accumulate.  Because of these limitations, we needed to take integral (often 1) period(s) of the fundamental in order to "average out" a reasonably clean set of 8 sinusoidal stimuli ...  Still, no excuse for not thinking clearly.

[DMJeff]

Hi Kevin,

Well, it seems the key to the issue was the 'DAQMx Write' property, 'Regen Mode', 'Do Not Allow Regeneration'.  When I added that to the AO task setup, things cleared up nicely.

Thanks for the help,

Jeff

[DMJeff]

Hi Michael,

Yes, the 'RegenMode', 'Do Not Allow Regeneration' was the key.

I had tried moving the Sample Clock outside of the While loop before, and that hadn't fixed the problem, so I left it alone.  After I put in the RegenMode setting, things settled out nicely.

Then I moved the Sample Clock outside the loops, in the initial setup steps, and things continued to work nicely.

Thanks for the input,

Jeff