-entered the LinuxCNC master branch</a> a few days ago. To enable auto
-tuning, one need to set a few HAL pins in the PID component. The most
-important ones are tune-effort, tune-mode and tune-start. But lets
-take a step back, and see what the auto tuning code will do.</p>
-
-<p>I do not know the mathematical foundation of the at_pid algorithm,
-but from observation I can tell that the algorithm will, when enabled,
-produce a square wave pattern centered around the bias value on the
-output pin of the PID controller. This can be seen using the HAL
-Scope provided by LinuxCNC. In my case, this is translated into
-voltage (+-10V) sent to the motor controller, which in turn is
-translated into motor speed. So it will ask the motor to move the
-axis back and forth. The number of cycles in the pattern is
-controlled by the tune-cycles, and the extremes of the wave pattern is
-controlled by the tune-effort pin. Of course, trying to change the
-direction of a physical object instantly (as in going directly from a
-positive voltage to the equivalent negative voltage) do not work, and
-it take some time for the object to slow down and move in the opposite
-direction. This result in more smooth movement wave form, as the axis
-in question were vibrating back and forth. When the axis reached the
-target speed in the opposing direction, the auto tuner change
-direction again. After several of these, the average time delay
-between the 'peaks' and 'valleys' of this movement graph is then used
-to calculate proposed values for Pgain, Igain and Dgain, and insert
-them into the HAL model to use by the pid controller. The end result
-is not great, but it work a lot better than the values I had been able
-to cook up on my own, at least for the horizontal X and Y axis. I've
-been less lucky with the Z axis, which is moving a heavy object up and
-down, and seem to confuse the algorithm. It became a lot better when
-I introduced a bias value to counter the gravitational drag, but I
-will have to work a lot more on the Z axis PID values.</p>
+entered the LinuxCNC master branch</a> a few days ago.</p>
+
+<p>To enable auto tuning, one need to set a few HAL pins in the PID
+component. The most important ones are <tt>tune-effort</tt>,
+<tt>tune-mode</tt> and <tt>tune-start</tt>. But lets take a step
+back, and see what the auto tuning code will do. I do not know the
+mathematical foundation of the at_pid algorithm, but from observation
+I can tell that the algorithm will, when enabled, produce a square
+wave pattern centered around the <tt>bias</tt> value on the output pin
+of the PID controller. This can be seen using the HAL Scope provided
+by LinuxCNC. In my case, this is translated into voltage (+-10V) sent
+to the motor controller, which in turn is translated into motor speed.
+So at_pid will ask the motor to move the axis back and forth. The
+number of cycles in the pattern is controlled by the
+<tt>tune-cycles</tt> pin, and the extremes of the wave pattern is
+controlled by the <tt>tune-effort</tt> pin. Of course, trying to
+change the direction of a physical object instantly (as in going
+directly from a positive voltage to the equivalent negative voltage)
+do not change velocity instantly, and it take some time for the object
+to slow down and move in the opposite direction. This result in a
+more smooth movement wave form, as the axis in question were vibrating
+back and forth. When the axis reached the target speed in the
+opposing direction, the auto tuner change direction again. After
+several of these changes, the average time delay between the 'peaks'
+and 'valleys' of this movement graph is then used to calculate
+proposed values for Pgain, Igain and Dgain, and insert them into the
+HAL model to use by the pid controller. The auto tuned settings are
+not great, but htye work a lot better than the values I had been able
+to cook up on my own, at least for the horizontal X and Y axis. But I
+had to use very small <tt>tune-effort<tt> values, as my motor
+controllers error out if the voltage change too quickly. I've been
+less lucky with the Z axis, which is moving a heavy object up and
+down, and seem to confuse the algorithm. The Z axis movement became a
+lot better when I introduced a <tt>bias</tt> value to counter the
+gravitational drag, but I will have to work a lot more on the Z axis
+PID values.</p>
projects / homepage.git / blobdiff