Re: [Emc-users] torque mode tuning yaskawa servo drives
just a quick follow up to make this question more general for everyone i really just want a working config from someone that has the torque mode servo stuff in linuxcnc working. i am getting confused if i need two nested PID loops or if i can just use the default velocity control setup On Mon, Aug 30, 2021 at 2:57 PM andrew beck wrote: > hey everyone > > i am trying to tune my yaskawa sigma 1 series servo drive at the moment > and thinking about using torque mode for tuning. > > currently the process is auto tune drives to a rigidity setting and then > control drives with velocity reference in linuxcnc. I am not getting the > most amazing control and any P value over 8 means the drive starts > vibrating. i have tried a range of rigidity settings in servo drive > > i have never set up linuxcnc to control torque mode and just wondering if > what the correct way is? is it the same as velocity control in terms of > the pid loops and hal layer? or is there another whole level of stuff i > need to do > > and i saw that i needed to speed up the servo thread a bit to get better > performance if using torque mode > > anyway let me know your experiences > > regards > > Andrew > ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] torque mode tuning yaskawa servo drives
hey everyone i am trying to tune my yaskawa sigma 1 series servo drive at the moment and thinking about using torque mode for tuning. currently the process is auto tune drives to a rigidity setting and then control drives with velocity reference in linuxcnc. I am not getting the most amazing control and any P value over 8 means the drive starts vibrating. i have tried a range of rigidity settings in servo drive i have never set up linuxcnc to control torque mode and just wondering if what the correct way is? is it the same as velocity control in terms of the pid loops and hal layer? or is there another whole level of stuff i need to do and i saw that i needed to speed up the servo thread a bit to get better performance if using torque mode anyway let me know your experiences regards Andrew ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
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
