CNC UI (Virtual hand jive vs. conversational prgmmg)
Posted by
ballendo@y...
on 2000-11-06 20:41:23 UTC
Hi all,
We started with a guy who wanted to retain the use of his
handwheels...
Moved to manual vs. CNC (for simple parts)...
Then pendants, and iso 3 axis handwheels...
Now, how best to implement "manual" functions in a modern CNC...
It seems to me that we are "really" talking about the ideal CNC User
Interface! And it seems that we have already crossed the line to at
least a partial s/w solution. As we add "features" to the pendant/
handwheel we start to overlap the functions of "conversational"
programming...
What I would like is:
A SINGLE handwheel(or pressure button/joystick) I can "link" the
other axes to. (at variable ratios)Defined by angles or arcs. Pop up
dialog boxes to "insert parameters" for the "manual move" which I
will control with the wheel/button/joystick. The thinking here is
that I really only NEED to move ONE axis(arbitrarily) at a time; the
times when I need to move two or more will be in some RELATION to
the "main" one.
VERY few people(but there ARE some!!) can move two wheels at anything
remotely resembling an angular ratio(If you find someone who thinks
they can, hand him/her an etch-a-sketch and say "draw me a diamond,
or a circle")
If we use the "standard" Tee-style pendant case(as in the pic posted
recently), we could implement axis selection pushbuttons on
the "handle" part(push on-push off/momentary. Selectable by setup
params:"Scaled" to the primary axis if nec., also by setup params)
which would allow us to "select/add-in" axis movement while moving
with the pendant encoder/joystick/button.
Surely this would equal the functionality of handwheels for getting
somewhere; "blip" in a little more Y there, oops add a little x. I
see this working for 3 axes easily(thumb, index, middle finger)or
(index, middle, ring). 4 axes possible. I'm left-handed. How about
you?(where do we put these buttons/How do we deal with this? (8
switch positions in the "case", you pick 3;or 4?) Duh! we buy a std.
case and each user machines his/her own switch locations!
The conversational control screen(s) supporting the pendant manual
movement functions would allow us to choose circular or linear interp
(for the add-in axes) and set angles/radius'.
You could even goof-proof a manual move by having the s/w set soft
limits according to conversational input( so you don't over-run; the
pulses just stop until you override...)
Allow the pendant to "call up" the conversational screens(for access
to Jon E style subroutines for commonly used features/pockets,etc.)
and "tab" through the parameters, and I believe you'd have a very
user friendly powerful system. Ron G, what do you think?
If I were implementing this, I'd use a "second" keyboard with the
master/slave switch and write the S/W to use "keypresses" where
possible. This would mean all the functionality is available at the
keyboard, and makes it easy to implement the s/w with std. system
calls.
Maybe use the game port also for the "handwheel/joystick/pressure
switch" functions.
Side note: the game port is relatively slow when used with joystick
functions. How slow is slow, relative to the speeds we'd need?
(because the joystick is already there/available and works very
nearly like what we NEED)
Ballendo
P.S. It's been awhile since I used it, but the later versions of
DanCam/DanPlot used the joystick for some interesting "path
construction" functions. (jog somewhere,mark this point. jog,mark.
jog,mark. Now DC/DP, those three points are an arc, please draw it
for me and remember it so we can cut it later!)
We started with a guy who wanted to retain the use of his
handwheels...
Moved to manual vs. CNC (for simple parts)...
Then pendants, and iso 3 axis handwheels...
Now, how best to implement "manual" functions in a modern CNC...
It seems to me that we are "really" talking about the ideal CNC User
Interface! And it seems that we have already crossed the line to at
least a partial s/w solution. As we add "features" to the pendant/
handwheel we start to overlap the functions of "conversational"
programming...
What I would like is:
A SINGLE handwheel(or pressure button/joystick) I can "link" the
other axes to. (at variable ratios)Defined by angles or arcs. Pop up
dialog boxes to "insert parameters" for the "manual move" which I
will control with the wheel/button/joystick. The thinking here is
that I really only NEED to move ONE axis(arbitrarily) at a time; the
times when I need to move two or more will be in some RELATION to
the "main" one.
VERY few people(but there ARE some!!) can move two wheels at anything
remotely resembling an angular ratio(If you find someone who thinks
they can, hand him/her an etch-a-sketch and say "draw me a diamond,
or a circle")
If we use the "standard" Tee-style pendant case(as in the pic posted
recently), we could implement axis selection pushbuttons on
the "handle" part(push on-push off/momentary. Selectable by setup
params:"Scaled" to the primary axis if nec., also by setup params)
which would allow us to "select/add-in" axis movement while moving
with the pendant encoder/joystick/button.
Surely this would equal the functionality of handwheels for getting
somewhere; "blip" in a little more Y there, oops add a little x. I
see this working for 3 axes easily(thumb, index, middle finger)or
(index, middle, ring). 4 axes possible. I'm left-handed. How about
you?(where do we put these buttons/How do we deal with this? (8
switch positions in the "case", you pick 3;or 4?) Duh! we buy a std.
case and each user machines his/her own switch locations!
The conversational control screen(s) supporting the pendant manual
movement functions would allow us to choose circular or linear interp
(for the add-in axes) and set angles/radius'.
You could even goof-proof a manual move by having the s/w set soft
limits according to conversational input( so you don't over-run; the
pulses just stop until you override...)
Allow the pendant to "call up" the conversational screens(for access
to Jon E style subroutines for commonly used features/pockets,etc.)
and "tab" through the parameters, and I believe you'd have a very
user friendly powerful system. Ron G, what do you think?
If I were implementing this, I'd use a "second" keyboard with the
master/slave switch and write the S/W to use "keypresses" where
possible. This would mean all the functionality is available at the
keyboard, and makes it easy to implement the s/w with std. system
calls.
Maybe use the game port also for the "handwheel/joystick/pressure
switch" functions.
Side note: the game port is relatively slow when used with joystick
functions. How slow is slow, relative to the speeds we'd need?
(because the joystick is already there/available and works very
nearly like what we NEED)
Ballendo
P.S. It's been awhile since I used it, but the later versions of
DanCam/DanPlot used the joystick for some interesting "path
construction" functions. (jog somewhere,mark this point. jog,mark.
jog,mark. Now DC/DP, those three points are an arc, please draw it
for me and remember it so we can cut it later!)
Discussion Thread
ballendo@y...
2000-11-06 20:41:23 UTC
CNC UI (Virtual hand jive vs. conversational prgmmg)
Ian Wright
2000-11-07 00:20:13 UTC
Re: [CAD_CAM_EDM_DRO] CNC UI (Virtual hand jive vs. conversational prgmmg)