I mentioned this in another forum, but decided to make it it’s own since I’m still having issues.
I’m running webcontrol from Linux to a mega (makermade classic)
My Z axis seems to be a little inaccurate when pocketing, lifting and moving the gcode sends it to the same depth but the sled measures a different depth. I did 3 trial 2x2" squares at a total depth of 0.5". (Carbide create is in inches, webcontrol mm)
Trail 2: (gcode is the same)
Sled:.
-3.62
-7.51
-11.25
-12.52
Trail 3: (gcode is the same)
Sled:.
-3.62
-7.44
-11.26
-12.60
I cut the pockets side by side. The pockets depth are indistinguishable by eyesight and look the same. But should the sled be reading the same as the gcode output and should not the pockets depth be the same at each interval?
Note picture is from a different test, but you can notice them being off.
unless you hit limits, the sled position and the gcode should match, but remember that 1mm is 0.04", so an error of .1mm is 0.004", an error of 0.01mm is 0.0004" so it’s not surprising that you can’t see the difference
what do you mean when you say total? 34mm is a lot of Z travel and I would expect you to run into grief (hitting the limits of how far the Z can physically move) around that point.
I’m with @bar on this. Can you post a picture of your Sled and Z-Axis setup?
Also, @dlang is correct. The GCode demand and the Z position feedback should match. Since Maslow only reports encoder feedback and NOT actual Z-axis position, what you are seeing for Z position is what Maslow THINKS the current position is. The fact that there is a difference between the demand and feedback is odd. It suggests and error in reading the endocder or some sort of offset being introduced in the software. That’s not to say that ther could also be some sort of mechanical source of error as well. It just might be compunding the problem.
The z axis runs smooth. I replaced the big pulley with one that has the correct internal diameter, so it fits snug. And the z was not physically bottoming out nor hung up on debris. Hard to see the unevenness in the picture. Its sometime .25 to a half a mm off when it comes back to finish the pocket at the same gcode depth. See my 3 tests numbers in the original post. Haven’t played with any PIDs scared to mess anything up since I don’t know what they do or what I’m doing.
Is there always a difference between Gcode and the feedback or does it sometimes match?
If you were to move Z to a position, save zero. Does the feedback displayed show “0”? If so, if you were to move the Z up or down, does the feedback match the demand when the Z stops?
The difference in the display I cannot explain. However, the unevenness in your pocket may be due to a “tramming” issue. For the most part, it looks like your machine is cutting to the same/even depth. If your router/Z axis is not “trammed” (perpendicular both front to back and side to side) then your bit is most likely not cutting perpendicular (one side of the bit is not cutting as deep as the other side), leaving behind those lines and unevenness in the cut. I could be wrong, but something you can check as well to cure the uneven cutting.
@dlang, @orob, is there a demand/position mismatch error for the Z in the software? Some form of alarm that is triggered when this type of deviation occurs?
One thing I noticed about your set up is the z axis control cable appears to be touching the power cable to the router. It’s good practice to separate them as much as possible. Also, it appears that you have looped the z axis cable to the body of the motor. It’s also good practice to keep the cable away from the z motor as well. It’s been found by others that both of the above have caused interference and erratic behavior of the Z.
I’m not sure if either is the cause of your problem but it’s a good idea to at least eliminate the possibility.
If you rigidly hold the sled base against the work surface and you apply lateral force to the carriage support, do you get a lot of flexing?
Most if not all of the Met-Z based implementations have used some form of gusseting to resist the flex caused by either the moment of the router as it moves up and down the Z travel or the flexing that is caused when the router plunges into the work.
Also, what kind of bit are you using when you cut the pockets? Up Cut? Down Cut? Combination of the two?
I’ve been lurking on this thread and I suspect it is a “control system” issue that either has to do with the PID loop not being tuned for the gearing or there is noise on the encoder line from high voltage from a nearby power tool such as the router power cable. I don’t have any concrete suggestions yet to offer, but I’m hoping it is something I can look at soon since my z axis is crazy out of tune and won’t sit still at all, so instead of a regular pattern of mismatched cuts, I get wavy or just irregular pocket floors. Both @c00nphrog and @jonatpridesleap suggest the gantry may not be square possibly due to a lack of vertical bracing.
Regarding the demand/position mismatch, that is the PID code I was referring to. there is a control loop that sets, and adjusts the setpoint based on how quickly the mechanical system responds. It sets a position and then counts encoder steps until it gets there. It has to go fast enough to be reasonable, but not so fast it overshoots and oscillates around the setpoint. This critically damped system should be both fast and effective. It does not appear to me that it is hitting the setpoint because one of the parameters could be off. Mastering control systems seems to be a bit of magic to me. So far my efforts to improve on it have failed. There are many much more adept at doing this that might be better able to help. To help with this, I copied the left-right motor PID tuning tools in webcontrol for the z axis. I have yet to get data from it though, but it is on my list so I can tune my z axis to stop the oscillations.
I actualy used to tune PID’s regularly in my old job and for some reason I haven’t for the life of me been able to do it successfuly with the Maslow. SO I understand your predicament and @TimS 's concern.
the 2022 beta release of webcontrol in the other thread has a z axis pid tune button in the actions menu. try it out and let me know if it works… It is a copy of the x-y pid tuning but renamed for z and it may not even function, but another set of hands to test it would be helpful. This could possibly be a help to this problem, but may not necessarily be the answer to it.
I know that when I auto zero with the touch plate sometimes it will say 0.1 or -0.1. I will have to check when I get home if it changes when I manually move the z axis
Actually there are 4 brackets, 2 of which are pretty thick. Zero movement of the structure, it’s really solid.
I’ve observed a similar thing and I am using Web Control. When I zero and this occurs I run my Z up 10mm or so and then back down again the same distance, then save zero. This usualy allows the feedback value to reset to “0”.
Dumb question but have you tried to pull the black cover off the end of the motor to check if there was any debris in the encoder or sensor? If you are not comfortable doing it I understand. I’m just trying to eliminate possible causes without getting into PID tuning.
Good to know. One of the issues I had on the first interatioin of my Met Z was this flexing I mentioned causing inconsistent cutting depths. I originaly used 12mm Baltic with minimal gusseting but switched to 18mm baltic with more substantial gussets that eliminated the problem.