Re: EMC & Linux

Matt Shaver wrote:

> [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?]

I have this document, too. I could scan it, but it would have to be published
as an image. There is so much henscratching all over it, no OCR could
read the original printed text (which is wrong in many places, hence the
henscratches).

>
> 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.

Right, I was pretty sure from some email with Fred that this was a permanently
active feature, right now. There is no 'tolerance'. The next move starts as
soon as the deceleration of the current move begins. Since the deceleration
is a linear ramp at a fixed rate, if you slow the feedrate, the decel begins closer
to the end point. So, if this is a problem, you can program or override the
feedrate at these points to prevent rounded corners (or crashes!) where it
matters.

>
> 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

<snip>

> 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).
>

Well, I see it on my fairly responsive servo system, especially when I have
some non-cutting moves above 45 IPM.

Jon