Something like the code you wrote could work as a "pseudo" rate limiter
if (output-prev_output)>output_rate_limit{
output=prev_output+output_rate_limit;}

However, not sure what "driver_flood_run" is. And i still don't really know what the error is. Still my opinion is that PID is wrong in this case.
/*Define the error
Error = Setpoint_Temp - corrected_temp;
What is this? Is the setpoint 85 celsius? Is corrected_temp the measured temperature?

Anyway, i think for a first order filter with step input, the maximum derivative is something like, input/Tr, which gives a Tr=300second to keep below 0.33%/second. This is way to slow.

2 pictures from simulation to show the problem with a low rate limit and a high Tr output filter.

With the rate limiter the temp goes all the way to 91C, even though the upper limit was 85C in the controller, as i suspected in my previous post.

And again, if the absolute temperature limit is 85C, then the lamp must be turned down one way or another when that temp is reached. Turning it down too slow will allow the temperature to rise boyond 85C.

 

Respecting the complexity that a design may call for implementing PID ; never understood the habit of pushing LEDs to their maximum design limits risking their thermal/current survival.

Want more light ? Use two/multiple LEDs at half their rated power and forget complications, will last forever and reliably cool.

Hi, thanks for your comment. Actually, in this case, it is not about the LEDs getting hot but the complete system. I agree with you but, as you said, it all depends on the complexity of the design.

 

Something like the code you wrote could work as a "pseudo" rate limiter
if (output-prev_output)>output_rate_limit{
output=prev_output+output_rate_limit;}

However, not sure what "driver_flood_run" is. And i still don't really know what the error is. Still my opinion is that PID is wrong in this case.
/*Define the error
Error = Setpoint_Temp - corrected_temp;
What is this? Is the setpoint 85 celsius? Is corrected_temp the measured temperature?

Anyway, i think for a first order filter with step input, the maximum derivative is something like, input/Tr, which gives a Tr=300second to keep below 0.33%/second. This is way to slow.

2 pictures from simulation to show the problem with a low rate limit and a high Tr output filter.
View attachment 150329 View attachment 150330
With the rate limiter the temp goes all the way to 91C, even though the upper limit was 85C in the controller, as i suspected in my previous post.

And again, if the absolute temperature limit is 85C, then the lamp must be turned down one way or another when that temp is reached. Turning it down too slow will allow the temperature to rise boyond 85C.

Hi again, thanks a lot for your simulations. I am not sure whether we need a PID or not. Nevertheless the results we would get according your simulations with a simple IF-test are not acceptable for our system. If the user set 100% the lamp MUST start at 100% and dim progressively to the power level that keep the temperature under the limit. So the control needs to predict that at the rate the lamp is getting hot it will pass the temperature limit and then start to dim the LEDs. And, I am guessing, only a well tuned and restricted PID will achieve it. I will post the test results next week after I optimize the code and can do the tests with the lamp.

 

The thermal time constant of the LED/Heat Sink assembly will be on the order of minutes.
The simplest scheme will be stable, you would have to work hard to get it to oscillate.
I think you are making this thing Wayyyyyyyy tooooo complicated!

If I told my boss I was using PID to protect an LED from overheating- he would fire me on the spot.

 

I have reviewed again your model and I think the reason why the lamp power is rising from 0 to 100 is that it is limited by the 'rate limiter', isn't it? If that is the case, can you plot the results after modify this?

 

The thermal time constant of the LED/Heat Sink assembly will be on the order of minutes.
The simplest scheme will be stable, you would have to work hard to get it to oscillate.
I think you are making this thing Wayyyyyyyy tooooo complicated!

If I told my boss I was using PID to protect an LED from overheating- he would fire me on the spot.

I will give a try to your proposal...

 

My point with the 2 last pictures was to show that your rate limit requirement/idea will cause overshoot (and undershoot) in the temperature. So the system HAS to decrease the power "fast" to meet the requirements.
I quote you: "If the user set 100% the lamp MUST start at 100% and dim progressively to the power level that keep the temperature under the limit." This is the exact function of my original design. New picture with single 100% step input.

Regarding the quote "So the control needs to predict that at the rate the lamp is getting hot it will pass the temperature limit and then start to dim the LEDs". This is kinda what happens when the temperature is between the 2 limits i declared. It gradually dims the LED because the temperature is getting close to the max temp, 85C, as seen in the new picture.

 

My point with the 2 last pictures was to show that your rate limit requirement/idea will cause overshoot (and undershoot) in the temperature. So the system HAS to decrease the power "fast" to meet the requirements.
I quote you: "If the user set 100% the lamp MUST start at 100% and dim progressively to the power level that keep the temperature under the limit." This is the exact function of my original design. New picture with single 100% step input. View attachment 150337

Regarding the quote "So the control needs to predict that at the rate the lamp is getting hot it will pass the temperature limit and then start to dim the LEDs". This is kinda what happens when the temperature is between the 2 limits i declared. It gradually dims the LED because the temperature is getting close to the max temp, 85C, as seen in the new picture.

Yes, I agree that with the slow rate will be hard to avoid the overshoot. Looking at your new pictures it looks like it could work. Could you please plot it again but with a slow system and rate change limit, maybe not slow, let's try 0.5%/s)? And do you have an idea how could we include the temperature rate change in a simple way, maybe with another if-test? Thanks a lot for your help.

 

As shown earlier, when you put a rate limiter (or filter), you will not meet the requirement regarding the step input, "If the user set 100% the lamp MUST start at 100%". But new picture also shows this.

Even if i make a unsymmetrical rate limiter to only limit negative rates, we still get overshoot.

So i guess you need to decide if you really need to limit the rate change of power to the LED. I have shown the problem with slow filters and low rate limits, but also shown a complete system which meets the other requirements (my first reply and reply #27). I post the picture again here.

 

Although I've stayed away from this thread. I may or may not have something to contribute. Back in the 80's I did an embedded PID with a colleague, but the computer and disk drive was huge. The program took two of us 9 months to write, It had a 7 loop PID, recipies and logging.
Spreadsheets were not invented yet, but data almost could have made it into CSV values.

We did a lot of neat stuff with PID and some of the cool stuff I did had to do with making Fortran routines that looked like a device driver.

In nay event we effectively did voltage, current, power and temperature control at the same time. Reality, you had one as a setpoint and the others became limits. I can't remember if temperature was an "all stop" deal. Also with that information we determined "stability" criteria. Open and shorted heaters were also detected, It also allowed us to computer "heat-up energy" and apply a limit there. A displaced thermocouple was a real possibility.

It was for resistance heating (Tantalum Heaters). You can continually compute R and effectively pick, V (the controlled variable) to be to stay within the various limits.

You have a non-linear element for power which makes it harder. I'm not sure if you can model it. What comes to mind is keep Pout (0-100%) and V^2 which is proportional to power to help guess the next point, if in fact your operating near the max power point.

 

Although I've stayed away from this thread. I may or may not have something to contribute. Back in the 80's I did an embedded PID with a colleague, but the computer and disk drive was huge. The program took two of us 9 months to write, It had a 7 loop PID, recipies and logging.
Spreadsheets were not invented yet, but data almost could have made it into CSV values.

We did a lot of neat stuff with PID and some of the cool stuff I did had to do with making Fortran routines that looked like a device driver.

In nay event we effectively did voltage, current, power and temperature control at the same time. Reality, you had one as a setpoint and the others became limits. I can't remember if temperature was an "all stop" deal. Also with that information we determined "stability" criteria. Open and shorted heaters were also detected, It also allowed us to computer "heat-up energy" and apply a limit there. A displaced thermocouple was a real possibility.

It was for resistance heating (Tantalum Heaters). You can continually compute R and effectively pick, V (the controlled variable) to be to stay within the various limits.

You have a non-linear element for power which makes it harder. I'm not sure if you can model it. What comes to mind is keep Pout (0-100%) and V^2 which is proportional to power to help guess the next point, if in fact your operating near the max power point.

Hello. This is a bit off topic, but what you are describing sounds very interesting! I knew i had simulated something similar before, and i spent some hours looking for it, and i found it. Do you have some more information about this 7-loop project?

Just to clarify, it would be similar to this structure? Where each loop has some gains, and sets the limits for the next loop with a saturation block or similar?

 

We had 7 independednt loops. the processor was a PDP-11 running RT-11, a real time OS and had 128K (16bit) of memory to work with, RT-11 has a Foreground/background monitor where the Foreground is REAL TIME.
There was lots of overlays, Meaning memory was limited, so the disk drive had to be a temporary storage. The entire program would not fit into memory at the same time, This was managed by the user.

There were a couple of "devices" like a thickness monitor, vacuum guage and a shutter as well as heaters.
The code nearly all on FORTRAN, was structured as a "device driver". Every driver had the same entry points.
e.g. print a line on the terminal, config, get config values from file, write config values to file. I found a way where the init routine would read the config file, determine who should get the line, back up the read pointer and pass it to the driver. The driver would then keep reading lines until it got something that wasn't theirs, back up the read pointer and return to be dispatched again.

The config file for the heaters contained things like a "nominal value" e.g, 0-5, a calibration and a full scale.
So, you might have 40, 5, 1 for 40 V FS 0-5 V * 1; So, you could have 40, 5 and 0.900; There were 1% resistor dividers and they could be calibrated out easily.

We created recipies using "indirect files" like @start.cfg. That file might look like. @setup.cfg as the first line.
Command like "send" and "set" e.g. send shutter open; set heater 1 mode power. Set heater 1 setpoint 300; set heater 1 voltage limit 20

We has to edit text files to make recipies. Then later, someone else wrote a Fortran program that would create the recipie files.

This was research and not production. The heaters were actually evaporation sources and a substrate heater.
They typically had a top (nozzle) and a bottom (bottle) Heater and one thermocouple either in the top or the bottom.

It became possible later, to use a ramp controller, but without all of the bells and whistles.

This was the 1980's. No microcontrollers or IBM PC.