On 2020-01-09 10:38, Phil Hobbs wrote:
> On 2009-11-06 00:55, Tim Wescott wrote:
>> On Thu, 05 Nov 2009 18:37:21 +0100, Frank W. wrote:
>>
>>> Is there a control engineering expert here?
>>>
>>> I could us a bit of help on how to implement a PID autotune function for
>>> a heating application (a small boiler).
>>>
>>> My current PID autotune function produces no reliable results. I use the
>>> relay feedback method (&Aring;strom and H&auml;gglund) but it seems that the
>>> ultimate period Tu - one of the paramters determined with the relay
>>> feedback test - is directly correlated to the relay output step u. u is
>>> an arbitrary value which makes Tu an arbitary value. Since Tu is
>>> required to compute Ti and Td (e.g. Ti = 0.5 Tu = Ziegler-Nichols),
>>> autotune is not possible.
>>
>> Are you sure you haven't just stopped too soon in turning the output step
>> down?&nbsp; I see where you're having trouble with this; is there some reason
>> you can't turn u down even further?&nbsp; Things may start looking better when
>> you get it down to where the temperature curve is roughly symmetrical
>> around the average.
>>
>>> I believe this is because the machine heats very quickly (1500W boiler)
>>> and cools down very slowly, so the process value isn't a sinusoid. Here
>>> is an example graphics, green line is setpoint, red plot is process
>>> value and the grey vertical bars represent heat output u:
>>>
>>> http://img196.imageshack.us/img196/7409/examplejr.jpg
>>>
>>> Regardless of u, the temperature always dips the same, small amount
>>> below setpoint - because the machine cools slowly, the temperature can
>>> not fall far below setpoint before it's reacting to the heat. It then
>>> shoots up by an amount that is proportional to u. As a result, the plot
>>> resembles mountains above setpoint. If u is large, temperature will
>>> shoot high above the setpoint and take very long to cool down. Big
>>> mountains, so Tu gets large, Tu ~ u = my problem.
>>>
>>> Since all PID temperature controllers have Autotune, there must be a
>>> solution for this problem. Any ideas?
>>
>> Why do you want to use autotune?&nbsp; If this is a product that you're
>> working on, and if the boiler design is the same for all of the parts
>> that you ship, then you should just need one tuning.
>>
>> Autotune is for when you're selling a shrink-wrapped controller that has
>> to work for anything -- and autotune is often considered to be a good way
>> to get the tuning in the ballpark so that a human can get involved and
>> actually make it work right.
>>
>> Unless you need to adapt to a variety of different, unexpected boiler
>> combinations -- that don't change as the boiler is operating -- then
>> there's not much value in autotune, IMHO.
>>
> 
> For simple temperature control applications such as using small TE 
> coolers to stabilize diode lasers and optical detectors, we use a very 
> simple autotuning algorithm that works really well.
> 
> We hit the plant with a step function, and fit the T(t) curve to a plant 
> model consisting of a time delay tau followed by an integrator.&nbsp; That 
> has a simple transform proportional to exp(-j omega tau)/(j omega), so 
> we compute P and I to get about a 65-degree phase margin, and wind up 
> with a nice-looking transient response and decent bandwidth.&nbsp; This is 
> done at test time using BIST functions in firmware.
> 
> The main thing that improves the BW is to put an 0603 thermistor on the 
> bottom of the cold plate circuit board, right next to the TEC and 
> connected to the top plate of the TEC by a ground pour.&nbsp; That gets the 
> response down into 100-ms territory.&nbsp; (It's hard to measure at that 
> rate, because it's faster than the TEC itself.)
> 
> As I say, that's a much simpler plant than a domestic heating system, 
> but it works great.
> 
> Cheers
> 
> Phil Hobbs
> 

Doh, just noticed the time stamp.  Weirdly this thread came up as unread 
in Thunderbird this morning.

Cheers

Phil Hobbs

-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

On 2009-11-06 00:55, Tim Wescott wrote:
> On Thu, 05 Nov 2009 18:37:21 +0100, Frank W. wrote:
> 
>> Is there a control engineering expert here?
>>
>> I could us a bit of help on how to implement a PID autotune function for
>> a heating application (a small boiler).
>>
>> My current PID autotune function produces no reliable results. I use the
>> relay feedback method (&Aring;strom and H&auml;gglund) but it seems that the
>> ultimate period Tu - one of the paramters determined with the relay
>> feedback test - is directly correlated to the relay output step u. u is
>> an arbitrary value which makes Tu an arbitary value. Since Tu is
>> required to compute Ti and Td (e.g. Ti = 0.5 Tu = Ziegler-Nichols),
>> autotune is not possible.
> 
> Are you sure you haven't just stopped too soon in turning the output step
> down?  I see where you're having trouble with this; is there some reason
> you can't turn u down even further?  Things may start looking better when
> you get it down to where the temperature curve is roughly symmetrical
> around the average.
> 
>> I believe this is because the machine heats very quickly (1500W boiler)
>> and cools down very slowly, so the process value isn't a sinusoid. Here
>> is an example graphics, green line is setpoint, red plot is process
>> value and the grey vertical bars represent heat output u:
>>
>> http://img196.imageshack.us/img196/7409/examplejr.jpg
>>
>> Regardless of u, the temperature always dips the same, small amount
>> below setpoint - because the machine cools slowly, the temperature can
>> not fall far below setpoint before it's reacting to the heat. It then
>> shoots up by an amount that is proportional to u. As a result, the plot
>> resembles mountains above setpoint. If u is large, temperature will
>> shoot high above the setpoint and take very long to cool down. Big
>> mountains, so Tu gets large, Tu ~ u = my problem.
>>
>> Since all PID temperature controllers have Autotune, there must be a
>> solution for this problem. Any ideas?
> 
> Why do you want to use autotune?  If this is a product that you're
> working on, and if the boiler design is the same for all of the parts
> that you ship, then you should just need one tuning.
> 
> Autotune is for when you're selling a shrink-wrapped controller that has
> to work for anything -- and autotune is often considered to be a good way
> to get the tuning in the ballpark so that a human can get involved and
> actually make it work right.
> 
> Unless you need to adapt to a variety of different, unexpected boiler
> combinations -- that don't change as the boiler is operating -- then
> there's not much value in autotune, IMHO.
> 

For simple temperature control applications such as using small TE 
coolers to stabilize diode lasers and optical detectors, we use a very 
simple autotuning algorithm that works really well.

We hit the plant with a step function, and fit the T(t) curve to a plant 
model consisting of a time delay tau followed by an integrator.  That 
has a simple transform proportional to exp(-j omega tau)/(j omega), so 
we compute P and I to get about a 65-degree phase margin, and wind up 
with a nice-looking transient response and decent bandwidth.  This is 
done at test time using BIST functions in firmware.

The main thing that improves the BW is to put an 0603 thermistor on the 
bottom of the cold plate circuit board, right next to the TEC and 
connected to the top plate of the TEC by a ground pour.  That gets the 
response down into 100-ms territory.  (It's hard to measure at that 
rate, because it's faster than the TEC itself.)

As I say, that's a much simpler plant than a domestic heating system, 
but it works great.

Cheers

Phil Hobbs

-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

clip....
> They are all independent but the results at the temperature sensors
> will be from the sum of the 3 heaters. =A0This should hold true unless
> there is something that I don't know where superimposition doesn't
> apply. =A0The states for a system of SOPDT equations would simply have
> the temperature and the temperature rate at each of the 3 temperature
> sensors. =A0I don't see how the temperature at one sensor will affect
> another temperature since the temperature sensors are not heat
> sources.
>
> Peter Nachtwey

Your right; and I see how the dependent/independent has to be handled
for state-space representation.  A state space reduction to a non-
singular matrix is required to make A nonsingular in the ABCD
representation.

> > t1'=3DA1*t1+B11*u1(t-dt11)+B12*u2(t-dt12)+B13*u3(t-dt13)+C
> > t2'=3DA2*t2+B21*u1(t-dt21)+B22*u2(t-dt22)+B23*u3(t-dt23)+C
> > t3'=3DA3*t3+B31*u1(t-dt31)+B32*u2(t-dt32)+B33*u3(t-dt33)+C

As a note:
In more complicated systems you need additional terms on the left.
m1*t1''' + n1*t1'' + p1*t1'
m2*t2''' + n2*t2'' + p2*t2'

Ray

On Nov 15, 1:47=A0pm, RRogers <rerog...@plaidheron.com> wrote:
> On Nov 15, 8:12=A0am, pnachtwey <pnacht...@gmail.com> wrote:
>
>
>
>
>
> > On Nov 14, 7:44=A0am, RRogers <rerog...@plaidheron.com> wrote:> I don't=
 quite understand your approach; it seems different from what I
> > > had in mind. =A0I have multiple sets of experimental data consisting =
of
> > > three stimulus/drive columns and three columns of resulting temeratur=
e
> > > data; together with a multitude of other columns of other temperature
> > > readings for thermal design of the overall assembly.
> > > =A0 =A0 =A0My hypothetical approach =A0to raw curve fitting type of m=
odeling:
> > > Write out the ABCD equations with unknown coefficients and try to fin=
d
> > > the coefficients; which are linear (superficially) coefficients
> > > applied to the data. =A0Having an adequate model in hand, then I thou=
ght
> > > I =A0would use optim() to find the control gains in the closed loop.
> > > This is not what you are describing. =A0My formulation was just a
> > > passing thought and certainly has a lot of problems I haven't
> > > resolved.
> > > Your comments don't fall in line with this, so why not tell me yours.
>
> > Why not use the principle of superimposition. =A0 Test each heater with
> > respect to each sensor
> > and then find the FOPDT or SOPDT coefficients that work
> > For the first temperature sensor you have a FOPDT formula that looks
> > like
> > t1'=3DA1*t1+B11*u1(t-dt11)+B12*u2(t-dt12)+B13*u3(t-dt13)+C
> > Where:
> > t1 is the temperature a sensor 1
> > A1 =A0is the system time constant at temperature sensor 1. =A0This is
> > basically exp(-t/tau1).
> > B11 is the input coupling of heater 1 to sensor 1.
> > B12 is the input coupling of heater 2 to sensor 1.
> > B13 is the input coupling of heater 3 to sensor 1.
> > u1(t-dt11) is the heater 1 signal for time t.
> > dt11 is the dead time from heater 1 to sensor 1.
> > C is the ambient temperature. =A0It had better be the same for all
> > test unless the ambient temperature is really changing.
> > It is easy to ID B11 B12 and B13 if they are turned on 1 at
> > a time but the starting point should be ambient temperature or
> > some steady state. When done you would have this
> > t1'=3DA1*t1+B11*u1(t-dt11)+B12*u2(t-dt12)+B13*u3(t-dt13)+C
> > t2'=3DA2*t2+B21*u1(t-dt21)+B22*u2(t-dt22)+B23*u3(t-dt23)+C
> > t3'=3DA3*t3+B31*u1(t-dt31)+B32*u2(t-dt32)+B33*u3(t-dt33)+C
>
> > All the coefficient could probably be ID at once but then it would
> > be much harder to get exact values. It is best to do small sections
> > at a time and rely on superimposition.
>
> > The way I ID a system is like thishttp://www.deltamotion.com/peter/PDF/=
Mathcad%20-%20Sysid%20SOPDT.pdf
>
> > 1. On page 1/10 I define the ideal SOPDT system. =A0I chose different
> > value to to see how the well the system identification works under
> > different conditions Notice that there is dead time and I don't assume
> > all the poles are at the same location like others on this newsgroup.
> > 2. At the bottom of page 2/10 I generate the test data that is later
> > to be used for system identification. =A0I add noise the to ideal data
> > just to simulate reality a bit. =A0The CO(t) function is a few steps.
> > The function can be arbitrary but I have found that the excitation is
> > critical to the identification. =A0 Dead times and time constants are
> > determined more accurately if the are step or rapid changes. =A0The gai=
n
> > and ambient coefficients are determined more accurate if the are steps
> > at different levels.
> > 3. One page 3/10 I plot and save the generated test data. =A0I can post
> > it on my FTP site for you to practice with. =A0Notice that this data ha=
s
> > dead time and two poles that aren't at the same location. =A0I could
> > have added more noise but the quasi-Newton method seems to filter it
> > out well.
> > 4. One page 4/10 the system identification is done. =A0Mathcad's Minerr
> > function can be like either Scilab's optim() function or lsqrsolve
> > function depending on the option chosen. =A0I chose the quasi-Newton
> > optimization which is similar to the optim() function. =A0Runge-Kutta i=
s
> > used to integrate the differential equation. The differential equation
> > doesn't need to be linear. =A0I could easily put a none linear term in
> > there like one that changes the gain as a function of temperature.
> > This happens with heat exchangers because of the LMTD. =A0Fluid systems
> > are often of the form
> > v'=3Dg/m-K*v^2. =A0It is easy to ID non linear system IF you know the
> > general form of the equation and just need to ID the constants.
> > Notice that the ID'd poles are closer together than the real poles. =A0=
I
> > have notice that system identification tends to ID the poles closer
> > together than what they really are. =A0Notice that I all ID a dead time
> > and an ambient temperature. =A0This is something that JCH does not do.
> > At the bottom of the MSE(), mean squared error function, is where I
> > calculate the mean squared error between the estimated temperature and
> > the actual or test data temperature. The Minerr function adjusts
> > Kp,t1,t2,thetap, and C till the MSE is minimized. =A0You can see the
> > results are not perfect but that is reality.
> > 5. On page 5/10 the actual or perfect response is compare to the
> > estimated response. =A0The response looks close, almost identical, even
> > though the system identification =A0puts the estimated poles closer
> > together. =A0Also notice that a good system identification routine can
> > ID systems that are excited by more than just a step change. =A0In fact
> > they must must be able to do system identification with arbitrary
> > excitation. =A0 Above I said the excitation is the key to doing system
> > identification. =A0 One key is the make multiple steps at different
> > levels. =A0This is very important in computing the gain and computing
> > the gain when it isn't linear. =A0 Heat exchanger's gain changes becaus=
e
> > of LMTD. ( log mean temperature difference ).
> > 6. On page 6/10 PID gains are calculated using the estimated plant
> > parameters found by system identification. =A0My formula is a little
> > more complex that the IMC formulas but the response is faster/better
> > for the same closed loop time constant. =A0I doubt the extra complexity
> > in the formula is worth the effort for most applications.
> > 7 Page 7/10 simulates the PID control of the original system using the
> > gains calculated from the system identification. =A0 Notice that feed
> > back noise is simulated as well as the dead time.
> > 8. Page 8/10. =A0The simulation show the response. =A0The response isn'=
t
> > perfect because there was noise in the original data used to do the
> > system identification. =A0The system identification is not perfect
> > because the poles are closer together than they should be and I
> > simulated noise on the feedback but this is closer to reality.
> > 9 Page 9/10 uses the internal model gain formulas that I got from theww=
w.controguru.comsite. =A0They work well too and are much simpler they
> > don't work quite as mine. =A0 I should have provided a IAE value for my
> > gains and the IMC gains for comparison.
> > 10 page 10/10 shows the IMC response is a little slower but most would
> > be please with it.
>
> > I would use the above technique one at time with each heater and
> > temperature sensor. =A0 Actually one can excite each of the heaters one
> > at a time but the data for the 3 temperature sensors at the same time.
>
> > I posted a link to a scilab program that does the same thing many
> > years ago but no one seemed interested.
>
> > JCH, you should copy this so your program can handle dead times,
> > arbitrary inputs, and poles that are not all at the same place. What
> > you appear to be missing the quasi-Newton code( BFGS) or Levenberg-
> > Marquardt code that allows you to do proper optimization. =A0I bet you
> > use a grid search.
>
> > Peter Nachtwey
>
> Peter,
> =A0 =A0 =A0 =A0Sorry I didn't answer earlier; I was answering JCH and put=
ting
> the data up. =A0 I considered the route you illustrated, and perhaps I
> should have tried harder. =A0 But in your example in the above text you
> implicitly assumed (by writing the equation that way) that a good
> description was accessible through a single state variable per heater/
> sensor, and I ran into intellectual problems trying to have the
> flexibility for extension.
> =A0 =A0 =A0 I did read your earlier posting and will reread it.
> The problem I had was this:
> Suppose the correct set of terms for sensor one was:
> x'=3DAx+Bu
> y=3DCx+Du
> Where u is heater power, y is the sensor readings, and x is the
> internal state vector larger than u or y . =A0 Now a set of individual
> SISO readings and using supposition would result in individual state
> vectors xi and Ai,Bi,Ci,Di . =A0 Some the state vectors might be shared
> between the individual responses and some not. =A0How do you determine
> which ones are shared or not?

They are all independent but the results at the temperature sensors
will be from the sum of the 3 heaters.  This should hold true unless
there is something that I don't know where superimposition doesn't
apply.  The states for a system of SOPDT equations would simply have
the temperature and the temperature rate at each of the 3 temperature
sensors.  I don't see how the temperature at one sensor will affect
another temperature since the temperature sensors are not heat
sources.

Peter Nachtwey

On Nov 16, 9:58=A0am, pnachtwey <pnacht...@gmail.com> wrote:
> On Nov 15, 5:16=A0pm, RRogers <rerog...@plaidheron.com> wrote:
>
> > > > When starting the identification process the system must be at stea=
dy
> > > > state. =A0The three temperature sensors are at different temperatur=
es.
> > > > That could be steady state for a combination of heater outputs but =
it
> > > > is hard to know. =A0If all the heaters started at the same ambient
> > > > temperature then I know the system was at steady state.
>
> > > > Peter Nachtwey
>
> > > Peter,
> > > =A0 =A0 =A0 Okay, I will post that experiment but it's not as clean. =
=A0Since
> > > I only had shared access to the prototype I couldn't let the machine
> > > cool down long enough for a real restart, and (of course) the room
> > > temperature changed. =A0 These thermal systems have really long "tail=
s";
> > > some sections (plastic) absorb heat and let it out very slowly.
>
> > > Ray
>
> > Well I looked around, while I do have SIMO =A0heater by heater data the
> > subject heater input is random trying to obtain information the sys-id
> > routines like.
> > Incidentally: In case I forget; some of the data was taken has a
> > problem which I found out after much work and threatening to sue the
> > programmers; the PWM percentages were rounded down to units not tenths
> > and such. =A0 That's the reason for the second set of PWM data.
> > Maybe I should have quit when they separated the programming from
> > engineering (: =A0Endeavour to write and check your own control and
> > monitoring algorithms; you will have a happier life.
>
> > Ray
>
> As I said above, the quality of the data is very important. The
> initial state must be known and usually that is to ensure the system
> is at a steady state where the derivatives are 0. =A0It is too bad the
> data got truncated too. =A0I work with motion control systems. =A0It is
> easy to make sure the system is stopped before getting into excitation
> procedure. =A0If the ambient temperature or C changes during the test
> then that must be recorded too. Then it isn't a parameter to be
> determined.
>
> Are the time periods seconds? =A0If so then time constants are long.
> The long time constants make it hard to find the difference between
> small changes in estimated time constants. =A0The optimizing routines
> calculate a sum of squared error. =A0I like to think of the SSE as the
> elevation in a multiple dimension terrain and the optimizer is seeking
> the valley floor or pit. The slope of the SSE is checked in all
> dimensions, one for each parameter being optimized. =A0 If the slopes
> are very flat it is hard for the optimizing routine to get to a final
> best position. =A0The truncating data will make this almost impossible
> because small difference make a big difference on a flat 'desert'
>
> We have a motor that we put a relatively heavy disk on. =A0The weight
> increases the time constant to about 1 minutes which is forever in a
> motion control system. =A0 This system doesn't ID with a consistent set
> of numbers but all seem to work. It appear that there are some steep
> hills but once the SSE gets off the steep hills the valley is more
> like a flat 'desert'. =A0The long time constants do make finding the
> lowest part in the 'desert' difficult. =A0However, any solution on the
> desert floor seems to work equally well as the elevations are all the
> same but the question is will they work equally well under all motion
> conditions. =A0This is odd but true. =A0We have put a lot of effort in to
> exciting the motor so that the SSE 'desert floor' has more of a slope.
>
> Motors with short time constants are ID with more consistent
> parameters.
>
> Ray, you had the cards stacked against you, but your main problem was
> with the data, not optim() or lsqrsolve(). =A0The superimposed method
> would work. =A0The MIMO problem was not the biggest problem you had.
>
> Hopefully this explains why auto tuning sometimes doesn't always
> work.
>
> Peter Nachtwey

I am sure you don't want to get into this area but....
For a multi-state SISO system with poles on the negative real axis
there is a mathematical theory that is guaranteed to produce a
convergent series of models; I think it was extended to complex poles
as well.   It is based up Muntz polynomials being converted to an
orthogonal polynomial series; really posynomials.
Good news and bad news from this theory.  Bad news: almost any
sequence of poles will work.  Good news: almost any sequence of poles
will work.
That means that you can guide the process and make mistakes; the
mistakes will be washed out later.   But the result, while accurate,
will not necessarily be physically meaningful.  It also implicitly
means that there are an infinite number of perfectly accurate models;
which might throw optimization procedures off a little.   To summarize
you can estimate the two dominant poles, then by subtracting them out
of the data in a precise manner find another pole, use that in a
precise manner, and so on; the "precise manner" is the generation of
the orthogonal polynomial sequence.   The most obvious application
would be to use the impulse response; but I think I see how to extend
it to arbitrary inputs.
I have been thinking about applying it to the standard sys-id process
to make successive approximations converge; get better and better as
the order increases.    I haven't actually managed to get insight on
how to do this for MIMO approximations.

Enough said
Ray

"RRogers" <rerogers@plaidheron.com> schrieb im Newsbeitrag

[...]
>
> *http://home.arcor.de/janch/janch/_control/20091117-mimo-system/
> Perhaps my spam filters are blocking but all I see is a complicated
> block diagram.


I haven't sent more. Have again a close look to:

* http://home.arcor.de/janch/janch/_control/20091117-mimo-system/

This block diagram shows you eliminating coupling superposition. The MIMO 
system 'should act' as if there were just two separate control loops not 
interconnecting. Each of them can be optimized separately if the process 
transfer functions are known. Therefore you MUST have a good process 
identification.

Controller y1 influences process value x2 and vice versa!

Be aware that this is just an EXAMPLE for 2 input and 2 output signals. We 
have to find 4 differential equations for this EXAMPLE using process 
identification methods.

Physical derivation is difficult. Therefore measured (true) values should be 
used for finding the differential equations.


-- 
Regards JCH

On Nov 15, 5:16=A0pm, RRogers <rerog...@plaidheron.com> wrote:
> > > When starting the identification process the system must be at steady
> > > state. =A0The three temperature sensors are at different temperatures=
.
> > > That could be steady state for a combination of heater outputs but it
> > > is hard to know. =A0If all the heaters started at the same ambient
> > > temperature then I know the system was at steady state.
>
> > > Peter Nachtwey
>
> > Peter,
> > =A0 =A0 =A0 Okay, I will post that experiment but it's not as clean. =
=A0Since
> > I only had shared access to the prototype I couldn't let the machine
> > cool down long enough for a real restart, and (of course) the room
> > temperature changed. =A0 These thermal systems have really long "tails"=
;
> > some sections (plastic) absorb heat and let it out very slowly.
>
> > Ray
>
> Well I looked around, while I do have SIMO =A0heater by heater data the
> subject heater input is random trying to obtain information the sys-id
> routines like.
> Incidentally: In case I forget; some of the data was taken has a
> problem which I found out after much work and threatening to sue the
> programmers; the PWM percentages were rounded down to units not tenths
> and such. =A0 That's the reason for the second set of PWM data.
> Maybe I should have quit when they separated the programming from
> engineering (: =A0Endeavour to write and check your own control and
> monitoring algorithms; you will have a happier life.
>
> Ray
As I said above, the quality of the data is very important. The
initial state must be known and usually that is to ensure the system
is at a steady state where the derivatives are 0.  It is too bad the
data got truncated too.  I work with motion control systems.  It is
easy to make sure the system is stopped before getting into excitation
procedure.  If the ambient temperature or C changes during the test
then that must be recorded too. Then it isn't a parameter to be
determined.

Are the time periods seconds?  If so then time constants are long.
The long time constants make it hard to find the difference between
small changes in estimated time constants.  The optimizing routines
calculate a sum of squared error.  I like to think of the SSE as the
elevation in a multiple dimension terrain and the optimizer is seeking
the valley floor or pit. The slope of the SSE is checked in all
dimensions, one for each parameter being optimized.   If the slopes
are very flat it is hard for the optimizing routine to get to a final
best position.  The truncating data will make this almost impossible
because small difference make a big difference on a flat 'desert'

We have a motor that we put a relatively heavy disk on.  The weight
increases the time constant to about 1 minutes which is forever in a
motion control system.   This system doesn't ID with a consistent set
of numbers but all seem to work. It appear that there are some steep
hills but once the SSE gets off the steep hills the valley is more
like a flat 'desert'.  The long time constants do make finding the
lowest part in the 'desert' difficult.  However, any solution on the
desert floor seems to work equally well as the elevations are all the
same but the question is will they work equally well under all motion
conditions.  This is odd but true.  We have put a lot of effort in to
exciting the motor so that the SSE 'desert floor' has more of a slope.

Motors with short time constants are ID with more consistent
parameters.

Ray, you had the cards stacked against you, but your main problem was
with the data, not optim() or lsqrsolve().  The superimposed method
would work.  The MIMO problem was not the biggest problem you had.

Hopefully this explains why auto tuning sometimes doesn't always
work.

Peter Nachtwey

clip......
>
> If you can't find one differential equation (process transfer function) as
> part of a set you won't be able to solve anything.
>
> See basics and decoupling of MIMO system:
>
> *http://home.arcor.de/janch/janch/_control/20091117-mimo-system/
>
> --
> Regards JCH

JCH & Peter

This thread is getting long and unfocused.  Rather than talk about
doing something perhaps we could start a new thread or blog, and
actually have some contests and results doing system-id on some data
sets?  Nothing formal, just trials and analysis to improve our grasp
of the problems.  A reference site is NICONET but that is real data
and the "truth" is unknown, although I think they have some results
for comparison.  In any case dividing the data up into analysis and
prediction parts allows an objective criteria of tracking accuracy.
In addition we could construct various systems (say circuits or
something like what CLF showed), run simulations, present the data,
and see if the others can reconstruct the source of the data.  A
variation is that the subjects of the test can specify the type of
drives and we can see what problems/solutions various experimental
designs present.
Experiment design is a crucial part of system identification.

JCH
 *http://home.arcor.de/janch/janch/_control/20091117-mimo-system/
Perhaps my spam filters are blocking but all I see is a complicated
block diagram.
I hope that you don't mind if I disagree with your flat statement.
Among other things the heat equation is quite explicit and succinct;
but the Laplace transform (or any other form of solution) has an
infinite number of poles/states.  Having a good differential equation
form doesn't guarantee simplicity.  In other cases, i.e. distributed
systems, the situation can also lead to complications.
In any case actually doing some test cases would be more interesting
than abstract talking.

Ray

"RRogers" <rerogers@plaidheron.com> schrieb im Newsbeitrag 
news:b489cc63-2964-418f-9dcd-90fd9e4b3683@z3g2000prd.googlegroups.com...
> On Nov 15, 6:14 am, "JCH" <ja...@nospam.arcornews.de> wrote:
>> "RRogers" <rerog...@plaidheron.com> schrieb im 
>> Newsbeitragnews:3d4e61d7-69d7-4431-a12a-88e31d5868f7@x5g2000prf.googlegroups.com...
>>
>>
>>
>> > clip..........
>> >> ...
>>
>> >> read more &#4294967295;
>>
>> > Okay  I have uploaded the file that corresponds to step inputs.  This
>> > one is fairly clean.
>> >http://www.plaidheron.com/ray/temp
>> > static-test.jpg
>> > static-test.xls
>> > Should get you there.  If there is a permission problem let me know; I
>> > will resolve.
>>
>> > The .jpg is a graph to get the idea.  T-11 is included to verify the
>> > environment didn't change much.
>> > The .xls is: sheet 1 graphs, sheet static-test is the long
>> > experimental run covering about 4 hours
>> > Cols: T-1,2,3  are the three direct thermistors used later for control
>> > Cols: M,N,O are the PWM drives, 0-100%, to the corresponding heaters;
>> > the trailing columns can be ignored
>> > The intermediate columns are various sensors distributed away from the
>> > actively controled points.
>>
>> > Let me know and I (or you ) can cross-verify your model against other
>> > experimental runs.
>>
>> > I have other experimental data sets that are less clear; some are
>> > basically random inputs to try to satisfy the sys-id programs.
>>
>> Basically refering to
>>
>> *http://home.arcor.de/janch/janch/_control/20081123-real-system-model/
>>
>> Can you approach the best possible ODE (process transfer function) in a
>> range of order <= 6?
>>
>> C6 y'''''' + C5 y''''' + C4 y'''' + C3 y''' + C2 y'' + C1 y' + y = K
>>
>> Decimal commas!
>>
>> Example data points: 30
>>
>> 0 0
>> 0,062 0
>> 0,124 0,002
>> 0,187 0,012
>> 0,249 0,04
>> 0,311 0,093
>> 0,373 0,17
>> 0,435 0,266
>> 0,498 0,373
>> 0,56  0,48
>> 0,622 0,581
>> 0,684 0,671
>> 0,746 0,748
>> 0,809 0,811
>> 0,871 0,861
>> 0,933 0,899
>> 0,995 0,929
>> 1,057 0,95
>> 1,12  0,966
>> 1,182 0,977
>> 1,244 0,984
>> 1,306 0,99
>> 1,368 0,993
>> 1,431 0,996
>> 1,493 0,998
>> 1,555 0,999
>> 1,617 1
>> 1,679 1
>> 1,741 1
>> 1,804 1,001
>>
>> --
>> Regards JCH
>>
>> My solution see down here:
>>
>> Decimal commas!
>> 1,048734E-06 y'''''' + 6,2427E-05 y''''' + 0,001548347 y'''' + 0,02048154
>> y''' + 0,1523982 y'' + 0,6047773 y' + y = 1,000953
>
> We seem to have a disconnect here.
> The system is MIMO which means that a finite model would have a set of
> simultaneous differential equations...


If you can't find one differential equation (process transfer function) as 
part of a set you won't be able to solve anything.

See basics and decoupling of MIMO system:

* http://home.arcor.de/janch/janch/_control/20091117-mimo-system/


-- 
Regards JCH