No matter what I’m trying for PID numbers (all 3). I can never get difference in gcode and sled to equal up. I will get difference of .03,.03,.02,.10 I can get three numbers close but there is always an outlier. And the numbers will change slightly with each test run.
Also, after doing it for awhile the z axis sled position was slowly dropping depth during a pocket at a set depth. The z motor was moving slowly too. It stopped after a restarted WC.
Any tips or theory out there? I tried to Google it but everything is talking about the heat on 3D printers.
It’s never going to be perfect, but if we’re talking in mm then 0.03 is darn close. I wouldn’t expect to get much better than that. A human hair is about 0.04mm.
I have to admit that I have spent A LOT of time chasing this dragogn. It’s easy to go down this path.
I also want to admit my frustration that I wasn’t able to provide any real insight to Tim’s problem. Totaly missed the enable switch. Hopefully, he’s latched onto the culprit to his problem.
I’m going to try to fine tune the PID a little more.
I am concerned about the observation that I made above with the z axis sled position drifting and the motor slowly turning. This happened quite a few times when I was tuning, and on some settings that it wasn’t drifting previously. Restarting WC would fix it but it would eventually happen again when continuing with tuning. I stopped at a somewhat good time and did some air cuts with no drift.
Did I damage anything? Do I have component failing? Has anyone seen this before during tuning? Do I have anything to worry about before going into a long cut?
I was thinking exactly the opposite. If the I term is too small (and IIRC it
started at 0), then there is nothing to force it towards the right position over
time. so if it’s drifting, wouldn’t we want to increase I so that the longer the
position is wrong, the harder it tries to fix it?
Being consistently off by some amount would be cause for increasing I, having it rotate after it should stop seems like cause to decrease I to me, but PID tuning is a bit of an art so I could see both being possible.
Haven’t had a chance to get on it again. I think it was 2685, 3, 34 or something. I still plan on playing around on it. I did a little reading on it and kind of understand what the values mean (although still very much a mystery). Hopefully I’ll have time tomorrow after work.
I was just randomly typing numbers to see what would work and did not get to a good solution that doesn’t overshoot. Overshooting will drill the hole too deep and so your pocket will have pock marks in it. It is a good idea to take the belt off the z axis so the motor can just run to do this instead of running through the endstop. Keep in mind this is a different motor (metal maslow high speed) so the numbers will be different. The velocity will likely need to be tuned as well in order to get this to work, which is probably why it won’t stop overshooting.
I wasn’t really sure what to put in the blocks for numbers on the pid tuning. So I was doing alot of number changes for the pid values and aircuts. At every pocket depth i would write down the difference between the two numbers. I tried today, using numbers close to what you entered and got the same result and graph shape, I tried to get the graph better with no luck, I did a aircut with the settings from the best graph and the differences were worst than just changing numbers and aircutting. I am going to now try a real cut with the best pid values i found based on aircuts. Wish me luck.
It does get worse. I was putting in 5 start, 0 stop, 200 steps, 1 version, 5 time and changing up the PID numbers all over the place. I got graphs that looked similar to the pic Orob posted, and aircuts would show differences in the positions that didn’t line up with the graph. What determines the steps and time numbers? So I play with these?
Should I try messing with z PID velocity? If so I need some guidance on what numbers to put in.
I’m really lost and my pockets look horrible. I have error ranges from .01mm to .12mm over the course of a cut without changing settings. When this is added up, stepping down and z up and downs, it makes a very noticeable uneven pocket.
Tim, is there any way you can share some of the graphs?
So right now we are pretty confident that this is a PID tuning issue. I realize that we have already covered this but is it possible that there is something wrong in the shield or arduino that is affecting the processing of the PID?
The graphs I posted were for position. There was a comment earlier about nested PID loops. I think (but have not yet verified in the firmware) that the velocity is the inner loop. It makes sense that both would need to be adjusted to hit a specific position accurately. One controls the accel/decel of the axis for the desired movement speed and the other the position. My next session will be to keep the settings I have arrived at that are not that great, but much better and then run the velocity changes and see if it makes it better or worse. Without any experiential basis of reference, I could see iterating velocity, position, velocity, position PID tuning to arrive at an optimal set of values. Is that a reasonable approach?
These are pretty on par with the tolerances the machine is designed to hold. Some PID tuning (Maybe increasing the P value until you see osculation is a good place to start), but you are starting to push the limits of what the machine is designed to do. The roughness of the surface of the plywood the sled slides on is probably going to give you .05mm of variability even if the z-axis is fixed in place.
When I was initially designing it I really had through cuts in mind. Pockets and 3D work are possible, but they aren’t really the thing it was designed to do.
Maybe if the gcode was setup so that the pocket was cut all in one go without raising and lowering the z-axis it might be nicer?
That’s the error error between gcode and sled position in WC. Pockets also do show unevenness.
Why are others not be seeing the same thing with the difference in gcode and sled position for the z axis? Surely I’m not the only one pocketing. When running a cut in mm, its showing .01-.12 mm difference (was showing worst with the default PID settings).
I have played with PID settings being all over the place .01-.12mm is the closest I can get it without slowing the z axis down to extremely low plunge rate in the gcode.
I don’t know how to make the gcode cut the pocket in all one go. A simple square will do it but pocketing around shapes or letters will cause the z axis to lift traverse and go back down.
Does anyone else see this difference in mm between the gcode and z axis sled position(running in inches doesn’t show because .01 inch is much bigger than .01mm)?
Does anyone have issues with very visible pocket unevenness when doing difficult pockets i.e. around letters or shapes?
If a attach a gcode file. Can anyone help to validate that this is normal and I don’t have a problem?
Thanks for all the help. Just banging my head against the wall because it seems like I’m the only one with this problem.
Admittedly, my pockets are a lot simpler than what you are trying to do. mor like mortises, dados, countersinks. I use fusion and the pocketing operations are pretty straight forward. Sled travels to start point, Z travels to first depth with a plunge. stays at that depth while it clears out the pocket at that depth. z retracts, sled travels back to starting point, z plunges to new depth, clears out pocket at that depth. whole thing repeats until final depth is reached.
i dont cycle the Z to and from the same depth as you do.
if you post a .nc file of the operation you known causes the problem you are seeing than i would be willing to run it in my machine to see if i can repeat it
