Z drives down after executing first line of SD job when it is a G38.2 probe - crash?

[jelsdon]

What version of the firmware are you using?

[VER:1.3a.20210306:] [OPT:PHSW]

Is the problem repeatable?

Yes - albeit sporadic

Under what conditions does the bug occur?

Running job off ESP/SD - immediately after the first line of stored gcode has completed execution, the Z axis starts dropping slowly (~0.5mm/s) - will stop dropping when any of the X/Y/Z limit switches are triggered (probe has no affect). At this point the ESP32 appears to reset.

It only happens after the first line has executed and before the second; this is consistent.

• it has not displayed this in a job if it gets as far as executing the the second line
• it has not displayed this before the first line is executed in the job.

Most of the time this is noticeable when I am running the following macro/stored job, as soon as the probe touches.

G91 G38.2 Z-20 F200
G91 G1 Z4.000 F400
G4 P0.25
G91 G38.2 Z-5.0 F40
G4 P0.25
G10 L20 P0 Z17.46
G4 P0.25
G90 G54 G0 Z20 F400

Last line of output is the SD/RUN [ESP220]/macros/zprobe.nc

I have not had this occur if sending commands in via terminal/telnet, only via stored (ESP and SD).

It behaves normally if I add movement before the G38.2 probe (such as below) ; this is my work around for now (might change to a dwell)

G91 G1 X5 F400
G91 G1 X-5 F400
G91 G38.2 Z-20 F200;
G91 G1 Z4.000 F400;
G4 P0.25;
G91 G38.2 Z-5.0 F40;
G4 P0.25;
G10 L20 P0 Z17.46;
G4 P0.25;
G90 G54 G0 Z20 F400

I notice there's a comment in Grbl_Esp32/Grbl_Esp32/src/WebUI/WebSettings.cpp about the first line executing outside of protocol.cpp, could be a condition that makes it go awol when in a probe state

741 SD_auth_level = auth_level; 742 // execute the first line now; Protocol.cpp handles later ones when SD_ready_next 743 report_status_message(execute_line(fileLine, SD_client, SD_auth_level), SD_client); 744 report_realtime_status(SD_client); 745 webPrintln(""); 746 return Error::Ok;

Note: This post has been edited a few times to better detail the behavior as information becomes available. Machine config https://github.com/jelsdon/grbl-cncsys-config/commit/f10afe0e1a10f2f056329fd012e9545772decf5e

[bdring]

I'll look at this when I get a chance.

What are you trying to do? Is this a macro to set work 0 using a probe?

[bdring]

I can repeat the problem. It appears to only occur if it is done before any motion.

What hardware are you running on?

[jelsdon]

Hi @bdring - I'm running Grbl_Esp32 on an ESP32-DevKitC-32UE

What are you trying to do? Is this a macro to set work 0 using a probe?

Yep, the macro is to set work 0 (on Z) using a probe

I can repeat the problem.

Good news! I hope no touch plates / end mills were harmed in the process

[bdring]

I was asking about the controller hardware, not the ESP32. I want to know what step generation method is being used?

[jelsdon]

For each of X Y Y' Z I have

• DM524 Stepper driver
• 3A Nema23 425oz Stepper motor

Limit switches (normally closed) for homing terminate onto relays which trigger the esp32 (GPIO_NUM 15,16,17). Probe is also connected to a relay which when triggered disconnects PROBE_PIN (GPIO_NUM_4) from ground. DEFAULT_INVERT_PROBE_PIN is set to 1.

(Full grbl_esp32 config can be found https://github.com/jelsdon/grbl-cncsys-config/commit/f10afe0e1a10f2f056329fd012e9545772decf5e )

[readeral]

@bdring I've run into this problem today using the macro feature running a .g file from SPIFFS. Exactly the same issue, G91 G38.2 Z-25 F100 doesn't progress to the next gcode line (which is to save but rather locks the ESP3D interface up and the Z slowly lowers until an endstop is switched. The full file contains these lines:

G21 G91
G38.2 Z-25 F100
G10 L20 P0 Z5
G0 Z3

Running each line manually through the Send Command window results in the correct outcome.

To answer the same question @jelsdon answered, I'm running DM556 Stepper drivers, 4A Nema23 425oz stepper motors. My controller is https://github.com/RootCNC/ESP32-GRBL-Root-Controller by @RootCNC

Has there been a fix for this found?

I have had other issues today after running G38.2 for all 3 axis manually, which may or may not be connected. I'll raise another issue for that.

[dfict]

did anyone find a fix for this issue? even if it's a workaround? i have a legacy system running esp32 that i added a touchplate to, this is the same crash behavior i'm having. just trying to make a macro that works. manual entry works, macro running makes the same intermittent crash.

[MitchBradley]

As far as I know nobody has done any updates to Grbl_Esp32 for a long time. All of the development and maintenance effort is on FluidNC. FluidNC has a lot of stability improvements in addition to many new features.