PCI-6713 buffer update time

[penguin1]

Hullo guys,

 
We were using PCI-6317for 50 Hz 3-phase waveform generation for a quite a while using traditional NI-DAQ library.

We could not get reliable update of a waveform with a single call to WFM_DB_Transfer function and have to double call it.
Otherwise we could sometimes get a signal composed of previous and current buffer.

For the time it was a good solution but now we have different requirements.

We switched to NI-DAQmx and surprisingly managed to update PCI-6713  buffer with a single call to DAQmxWriteAnalogF64. But it looks like we can update the buffer only once per output signal period.
For our 50 Hz signal it is 20mS. The function blocks till the next period.

Here goes the first question.
Can we call DAQmxWriteAnalogF64 updating waveform more often than 50 times per second for 50Hz output signal?

If the answer is positive than how can it be done?

I attached a LabWindows CVI 7.0 source code for a sample test program (for 1 channel only) we wrote especially for this post.
The waveform generation is started by invoking ConfigureTask and StartTask callbacks in this succsession.

Could anybody kindly point me out what changes to code must be made to update output buffer asynchronously with output signal?

And another question.
Can PCI6317 generate signal with different frequencies (say channel 1 generates 50 Hz signal, channel 2 - 60 Hz etc)?

Thank you very much for any glues provided!

Andriy

[penguin1]

I am sorry.

I found this thread Independent analog generation with DAQmx

so the question  about generating signals with different frequencies is answered.

[EricS.]

Hi Andry,

You are correct that DAQmxWriteAnalogF64 is a blocking function.  Therefore you cannot call it again before it finishes outputing the previous buffer.

However, why do you want to call it faster that 50Hz?  If you just want to continually output a 50Hz sign wave and make sure you have phase continuity (meaning you don't miss any points from cycle to cycle) you can just enable regeneration.  This would mean you only load data to the buffer once, and DAQmx will automatically regenerate the signal from data in the buffer.  The buffer doesn't actually change, but DAQmx just loops back to the beginning of the buffer and continues to output the same data over again at the same rate.

Even with regeneration you can still call the DAQmxWriteAnalogF64 function and change the buffer (for example, changing the amplitude or frequency) and then it will continually output that new signal until otherwise noted.

[penguin1]

Hi Eric,

Thank you for the reply.

We know about regeneration mode and moreover we use it.

We would like to change the waveform (please, note that waveform must not necessarily be a pure sine) on the fly, the same moment (we the lag may be no more than 3 mS) we know how to change it.

Sounds strange?

We want to run a system with feedback loops and PCI-6713 must react faster than in 20mS (the worst case).

We have come across example code at  http://zone.ni.com/devzone/cda/epd/p/id/39

But here the waveform is just cleverly simulated by frequent buffer updates (regeneration must be turned off in this case!). Too often the program stops with error 200290.

[EricS. · Accepted solution]

The short answer to that question is no.  It's not possible to dynamically change the buffer mid-output.  You have to wait until that buffer is depleated and then change the buffer to the next set of data.

The only thing to do with your current hardware is to reduce the waveform/buffer size.  You would need to call the write function significantly more often, but you could change it at anyone of those points.

Also, getting a reliable 3ms response in your software feedback loop will be completely dependent on the speed of your computer.  If Windows decides it needs to allocate resources elsewhere (automatic update check, MS Word being opened, media player playing music), then the CVI program can definitely lag.  Therefore it could miss the buffer update, which is most likely the reason you are getting the 200290 error. The code cannot run fast enough to process everything before the buffer depleats.

The absolute best thing to use for control is one of the FPGA modules.  With them you actually embed in hardware what you want your control algorithm to be.  This means the control algorithm is all hardware timed, producing the best response times possible.

What rate are you inputing for the sampling rate?  Also, in the code you sent you're sending "fFrequency*SAMPS_PER_GRID_CHANNEL" to the DAQmxCfgClkTiming function.  I'm wondering why you're multiplying your frequency by SAMPS_PER_GRID_CHANNEL.  The rate input parameter should just be the frequency in Hz that you want the points to be generated at.

[reddog]

What you're asking to do should be possible with your hardware/software but not necessarily easy.  Here's some past posts dealing with similar topics.  Some of them deal with digital output, but the fundamental concepts should still apply.  Give them a read and see if they give you any ideas.  If you still have questions about how to proceed, post back your questions and we'll go from there.

Related Post 1

Related Post 2

Related Post 3

[penguin1]

Thank you for the feedback, guys!

You are doing a great job helping amateurs like me. I mean it!

I believe that we can make a right decision/move with the information provided.

PS.  As to the question about multiplying fFrequency by SAMPS_PER_GRID_CHANNEL, it cannot really matter whether we multiply here or divide later. I agree though that our sample code is a bit muddy.