Erik Christiansen wrote: > Jon, there's probably no need to do this backwards. Look-ahead only > needs to be simple look-ahead, nothing more, AIUI. The current velocity > (feedrate) is known, and the stopping distance for the machine at that > velocity is fixed. > > So, by summing immediately upcoming gcode path segments to a length a > little greater than the stopping distance, LinuxCNC can _safely_ > continue at full feedrate in the currently executing path segment if > there are no sharp bends or stops in the look-ahead "headlights" zone of > scanned path segments. If there's a sharp manoeuvre showing in the > headlights: drop feedrate below that gcoded for the executing segment, > according to the deceleration needed for the impending path deviation. > So the look-ahead is simple. > > If there's any complexity thus far, or need to do it backwards, then I'm > having trouble seeing it, and would appreciate enlightenment. > OK, the problem with looking "ahead" is that these blocks have not been interpreted yet. So, your description is a lot like mine, just standing at the other end of a buffer of some sort, and looking the opposite direction. But, when you are at some point in the G-code, you'd have to read and interpret the code going forward in the file by some distance, which is an arbitrary number of blocks. > The memory required to queue even a thousand coordinate points of a long > G1 path is so miniscule in relation to current RAM stick sizes, as to be > completely negligible, I think. > Yes.
Jon ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
