If the issue was with the PID tuning, we would see the digial readout for the z-axis showing the error. If the issue is mechanical we wouldn’t see any error there.
The way to check that would be to see what the digial readout says while cutting a pocket. If the pocket is supposed to be -1mm deep and the digital readout shows -1.00mm (or something reasonably close) the whole time then the issue isn’t with the PID controller. If the ditial readout says -1.25mm at one point and -1 at another then it sounds like a PID issue to me.
These are readouts from my trial from the first post. It was 3 squares all the same gcode depths with the total pocket cut to 0.5" or 12.7 mm. Notice each sled depth is slightly different.
I agree, this has to be in the firmware. Either there’s a dead zone that says
that it’s ‘close enough’, or the position factor is too small.
PID adjusts speed based on 3 factors
P how far away from the target position it is
I how long it’s been away from that position
D how fast is the error changing
If it’s getting close and stopping, that sounds like the P factor probably needs
to be increased a bit.
The reason the motors on the maslow buzz is that we do not have a dead zone
implemented, so the motors are never exactly at the perfect location, they keep
getting an error on one side or the other, so they flip direction and buzz.
But I have zero experience in tuning PID parameters.
-23.6 was -24 but with some maths I was able to get it closer to the cut depth. When set back at -24 still gives me the same problem of mismatch between sled and gcode
It’s not so much that something is wrong, it’s that the firmware isn’t right for your motor and z-axis thread setup. The default settings are right for the original kit, but it had quite a different z-axis.
changing the pitch and Z encoder settings will change the physical location of
the router, but will not change where the system thinks it is.
the system knows where it is based based on how many steps the encoder has
moved. If the problem was that you told it to move 1/4" and it instead moved
1/2" we would be looking at these parameters to make sure they match your
physical machine.
but when the system doesn’t move to where it’s told to move (23.6mm vs 24mm)
that cannot be this sort of thing. The only thing it could be is a feature in
the firmware that says ‘stop trying to move when you are within X of the
destination’ (i.e. dead zone around the point it’s moving to), problems with
the PID settings, or errors in the translation of numbers to binary floating
point within the arduino (I really doubt it is the latter.
what firmware version are you running? it may be that we need to look at that
and create a debugging version that reports more info.
when you move the Z axis, does it move and then a couple seconds later stop
buzzing? or does it stop buzzing immediately at the end of the move? or does it
never stop buzzing?
I’m running holey 51.27 flashed from webcontrol. Should I reflash it, will I have to recalibrate after?
It starts to move buzz at the same time and stops buzzing a few seconds after it is done moving
Of note: when I zero the z, move it down 5 mm and back up after a few moves I start losing .01 every move. I.e. 5 down 5 ends up at -.01 up five ends up at 4.99 down 5 ends up at -.02 and so on
I should clarify. I was asking about the pitch because I am trying an experiment to replicate your problem and was curious about what your current setting is.
The thing is, you and I are using a very similar set up software wise WebControl, Holley calibration. I also see a similar problem as you where my reported position feedback does not exactly match my gcode output. Until now I’ve only seen this happen when I zero the Z or manually move my z axis. It’s only a small quirk for me because:
I am able to get it to clear by manually jogging the Z up and down and re-saving zero. That almost always gets the discrepancy to clear. That’s if the problem even shows up which it does with absolutely no regularity.
I only full cut through my material. I don’t carve and very rarely pocket anything where precise depth control is required. Even if the discrepancy exists while running a program, I wouldn’t have been looking for it to even notice it. It’s such a small discrepancy, that it wasn’t something I wanted to invest a whole lot of time investigating. Which doesn’t mean the problem doesn’t exist.
My point is I didn’t mean to suggest that pitch may have been a culprit, I’m sorry for the confusion if I did.
I’m going to try and replicate the problem tomorrow and report back.
I want to add that I am using an arduino, shield, and z motor from the original @bar kit. WebControl w/Holey calibration.
Wait, the discrepancy gets larger just with successive manual moves?
Let’s go back a step. I know I’ve already asked this but just to clarify, after you save zero, you don’t get the feedback position to read 0.0. It’s sometimes .1 or -.1 correct? After this, if you move the Z manually a few times, the error gets larger?
I’m running holey 51.27 flashed from webcontrol. Should I reflash it, will I have to recalibrate after?
reflashing with the same flashing won’t help, you should not need to recalibrate
as long as you stick with holey.
I was asking as we may want to create a version that does some additional
debugging output
It starts to move buzz at the same time and stops buzzing a few seconds after it is done moving
Of note: when I zero the z, move it down 5 mm and back up after a few moves I start losing .01 every move. I.e. 5 down 5 ends up at -.01 up five ends up at 4.99 down 5 ends up at -.02 and so on
I think this is a very important thing to know, and it means that we now have a
repeatable test.
I was able to replicate Tim’s issue on my machine this morning. At least partialy. I had the measurment systems set to MM on both the main console screen and the Z-axis zero control panel. After saving a zero position, the G-Code output showed G10 Z0 and the Sled position showed Z:0.00.
I then manualy jogged the Z to -5.0mm. After stopping the sled position showed the Z position was at -5.01mm. I then jogged it again to 5.0mm. After stopping the sled position showed the Z position was at 0.01mm.
I attempted and additional 10 joggs of differing distances, always running the Z in an identical +/- direction. I was trying to see if I could compound the deviation. The deviation never grew but it never got less either.
I then switched over to using USC Inches units. I performed the same test as above. At no point did I get a deviation between what the G-Code called for and what my reported sled position was.
How does WC handle the switch between metric and US Customary measurment systems? Does it work with metric natively and convert to USC or is it the other way around?
Doesn’t really get larger when manually moving. It just changes. The real problem is when it’s off alittle each plunge when pocketing it starts to add up and is noticable within the pocket. Let my test result numbers show above.
I really appreciate you helping and duplicating the problem, can you see how it acts when aircutting and how the gcode and sled numbers look?
Interesting finding with mm and inches. I currently output gcode from carbide create in mm and cut in mm. I will try switching everything to inches as well.
Here is another cut to show different depths. It was designed to pocket and contour the edges at .20 in.
This gcode was ran through gcodeclean with a lower z camp and over the course of the cut, the z axis wasn’t retracting enough to clear due to this issue, same as in the pockets why some area are deeper than others or vice versa.
