Hi Andy, On Dienstag, 31. März 2020, 17:59:13 CEST andy pugh wrote: > On Tue, 31 Mar 2020 at 16:07, Reinhard <reinha...@schwarzrot-design.de> > wrote: > > It's like a C-compiler which does (part) of the linkers job, but so bad, > > that lot of compilations units fail, as the compiler did not have compiled > > a necessary module yet. > > Sort-of. > > The scheme is to run ahead as far as possible to keep the motion queue > full. This is to allow blending of moves to keep the machine moving > smoothly (and within velocity and accel constraints, which are applied in > the realtime layer)
I know > The problem (which is normally quite a small one) is that the intepreter > state runs a long way ahead of machine state. No. I think the problem is not, that the interpreter reads to far ahead, but that the interpreter performs tasks, which it should not. > This should only matter when things go wrong.... Aborting G-code and > re-starting ought to be unusual behaviour. Well, the f-word handling, Chris is working on, shows that the problem occurs in quite normal gcode files and situations. I heavy use same tool for roughing and smoothing (HPC-cutters are so cute :) ) - only with different spindle speed and feed values. This usecase will fail with lc standard. So work needs to be done. Reinhard _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
