optimum value for planning ahead for a possible stop or maximum acceleration change: take current feed for current block and maximum possible accel of machine to get distance required for stop. then next N blocks that cover that distance, and apply appropriately modified feeds to them.
think of a gcode file as a matrix, each row would correspond to a block, the first several columns are all the various gcodes, the next several are all the various x1..xn axes, then several columns covering offset vectors, feeds, spindle, various Ms, etc. then just tack on another column that is the achievable feed. when file is loaded to controller, it gets scanned to fill in the values in the actual feetrate column. maybe there is another similar column for actual spindle speed that gets filled in similarly, in case it's being used like a c axis to get coordinated revolution. at program execution, the calculated realistic values columns are used to generate motion. soft program stops during execution may run out a few blocks. estops are an emergency situation, so who knows.. single stepping is usual one line check based on stop at end of block. are there not already some 'hidden' columns x1'..xn' that result from cutter radius compensation? i guess i'm thinking of linear programs, so in the case of loops and subroutine calls, the end result is a much longer list of actually executed blocks. maybe it never ends (= bad gcode). probing would also not fit the scheme very well - maybe consider probing blocks to be bounded in the code by stops? or, what if there were choices between more flavors of operation: advanced lookahead flavor would not allow nuts in it like conditional loops or surprise probings; crazy probe scanner routine mode wouldnt have the texture advantage of nice feedrate smoothness. --- On Sat, 4/21/12, Viesturs Lācis <[email protected]> wrote: > From: Viesturs Lācis <[email protected]> > Subject: Re: [Emc-users] Trajectory planning and other topics from a > EMC(LinuxCNC) newbie (TheNewbie) > To: "Enhanced Machine Controller (EMC)" <[email protected]> > Date: Saturday, April 21, 2012, 12:58 PM > 2012/4/21 Jon Elson <[email protected]>: > > > > The real problem I see is that RATIONAL G-code that was > correctly written to > > perform a particular operation cannot be executed as > fast as the machine and > > drives COULD allow it to go, due to the stop on next > block requirement. > > I agree. > 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. > Certain number of lines or a certain travel distance? Ok, > when the > method is chosen, how to determine, what is the optimum > value? > > That is why I am in favor of adding a separate filter, which > would > take the code and rephrase it to what is really in there - > either arcs > or splines/nurbs. In this case the file would be processed, > when > loaded (I have not really understood, when it would be > processed in > the first variant - also on loading or on the fly, when it > is > executed), so it definitely would not affect realtime > performance, > because the file would not be executed at that time. I think > that > waiting 10-20 seconds for the PC to recalculate the path and > find, > what curves would fit the existing profile, defined by tiny > G1s. > > Viesturs > > ------------------------------------------------------------------------------ > 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 > [email protected] > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
