Re: [CAD_CAM_EDM_DRO] virtual hand jive and human factors

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