PID Level Control using USB 6008

[richie81]

Hi,

I am wondering does anyone know the best way to work out my P, I and D values for my level control project? Basically I am using a subvi called simplePID which I found on the NI website. I have two DAQ assistants in my program - one configured as an analog input (this input is from a cistern arm turning a pot which will determine the level of my test tank), and the other is configured as a digital output driving a pump. I havnt tried to use this program with my hardware yet due to my lack of understanding of PID and tuning the controller. I have read up a bit on manual tuning and the Ziegler-Nichols method, but I have been reluctant to try these without a bit of advise 1st. If this works will I need to incorporate pulse-width modulation to ensure more accuracy on reaching my setpoint (my pumps flow rate is 13L/Min but I have installed a manual valve to restrict the flow as necessary)? I have attached the vi below. Thanks for your time,

Rich

PID-RichLevelControl.vi

[ned]

I am wondering does anyone know the best way to work out my P, I and D values for my level control project? Basically I am using a subvi called simplePID which I found on the NI website. I have two DAQ assistants in my program - one configured as an analog input (this input is from a cistern arm turning a pot which will determine the level of my test tank), and the other is configured as a digital output driving a pump. I havnt tried to use this program with my hardware yet due to my lack of understanding of PID and tuning the controller. I have read up a bit on manual tuning and the Ziegler-Nichols method, but I have been reluctant to try these without a bit of advise 1st. If this works will I need to incorporate pulse-width modulation to ensure more accuracy on reaching my setpoint (my pumps flow rate is 13L/Min but I have installed a manual valve to restrict the flow as necessary)? I have attached the vi below. Thanks for your time,

Given your hardware, PID is the wrong control algorithm for you.

PID is designed to drive an analog signal, not a digital one. PWM lets you use a digital output as though it were an analog signal by switching the output rapidly with varying duty cycle. Your USB 6008 cannot do digital pulse generation so you would have to do PWM in software, at which point it makes more sense to write a control algorithm that switches the output directly. A simple approach is an On-Off controller with deadband. An example of such a controller is attached.

On-Off Controller.vi

[mross]

Given your hardware, PID is the wrong control algorithm for you.

PID is designed to drive an analog signal, not a digital one. PWM lets you use a digital output as though it were an analog signal by switching the output rapidly with varying duty cycle. Your USB 6008 cannot do digital pulse generation so you would have to do PWM in software, at which point it makes more sense to write a control algorithm that switches the output directly. A simple approach is an On-Off controller with deadband. An example of such a controller is attached.

Ned,

That first sentence is interesting to me. "PID is designed to drive an analog signal, not a digital one."

I will soon be wiring to control fluid temperature by varying two streams, one hot, the other cold. I definitely thought I would use PID, but you have me wondering - my control means is to send RPM commands via Modbus to VFDs in charge of pump motors. The plan is to use cRIO, FWIW. simplePID.vi was recommended to me as a starting point, I haven't gotten that far yet.

This is digital output not analog. Do you have any advise?

My goal is to be able to change from one steady state temperature to another as fast as possible - including an initial overshoot to cool or heat the plumbing quickly.

mike

[ShaunR]

PID is designed to drive an analog signal, not a digital one.

PID is designed to control a process to alleviate overshoot, ripple and offsets. It has little to do with the interface.

A simple approach is an On-Off controller with deadband. An example of such a controller is attached.

