Dynomotion

Group: DynoMotion Message: 3201 From: fireup_kev Date: 1/18/2012
Subject: FeedOverride
Is there any way to make the feed override more responsive? It does not get updated until the current buffer gets flushed.

Thanks,
Kevin
Group: DynoMotion Message: 3205 From: Tom Kerekes Date: 1/19/2012
Subject: Re: FeedOverride
Hi Kevin,
 
No sorry haven't figured out a way to do that.  And we get asked that a lot :}  You can minimize it by setting the Windows lookahead to the minimum that will work reliably on your Windows.
 
The problem is that the trajectory planner runs on the PC and is very complicated planning through potentially hundreds of segments with many constraints which are all interactive so it doesn't lend itself well to run in real-time.
 
Wait.  Didn't you say you ported a simplified  version of the TP over to the DSP at one time?
 
Anyway we could offer feed rate reduction which like feedhold could be accomplished by ramping the rate of "time" down.  Unfortunately changing the rate of time not only scales the velocity but it changes the accelerations also.  So slowing down is sort of ok.  No max velocities are exceeded and accelerations just become sub-optimal.  But increasing the rate-of-time could easily violate max speeds and accelerations.  Speeds though tight curves would be too high.  In fact doubling the rate of time causes a 4X increase in acceleration (accelerates to 2x the speed in 1/2 the time).
 
In some cases (and probably most) it would work.  For example if you are cutting at a snail's pace along a straight line - although we might still fault when we come to the end because stopping distance increases 4X with speed.
 
So I can't find a practical solution.  It seems systems either have good trajectory planning with look-ahead or real-time feedrate changes, but not both.
 
My understanding of EMC2 is that it has real-time trajectory planning, but essentially no look ahead.
 
Any thoughts?
 
Regards
TK

Group: DynoMotion Message: 3211 From: fireup_kev Date: 1/19/2012
Subject: Re: FeedOverride
My Coord motion inside the DSP is working but not fully tested yet, not all features are implemented, and I still need to re-map the memory usage as it's currently overflowing out of Task7.

One other option I had was to port GCodeInterperter.cpp and all files related to it to an embedded system that has USB host and set lookahead to about 0.5 sec. Do you think this will be a do-able option?

Thanks,
Kevin
--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Kevin,
>  
> No sorry haven't figured out a way to do that.  And we get asked that a lot :}  You can minimize it by setting the Windows lookahead to the minimum that will work reliably on your Windows.
>  
> The problem is that the trajectory planner runs on the PC and is very complicated planning through potentially hundreds of segments with many constraints which are all interactive so it doesn't lend itself well to run in real-time.
>  
> Wait.  Didn't you say you ported a simplified  version of the TP over to the DSP at one time?
>  
> Anyway we could offer feed rate reduction which like feedhold could be accomplished by ramping the rate of "time" down.  Unfortunately changing the rate of time not only scales the velocity but it changes the accelerations also.  So slowing down is sort of ok.  No max velocities are exceeded and accelerations just become sub-optimal.  But increasing the rate-of-time could easily violate max speeds and accelerations.  Speeds though tight curves would be too high.  In fact doubling the rate of time causes a 4X increase in acceleration (accelerates to 2x the speed in 1/2 the time).
>  
> In some cases (and probably most) it would work.  For example if you are cutting at a snail's pace along a straight line - although we might still fault when we come to the end because stopping distance increases 4X with speed.
>  
> So I can't find a practical solution.  It seems systems either have good trajectory planning with look-ahead or real-time feedrate changes, but not both.
>  
> My understanding of EMC2 is that it has real-time trajectory planning, but essentially no look ahead.
>  
> Any thoughts?
>  
> Regards
> TK
>
> From: fireup_kev <kliboon@...>
> To: DynoMotion@yahoogroups.com
> Sent: Wednesday, January 18, 2012 11:55 PM
> Subject: [DynoMotion] FeedOverride
>
>
>  
> Is there any way to make the feed override more responsive? It does not get updated until the current buffer gets flushed.
>
> Thanks,
> Kevin
>
Group: DynoMotion Message: 3212 From: Tom Kerekes Date: 1/19/2012
Subject: Re: FeedOverride
Hi Kevin,
 
It should be easy to re-map the memory to the gather_buffer.  It should just involve using some pointers.
 
I don't know about the embedded system.  I'm sure it is possible but developing/debugging emmbedded code is much more time consuming than on a PC.
 
Regards
TK