Z Stop in PROBE for PCB Milling

[Lopezno68]

Hello, I am using the wonderful GRBLHAL software with the MKS SBASE(LPC1768) board and I have a problem with the PROBE functionality. My intention is to use this function to accurately measure the height of the tool to be able to make PCBs with my homemade CNC. The problem is that when the tool touches the PCB, it does not stop at that moment, but continues to advance for another 110ms, penetrating the tip of the engraving bit into the copper of the PCB, damaging it. Attached photos of the problem and configuration

I see 2 effects: 1.- The detection of the PROBE signal is not immediate and the Z motor does not stop instantly. 2.- In addition, the deceleration of the Z axis causes another additional delay

In my setup, the acceleration on the z axis is $122=33 If I directly execute the command $G38.3F100Z-10, the result is the same.

I have analyzed this problem with an oscilloscope: The logic of the probe signal is: 3.3V->No touch 0V->Touch

However, if I analyze the Homming in the Z axis, the Z motor stops exactly at the moment that the Zmin Limit is touched: The logic of the Zmin signal is: 3.3V->Touch 0V->No touch

Is there any configuration that allows the Z axis to be stopped at the same moment that the PROBE signal is activated, as it happens in Z homming? is it a software bug? For the second effect, and taking into account that when the PROBE function is used, the speed of the Z axis is quite small, the deceleration of the Z axis could be dispensed with at that moment, so that the engraving bit would not continue advancing. This could also be solved as follows:

$122=999999 ; infinite acceleration $G38.3F100Z-10 $122=33 ; normal acceleration

However, my main problem is that the Z axis stops after some time after detecting the Probe signal.

any ideas?

[terjeio]

any ideas?

Yes, do not use a tool as a probe. Or, if possible, increase acceleration until the overshoot becomes acceptable.

is it a software bug?

No.

Is there any configuration that allows the Z axis to be stopped at the same moment that the PROBE signal is activated, as it happens in Z homming?

No, because no physical system can stop instantly. For homing it is not an issue as the position is reset anyway. When probing the real position becomes unknown if suddenly no more stepper pulses are sent.

[Lopezno68]

Thanks for your quick response. Yes, I understand, it is not correct to use the tool as a PROBE sensor, but to make PCB boards it is what is most used. I can change the acceleration but this would only solve the second of the problems as I mentioned before. In the oscilloscope it is observed that the delay of approximately 110 ms is composed of 2 parts:

• The first part of about 90ms constant speed without deceleration
• The second part of about 20ms of deceleration

...and believe me, zooming in on the oscilloscope clearly shows the part with constant speed and the part with deceleration.

Increasing the deceleration quite a bit could solve the second 20ms delay but not the previous 90ms which I don't know where they come from. I have already tried increasing the acceleration with: $122=999999 ; infinite acceleration $G38.3F100Z-10 $122=33 ; normal acceleration ... and it works correctly at low speeds (solves the 20ms problem), but the other 90ms I don't know how to reduce.

About suddenly stopping the Z motor, if the speed is small enough, the motor does not lose steps. This obviously depends on the machine and again if the speed is small enough that the inertia is low. What can the 90ms be due to?

[langwadt]

I never really looked into how it really works, does the stepper interrupt finish the current block (which is constant speed because it is just a simple linear move) before it starts the deceleration blocks ?

[Lopezno68]

Sorry for my English but I can't quite understand the question. I understand that the stepper interrupt doesn't work properly and ends the block 90ms later than it should. For further clarification I am sending you a diagram of the ideal scenario and the one I check with the oscilloscope. A 90 ms delay appears until deceleration begins.

I will do more tests with different speeds to have more data.

[Lopezno68]

I've done another 2 tests at lower Z axis speed to make it look clearer: In the first one, the speed of the Z axis is 20 mm/min and it has an acceleration of 20 mm/s^2

In the second, the speed of the Z axis is also 20mm/min but the acceleration is very high, 999999mm/s^2

Here you can clearly see the effect of the deceleration, which is correct, but in both tests the approximately 90ms still appear in which the Z motor continues at constant speed instead of starting the deceleration. I think this behavior is wrong.

[terjeio]

@Lopezno68 Are you using the version from this repo or the latest from the new?

I never really looked into how it really works, does the stepper interrupt finish the current block (which is constant speed because it is just a simple linear move) before it starts the deceleration blocks ?

