On Freitag, 10. April 2020, 06:50:24 CEST Amit Goradia wrote: > On Fri, 10 Apr, 2020, 7:53 am andy pugh, <bodge...@gmail.com> wrote: > > On Fri, 10 Apr 2020 at 03:13, Johannes Fassotte > > > > <johan...@automationassist.com> wrote: > > > No, I think that is covering up a problem instead of fixing the problem. > > > > And what do you think that problem is? > > The problem is restoring the current state after abort. For this the > interpreter needs to be synced with motion.
I guess, the real problem is, that the interpreter performs tasks it should not. Normally no sync between motion and interpreter is (or should be) needed. Motion should always know what command to execute and Taskmanager is the one to hold states and the like and prevent a close coupling between interpreter and motion. For cnc-workers it is quite common to abort execution of current gcode job. For a restart you have to decide, which lines to execute to get the machine in the right state to continue the job. That includes everything, that is not handled by default startup codes. The machine I work with has a simple minded cnc-controller, so I have to issue several commands with mdi-interface to setup the machine for restart. Than I select the lines from aborted gcode-job and execute them by single-step (afaik linuxcnc has no single-step command for arbitrary line number). When the interpreter is setup for the job to continue, I can press start button on the right line to continue. Any cnc-user should know, what to do, to restart an aborted job. I don't think, that's a challenge for automation - and its of cause no reason to blame the interpreter. Reinhard _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
