A little too late for the China workshop, unfortunately, but I've just found and corrected a bug in the Chapter 3 demo of the control loop with an integral lag on the output and a transport lag on the input: when you click the "Slow" button, not only is the animation slowed down a factor of 10, but the input lag is reduced by the same amount. My expectation was that the slow and fast modes should present a simulation of exactly the same physical system, but in slow motion or in real time respectively. I also found that changing the value of dt in the source code produced a simulation with different physical properties.
So, I revised it to make sure that the change to dt only affects the numerical accuracy of the simulation, and "Slow" only affects the speed it is displayed, and also added the possibility of using a value of dt much smaller than the interval between updates of the screen. The last let me check the numerical accuracy of the simulation by comparing runs with different values of dt. In general, a value of dt that is too large has the effect of injecting some fictitious energy into the system.
This was so I could confirm my mathematical analysis of the system, and I've been gratified to find my predictions exactly satisfied.
I can post some mathematical details if anyone's interested, but in brief, there is a single number defining the stability of the system, which is:
gamma = (total gain round the loop) * (input delay) / (output delay)
By total gain I mean the product of all three gain elements.
When gamma < 1/e, the system's response to a step disturbance is a smooth exponential approach. Between 1/e and pi/2, damped oscillations appear. They become sustained at gamma = pi/2 and exponentially increasing above that value. The oscillations all have a period of 4 times the time delay.
In the original version that Bill put on the net, this can be demonstrated (in "normal" mode, not "slow" mode) with the following values of the parameters.
Instability Critical damping
input gain 1 1
feedback gain 1 1
output gain 100 30 ... 50
output delay 6.3 ... 7.2 10
input delay 0.1 0.1
In the first column, the critical value for stability should be 10/(pi/2) = 6.4. I find that with the original version of the program the value is about 7, but reducing the time delay from 1/60 to 1/6000 brought it down to 6.4. I believe this is due to the slight inaccuracy at the larger time step making the simulation slightly more unstable than the real system.
When the system is critically damped, the time constant of its response to a disturbance is equal to the input delay. (A slight simplification -- obviously, the system cannot respond at all to a disturbance before one input time delay has passed, and only then does it begin to move towards its steady state. It takes around 4 times the input delay for the error to decrease to about 10% of its initial value, which is a little longer than a pure exponential would.) As gamma either decreases towards zero or increases towards pi/2, the time constant becomes longer. Gamma = 1.2 is actually more practical than gamma = 1/e: the error goes to zero in about 3 input time delays, with only a small overshoot.
I've put a copy of my amended source code and executable up at
http://www.cmp.uea.ac.uk/~jrk/temp/LiveBlockRK/Unit1.pas
http://www.cmp.uea.ac.uk/~jrk/temp/LiveBlockRK/LiveBlock.exe
I've also put a plot of gamma against time constant of the closed-loop response at
http://www.cmp.uea.ac.uk/~jrk/temp/LiveBlockRK/all-b-gamma.png
Gamma is the vertical, time constant the horizontal, with negative values being stable, positive unstable. The blue trace shows the non-oscillating behaviour, the red the oscillating.
···
--
Richard Kennaway, jrk@cmp.uea.ac.uk, http://www.cmp.uea.ac.uk/~jrk/
School of Computing Sciences,
University of East Anglia, Norwich NR4 7TJ, U.K.
