Odd issue with cut depth

I have two different tool paths (gcode files) generated from that v-carve. The first file hogs out the general shape; the second one cleans up everything and adds some “light” texture. The problem I’m running into is that the second pass goes twice as deep as expected. I double checked the g-code generated, and it’s correct (via two different simulators).

I guarantee its operator error, I’m just not sure where – that’s why I’m asking…

Sequence

  • Secure the piece; zero all at the proper datum
  • Pass 1 finished; stopped the router and quick positioned the machine up front
  • Changed the bit
  • Re-zeroed only the z access to the same place I did in step 1
  • Hit run … and bogus-ness happened ><

I can make some assumptions; please let me know if they aren’t true.

Same instance of carbide motion; loading a new g-code; cuts will not be relative to previous cuts. So for instance if in an area I cut ¼ “ deep, and I ask for 3/8” deep; it won’t go down ¼+3/8. I assume it would only go down another 1/8 from the original.

Sorry for the ID-10-T question; still getting my bearings corrected.

EDIT: Agree w/ @Hard12find if you’re using a Probe — shift it to the surface of the stock as noted at: https://docs.carbide3d.com/assembly/touch-probe/userguide/#probing-z

The problem here is you seem to be slotting — that’s hard to do — consider the following aspects:

2 Likes

when zeroing only the z axis, are you setting the probe body entirely on the surface? for z ony you cant let it overhang the corner like when zeroing all three

1 Like

Thanks @WillAdams and @Hard12find for the responses.

I don’t have a probe, they were out of stock when I ordered the machine (maybe still are?), so I use the high tech approach w/ a paper between the stock and the router bit.

When I do re-zero (only) the z-axis, I put it at the corner where I initially zero’d out everything and move the bit closer to the stock until it’s almost touch (via the paper test).

paper works too, still use it on occasion…kind of eliminates that as a possibility

1 Like

– Update

I ended figuring out what the problem was. It was me :slightly_smiling_face:. I must not have re-zero’d the Z axis before I updated the bit like I thought I did…

I took the same g-code and an mdf board and attempted to repeat my steps, and it didn’t. I double checked to ensure my z was re-zero’d this time and all worked as planned.

As a side note, the second bit is slightly larger by 0.5" than the first.

Anyhow, thanks for the input folks!

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.