I agree with @NeilFerreri , that would be a good way to handle that I was just about to go look if you could pop a message and realized you cannot, and cancelling after the M6 is super non-intuitive.
Mike
Anything that will give information or leave flexibility for a user changing their mind or forgetting what to do next, especially at tool changes is welcome. It is hard to foresee and pre-program for all eventualities. I would like any comment on a M0 or M6 command line to show up in the dialog box to remind me what I wanted to happen next. I would also prefer to use the existing manual Z probe at tool change rather than a pre-determined macro, then just tell the thing to continue the job. There is also the possibility that I would decide a tool seems too dull so I could interrupt the job and replace the tool followed by a Z probe and tell it to continue
If I recall properly, with Gsender as is, you can go to the settings, and for Tool Change select “Pause”. In this case, you would turn off your router, jog the machine if necessary to change the bit, re-zero the new bit in the z-axis only, then continue with the cut.
By allowing us to extend that and run some code, we could pop a dialog box that would give you more information, such as the next tool number if it is listed in the file.
Mike.
1 Like
Hi Neil. Nice to see you here. I downloaded and installed the macros without difficulty. Thank you for putting in the considerable amount of work to code these macros. I have adjusted the user variables and all is well. I have a two tool job, which I was going to cut as my first gSender routine. My initial tool was zeroed to the workpiece and then I ran the initial BitSetter macro. All seemed well. I came to run the job and the machine, standard sized Shapeoko SO3, started to cut air at 11mm above the workpiece. I had a few hiccups loading the job and removed hard and soft limits. No more alarms concerning the limits.
My question is where would be a good place to start fixing this small issue? Thanks
EDIT: to add that the air cutting is now fixed. It was my failure to account for the stock depth at one point in my processes.
1 Like
Hi Neil,
It’s been a while since we chatted!
I was woondering if you know what the pinouts are for the BitZero v1, please? I wan to use it on my RatRig 1075, which is controlled with a Duet3 MB6HC, via one of the io ports, but I just need a little more infrmation to ensure I don’t fry it!
Nice to see you here!
Thanks
Just installed gSender and the macros from @NeilFerreri my shapeoko seem to run great on it and I love it! until I do a bit change, for some reason after running “New_Tool_bitsetter” my Z height is 0.816" lower than it should be. even if I don’t change the tool or the height. Any help would be greatly appreciated.
Current setup:
Shapeoko3 xxl
currently using touch probe for tool length (BitZero V1)
changed “%global.state.PROBE_DISTANCE = 100” to =30 (in both macros) I was getting soft limit errors before. yes, I put it back and disabled soft limits for testing and had the same results.
I run my machine in inches
Current test procedure:
install bit
probe for Z
G0 Z1.0
check with 123 block z= 1.0"
run Initial _Tool_Bitsetter macro
G0 Z1.0
check with 123 block z= 1.0"
run New_Tool_Bitsetter macro
G0 Z1.0
z=~0.184 (didn’t measure but that was the difference in the absolute Z coordinates)
Thanks again for any help!
1 Like
I am using gSender and Neil’s macros. I used a BitZero 2 with BitSetter but gSender is looking for a solid probe rather than the probe that needs centring in a hole.
My routine is measure Z height 0 by touching off
Run initial tool length macro
Mill part
Change tool command
measure tool length using second macro
thats it. I routinely carve using two or three tools and the macros work great
I should have clarified that I am using a BitZero V1. so there is no hole, but definitely see how that could be an issue. Thanks.
1 Like
Yes of course it was. I switched it and it works like a dream!!!
Thank you Very much @NeilFerreri! I knew it was going to be something silly like that.
1 Like
Great! No problem.
Only reason I had that thought is because you’re not the first. I don’t think I ever explored why (it still should work), but I just chalked it up to rounding issues. Generally, Grbl prefers metric.
@NeilFerreri macro’s work perfectly for me. One question:
Is there a way to modify what gSender does when you select “Manual” from the tool change settings screen? I like that it lifts the router and moves it to Machine x0y0, but I would like to add an M5. I hate that the spindle keeps whirling away until I manually send an M5 from the console. In a perfect world I would also send it to hover over the tool length setter rather than Machine X0Y0.
That would be better if it were included in your program when you post process?
What cam program and post processor are you using?
I use Fusion 360 with the stock GRBL post processor. That said, I don’t understand your suggestion. Currently the post processor adds an M6T{tool number}. Nothing else. I assume that gSender is interpreting that M6 and sending some pause command (M0?), and code to send the spindle home (G53X0Y0Z0?). I am just wondering if I can customize it a bit.
Of course, there are many ways to skin a cat. I suppose that instead of setting tool change to “Manual” I can set it to “Code” and try to recreate what it is already doing. But I like the way it works now, I just want it to stop the spindle while it waits for me to initiate the tool change macro. I was hoping there was an easy way to add an M5.
Try my post processor for Fusion…more configurable options. It will add an M5 spindle start command before the M6 tool change command, and it will add an M3 spindle start command after the toolchange is complete. You can also configure the spindle ramp up delay time.
1 Like
OK, I good with CNC, but software modifications I am not - pertaining to the carbide bit setter, you mention; how is the macro enabled and or loaded into g-sender to make the bit setter function properly. I use the touch pad, but it more tedious than the bit-setter
Rxman tomkaye@rxman.com
I have bought and wired in a 0.01mm capable touch probe (various people have referred to one, from Amazon or wherever for about $70). It works really well, and leaves me now to adapt @NeilFerreri macros to be able to probe back left as well as front left.
These macros are up and running, and working exactly as I hoped, except for inertial errors…
The probing technique in these macros is to call G38.2 and wait for a trigger, then read the machine position.
Link to Chamnit discussing this (Grbl leader/guru): Change probe architecture from polled to interrupt · Issue #1095 · grbl/grbl · GitHub
I am seeing a consistent X and Y error when using my 0.01mm touch probe, and from what I can read this is down to deceleration (of necessity) in the X and Y gantries, the ‘inertia’ mentioned above. A suggestion to improve this (0.3mm approx) error is to read the PRBZ, PRBX and PRBY machine co-ordinates that are stored in the same stepper ‘step’ as the trigger happened, rather than the machine position when G38.2 returns.
The original macro line that stores X after probing is, current X ± probe dimensions etc;
G10 L20 P1 X[-ENDMILL_DIAMETER/2 -PROBE_BLOCK_X]
This would become, I think, with PRBX access;
G10 L20 P1 X[PRBX -ENDMILL_DIAMETER/2 -PROBE_BLOCK_X]
So, can gSender read PRBX etc parameters? They appear in the console log, so I reckon gSender might have seen them…
I can concoct a test tomorrow, when I can get back on my machine, but I wonder if anyone knows for fact EDIT: testing doesn’t reveal any obvious way to obtain the PRB: results that happen in the instant the probe triggers - without access to this, one is reliant upon ‘calibrating the overshoot’ and compensating accordingly…
Any inputs on the PRB: data, and whether it does in fact get captured into a variable(s) would be much appreciated - for example: Tormach describe exactly this capture, but I cannot find anything in gSender or CNCjs that refers…
2 Likes
Hi all! I know many of you joined into this thread to discuss tool changing and BitSetter support within gSender and I wanted to let y’all know that with the 1.2.0 release of gSender (The next big release for gSender is here! (1.2.0)) we’ve now got (what we hope) are adequate alternate ways to deal with tool changing rather than running custom macros.
Obviously this was all kicked off by @NeilFerreri and the interest of many of the rest of you as well as the Shapeoko community as a whole. I’d really like to hear what you guys think about this new implementation"
- did we miss the mark entirely
- is it still too constraining
- are there small improvements we could still make
We’ve tested things for many many hours but ultimately there’s only so much we can do ourselves so the feedback would be greatly appreciated 
Chris
2 Likes
Hey Chris. I’ve been using @NeilFerreri’s code for a while now to streamline tool changing with my BitSetter and my router power controlled by a relay outlet and I’ve been really happy with the results. I tweaked the code a bit to get the workflow I liked where at a tool change command:
Router lifts up
Router turns off
Moves forward to position to easily change the tool and pauses
I remove dust boot, change tool and click resume
Router moves to bit setter location and probes new tool
Moves to new x0 y0 z0 so I can make sure everything is good, click resume
Router lifts so I can put dust boot back on, click resume
Router turns on and resumes program.
I was excited to hear about the new features in 1.2.0, but without being able to enter custom tool change code, I lost some of the features I liked having, mainly turning on and off the router with M8 and M9 and giving me a place in the process to take on and off the dust boot. If possible in an upcoming release, I would love to have access to more settings allowing me to control the process more or at least be able to add custom tool change code again. Thanks for all the hard work and can’t wait to see the future updates!
Jon
2 Likes