Robert, Chris - Am 30.09.2013 um 20:16 schrieb Chris Radek <[email protected]>:
> 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 yes, the interpreter is the wrong place there is also no point in making lookahead a rs274-only feature so the proper placement should be conceptually lower in the stack > 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. I think anything canon is the wrong place too, for several reasons: - there is likely interaction from the lower _into_ the upper half of the motion threads (for instance, an operation causing replanning like feed override), meaning lookahead planning and segment execution are rather tightly coupled - one cannot assume going forward the canon layer even resides in the same address space as motion.control, forcing such upcalls to become a _remote_ interaction; if the originator of the upcall is a kernel thread then the resulting structure is going to be a disgusting wart - at this point in time canon commands pass through task, bringing a third task into the equation and hence dependency I think canon should be viewed as an interface (API) into motion, but not part of any motion tasks proper; the reason why some functionality exists within canon which could be part of motion is more due to restrictions of the motion design, not because canon is such a great place to have that functionality in >> 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. That problem exists because of the way motion currently is structured, but this is just historic fact, not a hard constraint - functionally there is no hard RT requirement for the upper level motion handler (motion-command-handler) the problem goes away if the motion-command-handler part is restructured into user process - and there exist several components which do exactly that and show the principle: halstreamer, halsampler, classicladder which could be reapplied here as well the TP queue needs to be made thread-safe using standard techniques and the support to do that in RTAPI is in place; in fact the ubc3 code contains a lock-free queue as a first-class named HAL object which makes userland and kernel or user RT code cooperate perfectly fine and rather simple. One would have to study if this code can actually support the TP queue as it stands; it was intended to support the TP eventually, but some features might need to be added. there are several upsides to this overall approach: - a user process is infinitely easier to debug, and regression test. - any conceivable tool or library can be used. Need a linear programming package - well use it. Next to impossible in the current design. - multiple threads can be used if the design would suggest that. - the motion API moves to userland, and hence amenable to usage with stock userland IPC mechanisms, obviating the need for the current contortions to feed commands into motion. > >> #2 (withing the trajectory planner) seems like the better choice, at least >> for a first cut, for a few reasons: >> I would suggest to consider the design goal to be a multithreaded application of which one thread is hard RT, the other(s) are not, and spell out exactly what interthread communications requirements exist - shared queue access, variables, command/response scheme, whatever is needed then let us consider how these requirements can be mapped within the current environmental limitations; some of which can be changed, and some of might not even exist anymore. My biggest concern would be this: if you set out to do a strictly incremental improvement within the current motion design (a single RT component with two sequentially invoked RT thread handlers), then you will import the baggage of restrictions this structure implies. That in turn makes it likely some of the advanced code has to move to a less-than optimal place, and that has happened in the past. - Michael ------------------------------------------------------------------------------ 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
