C# DaqMx PWM Ramp Rate NI 9472

[Fifty60]

Hello, I have a NI 9472 that I am using to generate a PWM signal via C# using the DAQ.mx library.  I am able to change the duty cycle quite well.  For example if I want to go from 40% to 70% I can do that.  However, I can not do this over a predetermined ramp rate.  For example, if I want to ramp from 40 to 70% over 7 seconds, how would I do that?  Is there a function/method in the DAQ.mx C# library to do this?

[Kevin_Price]

Whether you can do it with hardware-level precision will depend on your chassis, where the counters used for PWM reside.  You'll need to check whether your chassis supports "buffered counter output" which would let predefine every pulse interval for your 7 second generation time.

Else, you can approximate the PWM ramp rate using software timing where you update the PWM duty cycle 10 times a second or so.  Since you only need to cover a 30% change in 7 seconds, each update could be less than 0.5% duty cycle change.  So software timing might do the job well enough.

-Kevin P

[DanielG1234]

Hi,
I was searching for a way to generate a PWM or Square Waveform from the 9472, and found this thread.  Could you please share the method you are using to generate the PWM signal?  I am also using DAQmx and C# for this project.  Do you have any examples that I could learn from?

Thanks.

[Kevin_Price]

I can't help with any C# examples or syntax as I'm a LabVIEW programmer.  I can mainly speak to the *idea* behind how to do this with DAQmx.

I would normally suggest you generate PWM with a Counter task rather than a DO task.  Pulse trains such as PWM is one of the things counters are made for.  It's also much simpler (and more immediate) to vary the duty cycle on the fly when you have an app that calls for that kind of control.

So that's my first advice: look for examples to generate a continuous pulse train where you can define the frequency and duty cycle.   Note the following little DAQmx quirk for future reference: when changing duty cycle on the fly, you actually have to *also* write a fresh value to the frequency parameter.  It can be the same value every time, but for some reason it's the act of writing to the frequency parameter that causes both duty cycle and frequency to be updated on the hardware.  Changing duty cycle alone just keeps changing the pending value that won't go into effect until you write a freq value.

-Kevin P