On Mon, Sep 30, 2013 at 01:31:25PM -0400, Robert Ellenberg wrote: > 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.
I'm positive you don't want it in the interpreter itself, which already has a motion queue it uses when doing cutter compensation. But you may want it at the canon level, where canon calls (the SHOUTYCASE functions the interpreter calls) are translated into motion messages. At this level there is already a queue we call the naive cam detector (see emccanon.cc:chained_points/flush_segments), which combines segments that are colinear within a given tolerance into single lines (and a few other things). The main purpose of the NCD is to make maximum-length segments for the TP to digest. This NCD will certainly not be needed anymore when you are done, and you might find that you want to put some of your smarts in its place? It is not realtime code so it's a convenient spot to do difficult things. > 2) In the trajectory planner's tpAddLine and tpAddCircle functions (and > tpRunCycle, of course). The problem putting anything intensive here is you need the runtime to be predictable (capped, anyway), and ideally fairly constant. > #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) I agree with all these, at least as reasons to not add more complexity and queueing to the interpreter. I can imagine the TP looking ahead in the queue and examining the determinations/promises made by the canon level, the situation getting better and better as it fills up, with the tpRunCycle always being O(n) in the number of lines of lookahead. I have to think more about your questions regarding chunking, and how much information you will really need about future coming moves before you can even start. Ideally you'd start moving as soon as you get the first motion -- maybe at a suboptimal speed -- and then if motions queue up ahead of you you could speed up? Or you could maybe attach to the first move information about how many are coming up shortly? > 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. I still have not taken the time to make it through the examples in your paper... I hope to catch up soon. It would be great if you could pop in at freenode/#linuxcnc-devel. Chris ------------------------------------------------------------------------------ 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