I have to look into this again... My best guess is that at least the current segment has to be finished which will be max 5 ms. The current block can be changed, but how long does it take for EXEC_MOTION_CANCEL to reach st_prep_buffer()?

If the segment buffer has to be cleared first then that holds 40-50 ms of steps. Maybe the segment buffer size should be reduced during probing? Code is here.

[phil-barrett]

RC filter on the probe input? Could be source of delay.

The right way to set up for pcb milling is to use a 3d probe, create a height map and apply to the gcode. I would then set z height via the paper test as that gives you very fine control.

[Lopezno68]

@terjeio: The LPC176X version is downloaded from https://github.com/grblHAL/LPC176x date: 21/12/21 the core version is downloaded from https://github.com/grblHAL/core date: 21/12/21

@phil-barrett : The Probe signal showed in the oscilloscope image is in the microcontroller pin directly after the RC filter. The edge of the RC filter is very fast as you can see in the photo. The filter RC affect principaly in the rising edge of the PROBE signal but in the falling edge don`t affect almost. Thanks for the suggestion. About the height map, of course, you're right, but every point is measured with the same command (G38.3) which is the one that does not work well for me. ¿I'm wrong?

[phil-barrett]

I use the height map probing of ioSender. Not sure what it uses under the covers.

[Lopezno68]

Confirmed, the height map uses gcode G38.3. It can be seen in the Console in verbose mode

[terjeio]

Try with this modified stepper.c:

stepper.zip

When probe is triggered the segment buffer is "flushed" and new segments are blocked from entering until decelerating starts. Hopefully the change does not have any side-effects...

[Lopezno68]

Congratulations, good job. I have been testing the new driver and it works. So far I haven't found any side effects. The 90ms time until the deceleration starts has been reduced from 90ms to a maximum of 2ms (it is variable between 0ms and 2ms, why?) With this modification, the effect of damaging the PCB's copper when Probing is performed no longer appears. Can you please include this modification in new releases? It could be configurable and by default the modification was not active.

Lastly, and if possible, I would like that in a new version of the IOSender program, in the "Probing" tab, a parameter would appear that would be the acceleration of the Z axis for the movements "Search feed Rate" and "Latch feed rate" . By default, the value should be the default Z axis acceleration value. This new acceleration should only be applied just before each G38.3 command and be restored by the default acceleration once the G38.3 command is finished. Example:

$122=500 ; change to a high acceleration Z (new parameter) G38.3F100Z-10 ; low speed testing $122=33 ; the default acceleration in the Z axis is recovered

What do you think? I assure you that for people who make PCBs with a CNC with GRBL it would be a good improvement since the deceleration effect also affects the damage of the PCB at the time of PROBING. This new Z acceleration value should be set by each user depending on the "Search feed Rate" speed and the inertia of their CNC in the Z axis. Obviously, and for safety reasons, this new parameter should be the generic Z axis acceleration by default. . I have done quite a few tests with this issue. If the speed at the time of the Z axis Probing is low (it is the most usual), for example 100mm/min, the Z axis can be stopped suddenly (very high acceleration) without losing steps.

Thanks Terjeio.

[terjeio]

it is variable between 0ms and 2ms, why?

Because the current segment cannot be terminated - it has run to completion. And if there is a few steps remaining I think I should let the next segment complete too or there will be a risk that motion just stops. The roundtrip from the probe contact beeing detected to the deceleration segment beeing added is normally less than 20 microseconds on the STM32F756 I am testing with, but can be significantly longer since the cancel motion message is handled by the foreground process. This worries me a little - and I will add what I believe are conservative checks for when to leave the next segment in place.

It could be configurable and by default the modification was not active.

I think I will add the change and not make it configurable. I'll have to run a few more tests before I decide.

Lastly, and if possible, I would like that in a new version of the IOSender program, in the "Probing" tab, a parameter would appear that would be the acceleration of the Z axis for the movements "Search feed Rate" and "Latch feed rate" . By default, the value should be the default Z axis acceleration value.

I do not think this is a good idea - remember probing is not only for the Z-axis, and legacy Grbl does not support changing acceleration on the fly without altering setting values... IMO a better idea will be to add a plugin to grblHAL for this.

[Lopezno68]

I agree Terjeio, I will be waiting for the modifications that you introduce. If you need me to perform any tests, tell me.

All the best.

[terjeio]

I have commited an update where the change has to be enabled in stepper.c by uncommenting this line.