LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW PID controlled PWM output

Solved!
Go to solution

Hi nad,

 

please ask your questions here in the forum. PMs are not meant to discuss LabVIEW problems…

 

why you use tick count and when you multiplie by 0.001 why 0.001 and not 1000.

Do you understand the math taking place in this snippet?

It's the conversion from ms to s…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 11 of 18
(1,800 Views)

Hello everyone, 

 

I have a similar problem as described in this thread and the solution was very helpful, I kindly thank you. 

 

However, I have a question regarding the effective minimum and maximum PID output. 

Imagine that each iteration of the loop  takes 100 ms and the PWM cycle is 3 seconds. This makes the effective minimum and maximum PID output to be 100/3000= 3,33% and 96,66% respectively. When the PID output is outside of this band, there is no action on the system. In my particular case, since I want the code for the PID to run in parallel with the rest of the VI for my application, the band is even smaller (around 5-95%). My system is sensitive to this PID output, so my question is if there is any way to increase the "resolution" of the program or if it is a limitation of the code. 

I tried to increase the PWM cycle but since the electric resistance I use has an high power output, it causes a little fluctuation in the system that I wanted to avoid by using small cycles.

 

Thank you very much.

0 Kudos
Message 12 of 18
(1,687 Views)

Hi vpereira,

 


@vpereira wrote:

However, I have a question regarding the effective minimum and maximum PID output. 

Imagine that each iteration of the loop  takes 100 ms and the PWM cycle is 3 seconds. This makes the effective minimum and maximum PID output to be 100/3000= 3,33% and 96,66% respectively.


Your limit calculation is wrong: your PWM signal can be "all time low" (0%) or "all time high" (100%). The steps for duty are 100/3000*100% = 3.33%…

 


@vpereira wrote:

my question is if there is any way to increase the "resolution" of the program or if it is a limitation of the code. 


You can either decrease the "100 ms" loop time or increase the "3000 ms full cycle time" to increase the resolution (aka duty step size) of your PWM output…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 13 of 18
(1,664 Views)

@GerdW  wrote:

 

Your limit calculation is wrong: your PWM signal can be "all time low" (0%) or "all time high" (100%). The steps for duty are 100/3000*100% = 3.33%…


Yes, I omitted the 100% because I thought it was obvious, I am sorry.

 


@GerdW  wrote:

 

You can either decrease the "100 ms" loop time or increase the "3000 ms full cycle time" to increase the resolution (aka duty step size) of your PWM output…

Increasing the duty step size causes a lot more fluctuation in my system and I need to avoid that.  I already knew I had to decrease the loop time, my question was how can I do it. I was not clear, I am sorry. 

Please find attached a image of my VI. Basically I read 3 temperatures and when the user clicks "Reinitialize" it creates a ramp to the SetPoint with the required ramp. 
Thanks for the help.

0 Kudos
Message 14 of 18
(1,636 Views)

Hi vpereira,

 


@vpereira wrote:

I already knew I had to decrease the loop time, my question was how can I do it. I was not clear, I am sorry.

In this image there is no timing function visible.

The only place where a timing might occur is the DAQmxRead function: did you set any sample timing in the DAQmx task?

 

(It always helps to attach the VI instead of a cropped image of the block diagram!)

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 15 of 18
(1,628 Views)

I am sorry for the mistake, here it goes.

 

I did not put any timing DAQmxRead function, I assumed that by being on demand it would be as fast as possible. 

0 Kudos
Message 16 of 18
(1,628 Views)

Hi vpereira,

 


@vpereira wrote:

I assumed that by being on demand it would be as fast as possible. 


Your assumption is correct.

You wrote you are reading some temperatures: which kind of module do you use in your cRIO?

Did you read its specs, especially about the supported sample rates?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 17 of 18
(1,625 Views)

Dear GerdW,

 

After inspecting the specs of the cRIO, I can tell that the loop time is indeed caused by the sample rate. 

So it is fair to assume that the problems I am having are limitations of the equipment I am using and I need to start thinking in acquiring the correct one. 

 

Thank you very much for your time and help

0 Kudos
Message 18 of 18
(1,616 Views)