[From Bruce Abbott (2016.11.11.1030 EST)]
In the July 1979 issue of Byte magazine, Bill Powers continued his series (introduced in the June issue) on control systems, which included a set of demonstrations written in BASIC. The July installment presented the code that simulates a standard PCT-style control system. Much of the code is devoted to I/O, which involved keyboard input of parameter and variable values and the display of results on a system capable only of displaying ASCII characters. This is now outdated, but I found the code that runs the actual simulation interesting enough to deserve a brief mention here.
The interesting part for me was Bill’s use of a leaky integrator. Typically the demos we use today include a leaky integrator in the output function, where it is used to prevent an artifact that arises when simulating a continuous system with variables that change one step at a time with each iteration of the control loop. (It is also used, with proper adjustment of the slowing factor, to match the simulation results to a participant’s performance, as in the TrackAnalyze simulation.) The leaky integrator in the output prevents the output from changing its full computed amount in one step. For example, the current value of the error signal might call for an output that fully corrects the error in the same step in which the error arose, as if the correction could happen instantaneously. Allowing the digital simulation to do this leads to unrealistic behavior since real physical systems require at least some minimum amount of time to react to changes. Adding a leaky integrator to the output corrects this problem. Instead of allowing the output to change instantly to the value that would fully correct the error in zero time, the leaky integrator allows only a portion of that full correction to develop on each iteration of the loop. For example, if the slowing factor were 0.5, then the output would change only half-way toward its final value on each iteration. Each succeeding iteration would cut the remaining difference in half, thus producing a negative exponential approach toward the final value.
So what is interesting about Bill’s use of a leaky integrator in his Byte simulation? It’s that he included one in both the output function and the input function. By changing the slowing factors of each, one could see the effect of having either the input, the output, both, or neither making use of leaky integration during the simulation. Setting a slowing factor to 1.0 eliminates leaky integration: the output changes its full value in the same iteration of the loop in which the error changed. Set both slowing factors to 1.0 and the simulation fails. Set the slowing factors of either or both to some fraction produces stable behavior that simulates the continuous system.
I like this and thought it worth pointing out, because it would be easy to conclude, incorrectly, from our typical PCT demos that the leaky integrator must appear in the output function. In fact it can go anywhere in the loop – even in the environment function if integration naturally takes place there. For the simulation to work properly, there only needs to be one integration in the loop, and it doesn’t have to be leaky – as is the case in integral control systems. There can be more than one; however each integration will contribute additional lag in the system, and too much lag leads to instability.