On Nov 6 2015 6:39 AM, Gene Heskett wrote: > On Friday 06 November 2015 04:53:15 andy pugh wrote: > >> On 6 November 2015 at 04:29, Fernand Veilleux >> <[email protected]> > wrote: >> > gcode is terrible IMHO. >> >> It's a terrible programming language, but then it was never intended >> to be one. > > I wouldn't condem it quite that vociferously. It has the basic trig > functions, all the basic control loop stuff, and several ways to do a > subroutine. My biggest and loudest bitch is the inability to > troubleshoot an errant arc move in a subroutine that may have 10 of > them > in it, it gets blamed on the line that calls the sub. I have had to > convert my blanket-chest code from 3 subroutines, to multiple copies > of > the subroutine but inline. In the process, I probably have 300 LOC > out > of 650 or so that are never executed. Its a horrible mess, but it > works.
So then the question is "how do we develop better debugging tools?" or at least analytic tools of the results? For example, I can see generating a little more output to go from the motion planner to the tool path display. If those lines and arcs had the program line number somehow associated with it, then you would be able to possible zoom in and ask a question about a specific line segment displayed. It would then tell you which line of code generated it. There might also be other metadata you want to associate with it (like depth of recursion or stack depth, ... hmmm... I do not know off the top of my head). If we did not provide analytics, then it would be good to be able to step into a subroutine to execute it as well as run a call. Last version of LCNC I used had *something* like this, but I do remember that it did not play well with subroutines. Not sure about the latest and greatest. What I am envisioning here is the GDB equivalent of motion control -- full variable querying and setting capabilities, and the ability to set break points and other useful functionality. Just a thought... now back to my normal programming... EBo -- ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
