I am able to recreate that problem. Here is what I see. Some jog types work and some do not. Normal moves appear to work and then all jogs work after that.

Here is a typical probe sequence that works

G38.2 Z-40 F100 ; probe down 40 at speed 100

[PRB:-299.000,-1.000,-8.095:1] ; grbl response of successful probe

G10 L2 P0 Z-28.095 ; set Z offset in current coordinate system to the returned Z value – touch plate thickness (20)

Either of these commands below work and all subsequent jogs are OK

G0 Z20 ; move to the probe thickness
$J=G53 G21 Z-1 F200 ;jog to Z-1mm in machine coordinates at speed 200

This problem might take a while to track down, but I think it might be due to the machine left in a problematic mode. doing a normal move cleans things up.

If you want to discuss short term fixes via Slack, let me know and I’ll send an invite.

@vogtitec BTW: What sender are you using?

@bdring Thanks for the first solution attempts. I first encountered the behaviour with candle 1.1.7, but I was able to reproduce it by entering the probing command manually in the WebUI and then jogging via Web.
Yes, Slack will be welcome, thanks!

Ok, so there is a simple workaround for the problem! I changed the standard probe command in candle by adding a simple G91G0Z10, and now it works! Thanks a lot!

Great.

I added Candle to this wiki page.

I’m not near my machine so can’t check myself but is it possible to use a G91G1X0 command, which would not actually move anything, to “reset” things after the probing?

That does not work. It appears you need to have some movement

I think I found the problem. Thanks to the ESP Exception Decoder, I found the offending line of code.

The stepper interrupt was crashing while trying to compensate the spindle speed vs feed rate. This is a feature used by lasers and does not apply during jogging. I just placed a test for joging around the code.

I’ll release it soon to the devt branch. Then merge to master soon.