Re: EMC & Linux

> From: Jon Elson <jmelson@...>
> This is the blending of moves. It can be a problem when you make an X
> move, then a Y move, as the Y move will start to ramp up when the X move
> just begins to ramp down. But, for a string of short continuous moves

describing

> a fluid curve, you need this, or the machine will absolutely CREEP. (My
> antique AB suffered from this.)
> Maybe we should ask Fred Proctor for some sort of switch (either in
> the RS-274 program (G-code) or on the user interface) to turn this
> on and off.

[There are other documents like the NCMS (National Center for Manufacturing
Sciences) Next Generation Controller Part programming Functional
Specification (RS274/NGC), which, unfortunately, only exist as paper
documents. This one is 127 pages and I have a Xerox which also has Tom
Kramer's handwritten notes in the margins regarding the inconsistencies in
the document. I'd scan it and html it if I had the time. I can't imagine how
long it would take to OCR it and then as slow as I type, we'll all be dead
before I could finish, plus, what do I do with Tom's handwritten notes?
Footnotes? Appendix?]

Paraphrasing NCMS:

G09 Exact Stop (Non-Modal) Causes an exact stop before the next move begins.
G61 Exact Stop Mode (Modal) Same as G09, except it doesn't affect rapid
moves.
G64 Contouring Mode (Modal) Default mode where the next move begins when the
previous move has reached a position within the "tolerance band" specified by
the machine builder. (I wonder where this tolerance is in the EMC, and how to
change it?)

Unfortunately, they don't seem to work. The reason for the blending in the
first place (as explained to me by Fred, and which I hope I remember
correctly) is that the heritage of the EMC is the robotics family, not the
machine tool control family. There are three variables involved in motion
control:

1. Desired Velocity (feed rate)
2. Maximum Acceleration Rate
3. Path Geometry

Imagine a tool path that goes along the X axis for a while, and then gently
radiuses into a Y axis move. In the servo systems I've worked on so far, at
machining feed rates it's no problem for the control to follow this toolpath
while keeping below the maximum acceleration limit. Now imagine the situation
that occurs at the end of a drilling cycle where we are rapidly pulling up
the Z axis to get the drill clear of the hole, and then we rapid in X and Y
to the next hole location. At the top of the Z travel we have to make a 90
degree corner at the rapid traverse rate. This move is definitely going to
exceed the maximum allowable acceleration rate. In robotics applications the
typical practice is to blend these motions together with a large enough
radius to limit the acceleration to an allowable rate while maintaining the
programmed feed rate. This is "exact velocity" mode. That's how the EMC works
now. As Jon points out, if you have a long series of short moves describing a
fluid curve, this is exactly what you want, because if you run in "exact
path" mode and come to a full stop before beginning the next move you will
gouge the surface and your mold or whatever will look like hell as well as
take forever to machine! However, I have experienced the problem of having a
drill broken off in a hole because X and Y started moving before the Z axis
had dragged the drill clear of the hole. This is definitely an "exact path"
operation! I believe Jon programs his drilling cycles by hand (or with one of
his nifty programs) without using the G8x series of canned cycles. I believe
his retract move is done as a feed move. What I have done to get around this
problem with rapid moves is to insert a dwell (G04) between the rapid moves
as shown in the skeleton program template at the end of this post. Another
workaround is to specify a retract level high enough off the top of the part
so that the drill is clear before blending occurs.

The immediate problem with all this is that the stepper guys (and that will
be me soon as well) have acceleration limits low enough that they are getting
blending at machining feed rates. This could cause there to be radiuses where
none are expected! Either they will need to hop up the hardware to allow
faster acceleration (higher supply voltage Tim?), or G61 needs to work, or
you need a dwell between every move (the other alternative of limiting the
feed rate isn't a good answer).

N5(SKELETON 00-00-00 1 filename, date, etc...)
(set up modal operators)
N10G17G20G40G49(XY plane select, inch mode, cancel diameter comp, cancel
length offset)
N15G54G80G94G98(coordinate system 1, cancel motion, feed/minute mode, initial
level return)
N20M48
(The next 3 lines probably aren't needed anymore, they fixed an old bug)
N25G91
N30G0X0Y0Z0
N35G90
N40G53G0Z0(retract quill)
N45X0.Y0.(move X and Y to the tool change position, change as required)
N50M05M09(spindle and coolant OFF!)
(display a message for the operator)
N55(MSG,LOAD TOOL #1)
N60M00(don't move until the operator presses the S key)
(clear the message line)
N65(MSG, )
N70T1M06G43H1(change to tool 1 and get its length from the tool table)
(start G0 lines with a .001 second pause to avoid motion blending problems)
N75G04P.001G0X1.0Y1.0S1000M3M8(rapid to the starting XY, spindle CW, coolant
ON, change as required)
N80G04P.001G0Z0.25(rapid to .25" above the part, change as required)
( )
(the program goes here, don't have blank lines)
( )
(PROGRAM END)
N980G0Z0.25(rapid to .25" above the part, change as required)
N985M05M09(spindle and coolant OFF!)
N990G53G0Z0(retract quill)
N995X0.Y0.(move X and Y to the tool change position, change as required)
N1000M2(end program)