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.
Some other methods, like a fixed number of blocks might be easier to implement, and would improve on the current situation. For instance, adding just ONE single block more lookahead might increase speeds by a factor of TWO in the worst case. Of course, if you can do it for 2 blocks, it should be relatively easy to extend that to 10 blocks. By adding this to the naive cam detector, that might be enough to make many users happy. A 10-block lookahead seems like it would not take excessive CPU or memory resources, while the scheme described in the previous paragraph just might. 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
