Probing Issue

[Northernboy]

I noticed that when probing the axis doesn’t stop right away after a touch has been detected. I measured it and it goes for approximately 500ms after probe has touched. I test an Arduino GRBL and it goes for approximately 100ms after probe has touched with the same feed rate. I also notice the Arduino is decelerating since steps are getting further apart, but the STM32 isn’t decelerating since pulse are staying the same. Also time is affected by feedrate will probing so I believe it is do to the deceleration calculation. I’ve been digging into it but haven’t found anything yet. If you need data I can provide.

Thanks for the awesome program I think we can make it better.
NB

[Schildkroet]

I didn't change the probing cycle, so there should be no difference. But i will look into it.
Can you send me your probing command?

[Northernboy]

G38.2 Z-5 F20

That is the one I have been testing.

[Schildkroet]

This seems to be a trade-off problem. You either have good high speed performance or good low speed performance.

Change https://github.com/Schildkroet/GRBL-Advanced/blob/software/grbl/Config.h#L312 to 512 (or similar) and
reduce https://github.com/Schildkroet/GRBL-Advanced/blob/software/grbl/Config.h#L440 to 16 (lower = less stopping time)
If you set the segment size to original (6), stopping time should be < 100ms. But you also have to lower acc ticks per second to ~100, otherwise there will be stops between moves (planner can't keep up with stepper)

[Northernboy]

I tested it and it does stop sooner when I reduce the segment size lower. I’m going to try some code to see if it possible to make it small just during probing.

Thx Again let you know how I make out.
NB

[Northernboy]

Modified the program for a shorter sequence during the probe only. Testing it now cutting some aluminum. Seems to be working well. Also have modified spindle communication to start, stop and change speed of VSD using RS485.

I’ll post my results after testing n debugging

[J-Dunn]

@Northernboy, did you get this working. It seems like a serious bug in original grbl.
I'm only just starting to look at z probe since I want to set up some kind of table levelling compensation.

If reduced speed stopping takes .1s that's a problem. Even at a conservative F speed that is a long way in terms of precision.

Does this just mean it is forcing the probe ( tooltip ) into the stock but not affecting the accuracy? What is the repetition accuracy on your testing?

Maybe OK if you are just touching off before doing a face milling op but if you are trying to pick up an existing surface as a reference it does not sound too good.

TBO until now I've been using the old fag-paper method . I may stick with that for z-probe ;)

[Northernboy]

Yes I modified the code for a shorter sequence will probing. Seemed to fix it. I was still working on fine tuning my VSD RS 485 controls but I don’t mind sharing the fix for the probing.

[J-Dunn]

Thanks that would be useful. Maybe a PR or just post some code snips if it's very few changes.

[Northernboy]

I’ll send my changes tonight.

[Northernboy]

@J-Dunn, give me your email address and I'll pass you the files that I changed and you can test it for yourself. If it works for you then I'll figure out how to share it with others.

[J-Dunn]

Thanks.

[Northernboy]

@J-Dunn, did you get the files? If so any testing results?

[J-Dunn]

Yes, thanks for code. I'm going to need a while to plough through the individual files of this port and work out what is connected where . Then I'll build a test rig with a classic Dir/Step driver and one motor. I'm hoping to look at that today.

BTW I did a probe test on my existing stm32 build and there was a 0.1mm difference between the z value when the probe triggered and the rest position of the machine ! About what I estimated previously. I would think the first thing to do was to back off that position before zeroing the machine. This must in fact be taken up by flexing in the mechanics. Once I get into this I'm going to add a double peck z-probe where it backs off something like 0.5mm and does a second peck 5 or ten times slower for accuracy. If all I get is 0.1mm accuracy I may as well stick with the fag-paper method !

[J-Dunn]

Hi, I just wanted to try testing this code so I set up a run one motor test , a F411RE Nucleo with X step/dir/enable wired to a NEMA23 via DM542 driver unit.

I built the code and the flash looked good:

2021-05-31T17:35:44 INFO flash_loader.c: Clear DFSR
2021-05-31T17:35:44 INFO common.c: enabling 32-bit flash writes
2021-05-31T17:35:45 INFO common.c: Starting verification of write complete
2021-05-31T17:35:45 INFO common.c: Flash written and verified! jolly good!

I opened Arduino IDE to act as a serial interface with /dev/ttyACM0

On connecting the USB to power up the F411RE , I get a couple of garbage characters, that's OK.

Then I press Enter to send a blank line to GRBL and get "ok" back. Looks good.

However, whatever else I type it seems to lock up. I don't get anything else back until I power cycle it. I sent $$ locked: $# locked: ? locked.

Now this is probably me being dumb since I have not worked on a stripped down rig like this for a long time, so can you tell me if I'm messing up. Thanks

[Northernboy]

Try unlocking command, $X