Thermal Systems

I'm not sure whether I'm reading too much into this or even looking at it right, but maybe someone can help me out.
Say I've got a heater modeled as a collection of caps (heat
capacity) and resistors (thermal resistance) pumped up with a current (representing power), Iw. Temperature is represented by the output voltage, Vo. To fake the input power with a current,
Iw = Vin^2/R
... that doesn't work so well in a V(s)/V(s) transfer function.
I guess this can be linearized by treating small excursions of Vin from a given operating point.
It got me thinking.
I noticed this:
Call the transfer function
Vo G(s) = --- Iw
d Vo ----- = sG(s) d Iw
d P d Iw d ( Vin^2 ) 2 Vin --- = ---- = ---- | ----- | = ----- d Vin d Vin d Vin ( R ) R
d Vo d Iw d Vo 2 s G(s) Vin ----- ---- = ----- = ------------ d Iw d Vin d Vin R
Vo 2 G(s) Vin --- = ---------- Vin R
I think the Vin on the right side would be the operating point and the Vin on the left, the error voltage derived input to the heater.
In closed loop form by itself, that'd be
Vo 2 G(s) Vin --- = -------------- Vin R + 2 G(s) Vin
To better see what's up, say the thermal model was a simple capacitor, 1/sC. We'd have
2 Vin ------------ RCs + 2 Vin
So if the temp (Vo) is zero and the command is Vin degrees, Vin is the error and the pole is way out to the left and moves in as the error decreases.
Am I looking at this right, so far? Dead on, slightly sideways, or dead wrong?
Is it the pole moving in that keeps the system from reaching the command temp?
Since the pole is sometimes way out in left plane, I'd be tempted to put a pole (integrator) somewhere closer in. I've read that the integral part (and the P and D) of a PID is used in this system, but if the pole moving in is what keeps the system from reaching the set point, that would be wrong. The proportional part that's most responsible for getting it there, right?
So what is the significance of this moving pole and is it the reason for using the I in PID, i.e., a purposely placed pole?
TIA
--
Best Regards,
Mike

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Active8 wrote:

Correct.
Incorrect. Laplace(d/dt Vo) / Laplace(Iw) = sG(s). dVo/dIw is something else entirely -- I'm not sure what it _is_, but sG(s) is one thing it _isn't_.

Correct.
Incorrect. More like Vo/Vin = (Vo/Iw)(Iw/Vin) = (2 Vin_s)/R, where Vin_s is the "standing" input voltage.
-- snipity snip --

Dead wrong.
Furthermore if you're commanding Vin when you want power input it's pretty easy to calculate P and command Vin = sqrt(P * R), assuming that you know R and don't mind doing a square root of some sort. Even just commanding the voltage and making sure you have plenty of gain margin isn't a bad way to go.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Thu, 27 Jan 2005 22:35:33 -0800, Tim Wescott wrote:

Oops! Time domain, not Iw domain --> freq domain.

I think you mean (Vo/Iw)(Iw/Vin) = G(s)(Iw/Vin) = G(s) (2 Vin_s)/R. ^^^ ^^
My answer had the s from the errant d/dt.
Thanks, Tim. That expresses the linearization I mentioned. Now even without my errant s in the transfer... Crap! I just noticed in the OP that I accidentally dropped it and rewrote it as
Vo 2 G(s) Vin --- = ---------- Vin R
which is right except for the missing subscript . And then the 1/sC I threw in for G[rin](s) makes that pole that moves which is just like a root locus thingy because that squaring of Vin is like increasing gain as Vin_s increases.

That moving pole interests me. It's in a different spot for each Vin_s.

Dead time for Mike?

I meant to hit on that sqrt'er approach. That was the first thing to come to mind. But it demands the prior calculation of P which is only a problem if I want to look at this system in the s domain.
I should explain my motive. Boredom? I'm pretending that I didn't read your stuff about PID controllers and want to compensate the system by looking at the s domain and adding poles and zeros and gain. Maybe do it with toobz ;) Preheaters :) I'd like to get a better feel for how pole/zero placement affects performance.
Can't use ^2 or sqrt in the freq domain where I've got
G(s) = Vo/Iw = Vo/(Vin^2/R) ... can't say Vo = G(s)Vin.
If I could undo the ^2 - like turning a PLL into a FLL by removing the integrator... but I can't figger' that working with a non-linear function.
--
Best Regards,
Mike

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Active8 wrote:

