search

terjeio / ioSender

A GCode Sender for Grbl and grblHAL written in C# (Windows only).
BSD 3-Clause "New" or "Revised" License
207 stars 65 forks source link

Probe protection not compatible with existing probe macros #330

Closed andrewmarles closed 9 months ago

andrewmarles commented 9 months ago

In the law of unintended consequences, the new probe protection plugin is not compatible with the IOSender probing macros.

As an example:

G38.3F100X10
!G0X-0.5
G38.3F25X2

Above probes to the workpiece and stops on contact. The problem is the G0 move to the latch distance. That move is initiated with the probe still in contact with the workpiece, so it triggers the probe protection because it is a non-probing move executed with the probe in the asserted state. With the probe protection, the macro would need to be as follows:

G38.3F100X10
!G38.5F1000X-0.5
G0X-0.5
G38.3F25X2

Here the probe is first taken off the workpiece with G38.5 so that the probe de-asserts, and then the rapid move can be used to finish the action.

I do apologize, I am not really set up to build IOSender and create a PR, but I had a look at the code. I think that to fix this in the sender would need the addition of a "ProbeRemoveContact" command to the ProbingViewModel.cs as well as small modifications to the various routines to insert the G38.5 moves to first pull the probe off the workpiece before executing the rapid moves.

Alternatively, I'm very happy to try to address this in the plugin, but I am not completely clear how to do that. The protection function is working as intended, it just isn't working the way that people expect when used with IOSender. I could look at trying to add something to specifically disable the protection during what are obviously pull-off moves, but I think that logic would get very complicated in the controller and be problematic.

Thanks for your attention as always.

andrewmarles commented 9 months ago

I think a possible work around in the controller would be that probe protection would not assert if a movement is begun with the probe asserted, only if it happens while in motion. I do think that is somewhat perilous, but it would resolve this particular issue.

andrewmarles commented 9 months ago

Ok, thanks to some sleuthing we found how they are doing it in LinuxCNC. They are just looking for a rising edge on the probe signal during moves, we can do that quite easily and this should preserve compatibility with existing probing macros:

https://github.com/LinuxCNC/linuxcnc/blob/29db881ed934174e26ac2f3390b01f74fcd20f80/src/emc/motion/control.c#L716