> Date: Sat, 16 Jan 2016 14:49:23 -0500 > From: ler...@se-ltd.com > To: emc-developers@lists.sourceforge.net > Subject: Re: [Emc-developers] Why is it not allowed to jog in MDI mode? > > 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,
oops this is not what Norbert asked about, he wants to jog while the interp is idle. jog while paused would be a separate request. 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. > This jog-while-paused problem actually has a coded example of a solution. IIRC it used two queues - on for the auto moves one for jog while paused. Unfortunately the guy who coded it doesn't work here anymore... https://www.youtube.com/watch?v=2wabcOH9YAA We now also have move-off ? which is a good work around it seems. > 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. This seems to be a common linuxcnc position. We always seem to take the position that the user is trying to use the controller wrongly. The same was said about the trajectory look-ahead planner. The complaints of the planner were valid. The complaints about the PWJ are valid. I mean certainly talking about work-arounds is not a bad thing, or to define the actually problem so the best course can be taken is logical. Telling users that doing what works well for them all ready, is wrong..... 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 Again a valid but separate problem. I think the biggest barrier here is that there are no real docs, roadmaps or very many current and capable devs who are interested. If someone really documented the internals well, I am sure we would see new people take on some of these annoyances. In fact linuxcnc's modes seem a little outdated and hard to work with. AXIS does wonderful things to hide the details of mode switching. But this also makes it difficult to work with if trying to do something different then the developers thought. For instance setting the origin requires MDI mode but really is something usually done in manual mode. There is really no conceptual reason for this, all you really want to know is the machine is homed (which MDI guarantees so probably why required) I think that the motion controller should try to minimize any required modes and allow the GUI builder/integrator to decide what is allowed when. my 2 cents worth. Chris M ------------------------------------------------------------------------------ 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