Hey Everyone - First of all, a big general thanks to this neat community… I’ve learned a ton from many of you.
Excited new user of a Journeyman X50 here. Aside from all sorts of usual dumb-ass learning along the way, I’m having a blast and getting some great results. One issue is still perplexing me however, and while I’ve seen others struggling with this here, I haven’t found an exact match to my situation. I’m sure it’s something silly that I’m messing up:
I am using Fusion 360 and say I do an initial 3d adaptive clearing path on a relief. Works great. I then create and a second path with a smaller / shorter bit, removing ‘Stock to Leave’, and postprocess/export a separate nc file (not even trying to do a tool change in the same file, as I read that could cause these types of issues). I change out my bit on the machine, re-probe Z in the same spot as before, and kick-off the new file. This works as expected if the bit height is >= to the bit from the first pass, but with a shorter bit, I’m just cutting air up above the stock (~quarter inch high or so).
It seems like it’s somehow saving the bit height from the first pass, even though I’m in a totally new file and re-probing Z with the new bit. I feel like this has to be something simple I’m missing, most likely in Fusion 360. I’ve triple checked my bit dimensions in Fusion 360… although I can’t see how that would matter with the re-probe. Any tips?
Thanks Derek - I should have specified that. The toolpath looks fine in F360, it shows it going down and cutting material away at the correct depth.
I’m using the same exact process when probing Z for the initial path and the second finishing path - just pressing ‘Probe Z’ and following instructions. I am wall mounted, so I have to hold the probe, which I have found can introduce some slight discrepancy between probes… but the bit is off way more than that… and it’s happened consistently so many times now that I’m convinced it’s something else.
A simple test is once you probe Z use the joypad to move the bit to the zero position. You don’t have to get it perfect but close enough to confirm that it did zero correctly. Once you confirm you zeroed it correctly then it must be your code.
I usually don’t advise people who are new to this to try editing their codes. Don’t get me wrong adding it is a good idea in general. There’s nothing like a simple check before the bit actually touches the wood to know if you’ve made a mistake after you press play.
Entering something like G0 Z0 into the command entry field of MDI Tab is in my opinion a simple way to show people that there are different ways to move the machine manually (jogging with the gamepad or the pendant, clicking on the arrow keys on jog pane on the display, or entering single motion commands into the manual data interface (MDI) (and to overcome any possibly existing inhibitions with a low threshold by showing that manually entered g-code commands don’t bite, but give a good feeling of self-efficacy while at the same time experiencing that it is so simple )
Hey All - Thanks so much for the tips / questions - This was all very helpful, as after doing these tests I found that eyeballing the bit back to zero did end up with Z at ~-.25 in… which confirmed my offset issue.
I’m embarrassed to say, the problem ended up being that one of my Z slider screws had vibrated loose, and was blocking the slider from descending that extra .25 in… an issue that wasn’t encountered with my longer bits. So there you go, it was silly user error.
Again, thanks for the help - these tips helped me cut through to the issue. Maybe this will be useful in the future to some other schmuck who just didn’t tighten the screws enough.