John's original response contains two aspects: 1 -- A technical reason why that would not be consistent with the present design 2 -- An argument (made by some) why that would be a bad idea.
To add to this: 1 -- The interpreter reads the gcode and outputs canonical instructions to a queue that is executed in real time. To maintain the real time constraint, the interpreter runs ahead of the queue so that there a multiple (sometimes many) instructions in the queue. When the program is paused, the current instruction in the queue is completed (although that might not be true for some canned instructions). If the operator could manually jog, the current position would change, but the next instruction in the queue would be based on the previous location. Unless there was a way to guarantee that the machine was left in the same position, bad things would happen. One way to handle this might be to have a pause cause the interpreter to be reset back to the source of the next command in the queue, to discard the rest of the queue and be prepared to restart from there. The interpreter would also have to know where it is and something would have to cause the position to be reset to where it was prior to the jog. 2 -- So, is this really a good idea? Why does one want to pause and jog? A -- The tool is dull and we need to move to a new position and replace the tool with a sharp one. In that case, we might want to also touch off the new tool to measure it's length and also change the tool length in a tool table. B -- ? C -- ? I would suggest that a better way to do this might be to stop, change the tool, and continue the program from a particular line. Of course, continuing from a specified line isn't so easy now that we have loops and multiply nested subroutines. That's something that could be fixed, though, if someone wants to step up and do the work. It should probably be done as part of a complete interpreter rewrite. A straightforward task -- once there is a spec. Ken On Sat, Jan 16, 2016 at 2:03 PM, Les Newell <les.new...@fastmail.co.uk> wrote: > I have to agree with Norbert here. On my mill I mostly do one-offs. I > have jog wheels for each axis, making it possible to operate the machine > very much like a manual with DRO. For simple stuff like facing off or > squaring up an edge I'll use the jog wheels. If for instance I want to > drill a hole at an accurate position I'll use MDI to position X,Y then > the Z jog wheel to do the drilling. For more complicated jobs I'll spend > half my time using the jog wheels and half using MDI. With a bit of > practice this becomes a very fast way of producing one-off parts. Being > able to jog any time the interpreter is idle is one of the few reasons > why I still use Mach on my mill. > > My lathe runs EMC and I have a number of front panel buttons that run > snippets of g-code. I wrote a component to handle the buttons. If you > are in jog mode it switches to MDI, executes the code then switches back > to jog. That has worked well for years. > > Les > > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > -- Kenneth Lerman 55 Main Street Newtown, CT 06470 ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
