Daniel, I would say that you hit it right on the head here. I will add to it that CAM operators often are not quite aware of the relationship between accuracy of the cut and size of program / length of the individual segments. And so they have not set the CAM parameters optimally.
Michael is in deep thought at the moment. Something has stirred him . . . . . . . [?] cheers, j. On Fri, Aug 10, 2012 at 8:08 PM, Daniel Rogge <dro...@tormach.com> wrote: > > > I did some torture testing for a potential customer a long time ago. > > The test was a 2" > > circle of 10000 G01 moves. On a 600 MHz Pentium II (or would that have > > been a PIII?) > > I got some 780 blocks/second. I have no idea how much of that was due > > to the interpreter > > and how much in the trajectory planner. Also, it was not clear how much > > was due > > to raw processing speed and how much due to the 1-block lookahead. Much > > of this > > experiment was to see what the G64 Pxx could do for contouring work. > > > > Well, I think even a 3:1 slow down would not be a good thing, unless the > > interpreter > > is a TINY part of the total block processing time (which it may well be, > > I just don't > > know.) > > > Jon, > > The interpreter is nowhere near the bottleneck that the 1-block lookahead > is. To satisfy my own curiosity I wrote a 1000-line long program (1000 > lines is the default interpreter lookahead, set in emccfg.h) that started > with M3 S500, ended with S1000, and consisted solely of .01mm G0 moves. > Since active_settings[] lives in interpreter time, not motion time, the > displayed S word in the Active Gcodes field of Axis tells you when the > interpreter hits the S1000 line. It's nearly instantaneous - the > interpreter is at the end of the file before motion even starts. > > Previous posts have defended the one-block TP lookahead (or more properly > put, the requirement that the machine be able to come to a controlled stop > during any one move). Most defenders of the current TP point the blame at > cheap CAM for outputting small line segments instead of G2/G3. This doesn't > help moldmakers much, who by the nature of the part need small line segment > code. Furthermore as more CAM companies implement constant tool engagement > strategies we will see more and more small line segment code. The big > controls compete on the ability to handle small line segments - HAAS > charges an extra $2000 to go from 40 to 80 blocks of lookahead. While > bigger accelerations help ameliorate this lookahead restriction, they don't > fix the problem. I would love to see improvement in this area, but I'm > hesitant to dive into development until I have a better feel for the > underlying code. Michael seems to be intimate with this code after some of > his thought experiments with VPT - perhaps he would be willing to provide > an outline on he thinks it would take to change the TP to better handle > small line segment code. > > Rogge > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers >
<<B56.gif>>
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
