On Samstag, 18. April 2020, 22:15:11 CEST Chris Morley wrote: > On 2020-04-18 8:27 a.m., Reinhard wrote: > > On Samstag, 18. April 2020, 17:15:48 CEST Robert Ellenberg wrote: > >> Reinhard, I strongly recommend using G10 for this because the NML command > >> doesn't update the offsets in interp. This would cause subsequent motions > >> to have the wrong offset values, and get the machine into an inconsistent > >> state. > > > > Puh - the interpreter is getting from bad to worse :( > > This actually makes sense to me, the interpreter is what defines offsets
Even if that was right, it makes no sense at all! The interpreter does lot of tasks it should not, so that misconception is source of all evil. May be you are willing to think about a redesign once 2.8 is done. Then ideas like proposal of Juergen Gnos could be realized: On Mittwoch, 15. April 2020, 15:24:11 CEST Juergen Gnoss wrote: > My idea is, sorting out the g-code interpreter and make it loadable modules, > where we choose at configuration level what machine we like to have. Just > as with kinematic module ... On Samstag, 18. April 2020, 22:15:11 CEST Chris Morley wrote: > The motion component only runs raw motion commands. Well, neither the interpreter, nor motion should care about offsets! In my way of thinking, interpreters job is to validate textual G-code from users and transform that into a binary command. Thinking in a pluggable concept, interpreter should be done at nml-command level, so output of interpreter should be the same as internal sent nml- command. Its then the job of the task-manager (or whatever you name the central intelligence), to care for all the logic, which ends in "simple" commands to motion and io. If responsability is new thought and redistributed, no line-number or g- or m- code will get lost during execution, and single step versus auto execution determines just the depth of motion-queue optimization. > Is there a reason we can't allow G10 in manual mode? As long as the > machine is homed I can't think of a reason. Because I agree switching to > MDI/AUTO to do manual things is annoying and there is lots of this done > in the screens. It's a major PITA to manage mode changes in screens. > > I'm thinking the whole MAN/MDI/AUTO mode process should be evaluated. Well, together with rethinking the interpreter this would make lot of sense. > ... why do we need the interpreter to decide what can and can't be done. Exactly what I think. Reinhard _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
