Robert Ellenberg wrote :
>I agree, the motion / TP component now is doing work that doesn't have to
>be in real-time. Specifically, the queueing of motion commands and the
>lookahead optimization could be done in a user space component. You'd need
>a real-time safe queue structure to do it, but
>As for feedrate override, the TP adjusts the feed rate on the current move
>almost instantly. It's a scale factor applied to the target velocity, so it
>doesn't actually change the "planned" motion data, just how it executes.
>On Sonntag, 19. April 2020, 16:15:07 CEST Robert Ellenberg wrote:
On Sonntag, 19. April 2020, 15:46:36 CEST Juergen Gnoss wrote:
> Sure, there are some occasions where trajectory needs to be recalculated,
> even after they made it already to the part where actual iron gets moved.
I think, there is no need to recalculate motion path based on users feed-
override
I agree, the motion / TP component now is doing work that doesn't have to
be in real-time. Specifically, the queueing of motion commands and the
lookahead optimization could be done in a user space component. You'd need
a real-time safe queue structure to do it, but it would make the
optimization p
At the moment I'm on Reinhard's page thinking that TP has to be done i a
separate module
rather than going to happen in motion.
But maybe I doesn't see the full picture.
What are the key factors why TP actually happens in motion?
Sure, there are some occasions where trajectory needs to be recalcu