Drat.
_Except_ that putting Vin in two places like that doesn't make sense. The Vin_s is used specifically because it _is_ different from Vin and makes a linear relation that you can transform. Sticking a Vin^2 term into the Laplace transform integral is going to give you something you can't evaluate. Moreover, if you ignore things like thermal resistance and heat capacity changing with temperature most thermal systems have fairly linear responses to power input i.e. their poles _don't_ move around, even if the power input vs. voltage input is quite nonlinear.

But it doesn't move in my formulation -- G(s) stays the same, the system is only modified by a gain that's dependent on Vin_s, which you've chosen at design time (or argument time, in my case)

Eew.
No problem at all. Build your system block diagram with power as the input and temperature as the output. Later on when you go to realize the system you'll have to contend with an "actuator" that delivers a power that's proportional to your command signal, but that's for later.

When you use my design technique for a PID controller the result will either be good enough in which case you'll be happy, or it won't, in which case I'd advise you to use more sophisticated methods like Bode plot or Nichols chart or Nyquist plot, or learn even more theory and do robust controller design.

Poles to the left -- performance gets faster. Pole pairs with high imaginary/real ratio -- ringing gets worse. That sort of information can be found in any good controls book.

The idea is to mask the nonlinearity, or ignore it. As long as your power command never goes below zero Vin = sqrt(P * R) can be used as the first block in the actuator that I mentioned above and _totally ignored_ for the purposes of the frequency-domain design. Alternately you figure out ahead of time that your operational Vin will hover around some value. You call that value Vin_s, you do your linearized design with extra robustness to gain variations, and you call it good.
Doing the linearization is a good way to go, particularly if you're using a tube-based controller and would have to spend a whole bunch of chassis space on a square-root function.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Tim Wescott wrote:

Don't overlook funny things that can happen because of the time it takes for heat to get from here to there. That might need to be modeled as a delay line, possibly series Ls and shunt Cs.
Jerry
--
Engineering is the art of making what you want from things you can get.

  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Fri, 28 Jan 2005 20:39:56 -0500, Jerry Avins wrote:

I've benn using a single cap to avoid confusing the math for purposes of this discussion, but I started with:
P (or Iw) ----> Rho = Vin^2/R Vh ___ Vo ( or T) ----------+---|___|---+---------+ | | | | | | --- --- .-. --- Ch --- Co | |Ro | | | | | | '-' | | | | | | ----------+-----------+---------+
Something I found later... buried.
http://tinyurl.com/5ee22
That looks like a better way of arriving at the xfer function.
--
Best Regards,
Mike

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Active8 wrote:

That's still way simplified. A real thermal system will most likely contain some pure delays, or some other continuous-state effect, that will make it impossible to model with a ratio of polynomials in the Laplace domain -- fortunately you can still do it with Bode plots.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Fri, 28 Jan 2005 22:00:50 -0800, Tim Wescott wrote:

Pure delays like the thermocouple? What else? This is interesting.
-- fortunately you can still do it with Bode plots.
Seriously low freq sweep? I wonder how long that would take.
I did manage to simulate that thing above and arrive at the temp ramp I measured - after the thing got pretty hot. It's still crude, but I think it's close enough for some purposes, and too much for others.
--
Best Regards,
Mike

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Active8 wrote:

-- snip --

Any time you have a heater over _here_ and a sensor over _there_ you will have some pure delay. I'm no thermodynamicist but it'll act somewhat like a lossy transmission line.

A long time. You could also excite it with a step or random input and build up a transfer function.

Look for Ziegler-Nichols, or Astrom-somebody. They have methods that let you take the step response of a system, characterize it, and directly design a controller. The controllers don't guarantee a stable system, and often the closed-loop systems are fairly under damped, but they're also often good enough.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Fri, 28 Jan 2005 13:08:18 -0800, Tim Wescott wrote:

