@Chris, thank you so much for that comments, as I fully share your opinion. If I at least would know where to begin, I would try to change the MDI behavior, to allow jogging, but I am a GUI programmer without any experience in C++, so that will be a huge learning curve for me.
Norbert Am 16.01.2016 um 23:26 schrieb Chris Morley: > >> 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 > ------------------------------------------------------------------------------ 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
