Hi All, As I'm looking into implementing lookahead, there seem to be a few places where the code could go:
1) In the interpreter, after tool-compensation processing. Having access to the queue of commands means that in principle we could calculate angles between moves, accelerations, etc. 2) In the trajectory planner's tpAddLine and tpAddCircle functions (and tpRunCycle, of course). #2 (withing the trajectory planner) seems like the better choice, at least for a first cut, for a few reasons: - The trajectory components reaching the planner already have tool compensation and machine state taken into account. If the processing was done in the interpreter, we'd have to search through the queue to find the previous move, which basically means redundant queue processing. - Blends and lookahead are just implementation details, from the perspective of the interpreter. - Often it won't be necessary to re-optimize the entire motion queue when adding a new TC. We only need to step backwards far enough to reach the peak speed. This means the computational burden might not be that bad (on average, at least) Of course, I could be missing something here, so please let me know if you see a reason to put lookahead code outside of the trajectory planner. Thanks! Rob ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
