Is there anything inherently wrong with this workflow that could cause an x-offset of about 1mm after doing a tool change? It uses multiple nc files. Ideally I’d have a single one but the free Fusion 360 won’t allow it.
Cut with first tool
turn off the machine
fight with it to change the tool (see other thread on stuck precision collets)
turn it back on. Re-initialize. This should ensure X and Y are precisely the same as the first tool, no?
Bitsetter gets the new Z
This should work in theory? If so, what are some possible sources of a 1mm X offset I can look toward to prevent this from happening again? I broke a very expensive endmill on this and obviously want to avoid that.
Alternatively, if I need to complete the entire job using a single file without re-initializing, any ways to manually join two gcode files and ensure the tool change is coded in there correctly ? and no extra initializing steps are going to mess things up (i’m not yet terribly familiar with gcode).
You don’t have to turn the machine off to change the bits, you can spare yourself re-initialization. In theory, the X and Y origins should remain the same after you restart. I know some people zero their coordinates after the machine initializes, homes, and pulls off then they set their origin. Depending on your work flow, you could get messed up.
I’d add the gcode files together as you stated create some simple projects in Carbide Create with multiple tool changes and look at the files in MS Notepad - note the M6 followed by the tool number commands - they prompt the tool changes when running the gcode. Practicing stitching cut files together with simple projects with the router off and air cutting to gain confidence. It’s a shame to let your BitSetter collect dust while doing manual tool changes.
To be clear, it IS using the bitsetting. I’m not manually re-zeroing because I believe that is more likely to introduce exactly this problem. By leaving the X-Y zero in tact, and using the bit setter to rezero Z after the tool change my assumption was everything should be lined up correctly.
Does your recommendation to use a single gcode file imply that there’s something inherently more accurate about that?
I’m really interested in learning what went wrong to avoid it again. Can you be more direct about what you think went wrong? Or are you just recommending what you believe to be a quicker/simpler workflow (in which case I agree… but doesn’t get at the problem here).
Thanks.
Oh right… you are using the BitSetter haha. My thoughts on the different sized diameter bits would have only been an issue if the second tool path assumed that you were using the same sized bit as the first tool path, then it wouldn’t account for the change in diameter.
As for your workflow, you
-Power on the machine.
-Initialize/home the machine.
-Load your first tool and go through BitSetter operation.
-Use BitZero to set X,Y, Z.
-Load program.
-Run tool path 1.
-Power off machine.
-Change to tool 2.
-Power on machine.
-Initialize/home.
-Run second BitSetter operation.
-Load second file.
-Run program two.
Is that correct?
What I was also getting at earlier is that some people zero out their coordinates after the machine initializes/homes and then set they’re origin. I could see someone being off by the pull off value (the configured distance the carriage moves away after activating the homing switches) if there was some inconsistency where the user zeros after pull off initially but can’t do so when they turn the machine back on after powering off and installing the second tool because then they would lose X,Y origin.
I was recommending a single gcode file for the simplicity. The simpler the better, perhaps less mistakes with less steps. Theoretically turning the machine off and re-initializing should get you to exactly where you were since the homing switches should be capable of that accuracy; however, it’s a variable no less.
Thanks for the info. If there’s nothing obviously wrong with that I’m going to temporarily chock it up to some sort of user error that I don’t recall doing… And I’ve got some cheaper end mills on order, so I’ll give it another try using those. I’ll also try running the job on some wood instead of aluminum.
My experience is that re-initializing the machine will NOT reliably get back to exactly the same co-ordinates. In my case, depending on where the gantry was when the machine powered up, then after homing and going to a particular position (in my case rapid SW) the end position would be slightly different. You might be able to get around this by ensuring that when you power down the machine your gantry is always in the same place (I would use NE, to reduce homing times).
Either leave the machine on AND connected (likely the most reliable), or re-zero each time you re-power the machine.