Please, Help me. I need to do Pluse Width Modulation using LabVIEW 7.1

[bkk]

I need to do Pluse Width Modulation (PWM) using LabVIEW 7.1. I have some analog signal e.g. sine-wave, then I want to transform this signal to be PWM signal.

See in Figure,

Now I already make by myself, but it 's not good. Because the frequency of sawtooth is very low, so the PWM signal is not smooth. Please , help me or give me for example.

I will try its.

[JLS]

Hello,

From the looks of your attached picture, generating a pulse width modulated signal really amounts to simply comparing two signals (say A and B), and when signal A >= B output some "high" value, and when A < B output some "low" value.  I am not sure what you're having trouble with - you should be able to use the comparison functions in the comparison palette to compare the signals and generate the corresponding PWM "square wave."  Are you having trouble defining the comparison code, or is actually generating the PWM signal with hardware giving you trouble?

Best Regards,

JLS

[bkk]

My trouble is that : I already make the comparision between 2 signals, but the PWM that generate from the different between 2 signals      isn't good because it's very low frequency. I need to improve my PWM becomes high frequency or faster. Thank you.

[JLS]

Hello,

I'm sorry, but I don't think I understand what you're having trouble with - can you post an example or a screenshot?  When you say, "but the PWM that generate from the different between 2 signals isn't good because it's very low frequency", are you saying that your low frequency signal is causing your PWM to be not good?  What do you mean by "isn't good"?  When you say, "I need to improve my PWM becomes high frequency or faster", are you saying that your current algorithm works, but you don't think it will work for higher frequency signals?  Are you saying that you need your PWM wave that results to have a higher frequency because the slow varying input signals are making your PWM wave "too long."  If this is the case, how about decimating the array to make your waveform shorter, but still maintain the high and low segment proportions.

I hope this helps to clarify things!

Best Regards,

JLS

[bkk]

Yes, I'm saying that my current algorithm works, but I don't think it 's work well. Yes, I'm saying that I need my PWM wave that results to have a higher frequency because the slow varying input signals are making my PWM wave "too long." 

The conclusions is that, because of the my sawtooth generated from LabVIEW  is very low frequency approximately around 100 Hz and can't generate higher than this (maximum is 100 Hz). I don't know why, when I change the higher frequency more than 100 Hz it will not generate sawtooth, It generate dc.  

[JLS]

Hello,

I think the problem you're having comes down to how you're using the function.  Basically, the frequency input to the sawtooth function is defined poorly in units of cycles/sample.  Of course, we're used to seeing frequency defined in terms of samples/second.  But remember, all we have in any programming language is data - in this case we have an array of data.  The timing information is to be interpreted, and has nothing to do with the data that defines the waveform.  What I mean here is, the time per sample in the sawtooth waveform is completely arbitrary and has nothing to do with the sawtooth itself.  It will be defined if you physically output that waveform, because you will be writing some number or samples per second - that will define the frequency of the waveform.  Thus, when you are working entirely in software, what you fundamentally care about are the number of samples, or perhaps a bit more specifically, the number of samples/cycle (for periodic functions) and also the number of cycles you'd like to define (together these two tell you the total number of samples).  Of course, if you know the rate at which your samples will be output, and you know the samples/cycle that you've defined, those to pieces of information tell you the actual frequency that the signal you output will have.

The moral of the story is, when you wired 100 to the f input of the sawtooth function, it was interpreted as 100 cycles/sample, which clearly doesn't make sense because a single sample cannot represent 100 cycles, let alone even a single cycle.  Take a look at the attached VI, where all I have done is used the reciprical function to make the front panel input be in units of samples/cycle instead of cycles/sample.  This way you can specify the total number of samples and the samples/cycle, and you should have a pretty good feel for how to use the function in the slightly modified form.

I think that clears things up!

Best Regards,

JLS