andy pugh wrote: > As I said earlier, I don't think this is a "Lookahead" problem, it is > a "must be able to stop inside the next code block" problem. > And I am not convinced that being able to stop the machine within the > next code block is necessarily a sensible requirement. > Exactly! It is a safe scheme, but becomes a limitation. Total lookahead is a boundless problem, so I can see that is not sensible. What I can imagine is a method of lookahead where each vector is examined for acceleration, and it keeps running ahead until a large acceleration would be required. Some kind of mark is made for that vector so the traj planner knows a deceleration would be required coming up on that point. Perhaps this accel scanning could put the mark back the required number of blocks so that when the traj planner hits that mark it begins the decel then. This all is complicated by the feedrate override that is implemented at the moment. But, the scanning could probably just assume 100% speed (or whatever the max override allows).
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
