November 1, 2018 at 2:15 pm #74143
So…. this is interestingNovember 1, 2018 at 2:23 pm #74145
Those are in use on the opendog build. They seem pretty effective (and $$$).November 17, 2018 at 1:16 pm #76049
I have been using the PID a lot lately. Perfect in wood, but aluminum and steel aren’t perfect yet. The PID values are not right. It tends to hold the RPM well but when it gets unloaded it dips hard. If it dips and gets back to cutting before it recovers and can leave a mark in the metal. So heavy loading and immediate unloading.
Not sure if that is clearly explained. I was making test cuts and I overlapped a previous cut so while it was cutting it woudl hit open air for ~7mm then hit more metal. or another spot it would be cutting fine make a small X or Y move and the RPM dip would dip hard (like the power was cut for a second). Previously I thought I had a loose wire…nope.
Just posting as info. I am confident the hardware is fine and this is all PID tuning issue related. I actually think it is specifically D? I had originally tuned it in free air by manually changing RPM. That method has shown it’s flaws.
Any test cut ideas are welcome. Perhaps just cutting across a thin (1/2″) strip of aluminum. Back and forth. This will load and unload the router. Maybe even just a wide trichoidal path!? I am having early days of quad copter kk2 PID tuning flashbacks (not easy).November 18, 2018 at 12:23 am #76063
I’m not a PID expert, but I think Kp, Ki AND Kd depend of the system. So new material would mean new factors.
I’m certainly wrong about that… But if not, you could have some factor sets, one for each material, once tuned.
Maybe even just a wide trichoidal path!?
I think that’s better than back and forth to start tuning parameters, but to verify the model back and forth may be better, as it would needs a bit more torqueNovember 18, 2018 at 12:52 am #76064
Why stop on material only? 🙂 If you will go this way probably you will have separate PID parameters for each bit you use. Also if we milling with different WOC and DOC we can say that it’s different physical systems with different properties.November 18, 2018 at 1:24 am #76065
I think that two things can be used to help solve the issue
1. You may build a data collection test system with a PC. You need to manually prepare
test set of gcode for milling with different feed rates, WOC, DOC, RPM, etc. and an application which will sent this gcode line by line (or block by block) and collects data from motor controller – input value and real RPM. So you will have per block set of data and can build a graphs. Then somehow tune PID coefficients.
2. The general problem is that PID acts reactively. It tries to restore RPM when it already had down due increased workload. It would be nice if the firmware will be more proactive and sends a signal to increase RPM before it touch the material. May be it should be something like Linear Advance algorithm for extrusion in 3d printing.November 18, 2018 at 8:41 am #76077
If I just tune it to the heaviest load (metals) won’t the settings work fine for lighter loads (wood)? Even if that is not the case the RPM difference has a much larger effect on metal, I would prefer to tune for that. As it is it is perfect in wood, even Ipe.
The RPMS are steady and react as perfect as I could ever hope from no load to heavy load, it just lets down to hard, goes to zero, tries to recover faster than the router is capable of. I think I might actually have a setting I can change for the unloading max. As in zero is not allowed as an input, or value changes can only make a certain size change. I need to dig deeper.
I hate when my words are not suitable for what I am trying to convey.
There is a PID autotune for this but at the time I couldn’t immediately figure out if it would work for our case or how to actually incorporate it into the program.
I do know when I spent those two days trying to tune it initially I was solely focused on low to high speed changes and honestly do not think I ever once tried high to low changes. I guess if I turn on debugging and watch the graph I will see the issue, if not one of you actually smart people will probably know which direction to go with a graph screenshot.November 18, 2018 at 9:12 am #76082
This is where some of the “art” of controls comes in. You can make sacrifices in terms of response time, or steady state error and end up with a system that works well enough for all cases, but is perfect in none of them.
Trichoidal paths are going to be the hardest, because it will need dramatically different output when it’s cutting and not. If the response time is too slow, it will sort of average out to the right speed, constantly being too slow when cutting and too fast when not. It might just be a case where you have to turn it off and do it the old fashioned way.
When you’re going from no load to a very high load (metal) without any knowledge of why (no feed forward input), you’re basically depending on the integrator to close that gap, right?November 18, 2018 at 12:55 pm #76087
Trichoidal paths are going to be the hardest, because it will need dramatically different output when it’s cutting and not. If the response time is too slow, it will sort of average out to the right speed, constantly being too slow when cutting and too fast when not. It might just be a case where you have to turn it off and do it the old fashioned way. When you’re going from no load to a very high load (metal) without any knowledge of why (no feed forward input), you’re basically depending on the integrator to close that gap, right?
Trochoidal milling is difficult to handle properly by another reason too. If you will check produced gcode you will see that trochoidal gcode constructed almost complete with using G1 commands. So there is no chance to firmware or anything else to separate free moves from workload moves.
Non-trochoidal gcode has properly issued G0 commands so it’s not big deal to implement system which will help to keep RPMs better.
As example you may implement injecting M3 commands with RPM +20% before a few last G0 commands preceded to G1 and M3 with requred RPM immediatelly before G1 command. For Fusion 360 good candidate for such improvement is postprocessor script. For other software like Estlcam it could be an external application implemented with any language.
But the same time trochoidal mode is easier. Because trochoidal step is usually pretty small (5%) and you may set small width (25%). So the tool will has small workload in moving in short spiral, so inertion of the rotor will help to keep +- same RPM. Anyway you may use trochoidal just to mill almost all material, but add finish step to get better surface.March 3, 2019 at 5:09 pm #91601
I’m working on getting this kit all set up on my newly built MPCNC and it’s been a good learning experience with the arduino and some other basic electronics. I am very much a novice, so wanted to verify I haven’t somehow completely botched something while also still getting the correct results.
On the first post, Ryan links the wiring diagram of the custom PCB and the IR sensor, and has the pins on the board numbered. However, from reading some tutorials on setting up the QRD1114 and just my understanding of the cabling, it seems like the pin numbers are labelled incorrectly. On the diagram the 4 pins are labelled 1 through 4 from left to right (in regards to the sensor input), but shouldn’t it be 2, 4, 3, 1? The far left pin on the board is the sensor read pin, pin 2; the 2nd from the left is ground which is needed for the IR LED pin 4; the 3rd is the current limited pin for the IR LED power; and finally the 4th pin is the +5v power for the IR sensor.
Wired the way it’s shown on the diagram gives the IR LED no ground (one pin is the +5v, the other is the 1Kohm resisted +5v), and no power input for the IR sensor.
When I’ve connected it in the order 2,4,3,1 I’m able to get a reading of ~26k rpm on the Dewalt 660.March 4, 2019 at 2:37 pm #91735
Dang I think you are right, how the heck did that get messed up?March 4, 2019 at 3:20 pm #91747
I think you copied the pin numbers from your PCB schematic since the numbers match there. They just don’t coincide with the IR sensor pins so when you combined the two pictures into the diagram the pin numbers didn’t align.March 12, 2019 at 3:58 pm #92847
Delete, I can’t find where to delete this duplicate post.March 12, 2019 at 5:47 pm #92858
I think you copied the pin numbers from your PCB schematic since the numbers match there. They just don’t coincide with the IR sensor pins so when you combined the two pictures into the diagram the pin numbers didn’t align.
Thanks for bring this up. I’m also a bit confused are you talking about the number for the sensor section of the board or are you talking about the diagram of the sensor at the bottom?
Either way thanks for pointing this out.
Ryan, Do you think you’ll be able to have a new image up before April? I’d love to be able to finish this in time for my birthday.
You must be logged in to reply to this topic.