Ok - initial testing. I ran spiral, splash, and 3d_chips. (the slow feeds that I was seeing on 3d_chips seems to be gone)
No constraint violations yet so far in all of them (I thought I was seeing violations in the splash screen before because of arc-arc but maybe I was smoking or it was actually something else.....) So - awesome!! nice work! For a comparison -3dchips with the original blending takes 4min 12 seconds - new takes 2min 11 seconds. -Full spiral takes 1 min 15 sec - new takes 23seconds. So - wow. Bad news . single block still isn't right - but it is better. when you pause the program - then click - run next line - it just runs till the end of the program. It looks like you have just optimized for 100% feed rate and don't allow anything higher. That seems like a good solution until the bugs are worked out. The programs so far seem to end normally with FO set to something like 200 also. Questions. -It looks like arc-arc you are falling back to parabolic blends. (I ran arcspiral.ngc and it runs exactly the same speed as the old tp) - is this something you hope to also tackle? (iirc it is on your list) -I don't have a way to test it right now - but I wonder how output control works now ie http://www.linuxcnc.org/docs/devel/html/gcode/m-code.html#sec:M62-M65 and http://www.linuxcnc.org/docs/devel/html/gcode/m-code.html#sec:M67-Analog-Output Again - nice work! sam On 11/22/2013 1:21 AM, Robert Ellenberg wrote: > That's unfortunately an issue with parabolic blends, so my fixes wouldn't > help there. I wouldn't hold back though, anything you can do to break it is > a good thing! > > > On Thu, Nov 21, 2013 at 10:00 PM, sam sokolik <[email protected]>wrote: > >> does this work arc-arc also - or should I stay away from those >> programs? (or did that get fixed with teh split-cycle method?) >> >> can't wait to bang on it >> >> thanks >> sam >> On 11/21/2013 04:19 PM, Robert Ellenberg wrote: >>> On Nov 19, 2013 12:18 PM, "sam sokolik" <[email protected]> wrote: >>>> Heh - Ok. I have been playing with it and the motion is a lot >>>> smoother. The velocity on the spiral is a strait line (used to be >>>> scaloped..) >>>> >>>> Couple more little issues.. :) >>>> On the spiral - if you pause it - then single block it. (try it - I >>>> dare you) ;) - it will take off in some random direction - or do a >>>> circle over and over. (kinda looks like the maybe the last blend move >>>> gets extended... ) Then when you take it out of single block - you get >>>> a large step change in acelleration/velocity as it goes to where it >>>> supposed to be instantly and continues on. >>> This should be fixed in the latest push. >>> >>>> I don't know how the feedrate override should act. I had mentioned that >>>> it didn't violate the constraints when I want to 120% - (its speed went >>>> up also 290ipm vs 350ipm. But then I thought - ok - so then I should be >>>> able to set the FO max to 100% in the ini and get 350ipm... but It >>>> doesn't - I still get 290ipm. (I was thinking it calculated worse case >>>> for the FO) So there must be some headroom in there. >>>> >>>> Ok - thinking out loud... I just set the FO in the ini to 200%. I was >>>> thinking I would break it being able to go over - but you have some sort >>>> of checking in there (more like the original planner) where it seems to >>>> stop at 350ipm and doesn't go over acceleration constraints. That is >>>> cool. Maybe you have 120% hard coded? huh? Do you? ;) >>>> >>>> Well - one more thing - setting the feed rate override to 200% cause the >>>> program not to end like before. (the motion ends but axis still thinks >>>> it is running the program - the play button is pushed.) ie.. >>>> http://imagebin.org/277887 Notice though - the constraints are >>>> obeyed... Yay >>> 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. If we can get to the point of there being no acceleration >>> violations under any circumstances, the next step is to improve the >>> override. I just don't want to build additional stuff on top of a buggy >>> base, then have to debug both at the same time. >>> >>> The good news is, I found a way to eliminate overshoot of trajectory >>> segments. Previous versions had a bunch of band-aid fixes to prevent >>> overshoot from causing too much damage, but made if very difficult to >>> control acceleration during tangent "joints". The new "split-cycle" >> method >>> uses the exact time that a segment ends, and updates the next one with >> the >>> difference. >>> >>> If you have some time, could you give it a quick sanity check? I don't >> need >>> exhaustive testing for another few days, but a quick check to see if you >>> can break it would be very helpful. Stepping, crazy feed overrides, >> spindle >>> start/stop, coolant, whatever you can think of to trip it up is fair >> game. >>> My goal is to get this on hardware ASAP. >>> >>> Thanks! >>> >>> Rob >>> >> ------------------------------------------------------------------------------ >>> 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 >>> >> >> >> ------------------------------------------------------------------------------ >> 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 >> > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ 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
