Re: Jog wheel

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

Hi Brian (comments in)

On Sunday 02 June 2002 00:57, Brian wrote:
> Hi Ray
>
> a few comments thrown in
>
> > 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.
>
> right...
> except the incremental handwheel would be easier than dealing with all
> the keyboard quirks and the calibration and timing on the analog joystick
> etc.

I've got to agree with you on this one.  I can visualize driving a car with a 
joystick, the old plane I flew had one, but I've got a bit of a crisis trying 
to visualize driving my mill with one.  My preference would be for the 
handwheel.  But that is only me.

> > 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.
>
> this one came up on the CCED list last time
> it should ,yes,should  ignore the extras if it is already jogging
>
> on many machines with MPGs you can hear/feel the larger increments as
> a bunch if startstops but the small increments will blend together and feel
> like a smooth motion
>
> > 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.
>
> sure they would
> it has to finish one before it can take another so they
> would either be the same size or be skipped over
> at the end of the move it would always stop on a multiple of
> the increments from the start point even if a few were skipped

I don't think this is the way my mill works here.  If I issue a 1 inch jog 
and then issue another while it is moving, I get a jog that stops somewhere 
in the middle of the second inch.

> > 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.
>
> exactly
> the axis will stop as soon as you stop ,just like a normal handwheel
> this is what we want to happen

I guess the meaning of normal here is the issue.  If I grab a Mazak handwheel 
from the t2 or t32 age and set it to the largest increment and spin the wheel 
it will count all of the pulses that it has not completed and will finish 
them all so that the ending distance is the distance I moved the wheel.

> > 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.
>
> so if the jog increment was set at .1 and you gave the wheel two quick
> turns you would get an axis movement of 20 inches ,with no way to stop it
> except smashing the E-Stop switch
> ummm...

Well I guess that's one more reason for limits.  Soft or hard.

> thats probably not the behavior we really want ;-)

I can certainly understand where you're coming from here.  Let's not let this 
minor difference in imagined function stall out the process of really making 
one of these that works.  Let's drawn up the specs for one of these and throw 
it into the code writing stage.  

I'm not sure that the Tcl/Tk code level is the appropriate one for this but 
we could easily prototype it there and then translate it when we have it 
working the way we think it should.

If we need cheap quadrature, one of those oven temp pulsers should do the 
job. but as Paul points out, mouse guts should do it also.  I seem to 
remember that he put started some code read a second mouse connected to a 
serial port.  

Ray