Awesome Mike,
Thanks again for the wealth of information. I will start looking to incorporate the macro once I finish off this last project I’m working on. I ordered my IOT Relay, it should arrive by Monday, or Tuesday. Looking forward to that as well -
And thanks for the Link! 
JENN
So big upgrade to this code with a huge shout out to @Cryptonym he re-wrote my very basic code to include subroutines. Really streamlined everything, top notch work Warren! So this version will measure both tools at the first tool change, each subsequent change will only need to measure the new tool. Also, it will carry the tool # forward to the correct dialogue box. Also, I added a move towards the middle of the machine for the actual changing of the bit, little easier than working way off in the corner. This version will not cause problems with the laser.
So this has been tested with the Onefinity PP for Vectric. THIS HAS ONLY BEEN TESTED WITH METRIC FILES AND CONTROLLER IN METRIC. There is likely some changes needed to use imperial. I’m not sure how other PP’s or software will work with this code. Firmware 1.0.8. I suspect that all the 1F PP’s will be similar so should work for them. IF your gcode has an M06 command for the FIRST tool there is some modifications that can be made to avoid the first probe sequence that would be unnecessary.
In the program-start dialogue box under settings in the flyout menu copy and paste the following:
(Runs at program start)
G90 (Absolute distance mode)
G17 (Select XY plane)
#5000=-999
o10 sub
G53 G0 Z-10
G53 G0 X780 Y50
o15 if [[#5000] EQ -999]
M0 (msg, Remove Dust Boot, Attach Magnet, Click “Continue”…)
o15 else
G53 G0 X600
M0 (debug, Remove Dust Boot, Insert Tool #<_selected_tool>, Attach Magnet, Click “Continue”…)
G53 G0 X780
o15 endif
G92.2
G53 G0 Z-70
G38.2 Z-133 F100
G0 Z[#<_Z>+1] F100
G38.2 Z-133 F25
o10 endsub
In the tool-change dialogue in the settings copy and paste the following:
(Runs on M6, tool-change)
M70
S0 M5
G21 G40 G49 G17 G90
o20 if [[#5000] EQ -999]
o10 call
#5000 = #<_Z>
G53 G0 Z-10
G92.3
o20 endif
o10 call
#4999= #<_Z>
G92.3
G0 Z25.4
G92 Z[#5000-#4999+25.4]
G53 G0 Z-10
#5000 = #4999
M0(MSG,Remove Probe, Install Dust Boot, Click “Continue”…)
G0 X0 Y0
M72
I cant figure out whats going wrong when i try to use this. i got most of it to work but it says z axis is over. ive been using carbide create, turns out it doesn’t add m06 where tool changes should be so i added it my self in the gcode. I probed Z, started the program, it went to tool change location and measured the tool, it cut the first path then returned to the tool change location but i noticed it seemed a little low, i changed the tool and hit continue and it raided straight down into my touch block that now has a couple nice new dimples in it. i only know a tiny amount of gcode and looking at the code im trying to use i cant figure out what im doing wrong for it to rapid down like that
Mine pretty much always says z is over. Never have any issues with probing straight down and not stopping unless I forget to attach the magnet. Can you make a simple square or something with 2 different tool paths and upload the gcode file and I’ll have a look. And maybe copy and paste what you’ve got in the program-start and tool-change dialogues. I’ve only ever used this with vectric, but I believe @Cryptonym has been using Carbide create and testing with that.
Do you have the probe block sitting way above your tabletop? If you do you may need to change the code to slow down at a higher height.
In the subroutine change the line after the G92.2 line from
G53 G0 Z-70
To like
G53 G0 Z-25
That will slow down like 2 inches higher. Basically it will then start searching (G38.2) for the probe 1 inch down from the max Z height, instead of 3 inches. I run with my probe on the tabletop, not on the spoil board. The -70mm along with how much bit you have stuck out might have been too optimistic.
For testing, I loosened the screws that clamp the router so if it were to not stop, it would just lift the router.
I wrote my code on 1.0.8.
Be aware Mike and I have discovered that some programs emit M6 commands at every tool change and some do not. His code is aligned to those (vectric) that do not, while the code I posted in the Onefinity Facebook group is meant for those who do insert m6 codes at every tool change. This means there is no magic “one” solution to bitsetter code, and if you use multiple programs, you may need to modify the program post processors to align to one way or the other.
thanks, this change gave me enough time to react if there were an issue. this is the only change ive made and it seems to be working now. i went through the whole process a few times and i “think” i see the issue and its a weird one. when i probe z to the face of my material it was zeroing the absolute as well. i did this tree times homing Z in between before it finally left Z absolute at something around -3.1 the first tool change would start out at only a little higher then my material if absolute had zeroed and all the way at the top if it stayed at -3 ish. i really dont know why it was happening
Are you homing the machine? Probing Z to the material surface should not change absolute coordinates to 0. After probing the unlabeled column should likely read somewhere around 12.5-12.7mm. And absolute will be some kind of negative number. Not sure if you’re in metric or imperial?
@Cryptonym perhaps there is an issue here because Charles is in imperial? There’s no G21 call in the subs in program-start that could be causing these issues I suspect.
The m72 should restore it to imperial if that is what was in use, but I can’t say I’ve tried it in imperial.
Is the amount of bit sticking out greatly different? For example, is bit 1 short and bit 2 extra long, or vice versa? I tried many runs with varied lengths with no issues. Since the routine is to keep the end of the bit at the right height, the clearances shouldn’t vary.
Yes but if there is no metric call in the sub won’t it default to imperial for G53 G0 Z-10? And try to go 10 inches below absolute zero.
G53 G0 Z-10 is in metric. The G21 tells in to use metric for numeric positions. M72 should return it to G20 if it was set. Basically it shifts everything into metric for the process, then restores whichever it was on exit.
What I’m wondering though is the G21 that is called in tool-change applied to the routine that is defined in program-start, or when that routine is called is it being left in G20 as that is what the gcode called for?
G21 is in the tool-change block not program start. Additionally, if the actual program has a G20 in it, that would run after the program-start code so it would just toggle at that point.
@anioconn said changing from -70 to -10 helped with the probe ramming. Therefore I think it was some combination of bitsetter height and bit length.
I cannot explain the initial probing behavior seen before he starts the program though.
@anioconn , when you went to 1.0.8 firmware did you reset your settings also in the web UI. Some people have had odd motion behaviors if they skip that step.
Sorry I didn’t reply sooner I got frustrated yesterday and called it a day. ill try to answer everyone’s questions thanks again for all the help. I’m homing the machine and making sure the absolute value is correct and the probing the surface of what I plan to cut (z). After I shut the 1f down for a bit and turning it back on it no longer seems to zero absolute when I probe z so I don’t know what that was but I’ll be keeping an eye on it for sure. I have a pretty new machine so I’m currently on version 1.07 I didn’t think it was super important to update immediately. I’m trying to change from a vee bit to a 1/4 inch endmill which after the changes you guys helped me make it finally worked and and I was able to get fully through the tool change and cuts. But then I tried to do them the other way around. Started with a 1/4 endmill and tried to change to the same vee bit. This time it crashed during the initial check of the 1/4" endmill. So I would thinkni have to be having some kind of height issues that “I’m " not easily able to see and change. so here is as much info I can think to give. I’m using a 3/4” mdf spoilboard, my z axis is mounted on the lowest possible mounting position. I’m placing the probe block on top to the work piece to probe z and placing g the prob block on top the spoil board when it prompting to measure tools. My vee bit sticks out of the router as close to 3/4" as I can get it and the 1/4" endmill sticks out about 1 inch at the shortest of my failed tests. The one successful run I’ve had changed back and forth between metric and inchs just fine just to answer that question. I saw that you had posted an updated version of this a few days ago should I change over to that or do you think it would be easier for me to problem solve on the older version first?
Thanks so much for everyone’s help
All FYI, I have been using the bit setter code in imperial and have had no issues.
Just wanted to check in and give an update for anyone curious. i updated from firmware 1.0.7 to 1.0.8 and change the macro to the one that was added just a few days ago by @BNB187. i also change my machine over to metric as well as the programs i was trying to run. Works flawless now with plenty of room for much longer endmills then what im using. Thanks again for every ones help and for the great macro
Hey Mike-
I am new to this so please be patient. I spoke to 1F support today about tool change issues with array copy tool path cuts. It seems to me that the concept of having to tool raise enough to change it should be an inherently rudimentary function. Sure, you can set the “safe z” to accommodate this, but in a large arrayed cut this adds considerable time to the cut. The suggestion was to save individual vector files which, to me, seems painstakingly tedious. Am I missing the boat, or am I just finding out that without a tool-change Gcode edit I might as well forget about array copies cuts? I will try what is laid out here as I am wishing I had started out metric vs imperial from the start anyway. Thanks- Morrelli
@BNB187 and @Cryptonym,
I am new to the game and I know this is an older thread, but I have been looking for this for a while.
Not to be over bearing with questions. But why can’t this be done like it is done on the Shapeoko or the Carbide 3D Nomad. Nothing has to be attached to the spindle or router. Their bitsetter/Z probe connects to the z probe location in the controller.
Just curious is all.
I was able to implement a script based off the script in this thread to use a tool setter from amazon (it was around $50) permanently mounted to my table wired to the controller breakout board with great success. For this to work it has to be mounted somewhere in the working area of the machine, I had mine in the front left corner wired in parallel with the probe block using the breakout board. I initially installed it it in the front right but this caused all of my programs to show “over” because the simulation didn’t properly interpret a G53 as absolute so moving to the tool setter switch on the right side was seen as beyond the limits of the machine although the actual movement is executed fine. Since it was mounted below the surface of my waste board it did not interfere with placing materials, I just had to make sure not to cover it with the stock. The other challenge with this setup was if the bit was too short it would hit the lower limit of the Z travel and would cause an e stop if it didn’t find the probe. Having the top of the tool setter about 3/4" above the waste board would probably yield the best results for the setup.
I’ve since upgraded to a Masso controller and moved the tool setter again to the back left of the table where it’s more out of the way and Masso doesn’t have the issue with how it handles the G53 command to locate the tool setter.