<snip>
But if Vin_s is PWM of 120 V... DC from 0 to 100%
What I meant is that (add missing subscript)

ends up in closed loop as
2 Vin_s ------------ RCs + 2 Vin_s ^^^^^ that's misleading. The heater resistance is mimicking part of the heater time constant.
I don't know what to say about that fake time constant at this point. R is about 9.6 ohms (120 VAC 1500 W) and C is big so that would keep the pole between -1 and 0. Not a big deal?
Like you said below:

I'm thinking set points from 100 C to 300 C where 120 Vin gives a slope of around 5 C per second or so, depending on losses. Yeah, I drilled into an old toaster/broiler/ovenator to get an idea of the thermal constants involved. I'd think a pole moving in would matter, but maybe this system is a bad example. Maybe I should use a magnetron for one of those toobz ;)
<snip>

Like so?
P (or Iw) ----> Rho = Vin^2/R Vh ___ Vo ( or T) ----------+---|___|---+---------+ | | | | | | --- --- .-. --- Ch --- Co | |Ro | | | | | | '-' | | | | | | ----------+-----------+---------+
.------------. P + .-. Perr | | Vin --------( )--------|sqrt(Perr*R)|----> heater '-' | | | - '------------' | | Vo' C or Vo/Ro
where Vo is really delta To
The thermal/electrical analogy is screwing with me here.
The transfer function for the heater should account for losses, right? IOW, I command the P that causes Vo across Ro and the xfer function adjusts for the actual Pin required to the heater?
So P gets calculated and temp is sampled and weighted by C for the error calc.
Kpwm G(s) ------------- 1 + Kpwm G(s)
For the simple one cap heater:
2 Kpwm Vin_s -------------------- RCs + 2 Kpwm Vin_s
Of course, I'd need to put H(s) feedback in.
--
Best Regards,
Mike

> The idea is to mask the nonlinearity, or ignore it. As long as
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Active8 wrote:

Since when has PWM crept into the discussion?
Actually if you're driving it with a PWM into a resistor then you don't have the whole V^2 mess to deal with -- the resistor always comes up to full current, the instantaneous power is either 0 or (120V)^2/R, and the average power is r_pwm * (120V)^2/R.

That certainly is misleading. You cannot put it into closed loop without having a transfer function for the controller -- what's your controller, and where's the rest of G(s)?

I have something pithy to say, but this is a family newsgroup. Actually in closed loop it's a real time constant, but you're not playing the math right to close the loop.

Yes.
I generally stay away from the analogies -- with control systems you either understand the math or you don't.

Losses? The whole damn thing is losses! It's a thermal system! The _controller_ should account for environmental and other effects in the thermal system and adjust the commanded power to whatever's correct for the heater.

--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Fri, 28 Jan 2005 22:09:21 -0800, Tim Wescott wrote:

It could be varied with a rheostat. The point was that Vin_s is set to linearize a range of Vin action. If I'm not planning on using different Vin_s settings, I wouldn't think I can vary Vin from 0 to 120, though you did suggest one operating point and ... here it is <quote> Alternately you figure out ahead of time that your operational Vin will hover around some value. You call that value Vin_s, you do your linearized design with extra robustness to gain variations, and you call it good. </quote>
Maybe it will.

Ok, Maybe I shouldn't look at that. With and without the controller, the denominator of the plant shows up on the bottom and I've been looking at it. Like I said, I thought I might get a feel for pole zero placement.

I found an error in my nodal analysis, but now I have
Ro Iw = [Rho Ch Ro Co s^2 + (Rho Ch + Ro Ch + Ro Co)s + 1] Vo ^^
That link I posted has the same C.E., but I stopped after the above step to try that method and my answer is missing the "Ro" that I pointed to above.
I think that for a Type I system, the controller should be an integrator and some gain.
<snip>

I mean the power which does not show up as a temp rise over Ro. The heat capacity of the element, Ch, consumes energy, etc. But it's in the plant xfer function, so the plant input gets what it needs.
--
Best Regards,
Mike

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.