MKS-DLC32 V2.1 rebooting when I home from a longer distance

Board randomly reboots with no clear cause; usually when it is manually rehoming after a print. That is pretty consistent. Sometimes it will happen at the beginning of a g-code run about 20-30seconds in. I noticed that there is a red LED lit when the board is parsing a g-code file. It is steady when the laser is firing. Off for all other moves. It can run a g-code file for up to 40mins with no issue completing a run; than for what appears to be no apparent reason, it will black out on a faster move during a home move $h.

Spec:
MKS-DLC32 v2.1
Firmware v2.30(8m.h35.20231206)
Monitor control connected
3 24 volt remote stepper drivers - DM556 running at 1.4A, 64 steps.
3 Nema 17 bi polar stepper motors.
1 z-axis stepper motor.
1 control wire running to I2C pin 4 for compressor relay.
18.5 amp 24 volt power supply with direct connection to MKS board.
24 volt laser directly connected to power supply. Single control wire to MKS.
RaspberryPi4 with 8gig ram and 32gig sd card running octoprint. (I see the same issue with CNCjs)
USB connection.
PI has its own dedicated power supply.
All other items run from the primary power source.

In testing setup the laser is not plugged in. So I have ruled that out completely as it is reproducing the issue without it plugged in.

The MKS appears to draw around .9 amps ±.25 while running g-code.

Config is:

Send: $$
Recv: $0=8
Recv: $1=120
Recv: $2=0
Recv: $3=2
Recv: $4=0
Recv: $5=1
Recv: $6=0
Recv: $10=1
Recv: $11=0.009
Recv: $12=0.002
Recv: $13=0
Recv: $20=1
Recv: $21=1
Recv: $22=1
Recv: $23=3
Recv: $24=50.000
Recv: $25=2000.000
Recv: $26=300.000
Recv: $27=2.500
Recv: $28=1000.000
Recv: $30=900.000
Recv: $31=1.000
Recv: $32=1
Recv: $49=0
Recv: $50=1
Recv: $38=0
Recv: $40=1
Recv: $43=0
Recv: $100=320.500
Recv: $101=320.500
Recv: $102=12400.000
Recv: $103=100.000
Recv: $104=100.000
Recv: $105=100.000
Recv: $110=3500.000
Recv: $111=3500.000
Recv: $112=250.000
Recv: $113=1000.000
Recv: $114=1000.000
Recv: $115=1000.000
Recv: $120=100.000
Recv: $121=100.000
Recv: $122=100.000
Recv: $123=200.000
Recv: $124=200.000
Recv: $125=200.000
Recv: $130=1520.000
Recv: $131=1450.000
Recv: $132=39.000
Recv: $133=300.000
Recv: $134=300.000
Recv: $135=300.000

Error:
Send: $J=G91 G21 X1200.000000 Y1200.000000 F3500.0

Recv: ok

Send: ?

Recv: <Jog|MPos:50.053,50.056,0.000|FS:3500,0|Pn:P>

Recv: ok

Send: ?

Recv: <Jog|MPos:256.100,256.100,0.000|FS:3500,0|Pn:P>

Recv: ok

Send: ?

Recv: <Jog|MPos:462.200,462.203,0.000|FS:3500,0|Pn:P>

Recv: ok

Send: ?

Recv: <Jog|MPos:668.218,668.218,0.000|FS:3500,0|Pn:P>

Recv: ok

Send: ?

Recv: <Jog|MPos:874.259,874.259,0.000|FS:3500,0|Pn:P>

Recv: ok

Send: ?

Recv: <Jog|MPos:1080.387,1080.387,0.000|FS:3500,0|Pn:P>

Recv: ok

Send: ?

Recv: <Idle|MPos:1200.000,1200.000,0.000|FS:0,0|Pn:P>

Recv: ok

Send: $H

Recv:

Recv: Stack smashing protect failure!

Recv:

Recv: abort() was called at PC 0x40182217 on core 1

Recv:

Recv: ELF file SHA256: 0000000000000000

Recv:

Recv: Backtrace: 0x4008af5c:0x3ffd52f0 0x4008b1d9:0x3ffd5310 0x40182217:0x3ffd5330 0x400ef80d:0x3ffd5350 0x400ef817:0x3ffd5380 0x400f90aa:0x3ffd53a0 0x400f9159:0x3ffd53c0 0x40082635:0x3ffd53e0 0x4008ce8a:0x3ffd5410

Recv:

Recv: Rebooting…

Recv: ets Jun 8 2016 00:22:57

Recv:

Recv: rst:0xc (SW_CPU_RESET),boot:0x1b (SPI_FAST_FLASH_BOOT)

Recv: configsip: 0, SPIWP:0xee

Recv: clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00

Recv: mode:DIO, clock div:1

Recv: load:0x3fff0018,len:4

Recv: load:0x3fff001c,len:1216

Recv: ho 0 tail 12 room 4

Recv: load:0x40078000,len:10944

Recv: load:0x40080400,len:6388

Recv: entry 0x400806b4

Recv:

Recv: E (61) efuse: Range of data does not match the coding scheme

Recv: [MSG:Using machine:MKS DLC32]

Recv:

Recv: Grbl 1.1h [‘$’ for help]

Recv: [MSG:‘$H’|‘$X’ to unlock]

Recv: [MSG:Caution: Unlocked]

It looks like the firmware they ship is a copy (not even the common decency of a fork) of a copy of grbl_esp32 that’s at least two years old since they last touched it:

I haven’t checked whether either grbl_esp32 or grblhal has had MKS-DLC32 support added. In either case, I’d expect it to need to be built from source rather than having it ready to just install.

I also have no idea whether it would address the problem you have seen. It does look like a firmware bug, though. Just not obvious to me what configuration might be triggering it. But it’s not crazy to think that if someone else has seen it in grbl_esp32 it might have been fixed since; it’s actively maintained. But it wouldn’t be reasonable to ask them to support a build created by MKS, that’s MKS’s job. :slightly_smiling_face:

Thank you for your comment. Not impressed with the board or the support.

FluidNC, the successor to Grbl_esp32, does support this board. That’s where I’d start.

Additionally, grblHAL also supports this board as BOARD_MKS_DLC32_V2P0:

You can apparently do web builds though I have no experience with this.

1 Like