Probe and Tool Length Sensors on Separate Pins?

[jaymis]

Hey terjeio and others. I've just switched my 4-axis PrintNC to grblHAL on a GRBLHAL2000 board (I've also had it running on one of Phil's Teensy 4.1 boards, but I wanted to try the GRBLHAL2000 as it was created by a member of the PrintNC community.) Moving between boards was super easy thanks to ioSender's grbl settings backup, so thanks for that terjeio.

In setting up the new board, I've come across an interesting edge case that may be something to think about for future development:
I have both a 3D touch probe (DIG3D.LP.M) and a tool length sensor (generic Aliexpress one, like this).
Both are NC sensors, but the touch probe has a magnetically connected cable, which gets removed when not in use, breaking the circuit. So I can't just daisy-chain the two NC sensors.

Would there be a way in current or future grblHAL to use separate inputs for probe and tool length sensors? Or perhaps to specify an input to use while probing vs tool changing? Z- limit input could make sense as a tool length sensor.

Obviously there's a number of ways I could get around this - stop unplugging the 3d probe, make a physical switch to choose which probing device to use - but if I can make something a bit more foolproof in software, then I have less chance to break stuff.

[andrewmarles]

I think that stock LinuxCNC still only uses a single probe pin, but at least both Pathpilot (Tormach) and Haas use G37 for this function with their toolsetter implementations in order to separate the function from normal probing.

[terjeio]

Would there be a way in current or future grblHAL to use separate inputs for probe and tool length sensors?

There is already if driver code is changed and a way to select the correct input is added. Making it generic is a bit more tricky, at least an optional function pointer for selecting the probe input has to be added to the HAL structure so code (in a plugin?) can detect that input switching is available. Then there is the issue of which pin(s) to use, the best would be to have a plugin claim one or more aux inputs and tell the driver which to use?

A quick glance at G37 Tormach and Haas specs it seems to me that they are not equal so I am am not so sure I want to adopt that. Perhaps automatic switching could be implemented by hooking it into the grblHAL tool change protocol when touch off at G59.3 is enabled?

@andrewmarles Should I add a link to your GRBLHAL2000 board in the new repo?

[jaymis]

Woah! Great catch! So it triggers soft limits because the target is beyond the Z limit?

That should be changed to the Latch distance multiplied by some factor, perhaps 1.5? With a minimum of 2 mm?

That sounds pretty reasonable. I don't think people would commonly have their tool setter right on the Z limit, and I don't see much reason for big latch distances, especially as the default is 0.5mm.

I changed my probe distance to 60mm because I've got some quite short cutters and spot drills, and then some quite long carbide insert cutters, so I didn't want it failing on the short ones because I forgot to update the probe distance.

Perhaps a fixed (and configurable?) distance should be added instead? What do you think?

I think what you suggested - having it as latch distance with a little bit of extra - should do the trick. I'd expect that the latch touchoff would generally be shorter than the initial probe touchoff, because the initial probe speed is generally faster. Maybe some people do a slow probe then fast latch touchoff? Who are we to judge.

Sorry about wasting your time with this issue.

Not at all! I'm happy to help find and fix bugs, and really excited about grblHAL as a project.

I've been keen to figure out this probing stuff as I've been working on a 4th axis setup, where the origin is going to be in the center of the chuck/stock. So having good tool length offsets will be critical to getting good results as I can't touch off on the stock for tool changes once I start machining. Once it's working reliably I'll put together some documentation for the wiki, and might do a little video to show off the functionality and publicise it to the PrintNC community and beyond :)

[jaymis]

Just tested the new Edge version and it works perfectly with full speed rapids and 0.5mm latch distance. Tested M401Q5 and Q3.

Thanks Terje. This is so exciting!

[jaymis]

Hey Terje. I've had a couple of goes at getting my tool setting workflow sorted (so I could write up some documentation for the wiki), but I'm not sure that I'm doing it correctly.

Previously I was using CNCJS with a couple of macros for tool setting, but I've realised that I didn't know what was actually happening at the GCode level.

The workflow I had in mind was this:
Find work coordinate Z0 with 3D touch probe on vice or spoilboard.
Touch off on tool setter with 3D touch probe
Change to cutting tool and touch off again on tool setter to get updated Z0 for cutting tool

However I can't seem to figure out how to make this process work using ioSender.
I've tried using "establish reference offset" with the 3D probe on the touch plate and on the part itself, tried probing the fixture with tool numbers and without and just setting G54 work coordinate system.
When I probe with the 3D probe and then move back to G54 0,0,0 it is in the right place, but when I try to change to a different tool and "probe fixture at G59.3" it comes back and the G54 0,0,0 position seems to be way too high.

I've been trying to find information on the subject, including this thread but I'm still not sure. Do I need to do a $TPW command or something? Am I misunderstanding how ioSender does this?

[terjeio]

Touch off on tool setter with 3D touch probe

Before starting you should touch off with the current tool and set the reference offset. Subsequent tool changes will perform new touch offs and set the tool length offset accordingly.

Do I need to do a $TPW command or something?

That depends on the tool change mode ($341), if automatic touch off @ G59.3 then no.

Am I misunderstanding how ioSender does this?

Maybe you are complicating this since you are used to CNCJS?
When the controller is grblHAL tool changes are handled by the controller according to the mode selected. This includes movements to Z home and back to the workpiece after touch off has been performed if mode is not "Normal", from the $341 settings description:

Normal: allows jogging for manual touch off. Set new position manually.
Manual touch off: retracts tool axis to home position for tool change, use jogging or $TPW for touch off.
Manual touch off @ G59.3: retracts tool axis to home position then to G59.3 position for tool change, use jogging or $TPW for touch off.
Automatic touch off @ G59.3: retracts tool axis to home position for tool change, then to G59.3 position for automatic touch off.
All modes except "Normal" and "Ignore M6" returns the tool (controlled point) to original position after touch off.

This means that there is usually no need to add any movements related to tool changes in the gcode, TnM6 alone is enough. Spindle and coolant is turned off and back on automatically as well.

[jaymis]

Thanks for that Terje. I think my problem was that I was trying to test the entire toolsetting workflow just using the probing screen. When I instead used "TnM6" it worked perfectly! Time to make some parts and write some documentation.