Re: [CAD_CAM_EDM_DRO] Re: EMC - M codes pause motion?

Hi Dean,

Yes indeed, the interpreter INTENTIONALLY delays where needed. Another
example is in the drill cycles, where a G82 or G83 (and others) dwell at
the full depth if the cycle. for example, my 'C' code calls a delay
function (watches clock ticks) for the prescribed amount of time.

Alan KM6VV


foxprints2003 wrote:

>
> --- In CAD_CAM_EDM_DRO@yahoogroups.com, Jon Elson <elson@p...> wrote:
> >
> >
> > foxprints2003 wrote:
> >
> > >In EMC m-codes cause the interpreter to pause motion, example:
> > >
> > >g02x30y30i30j0f300
> > >g02x0y0i0j-30m7(or m8,m3,m4 etc.)
> > >EMC executes 1 quadrant arc, pauses motion, turns on M code
> output,
> > >resumes motion to complete arc.
> > >If the M code is removed the motion is executed seamlessly.
> > >
> > >I need to be able to turn outputs on/off on-the-fly, Is it
> possible
> > >to setup EMC to allow M code output on-the-fly?
> > >
> > >
> > M03, M04 and M05 are spindle start and stop commands, and there is
> > a built-in delay (specified in the .ini file) that stops activity
> > waiting for
> > the spindle to come up to speed, or brake to a stop. It makes
> perfect
> > sense in machine tool applications to have a delay here. Reducing
> the
> > delay specified in the .ini file should make it shorter, but I
> don't know
> > how short it can be.
> >
> > M07, M08 andd M09 are coolant on/off commands, and it seems
> reasonable
> > that a delay is not always needed there. I think the problem may
> be
> > related to
> > the fact that the auxilliary I/O is handled in the Linux part of
> EMC, while
> > motion is done by the real-time part. I suspect that the pause is
> when
> > these
> > two parts are synchronizing for these operations.
> >
> > Jon
>
> This must be done by the interpreter because the pause is not due to
> lack of processing speed, the system decelerates to a stop turns on
> the output immediately after stopping & then accelerates back into
> the next move. Clearly the system planned the stop due to the m code
> insertion. I can't imagine turning on a single discrete output would
> require nearly as much processing time as anything else.
> -Dean
>