PID tuning and accelereation
26 Sep 2014 16:39 #51590
by akb1212
PID tuning and accelereation was created by akb1212
I have finally started the PID tuning in LCNC..... which I have to admit is one of the things I wasn't looking forward to.
The reason for this was my previous attempts at tuning it with a different controller. Not a pleasent experience really.....
To my relief tuning in LCNC was considerably easier compared to my previous experiences, much thanks to BigJohnT's excellent tuning manual. So a big thanks to JT for that!
But there are some minor things I see as possible to improve further.
The first is the lack of being able to change the acceleration while tuning. I'm not sure if this is left out on purpose or not. But from yesterdays' experience I found it to be an important factor to get correct! If it's set to high there’s no way you will be able to tune your axes.
In my case I think I set it somewhat high when I started the tuning process. I set it to 1000 mm/s^2, or about 0.1G, possibly a bit optimistic for my machine when seen in retrospect..... but in my case it wasn't so high as to prevent me from tuning and getting some results. I'd say it's more on the opposite side really. Having it set as high as I did made it easier to tune....
I found that out after having tuned to what looked like a decent result. I used only P, FF1 and FF2 as described, but ending up with FF1 and FF2 values at about 1/10th or so of the values given in the manual. But I guess that is ok.
Anyway, after having done tuning I did some quick jogging at full speed. In particular when I had it in continuous mode and pressed the jog button on and off as fast as I could it didn't look so good anymore!
The axis.x.f-error signal spiked to very high values, not anything like the low values it had when I did the tuning. I could feel it on the machine that it wasn't happy with it. If I’m correct this is also the signal that will trip the axis following error when I set the values back down to normal values in my ini file after tuning is done? So if my tuning isn’t able to bring this value down I’m not done tuning.
When I realized I need to lower my acceleration I looked for where to set that value in the tuning utility. But it wasn't there. I had to manually edit the ini file to correct this, and to my knowledge that means I need a complete restart of LCNC for the new values to be read. I guess the tuning feature is made to avoid having to do exactly this when doing PID tuning. Which is why I ask for this parameter to also be included in the parameters possible to be changed during PID tuning. After all it's a parameter that will affect the tuning, possibly even to an extent that will prevent tuning. And I don’t see a very important reason for it to not be in there.
I also believe it's a parameter that could be used actively during tuning? You tune to get oscillation by increasing the other values to find the needed values. In the same way it would be possible to set acceleration to a too high value. This would make tuning easier by bringing out and highlighting resonances and other characteristics on the mechanical system and make them easier to find. Then after tuning to remove as many of the resonances and unwanted behavior one can bring the acceleration back down to a more reasonable value. Then you will end up having a more precise tuned system?
My mill is a MahoMH600E (1990), and I'm replacing an old controller. This controller was already tuned, and I was trying to copy the setting from that. Now I don't know how to read out any of the PID values from my Philips 432 controller, but I was trying to measure the acceleration it used. But because of all the noise in the mechanical system I found that reading them out with an accelerometer was almost impossible. So I ended up taking a guess, which ended up being a bit on the optimistic side....
Any thoughts on if putting acceleration in as one of the parameters in the tuning application? Is it a good or a bad idea? I assume (or hope anyway) it would be a quick thing to implement for you guys who made the feature in the first place? If a decision to put in in there is made that is....
Anders
The reason for this was my previous attempts at tuning it with a different controller. Not a pleasent experience really.....
To my relief tuning in LCNC was considerably easier compared to my previous experiences, much thanks to BigJohnT's excellent tuning manual. So a big thanks to JT for that!
But there are some minor things I see as possible to improve further.
The first is the lack of being able to change the acceleration while tuning. I'm not sure if this is left out on purpose or not. But from yesterdays' experience I found it to be an important factor to get correct! If it's set to high there’s no way you will be able to tune your axes.
In my case I think I set it somewhat high when I started the tuning process. I set it to 1000 mm/s^2, or about 0.1G, possibly a bit optimistic for my machine when seen in retrospect..... but in my case it wasn't so high as to prevent me from tuning and getting some results. I'd say it's more on the opposite side really. Having it set as high as I did made it easier to tune....
I found that out after having tuned to what looked like a decent result. I used only P, FF1 and FF2 as described, but ending up with FF1 and FF2 values at about 1/10th or so of the values given in the manual. But I guess that is ok.
Anyway, after having done tuning I did some quick jogging at full speed. In particular when I had it in continuous mode and pressed the jog button on and off as fast as I could it didn't look so good anymore!
The axis.x.f-error signal spiked to very high values, not anything like the low values it had when I did the tuning. I could feel it on the machine that it wasn't happy with it. If I’m correct this is also the signal that will trip the axis following error when I set the values back down to normal values in my ini file after tuning is done? So if my tuning isn’t able to bring this value down I’m not done tuning.
When I realized I need to lower my acceleration I looked for where to set that value in the tuning utility. But it wasn't there. I had to manually edit the ini file to correct this, and to my knowledge that means I need a complete restart of LCNC for the new values to be read. I guess the tuning feature is made to avoid having to do exactly this when doing PID tuning. Which is why I ask for this parameter to also be included in the parameters possible to be changed during PID tuning. After all it's a parameter that will affect the tuning, possibly even to an extent that will prevent tuning. And I don’t see a very important reason for it to not be in there.
I also believe it's a parameter that could be used actively during tuning? You tune to get oscillation by increasing the other values to find the needed values. In the same way it would be possible to set acceleration to a too high value. This would make tuning easier by bringing out and highlighting resonances and other characteristics on the mechanical system and make them easier to find. Then after tuning to remove as many of the resonances and unwanted behavior one can bring the acceleration back down to a more reasonable value. Then you will end up having a more precise tuned system?
My mill is a MahoMH600E (1990), and I'm replacing an old controller. This controller was already tuned, and I was trying to copy the setting from that. Now I don't know how to read out any of the PID values from my Philips 432 controller, but I was trying to measure the acceleration it used. But because of all the noise in the mechanical system I found that reading them out with an accelerometer was almost impossible. So I ended up taking a guess, which ended up being a bit on the optimistic side....
Any thoughts on if putting acceleration in as one of the parameters in the tuning application? Is it a good or a bad idea? I assume (or hope anyway) it would be a quick thing to implement for you guys who made the feature in the first place? If a decision to put in in there is made that is....
Anders
Please Log in or Create an account to join the conversation.
26 Sep 2014 18:52 #51592
by BigJohnT
Replied by BigJohnT on topic PID tuning and accelereation
What shows up in the Calibration window depends on how your configuration is done. If it is not in the ini file it won't show up. I'm not sure of the list of items that will show up.
JT
JT
Please Log in or Create an account to join the conversation.
27 Sep 2014 06:59 #51604
by andypugh
It's a great idea, but hard to do.
During tuning you are changing the values of a HAL realtime component (the PID component) and that reads values in from the parameters in HAL that control it.
Unfortunately the axis velocity and accel numbers are completely different, those are parameters of the motion planner, read in only once (from the INI) at load time.
If you want a fun experiment, when LinuxCNC is running open a terminal window, and typeYou can change anything there without restarting, but not anything else.
(What you will see is a huge list, but it isn't everything)
It would be technically possible to have the axis limits as HAL parameters. Bearing in mind that the interpreter will often have set up every motion of the entire G-code program ahead of time before the first move finishes there would be some unexpected behaviour if you changed it in a live system.
Replied by andypugh on topic PID tuning and accelereation
Any thoughts on if putting acceleration in as one of the parameters in the tuning application? Is it a good or a bad idea?
It's a great idea, but hard to do.
During tuning you are changing the values of a HAL realtime component (the PID component) and that reads values in from the parameters in HAL that control it.
Unfortunately the axis velocity and accel numbers are completely different, those are parameters of the motion planner, read in only once (from the INI) at load time.
If you want a fun experiment, when LinuxCNC is running open a terminal window, and type
halcmd show all
(What you will see is a huge list, but it isn't everything)
It would be technically possible to have the axis limits as HAL parameters. Bearing in mind that the interpreter will often have set up every motion of the entire G-code program ahead of time before the first move finishes there would be some unexpected behaviour if you changed it in a live system.
Please Log in or Create an account to join the conversation.
28 Sep 2014 03:55 #51618
by akb1212
Replied by akb1212 on topic PID tuning and accelereation
Ok, it was as I feared then.... its harder to implement acceleration changing during tuning than changing the PID parameters.
I guess there's a reason it's not in there already.....
I realize it's not a good thing to restart all the motion planning processes while working. But how about during calibration? That is after all a special case, and there should be no real implications of doing it. You really shouldn't go in to the calibration menu and start assigning new values if you don't need to. How difficult would it be to have the process restart the necessary processes in the calibration utility?
It is a little more than a "nice to have in there" I would say. So a better way to change it around during calibration would be great. A script to restart only the needed processes or something?
Are you saying you can alter the values of the user variables when starting LCNC in a terminal window, but acceleration isn't one of the parameters possible to change in there? I'm not in front of my Linux machine now, so I can't check for myself.
On a slightly related note. What is the best way to determine how high accel to use? I guess its all part of the black magic involved in PID tuning, but some guidelines from you experts would be very welcomed. It would be welcomed both by users like me who are retrofitting old quality iron with an updated controller and hoping for increased speed capabilities as well as users building new mills. Acceleration is one of the key elements here. In particular for 3D contouring and such. Increasing the acceleration could mean a big improvement there.
But the question is how much acceleration can be increased before you will get in to trouble.
One thought in that area is as follows:
I have seen torque meters and such on larger machines. These are to show you how much you are utilizing the machine, and is a good idea. My spindle drive has an analogue output for this, and I will implement this with an analogue input. A friend have this as an original feature on his Maho mill.
Anyway, the idea is to make a meter in the GUI that is showing the value of the f-error pin (possibly also one for each axis). This will continuously show you what accuracy you have at any given time, and you can add storing of max values and other features as wanted as well. My plan is to use the gmoccapy GUI, and as far as I understand there should be no problem to implement it there. It's in fact one of the things I hope to be able to implement myself....![:-) :-)](/media/kunena/emoticons/smile.png)
The idea for this came when I was doing my PID tuning and saw the values of f-error I was able to get compared to the ones in JT's guide. I wondered if the values I was getting were in fact good or not. And to know that I needed to know what the scale is on the HAL scope. I noticed that I wasn't able to get anything as low values on f-error as JT had in his screenshots. But then I realized he is using inch as base units, right JT? That means that when I use mm I can have 25 times higher values of f-error and still be well off.
When tuning you need to set max f-error way high (as a side note this is also one of the things that would be a good idea to be able to change in the calibration feature... at least if it's easily accessible). But the idea is that your tuning should make you able to reduce the values of this down to reasonable values by tuning the axes. But I became quite scared when after tuning I did some quick jogging around and saw the values of f-error fly what seemed sky high compared to the values I got during tuning.
That was when I realized that my acceleration was too high. And reducing accel by half to a third of the first values I was able to reduce most of this error.
But this also made me realse, lowering the acceleration even further down would make it possible to increase the accuracy of my mill in general by reducing f-error values.
Then I came to think of one of my plans for the mill, I want to add a 4th axis and use the mill to sharpen HM tools with it (I have access to free worn out HM tools from work, for private use anyway....). I know that is possible, but this is one of the things that will require high accuracy. And a way to monitor this is a good idea. So if I have an indicator that shows what my accuracy is in real time I would be able to make trial runs and test out what accuracy I will be able to get, and possibly tune the g-code programs to reduce the error.
Grinding like this doesn't require high speed movements though, so there should be good possibility to get fairly high accuracy. But this will mean the PID tuning will have to be very good.
And I found that in particular FF1 are very sensitive, and changing it from 0.0092 to 0.0093 made the steady state error change surprisingly much. For this I found that the HAL scope was irreplaceable. It wouldn't even be possible to get a good tuning without it. So l found that learning how to use that was well spent time!
Back to acceleration..... reducing acceleration will increase accuracy (down to a certain value anyway), and some types of work will favor accuracy over acceleration (like my tool grinding example). Then again other kinds of work will benefit from higher acceleration and won't require high accuracy (like roughing out huge volumes of material as quick as possible, in particular if new HSM CAM software is used where circular acceleration is set as high as possible all the time).
What would be the best way to change between them? Would I need two completely different configurations of LCNC, one for each kind of work? Then how about if I need both in different parts of the code?
So come to think of it, changing acceleration is in fact something I'd like to be able to do while machining a part. It's in fact comparable to changing the values used with G65 throughout your parts as some operations require more accuracy compared to others.
The difference is that with changing the main acceleration value you will be able to controll the accuracy for all movements in a way the controller won't be able to by applying low values to G65. As long as acceleration is set high it will use relatively high acceleration even if it is asked to use higher accuracy. Is there a g-code to override acceleration (to lower it from standard value)?
Is there something to these thoughts, or am I way off? I would think there is something to gain from looking in to it.
Anders
I guess there's a reason it's not in there already.....
I realize it's not a good thing to restart all the motion planning processes while working. But how about during calibration? That is after all a special case, and there should be no real implications of doing it. You really shouldn't go in to the calibration menu and start assigning new values if you don't need to. How difficult would it be to have the process restart the necessary processes in the calibration utility?
It is a little more than a "nice to have in there" I would say. So a better way to change it around during calibration would be great. A script to restart only the needed processes or something?
Are you saying you can alter the values of the user variables when starting LCNC in a terminal window, but acceleration isn't one of the parameters possible to change in there? I'm not in front of my Linux machine now, so I can't check for myself.
On a slightly related note. What is the best way to determine how high accel to use? I guess its all part of the black magic involved in PID tuning, but some guidelines from you experts would be very welcomed. It would be welcomed both by users like me who are retrofitting old quality iron with an updated controller and hoping for increased speed capabilities as well as users building new mills. Acceleration is one of the key elements here. In particular for 3D contouring and such. Increasing the acceleration could mean a big improvement there.
But the question is how much acceleration can be increased before you will get in to trouble.
One thought in that area is as follows:
I have seen torque meters and such on larger machines. These are to show you how much you are utilizing the machine, and is a good idea. My spindle drive has an analogue output for this, and I will implement this with an analogue input. A friend have this as an original feature on his Maho mill.
Anyway, the idea is to make a meter in the GUI that is showing the value of the f-error pin (possibly also one for each axis). This will continuously show you what accuracy you have at any given time, and you can add storing of max values and other features as wanted as well. My plan is to use the gmoccapy GUI, and as far as I understand there should be no problem to implement it there. It's in fact one of the things I hope to be able to implement myself....
![:-) :-)](/media/kunena/emoticons/smile.png)
The idea for this came when I was doing my PID tuning and saw the values of f-error I was able to get compared to the ones in JT's guide. I wondered if the values I was getting were in fact good or not. And to know that I needed to know what the scale is on the HAL scope. I noticed that I wasn't able to get anything as low values on f-error as JT had in his screenshots. But then I realized he is using inch as base units, right JT? That means that when I use mm I can have 25 times higher values of f-error and still be well off.
When tuning you need to set max f-error way high (as a side note this is also one of the things that would be a good idea to be able to change in the calibration feature... at least if it's easily accessible). But the idea is that your tuning should make you able to reduce the values of this down to reasonable values by tuning the axes. But I became quite scared when after tuning I did some quick jogging around and saw the values of f-error fly what seemed sky high compared to the values I got during tuning.
That was when I realized that my acceleration was too high. And reducing accel by half to a third of the first values I was able to reduce most of this error.
But this also made me realse, lowering the acceleration even further down would make it possible to increase the accuracy of my mill in general by reducing f-error values.
Then I came to think of one of my plans for the mill, I want to add a 4th axis and use the mill to sharpen HM tools with it (I have access to free worn out HM tools from work, for private use anyway....). I know that is possible, but this is one of the things that will require high accuracy. And a way to monitor this is a good idea. So if I have an indicator that shows what my accuracy is in real time I would be able to make trial runs and test out what accuracy I will be able to get, and possibly tune the g-code programs to reduce the error.
Grinding like this doesn't require high speed movements though, so there should be good possibility to get fairly high accuracy. But this will mean the PID tuning will have to be very good.
And I found that in particular FF1 are very sensitive, and changing it from 0.0092 to 0.0093 made the steady state error change surprisingly much. For this I found that the HAL scope was irreplaceable. It wouldn't even be possible to get a good tuning without it. So l found that learning how to use that was well spent time!
Back to acceleration..... reducing acceleration will increase accuracy (down to a certain value anyway), and some types of work will favor accuracy over acceleration (like my tool grinding example). Then again other kinds of work will benefit from higher acceleration and won't require high accuracy (like roughing out huge volumes of material as quick as possible, in particular if new HSM CAM software is used where circular acceleration is set as high as possible all the time).
What would be the best way to change between them? Would I need two completely different configurations of LCNC, one for each kind of work? Then how about if I need both in different parts of the code?
So come to think of it, changing acceleration is in fact something I'd like to be able to do while machining a part. It's in fact comparable to changing the values used with G65 throughout your parts as some operations require more accuracy compared to others.
The difference is that with changing the main acceleration value you will be able to controll the accuracy for all movements in a way the controller won't be able to by applying low values to G65. As long as acceleration is set high it will use relatively high acceleration even if it is asked to use higher accuracy. Is there a g-code to override acceleration (to lower it from standard value)?
Is there something to these thoughts, or am I way off? I would think there is something to gain from looking in to it.
Anders
Please Log in or Create an account to join the conversation.
28 Sep 2014 05:28 #51619
by PCW
Replied by PCW on topic PID tuning and accelereation
Not related to acceleration but a general comment on PID scaling:
For velocity mode drives, If you scale the output device so that the PID output is in machine units per second
then the PID values are "normalized" so inch and mm machines will have comparable PID numbers and things
like FF1 make sense (FF1 will be 1.00 if the scaling is correct)
For velocity mode drives, If you scale the output device so that the PID output is in machine units per second
then the PID values are "normalized" so inch and mm machines will have comparable PID numbers and things
like FF1 make sense (FF1 will be 1.00 if the scaling is correct)
Please Log in or Create an account to join the conversation.
28 Sep 2014 06:19 - 28 Sep 2014 06:25 #51620
by dgarrett
Replied by dgarrett on topic PID tuning and accelereation
In linuxcnc2.6, hal pins are provided for a number of ini parameters
Example:
The linuxcnc script named sim_pin is useful for modifying hal pins like these during testing.
Example:
linuxcnc2.6 includes a simulator configuration that demonstrates the ini hal pins as:
This sim config starts up a sim_pin instance for a number of ini pins to demonstrate usage.
Example:
$ halcmd show pin ini
Component Pins:
Owner Type Dir Value Name
48 float IN 0.001 ini.0.backlash
48 float IN 0.05 ini.0.ferror
48 float IN 100 ini.0.max_acceleration
48 float IN 400 ini.0.max_limit
48 float IN 40 ini.0.max_velocity
48 float IN 0.01 ini.0.min_ferror
...
48 float IN 0 ini.8.min_limit
48 float IN 1e+99 ini.traj_default_acceleration
48 float IN 1.2 ini.traj_default_velocity
48 float IN 1e+99 ini.traj_max_acceleration
48 float IN 1.2345 ini.traj_max_velocity
The linuxcnc script named sim_pin is useful for modifying hal pins like these during testing.
Example:
$ sim_pin ini.0.max_acceleration ini.1.max_acceleration
linuxcnc2.6 includes a simulator configuration that demonstrates the ini hal pins as:
configs/sim/axis/ini_hal_demo.ini
This sim config starts up a sim_pin instance for a number of ini pins to demonstrate usage.
Last edit: 28 Sep 2014 06:25 by dgarrett. Reason: typos
Please Log in or Create an account to join the conversation.
28 Sep 2014 18:59 #51626
by BigJohnT
Replied by BigJohnT on topic PID tuning and accelereation
The F error should be within the distance you can accept. Say for me that might be 0.0001" and for you yes the number is 25.4 times higher but the same actual distance. IIRC F error can be as good as 2 encoder counts and can not be better than 2 encoder counts.
As for acceleration in my limited experience it has be 10 to 20 times the max velocity.
JT
As for acceleration in my limited experience it has be 10 to 20 times the max velocity.
JT
Please Log in or Create an account to join the conversation.
29 Sep 2014 19:10 #51653
by andypugh
I appear to be completely out of date and a peddler of bad advice.
Does the tuning tool know how to tweak those?
Replied by andypugh on topic PID tuning and accelereation
In linuxcnc2.6, hal pins are provided for a number of ini parameters
Example:$ halcmd show pin ini Component Pins: Owner Type Dir Value Name 48 float IN 0.001 ini.0.backlash 48 float IN 0.05 ini.0.ferror 48 float IN 100 ini.0.max_acceleration 48 float IN 400 ini.0.max_limit 48 float IN 40 ini.0.max_velocity 48 float IN 0.01 ini.0.min_ferror
The linuxcnc script named sim_pin is useful for modifying hal pins like these during testing.
I appear to be completely out of date and a peddler of bad advice.
Does the tuning tool know how to tweak those?
Please Log in or Create an account to join the conversation.
29 Sep 2014 21:54 #51657
by DaBit
Replied by DaBit on topic PID tuning and accelereation
In my 2.7.0~pre from yesterday: no.
But that doesn't matter since executing a 'halcmd setp ini.0.max_acceleration 5000' does not give you the desired effect of setting acceleration. These values are cached somewhere in LinuxCNC; I saw some discussion about that in another topic.
But that doesn't matter since executing a 'halcmd setp ini.0.max_acceleration 5000' does not give you the desired effect of setting acceleration. These values are cached somewhere in LinuxCNC; I saw some discussion about that in another topic.
Please Log in or Create an account to join the conversation.
29 Sep 2014 22:49 - 29 Sep 2014 22:52 #51663
by dgarrett
Replied by dgarrett on topic PID tuning and accelereation
works for me
change ini.0.max_accelration (while stopped)
The image shows velocity with ini.0.max_acceleration set to 50 and then 20 (inch units)
change ini.0.max_accelration (while stopped)
The image shows velocity with ini.0.max_acceleration set to 50 and then 20 (inch units)
Last edit: 29 Sep 2014 22:52 by dgarrett.
Please Log in or Create an account to join the conversation.
Time to create page: 0.244 seconds