> 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
