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

[J-Dunn]

Thanks but that should not stop serial comms. $$ $# etc should still work. This is looking a bit borked. Do you have a f411re board to test on ?

[Northernboy]

I could do testing on mine tomorrow night. If you like email me your flash and I could test it.

[J-Dunn]

Thanks, I was initially wondering if you can run a vanilla git clone of this project. When did you last pull a working copy ?

[J-Dunn]

Thanks for the files. Essentially the same results.

I've rather hijacked your probe thread. We'll get back to your probe tweaks once I've fixed what is going on.

I've opened another issue about this problem if you'd like to join us there.
#66

[Schildkroet]

It seems this is rather an issue with some external hardware/software.

[J-Dunn]

Yes, I've been looking that direction. I've change hardware ports on the box ( two front panel, two back panel ) and several different cables. I only have USB not USB2.0 cables with OTG ends at 115kbaud and even "low speed" USB1.1 can handle 1.5 Mbit/s.

It also does not seem consistent with the st-link running perfectly flashing and verifying the data. If there was a port/cable problem that would be unlikely to work flawlessly and verify the flashed image.

BTW, what's the difference in .bin vs .hex, the latter seems to be just an ASSCI representation of hex data. Is it fine to send either ? Does st-flash take care of all that and send exactly the same thing down to the target?

[Schildkroet]

Just a different file format to choose from. The all contain the same grbl.

[J-Dunn]

OK, just checking, thanks.
So does the fact the flash is working flawlessly rule out an issue between the PC and F411 ?
If it's dumping circa 100kB of program why can't it transfer a few 100 bytes?

[Schildkroet]

At least your cable seems to be fine. But st-link and serial use different end points and driver. Can you try a differnet terminal like putty, tera term etc?

[J-Dunn]

So far I have been testing with arduino IDE as terminal and minicom . Essentially the same problems. In fact minicom tends to get even less back or even nothing.

[J-Dunn]

I'm wondering whether there is some other process run automatically which is parasiting on ttyACM0.
OK , I've tried this on two other PCs: the old Fedora connected to the CNC and the old PC running current Fedora version same as the problem system.

Both work fine.

It looks like this is related to the new hardware I migrated by system to . Both the front panel and the direct mobo mounted USB slots are not working properly. Sadly it's all PCI-express slots so I don't have any cards I can slot in for separte USB ports.

Buggy BIOS ?

[EDIT]
OK, this turned out to be a BIOS issue. I flipped a couple of USB options in the BIOS and it works correctly.

Seems a bit strange that the st-flash process went OK, that was a bit of a distraction in narrowing it down. One of the options was EHCI handoff, so maybe there were issues in negotiating between the different USB endpoints on the same cable.

Now to get back to sorting out probing ....

[J-Dunn]

I've never used z-probe till now, though I buffered the GPIO line with an opto and have it all the wiring in place.

Since I'm using STM STEP01 drivers , not the usual STEP/DIR pins this needs some debugging.

I still have some issues but initial test showed difference between Z coord on probe trigger and final position to be 0.05mm ( 2 thou ) on a one off test, ie "fag paper" accuracy, using F30 ( 0.5mm/s ). That was a single test, so may not be indicative.

Maybe NB could post something like the difference between PRB output Z and machine rest Z , with and without his mods.

My inclination would be to drive the machine back to the trigger point.

[Northernboy]

When I did my testing I was measuring the actual pulses out to the stepper driver and for it was reduced to what a normal Arduino GRBL would do. I never actually measured the difference. If you think you need it closer you could the ‘Seqment_Buffer_Size_Probe’ In config.h to less than 6.

[J-Dunn]

I now have my stm32 grbl (not this port) with basic grid array probing. So now I can start speed and repeatability testing.
I'm not seeing very good repeatability using F30 ( 0.5mm/s ) . I have a range out about 4 z-steps (1/80mm each) .

I'm going to test 38.4 after 38.2, since this is trip very early deceleration buffer will be very short. 38.4 could be with a very slow speed too since it hardly moves.

The execution path to stopping is pretty long and convoluted. I'm sure it could be trimmed but I think need for deceleration path is probably the critical part. You approach of setting a short planning buffer for probe may be a good solution.

For the record I currently use the following on my machine already ( unrelated to this issue ).
#define ACCELERATION_TICKS_PER_SECOND 100
#define SEGMENT_BUFFER_SIZE 6

Confirmed , using probe retraction seems to give more consistent results.

[J-Dunn]

Rather than hacking ACCEL TICKS etc. I think the basic problem here is lack of dymanic range in AMASS_LEVELs

I found that slow mm/min rates never happened because the time counter overflowed and GRBL correctly limits it to 0xffff .

I added a couple more amass levels and could then program low speed gcode F rates and they worked.

I now probe at F60 , then in my modified "G38.9" grid probe cycle, I do repeat pull-off probe cycles at f/5.0 and take the mean , these slow speeds now work.

On five repeats I have max +/-1 step variability. I'd prefer +1/-0 but that maybe attributable to machine flexibility.

#define MAX_AMASS_LEVEL 5
// AMASS_LEVEL0: Normal operation. No AMASS. No upper cutoff frequency. Starts at LEVEL1 cutoff frequency.
#define AMASS_LEVEL1 (F_CPU/8000) // Over-drives ISR (x2). Defined as F_CPU/(Cutoff frequency in Hz)
#define AMASS_LEVEL2 (F_CPU/4000) // Over-drives ISR (x4)
#define AMASS_LEVEL3 (F_CPU/2000) // Over-drives ISR (x8)
#define AMASS_LEVEL4 (F_CPU/1000) // Over-drives ISR (x16)
#define AMASS_LEVEL5 (F_CPU/500)  // Over-drives ISR (x32)

      if (cycles < AMASS_LEVEL1) { prep_segment->amass_level = 0; }
      else {
        if (cycles < AMASS_LEVEL2) { prep_segment->amass_level = 1; }
        else if (cycles < AMASS_LEVEL3) { prep_segment->amass_level = 2; }
        else if (cycles < AMASS_LEVEL4) { prep_segment->amass_level = 3; }
        else if (cycles < AMASS_LEVEL5) { prep_segment->amass_level = 4; }
        else { prep_segment->amass_level = 5; }    
        cycles >>= prep_segment->amass_level; 
        prep_segment->num_steps<<= prep_segment->amass_level;
      }

[J-Dunn]

G38.2 Z-5 F20

That is the one I have been testing.

Did you measure the pulse timings or travel time to check speed? Was it really going at 20mm/min ?
Maybe it was not decelerating because it was already at the longest counter interval. That's what I was seeing. Adding amass levels fixed it.

[pagabee]

I hade the same issue with another STM32 fork from robomechs. The probing was inaccurate.
I tried to optimize the ACCELERATION_TICKS_PER_SECOND and the SEGMENT_BUFFER_SIZE, but I was not really satisfied with the result.

After reading this topic I added AMASS_LEVEL4 and AMASS_LEVEL5 to the code. I think this solves the issue with the probing and the movements are better and smoother.

[J-Dunn]

I'm glad this solution was of use. I'll open an issue upstream, this should probably be in grbl 1.1