I wanted to mention that all the stuff in my github repo is based off of information found here and in other various linked github repos. I threw them into a repo to keep myself sane, but they are certainly inspired by all the work that has come before. So shout out to every here who has worked on this long before I poked at it for a weekend 
2 Likes
Did you use my Macros directly or did you import the gSender config bundle?
For bitsetter, it always does a tool load at max Z for me before going to the bitsetter location, so this is kinda funky that it would be so low when you ran it. Or maybe I was doing something differently when I used it, also entirely possible…
the imported the macros, and imported your gsender confiig.
the bitsetter toolchange macro ran perfectly.
the thing that I noticed is that if you use the goto commands [see screenshot below] it moves the Z axis to the safe height first.
Your config that I imported had it set to 30mm (i set mine to 5mm beforehand, and importing the config overwrote it) and that caused the Z axis to be very close the the bed, or at least closer than I would like. in the cases where i used it, my Z was at the homed height (i.e. 3mm off the endstop) so it actually moved my Z axis down by almost 27 something mm, which initially cause my heartbeat to increase.
Ohhh ok. So it wasn’t the Bitsetter macro, but the Go To buttons. Got it! That makes more sense. Safe height could definitely be higher.
I adjusted my original post for clarity, sorry for any confusion. And the bitsetter macro worked great as well. I haven’t actually made any chips with gSender as of yet, but i ran the routine just to see it working properly.
I mentioned this in the other Nomad/gSender thread, but i modified your macro, and the post toolchange hook to just return the machine to the “parked” position, rather than the work zero, because when i had ran the macro initially after turning the machine on, it sent them machine right to the endstops (for me at least) and ended up firing off an alarm. Now when it returns to the parked position, i believe it operates the same way as the Carbide Motion toolchange routine.
Would you mind posting an issue on my github repo with the code for this change? I’d like to make the same change in the repo.
Thanks!
1 Like
sure!
20 characters limit.
results of setting XY zero with the touch probe using gSender. pretty damn good. Using the “stock” X & Y probing routines in gSender is pretty user friendly, and it attempts to probe the way the endmill/probing dowel would move using the bitzero. I did a test before actually sending the probe towards a solid object. I used 100mm/min and 50mm/min speeds for the initial and accurate probe speeds.
You have to specify the diameter of the “tool” you are using, in this case the probe tip diameter is 2mm
I didnt think to get a video, but it looks the same as everyone elses.
i got crpalmers probe_hole macro working after a slight modification, not sure if CNCjs differs from gSender, but it gave me errors running as is.
the picture above, is after running this macro to get my hole center on this part.
%RESTORE_FEEDRATE=600
%x0 = posx
%y0 = posy
%global.state.PROBE_DISTANCE = 25
%global.state.PROBE_FEED_FAST = 100
%global.state.PROBE_FEED_SLOW = 75
G91 ; Relative positioning
; ====================== X pass 1 ===============================
; Probe toward right side of hole with a maximum probe distance,
; zero at the point and then return to the starting point
G38.2 X[global.state.PROBE_DISTANCE] F[global.state.PROBE_FEED_FAST]
G38.4 X[-global.state.PROBE_DISTANCE] F[global.state.PROBE_FEED_SLOW]
G38.2 X[global.state.PROBE_DISTANCE] F[global.state.PROBE_FEED_SLOW]
%wait
%return_x = x0 - posx
G10 L20 X0
([return_x])
G1 X[return_x] F[RESTORE_FEEDRATE]
; Probe toward Left side of hole with a maximum probe distance,
; zero in the middle based on where it touches and return to X=0
G38.2 X[-global.state.PROBE_DISTANCE] F[global.state.PROBE_FEED_FAST]
G38.4 X[global.state.PROBE_DISTANCE] F[global.state.PROBE_FEED_SLOW]
G38.2 X[-global.state.PROBE_DISTANCE] F[global.state.PROBE_FEED_SLOW]
%wait
%return_x = -posx/2
G10 L20 X[posx/2]
G1 X[return_x] F[RESTORE_FEEDRATE]
; ====================== Y pass 1 ===============================
; Probe toward back side of hole with a maximum probe distance,
; zero at the point and return to the starting point
G38.2 Y[global.state.PROBE_DISTANCE] F[global.state.PROBE_FEED_FAST]
G38.4 Y[-global.state.PROBE_DISTANCE] F[global.state.PROBE_FEED_SLOW]
G38.2 Y[global.state.PROBE_DISTANCE] F[global.state.PROBE_FEED_SLOW]
%wait
%return_y = y0 - posy
G10 L20 Y0
G1 Y[return_y] F[RESTORE_FEEDRATE]
; Probe toward front side of hole with a maximum probe distance,
; zero in the middle when it touches and return to X,Y=0
G38.2 Y[-global.state.PROBE_DISTANCE] F[global.state.PROBE_FEED_FAST]
G38.4 Y[global.state.PROBE_DISTANCE] F[global.state.PROBE_FEED_SLOW]
G38.2 Y[-global.state.PROBE_DISTANCE] F[global.state.PROBE_FEED_SLOW]
%wait
%return_y = -posy/2
G10 L20 Y[posy/2]
G1 Y[return_y] F[RESTORE_FEEDRATE]
g90
2 Likes
I love seeing more of you using G38.4 in your macros!
2 Likes
i take zero credit, just modifying existing macros lol.
I did way too much testing on probing back when this all started. The combo of G38.2 & G38.4 really helped to increase the precision of the probing. I think there will always be limitations with the original grbl controllers, so every bit helps.
2 Likes
I added a comment in github but I guess you figured out what the error was. It would be good to get the Probe_Insert_Probe macro into your workflow though. With that you can set a Z zero using the probe as well. If you aren’t doing a tool length measurement of the probe, you’ll have problems trying to set Z zeros.
1 Like
yeah im not sure how i would get that working with the nomad toolsetter, wouldn’t i need to know the z difference between where the Nomad’s BitSetter triggers and where I would be probing with the touch probe (probably in a corner of the bed, since I dont think I can move the bed out of the way enough to probe the aluminum base plate.)
for the moment I’ve been re-running a BitSetter tool change after setting XY zero with the probe, and setting z zero by eye, but I would definitely like to get some variation of that macro working.
Ah now that’s clever! Trigger the sensor and set 0 as soon as the sensor is no longer tripped.
Today I learned.
(Thanks for giving me an hour or so of macro cleanup work 
)
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 PRB 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…
3 Likes
I think the G38.4 would be much more accurate than the 38.2s.
It’s probably still a similar issue in that it’s not storing the exact coordinates but moving away from the target can be done at a much slower rate without extending the probe time too much.
So leveraging a very slow G38.4 may be the most accurate we can get with an unmodified setup 
Not yet…
@neilferreri OK, understood.
@HeuristicBishop My approach to compensate for the overshoot is to approach the workpiece/puck with G38.2 at 150/mm-min, then retreat using G38.4 at 15mm/min. Observing the machine during this, with Chamnit’s explanation of deceleration in mind, even at very slow speeds (2mm/min) the steppers continue for 12 steps after first contact - almost like the deceleration routine has ‘12’ somewhere enshrined in its logic.
One last optimisation is have in mind to explore: storing current machine pos from a slow G38.2 approach, then retreating using slow G38.4 and halving the positions to give the mid-point. It will mean 3 G38’s if a fast approach is also necessary (for time reasons). One to have a play with…
It’s the best I have for now, and hopefully ‘Not yet…’ will bring something along
If 12 really is a magic number like some hardcoded minimum deceleration value then at least it’s consistent.
If it’s consistent then maybe hardcoding your offset in the routines isn’t terribly crazy.
Splitting the difference should do roughly the same thing, with the 12 steps in opposite directions effectively cancelling but i wonder if it’s necessary
I suppose at the end of the day, either method would net you some exceptionally accurate results compared to what most folks are looking for 
Thanks for sharing this new found quirk of gSender