Some good news on the feed override front: the latest changes allow feed overrides greater than 100% without having to sacrifice performance at 100%. It's a simple trick:
1. Scale the requested velocity up by the max feed override to calculate the blend arc radius (store this as the maxvel) 2. (Initially) cap the target velocity to the original requested velocity of the two line segments. This way, the arc's velocity is only capped if we can make a larger radius than needed for the 100% case. The downside of this method is that we always create arcs that are larger than necessary, and the actual radius will depend non-intuitively on the max feed override. Since this method is a trivial change over the simple case, I'd like to test this out and see how big a deal "oversize" blend arcs actually are. Here's a summary of the changes in the latest push: - Feed rate calculation as described above with hard-coded 200% max override estimate. - Reduced maximum velocity and acceleration for circular arcs during parabolic blending. The arc-arc.ngc example no longer violates acceleration limits as a result. The tradeoff is a modest performance hit in circular arcs with more favorable end conditions. - Lifted some overly conservative acceleration bounds for blend arcs and shortened segments - Revamped performance calculation that compares blend arcs vs. parabolic blends. This should result in less velocity ripple. - Fixed blend velocity calculation for parabolic blends. This tweak scales blend velocity for the current and next segment based on their maximum accelerations. The parabolic_test.ngc file shows more uniform blending compared to the current master. - Fixed status updating (again) so that stepping works properly in 90% of cases. I'm still getting some weird behavior with single-line programs, but "normal" code seems to work now. I'm in particular curious if anyone can find issues with the feed override behavior, especially with the blend arcs being too big (objectively or subjectively). If we don't have any major issues with this crude solution, it would save the trouble of doing replanning. -Rob On Mon, Nov 25, 2013 at 8:25 AM, sam sokolik <[email protected]> wrote: > heh - Siri like voice 'Recalculating route...' > > sam > > On 11/25/2013 4:41 AM, andy pugh wrote: > > On 21 November 2013 22:19, Robert Ellenberg <[email protected]> wrote: > > > >> Yeah, feed override needs more work. The current version should at a > >> minimum not fail under feed override, but it doesn't give optimal > behavior > >> either. > > > > I was randomly thinking about this the other day, and I wondered if this > > was an option: > > 1) Always allow for 120% override. > > 2) If the over-ride goes above 120% then re-calculate (possibly with a > > motion-stutter) to 120% of the new value. > > > > I can't decide whether you would want to re-calculate at 80% too[1] > > > > [1] Or 83.333% to be mathematically symmetrical > > > > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up > now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
