Re: EMC - M codes pause motion?

The catch with M codes is that the EIA standard only defines them as
being Miscellaneous function codes & their operating characteristics
are up to each manufacturer to determine.
-Dean


--- In CAD_CAM_EDM_DRO@yahoogroups.com, Alan Marconett KM6VV
<KM6VV@a...> wrote:

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