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
