Re: [Emc-users] jerk control
On Sunday 29 August 2021 14:54:12 Rob C wrote: > any interest / help > > https://www.pmdcorp.com/resources/type/articles/get/mathematics-of-mot >ion-control-profiles-article > Figure 4 of that link largely describes linuxcnc current reversal profile if a second inverted waveform is assumed at a direction reversal. This is near ideal for steppers because they have max accel available at zero speed. But this, applied to a spindle motor where there may be instant power for accel thats several times the equivalent of its steady state capabilities, can very easily exceed the ability of a stepper moveing a 30+ pound sled for Z motion, at well beyond its ability to keep up. I reasoned that a limit3 placed in front of the pid command pin would if grounded at its input, ramp the spindle motor down to a much more gentle stop, So when motion issues the reversal, and a mux2 as a sample-hold compares the old direction with the new, finds it miss-matched, blocks the reversal and grounds the limit3's input, the pid then ramps the spindle to near zero speed, with zero speed being detected by a oneshot watching an encoder leg. When zero, as defined by the oneshot recovering, occurs, the new direction signal is allowed thru to the pwm-servo, the ground on the limit3 is released, and the pid then ramps the spindle back to the set speed. So the turnaround is slowed enough there is no z following error, yet its back to the set speed in under 400 milliseconds turning the opposite direction. Having a tail on both ends of the curve would be even nicer as the waveform would better resemble a test signal we used heavily back in NTSC days and which litterally tests the absolute bandwidth and sharpness that an NTSC transmitter could manage, yet remain within its assigned channel. Unforch, the limit3 can only shape the tail, but its enough to help considerably. The relatively quick ramp up after the reversal puts that "jerk" at a speed where the stepper has maximum torque and can keep up. I would have experimented with both maxa and maxv to optimize it even better, but halscope, without a base thread, simply isn't fast enough to show it well enough to define "best". I'd have to setup a 100 u-sec base thread and put all that stuff in it to begin to see it in real time. This is not ideal, and its only one signal, but it does the job. > On Sun, 29 Aug 2021, 18:40 Chris Albertson, > > > wrote: > > In the general case there may be no closed form solution so numeric > > integration is the only possible solution.I don't think there is > > any other way to do it other than numeric integration except to > > require the user to supply a function for closed form integrals. > > But for a 3-axis mill that uses trivial kinematics there is an easy > > closed form integral. So the problem is very different depending on > > what kind of machine you want to control.For people here, almost > > all are using trivial kinematics. > > > > The problem is also VERY different based on another decision. Do > > you want only simple jerk limiting or do you want an optimal path? > > In other words, do you simply take your foot off the gas to avoid > > going over the speed limit or do you want to drive to work in the > > absolute minimum time but without speeding. Those are different > > problems. The first one is easy to do, the second takes quite a lot > > of effort. > > > > Jerk limited, optimal paths for non trivial kinematics is a very > > hard problem. Putting a simple jerk limit on a simple machine is > > easy, Marlin does this on my 3D printer and it runs on an Aruino. > > > > On Sun, Aug 29, 2021 at 10:07 AM Curtis Dutton wrote: > > > I'm not sure about all this yet, brainstorming here... > > > > > > After looking at TinyG code for handling jerk limitation in the > > > joint control it appears that they are using the forward physics > > > equations and numerically integrating to avoid violations. > > > > > > Since numerical integration needs to be used for jerk equations > > > (as well > > > > as > > > > > snap crackle and pop...) The forward kinematic equations will > > > need to be fed into the integrator for non trivial kinematics. > > > > > > The integrator should be pluggable as well. We should find an open > > > source library for this as numerical integration methods are > > > always advancing > > > > and > > > > > high performance integration is not easy to implement. > > > > > > On Sun, Aug 29, 2021 at 11:55 AM Andy Pugh wrote: > > > > > On 29 Aug 2021, at 11:40, Alexander Brock > > > > > > > > > > > > wrote: > > > > > The idea can be implemented in C and for simple cases like 1D > > > > funktions > > > > > > > it should be fairly straight-forward. > > > > > > > > My point is that the kinematics modules already exist, and not > > > > all of them are under our control. Various users’ machines are > > > > out there with their own custom kinematics. > > > > Also, AFAIK if they are kernel
Re: [Emc-users] jerk control
any interest / help https://www.pmdcorp.com/resources/type/articles/get/mathematics-of-motion-control-profiles-article On Sun, 29 Aug 2021, 18:40 Chris Albertson, wrote: > In the general case there may be no closed form solution so numeric > integration is the only possible solution.I don't think there is any > other way to do it other than numeric integration except to require the > user to supply a function for closed form integrals. But for a 3-axis > mill that uses trivial kinematics there is an easy closed form integral. > So the problem is very different depending on what kind of machine you want > to control.For people here, almost all are using trivial kinematics. > > The problem is also VERY different based on another decision. Do you want > only simple jerk limiting or do you want an optimal path? In other words, > do you simply take your foot off the gas to avoid going over the speed > limit or do you want to drive to work in the absolute minimum time but > without speeding. Those are different problems. The first one is easy to > do, the second takes quite a lot of effort. > > Jerk limited, optimal paths for non trivial kinematics is a very hard > problem. Putting a simple jerk limit on a simple machine is easy, Marlin > does this on my 3D printer and it runs on an Aruino. > > > > > On Sun, Aug 29, 2021 at 10:07 AM Curtis Dutton wrote: > > > I'm not sure about all this yet, brainstorming here... > > > > After looking at TinyG code for handling jerk limitation in the joint > > control it appears that they are using the forward physics equations and > > numerically integrating to avoid violations. > > > > Since numerical integration needs to be used for jerk equations (as well > as > > snap crackle and pop...) The forward kinematic equations will need to be > > fed into the integrator for non trivial kinematics. > > > > The integrator should be pluggable as well. We should find an open source > > library for this as numerical integration methods are always advancing > and > > high performance integration is not easy to implement. > > > > > > > > > > > > On Sun, Aug 29, 2021 at 11:55 AM Andy Pugh wrote: > > > > > > > > > > > > On 29 Aug 2021, at 11:40, Alexander Brock > > > > wrote: > > > > > > > > The idea can be implemented in C and for simple cases like 1D > funktions > > > > it should be fairly straight-forward. > > > > > > My point is that the kinematics modules already exist, and not all of > > > them are under our control. Various users’ machines are out there with > > > their own custom kinematics. > > > Also, AFAIK if they are kernel modules then they have to be written in > C. > > > > > > Hence my suggestion of calling the kinematics function repeatedly to > > > perform simple numerical differentiation. > > > > > > > > > > > > ___ > > > 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 > > > > > -- > > Chris Albertson > Redondo Beach, California > > ___ > 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
Re: [Emc-users] jerk control
In the general case there may be no closed form solution so numeric integration is the only possible solution.I don't think there is any other way to do it other than numeric integration except to require the user to supply a function for closed form integrals. But for a 3-axis mill that uses trivial kinematics there is an easy closed form integral. So the problem is very different depending on what kind of machine you want to control.For people here, almost all are using trivial kinematics. The problem is also VERY different based on another decision. Do you want only simple jerk limiting or do you want an optimal path? In other words, do you simply take your foot off the gas to avoid going over the speed limit or do you want to drive to work in the absolute minimum time but without speeding. Those are different problems. The first one is easy to do, the second takes quite a lot of effort. Jerk limited, optimal paths for non trivial kinematics is a very hard problem. Putting a simple jerk limit on a simple machine is easy, Marlin does this on my 3D printer and it runs on an Aruino. On Sun, Aug 29, 2021 at 10:07 AM Curtis Dutton wrote: > I'm not sure about all this yet, brainstorming here... > > After looking at TinyG code for handling jerk limitation in the joint > control it appears that they are using the forward physics equations and > numerically integrating to avoid violations. > > Since numerical integration needs to be used for jerk equations (as well as > snap crackle and pop...) The forward kinematic equations will need to be > fed into the integrator for non trivial kinematics. > > The integrator should be pluggable as well. We should find an open source > library for this as numerical integration methods are always advancing and > high performance integration is not easy to implement. > > > > > > On Sun, Aug 29, 2021 at 11:55 AM Andy Pugh wrote: > > > > > > > > On 29 Aug 2021, at 11:40, Alexander Brock > > wrote: > > > > > > The idea can be implemented in C and for simple cases like 1D funktions > > > it should be fairly straight-forward. > > > > My point is that the kinematics modules already exist, and not all of > > them are under our control. Various users’ machines are out there with > > their own custom kinematics. > > Also, AFAIK if they are kernel modules then they have to be written in C. > > > > Hence my suggestion of calling the kinematics function repeatedly to > > perform simple numerical differentiation. > > > > > > > > ___ > > 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 > -- Chris Albertson Redondo Beach, California ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
I'm not sure about all this yet, brainstorming here... After looking at TinyG code for handling jerk limitation in the joint control it appears that they are using the forward physics equations and numerically integrating to avoid violations. Since numerical integration needs to be used for jerk equations (as well as snap crackle and pop...) The forward kinematic equations will need to be fed into the integrator for non trivial kinematics. The integrator should be pluggable as well. We should find an open source library for this as numerical integration methods are always advancing and high performance integration is not easy to implement. On Sun, Aug 29, 2021 at 11:55 AM Andy Pugh wrote: > > > > On 29 Aug 2021, at 11:40, Alexander Brock > wrote: > > > > The idea can be implemented in C and for simple cases like 1D funktions > > it should be fairly straight-forward. > > My point is that the kinematics modules already exist, and not all of > them are under our control. Various users’ machines are out there with > their own custom kinematics. > Also, AFAIK if they are kernel modules then they have to be written in C. > > Hence my suggestion of calling the kinematics function repeatedly to > perform simple numerical differentiation. > > > > ___ > 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
Re: [Emc-users] jerk control
> On 29 Aug 2021, at 11:40, Alexander Brock wrote: > > The idea can be implemented in C and for simple cases like 1D funktions > it should be fairly straight-forward. My point is that the kinematics modules already exist, and not all of them are under our control. Various users’ machines are out there with their own custom kinematics. Also, AFAIK if they are kernel modules then they have to be written in C. Hence my suggestion of calling the kinematics function repeatedly to perform simple numerical differentiation. ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
On 8/26/21 10:38 AM, andy pugh wrote: > On Thu, 26 Aug 2021 at 00:34, Alexander Brock > wrote: > >> There is an elegant way to compute exact derivatives without computing >> analytical derivatives by hand. Here is a nice introduction: > > Is that applicable to the LinuxCNC kinematics functions? (Which are > kernel modules written in C). The idea can be implemented in C and for simple cases like 1D funktions it should be fairly straight-forward. The beauty with C++ is having templates and operator overloading so the kinematic function needs to implemented only once and can then be used for all datatypes (double, Jet). Also, operator overloading makes code more readable, for example in C++ I could write (random example): x = cos(4*t) + 2*t*t + 9 and it works with Jet but in C that would probably translate to something like x = sum(cos(product(4,t)), product(2,t,t), 9) I'm using C++ 99.99% of the time so if I would be tasked with providing derivatives in a C program I would try to make some kind of library / module where I just use C++ for the actual computations but I don't know how that would work or what the downsides would be. Best Regards, Alexander ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
The software in the link below is very widely used in industry. It is used inside MoveIt which in turn is driving many complex machines. https://moveit.ros.org On Fri, Aug 27, 2021 at 11:52 AM Curtis Dutton wrote: > That thread leads to this. https://githubhelp.com/pantor/ruckig > -- Chris Albertson Redondo Beach, California ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
That thread leads to this. https://githubhelp.com/pantor/ruckig Pretty interdasting! On Fri, Aug 27, 2021 at 12:36 PM Andy Pugh wrote: > > >> It will require jerk limiting to really get the value out of the > machine. > > There is a jerk-limiting component in the forum > > > https://forum.linuxcnc.org/47-hal-examples/43401-hal-s-curve-component-for-download-loadrt-dofs-x > > It sacrifices path accuracy for jerk limitation (or so I assume) but would > allow folk to see what difference it makes. > > > ___ > 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
Re: [Emc-users] jerk control
>> It will require jerk limiting to really get the value out of the machine. There is a jerk-limiting component in the forum https://forum.linuxcnc.org/47-hal-examples/43401-hal-s-curve-component-for-download-loadrt-dofs-x It sacrifices path accuracy for jerk limitation (or so I assume) but would allow folk to see what difference it makes. ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
how is everyone working out jerk / jolt? on a stepper motor you have a defined step or micro step (distance) so if your acceleration is say 3000mm/s/s. (plasma cutter) and you are driving a 20T mod 1 rack and pinion with a 3:1 ratio drive, with a 200 step per rev stepper motor on 10uSteps the distance traveled per step is 0.01047197551 mm at 3000mm/s/s, the time that it takes from zero to the first step is sqroot ( 2x distance / acceleration) = 0.0026422182 seconds the jerk / jolt is therefore (acceleration X time for first step) >>> 3000 X 0.0026422182 = 7.92 mm/s/s/s without the 3:1 ratio drive reduction, the jolt or jerk is 13.72 mm/s/s/s. (or 1.73x greater than without a 3:1 ratio drive I used to have my same machine set up with a direct htd 5m 20T belt drive (ie each microstep was 0.05mm), with the same acceleration, the jolt or jerk was 17.32 mm/s/s/s. although the belts were rubber and no doubt some compression of the teeth and movement in the belts took place Firstly I am trying to check my math is correct? On Thu, 26 Aug 2021, 09:44 andy pugh, wrote: > On Thu, 26 Aug 2021 at 00:34, Alexander Brock > wrote: > > > There is an elegant way to compute exact derivatives without computing > > analytical derivatives by hand. Here is a nice introduction: > > Is that applicable to the LinuxCNC kinematics functions? (Which are > kernel modules written in C). > > -- > 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
Re: [Emc-users] jerk control
On Thu, 26 Aug 2021 at 00:34, Alexander Brock wrote: > There is an elegant way to compute exact derivatives without computing > analytical derivatives by hand. Here is a nice introduction: Is that applicable to the LinuxCNC kinematics functions? (Which are kernel modules written in C). -- 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
Re: [Emc-users] jerk control
On 8/24/21 1:08 AM, andy pugh wrote: > 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. There is an elegant way to compute exact derivatives without computing analytical derivatives by hand. Here is a nice introduction: http://ceres-solver.org/automatic_derivatives.html#chapter-automatic-derivatives Best Regards, Alexander ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
Well I have two high speed CNC machines.. But they are all analog control. Probably no good for tinyg On Thu, 26 Aug 2021, 04:12 dave engvall, wrote: > IIRC emc was conceived as a vehicle to test intercommunication between > processes and as such higher level features such as lookahead, > smoothing, etc were not part of the master plan. In fact emc would not > have had stepping if Matt Shaver had not requested it. > > Now on to the real subject of this email. Is there a user that has the > resources to test linuxcnc vs tiny g for smoothness vis a vis jerk. I > suspect that tiny g does not have integrated tools to do this so simply > milling under extreme conditions may be the only way to access the > utility of its jerk component. > Ideas, comments. > Ray Henry used to talk about tuning by milling before we had good tools > in emc. It could also be that he was dealing with analog controls. ;-) > > Dave > > On 8/23/21 5:51 PM, andrew beck wrote: > > Andy do you know what the tormach uses for more than 3 axis path > blending? > > > > > > > > On Tue, Aug 24, 2021, 11:11 AM andy pugh wrote: > > > >> On Mon, 23 Aug 2021 at 21:27, andrew beck > >> 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 > > > > ___ > 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
Re: [Emc-users] jerk control
So for an abort I think would be still following the proscribed machine path in a coordinated fashion but stop as fast as possible within constraints. Sort of like dragging feed override to 0 as quickly as possible without violating constraints. For an e-stop it will be an uncoordinated stop. Each joint will halt as quickly as possible independently while still obeying joint constraints. I think that jerk limit will apply for all joint and cartesian space. On Mon, Aug 23, 2021 at 4:54 AM andy pugh wrote: > On Mon, 23 Aug 2021 at 04:40, Chris Albertson > wrote: > > > Actually for a machine tool, why not run the > > simulation off-line and use as much time and computer power as it takes. > > Feed-override? > > Do you allow infinite jerk on abort? You might think that is an easy > question, except that continuous jog is implemented as a move to the > limit that is aborted on key release. > > And, do we need to jerk-limit in joint space or cartesian space, or both? > > -- > 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
Re: [Emc-users] jerk control
IIRC emc was conceived as a vehicle to test intercommunication between processes and as such higher level features such as lookahead, smoothing, etc were not part of the master plan. In fact emc would not have had stepping if Matt Shaver had not requested it. Now on to the real subject of this email. Is there a user that has the resources to test linuxcnc vs tiny g for smoothness vis a vis jerk. I suspect that tiny g does not have integrated tools to do this so simply milling under extreme conditions may be the only way to access the utility of its jerk component. Ideas, comments. Ray Henry used to talk about tuning by milling before we had good tools in emc. It could also be that he was dealing with analog controls. ;-) Dave On 8/23/21 5:51 PM, andrew beck wrote: Andy do you know what the tormach uses for more than 3 axis path blending? On Tue, Aug 24, 2021, 11:11 AM andy pugh wrote: On Mon, 23 Aug 2021 at 21:27, andrew beck 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 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
On Tue, 24 Aug 2021 at 01:54, andrew beck wrote: > > Andy do you know what the tormach uses for more than 3 axis path blending? It's an extension to the circular arc interpolation that went in to the "new" LinuxCNC TP at 2.7. -- 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
Re: [Emc-users] jerk control
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 wrote: > On Mon, 23 Aug 2021 at 21:27, andrew beck > 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
Re: [Emc-users] jerk control
Andy do you know what the tormach uses for more than 3 axis path blending? On Tue, Aug 24, 2021, 11:11 AM andy pugh wrote: > On Mon, 23 Aug 2021 at 21:27, andrew beck > 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
Re: [Emc-users] jerk control
On Mon, 23 Aug 2021 at 21:27, andrew beck 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
Re: [Emc-users] jerk control
It really does matter on a high speed vmc too. On Tue, Aug 24, 2021, 9:40 AM Chris Albertson wrote: > I think the reason for a jerk limit is to limit changes in the force > applied to the machine's structure.A high constant acceleration applies > a constant force and hence constant deflection. "A constant deflection" > is a fancy way to way "no motion". But any jerk means the force and > deflection is non-constant, a fancy way to so the machine's frame is > moving. > > This matters on 3D printers and other lightly constructed machines a lot > more than on a CNC mill. > > On Mon, Aug 23, 2021 at 1:45 PM Todd Zuercher > wrote: > > > But you need to look at why you have your jerk limit is set to what it is > > in the first place. Is it not there so that the motor (joint) can > > accelerate in a controlled fashion as quickly as possible within its > > capabilities smoothly? Therefore the vector sum is also the vector sum > of > > the combined joints capabilities, so shouldn't that also be the same > amount > > higher? > > > > Todd Zuercher > > P. Graham Dunn Inc. > > 630 Henry Street > > Dalton, Ohio 44618 > > Phone: (330)828-2105ext. 2031 > > > > -Original Message----- > > From: Chris Albertson > > Sent: Monday, August 23, 2021 3:39 PM > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] jerk control > > > > [EXTERNAL EMAIL] Be sure links are safe. > > > > On Mon, Aug 23, 2021 at 7:16 AM Todd Zuercher > > wrote: > > > > > To my lay persons eyes I would think it would be enough to jerk limit > > > in joint space. The limiting in Cartesian space would then take care > > > of itself. > > > > > > > Let's work a simple example to see. Assume jerk is limited to 1 meter > per > > second cubed. Assume the machine is just 2D, X and Y pen plotter. If > > both axes are running at the same speed and the current X and Y jerk is > at > > the 1m/s^3 limit then the pen (Cartesian space) has jerk equal to 1.414 > > (square root of two) which is over the limit. > > > > Controllering only joint limits can't work if the cartesian motion can be > > expressed as the vector sum of joint motions because the sum of two > vacters > > can have greater magnitude then either of the two joint vectors > > > > Simply not bumping into a limit is not really hard but it becomes a hard > > problem when you want to move as fast as possible, but no faster. You > can't > > do it without doing a full simulation and numeric optimization. > > > > > > > > > > I think this is true on a 3-axis machine where all the axes are linear > and > > orthogonal. Basically wherever "trivial kinematics" applies. > > > > > > > > > > > > > > As to the jogging question, does it matter? Why would jogging have to > > > have the same acceleration limits as planned motion? Set the jogging > > > limits to something safe and conservative that won't matter if they > > > are jerk limited. > > > > > > Todd Zuercher > > > P. Graham Dunn Inc. > > > 630 Henry Street > > > Dalton, Ohio 44618 > > > Phone: (330)828-2105ext. 2031 > > > > > > -Original Message- > > > From: andy pugh > > > Sent: Monday, August 23, 2021 4:50 AM > > > To: Enhanced Machine Controller (EMC) > > > > > > Subject: Re: [Emc-users] jerk control > > > > > > [EXTERNAL EMAIL] Be sure links are safe. > > > > > > On Mon, 23 Aug 2021 at 04:40, Chris Albertson > > > > > > wrote: > > > > > > > Actually for a machine tool, why not run the simulation off-line and > > > > use as much time and computer power as it takes. > > > > > > Feed-override? > > > > > > Do you allow infinite jerk on abort? You might think that is an easy > > > question, except that continuous jog is implemented as a move to the > > > limit that is aborted on key release. > > > > > > And, do we need to jerk-limit in joint space or cartesian space, or > both? > > > > > > -- > > > 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 > > > > > > > > > _
Re: [Emc-users] jerk control
I think the reason for a jerk limit is to limit changes in the force applied to the machine's structure.A high constant acceleration applies a constant force and hence constant deflection. "A constant deflection" is a fancy way to way "no motion". But any jerk means the force and deflection is non-constant, a fancy way to so the machine's frame is moving. This matters on 3D printers and other lightly constructed machines a lot more than on a CNC mill. On Mon, Aug 23, 2021 at 1:45 PM Todd Zuercher wrote: > But you need to look at why you have your jerk limit is set to what it is > in the first place. Is it not there so that the motor (joint) can > accelerate in a controlled fashion as quickly as possible within its > capabilities smoothly? Therefore the vector sum is also the vector sum of > the combined joints capabilities, so shouldn't that also be the same amount > higher? > > Todd Zuercher > P. Graham Dunn Inc. > 630 Henry Street > Dalton, Ohio 44618 > Phone: (330)828-2105ext. 2031 > > -Original Message- > From: Chris Albertson > Sent: Monday, August 23, 2021 3:39 PM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] jerk control > > [EXTERNAL EMAIL] Be sure links are safe. > > On Mon, Aug 23, 2021 at 7:16 AM Todd Zuercher > wrote: > > > To my lay persons eyes I would think it would be enough to jerk limit > > in joint space. The limiting in Cartesian space would then take care > > of itself. > > > > Let's work a simple example to see. Assume jerk is limited to 1 meter per > second cubed. Assume the machine is just 2D, X and Y pen plotter. If > both axes are running at the same speed and the current X and Y jerk is at > the 1m/s^3 limit then the pen (Cartesian space) has jerk equal to 1.414 > (square root of two) which is over the limit. > > Controllering only joint limits can't work if the cartesian motion can be > expressed as the vector sum of joint motions because the sum of two vacters > can have greater magnitude then either of the two joint vectors > > Simply not bumping into a limit is not really hard but it becomes a hard > problem when you want to move as fast as possible, but no faster. You can't > do it without doing a full simulation and numeric optimization. > > > > > I think this is true on a 3-axis machine where all the axes are linear and > orthogonal. Basically wherever "trivial kinematics" applies. > > > > > > > > As to the jogging question, does it matter? Why would jogging have to > > have the same acceleration limits as planned motion? Set the jogging > > limits to something safe and conservative that won't matter if they > > are jerk limited. > > > > Todd Zuercher > > P. Graham Dunn Inc. > > 630 Henry Street > > Dalton, Ohio 44618 > > Phone: (330)828-2105ext. 2031 > > > > -Original Message- > > From: andy pugh > > Sent: Monday, August 23, 2021 4:50 AM > > To: Enhanced Machine Controller (EMC) > > > > Subject: Re: [Emc-users] jerk control > > > > [EXTERNAL EMAIL] Be sure links are safe. > > > > On Mon, 23 Aug 2021 at 04:40, Chris Albertson > > > > wrote: > > > > > Actually for a machine tool, why not run the simulation off-line and > > > use as much time and computer power as it takes. > > > > Feed-override? > > > > Do you allow infinite jerk on abort? You might think that is an easy > > question, except that continuous jog is implemented as a move to the > > limit that is aborted on key release. > > > > And, do we need to jerk-limit in joint space or cartesian space, or both? > > > > -- > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > s.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cto > > ddz%40pgrahamdunn.com%7Cdd7544f442b14a481c5d08d9666dccd5%7C5758544c573 > > f47cebee96c3e0806fb43%7C0%7C0%7C63765382037937%7CUnknown%7CTWFpbGZ > > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 > > D%7C3000sdata=2OcIVDtgOdrHp0UmetoWxlAJ3mdvi%2FoT5hRpOH3Oc4Q%3D > > p;reserved=0 > > > > > > ___ > > Emc-user
Re: [Emc-users] jerk control
But you need to look at why you have your jerk limit is set to what it is in the first place. Is it not there so that the motor (joint) can accelerate in a controlled fashion as quickly as possible within its capabilities smoothly? Therefore the vector sum is also the vector sum of the combined joints capabilities, so shouldn't that also be the same amount higher? Todd Zuercher P. Graham Dunn Inc. 630 Henry Street Dalton, Ohio 44618 Phone: (330)828-2105ext. 2031 -Original Message- From: Chris Albertson Sent: Monday, August 23, 2021 3:39 PM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] jerk control [EXTERNAL EMAIL] Be sure links are safe. On Mon, Aug 23, 2021 at 7:16 AM Todd Zuercher wrote: > To my lay persons eyes I would think it would be enough to jerk limit > in joint space. The limiting in Cartesian space would then take care > of itself. > Let's work a simple example to see. Assume jerk is limited to 1 meter per second cubed. Assume the machine is just 2D, X and Y pen plotter. If both axes are running at the same speed and the current X and Y jerk is at the 1m/s^3 limit then the pen (Cartesian space) has jerk equal to 1.414 (square root of two) which is over the limit. Controllering only joint limits can't work if the cartesian motion can be expressed as the vector sum of joint motions because the sum of two vacters can have greater magnitude then either of the two joint vectors Simply not bumping into a limit is not really hard but it becomes a hard problem when you want to move as fast as possible, but no faster. You can't do it without doing a full simulation and numeric optimization. I think this is true on a 3-axis machine where all the axes are linear and orthogonal. Basically wherever "trivial kinematics" applies. > > As to the jogging question, does it matter? Why would jogging have to > have the same acceleration limits as planned motion? Set the jogging > limits to something safe and conservative that won't matter if they > are jerk limited. > > Todd Zuercher > P. Graham Dunn Inc. > 630 Henry Street > Dalton, Ohio 44618 > Phone: (330)828-2105ext. 2031 > > -Original Message- > From: andy pugh > Sent: Monday, August 23, 2021 4:50 AM > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] jerk control > > [EXTERNAL EMAIL] Be sure links are safe. > > On Mon, 23 Aug 2021 at 04:40, Chris Albertson > > wrote: > > > Actually for a machine tool, why not run the simulation off-line and > > use as much time and computer power as it takes. > > Feed-override? > > Do you allow infinite jerk on abort? You might think that is an easy > question, except that continuous jog is implemented as a move to the > limit that is aborted on key release. > > And, do we need to jerk-limit in joint space or cartesian space, or both? > > -- > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cto > ddz%40pgrahamdunn.com%7Cdd7544f442b14a481c5d08d9666dccd5%7C5758544c573 > f47cebee96c3e0806fb43%7C0%7C0%7C63765382037937%7CUnknown%7CTWFpbGZ > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 > D%7C3000sdata=2OcIVDtgOdrHp0UmetoWxlAJ3mdvi%2FoT5hRpOH3Oc4Q%3D > p;reserved=0 > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > s.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cto > ddz%40pgrahamdunn.com%7Cdd7544f442b14a481c5d08d9666dccd5%7C5758544c573 > f47cebee96c3e0806fb43%7C0%7C0%7C63765382037937%7CUnknown%7CTWFpbGZ > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 > D%7C3000sdata=2OcIVDtgOdrHp0UmetoWxlAJ3mdvi%2FoT5hRpOH3Oc4Q%3D > p;reserved=0 > -- Chris Albertson Redondo Beach, California ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Ctoddz%40pgrahamdunn.com%7Cdd7544f442b14a481c5d08d9666dccd5%7C5758544c573f47cebee96c3e0806fb43%7C0%7C0%7C63765382037937%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=2OcIVDtgOdrHp0UmetoWxlAJ3mdvi%2FoT5hRpOH3Oc4Q%3Dreserved=0 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
Just had a look at tiny g looks great. Hopefully we can adapt the code On Tue, Aug 24, 2021, 6:45 AM Rob C wrote: > how do they get it to work on the tiny g? > > https://github.com/synthetos/TinyG/wiki/Jerk-Controlled-Motion-Explained > > could we not adapt and improve on the code > > On Mon, 23 Aug 2021, 15:32 Feral Engineer, > wrote: > > > As someone who uses functions like g8p1, g5.1q1 and g5p1 on > mits/fanuc > > and cycle832 on Siemens, I can say that the need for high speed data > > processing functionality is pretty great. Although I don't know how > > Linuxcnc processes g code data, I do know that the aforementioned > functions > > will buffer hundreds of lines of code and smooth the transitions between > > points to a certain degree of accuracy, much like calculating down to a > > nurb or spline instead of worrying about acc/dec on a point to point > basis. > > Much like how lcnc has g64 with selectable accuracy, these functions > offer > > selectable acc/dec settings that will either rattle your fillings or > smooth > > out sharp corners to be razor perfect. I've not tried to run any of my > lcnc > > machines at speeds that would make me see an eminent need for this > > functionality, but I'm sure it would be a welcomed addition. > > > > Phil T. > > The Feral Engineer > > > > Check out my LinuxCNC tutorials, machine builds and other antics at > > www.youtube.com/c/theferalengineer > > > > Help support my channel efforts and coffee addiction: > > www.patreon.com/theferalengineer > > > > On Mon, Aug 23, 2021, 10:17 AM Todd Zuercher > > wrote: > > > > > To my lay persons eyes I would think it would be enough to jerk limit > in > > > joint space. The limiting in Cartesian space would then take care of > > > itself. > > > > > > As to the jogging question, does it matter? Why would jogging have to > > > have the same acceleration limits as planned motion? Set the jogging > > > limits to something safe and conservative that won't matter if they are > > > jerk limited. > > > > > > Todd Zuercher > > > P. Graham Dunn Inc. > > > 630 Henry Street > > > Dalton, Ohio 44618 > > > Phone: (330)828-2105ext. 2031 > > > > > > -Original Message- > > > From: andy pugh > > > Sent: Monday, August 23, 2021 4:50 AM > > > To: Enhanced Machine Controller (EMC) > > > > Subject: Re: [Emc-users] jerk control > > > > > > [EXTERNAL EMAIL] Be sure links are safe. > > > > > > On Mon, 23 Aug 2021 at 04:40, Chris Albertson < > albertson.ch...@gmail.com > > > > > > wrote: > > > > > > > Actually for a machine tool, why not run the simulation off-line and > > > > use as much time and computer power as it takes. > > > > > > Feed-override? > > > > > > Do you allow infinite jerk on abort? You might think that is an easy > > > question, except that continuous jog is implemented as a move to the > > limit > > > that is aborted on key release. > > > > > > And, do we need to jerk-limit in joint space or cartesian space, or > both? > > > > > > -- > > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Ctoddz%40pgrahamdunn.com%7Caaabdbd2b59a4e0ad88708d966134695%7C5758544c573f47cebee96c3e0806fb43%7C0%7C0%7C637653055682515186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=iD2Nxd21YC5aKx8hByW2ScEBuMjM9%2FXJCwo05FHb%2BLU%3Dreserved=0 > > > > > > > > > ___ > > > 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 > > > > ___ > 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
Re: [Emc-users] jerk control
On Mon, Aug 23, 2021 at 7:16 AM Todd Zuercher wrote: > To my lay persons eyes I would think it would be enough to jerk limit in > joint space. The limiting in Cartesian space would then take care of > itself. > Let's work a simple example to see. Assume jerk is limited to 1 meter per second cubed. Assume the machine is just 2D, X and Y pen plotter. If both axes are running at the same speed and the current X and Y jerk is at the 1m/s^3 limit then the pen (Cartesian space) has jerk equal to 1.414 (square root of two) which is over the limit. Controllering only joint limits can't work if the cartesian motion can be expressed as the vector sum of joint motions because the sum of two vacters can have greater magnitude then either of the two joint vectors Simply not bumping into a limit is not really hard but it becomes a hard problem when you want to move as fast as possible, but no faster. You can't do it without doing a full simulation and numeric optimization. I think this is true on a 3-axis machine where all the axes are linear and orthogonal. Basically wherever "trivial kinematics" applies. > > As to the jogging question, does it matter? Why would jogging have to > have the same acceleration limits as planned motion? Set the jogging > limits to something safe and conservative that won't matter if they are > jerk limited. > > Todd Zuercher > P. Graham Dunn Inc. > 630 Henry Street > Dalton, Ohio 44618 > Phone: (330)828-2105ext. 2031 > > -Original Message- > From: andy pugh > Sent: Monday, August 23, 2021 4:50 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] jerk control > > [EXTERNAL EMAIL] Be sure links are safe. > > On Mon, 23 Aug 2021 at 04:40, Chris Albertson > wrote: > > > Actually for a machine tool, why not run the simulation off-line and > > use as much time and computer power as it takes. > > Feed-override? > > Do you allow infinite jerk on abort? You might think that is an easy > question, except that continuous jog is implemented as a move to the limit > that is aborted on key release. > > And, do we need to jerk-limit in joint space or cartesian space, or both? > > -- > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Ctoddz%40pgrahamdunn.com%7Caaabdbd2b59a4e0ad88708d966134695%7C5758544c573f47cebee96c3e0806fb43%7C0%7C0%7C637653055682515186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=iD2Nxd21YC5aKx8hByW2ScEBuMjM9%2FXJCwo05FHb%2BLU%3Dreserved=0 > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > -- Chris Albertson Redondo Beach, California ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
how do they get it to work on the tiny g? https://github.com/synthetos/TinyG/wiki/Jerk-Controlled-Motion-Explained could we not adapt and improve on the code On Mon, 23 Aug 2021, 15:32 Feral Engineer, wrote: > As someone who uses functions like g8p1, g5.1q1 and g5p1 on mits/fanuc > and cycle832 on Siemens, I can say that the need for high speed data > processing functionality is pretty great. Although I don't know how > Linuxcnc processes g code data, I do know that the aforementioned functions > will buffer hundreds of lines of code and smooth the transitions between > points to a certain degree of accuracy, much like calculating down to a > nurb or spline instead of worrying about acc/dec on a point to point basis. > Much like how lcnc has g64 with selectable accuracy, these functions offer > selectable acc/dec settings that will either rattle your fillings or smooth > out sharp corners to be razor perfect. I've not tried to run any of my lcnc > machines at speeds that would make me see an eminent need for this > functionality, but I'm sure it would be a welcomed addition. > > Phil T. > The Feral Engineer > > Check out my LinuxCNC tutorials, machine builds and other antics at > www.youtube.com/c/theferalengineer > > Help support my channel efforts and coffee addiction: > www.patreon.com/theferalengineer > > On Mon, Aug 23, 2021, 10:17 AM Todd Zuercher > wrote: > > > To my lay persons eyes I would think it would be enough to jerk limit in > > joint space. The limiting in Cartesian space would then take care of > > itself. > > > > As to the jogging question, does it matter? Why would jogging have to > > have the same acceleration limits as planned motion? Set the jogging > > limits to something safe and conservative that won't matter if they are > > jerk limited. > > > > Todd Zuercher > > P. Graham Dunn Inc. > > 630 Henry Street > > Dalton, Ohio 44618 > > Phone: (330)828-2105ext. 2031 > > > > -----Original Message- > > From: andy pugh > > Sent: Monday, August 23, 2021 4:50 AM > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] jerk control > > > > [EXTERNAL EMAIL] Be sure links are safe. > > > > On Mon, 23 Aug 2021 at 04:40, Chris Albertson > > > wrote: > > > > > Actually for a machine tool, why not run the simulation off-line and > > > use as much time and computer power as it takes. > > > > Feed-override? > > > > Do you allow infinite jerk on abort? You might think that is an easy > > question, except that continuous jog is implemented as a move to the > limit > > that is aborted on key release. > > > > And, do we need to jerk-limit in joint space or cartesian space, or both? > > > > -- > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Ctoddz%40pgrahamdunn.com%7Caaabdbd2b59a4e0ad88708d966134695%7C5758544c573f47cebee96c3e0806fb43%7C0%7C0%7C637653055682515186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=iD2Nxd21YC5aKx8hByW2ScEBuMjM9%2FXJCwo05FHb%2BLU%3Dreserved=0 > > > > > > ___ > > 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 > ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
As someone who uses functions like g8p1, g5.1q1 and g5p1 on mits/fanuc and cycle832 on Siemens, I can say that the need for high speed data processing functionality is pretty great. Although I don't know how Linuxcnc processes g code data, I do know that the aforementioned functions will buffer hundreds of lines of code and smooth the transitions between points to a certain degree of accuracy, much like calculating down to a nurb or spline instead of worrying about acc/dec on a point to point basis. Much like how lcnc has g64 with selectable accuracy, these functions offer selectable acc/dec settings that will either rattle your fillings or smooth out sharp corners to be razor perfect. I've not tried to run any of my lcnc machines at speeds that would make me see an eminent need for this functionality, but I'm sure it would be a welcomed addition. Phil T. The Feral Engineer Check out my LinuxCNC tutorials, machine builds and other antics at www.youtube.com/c/theferalengineer Help support my channel efforts and coffee addiction: www.patreon.com/theferalengineer On Mon, Aug 23, 2021, 10:17 AM Todd Zuercher wrote: > To my lay persons eyes I would think it would be enough to jerk limit in > joint space. The limiting in Cartesian space would then take care of > itself. > > As to the jogging question, does it matter? Why would jogging have to > have the same acceleration limits as planned motion? Set the jogging > limits to something safe and conservative that won't matter if they are > jerk limited. > > Todd Zuercher > P. Graham Dunn Inc. > 630 Henry Street > Dalton, Ohio 44618 > Phone: (330)828-2105ext. 2031 > > -Original Message- > From: andy pugh > Sent: Monday, August 23, 2021 4:50 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] jerk control > > [EXTERNAL EMAIL] Be sure links are safe. > > On Mon, 23 Aug 2021 at 04:40, Chris Albertson > wrote: > > > Actually for a machine tool, why not run the simulation off-line and > > use as much time and computer power as it takes. > > Feed-override? > > Do you allow infinite jerk on abort? You might think that is an easy > question, except that continuous jog is implemented as a move to the limit > that is aborted on key release. > > And, do we need to jerk-limit in joint space or cartesian space, or both? > > -- > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Ctoddz%40pgrahamdunn.com%7Caaabdbd2b59a4e0ad88708d966134695%7C5758544c573f47cebee96c3e0806fb43%7C0%7C0%7C637653055682515186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=iD2Nxd21YC5aKx8hByW2ScEBuMjM9%2FXJCwo05FHb%2BLU%3Dreserved=0 > > > ___ > 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
Re: [Emc-users] jerk control
To my lay persons eyes I would think it would be enough to jerk limit in joint space. The limiting in Cartesian space would then take care of itself. As to the jogging question, does it matter? Why would jogging have to have the same acceleration limits as planned motion? Set the jogging limits to something safe and conservative that won't matter if they are jerk limited. Todd Zuercher P. Graham Dunn Inc. 630 Henry Street Dalton, Ohio 44618 Phone: (330)828-2105ext. 2031 -Original Message- From: andy pugh Sent: Monday, August 23, 2021 4:50 AM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] jerk control [EXTERNAL EMAIL] Be sure links are safe. On Mon, 23 Aug 2021 at 04:40, Chris Albertson wrote: > Actually for a machine tool, why not run the simulation off-line and > use as much time and computer power as it takes. Feed-override? Do you allow infinite jerk on abort? You might think that is an easy question, except that continuous jog is implemented as a move to the limit that is aborted on key release. And, do we need to jerk-limit in joint space or cartesian space, or both? -- 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Ctoddz%40pgrahamdunn.com%7Caaabdbd2b59a4e0ad88708d966134695%7C5758544c573f47cebee96c3e0806fb43%7C0%7C0%7C637653055682515186%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=iD2Nxd21YC5aKx8hByW2ScEBuMjM9%2FXJCwo05FHb%2BLU%3Dreserved=0 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
On Mon, 23 Aug 2021 at 04:40, Chris Albertson wrote: > Actually for a machine tool, why not run the > simulation off-line and use as much time and computer power as it takes. Feed-override? Do you allow infinite jerk on abort? You might think that is an easy question, except that continuous jog is implemented as a move to the limit that is aborted on key release. And, do we need to jerk-limit in joint space or cartesian space, or both? -- 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
Re: [Emc-users] jerk control
On Sun, Aug 22, 2021 at 5:15 PM John Dammeyer wrote: > > > What's the goal? To traverse the path as accurately as possible or to > reduce the shaking from sudden speed changes (the jerk)? > "jerk" is not a chance in speed. Jerk is change in acceleration. Planning an optimum jerk limited curved path in n-dimension has no closed form solution. I think you only option is to do a simulation out to some future time horizon. Actually for a machine tool, why not run the simulation off-line and use as much time and computer power as it takes. What is the goal? Usually it is a complex compromise of time and accuracy. It could even be a different compromise at different locations on the part > Mostly just confused. > John > > > > > > > -Original Message- > > From: Curtis Dutton [mailto:curtd...@gmail.com] > > Sent: August-22-21 11:48 AM > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] jerk control > > > > I have a desire to implement this. > > > > My business is in need of another cnc router and I will be building as > > high speed of a machine as I can afford. It is going to be a dual table > but > > a horizontal spindle. 1m x 1m working envelope. I plan on using linear > > motors. > > > > It will require jerk limiting to really get the value out of the machine. > > > > I have been working on bits and pieces in my spare time but I have very > > little time right now. > > > > > > My main approach so far is > > > > > > The realtime motion component will be enhanced so as to interpolate > nurbs > > curves. Those curves need be in a specific form of parameterization. > (coord > > length parameterized) > > > > > > The other part is in user space and it is the hard part. To perform > > blending of line segments it converts segments to nurbs curves, and > blends > > them together by fitting a segment of a clothoid (euler spirals) in > between > > them. It must do all of this while fitting within all of the velocity, > > accel, jerk and limit constraints. Then it reparameterizes these curves > for > > consumption by the motion component. > > > > This is essentially plotting a reasonable driving path on an N > dimensional > > race track. > > > > From some of the papers that I have read it looks like it will involve > > numerical integration and/or linear programming. Adding jerk equations > into > > standard physics makes it very much harder to solve. Closed form > equations > > don't really seem to exist. (If you have experience with this I could > > sorely use pointers, links, papers) > > > > > > Ultimately this is a very difficult task. Building a stripped down > version > > of a jerk controlled motion planner is what many people have done to > earn a > > PHD. > > > > > > I would be happy to join up with anyone else that is interested in > working > > on this. Even ideas, papers, demos is very helpful. Timeline for this... > > sadly a few years at best before completion. > > > > > > Thanks, > > Curt > > > > On Tue, Aug 17, 2021, 10:10 PM andrew beck > wrote: > > > > > Here is the text from your link sam > > > > > > > > > Ramped velocity in this case just means constant acceleration over the > > > whole segment. This is less optimal than a trapezoidal velocity > profile, > > > since the acceleration is not maximized. However, if the segment is > short > > > enough, there isn�t enough time to accelerate much before we hit the > next > > > segment. Recall the short line segments from the previous example. > Since > > > they�re lines, there�s no cornering acceleration, so we�re free to > > > accelerate up to the requested speed. However, if this line is between > two > > > arcs, then it will have to quickly decelerate again to be within the > > > maximum speed of the next segment. This means that we have a spike of > > > acceleration, then a spike of deceleration, causing a large jerk, for > very > > > little performance gain. This setting is a way to eliminate this jerk > for > > > short segments. > > > > > > Basically, if a segment will complete in less time than 1 / > > > ARC_BLEND_RAMP_FREQ, we don�t bother with a trapezoidal velocity > profile on > > > that segment, and use constant acceleration. (Setting > ARC_BLEND_RAMP_FREQ = > > > 1000 is equivalent to always using trapezoidal acceleration, if the > servo > > &
Re: [Emc-users] jerk control
and I will be a happy man once some wonderful person works it out:) On Mon, Aug 23, 2021 at 1:49 PM Curtis Dutton wrote: > The goal is allow both accuracy and speed. However there is a tradeoff > between those two just as there is now. > > During any move all vel, acc, jerk values must be coordinated to follow a > given path. For a coordinated move any limiting constraints will limit the > other related joints to prevent violations. > > > To perform multiple move through a sequence of lines the motion planner has > to blend moves and cut corners. The blend is also shaped to avoid violating > any limits but go as fast as possible. The distance the corner can be cut > by will be user specified. G64 just like now. > > Ultimatly the gcode program combined with your machine and its capabilities > are still going to limit the upper feed rates that can be accomplished. > > With jerk limiting the max acceleration values for any given machine will > be able to be increased while still having less following error. This > should lead to decreased cycle times for any given g-code program. > > > > > On Sun, Aug 22, 2021, 8:15 PM John Dammeyer > wrote: > > > This jerk control raises some questions for me. They probably have > simple > > answers rather than as complex as jerk control but perhaps it's related. > > > > Each axis has a MAX_ACCELERATION value. Simple math says that if X and Y > > are moving at an identical velocity then the path of the tool is 45 > > degrees. > > > > I suspect that the MAX_ACCELERATION is exactly that: maximum. If we want > > that 45 degree line to remain straight then both axis have to accelerate > at > > the same rate and end up at the same velocity at the same time so the > > acceleration that’s used is the lowest of the MAX_ACCELERATION value? > > > > From a feed rate perspective we want to get up to the target feed as > > quickly as possible since chip load, tool rubbing etc. can have adverse > > effects if the speed is too slow? > > > > By the same token the speed along that 45 degree path is the F parameter > > so each axis speed isn't the F value but the amount required to create > the > > speed on that path? > > > > Finally if the combination of acceleration and distance is such that the > F > > parameter isn't reached before it's time to decelerate then the tool > > reaches 0 before ever hitting the requested speed? > > > > This is all for a simple move that starts and stops. And clearly would > > cause a jerk like motion but it's precise from point A to point B. As I > > understand the jerk side of things the requirement is to look ahead at > the > > next move and only accelerate or decelerate as required to reach the new > > velocity for each axis and change the rate of acceleration within that > > envelope. > > > > But now the two axis are no longer following the target path right? > > There is one that has to slow down to half the speed while the other > > accelerates up to twice the speed (for example). The path followed now > is > > more complex? And which acceleration is used and is it changed as the > path > > is followed? > > > > What's the goal? To traverse the path as accurately as possible or to > > reduce the shaking from sudden speed changes (the jerk)? > > > > Mostly just confused. > > John > > > > > > > > > > > > > -Original Message- > > > From: Curtis Dutton [mailto:curtd...@gmail.com] > > > Sent: August-22-21 11:48 AM > > > To: Enhanced Machine Controller (EMC) > > > Subject: Re: [Emc-users] jerk control > > > > > > I have a desire to implement this. > > > > > > My business is in need of another cnc router and I will be building as > > > high speed of a machine as I can afford. It is going to be a dual table > > but > > > a horizontal spindle. 1m x 1m working envelope. I plan on using linear > > > motors. > > > > > > It will require jerk limiting to really get the value out of the > machine. > > > > > > I have been working on bits and pieces in my spare time but I have very > > > little time right now. > > > > > > > > > My main approach so far is > > > > > > > > > The realtime motion component will be enhanced so as to interpolate > > nurbs > > > curves. Those curves need be in a specific form of parameterization. > > (coord > > > length parameterized) > > > > > > > > > The other p
Re: [Emc-users] jerk control
ween > two > > arcs, then it will have to quickly decelerate again to be within the > > maximum speed of the next segment. This means that we have a spike of > > acceleration, then a spike of deceleration, causing a large jerk, for > very > > little performance gain. This setting is a way to eliminate this jerk for > > short segments. > > > > Basically, if a segment will complete in less time than 1 / > > ARC_BLEND_RAMP_FREQ, we don’t bother with a trapezoidal velocity profile > on > > that segment, and use constant acceleration. (Setting > ARC_BLEND_RAMP_FREQ = > > 1000 is equivalent to always using trapezoidal acceleration, if the servo > > loop is 1kHz). > > > > You can characterize the worst-case loss of performance by comparing the > > velocity that a trapezoidal profile reaches vs. the ramp: > > > > # v_ripple = a_max / (4.0 * f) # where: # v_ripple = average velocity > > "loss" due to ramping # a_max = max axis acceleration # f = cutoff > > frequency from INI > > > > For the aforementioned machine, the ripple for a 20Hz cutoff frequency is > > 100 / (4 * 20) = 1.25 IPS. This seems high, but keep in mind that it is > > only a worst-case estimate. In reality , the trapezoidal motion profile > is > > limited by other factors, such as normal acceleration or requested > > velocity, and so the actual performance loss should be much smaller. > > Increasing the cutoff frequency can squeeze out more performance, but > make > > the motion rougher due to acceleration discontinuities. A value in the > > range 20Hz to 200Hz should be reasonable to start. > > > > Finally, no amount of tweaking will speed up a toolpath with lots of > small, > > tight corners, since you’re limited by cornering acceleration. > > > > On Wed, Aug 18, 2021, 2:06 PM John Dammeyer > > wrote: > > > > > This is what we're talking about right? > > > Ramping acceleration? > > > https://www.mmsonline.com/articles/understanding-jerk-control > > > > > > John > > > > > > > > > > -Original Message- > > > > From: Feral Engineer [mailto:theferalengin...@gmail.com] > > > > Sent: August-17-21 6:46 PM > > > > To: Enhanced Machine Controller (EMC) > > > > Subject: Re: [Emc-users] jerk control > > > > > > > > I'm curious what the current level of block lookahead is on lcnc > > compared > > > > to commercial controls. Anyone know the amount of data buffering that > > it > > > > can handle? > > > > > > > > Phil T. > > > > The Feral Engineer > > > > > > > > Check out my LinuxCNC tutorials, machine builds and other antics at > > > > www.youtube.com/c/theferalengineer > > > > > > > > Help support my channel efforts and coffee addiction: > > > > www.patreon.com/theferalengineer > > > > > > > > On Tue, Aug 17, 2021, 9:36 PM Sam Sokolik > wrote: > > > > > > > > > It would be the same setup... Just using servo amps.. Velocity > out > > > of > > > > > the pid - position back from the encoders. > > > > > > > > > > On Tue, Aug 17, 2021, 8:14 PM andrew beck < > andrewbeck0...@gmail.com> > > > > > wrote: > > > > > > > > > > > Not sure Sam. > > > > > > > > > > > > I have a 7i77 on this mill though also. So analog control > > > > > > > > > > > > On Wed, Aug 18, 2021, 12:51 PM Sam Sokolik > > > wrote: > > > > > > > > > > > > > I am going to ask a stuid question.. If you have a velocity > run > > > step > > > > > gen > > > > > > > with pid. Couldn't you hook a limit3 between the pid and > > steghen. > > > > > > > Because the input is velocity instead of position - wouldn't > the > > > > > > > acceleration limit in the limit3 be jerk instead of > acceleration? > > > I > > > > > am > > > > > > > sure it doesn't work that way.. I was just thinking you have > > moved > > > the > > > > > > > derivatives up one.. > > > > > > > > > > > > > > (I can tell you it doesn't seem to work in practice - probably > > > because > > > > > > the > > > > > > > pid will always try to correct the error. Like maybe y
Re: [Emc-users] jerk control
The goal is allow both accuracy and speed. However there is a tradeoff between those two just as there is now. During any move all vel, acc, jerk values must be coordinated to follow a given path. For a coordinated move any limiting constraints will limit the other related joints to prevent violations. To perform multiple move through a sequence of lines the motion planner has to blend moves and cut corners. The blend is also shaped to avoid violating any limits but go as fast as possible. The distance the corner can be cut by will be user specified. G64 just like now. Ultimatly the gcode program combined with your machine and its capabilities are still going to limit the upper feed rates that can be accomplished. With jerk limiting the max acceleration values for any given machine will be able to be increased while still having less following error. This should lead to decreased cycle times for any given g-code program. On Sun, Aug 22, 2021, 8:15 PM John Dammeyer wrote: > This jerk control raises some questions for me. They probably have simple > answers rather than as complex as jerk control but perhaps it's related. > > Each axis has a MAX_ACCELERATION value. Simple math says that if X and Y > are moving at an identical velocity then the path of the tool is 45 > degrees. > > I suspect that the MAX_ACCELERATION is exactly that: maximum. If we want > that 45 degree line to remain straight then both axis have to accelerate at > the same rate and end up at the same velocity at the same time so the > acceleration that’s used is the lowest of the MAX_ACCELERATION value? > > From a feed rate perspective we want to get up to the target feed as > quickly as possible since chip load, tool rubbing etc. can have adverse > effects if the speed is too slow? > > By the same token the speed along that 45 degree path is the F parameter > so each axis speed isn't the F value but the amount required to create the > speed on that path? > > Finally if the combination of acceleration and distance is such that the F > parameter isn't reached before it's time to decelerate then the tool > reaches 0 before ever hitting the requested speed? > > This is all for a simple move that starts and stops. And clearly would > cause a jerk like motion but it's precise from point A to point B. As I > understand the jerk side of things the requirement is to look ahead at the > next move and only accelerate or decelerate as required to reach the new > velocity for each axis and change the rate of acceleration within that > envelope. > > But now the two axis are no longer following the target path right? > There is one that has to slow down to half the speed while the other > accelerates up to twice the speed (for example). The path followed now is > more complex? And which acceleration is used and is it changed as the path > is followed? > > What's the goal? To traverse the path as accurately as possible or to > reduce the shaking from sudden speed changes (the jerk)? > > Mostly just confused. > John > > > > > > > -Original Message----- > > From: Curtis Dutton [mailto:curtd...@gmail.com] > > Sent: August-22-21 11:48 AM > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] jerk control > > > > I have a desire to implement this. > > > > My business is in need of another cnc router and I will be building as > > high speed of a machine as I can afford. It is going to be a dual table > but > > a horizontal spindle. 1m x 1m working envelope. I plan on using linear > > motors. > > > > It will require jerk limiting to really get the value out of the machine. > > > > I have been working on bits and pieces in my spare time but I have very > > little time right now. > > > > > > My main approach so far is > > > > > > The realtime motion component will be enhanced so as to interpolate > nurbs > > curves. Those curves need be in a specific form of parameterization. > (coord > > length parameterized) > > > > > > The other part is in user space and it is the hard part. To perform > > blending of line segments it converts segments to nurbs curves, and > blends > > them together by fitting a segment of a clothoid (euler spirals) in > between > > them. It must do all of this while fitting within all of the velocity, > > accel, jerk and limit constraints. Then it reparameterizes these curves > for > > consumption by the motion component. > > > > This is essentially plotting a reasonable driving path on an N > dimensional > > race track. > > > > From some of the papers that I have read it looks like it will involve > > numer
Re: [Emc-users] jerk control
This jerk control raises some questions for me. They probably have simple answers rather than as complex as jerk control but perhaps it's related. Each axis has a MAX_ACCELERATION value. Simple math says that if X and Y are moving at an identical velocity then the path of the tool is 45 degrees. I suspect that the MAX_ACCELERATION is exactly that: maximum. If we want that 45 degree line to remain straight then both axis have to accelerate at the same rate and end up at the same velocity at the same time so the acceleration that’s used is the lowest of the MAX_ACCELERATION value? From a feed rate perspective we want to get up to the target feed as quickly as possible since chip load, tool rubbing etc. can have adverse effects if the speed is too slow? By the same token the speed along that 45 degree path is the F parameter so each axis speed isn't the F value but the amount required to create the speed on that path? Finally if the combination of acceleration and distance is such that the F parameter isn't reached before it's time to decelerate then the tool reaches 0 before ever hitting the requested speed? This is all for a simple move that starts and stops. And clearly would cause a jerk like motion but it's precise from point A to point B. As I understand the jerk side of things the requirement is to look ahead at the next move and only accelerate or decelerate as required to reach the new velocity for each axis and change the rate of acceleration within that envelope. But now the two axis are no longer following the target path right? There is one that has to slow down to half the speed while the other accelerates up to twice the speed (for example). The path followed now is more complex? And which acceleration is used and is it changed as the path is followed? What's the goal? To traverse the path as accurately as possible or to reduce the shaking from sudden speed changes (the jerk)? Mostly just confused. John > -Original Message- > From: Curtis Dutton [mailto:curtd...@gmail.com] > Sent: August-22-21 11:48 AM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] jerk control > > I have a desire to implement this. > > My business is in need of another cnc router and I will be building as > high speed of a machine as I can afford. It is going to be a dual table but > a horizontal spindle. 1m x 1m working envelope. I plan on using linear > motors. > > It will require jerk limiting to really get the value out of the machine. > > I have been working on bits and pieces in my spare time but I have very > little time right now. > > > My main approach so far is > > > The realtime motion component will be enhanced so as to interpolate nurbs > curves. Those curves need be in a specific form of parameterization. (coord > length parameterized) > > > The other part is in user space and it is the hard part. To perform > blending of line segments it converts segments to nurbs curves, and blends > them together by fitting a segment of a clothoid (euler spirals) in between > them. It must do all of this while fitting within all of the velocity, > accel, jerk and limit constraints. Then it reparameterizes these curves for > consumption by the motion component. > > This is essentially plotting a reasonable driving path on an N dimensional > race track. > > From some of the papers that I have read it looks like it will involve > numerical integration and/or linear programming. Adding jerk equations into > standard physics makes it very much harder to solve. Closed form equations > don't really seem to exist. (If you have experience with this I could > sorely use pointers, links, papers) > > > Ultimately this is a very difficult task. Building a stripped down version > of a jerk controlled motion planner is what many people have done to earn a > PHD. > > > I would be happy to join up with anyone else that is interested in working > on this. Even ideas, papers, demos is very helpful. Timeline for this... > sadly a few years at best before completion. > > > Thanks, > Curt > > On Tue, Aug 17, 2021, 10:10 PM andrew beck wrote: > > > Here is the text from your link sam > > > > > > Ramped velocity in this case just means constant acceleration over the > > whole segment. This is less optimal than a trapezoidal velocity profile, > > since the acceleration is not maximized. However, if the segment is short > > enough, there isn�t enough time to accelerate much before we hit the next > > segment. Recall the short line segments from the previous example. Since > > they�re lines, there�s no cornering acceleration, so we�re free to > > accelerate up to the requested speed. However, if this line is
Re: [Emc-users] jerk control
I have a desire to implement this. My business is in need of another cnc router and I will be building as high speed of a machine as I can afford. It is going to be a dual table but a horizontal spindle. 1m x 1m working envelope. I plan on using linear motors. It will require jerk limiting to really get the value out of the machine. I have been working on bits and pieces in my spare time but I have very little time right now. My main approach so far is The realtime motion component will be enhanced so as to interpolate nurbs curves. Those curves need be in a specific form of parameterization. (coord length parameterized) The other part is in user space and it is the hard part. To perform blending of line segments it converts segments to nurbs curves, and blends them together by fitting a segment of a clothoid (euler spirals) in between them. It must do all of this while fitting within all of the velocity, accel, jerk and limit constraints. Then it reparameterizes these curves for consumption by the motion component. This is essentially plotting a reasonable driving path on an N dimensional race track. From some of the papers that I have read it looks like it will involve numerical integration and/or linear programming. Adding jerk equations into standard physics makes it very much harder to solve. Closed form equations don't really seem to exist. (If you have experience with this I could sorely use pointers, links, papers) Ultimately this is a very difficult task. Building a stripped down version of a jerk controlled motion planner is what many people have done to earn a PHD. I would be happy to join up with anyone else that is interested in working on this. Even ideas, papers, demos is very helpful. Timeline for this... sadly a few years at best before completion. Thanks, Curt On Tue, Aug 17, 2021, 10:10 PM andrew beck wrote: > Here is the text from your link sam > > > Ramped velocity in this case just means constant acceleration over the > whole segment. This is less optimal than a trapezoidal velocity profile, > since the acceleration is not maximized. However, if the segment is short > enough, there isn’t enough time to accelerate much before we hit the next > segment. Recall the short line segments from the previous example. Since > they’re lines, there’s no cornering acceleration, so we’re free to > accelerate up to the requested speed. However, if this line is between two > arcs, then it will have to quickly decelerate again to be within the > maximum speed of the next segment. This means that we have a spike of > acceleration, then a spike of deceleration, causing a large jerk, for very > little performance gain. This setting is a way to eliminate this jerk for > short segments. > > Basically, if a segment will complete in less time than 1 / > ARC_BLEND_RAMP_FREQ, we don’t bother with a trapezoidal velocity profile on > that segment, and use constant acceleration. (Setting ARC_BLEND_RAMP_FREQ = > 1000 is equivalent to always using trapezoidal acceleration, if the servo > loop is 1kHz). > > You can characterize the worst-case loss of performance by comparing the > velocity that a trapezoidal profile reaches vs. the ramp: > > # v_ripple = a_max / (4.0 * f) # where: # v_ripple = average velocity > "loss" due to ramping # a_max = max axis acceleration # f = cutoff > frequency from INI > > For the aforementioned machine, the ripple for a 20Hz cutoff frequency is > 100 / (4 * 20) = 1.25 IPS. This seems high, but keep in mind that it is > only a worst-case estimate. In reality , the trapezoidal motion profile is > limited by other factors, such as normal acceleration or requested > velocity, and so the actual performance loss should be much smaller. > Increasing the cutoff frequency can squeeze out more performance, but make > the motion rougher due to acceleration discontinuities. A value in the > range 20Hz to 200Hz should be reasonable to start. > > Finally, no amount of tweaking will speed up a toolpath with lots of small, > tight corners, since you’re limited by cornering acceleration. > > On Wed, Aug 18, 2021, 2:06 PM John Dammeyer > wrote: > > > This is what we're talking about right? > > Ramping acceleration? > > https://www.mmsonline.com/articles/understanding-jerk-control > > > > John > > > > > > > -----Original Message- > > > From: Feral Engineer [mailto:theferalengin...@gmail.com] > > > Sent: August-17-21 6:46 PM > > > To: Enhanced Machine Controller (EMC) > > > Subject: Re: [Emc-users] jerk control > > > > > > I'm curious what the current level of block lookahead is on lcnc > compared > > > to commercial controls. Anyone know the amount of data buffering that > it > > > can handle?
Re: [Emc-users] jerk control
Here is the text from your link sam Ramped velocity in this case just means constant acceleration over the whole segment. This is less optimal than a trapezoidal velocity profile, since the acceleration is not maximized. However, if the segment is short enough, there isn’t enough time to accelerate much before we hit the next segment. Recall the short line segments from the previous example. Since they’re lines, there’s no cornering acceleration, so we’re free to accelerate up to the requested speed. However, if this line is between two arcs, then it will have to quickly decelerate again to be within the maximum speed of the next segment. This means that we have a spike of acceleration, then a spike of deceleration, causing a large jerk, for very little performance gain. This setting is a way to eliminate this jerk for short segments. Basically, if a segment will complete in less time than 1 / ARC_BLEND_RAMP_FREQ, we don’t bother with a trapezoidal velocity profile on that segment, and use constant acceleration. (Setting ARC_BLEND_RAMP_FREQ = 1000 is equivalent to always using trapezoidal acceleration, if the servo loop is 1kHz). You can characterize the worst-case loss of performance by comparing the velocity that a trapezoidal profile reaches vs. the ramp: # v_ripple = a_max / (4.0 * f) # where: # v_ripple = average velocity "loss" due to ramping # a_max = max axis acceleration # f = cutoff frequency from INI For the aforementioned machine, the ripple for a 20Hz cutoff frequency is 100 / (4 * 20) = 1.25 IPS. This seems high, but keep in mind that it is only a worst-case estimate. In reality , the trapezoidal motion profile is limited by other factors, such as normal acceleration or requested velocity, and so the actual performance loss should be much smaller. Increasing the cutoff frequency can squeeze out more performance, but make the motion rougher due to acceleration discontinuities. A value in the range 20Hz to 200Hz should be reasonable to start. Finally, no amount of tweaking will speed up a toolpath with lots of small, tight corners, since you’re limited by cornering acceleration. On Wed, Aug 18, 2021, 2:06 PM John Dammeyer wrote: > This is what we're talking about right? > Ramping acceleration? > https://www.mmsonline.com/articles/understanding-jerk-control > > John > > > > -Original Message- > > From: Feral Engineer [mailto:theferalengin...@gmail.com] > > Sent: August-17-21 6:46 PM > > To: Enhanced Machine Controller (EMC) > > Subject: Re: [Emc-users] jerk control > > > > I'm curious what the current level of block lookahead is on lcnc compared > > to commercial controls. Anyone know the amount of data buffering that it > > can handle? > > > > Phil T. > > The Feral Engineer > > > > Check out my LinuxCNC tutorials, machine builds and other antics at > > www.youtube.com/c/theferalengineer > > > > Help support my channel efforts and coffee addiction: > > www.patreon.com/theferalengineer > > > > On Tue, Aug 17, 2021, 9:36 PM Sam Sokolik wrote: > > > > > It would be the same setup... Just using servo amps.. Velocity out > of > > > the pid - position back from the encoders. > > > > > > On Tue, Aug 17, 2021, 8:14 PM andrew beck > > > wrote: > > > > > > > Not sure Sam. > > > > > > > > I have a 7i77 on this mill though also. So analog control > > > > > > > > On Wed, Aug 18, 2021, 12:51 PM Sam Sokolik > wrote: > > > > > > > > > I am going to ask a stuid question.. If you have a velocity run > step > > > gen > > > > > with pid. Couldn't you hook a limit3 between the pid and steghen. > > > > > Because the input is velocity instead of position - wouldn't the > > > > > acceleration limit in the limit3 be jerk instead of acceleration? > I > > > am > > > > > sure it doesn't work that way.. I was just thinking you have moved > the > > > > > derivatives up one.. > > > > > > > > > > (I can tell you it doesn't seem to work in practice - probably > because > > > > the > > > > > pid will always try to correct the error. Like maybe you would > need to > > > > > negate the limit3 amount on the feedback side..) > > > > > > > > > > On Tue, Aug 17, 2021 at 1:28 PM Scott Harwell via Emc-users < > > > > > emc-users@lists.sourceforge.net> wrote: > > > > > > > > > > > I haven't tried it yet, but this looks promising. > > > > > > LinuxCNC S-Curve Accelerations > > > > > > >
Re: [Emc-users] jerk control
This is what we're talking about right? Ramping acceleration? https://www.mmsonline.com/articles/understanding-jerk-control John > -Original Message- > From: Feral Engineer [mailto:theferalengin...@gmail.com] > Sent: August-17-21 6:46 PM > To: Enhanced Machine Controller (EMC) > Subject: Re: [Emc-users] jerk control > > I'm curious what the current level of block lookahead is on lcnc compared > to commercial controls. Anyone know the amount of data buffering that it > can handle? > > Phil T. > The Feral Engineer > > Check out my LinuxCNC tutorials, machine builds and other antics at > www.youtube.com/c/theferalengineer > > Help support my channel efforts and coffee addiction: > www.patreon.com/theferalengineer > > On Tue, Aug 17, 2021, 9:36 PM Sam Sokolik wrote: > > > It would be the same setup... Just using servo amps.. Velocity out of > > the pid - position back from the encoders. > > > > On Tue, Aug 17, 2021, 8:14 PM andrew beck > > wrote: > > > > > Not sure Sam. > > > > > > I have a 7i77 on this mill though also. So analog control > > > > > > On Wed, Aug 18, 2021, 12:51 PM Sam Sokolik wrote: > > > > > > > I am going to ask a stuid question.. If you have a velocity run step > > gen > > > > with pid. Couldn't you hook a limit3 between the pid and steghen. > > > > Because the input is velocity instead of position - wouldn't the > > > > acceleration limit in the limit3 be jerk instead of acceleration? I > > am > > > > sure it doesn't work that way.. I was just thinking you have moved the > > > > derivatives up one.. > > > > > > > > (I can tell you it doesn't seem to work in practice - probably because > > > the > > > > pid will always try to correct the error. Like maybe you would need to > > > > negate the limit3 amount on the feedback side..) > > > > > > > > On Tue, Aug 17, 2021 at 1:28 PM Scott Harwell via Emc-users < > > > > emc-users@lists.sourceforge.net> wrote: > > > > > > > > > I haven't tried it yet, but this looks promising. > > > > > LinuxCNC S-Curve Accelerations > > > > > > > > > > > > > > > > > > > > Scott H > > > > > > > > > > > > > > > On Tuesday, August 17, 2021, 12:57:06 PM CDT, Ralph Stirling < > > > > > ralph.stirl...@wallawalla.edu> wrote: > > > > > > > > > > I've also been hoping to see this appear in a Linuxcnc update, > > > > > as it has been worked on by a number of people for years. > > > > > Here are the most recent threads about jerk-limited trajectory > > > planning: > > > > > > > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/24-hal-components/40152-jerk-limited-trajectory-planner-hal-component > > > > > > > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/38-general-linuxcnc-questions/34666-c2-smooth-velocity-profile?start=0 > > > > > > > > > > -- Ralph > > > > > > > > > > From: David Berndt [ber...@uberwin.com] > > > > > Sent: Tuesday, August 17, 2021 9:01 AM > > > > > To: Enhanced Machine Controller (EMC); andrew beck > > > > > Subject: Re: [Emc-users] jerk control > > > > > > > > > > CAUTION: This email originated from outside the Walla Walla > > University > > > > > email system. > > > > > > > > > > > > > > > I don't have a great need for it with my machines, or the time/brains > > > to > > > > > implement it. It just seems like a feature we really should have. > > > > > > > > > > I'd be willing to participate monetarily in some sort of system to > > > > > incentivize the inclusion of jerk control. Perhaps an open-source > > > feature > > > > > bounty? Does the community want to consider that sort of thing? > > > > > > > > > > -Dave > > > > > > > > > > On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck < > > > > andrewbeck0...@gmail.com> > > > > > wrote: > > > > > > > > > > > hey guys > > > > > > > > > > > > I am
Re: [Emc-users] jerk control
I think 250 lines a head rings a bell On Wed, Aug 18, 2021, 1:49 PM Feral Engineer wrote: > I'm curious what the current level of block lookahead is on lcnc compared > to commercial controls. Anyone know the amount of data buffering that it > can handle? > > Phil T. > The Feral Engineer > > Check out my LinuxCNC tutorials, machine builds and other antics at > www.youtube.com/c/theferalengineer > > Help support my channel efforts and coffee addiction: > www.patreon.com/theferalengineer > > On Tue, Aug 17, 2021, 9:36 PM Sam Sokolik wrote: > > > It would be the same setup... Just using servo amps.. Velocity out of > > the pid - position back from the encoders. > > > > On Tue, Aug 17, 2021, 8:14 PM andrew beck > > wrote: > > > > > Not sure Sam. > > > > > > I have a 7i77 on this mill though also. So analog control > > > > > > On Wed, Aug 18, 2021, 12:51 PM Sam Sokolik wrote: > > > > > > > I am going to ask a stuid question.. If you have a velocity run step > > gen > > > > with pid. Couldn't you hook a limit3 between the pid and steghen. > > > > Because the input is velocity instead of position - wouldn't the > > > > acceleration limit in the limit3 be jerk instead of acceleration? I > > am > > > > sure it doesn't work that way.. I was just thinking you have moved > the > > > > derivatives up one.. > > > > > > > > (I can tell you it doesn't seem to work in practice - probably > because > > > the > > > > pid will always try to correct the error. Like maybe you would need > to > > > > negate the limit3 amount on the feedback side..) > > > > > > > > On Tue, Aug 17, 2021 at 1:28 PM Scott Harwell via Emc-users < > > > > emc-users@lists.sourceforge.net> wrote: > > > > > > > > > I haven't tried it yet, but this looks promising. > > > > > LinuxCNC S-Curve Accelerations > > > > > > > > > > > > > > > > > > > > Scott H > > > > > > > > > > > > > > > On Tuesday, August 17, 2021, 12:57:06 PM CDT, Ralph Stirling < > > > > > ralph.stirl...@wallawalla.edu> wrote: > > > > > > > > > > I've also been hoping to see this appear in a Linuxcnc update, > > > > > as it has been worked on by a number of people for years. > > > > > Here are the most recent threads about jerk-limited trajectory > > > planning: > > > > > > > > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/24-hal-components/40152-jerk-limited-trajectory-planner-hal-component > > > > > > > > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/38-general-linuxcnc-questions/34666-c2-smooth-velocity-profile?start=0 > > > > > > > > > > -- Ralph > > > > > > > > > > From: David Berndt [ber...@uberwin.com] > > > > > Sent: Tuesday, August 17, 2021 9:01 AM > > > > > To: Enhanced Machine Controller (EMC); andrew beck > > > > > Subject: Re: [Emc-users] jerk control > > > > > > > > > > CAUTION: This email originated from outside the Walla Walla > > University > > > > > email system. > > > > > > > > > > > > > > > I don't have a great need for it with my machines, or the > time/brains > > > to > > > > > implement it. It just seems like a feature we really should have. > > > > > > > > > > I'd be willing to participate monetarily in some sort of system > to > > > > > incentivize the inclusion of jerk control. Perhaps an open-source > > > feature > > > > > bounty? Does the community want to consider that sort of thing? > > > > > > > > > > -Dave > > > > > > > > > > On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck < > > > > andrewbeck0...@gmail.com> > > > > > wrote: > > > > > > > > > > > hey guys > > > > > > > > > > > > I am sitting here watching my cnc mill atm its shaking quite a > bit > > > > > > acceleration is 600mm/sec2 which is not that high i think. > > compared > > > > to >
Re: [Emc-users] jerk control
Default is 50... These are what can be tweeked in the tp.. http://linuxcnc.org/docs/2.8/html/config/ini-config.html#sec:traj-section On Tue, Aug 17, 2021, 8:49 PM Feral Engineer wrote: > I'm curious what the current level of block lookahead is on lcnc compared > to commercial controls. Anyone know the amount of data buffering that it > can handle? > > Phil T. > The Feral Engineer > > Check out my LinuxCNC tutorials, machine builds and other antics at > www.youtube.com/c/theferalengineer > > Help support my channel efforts and coffee addiction: > www.patreon.com/theferalengineer > > On Tue, Aug 17, 2021, 9:36 PM Sam Sokolik wrote: > > > It would be the same setup... Just using servo amps.. Velocity out of > > the pid - position back from the encoders. > > > > On Tue, Aug 17, 2021, 8:14 PM andrew beck > > wrote: > > > > > Not sure Sam. > > > > > > I have a 7i77 on this mill though also. So analog control > > > > > > On Wed, Aug 18, 2021, 12:51 PM Sam Sokolik wrote: > > > > > > > I am going to ask a stuid question.. If you have a velocity run step > > gen > > > > with pid. Couldn't you hook a limit3 between the pid and steghen. > > > > Because the input is velocity instead of position - wouldn't the > > > > acceleration limit in the limit3 be jerk instead of acceleration? I > > am > > > > sure it doesn't work that way.. I was just thinking you have moved > the > > > > derivatives up one.. > > > > > > > > (I can tell you it doesn't seem to work in practice - probably > because > > > the > > > > pid will always try to correct the error. Like maybe you would need > to > > > > negate the limit3 amount on the feedback side..) > > > > > > > > On Tue, Aug 17, 2021 at 1:28 PM Scott Harwell via Emc-users < > > > > emc-users@lists.sourceforge.net> wrote: > > > > > > > > > I haven't tried it yet, but this looks promising. > > > > > LinuxCNC S-Curve Accelerations > > > > > > > > > > > > > > > > > > > > Scott H > > > > > > > > > > > > > > > On Tuesday, August 17, 2021, 12:57:06 PM CDT, Ralph Stirling < > > > > > ralph.stirl...@wallawalla.edu> wrote: > > > > > > > > > > I've also been hoping to see this appear in a Linuxcnc update, > > > > > as it has been worked on by a number of people for years. > > > > > Here are the most recent threads about jerk-limited trajectory > > > planning: > > > > > > > > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/24-hal-components/40152-jerk-limited-trajectory-planner-hal-component > > > > > > > > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/38-general-linuxcnc-questions/34666-c2-smooth-velocity-profile?start=0 > > > > > > > > > > -- Ralph > > > > > > > > > > From: David Berndt [ber...@uberwin.com] > > > > > Sent: Tuesday, August 17, 2021 9:01 AM > > > > > To: Enhanced Machine Controller (EMC); andrew beck > > > > > Subject: Re: [Emc-users] jerk control > > > > > > > > > > CAUTION: This email originated from outside the Walla Walla > > University > > > > > email system. > > > > > > > > > > > > > > > I don't have a great need for it with my machines, or the > time/brains > > > to > > > > > implement it. It just seems like a feature we really should have. > > > > > > > > > > I'd be willing to participate monetarily in some sort of system > to > > > > > incentivize the inclusion of jerk control. Perhaps an open-source > > > feature > > > > > bounty? Does the community want to consider that sort of thing? > > > > > > > > > > -Dave > > > > > > > > > > On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck < > > > > andrewbeck0...@gmail.com> > > > > > wrote: > > > > > > > > > > > hey guys > > > > > > > > > > > > I am sitting here watching my cnc mill atm its shaking quite a > bit > > > > > > acceleration is 600mm/sec2 which
Re: [Emc-users] jerk control
I'm curious what the current level of block lookahead is on lcnc compared to commercial controls. Anyone know the amount of data buffering that it can handle? Phil T. The Feral Engineer Check out my LinuxCNC tutorials, machine builds and other antics at www.youtube.com/c/theferalengineer Help support my channel efforts and coffee addiction: www.patreon.com/theferalengineer On Tue, Aug 17, 2021, 9:36 PM Sam Sokolik wrote: > It would be the same setup... Just using servo amps.. Velocity out of > the pid - position back from the encoders. > > On Tue, Aug 17, 2021, 8:14 PM andrew beck > wrote: > > > Not sure Sam. > > > > I have a 7i77 on this mill though also. So analog control > > > > On Wed, Aug 18, 2021, 12:51 PM Sam Sokolik wrote: > > > > > I am going to ask a stuid question.. If you have a velocity run step > gen > > > with pid. Couldn't you hook a limit3 between the pid and steghen. > > > Because the input is velocity instead of position - wouldn't the > > > acceleration limit in the limit3 be jerk instead of acceleration? I > am > > > sure it doesn't work that way.. I was just thinking you have moved the > > > derivatives up one.. > > > > > > (I can tell you it doesn't seem to work in practice - probably because > > the > > > pid will always try to correct the error. Like maybe you would need to > > > negate the limit3 amount on the feedback side..) > > > > > > On Tue, Aug 17, 2021 at 1:28 PM Scott Harwell via Emc-users < > > > emc-users@lists.sourceforge.net> wrote: > > > > > > > I haven't tried it yet, but this looks promising. > > > > LinuxCNC S-Curve Accelerations > > > > > > > > > > > > > > > > Scott H > > > > > > > > > > > > On Tuesday, August 17, 2021, 12:57:06 PM CDT, Ralph Stirling < > > > > ralph.stirl...@wallawalla.edu> wrote: > > > > > > > > I've also been hoping to see this appear in a Linuxcnc update, > > > > as it has been worked on by a number of people for years. > > > > Here are the most recent threads about jerk-limited trajectory > > planning: > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/24-hal-components/40152-jerk-limited-trajectory-planner-hal-component > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/38-general-linuxcnc-questions/34666-c2-smooth-velocity-profile?start=0 > > > > > > > > -- Ralph > > > > > > > > From: David Berndt [ber...@uberwin.com] > > > > Sent: Tuesday, August 17, 2021 9:01 AM > > > > To: Enhanced Machine Controller (EMC); andrew beck > > > > Subject: Re: [Emc-users] jerk control > > > > > > > > CAUTION: This email originated from outside the Walla Walla > University > > > > email system. > > > > > > > > > > > > I don't have a great need for it with my machines, or the time/brains > > to > > > > implement it. It just seems like a feature we really should have. > > > > > > > > I'd be willing to participate monetarily in some sort of system to > > > > incentivize the inclusion of jerk control. Perhaps an open-source > > feature > > > > bounty? Does the community want to consider that sort of thing? > > > > > > > > -Dave > > > > > > > > On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck < > > > andrewbeck0...@gmail.com> > > > > wrote: > > > > > > > > > hey guys > > > > > > > > > > I am sitting here watching my cnc mill atm its shaking quite a bit > > > > > acceleration is 600mm/sec2 which is not that high i think. > compared > > > to > > > > > every other cnc mill i have used with a commercial controller. > they > > > have > > > > > jerk control and work much better. so looking forward to when we > get > > > > > jerk > > > > > control here on linuxcnc! > > > > > > > > > > but in the mean time i need a poor mans jerk control and thinking > of > > a > > > > > limit on the pid output to chop down the initial acceleration for > the > > > > > first > > > > > moment in time just so little moves don't shake it to death >
Re: [Emc-users] jerk control
Well if anyone has some time examples on how this would work I can make a test config on my machine On Wed, Aug 18, 2021, 1:36 PM Sam Sokolik wrote: > It would be the same setup... Just using servo amps.. Velocity out of > the pid - position back from the encoders. > > On Tue, Aug 17, 2021, 8:14 PM andrew beck > wrote: > > > Not sure Sam. > > > > I have a 7i77 on this mill though also. So analog control > > > > On Wed, Aug 18, 2021, 12:51 PM Sam Sokolik wrote: > > > > > I am going to ask a stuid question.. If you have a velocity run step > gen > > > with pid. Couldn't you hook a limit3 between the pid and steghen. > > > Because the input is velocity instead of position - wouldn't the > > > acceleration limit in the limit3 be jerk instead of acceleration? I > am > > > sure it doesn't work that way.. I was just thinking you have moved the > > > derivatives up one.. > > > > > > (I can tell you it doesn't seem to work in practice - probably because > > the > > > pid will always try to correct the error. Like maybe you would need to > > > negate the limit3 amount on the feedback side..) > > > > > > On Tue, Aug 17, 2021 at 1:28 PM Scott Harwell via Emc-users < > > > emc-users@lists.sourceforge.net> wrote: > > > > > > > I haven't tried it yet, but this looks promising. > > > > LinuxCNC S-Curve Accelerations > > > > > > > > > > > > > > > > Scott H > > > > > > > > > > > > On Tuesday, August 17, 2021, 12:57:06 PM CDT, Ralph Stirling < > > > > ralph.stirl...@wallawalla.edu> wrote: > > > > > > > > I've also been hoping to see this appear in a Linuxcnc update, > > > > as it has been worked on by a number of people for years. > > > > Here are the most recent threads about jerk-limited trajectory > > planning: > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/24-hal-components/40152-jerk-limited-trajectory-planner-hal-component > > > > > > > > > > > > > > > > > > https://forum.linuxcnc.org/38-general-linuxcnc-questions/34666-c2-smooth-velocity-profile?start=0 > > > > > > > > -- Ralph > > > > > > > > From: David Berndt [ber...@uberwin.com] > > > > Sent: Tuesday, August 17, 2021 9:01 AM > > > > To: Enhanced Machine Controller (EMC); andrew beck > > > > Subject: Re: [Emc-users] jerk control > > > > > > > > CAUTION: This email originated from outside the Walla Walla > University > > > > email system. > > > > > > > > > > > > I don't have a great need for it with my machines, or the time/brains > > to > > > > implement it. It just seems like a feature we really should have. > > > > > > > > I'd be willing to participate monetarily in some sort of system to > > > > incentivize the inclusion of jerk control. Perhaps an open-source > > feature > > > > bounty? Does the community want to consider that sort of thing? > > > > > > > > -Dave > > > > > > > > On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck < > > > andrewbeck0...@gmail.com> > > > > wrote: > > > > > > > > > hey guys > > > > > > > > > > I am sitting here watching my cnc mill atm its shaking quite a bit > > > > > acceleration is 600mm/sec2 which is not that high i think. > compared > > > to > > > > > every other cnc mill i have used with a commercial controller. > they > > > have > > > > > jerk control and work much better. so looking forward to when we > get > > > > > jerk > > > > > control here on linuxcnc! > > > > > > > > > > but in the mean time i need a poor mans jerk control and thinking > of > > a > > > > > limit on the pid output to chop down the initial acceleration for > the > > > > > first > > > > > moment in time just so little moves don't shake it to death > > > > > > > > > > andy mentioned that I could maybe use a limit component to limit > the > > > > > initial acceleration for the first tiny moment in time to cut down > on > > > the > > > > > vibrations. > > > > >
Re: [Emc-users] jerk control
It would be the same setup... Just using servo amps.. Velocity out of the pid - position back from the encoders. On Tue, Aug 17, 2021, 8:14 PM andrew beck wrote: > Not sure Sam. > > I have a 7i77 on this mill though also. So analog control > > On Wed, Aug 18, 2021, 12:51 PM Sam Sokolik wrote: > > > I am going to ask a stuid question.. If you have a velocity run step gen > > with pid. Couldn't you hook a limit3 between the pid and steghen. > > Because the input is velocity instead of position - wouldn't the > > acceleration limit in the limit3 be jerk instead of acceleration? I am > > sure it doesn't work that way.. I was just thinking you have moved the > > derivatives up one.. > > > > (I can tell you it doesn't seem to work in practice - probably because > the > > pid will always try to correct the error. Like maybe you would need to > > negate the limit3 amount on the feedback side..) > > > > On Tue, Aug 17, 2021 at 1:28 PM Scott Harwell via Emc-users < > > emc-users@lists.sourceforge.net> wrote: > > > > > I haven't tried it yet, but this looks promising. > > > LinuxCNC S-Curve Accelerations > > > > > > > > > > > > Scott H > > > > > > > > > On Tuesday, August 17, 2021, 12:57:06 PM CDT, Ralph Stirling < > > > ralph.stirl...@wallawalla.edu> wrote: > > > > > > I've also been hoping to see this appear in a Linuxcnc update, > > > as it has been worked on by a number of people for years. > > > Here are the most recent threads about jerk-limited trajectory > planning: > > > > > > > > > > > > https://forum.linuxcnc.org/24-hal-components/40152-jerk-limited-trajectory-planner-hal-component > > > > > > > > > > > > https://forum.linuxcnc.org/38-general-linuxcnc-questions/34666-c2-smooth-velocity-profile?start=0 > > > > > > -- Ralph > > > > > > From: David Berndt [ber...@uberwin.com] > > > Sent: Tuesday, August 17, 2021 9:01 AM > > > To: Enhanced Machine Controller (EMC); andrew beck > > > Subject: Re: [Emc-users] jerk control > > > > > > CAUTION: This email originated from outside the Walla Walla University > > > email system. > > > > > > > > > I don't have a great need for it with my machines, or the time/brains > to > > > implement it. It just seems like a feature we really should have. > > > > > > I'd be willing to participate monetarily in some sort of system to > > > incentivize the inclusion of jerk control. Perhaps an open-source > feature > > > bounty? Does the community want to consider that sort of thing? > > > > > > -Dave > > > > > > On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck < > > andrewbeck0...@gmail.com> > > > wrote: > > > > > > > hey guys > > > > > > > > I am sitting here watching my cnc mill atm its shaking quite a bit > > > > acceleration is 600mm/sec2 which is not that high i think. compared > > to > > > > every other cnc mill i have used with a commercial controller. they > > have > > > > jerk control and work much better. so looking forward to when we get > > > > jerk > > > > control here on linuxcnc! > > > > > > > > but in the mean time i need a poor mans jerk control and thinking of > a > > > > limit on the pid output to chop down the initial acceleration for the > > > > first > > > > moment in time just so little moves don't shake it to death > > > > > > > > andy mentioned that I could maybe use a limit component to limit the > > > > initial acceleration for the first tiny moment in time to cut down on > > the > > > > vibrations. > > > > > > > > how do you guys think that could work? > > > > > > > > Regards > > > > > > > > Andrew > > > > > > > > ___ > > > > Emc-users mailing list > > > > Emc-users@lists.sourceforge.net > > > > > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-users=04%7C01%7Cralph.stirling%40wallawalla.edu%7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
Re: [Emc-users] jerk control
Not sure Sam. I have a 7i77 on this mill though also. So analog control On Wed, Aug 18, 2021, 12:51 PM Sam Sokolik wrote: > I am going to ask a stuid question.. If you have a velocity run step gen > with pid. Couldn't you hook a limit3 between the pid and steghen. > Because the input is velocity instead of position - wouldn't the > acceleration limit in the limit3 be jerk instead of acceleration? I am > sure it doesn't work that way.. I was just thinking you have moved the > derivatives up one.. > > (I can tell you it doesn't seem to work in practice - probably because the > pid will always try to correct the error. Like maybe you would need to > negate the limit3 amount on the feedback side..) > > On Tue, Aug 17, 2021 at 1:28 PM Scott Harwell via Emc-users < > emc-users@lists.sourceforge.net> wrote: > > > I haven't tried it yet, but this looks promising. > > LinuxCNC S-Curve Accelerations > > > > > > > > Scott H > > > > > > On Tuesday, August 17, 2021, 12:57:06 PM CDT, Ralph Stirling < > > ralph.stirl...@wallawalla.edu> wrote: > > > > I've also been hoping to see this appear in a Linuxcnc update, > > as it has been worked on by a number of people for years. > > Here are the most recent threads about jerk-limited trajectory planning: > > > > > > > https://forum.linuxcnc.org/24-hal-components/40152-jerk-limited-trajectory-planner-hal-component > > > > > > > https://forum.linuxcnc.org/38-general-linuxcnc-questions/34666-c2-smooth-velocity-profile?start=0 > > > > -- Ralph > > ________________ > > From: David Berndt [ber...@uberwin.com] > > Sent: Tuesday, August 17, 2021 9:01 AM > > To: Enhanced Machine Controller (EMC); andrew beck > > Subject: Re: [Emc-users] jerk control > > > > CAUTION: This email originated from outside the Walla Walla University > > email system. > > > > > > I don't have a great need for it with my machines, or the time/brains to > > implement it. It just seems like a feature we really should have. > > > > I'd be willing to participate monetarily in some sort of system to > > incentivize the inclusion of jerk control. Perhaps an open-source feature > > bounty? Does the community want to consider that sort of thing? > > > > -Dave > > > > On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck < > andrewbeck0...@gmail.com> > > wrote: > > > > > hey guys > > > > > > I am sitting here watching my cnc mill atm its shaking quite a bit > > > acceleration is 600mm/sec2 which is not that high i think. compared > to > > > every other cnc mill i have used with a commercial controller. they > have > > > jerk control and work much better. so looking forward to when we get > > > jerk > > > control here on linuxcnc! > > > > > > but in the mean time i need a poor mans jerk control and thinking of a > > > limit on the pid output to chop down the initial acceleration for the > > > first > > > moment in time just so little moves don't shake it to death > > > > > > andy mentioned that I could maybe use a limit component to limit the > > > initial acceleration for the first tiny moment in time to cut down on > the > > > vibrations. > > > > > > how do you guys think that could work? > > > > > > Regards > > > > > > Andrew > > > > > > ___ > > > Emc-users mailing list > > > Emc-users@lists.sourceforge.net > > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-users=04%7C01%7Cralph.stirling%40wallawalla.edu%7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3D=0 > > > > > > ___ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-users=04%7C01%7Cralph.stirling%40wallawalla.edu%7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3D=0 > > > > > > ___ > > 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 > > > > ___ > 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
Re: [Emc-users] jerk control
I am going to ask a stuid question.. If you have a velocity run step gen with pid. Couldn't you hook a limit3 between the pid and steghen. Because the input is velocity instead of position - wouldn't the acceleration limit in the limit3 be jerk instead of acceleration? I am sure it doesn't work that way.. I was just thinking you have moved the derivatives up one.. (I can tell you it doesn't seem to work in practice - probably because the pid will always try to correct the error. Like maybe you would need to negate the limit3 amount on the feedback side..) On Tue, Aug 17, 2021 at 1:28 PM Scott Harwell via Emc-users < emc-users@lists.sourceforge.net> wrote: > I haven't tried it yet, but this looks promising. > LinuxCNC S-Curve Accelerations > > > > Scott H > > > On Tuesday, August 17, 2021, 12:57:06 PM CDT, Ralph Stirling < > ralph.stirl...@wallawalla.edu> wrote: > > I've also been hoping to see this appear in a Linuxcnc update, > as it has been worked on by a number of people for years. > Here are the most recent threads about jerk-limited trajectory planning: > > > https://forum.linuxcnc.org/24-hal-components/40152-jerk-limited-trajectory-planner-hal-component > > > https://forum.linuxcnc.org/38-general-linuxcnc-questions/34666-c2-smooth-velocity-profile?start=0 > > -- Ralph > > From: David Berndt [ber...@uberwin.com] > Sent: Tuesday, August 17, 2021 9:01 AM > To: Enhanced Machine Controller (EMC); andrew beck > Subject: Re: [Emc-users] jerk control > > CAUTION: This email originated from outside the Walla Walla University > email system. > > > I don't have a great need for it with my machines, or the time/brains to > implement it. It just seems like a feature we really should have. > > I'd be willing to participate monetarily in some sort of system to > incentivize the inclusion of jerk control. Perhaps an open-source feature > bounty? Does the community want to consider that sort of thing? > > -Dave > > On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck > wrote: > > > hey guys > > > > I am sitting here watching my cnc mill atm its shaking quite a bit > > acceleration is 600mm/sec2 which is not that high i think. compared to > > every other cnc mill i have used with a commercial controller. they have > > jerk control and work much better. so looking forward to when we get > > jerk > > control here on linuxcnc! > > > > but in the mean time i need a poor mans jerk control and thinking of a > > limit on the pid output to chop down the initial acceleration for the > > first > > moment in time just so little moves don't shake it to death > > > > andy mentioned that I could maybe use a limit component to limit the > > initial acceleration for the first tiny moment in time to cut down on the > > vibrations. > > > > how do you guys think that could work? > > > > Regards > > > > Andrew > > > > ___ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-users=04%7C01%7Cralph.stirling%40wallawalla.edu%7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3D=0 > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-users=04%7C01%7Cralph.stirling%40wallawalla.edu%7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3D=0 > > > ___ > 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 > ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
I haven't tried it yet, but this looks promising. LinuxCNC S-Curve Accelerations Scott H On Tuesday, August 17, 2021, 12:57:06 PM CDT, Ralph Stirling wrote: I've also been hoping to see this appear in a Linuxcnc update, as it has been worked on by a number of people for years. Here are the most recent threads about jerk-limited trajectory planning: https://forum.linuxcnc.org/24-hal-components/40152-jerk-limited-trajectory-planner-hal-component https://forum.linuxcnc.org/38-general-linuxcnc-questions/34666-c2-smooth-velocity-profile?start=0 -- Ralph From: David Berndt [ber...@uberwin.com] Sent: Tuesday, August 17, 2021 9:01 AM To: Enhanced Machine Controller (EMC); andrew beck Subject: Re: [Emc-users] jerk control CAUTION: This email originated from outside the Walla Walla University email system. I don't have a great need for it with my machines, or the time/brains to implement it. It just seems like a feature we really should have. I'd be willing to participate monetarily in some sort of system to incentivize the inclusion of jerk control. Perhaps an open-source feature bounty? Does the community want to consider that sort of thing? -Dave On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck wrote: > hey guys > > I am sitting here watching my cnc mill atm its shaking quite a bit > acceleration is 600mm/sec2 which is not that high i think. compared to > every other cnc mill i have used with a commercial controller. they have > jerk control and work much better. so looking forward to when we get > jerk > control here on linuxcnc! > > but in the mean time i need a poor mans jerk control and thinking of a > limit on the pid output to chop down the initial acceleration for the > first > moment in time just so little moves don't shake it to death > > andy mentioned that I could maybe use a limit component to limit the > initial acceleration for the first tiny moment in time to cut down on the > vibrations. > > how do you guys think that could work? > > Regards > > Andrew > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-users=04%7C01%7Cralph.stirling%40wallawalla.edu%7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3D=0 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-users=04%7C01%7Cralph.stirling%40wallawalla.edu%7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3D=0 ___ 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
Re: [Emc-users] jerk control
tormach did something to the planner, does anyone know what they paid for it, and how / who they commissioned to do it? On Tue, 17 Aug 2021, 18:57 Ralph Stirling, wrote: > I've also been hoping to see this appear in a Linuxcnc update, > as it has been worked on by a number of people for years. > Here are the most recent threads about jerk-limited trajectory planning: > > > https://forum.linuxcnc.org/24-hal-components/40152-jerk-limited-trajectory-planner-hal-component > > > https://forum.linuxcnc.org/38-general-linuxcnc-questions/34666-c2-smooth-velocity-profile?start=0 > > -- Ralph > > From: David Berndt [ber...@uberwin.com] > Sent: Tuesday, August 17, 2021 9:01 AM > To: Enhanced Machine Controller (EMC); andrew beck > Subject: Re: [Emc-users] jerk control > > CAUTION: This email originated from outside the Walla Walla University > email system. > > > I don't have a great need for it with my machines, or the time/brains to > implement it. It just seems like a feature we really should have. > > I'd be willing to participate monetarily in some sort of system to > incentivize the inclusion of jerk control. Perhaps an open-source feature > bounty? Does the community want to consider that sort of thing? > > -Dave > > On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck > wrote: > > > hey guys > > > > I am sitting here watching my cnc mill atm its shaking quite a bit > > acceleration is 600mm/sec2 which is not that high i think. compared to > > every other cnc mill i have used with a commercial controller. they have > > jerk control and work much better. so looking forward to when we get > > jerk > > control here on linuxcnc! > > > > but in the mean time i need a poor mans jerk control and thinking of a > > limit on the pid output to chop down the initial acceleration for the > > first > > moment in time just so little moves don't shake it to death > > > > andy mentioned that I could maybe use a limit component to limit the > > initial acceleration for the first tiny moment in time to cut down on the > > vibrations. > > > > how do you guys think that could work? > > > > Regards > > > > Andrew > > > > ___ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3Dreserved=0 > > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3Dreserved=0 > > > ___ > 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
Re: [Emc-users] jerk control
I've also been hoping to see this appear in a Linuxcnc update, as it has been worked on by a number of people for years. Here are the most recent threads about jerk-limited trajectory planning: https://forum.linuxcnc.org/24-hal-components/40152-jerk-limited-trajectory-planner-hal-component https://forum.linuxcnc.org/38-general-linuxcnc-questions/34666-c2-smooth-velocity-profile?start=0 -- Ralph From: David Berndt [ber...@uberwin.com] Sent: Tuesday, August 17, 2021 9:01 AM To: Enhanced Machine Controller (EMC); andrew beck Subject: Re: [Emc-users] jerk control CAUTION: This email originated from outside the Walla Walla University email system. I don't have a great need for it with my machines, or the time/brains to implement it. It just seems like a feature we really should have. I'd be willing to participate monetarily in some sort of system to incentivize the inclusion of jerk control. Perhaps an open-source feature bounty? Does the community want to consider that sort of thing? -Dave On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck wrote: > hey guys > > I am sitting here watching my cnc mill atm its shaking quite a bit > acceleration is 600mm/sec2 which is not that high i think. compared to > every other cnc mill i have used with a commercial controller. they have > jerk control and work much better. so looking forward to when we get > jerk > control here on linuxcnc! > > but in the mean time i need a poor mans jerk control and thinking of a > limit on the pid output to chop down the initial acceleration for the > first > moment in time just so little moves don't shake it to death > > andy mentioned that I could maybe use a limit component to limit the > initial acceleration for the first tiny moment in time to cut down on the > vibrations. > > how do you guys think that could work? > > Regards > > Andrew > > ___ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3Dreserved=0 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Femc-usersdata=04%7C01%7Cralph.stirling%40wallawalla.edu%7C7457b9607a2d4747a1e508d961a1b508%7Cd958f048e43142779c8debfb75e7aa64%7C0%7C0%7C637648169423748846%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=ue%2BwIaVhfay08NBevlCAvyOoNp0qVz9ojUuigRuCOOs%3Dreserved=0 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
I don't have a great need for it with my machines, or the time/brains to implement it. It just seems like a feature we really should have. I'd be willing to participate monetarily in some sort of system to incentivize the inclusion of jerk control. Perhaps an open-source feature bounty? Does the community want to consider that sort of thing? -Dave On Mon, 16 Aug 2021 23:06:05 -0400, andrew beck wrote: hey guys I am sitting here watching my cnc mill atm its shaking quite a bit acceleration is 600mm/sec2 which is not that high i think. compared to every other cnc mill i have used with a commercial controller. they have jerk control and work much better. so looking forward to when we get jerk control here on linuxcnc! but in the mean time i need a poor mans jerk control and thinking of a limit on the pid output to chop down the initial acceleration for the first moment in time just so little moves don't shake it to death andy mentioned that I could maybe use a limit component to limit the initial acceleration for the first tiny moment in time to cut down on the vibrations. how do you guys think that could work? Regards Andrew ___ 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
Re: [Emc-users] jerk control
Forgot to say this is metric of course On Tue, Aug 17, 2021, 3:53 PM andrew beck wrote: > Yep g64 p. 01. > > This is a high speed vmc so I can't really afford to blend the path more > than this > > On Tue, Aug 17, 2021, 3:48 PM Curtis Dutton wrote: > >> Are you using any G64 P- Q- path blending? >> >> On Mon, Aug 16, 2021, 11:19 PM andrew beck >> wrote: >> >> > hey guys >> > >> > I am sitting here watching my cnc mill atm its shaking quite a bit >> > acceleration is 600mm/sec2 which is not that high i think. compared to >> > every other cnc mill i have used with a commercial controller. they >> have >> > jerk control and work much better. so looking forward to when we get >> jerk >> > control here on linuxcnc! >> > >> > but in the mean time i need a poor mans jerk control and thinking of a >> > limit on the pid output to chop down the initial acceleration for the >> first >> > moment in time just so little moves don't shake it to death >> > >> > andy mentioned that I could maybe use a limit component to limit the >> > initial acceleration for the first tiny moment in time to cut down on >> the >> > vibrations. >> > >> > how do you guys think that could work? >> > >> > Regards >> > >> > Andrew >> > >> > ___ >> > 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 >> > ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
It's pretty much a slightly beefier haas vf2 This is a chevalier 2040 vmc On Tue, Aug 17, 2021, 3:53 PM andrew beck wrote: > Yep g64 p. 01. > > This is a high speed vmc so I can't really afford to blend the path more > than this > > On Tue, Aug 17, 2021, 3:48 PM Curtis Dutton wrote: > >> Are you using any G64 P- Q- path blending? >> >> On Mon, Aug 16, 2021, 11:19 PM andrew beck >> wrote: >> >> > hey guys >> > >> > I am sitting here watching my cnc mill atm its shaking quite a bit >> > acceleration is 600mm/sec2 which is not that high i think. compared to >> > every other cnc mill i have used with a commercial controller. they >> have >> > jerk control and work much better. so looking forward to when we get >> jerk >> > control here on linuxcnc! >> > >> > but in the mean time i need a poor mans jerk control and thinking of a >> > limit on the pid output to chop down the initial acceleration for the >> first >> > moment in time just so little moves don't shake it to death >> > >> > andy mentioned that I could maybe use a limit component to limit the >> > initial acceleration for the first tiny moment in time to cut down on >> the >> > vibrations. >> > >> > how do you guys think that could work? >> > >> > Regards >> > >> > Andrew >> > >> > ___ >> > 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 >> > ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
Yep g64 p. 01. This is a high speed vmc so I can't really afford to blend the path more than this On Tue, Aug 17, 2021, 3:48 PM Curtis Dutton wrote: > Are you using any G64 P- Q- path blending? > > On Mon, Aug 16, 2021, 11:19 PM andrew beck > wrote: > > > hey guys > > > > I am sitting here watching my cnc mill atm its shaking quite a bit > > acceleration is 600mm/sec2 which is not that high i think. compared to > > every other cnc mill i have used with a commercial controller. they have > > jerk control and work much better. so looking forward to when we get > jerk > > control here on linuxcnc! > > > > but in the mean time i need a poor mans jerk control and thinking of a > > limit on the pid output to chop down the initial acceleration for the > first > > moment in time just so little moves don't shake it to death > > > > andy mentioned that I could maybe use a limit component to limit the > > initial acceleration for the first tiny moment in time to cut down on the > > vibrations. > > > > how do you guys think that could work? > > > > Regards > > > > Andrew > > > > ___ > > 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 > ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control
Are you using any G64 P- Q- path blending? On Mon, Aug 16, 2021, 11:19 PM andrew beck wrote: > hey guys > > I am sitting here watching my cnc mill atm its shaking quite a bit > acceleration is 600mm/sec2 which is not that high i think. compared to > every other cnc mill i have used with a commercial controller. they have > jerk control and work much better. so looking forward to when we get jerk > control here on linuxcnc! > > but in the mean time i need a poor mans jerk control and thinking of a > limit on the pid output to chop down the initial acceleration for the first > moment in time just so little moves don't shake it to death > > andy mentioned that I could maybe use a limit component to limit the > initial acceleration for the first tiny moment in time to cut down on the > vibrations. > > how do you guys think that could work? > > Regards > > Andrew > > ___ > 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
[Emc-users] jerk control
hey guys I am sitting here watching my cnc mill atm its shaking quite a bit acceleration is 600mm/sec2 which is not that high i think. compared to every other cnc mill i have used with a commercial controller. they have jerk control and work much better. so looking forward to when we get jerk control here on linuxcnc! but in the mean time i need a poor mans jerk control and thinking of a limit on the pid output to chop down the initial acceleration for the first moment in time just so little moves don't shake it to death andy mentioned that I could maybe use a limit component to limit the initial acceleration for the first tiny moment in time to cut down on the vibrations. how do you guys think that could work? Regards Andrew ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control for high speed machines -->
Yes I already turned them down. Currently running max velocity at 8m/min and 750mm/sec2 I think. Which is way slower than it used to run. On Wed, Sep 23, 2020, 5:50 AM N wrote: > There are limits in trajectory planner adjustable in .ini file > DEFAULT_ACCELERATION= and MAX_ACCELERATION= you tried them? > > > Hi again, > > Indeed it is pretty hard to use spindle load if is doesn't change thru > > the corner. I suspect it does on smaller machines but that is not a > > generalized solution. > > Just for experimental purposes it might be interesting to decrease the > > velocity thru a corner see if it helps. Lacking the adding another row > > to the matrix should control jerk but the may not be the whole solution > > when dealing with a change in direction. So much to learn so little time > > (and energy). > > I suspect the 'big boys' do some pretty fancy adaptation to get good > > smoothing thru the corners. Of course it is all propitiatory and those > > patents take a long time to run out. Silvia McFarland (sp?) in her > > masters thesis (Uni BC) used sin accel rather than trapezoidal. Might > > help. I think traj control get much more critical as velocities get > > really radical. Some of the new Brothers with 30 tapers absolutely > > scream. When the machinist describes stepping back from the machine when > > the tool moves toward him then is must be really impressive. > > > > Dave > > > > On 9/21/20 4:55 PM, andrew beck wrote: > > > hey dave > > > > > > I hear you. I might get good at coding myself soon.. but would love > to > > > solve the problem. > > > > > > I don't think the spindle load could really help much though. > > > > > > I am machining plastic and aluminium and the spindle load doesn't > > > noticeably change in corners. I more need a limit on the initial > > > acceleration for a split second I suppose > > > > > > or go the full way and have something that analyzes the G code path and > > > calculates the best speed and path for the machine > > > > > > regards > > > > > > Andrew > > > > > > regards > > > > > > > > > > > > On Tue, Sep 22, 2020 at 11:35 AM dave engvall > wrote: > > > > > >> HI Andrew, > > >> Just because I have ideas does not imply I can implement them. ;-) > > >> However, I believe there is a velocity pin that might be used to slow > > >> down in corners. Since the spindle loads up going thru corners it may > be > > >> possible to monitor spindle load and back off velocity thru the corner > > >> which should make milling a bit smoother. Adding jerk control > involves , > > >> as you know, adding another order to motion. (see first sentence). ;-) > > >> A lot of bright people are involved in linuxcnc but they all have > their > > >> own pet projects. Just the way it goes. > > >> Hang in there, your heart is in the right place. > > >> > > >> Dave > > >> > > >> On 9/20/20 8:19 PM, andrew beck wrote: > > >>> Hey guys > > >>> > > >>> just a few thoughts here. > > >>> > > >>> I have a high speed cnc machining center (cnc mill) > > >>> > > >>> it has 16mm pitch ballscrews and weighs 6ton > > >>> > > >>> linuxcnc is awesome and does a great job controlling it. I make > plastic > > >>> injection molds and lots of 3d machining all the time. plus all the > > >> little > > >>> jobs that a cnc is great for. > > >>> > > >>> I think the only thing lacking from linuxcnc for my use is some sort > of > > >>> jerk control for corners. there may already be something around that > > >>> solves the issue though without jerk control. so what happens is > when > > >> the > > >>> machine changes direction the whole machine vibrates and jumps > around. > > >> its > > >>> quite bad. enough that I may rubber mount the electrical box lol. > > >>> > > >>> I have accelerations of 750 (i think it is mm/sec2) > > >>> > > >>> and max rapids of 8m/min > > >>> > > >>> I would love to turn those up to like 25m/min rapid and 2000mm/sec2 > > >>> accelerations > > >>> > > >>> has any one tried any form of jerk control yet on linuxcnc? or > wants to > > >>> have a play and code it. I have 3 6 ton cnc machines that will all > use > > >>> linuxcnc so very keen to solve this jerk control issue. > > >>> > > >>> regards > > >>> > > >>> Andrew > > > ___ > 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
Re: [Emc-users] jerk control for high speed machines -->
There are limits in trajectory planner adjustable in .ini file DEFAULT_ACCELERATION= and MAX_ACCELERATION= you tried them? > Hi again, > Indeed it is pretty hard to use spindle load if is doesn't change thru > the corner. I suspect it does on smaller machines but that is not a > generalized solution. > Just for experimental purposes it might be interesting to decrease the > velocity thru a corner see if it helps. Lacking the adding another row > to the matrix should control jerk but the may not be the whole solution > when dealing with a change in direction. So much to learn so little time > (and energy). > I suspect the 'big boys' do some pretty fancy adaptation to get good > smoothing thru the corners. Of course it is all propitiatory and those > patents take a long time to run out. Silvia McFarland (sp?) in her > masters thesis (Uni BC) used sin accel rather than trapezoidal. Might > help. I think traj control get much more critical as velocities get > really radical. Some of the new Brothers with 30 tapers absolutely > scream. When the machinist describes stepping back from the machine when > the tool moves toward him then is must be really impressive. > > Dave > > On 9/21/20 4:55 PM, andrew beck wrote: > > hey dave > > > > I hear you. I might get good at coding myself soon.. but would love to > > solve the problem. > > > > I don't think the spindle load could really help much though. > > > > I am machining plastic and aluminium and the spindle load doesn't > > noticeably change in corners. I more need a limit on the initial > > acceleration for a split second I suppose > > > > or go the full way and have something that analyzes the G code path and > > calculates the best speed and path for the machine > > > > regards > > > > Andrew > > > > regards > > > > > > > > On Tue, Sep 22, 2020 at 11:35 AM dave engvall wrote: > > > >> HI Andrew, > >> Just because I have ideas does not imply I can implement them. ;-) > >> However, I believe there is a velocity pin that might be used to slow > >> down in corners. Since the spindle loads up going thru corners it may be > >> possible to monitor spindle load and back off velocity thru the corner > >> which should make milling a bit smoother. Adding jerk control involves , > >> as you know, adding another order to motion. (see first sentence). ;-) > >> A lot of bright people are involved in linuxcnc but they all have their > >> own pet projects. Just the way it goes. > >> Hang in there, your heart is in the right place. > >> > >> Dave > >> > >> On 9/20/20 8:19 PM, andrew beck wrote: > >>> Hey guys > >>> > >>> just a few thoughts here. > >>> > >>> I have a high speed cnc machining center (cnc mill) > >>> > >>> it has 16mm pitch ballscrews and weighs 6ton > >>> > >>> linuxcnc is awesome and does a great job controlling it. I make plastic > >>> injection molds and lots of 3d machining all the time. plus all the > >> little > >>> jobs that a cnc is great for. > >>> > >>> I think the only thing lacking from linuxcnc for my use is some sort of > >>> jerk control for corners. there may already be something around that > >>> solves the issue though without jerk control. so what happens is when > >> the > >>> machine changes direction the whole machine vibrates and jumps around. > >> its > >>> quite bad. enough that I may rubber mount the electrical box lol. > >>> > >>> I have accelerations of 750 (i think it is mm/sec2) > >>> > >>> and max rapids of 8m/min > >>> > >>> I would love to turn those up to like 25m/min rapid and 2000mm/sec2 > >>> accelerations > >>> > >>> has any one tried any form of jerk control yet on linuxcnc? or wants to > >>> have a play and code it. I have 3 6 ton cnc machines that will all use > >>> linuxcnc so very keen to solve this jerk control issue. > >>> > >>> regards > >>> > >>> Andrew ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control for high speed machines
On Tuesday 22 September 2020 02:30:21 dave engvall wrote: > Hi again, > Indeed it is pretty hard to use spindle load if is doesn't change thru > the corner. I suspect it does on smaller machines but that is not a > generalized solution. > Just for experimental purposes it might be interesting to decrease the > velocity thru a corner see if it helps. Lacking the adding another row > to the matrix should control jerk but the may not be the whole > solution when dealing with a change in direction. So much to learn so > little time (and energy). > I suspect the 'big boys' do some pretty fancy adaptation to get good > smoothing thru the corners. Of course it is all propitiatory and those > patents take a long time to run out. Silvia McFarland (sp?) in her > masters thesis (Uni BC) used sin accel rather than trapezoidal. The proper term for that is sine-squared, as we used it in broadcasting back in Never Twice Same Color days where you start at the peak of the waveform where the velocity change is zero, accelerate in the shape of a sine wave where velocity is greatest going thru the center of the move, and then following the same curve, wind up at max speed and keep on going as the peak of the curve is attained in the new direction. We used a test signal that started and ended at 7.5% black Done right, using a limit3 to try shaping it, the vfd on my rpi4 driven Sheldon lathe, can reverse the spindle direction of a 40 lb 4 jaw chuck with an overtravel of only .25 turns at 100 rpms. Chuck obviously is clamped to the spindle so it can't unscrew itself. It may go faster, but the belts slip some. Since I put the red link belts on it, they slip quietly, the badly worn stock v-belts yelped like Michelin tires on hot blacktop. I seriously need new pulleys, they have a good belly worn into them in their 70+ years of use. > Might > help. I think traj control get much more critical as velocities get > really radical. Some of the new Brothers with 30 tapers absolutely > scream. When the machinist describes stepping back from the machine > when the tool moves toward him then is must be really impressive. > > Dave > > On 9/21/20 4:55 PM, andrew beck wrote: > > hey dave > > > > I hear you. I might get good at coding myself soon.. but would > > love to solve the problem. > > > > I don't think the spindle load could really help much though. > > > > I am machining plastic and aluminium and the spindle load doesn't > > noticeably change in corners. I more need a limit on the initial > > acceleration for a split second I suppose > > > > or go the full way and have something that analyzes the G code path > > and calculates the best speed and path for the machine > > > > regards > > > > Andrew > > > > regards > > > > On Tue, Sep 22, 2020 at 11:35 AM dave engvall wrote: > >> HI Andrew, > >> Just because I have ideas does not imply I can implement them. ;-) > >> However, I believe there is a velocity pin that might be used to > >> slow down in corners. Since the spindle loads up going thru corners > >> it may be possible to monitor spindle load and back off velocity > >> thru the corner which should make milling a bit smoother. Adding > >> jerk control involves , as you know, adding another order to > >> motion. (see first sentence). ;-) A lot of bright people are > >> involved in linuxcnc but they all have their own pet projects. Just > >> the way it goes. > >> Hang in there, your heart is in the right place. > >> > >> Dave > >> > >> On 9/20/20 8:19 PM, andrew beck wrote: > >>> Hey guys > >>> > >>> just a few thoughts here. > >>> > >>> I have a high speed cnc machining center (cnc mill) > >>> > >>> it has 16mm pitch ballscrews and weighs 6ton > >>> > >>> linuxcnc is awesome and does a great job controlling it. I make > >>> plastic injection molds and lots of 3d machining all the time. > >>> plus all the > >> > >> little > >> > >>> jobs that a cnc is great for. > >>> > >>> I think the only thing lacking from linuxcnc for my use is some > >>> sort of jerk control for corners. there may already be something > >>> around that solves the issue though without jerk control. so what > >>> happens is when > >> > >> the > >> > >>> machine changes direction the whole machine vibrates and jumps > >>> around. > >> > >> its > >> > >>> quite bad. enough that I may rubber mount the electrical box lol. > >>> > >>> I have accelerations of 750 (i think it is mm/sec2) > >>> > >>> and max rapids of 8m/min > >>> > >>> I would love to turn those up to like 25m/min rapid and > >>> 2000mm/sec2 accelerations > >>> > >>> has any one tried any form of jerk control yet on linuxcnc? or > >>> wants to have a play and code it. I have 3 6 ton cnc machines > >>> that will all use linuxcnc so very keen to solve this jerk control > >>> issue. > >>> > >>> regards > >>> > >>> Andrew > >>> > >>> ___ > >>> Emc-users mailing list > >>> Emc-users@lists.sourceforge.net > >>>
Re: [Emc-users] jerk control for high speed machines
Hi again, Indeed it is pretty hard to use spindle load if is doesn't change thru the corner. I suspect it does on smaller machines but that is not a generalized solution. Just for experimental purposes it might be interesting to decrease the velocity thru a corner see if it helps. Lacking the adding another row to the matrix should control jerk but the may not be the whole solution when dealing with a change in direction. So much to learn so little time (and energy). I suspect the 'big boys' do some pretty fancy adaptation to get good smoothing thru the corners. Of course it is all propitiatory and those patents take a long time to run out. Silvia McFarland (sp?) in her masters thesis (Uni BC) used sin accel rather than trapezoidal. Might help. I think traj control get much more critical as velocities get really radical. Some of the new Brothers with 30 tapers absolutely scream. When the machinist describes stepping back from the machine when the tool moves toward him then is must be really impressive. Dave On 9/21/20 4:55 PM, andrew beck wrote: hey dave I hear you. I might get good at coding myself soon.. but would love to solve the problem. I don't think the spindle load could really help much though. I am machining plastic and aluminium and the spindle load doesn't noticeably change in corners. I more need a limit on the initial acceleration for a split second I suppose or go the full way and have something that analyzes the G code path and calculates the best speed and path for the machine regards Andrew regards On Tue, Sep 22, 2020 at 11:35 AM dave engvall wrote: HI Andrew, Just because I have ideas does not imply I can implement them. ;-) However, I believe there is a velocity pin that might be used to slow down in corners. Since the spindle loads up going thru corners it may be possible to monitor spindle load and back off velocity thru the corner which should make milling a bit smoother. Adding jerk control involves , as you know, adding another order to motion. (see first sentence). ;-) A lot of bright people are involved in linuxcnc but they all have their own pet projects. Just the way it goes. Hang in there, your heart is in the right place. Dave On 9/20/20 8:19 PM, andrew beck wrote: Hey guys just a few thoughts here. I have a high speed cnc machining center (cnc mill) it has 16mm pitch ballscrews and weighs 6ton linuxcnc is awesome and does a great job controlling it. I make plastic injection molds and lots of 3d machining all the time. plus all the little jobs that a cnc is great for. I think the only thing lacking from linuxcnc for my use is some sort of jerk control for corners. there may already be something around that solves the issue though without jerk control. so what happens is when the machine changes direction the whole machine vibrates and jumps around. its quite bad. enough that I may rubber mount the electrical box lol. I have accelerations of 750 (i think it is mm/sec2) and max rapids of 8m/min I would love to turn those up to like 25m/min rapid and 2000mm/sec2 accelerations has any one tried any form of jerk control yet on linuxcnc? or wants to have a play and code it. I have 3 6 ton cnc machines that will all use linuxcnc so very keen to solve this jerk control issue. regards Andrew ___ 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 ___ 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
Re: [Emc-users] jerk control for high speed machines
My first innocent thought was to use a DDT component somehow but I guess this involves fgpa programming if you're using Mesa boards. It sounded simple at first but as you think it through it you realize it's a pain in the ass. Mostly because my only fpga experience is controlling displays lol. I really need to resume my practicing with that digilent board someday... Leonardo Marsaglia El lun., 21 sep. 2020 21:00, andrew beck escribió: > hey dave > > I hear you. I might get good at coding myself soon.. but would love to > solve the problem. > > I don't think the spindle load could really help much though. > > I am machining plastic and aluminium and the spindle load doesn't > noticeably change in corners. I more need a limit on the initial > acceleration for a split second I suppose > > or go the full way and have something that analyzes the G code path and > calculates the best speed and path for the machine > > regards > > Andrew > > regards > > > > On Tue, Sep 22, 2020 at 11:35 AM dave engvall > wrote: > > > HI Andrew, > > Just because I have ideas does not imply I can implement them. ;-) > > However, I believe there is a velocity pin that might be used to slow > > down in corners. Since the spindle loads up going thru corners it may be > > possible to monitor spindle load and back off velocity thru the corner > > which should make milling a bit smoother. Adding jerk control involves , > > as you know, adding another order to motion. (see first sentence). ;-) > > A lot of bright people are involved in linuxcnc but they all have their > > own pet projects. Just the way it goes. > > Hang in there, your heart is in the right place. > > > > Dave > > > > On 9/20/20 8:19 PM, andrew beck wrote: > > > Hey guys > > > > > > just a few thoughts here. > > > > > > I have a high speed cnc machining center (cnc mill) > > > > > > it has 16mm pitch ballscrews and weighs 6ton > > > > > > linuxcnc is awesome and does a great job controlling it. I make > plastic > > > injection molds and lots of 3d machining all the time. plus all the > > little > > > jobs that a cnc is great for. > > > > > > I think the only thing lacking from linuxcnc for my use is some sort of > > > jerk control for corners. there may already be something around that > > > solves the issue though without jerk control. so what happens is when > > the > > > machine changes direction the whole machine vibrates and jumps around. > > its > > > quite bad. enough that I may rubber mount the electrical box lol. > > > > > > I have accelerations of 750 (i think it is mm/sec2) > > > > > > and max rapids of 8m/min > > > > > > I would love to turn those up to like 25m/min rapid and 2000mm/sec2 > > > accelerations > > > > > > has any one tried any form of jerk control yet on linuxcnc? or wants > to > > > have a play and code it. I have 3 6 ton cnc machines that will all use > > > linuxcnc so very keen to solve this jerk control issue. > > > > > > regards > > > > > > Andrew > > > > > > ___ > > > 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 > > > > ___ > 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
Re: [Emc-users] jerk control for high speed machines
hey dave I hear you. I might get good at coding myself soon.. but would love to solve the problem. I don't think the spindle load could really help much though. I am machining plastic and aluminium and the spindle load doesn't noticeably change in corners. I more need a limit on the initial acceleration for a split second I suppose or go the full way and have something that analyzes the G code path and calculates the best speed and path for the machine regards Andrew regards On Tue, Sep 22, 2020 at 11:35 AM dave engvall wrote: > HI Andrew, > Just because I have ideas does not imply I can implement them. ;-) > However, I believe there is a velocity pin that might be used to slow > down in corners. Since the spindle loads up going thru corners it may be > possible to monitor spindle load and back off velocity thru the corner > which should make milling a bit smoother. Adding jerk control involves , > as you know, adding another order to motion. (see first sentence). ;-) > A lot of bright people are involved in linuxcnc but they all have their > own pet projects. Just the way it goes. > Hang in there, your heart is in the right place. > > Dave > > On 9/20/20 8:19 PM, andrew beck wrote: > > Hey guys > > > > just a few thoughts here. > > > > I have a high speed cnc machining center (cnc mill) > > > > it has 16mm pitch ballscrews and weighs 6ton > > > > linuxcnc is awesome and does a great job controlling it. I make plastic > > injection molds and lots of 3d machining all the time. plus all the > little > > jobs that a cnc is great for. > > > > I think the only thing lacking from linuxcnc for my use is some sort of > > jerk control for corners. there may already be something around that > > solves the issue though without jerk control. so what happens is when > the > > machine changes direction the whole machine vibrates and jumps around. > its > > quite bad. enough that I may rubber mount the electrical box lol. > > > > I have accelerations of 750 (i think it is mm/sec2) > > > > and max rapids of 8m/min > > > > I would love to turn those up to like 25m/min rapid and 2000mm/sec2 > > accelerations > > > > has any one tried any form of jerk control yet on linuxcnc? or wants to > > have a play and code it. I have 3 6 ton cnc machines that will all use > > linuxcnc so very keen to solve this jerk control issue. > > > > regards > > > > Andrew > > > > ___ > > 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 > ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] jerk control for high speed machines
HI Andrew, Just because I have ideas does not imply I can implement them. ;-) However, I believe there is a velocity pin that might be used to slow down in corners. Since the spindle loads up going thru corners it may be possible to monitor spindle load and back off velocity thru the corner which should make milling a bit smoother. Adding jerk control involves , as you know, adding another order to motion. (see first sentence). ;-) A lot of bright people are involved in linuxcnc but they all have their own pet projects. Just the way it goes. Hang in there, your heart is in the right place. Dave On 9/20/20 8:19 PM, andrew beck wrote: Hey guys just a few thoughts here. I have a high speed cnc machining center (cnc mill) it has 16mm pitch ballscrews and weighs 6ton linuxcnc is awesome and does a great job controlling it. I make plastic injection molds and lots of 3d machining all the time. plus all the little jobs that a cnc is great for. I think the only thing lacking from linuxcnc for my use is some sort of jerk control for corners. there may already be something around that solves the issue though without jerk control. so what happens is when the machine changes direction the whole machine vibrates and jumps around. its quite bad. enough that I may rubber mount the electrical box lol. I have accelerations of 750 (i think it is mm/sec2) and max rapids of 8m/min I would love to turn those up to like 25m/min rapid and 2000mm/sec2 accelerations has any one tried any form of jerk control yet on linuxcnc? or wants to have a play and code it. I have 3 6 ton cnc machines that will all use linuxcnc so very keen to solve this jerk control issue. regards Andrew ___ 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
[Emc-users] jerk control for high speed machines
Hey guys just a few thoughts here. I have a high speed cnc machining center (cnc mill) it has 16mm pitch ballscrews and weighs 6ton linuxcnc is awesome and does a great job controlling it. I make plastic injection molds and lots of 3d machining all the time. plus all the little jobs that a cnc is great for. I think the only thing lacking from linuxcnc for my use is some sort of jerk control for corners. there may already be something around that solves the issue though without jerk control. so what happens is when the machine changes direction the whole machine vibrates and jumps around. its quite bad. enough that I may rubber mount the electrical box lol. I have accelerations of 750 (i think it is mm/sec2) and max rapids of 8m/min I would love to turn those up to like 25m/min rapid and 2000mm/sec2 accelerations has any one tried any form of jerk control yet on linuxcnc? or wants to have a play and code it. I have 3 6 ton cnc machines that will all use linuxcnc so very keen to solve this jerk control issue. regards Andrew ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
