Re: [Emc-developers] Best location for trajectory lookahead code

[Chris R. <ch...@ti...>]

On Mon, Sep 30, 2013 at 09:57:20PM +0200, Michael Haberler wrote:

> - 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

If you know the max feed override ahead of time, then changing feed
override does not have to require a re-plan.

If you require a re-plan when feed override changes, you will not
have instantaneous feed scaling, which is needed for at least EDM
(adaptive feed realtime input), and the way spindle-sync motion
works is a lot like feed scaling, too.

I think we are working under different assumptions.  Max feed
override of 120% is common on industrial machines, and it doesn't
seem like much of a burden to plan with your constraints at that
120%.  Then your planning remains valid no matter how the knob gets
turned, and in the usual 100% case the planning is only slightly
suboptimal.  If someone thinks they need max override of 500%, well,
that's a different story, but it feels like a misconfiguration to
me.  Currently only the UIs care about max feed override (because
the current planner doesn't ever violate constraints) but there's no
reason why the planner couldn't use this knowledge too.

> 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

I don't understand your objection.  What I call the canon level we
might instead call "the last nonrealtime layer before we send
messages to the first realtime layer" - that's a fine place to put
big calculations and I don't see why you think it's hard to link in
a library or whatever.

I do not understand why you are intent on breaking out part of
motion - either way there has to be message-receiving code, no??

> 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.

Sure but the upside of an incremental improvement is you don't
blossom the project into one of intractable size and give up, and
you may be able to get working code to users in short order.  I see
no sign that Robert is planning to make any of the structure worse.

If all your suggestions are predicated on feed override causing a
re-plan (and hence a whole new direction of communication) then I
understand where our thoughts diverge.  Robert - what do you think
about that specifically?

Chris