Re: Jog wheel

[Ray Henry <rehenry-at-up.net>]

Dean

There are a bunch of cautions buried in this post.  And it attempts to deal 
with both the issue of a joystick and with a handwheel.  And it is not all my 
own work, Fred, Will, Matt, Steve, and I discussed some of this recently.

Joystick

It is easy enough to take a single keystroke and turn it into a motion 
command using Tcl/Tk and emcsh.  All that you would have to do is bind the 
keystroke to a specific jog command.  These bindings are already active with 
tkemcex.  I believe the also work with tkemc.

These target the active axis' jog processes
    bind ManualBindings <KeyPress-minus> minusDown
    bind ManualBindings <KeyRelease-minus> minusUp
    bind ManualBindings <KeyPress-equal> equalDown
    bind ManualBindings <KeyRelease-equal> equalUp

These target X jog processes
    bind ManualBindings <KeyPress-Left> leftDown
    bind ManualBindings <KeyRelease-Left> leftUp
    bind ManualBindings <KeyPress-Right> rightDown
    bind ManualBindings <KeyRelease-Right> rightUp

These target Y jog processes
    bind ManualBindings <KeyPress-Down> downDown
    bind ManualBindings <KeyRelease-Down> downUp
    bind ManualBindings <KeyPress-Up> upDown
    bind ManualBindings <KeyRelease-Up> upUp

These target Z jog processes
    bind ManualBindings <KeyPress-Prior> priorDown
    bind ManualBindings <KeyRelease-Prior> priorUp
    bind ManualBindings <KeyPress-Next> nextDown
    bind ManualBindings <KeyRelease-Next> nextUp

Caution -- While the EMC motion modules themselves have no problem with 
jogging more than one axis at a time, part of the problem here is that you 
will get the key presses mixed up with the key releases if you try to run 
more than one set at at time from the keyboard or from these processes in 
tkemc.

If we added a test variable to each of the jog processes that would prevent a 
second axis jog when one is already active we could prevent the keystroke 
interference problem.

These jog processes use the current jog speed as the speed they use whenever 
they issue a motion command.  This speed can be overridden using the feed 
override stuff.  I suppose that you could set jog speed to rapid and jog type 
to continuous mode when you activated the joystick routines and then issue 
the keystrokes below if you can figure out a way to take the value of the 
joystick offset from zero and chop it up into ten chunks.

In the case of a joystick, the following feedrate bindings are already active 
with tkemcex.

    bind ManualBindings <KeyPress-grave> {emc_feed_override 0}
    bind ManualBindings <KeyPress-1> {emc_feed_override 10}
    bind ManualBindings <KeyPress-2> {emc_feed_override 20}
    bind ManualBindings <KeyPress-3> {emc_feed_override 30}
    bind ManualBindings <KeyPress-4> {emc_feed_override 40}
    bind ManualBindings <KeyPress-5> {emc_feed_override 50}
    bind ManualBindings <KeyPress-6> {emc_feed_override 60}
    bind ManualBindings <KeyPress-7> {emc_feed_override 70}
    bind ManualBindings <KeyPress-8> {emc_feed_override 80}
    bind ManualBindings <KeyPress-9> {emc_feed_override 90}
    bind ManualBindings <KeyPress-0> {emc_feed_override 100}

If the code indicated can do this then all that would be necessary is to have 
it issue these keystrokes. 


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 pulses, 
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.

Ray


On Saturday 01 June 2002 19:21, you wrote:
> Hey Jogging input device seekers,
>
> Look what I just found:
>
> http://www-unix.oit.umass.edu/~tetron/technology/joy2key/
>
> It takes joystick motion  and converts it to keystrokes.  I wonder if
> we can set it up with EMC's GUI for jogging?
>
> I wonder if I still have a PC joystick lying around somewhere.
>
> I'll keep you posted...