Re: [CAD_CAM_EDM_DRO] virtual hand jive and human factors

Howdy! As a point of clarity, yes, the goldmine encoders. I agree that key devices typically use matrix encoding but it is no problem to create
your own "slave" keyboard with just switches. The [CAD_CAM_EDM_DRO] files section has a directory called "Dual Keyboard" which contains
information and pictures showing how to do this very thing. <g> Essentially what you do is run 2 keyboards in parallel by using a simple
switch. Either of these keyboards will send an "a" to the PC when the respective "a" key is pressed. But what is the joy in that?

The magic happens when you re-label the the keys of one of the keyboards. In CNCpro a "PgUp" gives a +Z jog, so a "PgUp" from either keyboard
will give the same jog. You could put a SPDT mom-off-mom switch into an aluminum box and wire both "PgUp" and "PgDn" to this switch. Then when
you push the toggle towards the +Z position, the slave keyboard send a "PgUp" to the PC, CNCpro "sees" this and sends pulses to the drivers,
and the stepper rotates in the house that Jack built.

The next logical step is to press this +Z jog key repeatedly until the tool clears the workpiece. I could do this by repeatedly pushing the +Z
key or by turning our handwheel which sends out a string of pulses proportional to rotation. These pulses trigger an analog switch instead of
the SPDT mom-off-mom. But the result is the same, CNCpro "sees" a string of "PgUp" pulses. Whatta' ya think?


Alan Marconett KM6VV wrote:

> Rick,
>
> By motor's encoder, I assume you mean the "goldmine" motors, not the
> mill's steppers/encoders! That could work. As long as you've added
> logic to generate something like CW and CCW lines that simulate keyboard
> key closures.
>
> I checked on the Joystick interface, four switches, so we have the
> possibility of X and Y axes "jog" knobs. The 15-pin connector also
> provides +5v, so we can power the encoders.
>
> The typical keyboard/keypad uses row/column type addressing. The keypad
> I have in mind is just switches. It can use a "row drive", and you read
> the columns. If it's scanned this way, ya gonna need more logic. The
> software driver for the PC (or PIC) generates the "row drive", and then
> reads the columns, to figure out what key is pressed. Not quite
> compatible with CW/CCW lines. Or some 8041 type processor scans the
> keyboard and sends serial make/break codes to be handled by the PC.
> What keypad are you thinking of?
>
> If we have our own "software driver" to add the additional keypad, we
> might want to simulate the keys at that level.
>
> The "human factor" is good, which way do you turn the knobs/handwheels?
> match the old ones? If I do three encoders, I'll match the Sherline
> handwheels. Just two encoders might be an improvement, Z doesn't get
> cranked for cuts as much.
>
> Another thought, for MaxNC, "turning" the appropriate encoder could
> "always" shift you into the proper jog mode, X, Y, or Z (gonna be easier
> in software). Need more interface bits, only get 4 with Joystick
> interface.
>
> More thoughts?
>
> Alan
>
> Rick Dulas wrote:
> >
> > Howdy! Interesting ideas! How 'bout this? Instead of a TSR and some port getting step and dir, you hardware decode the motor's encoder
> > output onto 2 pins, one of which is high while the other is low and these pins pulse once for each encoder pulse. For the X axis these
> > could be called +X and -X. (kinda catchy don't ya think?) Then we wire these pins into/onto the slave keyboard instead of the left <- and
> > right -> arrow keys. This way we get the "handwheel" feature but still use CNCpro or whatever and wouldn't have anymore problem with
> > buffer overflow than you would have with the keyboard. You could get variable handwheel speeds by using a hardware divider/multiplier but
> > a software solution is probably a much better way to go on this.
> >
> > As for the mounting of the handwheels, by putting them on 3 perpendicular axes, you more closely mimic the control behavior of the
> > machine. The key issue here is what Human Factors people call control mapping. You always want to map the control's behavior so the
> > operator can make the right move at the right time. In times of stress, you don't want the operator to say to himself "Let's see, left
> > means forward, so right means back."
> >
> > Here is a perfect example of a control mapping issue. When the swing-wing F-111 was in flight test, the swing wing control was set up by
> > the engineers to mimic the movement of the wings. Push forward, wings out, pull back wings in. Easy right?
> >
> > For pilots, pushing forward means "go fast", pulling back means "go slow". When the plane is landing, the wings move from a swept
> > position, to a deployed or wings out position. So the throttle is pulled back, the landing gear lever is pulled back, the wing position
> > lever is pulled back...
> >
> > In the words of a famous test pilot, "this is a serious 'Ah, shit' situation". After several mishaps, the wing control was changed to
> > mimic its flight behavior, not its mechanical behavior.
> >
> > Rick Dulas
> >
> > Alan Marconett KM6VV wrote:
> >
> > > Rick,
> > >
> > > The three goldmine encoders sound like a good idea (missed getting mine
> > > 8>( ), however I think you will want to stay in CNCpro, not exit it to
> > > run manual. SO, we need to get encoder inputs INTO CNCpro, (MaxNC, any
> > > chance?), or whatever control program. I had thought that a TSR program
> > > could watch the encoder(s) on timer ticks, and add the appropriate keys
> > > into the keyboard buffer, but as has been mentioned, the overflow could
> > > kill ya! The TSR could still help to map a keyboard pendent into
> > > program keys :>)
> > >
> > > The "orthogonal directions" sounds interesting, put the encoder knobs
> > > (handwheels) on three mutually perpendicular axis? ...And I was just
> > > going to add a jog knob (with led's to remind me which axis I was
> > > jogging, and selection p/b's)!
> > >
> > > Alan
>
> Welcome to CAD_CAM_EDM_DRO@...,an unmoderated list for the discussion of shop built systems, for CAD, CAM, EDM, and DRO.
>
> Addresses:
> Post message: CAD_CAM_EDM_DRO@egroups.com
> Subscribe: CAD_CAM_EDM_DRO-subscribe@egroups.com
> Unsubscribe: CAD_CAM_EDM_DRO-unsubscribe@egroups.com
> List owner: CAD_CAM_EDM_DRO-owner@egroups.com, wanliker@...
> Moderator: jmelson@... [Moderator]
> URL to this page: http://www.egroups.com/group/CAD_CAM_EDM_DRO
> FAQ: http://www.ktmarketing.com/faq.html
> bill,
> List Manager