Handwheels with EMC

Handwheel folks,

I've been reading the recent posts on implementing handwheel encoders
for moving axes. I know of a couple of ways to implement a handwheel:

1. analogous to electronic gearing. With this method, the handwheel
encoder is read at the same time all the axis encoders are read. The
encoder input for the fourth axis of the Servo To Go card would serve
nicely for the handwheel.
At the GUI, you would activate or deactive the handwheel, possibly by
selecting an axis, clicking a "handwheel activate" GUI button, and
changing the sensitivity factor through some continuous or incremental
range. The controller would then switch the input to the PID for the
selected axis from the trajectory planner to the handwheel, taking care
to set an offset so that the axis didn't jump. As you turned the
handwheel, the selected axis would be electronically slaved to it. The
commanded position for that axis would track the actual position, as is
done when in estop, so the displayed numbers would be true.
The accel/decel and speed of the axis would be controlled by your hand.
If you cranked the sensitivity too high, you'd likely see servo lag,
overshoot, etc. just like you would if you set the max acceleration and
feed too high in the INI file. Software limits would still be in effect,
if the axis were already homed. If you tried to jog past the software
limit the controller would prevent you. Simple deceleration lookahead
would cause a graceful stop at the software limit, rather than an abrupt
clamp.
When you deactivated the handwheel, the actual position would be used
as the commanded position, so there would be no jump.
Incremental motion would be accomplished only through the detents on
the handwheel. Selecting the sensitivity could enable you to set the
detents so that each one amounted to 0.001 unit, 0.010 unit, etc. so
you'd effectively have incremental jogging.

2. As an alternative way to jog an axis. With this method, the GUI
itself reads the handwheel, and sends jog messages to the controller.
There are problems with latency with this method, since the GUI needs to
compose jog commands and send them to the controller. As you change the
handwheel speed, new commands need to be sent down. Advantages with this
method are that the INI file accel/decel values are honored; incremental
handwheel motion is truly incremental jogging; and multiple distributed
pendants or panels, each with its own handwheel, can be supported.

The advantages to the second method may not be enough to offset the
latency. Accel/decel with the first method are controlled directly by
you, so it may simply be a question of not being unreasonably rough with
the wheel. Using detents and proper scaling with the first method, its
incremental jogging is indistinguishable from the second method. The
biggest problem with electronic gearing is that you can't have multiple
GUIs each with its own handwheel, unless you wire the handwheel encoders
from the pendant to the motion card. Noise becomes a problem as the
cable length to the pendant gets long.

I plan on implementing handwheels using the first method, electronic
gearing. This technique can also be adapted to do rigid tapping, where
the Z axis is slaved to the feedback from the spindle encoder.

The two methods are compatible, and both can be done in a single
controller. At this point it's a question of priorities.

--Fred