Indeed. First choice is always an on/off controller (they're cheap and easy). But the choice on this type of control depends on whether the process can tolerate overshoot and ripple rather than digital or analogue. Some processes that have significant lag or asymmetric properties cannot be controlled at all this way.

[ned]

Ned,

That first sentence is interesting to me. "PID is designed to drive an analog signal, not a digital one."

I will soon be wiring to control fluid temperature by varying two streams, one hot, the other cold. I definitely thought I would use PID, but you have me wondering - my control means is to send RPM commands via Modbus to VFDs in charge of pump motors. The plan is to use cRIO, FWIW. simplePID.vi was recommended to me as a starting point, I haven't gotten that far yet.

This is digital output not analog. Do you have any advise?

My goal is to be able to change from one steady state temperature to another as fast as possible - including an initial overshoot to cool or heat the plumbing quickly.

Perhaps a better phrasing would have been "PID is designed to drive a continuous signal, not a discrete one." If you can only turn your output on and off, and you can't use a PWM driver to do that more rapidly than your control loop runs, then the PID isn't helping. Are you sending a speed command over Modbus, or a command to turn the motor on or off? If it's a speed command - and I'm guessing it is, since you have a VFD - then you have a continuous output and PID is a reasonable choice.

[ShaunR]

Perhaps a better phrasing would have been "PID is designed to drive a continuous signal, not a discrete one."

Nope. Since you are still advocating that the type control interface is implicitly linked to the process.

Ovens and kilns, for example, use contractors, SSRs and normal relays, all of which are digital.

NI have an example of PWM PID control for their FPGA boards.PID Control Reference Example for LabVIEW FPGA

They also have a note on their PID autotune function from the PiD control toolkit which uses a relay PID Autotuning VI and Limitations (it uses Ziegler-Nichols apparently )

But I suppose I'd better answer the OPs original question

Choosing PID parameters is a bit of a black art. Manufacturers of PID controllers all have their own algorithms for determining the P, I and D terms (usually called "Autotune") and generally they will be biased to their particular industry and products.. One thing they all have in common though, is that they will analyse one or more step functions as you have seen with the Ziegler-Nichols. But it is worth bearing in mind that this "Autotune" is not a magic bullet. It is a "first best guess" and time will still need to be taken to optimise for the particular process.

So. If the manufacturers can't get it spot on for every process. Then I don't think we can expect to.

You've read up on Z-N (if its good enough for NI then its good enough to start with eh? ). and its probably time to bite the bullet and see what happens. Use your calculated values and log the tanks (level?) process variable. Start off by using a low setpoint so you don't overfill and inspect the log record to see how much overshoot, ripple and offset there was (you never know, it might be acceptable as is!). You've been wise enough to install a manual valve so if things go really askew you can just shut it off. If you didn't have any problems, Increase the P a large amount and start running for that valve:lol:

[ned]

Nope. Since you are still advocating that the type control interface is implicitly linked to the process.

Ovens and kilns, for example, use contractors, SSRs and normal relays, all of which are digital.

Right, but if they're hooked up to a PID loop, they're using a PWM driver to convert the PID's continuous signal (duty cycle) into the device's discrete output (on or off). PID is meaningless in a digital system; if you can't change the magnitude of your output based on the magnitude of the error, then there's no reason to use PID, and that's the situation the original poster is in. Did you look at the poster's code? He's trying to connect the PID output directly to a digital out, which isn't going to work. No amount of tuning will make much difference in the performance. If he were to add a PWM driver and connect it to an analog output instead, then PID will become a reasonable control scheme.

Edited September 2, 2010 by ned

[ShaunR]

Right, but if they're hooked up to a PID loop, they're using a PWM driver to convert the PID's continuous signal (duty cycle) into the device's discrete output (on or off). PID is meaningless in a digital system; if you can't change the magnitude of your output based on the magnitude of the error,

Ahhh. But you can.

Consider the lilly a tank that requires 10 litres to fill completely and all we have is a valve that only has 2 positions (open and closed i.e. digital control). Our hypothetical tank is (say) being drained at a rate of 1 litre per minute however, our valve, when fully opened, is capable of supplying 2 litres per minute. If we open that valve for 10 minutes then we will fill the tank to the brim and it all gets rather messy, what with the overspill and everything. However, if we open the valve for 30 seconds, we will supply the tank at the same rate as it is being emptied (on a minute by minute basis).

Now. the problem is, in all probability there will be times when there is nothing in the tank (due to timing differences, magic and the law of jam-butty) . So its desirable to open the valve for (say) 40 seconds so there is always more than is being consumed. Ultimately the tank will fill so as we approach the a pre-determined limit we want to switch back to 30 second "pulses".

We haven't changed the magnitude of the output (the valve can only be on or off). But what we have done is opened it for more or less time. We have "pulsed" the valve and by changing (or "modulating") how long we keep in open for ( "width" of the pulse), controlled the system and we can all go home .

For the above, PID control is simply a calculation (derived from the current level in the tank) that continuously calculates how long we leave the valve open for to achieve and maintain a desired steady state (a level in the tank).. What it gives us is a continuously varying duty PWM signal (which is varying at the sampling rate) , where the period is 1 minute and has a steady state at 50% duty cycle (30 seconds).

It doesn't really matter what interface we use to control the valve itself (analogue, digital, a hammer or telekinesis). Just as long as we can open and close it for an amount of time the PID algorithm tells us to.

[mross]

But the choice on this type of control depends on whether the process can tolerate overshoot and ripple rather than digital or analogue. Some processes that have significant lag or asymmetric properties cannot be controlled at all this way.

Shaun,

The fellow I work with is taking a controls class from the same prof I did 20 years ago (so I know he is worth listening to). He was reported to have made a provocative statement to the effect:

People are always trying to come up with some special algorithm for control, but after screwing around, and around, and around, they always find out the PID would do it better.

(my words again)

He believe meant that to cover even the asymmetrical case (that should be defined in more detail probably).

I suspect he is very good at ferreting out the P, the I , and the D. But that is a weighty statement. I will probably keep it in mind and not give up too soon.

Mike

[ShaunR]

Shaun,

The fellow I work with is taking a controls class from the same prof I did 20 years ago (so I know he is worth listening to). He was reported to have made a provocative statement to the effect:

People are always trying to come up with some special algorithm for control, but after screwing around, and around, and around, they always find out the PID would do it better.

Who? The Prof? Or your colleague?

(my words again)

He believe meant that to cover even the asymmetrical case (that should be defined in more detail probably).

What I meant was that there are certain processes that on/off controllers simply cannot control. They become unstable and oscillate.

As an example of an asymmetric system (just to clarify after all.....aren't they all?). I once had an environmental chamber that was convection heated but nitrogen cooled. So. To ramp up (say) 5 °C would take 15 mins at 100% output, but with a 2 second injection of liquid nitrogen the temp would drop by 5°C in about 10 seconds. Especially since some dork had designed the thing with the temperature probe near the injector.

I suspect he is very good at ferreting out the P, the I , and the D. But that is a weighty statement. I will probably keep it in mind and not give up too soon.

Mike

What you have to bear in mind is that PID isn't 1 algorithm. Its 3 algorithms cascaded. And you can choose which benefits from the 3 you want to include. You could (for example) use only the P and I terms or the P and D or just the P. Its the flexibility that makes it attractive since there is no "one size fits all" solution for every system.

If maths is your forte then I would suggest reading P, PI, PID Control.

If (like me) you only want the bullet points and prefer practical examples then try PID Tutorial is

[richie81]

Thanks everybody for all the help and advise:rolleyes:! I'm going to focus on trying to make my process work with one of two programs;

1 - My initial program with the on-off controller added in(cheers anon),

2 - An edited version of the FPGA PID PWM program(thanks for pointing that out Shaun).

I've run into a bit of a snag with wiring my DAQ assistant Ai/p and Do/p into the FPGA program... My analog input subbed in nicely into the PID loop, but in the PWM generation loop there are 2 terminals to wire into my digital output(direction bit & PWM output), where as I only have one digital output to generate on my DAQ assistant. Also, when I did try to wire up the DAQ assistant to one of the terminals it gives the error;

'2 terminals connected of different types. Type of source is boolean(T or F). Type of sink is 1-D array of boolean(T or F)'.

I understad that one is a scaler type and one is array type, but even by clearing the error I can't be sure that I'd wire it up correctly... Am I on the right track? I've attached the FPGA program. Thanks again guys,

Richie (Labview & PID rookie)!!

FPGA PID PWM Control.vi

[ShaunR]

Thanks everybody for all the help and advise:rolleyes:! I'm going to focus on trying to make my process work with one of two programs;

1 - My initial program with the on-off controller added in(cheers anon),

2 - An edited version of the FPGA PID PWM program(thanks for pointing that out Shaun).

I've run into a bit of a snag with wiring my DAQ assistant Ai/p and Do/p into the FPGA program... My analog input subbed in nicely into the PID loop, but in the PWM generation loop there are 2 terminals to wire into my digital output(direction bit & PWM output), where as I only have one digital output to generate on my DAQ assistant. Also, when I did try to wire up the DAQ assistant to one of the terminals it gives the error;

'2 terminals connected of different types. Type of source is boolean(T or F). Type of sink is 1-D array of boolean(T or F)'.

I understad that one is a scaler type and one is array type, but even by clearing the error I can't be sure that I'd wire it up correctly... Am I on the right track? I've attached the FPGA program. Thanks again guys,

Richie (Labview & PID rookie)!!

Unfortunately. You have the software, but not the hardware. You need FPGA hardware to run the FPGA stuff on. I only mentioned it to illustrate that NI also have a digital solution.

But all is not lost.

If you remember back to my example, I said we just need a way to open the valve for a period the PID algo tells us. This seems to be the bit you are having problems with.

For the digital output. You already Have an on/off controller example supplied by Ned. But what we really want is a PWM On/Off Controller then it would give us the opportunity to vary the on/off outside the dead-band. PWM always sounds complicated. It really isn't and to demonstrate I've modified Neds example.

The bottom half of the loop is Neds on/off controller. I've just modified it a bit so it isn't reliant on the previous iteration of the loop. It's functionally identical.

The top half is a timed gate which allows the signal from the on/off controller through for a specified period of time. So now we have an on off controller that we can vary the pulse width in the time domain. And that's PWM. Generally we wouldn't have it all in the same VI and the PWM would run asynchronously to the controller. But for our purposes its actually a bonus.

If we set the duty cycle to 100% (note I've used duty cycle and made it a percentage) then it will behave as Neds On/Off controller) then we have our on/off controller back again.

If only we could figure out a way to turn the error between the setpoint and the process value into a percentage......

It's unfortunate your hardware doesn't have a configurable counter/timer output otherwise you could have used that.

Edited September 4, 2010 by ShaunR

[ShaunR]

Oppps.

Just noticed a feature (bug..it is the wee hours is my excuse) The over set-point check is inverted (sorry about that).

This is what it should be

Edited September 5, 2010 by ShaunR

[richie81]

Hi Shaun,

Thanks a mil for all the help - I'd be lost without it:worshippy:! I've attached my vi with the PID & PWM subvi's added in. I'm sure that it'll be wrong somewhere but I'm going to try and tune the PID controller tomorrow and see can I get some sort of response... When it comes to the PID tuning, I spoke to my project supervisor from the college & he said that I would need to work out my values by the 'plant response' method...?

Leaving Ki & Kd at zero, he said to 1st get; Kc = % change in voltage shift of my output

% change in voltage shift of my input

He said that I then calculate the rise time of the slope Kr and the lag Kl. These values are then used in the ziegler nicolls formula to calculate my P, I & D... It sounds like an awfully complicated way of calculating the gains to me, but then again so does most associated with PID...! The 0-500 values on my front panel is just the range of response I got from my cistern arm(pot) from empty to full... Thanks again,

Richie

PID-RichLevelControl.vi

[ShaunR]

Hi Shaun,

Thanks a mil for all the help - I'd be lost without it:worshippy:! I've attached my vi with the PID & PWM subvi's added in. I'm sure that it'll be wrong somewhere but I'm going to try and tune the PID controller tomorrow and see can I get some sort of response... When it comes to the PID tuning, I spoke to my project supervisor from the college & he said that I would need to work out my values by the 'plant response' method...?

Leaving Ki & Kd at zero, he said to 1st get; Kc = % change in voltage shift of my output

% change in voltage shift of my input

He said that I then calculate the rise time of the slope Kr and the lag Kl. These values are then used in the ziegler nicolls formula to calculate my P, I & D... It sounds like an awfully complicated way of calculating the gains to me, but then again so does most associated with PID...! The 0-500 values on my front panel is just the range of response I got from my cistern arm(pot) from empty to full... Thanks again,

Richie

Hmmm.

I think maybe I have failed miserably to explain the key concepts.

The previous example was to show how you can add a very simple PWM (there is more than 1 type) to an on/off controller that controls a single digital output Cutting and pasting my example and wiring up controls with the same name won't cut it since you want to use a PID controller and not an on/off controller. I'm not doing your project for you, merely trying to show, with he use of examples, how to go about it. The example demonstrates how you can vary a digital output to react a a certain stimulus and since it was available, I used Neds on/off controller .

You could, for example, replace the PID VI in the NI example "PID simulator" with the vi I supplied, but you would still have to figure out a method of calculating the duty-cycle on each iteration in relation to the input (which you haven't). You could, however, replace it with Neds example (no mods needed) and see what the difference is to the PID one.

I would suggest taking the time to view all the PID examples shipped with the PID toolkit (assuming you have it) and understand the theory.

I would even be tempted to rip out the process simulator into another vi and use it to create the step response graph and log the results. Then do my ZN analysis on it to see if I came close to the ones in the example. Then change the process values and repeat.

From your project supervisors comment, I think he is expecting an analogue output (or a PWM simulation of an analogue voltage which isn't the type of PWM I used). Is the pump analogue controlled? If it is. What is the reason for using a digital output when your USB device has analogue outputs (And there are many tutorials on Youtube of PID with an analogue output. using LabView)

One further point. If your posting VIs that uses sub-vis. Can you put the all vis into a single directory and zip up the entire directory so that all the sub-vis are included. I don't have "On-Off Controller-PWM.vi" or "Simple PID- ViFormyproject.vi". I can guess at what they probably are but its always best to be looking at the same code.

[richie81]

Hi Shaun,

I'm sorry, my submission deadline is soon enough, so I've been a bit naive with this expecting everything to fall into place in a short space of time... That's not going happen...

My pump is just on-off, 12v dc. An analogue controlled pump would probably have been a sounder option, at least when working with labview. I realize that now...

I have the PID toolkit, so I'll have a look at the 'PID simulator' and the other examples like you said. I have attached the main program & sub vi's. I've also attached the basic program that I started off with(minus PID & PWM) & a manual PWM program that I was also trying to use... Thanks for all the help and I apologize if you thought that I'm trying to get you to do my project for me!! I'm just hoping to pass it when it comes down to the crunch...

Thanks again,

Rich

LavaG.zip

[ShaunR]

Hi Shaun,

I'm sorry, my submission deadline is soon enough, so I've been a bit naive with this expecting everything to fall into place in a short space of time... That's not going happen...

My pump is just on-off, 12v dc. An analogue controlled pump would probably have been a sounder option, at least when working with labview. I realize that now...

I have the PID toolkit, so I'll have a look at the 'PID simulator' and the other examples like you said. I have attached the main program & sub vi's. I've also attached the basic program that I started off with(minus PID & PWM) & a manual PWM program that I was also trying to use... Thanks for all the help and I apologize if you thought that I'm trying to get you to do my project for me!! I'm just hoping to pass it when it comes down to the crunch...

Thanks again,

Rich

Sorry for the delay. Had my own projects that weren't falling and needed kicking into place

No need to apologise. I was just trying to let you know that you need to understand what you are doing

OK. So you have a 12 digitally controlled motor. That's your design decision Nothing wrong with that, after all we need to keep within budget don't we?

I'm assuming you have seen the NI PID Examples and seen that they get a lovely smooth control curve. Right?. Just change the sampling time from 50m to, say 500 m.

Does it still look like a nice well controlled curve? What do you see? Remember we haven't changed any PID parameters, or the load we are controlling. Just how often we sample the PV.

What do you think is happening here?

[richie81]

Hi Shaun,

It was definitely financial reasons that I chose the 12v dc pump (I bought it on ebay for 20euro:P)! Otherwise I probably would have tried to get a 3 phase or something like that.

Anyways, as it turns out I'm finished - I had my project presentation Wedsnesday afternoon. It went very well - I got the PID & PWM working, thanks to the help of my project supervisor during the presentation (it was a pretty informal affair!). I wasn't far off, thanks to all the information from you and this site but it was just putting it all together in labview where I fell down. We ended up using a simulate signal block for the PWM. We installed this 1st into my basic program with just the input driving the output, and put a control on the duty cycle to set our pulses, and also set the samples per second, offset, frequency. We then managed to wire in the simple PID subvi, and it was just a matter of trial and error with the PID values. In the end, when a setpoint was entered it held very well going by the double needle meter, and the PID response was quite good. This could have probably been bettered but I was happy enough to get as far as I did with this. You probably think that I have a softie for a supervisor;) but I think he saw that I had all the pieces of the puzzle, just not in the right order!! Thanks again anyways Shaun - I have posted the working vi just in case you were intrigued how I got on. I'm sure it's pretty simple to you:worshippy:.

P.s - Taking a break from Labview for a while. My results are out Monday. That will be level 7 complete(pass degree or diploma), but I will probably be back to this site when I attempt level 8 of the course...

Take it easy,

Rich

RichProject2010-Basic Program.vi

simplepid.vi

[ShaunR]

Hi Shaun,

It was definitely financial reasons that I chose the 12v dc pump (I bought it on ebay for 20euro:P)! Otherwise I probably would have tried to get a 3 phase or something like that.

Anyways, as it turns out I'm finished - I had my project presentation Wedsnesday afternoon. It went very well - I got the PID & PWM working, thanks to the help of my project supervisor during the presentation (it was a pretty informal affair!). I wasn't far off, thanks to all the information from you and this site but it was just putting it all together in labview where I fell down. We ended up using a simulate signal block for the PWM. We installed this 1st into my basic program with just the input driving the output, and put a control on the duty cycle to set our pulses, and also set the samples per second, offset, frequency. We then managed to wire in the simple PID subvi, and it was just a matter of trial and error with the PID values. In the end, when a setpoint was entered it held very well going by the double needle meter, and the PID response was quite good. This could have probably been bettered but I was happy enough to get as far as I did with this. You probably think that I have a softie for a supervisor;) but I think he saw that I had all the pieces of the puzzle, just not in the right order!! Thanks again anyways Shaun - I have posted the working vi just in case you were intrigued how I got on. I'm sure it's pretty simple to you:worshippy:.

P.s - Taking a break from Labview for a while. My results are out Monday. That will be level 7 complete(pass degree or diploma), but I will probably be back to this site when I attempt level 8 of the course...

Take it easy,

Rich

Glad to hear it. Congrats. Always easier when someone is sitting in front of you (that knows the exam answers )

I noticed wired up the duty cycle to the simulator

[ned]

I realize the original poster's question has already been solved, but I still wanted to add a few comments.

The bottom half of the loop is Neds on/off controller. I've just modified it a bit so it isn't reliant on the previous iteration of the loop. It's functionally identical.

No, it's not functionally identical. Your version will shut off the output as soon as the process variable is in the range of the setpoint +/- the deadband. Mine keeps the output on until the process variable is greater than the setpoint + deadband, then turns the output off until the output is below the setpoint - deadband (a form of hysteresis).

Now. the problem is, in all probability there will be times when there is nothing in the tank (due to timing differences, magic and the law of jam-butty) . So its desirable to open the valve for (say) 40 seconds so there is always more than is being consumed. Ultimately the tank will fill so as we approach the a pre-determined limit we want to switch back to 30 second "pulses".

We haven't changed the magnitude of the output (the valve can only be on or off). But what we have done is opened it for more or less time. We have "pulsed" the valve and by changing (or "modulating") how long we keep in open for ( "width" of the pulse), controlled the system and we can all go home .

For the above, PID control is simply a calculation (derived from the current level in the tank) that continuously calculates how long we leave the valve open for to achieve and maintain a desired steady state (a level in the tank).. What it gives us is a continuously varying duty PWM signal (which is varying at the sampling rate) , where the period is 1 minute and has a steady state at 50% duty cycle (30 seconds).

Any control algorithm for this situation will necessarily vary the amount of time that the output is on. What I was trying to say is that PWM doesn't make much sense when the PWM and PID run at the same rate. Let's take your example with 1 minute periods and the PID calculates the number of seconds the output should be on. Say the loop runs once per second and it calculates that the output should be on for 30s. Now what? Do you turn on the output for 30s, turn it off for 30s, then run the PID again? That's going to slow your control response substantially. Or, you run the PID again one second later and it calculates the output should only be on for 10s. How long should the output be on? If the PID output is 0s on the iteration after that, do you turn off the output immediately? If not, then your control probably isn't going to be great. If so, then you should be using a simpler control algorithm that provides a boolean output instead of the analog signal provided by PID, as I was trying to explain.

[ShaunR]

No, it's not functionally identical. Your version will shut off the output as soon as the process variable is in the range of the setpoint +/- the deadband. Mine keeps the output on until the process variable is greater than the setpoint + deadband, then turns the output off until the output is below the setpoint - deadband (a form of hysteresis).

No (or is it yes?). You are correct. It's not functionally identical. But the OP was struggling with some very basic concepts and I didn't want to cloud the issue when his next step was to remove it anyway (he never got that far ). I also wanted to give some credit where credit was due.

Any control algorithm for this situation will necessarily vary the amount of time that the output is on.

Indeed. But an on/off controler doesn't do that in response to how near or far away from the setpoint we are. Its a bit like having On/Off brakes in your car. It doesn't make for a very smooth journey.

What I was trying to say is that PWM doesn't make much sense when the PWM and PID run at the same rate. Let's take your example with 1 minute periods and the PID calculates the number of seconds the output should be on. Say the loop runs once per second and it calculates that the output should be on for 30s. Now what? Do you turn on the output for 30s, turn it off for 30s, then run the PID again? That's going to slow your control response substantially. Or, you run the PID again one second later and it calculates the output should only be on for 10s. How long should the output be on? If the PID output is 0s on the iteration after that, do you turn off the output immediately? If not, then your control probably isn't going to be great. If so, then you should be using a simpler control algorithm that provides a boolean output instead of the analog signal provided by PID, as I was trying to explain.

An averaging PWM output (where we are trying to simulate a voltage level) typically runs at about 20-40 KHz. The lower the frequency the "choppier" the output. Why 20-40KHz? Because that is higher than the frequency response of most analogue inputs to give a stable reading (read DVMs which is about 20Hz-20 Khz) . And that is due to the input filtering of the analogue device . But we didn''t have the hardware to do that and we cannot run our loop fast enough (or accurately enough) to do it in software (without a real-time OS). But do we really need to? Well. for long lag systems no. A long lag system may have a frequency response anywhere between 0.1 or and 0.0001 HZ. That we can achieve in software. We can run our PWM at very low frequencies. And it works very well.

So the answer to your "then what?" is A. "you turn on the output for 30s, turn it off for 30s, then run the PID again". In the example you will only get reasonable control if the response of the system is more than 10 mins (preferably more). But it will be far superior to the an on/off controller.

Now the interesting part is that when you characterise a system to find the PID parameters. Because it is a closed loops system, Your control method becomes part of the system (regardless if its digital or analogue). So the PID algorithm is not only trying to predict the behaviour of the target system, but the target system AND the control. This is why I was taking you to task on your statement that PID is for analogue devices. It isn't. It's a predictive algorithm. Nothing more. We could use (and I have used) a bi-section algorithm just as easily.

Edited September 15, 2010 by ShaunR