LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx generate subset of buffer

Solved!
Go to solution

Hello friendly forum members 🙂

 

I have a problem I haven't been able to solve. What I would like to achieve is to more or less arbitrarily change the content of the write buffer of a daqmx-task without having to stop the task. Is this at all possible?

 

I have made an example that illustrates my problem, please see attached image.

 

Block diagram exampleBlock diagram exampleIn the code, two buffers of different sizes are illustrated. At this moment they are simply a single period of a sine wave, but in the future I'd like them to hold arbitrary content. I then apply the difference of buffer sizes as the offset property of a Write property node. The documentation for the RelativeTo property states "Specifies the point in the buffer at which to write data. If you also specify an offset with Offset, the write operation begins at that offset relative to this point you select with this property."

 

I can see it begins at the correct phase in the buffer, but unfortunately the write operation seems to wrap around to the beginning of the buffer, so that the old data is also written. I've attached a photo from an oscilloscope that illustrate the problem. Is it possible to ensure that just a subset of the buffer is written? Or is there another approach that makes sure two different buffers are written continuously back to back (without having to end the tasks.

Oscilloscope snapshotOscilloscope snapshot

Best regards,

Oscar 

0 Kudos
Message 1 of 4
(2,404 Views)

Let me state that this is coming "off the top of my head", without my taking my own advice of "be a scientist/engineer, form a hypothesis of How It Works, then write a little VI to test and confirm/refute your hypothesis".

 

You have set up your DAQ device to use Continuous Sampling.  You associate it with a (fixed-length) Buffer to serve as an intermediary between you (memory) and the hardware device.  The Device will (hypothesis) use the contents of this buffer over and over again until you say "Stop" -- it is your responsibility to see that the Buffer contents are always "right".

 

As long as you maintain the data in the buffer appropriately, your scheme will work.  Say you have a buffer of 1000 samples.  You generate the first 1000 (say, 10 cycles of a sinusoid with 100 points/cycle) and put it in the buffer.  You generate two more cycles and then want to change the waveform to 16 cycles at 50 points/cycle -- well, that's 1000 points that you put in the buffer (200 for the first two cycles and 800 for the next 16).  As long as you keep filling the buffer appropriately before it is time for the DAQ Write to read it, you should be OK.

 

Note, however, that if you do what you did and fill, say, the middle third of the buffer with new data, you'd see an output consisting of the unmodified first third, the modified middle third, and the unmodified last third.

 

Bob "But Do The Experiment First!" Schor

Message 2 of 4
(2,387 Views)

I don't think you'll be able to accomplish the thing I *think* you're after with the simple kind of approach you've been taking.  I'm essentially agreeing with what Bob_Schor already said but am emphasizing that your code is liable to become more complex.

 

1. Fact - once you've defined a buffer size for your task, the size *cannot* be changed while the task is running.   In your example, the buffer will always hold 1667 samples.

2. Fact - in a continuous AO task, when DAQmx reaches the end of the buffer, it wraps around and treats it as a circular buffer as it keeps generating.

 3. Fact - the position within the buffer where your application code can write data is *distinct* from the position within the buffer which DAQmx tracks as it continuously feeds the board with data to turn into real-world DAC signals.

   Consequence - it's not common practice to explicitly calculate a specific offset within the buffer where you write your data.  Most (not all) people who think they need to do it don't really.

4. Fact - DAQmx has some carefully thought out safeguards in place to try to prevent you from doing mischief to the buffer on-the-fly.   

   Opinion - I'm not sure they're totally foolproof.  Writing to explicit locations within the buffer opens you up to various kinds of unexpected behavior, especially if your expectations come from intuition or educated guesswork rather than specs & verification tests.

 

Consequence - you made a task with a 1667 sample buffer.  The task will keep generating indefinitely from that buffer sequentially and circularly.  If you later want to start generating a 500 sample waveform, you can't do it by writing to the buffer just once.  You'll have to keep writing to the buffer repeatedly because your 500 sample waveform won't wrap around cleanly at a 1667 sample boundary.  You'll have to commit yourself to having your app write to the buffer at a rate that stays "just a little ahead" of the DAC sample clock.

 

This is a little analogous to putting a railroad track factory on a train, starting the train down some unfinished tracks, and committing to making sure that the factory produces tracks fast enough to keep putting them in front of the train before it reaches the end of the line.   You can do it, but it's less trivial a problem to solve than laying out all the tracks once and then sending the train down them.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 3 of 4
(2,367 Views)
Solution
Accepted by topic author ocyj

Hi Kevin and Bob, and thank you for your carefully thought out response 🙂

 

I've continued to do some research and found the approach based on the setting "Do not allow regeneration". I've based my approach on the example NI DAQmx: Continuously Generate Waveform - Non Regeneration - Rapidly Updating.

 

It's not ideal in my case, but it will have to do!

0 Kudos
Message 4 of 4
(2,336 Views)