Daniel Rogge wrote: > > 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. > OK, a good data point. > 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. Well, clearly my torture test is a stupid program, a single G02 would have done a better job of the desired path. BUT, there are contour tasks, like depth-engraving a picture, where there will be constant tiny movement in one axis while another runs at a high constant speed. This is where the one-block lookahead falls down, the "scanning" axis should be able to run quite fast if the "engraving" axis is moving in very small increments. > This doesn't help moldmakers much, who by the nature of the part need small > line segment code. Exactly. > 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. > Right, I have neither the time nor the expertise to dig into this myself. I have a general concept of what the problem is. If it was all vectors, I think I might actually be able to code up something, but when you throw in arcs, tool offsets, acceleration, etc. it becomes a complex mathematical problem.
One approach I have mentioned, to no avail, was a CAM "trust me" option. An internal switch that defaults to the current scheme could be set to remove the stop on next block velocity limit, and assume the CAM will never order acceleration greater than the machine can handle. This would, of course, allow following errors or servo shutdowns if the CAM didn't obey the limits, but would allow higher speeds for this kind of contouring. Just a dirty way to get around the current TP limits. Jon ------------------------------------------------------------------------------ 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
