Re: EMC & Linux

Jon,

If you want to scan it I have an FTP server available to me that we could
put the images on.


Tim
[Denver, CO]

> -----Original Message-----
> From: Jon Elson [mailto:jmelson@...]
> Sent: Sunday, June 06, 1999 6:10 PM
> To: CAD_CAM_EDM_DRO@onelist.com
> Subject: Re: [CAD_CAM_EDM_DRO] EMC & Linux
>
>
> From: Jon Elson <jmelson@...>
>
>
>
> 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
>
>
> ------------------------------------------------------------------------
> How many communities do you think join ONElist each day?
> http://www.onelist.com
> More than 1,000! Create yours now!
> ------------------------------------------------------------------------
> welcome to CAD_CAM_EDM_DRO@..., an unmodulated list for
> the discussion of shop built systems in the above catagories.
>