Protected Moves with a Touch Probe

NineMile

@chrishamm said in Protected Moves with a Touch Probe:

@NineMile I'm sorry but my CNC machine isn't operational at the moment so I cannot really check your PR. Perhaps @Sindarius can comment on this, he developed the CNC frontend, too.

I've got a touch probe as well but it will take some more time before I have it working.

That's no issue I haven't written the code (for DWC) yet - currently my protected move code is only in RRF macros.

I'm talking here about a proposed addition to DWC, completely separate to my existing macro code, that would switch the gcode sent from the movement panel and movement dialogs so that if the user selects to protect their moves with a particular probe, the jog buttons would use G38.3 with the configured probe ID instead.

I was curious if you have any input on this before I write the code.

On the testing front, there's a ton of Milo CNC owners using DWC with touch probes who I think would be more than happy to test the changes if that would help.

oliof

@NineMile an alternative would be to build your own UI with btncmd plugin

NineMile

@oliof said in Protected Moves with a Touch Probe:

@NineMile an alternative would be to build your own UI with btncmd plugin

My end goal is to complete a DWC plugin (currently in progress) that acts as the user interface for the MillenniumOS probing macros (pre this plugin, the "interface" was driven by M291 dialogs) - adding protected jogging is a feature that I would add to this plugin in lieu of any other option.

I think protected jogging is a generic enough feature for CNC owners that integrating it into the CNC movement panel is the best approach, and while I think BtnCmd is great, I also think it would be great for the "default" UI to cater to more advanced CNC use cases.

oliof

@NineMile fully agree that it would be a good default feature; just wanted to mention the alternative way to add it

o_lampe

For people not having that touchprobe thing, would it help to use modified "sensorless homing" moves as crash protection?
You'd check for contact , but don't set coords to whatever your homing coodrs are

NineMile

@o_lampe said in Protected Moves with a Touch Probe:

For people not having that touchprobe thing, would it help to use modified "sensorless homing" moves as crash protection?
You'd check for contact , but don't set coords to whatever your homing coodrs are

That'd be interesting. There's a P10 probe type which means use Z motor stall detection as the Z probe trigger, so in theory that could be used with the same straight probes that I use to implement touch probe collision prevention, but whether or not that works for non-Z axes is an important question - there's no way to configure axis on the probe itself, but I wonder if running G38.2 K<z-stall-detection-probe> X<target> automatically switches to monitoring the X axis stall sensor?

If it was possible to configure the command used for movement sent by DWC then that would make everything easier but that opens a large can of worms and possible screwups.

Whether or not motor stalling will stop you from damaging anything though is another question. The Z axis on my CNC happily snapped my touch probe tip clean off before the motor even stalled, so depends on your axis power I guess.

I started looking at the touch probe move protection yesterday, adding a button to the CNC movement panel to allow the protection to be configured / unconfigured:

Doing this reminded me why protected moves was a pain to implement in the first place - G38.2 moves do not respect machine limits, and they appear to always run in absolute co-ordinates (although the docs say that was fixed in v3.11? ) - so there needs to be some validation of the current machine position and generation of the target absolute co-ordinate rather than being able to just send a static gcode like the current buttons do.

This means I'd need to refactor the way the button gcode is generated slightly - not a particular issue, but might make it a little more complex than I remembered

Gonna keep working on it and see what it looks like when fully implemented.

gloomyandy

@NineMile I'm a little puzzled as to how this will work. Most probes will only detect an object when approaching from a particular direction (so from above in the case of a standard Z probe), is that not the case for the probes you are using here? In which case you will only get this protection in those cases? Also when performing probing moves are the coordinates not based on the probe end point rather than the normal tool position? Will this not cause a jump in the "current location" when switching from normal moves to "protected moves"?

As to using stall detection you will normally need to ensure that a number of things are in place for this to work reliably (so motor operating mode stealthchop/spreadcycle depending on the driver in use), motor operating current plus minimum motor speed etc. I'm not sure how safe it would be to switch these various parameters on the fly.

o_lampe

@NineMile Last time I tried, you could use sensorless homing/stall detection on any axis.
But you are right, you'd have to reduce motor current for those moves, but at the same time it needs a minimum speed to be succesful.
I wouldn't like to see my 50$ router bits crashing in a clamp.
Maybe a regular endstop-config would be a better choice? When the routerbit itself gets electric contact to the metal clamp it doesn't wait for so_many missed steps to trigger alarm.
@gloomyandy That kind of metal2metal contact probes would trigger in any direction, but you wouldn't know where the obstacle is. No problem for an emergency-stop IMHO

NineMile

@gloomyandy As mentioned, this is intended for use with a '3D' CNC Touch Probe, they can indeed detect contact in 3 axes. Generally the ones in use on the Milo and other CNCs look something like this internally:

These are installed in place of the cutting tool so generally don't have an X/Y offset.

When trying to probe a workpiece, the usual workflow is to position the probe near to the feature to be probed - either inside a pocket, over a corner, inside a hole or centrally over a rectangular block.

The probe tips and mechanics are incredibly sensitive, and overtravel of a few millimeters will easily damage the probe tip or the internals.

The idea behind the protection is to make sure the probe status is watched while the user is moving the probe around (manually) to position it near the relevant feature.

Accidentally jogging in the wrong direction might cause the probe to make contact with an unintended surface and when protected, that would cause the move to stop rather than continue to the target position and damage the probe.

NineMile

Implemented limit checks and machine position calculation so the moves work properly, this is how it works in practice: video