Re: Jog wheel

["Peter Cook" <kf2qd-at-terraworld.net>]

My thought on the encoder type handwheel is that it is a form of what is
commonly referred to as electronic gearing - look at the move distance on a
"master" axis and dulplicate it on a "slave" axis.
Right now I don't think this is impimented in any for -or is it?

Pete

>
> Handwheel
>
> Now the handwheel problem is not quite so simple.  Rather than the
continuous
> jog as in the suggested stuff above, we would use incremental jog and the
> increment would determine the multiplier to be used with each pulse/push.
>
> But now any motion command issued by the emc has a speed and an endpoint
so
> this would seem to work okay but what happens in the case of a handwheel
> where a second or third jog command is issued while the first one hasn't
yet
> completed it's move.  Normally the endpoint of an incremental jog command
is
> computed from the current position to the position of the axis with the
> increment added or subtracted.  So what would normally happen is that
> whenever the second motion command is recognized by the task module, it
will
> take the current location and add the increment.  Thus not all increments
or
> handwheel steps will be the same length.  Only those issued after the
> previous has been completed will move the axis the full increment
distance.
> So spinning the handwheel rapidly during a jog will only get you a bit
> further than the next to last one executing.
>
> This behavior could be altered if we wrote a routine that captured the
pulses
> of the handwheel and add them up while a jog command is being executed.
Then
> when the current motion command completes, it would issue a single command
> with the distance value as the number of pulses times the increment and
set
> the count to zero again.
>
> The jogwheel commands could be derived from the pins of a parport if the
tcl
> loop were fast enough to catch all of the pulses.  There are five pins in
on
> a standard parport so we could use one for plus pulses, one for minus puls
es,
> one for axis toggle, one for increment toggle and one for jog speed
toggle.
> Or we could make a more exotic bcd like code combination that would give
us
> more control.
>
> If we were to build this thing into a pendent we could use the 12 out bits
to
> turn on leds that would show current axis, increment, and speed values.
>
> It would also be easily possible to issue an abort command from this
pendent.
> Abort would stop any active motion command.  We would also need to empty
the
> pulse bins.
>
> I hesitate to suggest that we issue a software estop.  I like to reserve
that
> for something that really shuts off the power to the motors without having
> to be directed through the PC.