let's discuss terminology for a minute (paths vs gcode segments) we have: 1. linear G-code programs (no oword control structures) 2. G-code with arbitrary control structures 3. Some other yet-to-be-invented language for machine control.
execution of any such program generates a path (sequence of moves), which is input to the trajectory planner. for 1), there's a fixed relation between program length and number of path elements, although it might not be 1:1 (eg because of cycles) for 2), this doesnt not hold in general because the execution flow cannot be determined without looking at variables driving the flow the same must be assumed for 3) as well. Cutter radius compensation (CRC), Naive CAM detection (NCD) and other 'lookeahead based features' must operate on the path, at least because of 2) and 3). So for these features the language really drops out of the picture (although it might supply parameters to drive operations on paths), which is why I used the term 'path history'. Any preprocessor-based solution to one of these problems also needs to generate the path, operate on it, and then regenerate matching G-code (which will be the fun part of any such venture). Hence 'lookahead' is a path-based, not a language-based concept. -- it might make sense in the context of the lookahead discussion to use a concept like 'path segment' to mean a sequence of moves which can be subject to some path-based operation; so a 'path segment of size 2' would imply 'possible lookahead 1'. For instance, the some operations are incompatible with CRC, which means the current path segment must end here. For example, a 'path segment end operation' is the FINISH() canon call in emccanon.cc, which ends a path segment of moves collapsed due to Naive CAM detection. Or 'dequeue_canones()' in interp_queue.cc which ends a path segment of moves which were subject to Cutter Radius Compensation (offset curve computation). - Michael Am 23.04.2012 um 06:12 schrieb Jon Elson: > 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 ------------------------------------------------------------------------------ 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
