So for feed override. I think just having the planner generate a blended path using the "max' override speed. thus guaranteeing that no constraints could be violated for any range of the feed override.
Otherwise you would need to regenerate the path based upon override speed as it changes thus the path would change as well (around blend points). I think that could be quite bad especially if your blending tolerances were set large (say for fast roughing passes). You boost up max override and all of a sudden your tool is running larger corners than it was prior and you break a tool. Naturally leading an operator to think "whoops too fast" when it may not have been the speed induced load that broke the toool but too much sudden overstepping. I think it would be prefered that the path remains identical at any feed speed. On Mon, Aug 23, 2021, 7:12 PM andy pugh <bodge...@gmail.com> wrote: > On Mon, 23 Aug 2021 at 21:27, andrew beck <andrewbeck0...@gmail.com> > wrote: > > > > Just had a look at tiny g looks great. > > I did try to implement a zero look-ahead finite jerk planner for laser > rastering. It was interesting, and I learned a bit. > > It is easier the less general you make it. > > Ideally LinuxCNC would have a 9-axis finite-jerk planner that handled > arbitrary kinematics with feed-override control. > > Tiny-G is a 3-axis (I think) planner with trivial kinematics and no > feed override (AFAIK). > > At the moment I would be happy just to see LinuxCNC handle more than > 3-axis blending. It's in Tormach. > > I have a feeling that kinematics is not a problem in most cases, the > kins functions run fast enough to be used for finite-difference > differentiation / numerical integration. > I am not sure about the more computationally intensive ones, such as > genserkins. (I think that is fast forwards, slow inverse) > > -- > atp > "A motorcycle is a bicycle with a pandemonium attachment and is > designed for the especial use of mechanical geniuses, daredevils and > lunatics." > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
