On 2/11/2012 11:13 PM, Erik Christiansen wrote: > Here's Brian's post, as it came through this end of the email pipe: > > » » » > Subject: Re: New dialects [Was: Do CAM instead? ] > > Yes, much more readable. The downside is that you can't do a "restart at > >> line" without specifying which iteration of the outer loop to restart >> from. And neither the GUIs nor the "runtime" support that. >> > For me, I simply go back to the oword call and rerun the particular > string. I am a hobbyist so its ok for it to cut air for several passes > until it gets back to the particular Z depth where it was stopped. > > Brian > « « « > > All of the first three lines of text are actually a quote of Kenneth > Lerman's prior post. So let's go with this understanding: > > On 11.02.12 11:57, BRIAN GLACKIN wrote: >> Before that, Kenneth Lerman wrote: >>> Yes, much more readable. The downside is that you can't do a "restart at >>> line" without specifying which iteration of the outer loop to restart >>> from. And neither the GUIs nor the "runtime" support that. >>> >> For me, I simply go back to the oword call and rerun the particular >> string. I am a hobbyist so its ok for it to cut air for several passes >> until it gets back to the particular Z depth where it was stopped. > I'll drink to that, if we're only talking about a few passes over a > short toolpath, on an amateur job. > > But there is a way to get the best of both worlds. A gcode filter > program can unroll e.g. a 20-iteration loop programmed in the input > source, so that it is passed on to LinuxCNC as 20 consecutive copies of > the loop, with individual values inserted for each run. The iteration > number can be added in comments, for good measure. Now we can "restart > at line", anywhere we choose, because AXIS isn't given any loops to deal > with. > > I haven't yet thought through exactly how much work it is, but unrolling > one loop (so there's one variable to increment and substitute) isn't too > bad, except for the trick of feeding the loop gcode back through the > filter again. One option is to just do it in the lexer, keeping > everything within a single process. (Fortunately, flex has a mechanism > we could use.) > > It is an interesting task, and if it is of significant use, then it's > something to add to the list of things to do. > > Erik > The right way to do it, though (IMHO), is for the system (including GUI and interpreter) to keep and display the call stack and history let you unwind at each level. Instead of looking at the linear sequence of lines that were executed, I should be able to look at the structure.
Just as a debugger lets me step into a subroutine or over a subroutine, I should be able to do this in a backwards direction from my GUI. Ken ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
