From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem with simultaneous PWM with NI-9041

Hello everyone,

I'm running a very very simple vi with 4 PWM that are being sent through a NI9401 module to a PCB.

I'm using the DIO channels 0 to 3.

I'm simply using 4 numeric controls on the front panel to be able to independently control the Duty Cycle of the PWM signals.

Now, when I set the DC of channel 0 to 50%, all is good, the PWM is correctly displayed in my oscilloscope. But, when I set the DC of channel 1 to something like 30%, this PWM signals also is being displayed with a 50% DC in the oscilloscope.

Now, for another experiment:
Set channel 1 to 0%
Set channel 2 to 40%
Increase in 10% steps the channel 1 from 0 to 100...

When I do that, the channel 2 stays at 40% before the channel 1 reaches that value as well, but as soon as channel 1 goes beyond this duty cycle, the channel 2 will lock onto the same duty cycle as channel 1, I don't know why is this happening, these 4 pwm signals are not connected in any way whatsoever.

 

Please help me out

0 Kudos
Message 1 of 8
(2,364 Views)

Hello everyone,

I'm running a very very simple vi with 4 PWM that are being sent through a NI9401 module to a PCB.

I'm using the DIO channels 0 to 3.

I'm simply using 4 numeric controls on the front panel to be able to independently control the Duty Cycle of the PWM signals.

Now, when I set the DC of channel 0 to 50%, all is good, the PWM is correctly displayed in my oscilloscope. But, when I set the DC of channel 1 to something like 30%, this PWM signals also is being displayed with a 50% DC in the oscilloscope.

Now, for another experiment:
Set channel 1 to 0%
Set channel 2 to 40%
Increase in 10% steps the channel 1 from 0 to 100...

When I do that, the channel 2 stays at 40% before the channel 1 reaches that value as well, but as soon as channel 1 goes beyond this duty cycle, the channel 2 will lock onto the same duty cycle as channel 1, I don't know why is this happening, these 4 pwm signals are not connected in any way whatsoever.

 

Please help me out

0 Kudos
Message 2 of 8
(2,362 Views)

I think the problem is being caused by the implementation of the Express VIs you're using.

It looks like each contains a SCTL, which stops only when the boolean output changes (or you have invalid inputs, like DC = 0 or f=0).

As a result, the While loop rate that you have is determined by the slowest changing value, and it will sort-of lock them together.

 

To fix this, you can remove the Express VIs and create a cluster containing your currently desired frequency, then 3*2 pairs of "Wait Remaining" and "Wait Total" (3 channels, high and low times). You can calculate the Wait Totals by doing 1/f * DC = high total, (1/f * (1-DC)) = low total, or the opposite (I don't remember if DC is fraction high or fraction low, but I think high?)

Then, decrement the "Wait Remaining" each cycle of a SCTL, and if =0, reset to the value of "Wait Total" for that type (e.g. "Wait Total High 1") and change the boolean (probably also putting this value in the Shift Register's cluster is easiest for working out if your next is high or low).

 

The difficulty will be in consistently handling the behaviour when changing the inputs (frequency, DC{1,2,3}). How do you want it to behave in that case?


GCentral
0 Kudos
Message 3 of 8
(2,330 Views)

Actually, before you do that, changing your While loop to a SCTL and changing the Express VI configuration to "Inside a Single Cycle Timed Loop" is probably worth trying. That looks like it has a good chance of working and will not require much effort to check.


GCentral
0 Kudos
Message 4 of 8
(2,326 Views)

Hello cbutcher, thank you for your input,

 

This is actually a small part of a bigger project that I'm developing in another big VI,

 

the frequency will be kept at 20kHz, and I will be using a combination of PWM with Sinusoidal modulation (the magnitude of the modulation will be controlled through a model coming from the RT). These "Sinusoidal PWM" - as i like to call them - will then be filtered through a circuitry that I've already designed (and I've proven it's functionality) and I can obtain a sine wave of 125 Hz proportional to the magnitude of the modulation of these PWMs.

 

I'm talking about something like 20 Sinusoidal PWMs, but in this big project I'll also need 4 "normal" PWMs that will only change the DC at a more linear fashion (that will later be filtered through a circuitry to obtain the a DC voltage value, proportional to the Duty cycle).

 

I'm unable to use SCTL because of the Sine wave generator function that I'm using to create the core signal that will control the Duty cycle of the SPMWs, the sine wave generator is not compatible with SCTLs.

I've found a temporary solution which involves raising the "reset" boolean value of these 4 Square wave generators and then pulling it down (I could do this programatically after 1 or 2 iterations of the while loop, I think).

 

After I do this, the PWM will start becoming independent from each other again. I tried this particular "solution" because I saw inside the Express VI that there's an "or" gate that has the following inputs:

check for the first call of the VI

or
reset flag = true

 

Despite this fact, I'm not actually very convinced that this will actually solve the problem on the long-term. I think I'll try the first solution that you offered though (The second solution works pretty well, I tried it earlier today after posting my issue, thank you!)

 

I hope that this clears up some stuff, maybe you could give me some further suggestions,

 

Thanks again!

0 Kudos
Message 5 of 8
(2,323 Views)

Would something like a VI-Defined FIFO help you?

SCTL.png

I didn't compile this, but it generates the intermediate files fine. Obviously if I put the wait in the SCTL as well it fails (I use this just to demonstrate splitting allowed and non-allowed functionality)

 

Edit: I'm looking at this now - of course, that should be "Not Timeout" as the enable input to the FB node. (And I didn't test that, so just check it's not logically broken to do that to only get valid values - you can check the FB behaviour on Desktop).


GCentral
0 Kudos
Message 6 of 8
(2,320 Views)

I'll test this tomorrow at the workplace for the Sine wave generators and I'll let you know

0 Kudos
Message 7 of 8
(2,317 Views)

I think this is equivalent as a desktop test:

QueueDesktopEquivalent.png

(If you don't want to drag and test, it works 🙂 )


GCentral
0 Kudos
Message 8 of 8
(2,316 Views)