not sure where we are at with this.
my guess is either there is something wrong with the encoder feedback itself, giving an intermittent error in the feedback value or there is something wrong in the software.
possible courses of action:
pop the cover off the back of the Z motor to expose the encoder and make sure that there is no debris inside and inspect the solder joints for cracks or breakage.
completly wipe the controller and start from scratch with a new firmware flash.
I thought we decided it was a PID controller issue since the default PID settings are for driving the rigid router directly?
I’ll be trying this weekend. Long week at work.
Thx for producing the gcode test.
-Tim
This is still a possibility but I have been running on the assumption that Tim was using the stock MakerMade Z axis motor with stock PID settings. When I went from the direct drive Rigid base to my Met-Z I just had to fiddle with the pitch setting. My PID settings never changed. I assuemed this was this case with his set up as well. I could be wrong though. Since he bought his machine used it could be that he might not be using the stock PID settings for the motor.
No worries. Just didn’t want you to think we’d given up on your problem 
I used the one with tool changes. It was hard to judge the depth and height while watching because the z axis is constantly moving, I had it in inches and it seemed like at times i was 0.01" off. I attached the log files.
Good point, I guess the issue would be more common if that were the case.
The combination of the position being mechanically off, and the digital readout showing that the position is off seems to me like motor isn’t being driven to the correct position.
Here is a pocket test with different shapes, that I made in easel to try and rule out if it was due to the carbide create gcode. Same issues, most easily seen when watching the gcode in mm.
log.txt (1.2 MB)
alog.txt (200.3 KB)
Test_Sq-Tri-Cir_Pocket-Contour_easel.nc (39.4 KB)
It seems looking at the log files that they are not reflecting the problem that I see on screen and in the pockets. (Unless I’m looking at them wrong) very frustrating.
I was afraid this may be the case, and if so, we may need to try and get a
modified version of either webcontrol or the firmware to get better info.
the log files weren’t reflecting it but when cutting your test pockets you did see the discrepancy in the web control screen like you have been correct?
Same discrepancies, yes
Any ideas for the next step forward?
I feel like we haven’t really gotten anywhere. All the options for what could be going on are still on the table. 
Does it seem like the z-axis motor is having a hard time rotating?
Everything moves smoothly with plenty of power. I even lubed it with dry lube.
Are you seeing the same behavior when the router is on and cutting as when the router is off and there is no end-mill in it?
Doesn’t matter if it’s running and cutting or doing aircuts. The gcode and sled position for the z axis are off, best seen by using webcontrol in mm. This causes my pockets to have some unevenness because the z axis picks up and lowers by slightly different measurements at every z axis movement. Mechanically everything seems to operate fine. Bits and router are not slipping in the collet or clamp, the z axis isn’t moving when not commanded.
I have to own up to this. I’ve been re-wirring my house and trying to get the attic insulated before it gets too hot up there to work. The last couple of weeks have been rough with home improvement projects and I haven’t been able to focus on @TimS 's problem as much as I could have.
I want to create a list of all the potential causes of @TimS 's problem. This list is by no means complete and some of the things on it can be quickly eliminated. However, I wanted to at least consolidate all of the things that have been discussed so far. Please feel free to add to it or offer corrections to anything I’ve stated below.
PROBLEM:
A discrepency is being reported betwen the gcode command (demand) and the feedback position (position). This discrepency is noticeable on the WC display but is also observed in inconsistent depth of cuts while pocketing. The variations in the depth of cuts seem to corespond to the discrepency observed in the WC display. This discrepency exists while cutting in both mm and inch settings but is more noticeable in mm.
This discrepency can be replicated using the Z-Axis zeroing feature in WC and by manualy cycling the Z up and down using this feature. It is reproducable using this feature in both mm and inch settings but is more noticeable in mm.
@jonatpridesleap has replicated the error independently using the Z-Axis zeroing feature but has only been able to replicate the error while using mm as the units. @jonatpridesleap was NOT able to replicate the error while making actual pocket or any other type of cuts.
The discrepency can be caused by problems any of three areas. Mechanical, Electrical, or Software.
MECHANICAL:
ELECTRICAL:
SOFTWARE:
There is a bug in Web Control that is casuing not only the readout on the screen to show a position/demand mismatch but it’s causing an ACTUAL mismatch.
The PID settings are not correct for the Z motor being used.
I’ve been trying to get a z axis pid tuner working… Or at least the ability to operate it from webcontrol. The gcode is generated. Whether the firmware functions work or not remains to be seen, but I think using that to improve the z axis control loop is one of the next steps in this process.