gents, you are busily inventing path queueing mechanism number 3. The existing ones are: CRC offset curve aka queued_canon, and NCD aka chained_points.
Other ideas have been floating around like a circular buffer in front of motion so motions can be stepped back. If this goes on like discussed here, next time we look at the repo we'll have a grand total of 5 (*five*) path queuing mechanism in linuxcnc. Not sure whether this dog will not hunt. ok, path history (as opposed to gcode line history) is needed, and it is so for several features. I would encourage to think about, and architect a single path history mechanism, which in principle can support all of the so-far-implemented and considered features. IMO this requires reconsidering where some features are implemented, and face the fact that they might have to be moved. For instance, offsets, rotation, CRC, and NCD not necessarily have to be in the canon layer. Observe that all of the existing, and the proposed mechanism have to do with delaying binding decisions. -- I could imagine the following approach, the basic idea being to collapse all path history processing into a single mechanism, while at the same time delaying some decisions so they can be more easily reconsidered, for instance during pause (see below). - the interpreter/canon generates motions without actually applying offsets, CRC etc, but passes on the information needed to apply them later. - between task and motion is not a single queue, but two: -- a 'unbound queue' (actually a circular buffer) -- a binding thread which works on the unbound queue, records and applies offsets, CRC, does lookahead/correction as needed for NCD etc, and feeds commands into -- a 'bound queue' (also a circular buffer) - this is where move coordinates have their final values. -- motion works off the bound queue. re undoing (aka 'backing up the interpreter') - this relates to 'manual/MDI/jog while paused': changing offsets while paused: this amounts to finding, for a given bound queue entry active while pause was executed: - have the binding thread find the corresponding 'unbound queue' entry - change offset - throw away the bound queue, and reexecute the unbound queue with new offsets. changing tool while paused, which could change tool radius and hence the CRC offset curve: same trick: - find the corresponding 'unbound queue' entry - change tool properties - throw away the bound queue, and reexecute the unbound queue to generate a new CRC offset curve. MDI-while-paused: this could be doable as follows: - on pause, snapshot bound and unbound queues. - switch to a new instance of task and interpreter, which is synced to the current position. - 'MDI around' - when done, switch back to original task/interpreter instance, restore queue snapshots, then reexecute the unbound queue if some world model state changed, else continue on bound queue. Jogging back moves during pause: - apply commands in bound queue in reverse. This is just a rough sketch of a possible approach; I did not think through details like the reentry moves. I would also think the effort is considerable, and would not necessarily recommend grafting this onto the current code. But then it's time to start collecting ideas for Linuxcnc3. - Michael Am 22.04.2012 um 10:21 schrieb Erik Christiansen: > On 21.04.12 23:23, Jon Elson wrote: >> Viesturs Lācis wrote: >>> What I see the big issue for solving this in trajectory planner or >>> whatever _inside_ LinuxCNC is that I do not see, how to determine by >>> some hard facts, what is the best way to determine the lookup amount. >>> >> The number of blocks you need to look ahead is variable. The way I >> imagine it, you'd look ahead until you found a move that violates the >> requested speed due to acceleration. Then, you have to work backwards >> from that point to find out what block you need to begin slowing down >> at. > > 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. > > 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. > > Erik > > -- > Bumper sticker: Honk if you love peace and quiet. > > ------------------------------------------------------------------------------ > 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
