Holy cow, SquidPlan you might have saved me from surely going grey over this. I would have not known but after reading (actually reading) the first link, wow…Heffe if you get a chance this looks plug and play?
Links are all the same just, explanation, code, arduino page.
http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/
So if we use 60hz as the fastest possible rate of change, run the PID at that or is there some reason to speed it up?
The library is slick, it does have an auto tune, and a manual option so we can use an encoder/lcd easily.
Heh, I haven’t programmed a PID since that middle 90s, when I was writing energy management software for HVAC systems. Plug in a P first, tune for how quickly it stabilizes, it’ll be stable at some remove from the set point. Next plug in I to shove it closer to the set point, keep it low because otherwise you’ll overshoot badly when you start from way off. Finally be real cautious about using and D, that derivative can really destabilize when you get it off.
For the HVAC systems we were running the loop about every 10 seconds… For a DW660 you’ll want it a tad faster. 
Glad to hear something looks promising.
Looking forward to the day when I can adjust the speed of the 660. 
This is shaping up to be one of the most helpful threads on here.
I second or third the encouragement for arduino. Most of the stuff i have done is based off taking an example and making it do what i need it to do. Currently working on a pitch control for a record lathe that started from the arduino blink tutorial
Okay it is ugly but I am PID tuning the Router!!! Are you kidding me.
Congratulations ! Have you yet tried and put some “stress” on the spindle to see it adjust the output to different/variable conditions ?
Awesome!
What! Awesome!
I need to get the auto tune figured out, there isn’t much info on it. PID Tuning is hard. I can get a pretty good setup with a “soft start feel” and then speed changes respond really well. I didn’t write it down though… So the initial start up was a bit slow but who cares, in my quest for perfection I screwed that up. Brute force tuning sucks so I need to get the auto tune working to automate it.
For some reason a low P, super crazy high I, and minuscule D work best. Like 1.5, 40, .01? Someone that deals with PID would know what is wrong with that. I remember a professor mention things so far out of balance but I can’t find any info.
At the same time, this PID library doesn’t seem to work right with a zero “I” and “D”.
Seems legit, hard to really force it too much with all the wires and stuff but coded speed changes responded well and trying to slow the spindle with a stick worked as expected. Won’t know until I can get it dirty. But as is having a much real sense of rpm and a auto correct it should already make a difference, but hopefully in a few more hours work I can tune it in.
Tuning PID loops is an art, not a science. So don’t get too frustrated.
First, a little talking about what p, i, d do and don’t do.
P is the natural one. If you’re under your goal by some amount, you push harder. The amount you push is proportional to how far away you are from your goal. If your Part gain is too low, you will give up too early. If it’s too high, and you have some delay, you will blow right past your goal.
D gets bigger the faster you move towards your goal. As you push towards your goal, this is the voice in your head saying, “whoa”. If D is too low, you blow past your goal. If it’s too high, you slow down too early while making progress towards your goal. IMHO, D gain is the hardest to tune. I would expect it to be much lower than P for this system, because it has a pretty fast response. I imagine it has a fast response, maybe it doesn’t. P and D are very coupled. They work against each other so whenever you change one, you’ll probably move the other. If you’re seeing a lot on ringing, then you can either increase D or decrease P. So it’s easy to get way out of whack.
I accounts for systematic error. You’ve got your p and d tuned. You’re headed to your goal, you’re almost there, but there’s a headwind. You’re just a little short, and you stop. Since you are close to your goal, your effort is small, and it’s matching the effort of the headwind. You aren’t getting closer to the goal, so D is doing nothing. This error is called the steady state error. The I will add up the amount of time and how far away you are from your goal and add in more effort, which will compensate for that headwind, eventually. The trouble with I is that it has a memory. When the wind dies, you’ll take off past the goal and the I has to “unwind” (wind, like a yo-yo, not wind like a breeze). The winding/unwinding is why we have a max I term. If your I gain is too low, you won’t quite be able to reach speed, especially during some external force, like when you’re cutting. I is really the icing on the cake, not the main strength. If I is too high, it can cause you to compensate with I while still approaching the goal with P. That will lead to going too far, and then it has to unwind, while the P is pulling back… You’ll end up with more ringing. A very experienced controls engineer told me I is the devil, and he was absolutely right.
I think there’s something wrong with the system and I have a guess, but I’ll put it in the next post.
Here’s where I think we went wrong. When you’re running at 5krpm, you need to have the output be, something like 50/255. If you’re hitting that perfectly, the error will be zero. The P output will be zero, your D output will be zero, and your I output will be zero. How will you get 50?
Because the output of the control loop isn’t the output to the speed controller, it should be the delta output to the speed controller.
So save a variable, speed_output. Initialize it to zero, and at the end of each PID loop, add the PID output to the speed output. You’ll have to shrink the gains right away. You’ll also need to watch out for speed_output going negative or greater than 255. If you get goody type errors, send it to me and I’ll help sort them out.
That library has a few built in features that make it easy. Last night I figured out the way I was stopping the power to the spindle wasn’t clearing the equations, it was saving the variables and without a reboot it was screwing with the tuning. Pretty sure you warned me about that Heffe. So I got most of the PID side sorted out last night. I also turned off the low pass filter you had, but will try and put it back now that the issue is found.
So next up is tuning which seems to be way better now. Then maybe some LCD stuff? Still want the auto tune in there so switching routers will be easier.
I also want to try and get an optical sensor tucked into one of the small fan vents above the collet lock and bounce the beam off a fan blade. Have to be careful of dirt build up though. Probably going to require drilling a hole but that part is 4 screws and really easy to take off. The encoder disk is great for testing but just is not going to be practical in real world use. There is also a really tiny spot at the top end of the router above the brushes but that is kinda sketchy trying to get a signal from right next to mains power and sparks.
After coffee and breakfast I will try and clean up the code a bit and share it so ya’ll can see what is going on. Try and catch my mistakes.
You could make a dxf part or 3D printed part to make drilling in the right spot easier. I like the idea of drilling on the 660 near the top. I don’t like the idea of drilling on the 611, but I don’t have a better solution.
I haven’t looked at the 611 yet. I am pretty sure it has to get opened up to disable the speed control. I remember reading that somewhere but can’t find anything now.
On the 660 reflecting the optical sensor on one of those fan blades should give a pretty clean signal I would think. The other way would be to put an encoder disk above the collet nut but would need to clamp or glue it to the shaft, any kind of clamp would probably cause vibrations I would think and is super sketchy at 30k rpm. I could have sworn the shaft came all the way out the back end and was hoping to get a tiny encoder disk in there but no dice.
Quick progress report. PID is good enough for now, still want auto tune though. 0-11k is pretty nice hardly notice the wobble, 11k-18k is super nice! 0-8k is a little rough not sure if the loop is to blame or if the router is just wonky at such a low speed. Of course this is just free spinning and it needs some cutting tests.
There is a nice gif on the wiki about the settings changing the curve. It seems to hold true.
The P controls the initial burst, I brings up the burst as well as the sustained speed, D clamps them down in a big way and comes unstable easily. The numbers in the screen shot still got adjusted a few more points but is good enough to prove the concept and move on to the next step.
So do I just drop this on GitHub with a MIT license as I work on it? It is not exactly hardware specific yet but I know a lot of you guys know more than me about this stuff.
[attachment file=53638]
That would be a great way to do it.
Ryan. Maybe you should touch base with JDGreen to compare your performance with what he gets with the Super PID. As I understand it he is currently running it successfully on the DW660.
If it has a speed control, it might make sense to use that to control the speed? By that I mean, connect something to the thing that takes the input from the knob or whatnot and then allows you to set whatever speed you want through automation. Of course, being able to use the same setup for both the 660 and 611 would make things simpler.
Johnny, I tried to by a bunch of those PID in bulk a few times to get the price down for us, but there is no wholesale/bulk pricing even if I only included them in a full kit. So I had to make it to bring the price down. I did find an installation write up last night that someone posted about it with a bosch router. He used black and white nail polish on the top of the shaft. That could really make this easy to use on any router.
Squid, I doubt I have that kind of EE skill but after I get the 660 pimped out then I will crack open the 611. I guess it could be a possibility to use the built in speed control.
I learned something from the tach article linked on hackaday. I wasn’t using a resistor on my first photodiode, that might explain the super crappy signal I was getting. I will try it again when I get it sorted out a little more.
And a little more progress was made. I hooked up and did some messing around with an LCD on an arduino for the first time last night. Way easier than I thought. The 20x4 lcd is much easier to use than the full graphic ones. Now I understand why the big full graphic lcds take the special u8glib and the other doesn’t. Might have to go back to the basics. I kind of like the old school one better.
