Re: Is this an unreported bug in EMC? (rant)

[Jon Elson <jmelson-at-artsci.wustl.edu>]

Ray Henry wrote:

> Clint
>
> It is probably a good idea to resist the two axis Keyboard impulse.  I did
> a little study a while back because I thought a keyboard emulator would be
> a good way to make an auxiliary control panel. The keyboard sends 11 bits
> when a key is pressed and 11 more when it is released.  These bits are an
> inverted and muddled asc code and they vary from one IBM "standard" to the
> next.

No, it is not ascii, at all.  It is an event code to tell whether it is a key
up, key
down, or other event, and then a binary code related to the position of the
key on the keyboard.  So, the S key is one higher than the A key, and the
D key is one higher than S, etc.  The shift, ctrl and alt keys are added on
by the interrupt handler as it recieves the 11 bit codes.

> Whomever thought this up is right up there with the creators of the y2k
> short sightedness. They never intended for two keys to be pressed at the
> same time. (we don't do that typing text)

Yes, it happens ALL the time.  It is such a problem that IBM Selectric
typewriters (the ones with the 'golf ball' print element) had a 5-character
buffer to keep up with this problem from fast typists.  Practically ALL
computer-style keyboards have at least 2-key rollover, and many have
n-key-rollover.

>  They had to add special routines
> for shift and the other modifiers.  So one press followed by another causes
> the end codes to get mixed.

Yes, this seems to be a problem, possibly having to do with overloaded
8-bit micros in the keyboard.

> Add to this the fact that the keyboard interpreter chip on the mb dumps
> stuff it doesn't understand and requests a re-send and you have the makings
> of a whole disaster.

I've never heard of this.  As far as I know, once a keystroke has been
sent from the keyboard, it is gone, and if the keyboard controller on
the MB loses it, there is no way to ask the keyboard to send it again.

> We could pretty easily cook up a tkemc that had an array of buttons that
> would let you press one and get two motions.

How about a physical device that does that?  There are chips and little
boards that you can buy, that either generate unique scan codes for some
number of buttons, or can be programmed to transmit an arbitrary
keystroke sequence for each button.  You hook these between the
keyboard and the motherboard.

A joystick (but the regular PC joystick is totally inadequate) however,
at least all analog servo users have unused A/D channels on their
STG boards.

Also, a jog dial with an encoder would be real nice.

> Perhaps a popup. Some games do
> this with the num pad.  I'm playing with this for a touch screen (also a
> serial imput device) but decided quite a while ago, after a nasty crash,
> that I would abandon the keyboard for machine control.

Yes, I've had a few crashes, too.  I even brought a boring head down on
two fingers, once.  But, it was MY fault, not the computer's.  I hit the
wrong button.

> I wrote stkemc (a tcltk exercise) with a single row of buttons that I
> access with the mouse.  It's a bit slower but I don't make mistakes. This
> also means that I use mdi for those long multi axis moves. (g0 x21 y8 z-5)
>
> IMO the stock emc gui's really aren't intended for hard core shop floor
> work.  They are optimized for the flexibility and detail that the emc group
> needs to develop and test emc itself.  One of the first tasks of the
> emc_gui committee, (see other rant) beyond bug fixes, should be the
> specification and development of some shop hardened hmi's that take account
> of the ways operators make their production quantities and maintenence folk
> check out, service, and tune machines.

I've done quite a bit of work with the Xemc gui, and pretty much got used to
it.  There are a few small quibbles I have with it, but I could really live
with
it, even if it never changes.  (I do want an extra axis, though.)

But, of course, there are a lot of things that could be added, I've mentioned
a few above.

But, there is so much stuff that is already IN the gui's that needs fixing.
The
business where the status line shows a mixture of info that is related to the
current state of the machine (like G codes in force) and info that is related
to the current state of the interpreter (which has run to the end of the file
in most cases - like feed rate).  The Allen-Bradley 7320 displays instantaneous

feed rate at all times.  If you turn the feed rate override, the display
reflects
that.  It even changes as a move is ramping up or down in speed (don't
think we need that, anyway the AB updated the screen at 100 Hz, and we
won't be.)

There is the business that when you e-stop, crash or abort the program, the
display goes back to the top of the program, so you lose your place where
the problem was.  All other CNC's hold your place, so you can resume
from the place you stopped.  They also allow you to back up a few lines
and resume from there at the touch of a button.  My old Allen-Bradley
7320 also had 'jog retract', which allows you to stop a program, even in
the middle of an interpolated move, select one axis and jog it (perhaps to
check or replace a tool), and then resume the operation from where you
left off.  (It reversed the jog movement before resuming the interrupted
move.)

On the other hand, the feature where EMC reads through the program from
the beginning, so that the machine is at the right place, and the interpreter
is in the right state, to start a program from the middle, is pretty neat.

Oh, one other thing I wanted, but I don't think has been done, is to be
able to enter more than one block in MDI at one time, and then release
all of them at once.  On the AB 7320, there is an end of block character,
they use the '#', and a 'transmit' character, they use ']'.
If you just want to move several axes at once, you could say :
X1.23 Y4.56 Z-0.5 #]
and all 3 axes would interpolate to that point.  But, if you entered :
X1.23 # Y4.56 # z-0.5 #]
it would move the X to 1.23, then move the Y to 4.56, then finally the
Z axis would move.  I used this for cleaning up edges and such, with
something like :
Y-.04 # X10.5 F10 # Y0 F45 # X0 #]
This would move in in Y, make a cutting pass in X, back Y away, and then
rapidly return to X0.  With the ability to edit the MDI buffer, you could just
edit that first Y coordinate and re-execute the command until the surface
has been fully cleaned up.  This seems like a relatively straightforward
change.
Any thoughts?  The # char should be able to be used as the separator, I don't
think it has any use in RS-274D, except in comments.  Forget the ']' char,
that was like the enter key on the AB.

There are a few more little quibbles on TkEmc, where it broke things I
was used to in Xemc.  One is that the error dialog boxes and open file
dialog boxes come up outside the main window, often off the viewable
part of the screen.  (I use a larger virtual screen of 1024 x 768, with a
viewable 800 x 600 most of the time.)

One other little one is that the default path for program files in the .ini
file is not used, so you have to type the /usr/... path everytime you start
TkEmc.  Very minor one, there.

The 'End' key doesn't work, and if somebody did that on purpose, that
is fine, as it was sort of dangerous having that right next to the page up
and down.

Thanks,

Jon