ioSender
ioSender copied to clipboard
terjeio
probe macro simplification
I continue to have a hard time being able to predict the probe movements prior to running the probe. I trashed my probe last night due to the complexity of the probing screen and the fact that bart's port doesn't allow you to turn the probe monitor on for a probing macro.
Due to paralax I was off by just a little bit and the XY offset and probing distance values just don't make sense. I'm willing to do the work and submit a PR but last time I brought this up it didn't seem like you were willing to make any changes.
What i'm proposing is that the corner probing only moves out down and back from the starting position, no diagonal moves in the default. This would simply be another option and you could keep the existing behavior. I can put all of the changes in it's own tab that is toggled via the settings if that helps make it acceptable.
Ouch, that was bad. Simple probe protection as I have added to grblHAL via the Run substatus should be added as an option to Bart's port as well?
I can put all of the changes in it's own tab that is toggled via the settings if that helps make it acceptable.
Is your idea to add a new probing tab (in a separate project?) that can be selected via Settings: App? If so I like that as it is in line with how the app is designed.
Yes, that works, any pointers so i stick to your intended use of the tabs?
Not sure I understand what you mean by the above...
As I understand it you would make a simpler ProbingView (the main tab) and change some or all of the probing tabs to match. I believe it should be possible for you to use at least ProbingViewModel.cs and Program.cs, if not more, from the existing code either "as-is" or by subclassing/overriding bits as needed.
I'll give it a try and let you know where to take a look.
Bart's created a new setting to prevent the issue $Probe/Protection={Off, Reset, or Feedhold}. I've tested with your probing macro (center finding) and it seems to work and your code seems to recognize an error has occured and stops the probing macro. I think the big question I have now is; what is the best way to recover from an accidental probe trigger during a probing macro? The controller likely doesn't know how to move off the collision. it seems a soft reset is needed and then you jog away from the collision. how does grblHAL handle this condition?
I think the big question I have now is; what is the best way to recover from an accidental probe trigger during a probing macro?
Start over? If a reset is triggered then you can jog away, if a feed hold then a reset has to be executed anyway? A reset will lead to the home position beeing lost?
Currently probe protection is handled by the sender if the controller is grblHAL based, if a probe asserted signal is detected during non-probe motions a stop command is issued. The stop command is not as harsh as a soft reset, but position may be lost anyway so it is best to start over. I want to improve probe handling in grblHAL - some bits are already in place in the core but there is still work to do, IIRC mainly at the driver level.
I also noticed some limitations to the current probing routine.
During some of them there are G0/G91 commands for fast movements. During these the probe status is irrelevant. If you have made a mistake and set a parameter wrong your probe is probably gone for ever :disappointed:
There are some separate controller boards to protect probes during unintentionally touches. I thought there must be an easier way to implement such a desirable safety in the current setup.
A constant check during G0/G91 commands would be way to overkill and at least my mill might not stop in time.
It would be enough to check the faster movements during the probing routine.
Since we are running faster movements with G91 and an already existing Rapids feed rate parameter for probing, it should be possible to change the G93 with G38.3.
If the probe would sense something, the controller would stop the movement immediately. If there isn't a signal, G38.3 wouldn't give an error.
My probe has an acceptable overshoot of around 1.4 mm. With that I can run my mill up to 800 mm/min and it would still stop in time. I would prefer an overall slower probing routine with a safer setup and would happily sacrifice each G0 command during probing.
Since Terje Io did already an awesome job, I'm hoping that this won't be too much work to implement.
A constant check during G0/G91 commands
This is exactly what my plans are - I should get around to implement it. It will be implemented in grblHAL drivers by enabling interrupt handling for the probe input. The grblHAL core already has support. There is core support for a probe connected input as well, I should write a plugin for that now that most drivers supports aux inputs that can be acessed by plugin code.
BTW there is already a simple probe protection scheme in place that has to be enabled, this stops motion if a probe triggered report is received. The downside to this is that the response time is worst case up to the polling rate - default is 200ms. It is enabled by checking "Run substatus" for the Status report options setting ($10).
Nothing in the hobby segment beats an internal interrupt, but a secondary fail-safe won't hurt for sure.
I would be happily willing to test the probe interrupt out, when implemented.
I would be happily willing to test the probe interrupt out, when implemented.
Ok, which driver/board combo are you using?
I'm using a iMXRT1062 with the T41U5XBB connected via ethernet, would also test the usb too.