Incorrect behavior with espduino-32_wemos_d1_r32_uno

[OrsoLaser]

good morning
I have a board espduino-32_wemos_d1_r32_uno, in which I had installed an EspGrbl firmware. Everything was ok, everything worked...
I wanted to install your grblHal because I already use it on another laser with another type of board.
The first problem I encountered was that I had to change the pin map, because if I used the GPIO_NUM_02 // Coolant flood pin, the GPIO_NUM_18 // Spindle enable pin didn't work either!!!
I had to change the GPIO_NUM_02 // Coolant flood pin to GPIO_NUM_33// Coolant flood and everything works now!!!
But the worst thing is that when I press the stop button on lightburn everything freezes and you can't restart the work in any way!! You have to disconnect the board and reconnect it!
I attach two short videos, the first is the behavior I had with the espGrbl firmware (to show you that I don't think it's a problem related to the board).
The second video is related to the incorrect behavior, after installing grblhal!

[OrsoLaser]

Correct behavior with Espgrbl firmware...

EspGrbl.mp4

[OrsoLaser]

Incorrect behavior with grblHal firmware...

Registrazione.dello.schermo.2025-03-15.122356.mp4

[OrsoLaser]

Incorrect behavior with grblHal firmware...

Even pressing the stop button before starting the process creates a block and you need to disconnect the board to restart.... it does not accept any type of $ command!!!!!

Could you help me?
Thanks

Grblhal.mp4

[OrsoLaser]

This is my board....

[terjeio]

The first problem I encountered was that I had to change the pin map, because if I used the GPIO_NUM_02 // Coolant flood pin, the GPIO_NUM_18 // Spindle enable pin didn't work either!!!
I had to change the GPIO_NUM_02 // Coolant flood pin to GPIO_NUM_33// Coolant flood and everything works now!!!

These pin mappings does not match the ones in the map:

[PIN:4,Feed hold]
[PIN:35,Cycle start]
[PIN:2,Emergency stop]
[PIN:39,Probe]
[PIN:13,X limit min]
[PIN:5,Y limit min]
[PIN:23,Z limit min]
[PIN:26,X step]
[PIN:25,Y step]
[PIN:17,Z step]
[PIN:16,X dir]
[PIN:27,Y dir]
[PIN:14,Z dir]
[PIN:12,Steppers enable]
[PIN:18,Spindle on]
[PIN:19,Spindle PWM]
[PIN:32,Flood]
[PIN:34,RX,Primary UART]
[PIN:35,TX,Primary UART]

AFAIKT everything is working with the map provided, tested with a "standard" development board.

Even pressing the stop button before starting the process creates a block and you need to disconnect the board to restart.... it does not accept any type of $ command!!!!!

Are the control inputs (Feed hold, Cycle start and Emergency stop) left floating? If so you should ground them.
I do have a problem with the shitty CP210x USB <> UART chips, often used on the cheapo ESP32 boards, crashing causing loss of communication. A better USB cable and/or USB hub may help if you have such a problem?

[OrsoLaser]

s

Queste mappature dei pin non corrispondono a quelle nella mappa:

[PIN:4,Feed hold]
[PIN:35,Cycle start]
[PIN:2,Emergency stop]
[PIN:39,Probe]
[PIN:13,X limit min]
[PIN:5,Y limit min]
[PIN:23,Z limit min]
[PIN:26,X step]
[PIN:25,Y step]
[PIN:17,Z step]
[PIN:16,X dir]
[PIN:27,Y dir]
[PIN:14,Z dir]
[PIN:12,Steppers enable]
[PIN:18,Spindle on]
[PIN:19,Spindle PWM]
[PIN:32,Flood]
[PIN:34,RX,Primary UART]
[PIN:35,TX,Primary UART]

Per quanto ne so, tutto funziona con la mappa fornita, testata con una scheda di sviluppo "standard".

I have a CNC SHIELD V3 on the ABMI board and to respect the original mapping of the shield v3, the pin map provided in the firmware does not fully correspond to the reality of my ESP32.....
But this is not a big problem! I solved it by using the GPIO33 pin for the Coolant flood and as I said everything works!!

[OrsoLaser]

Are the control inputs (Feed hold, Cycle start and Emergency stop) left floating?

I didn't map these pins!? Could this be the problem?

I do have a problem with the shitty CP210x USB <> UART chips, often used on the cheapo ESP32 boards, crashing causing loss of communication. A better USB cable and/or USB hub may help if you have such a problem?

I don't think it's a problem related to the USB cable...Because I was using it with the esp32 firmware and I never had any problems with communication!!

[OrsoLaser]

Are the control inputs (Feed hold, Cycle start and Emergency stop) left floating? If so you should ground them.

I tried mapping the Feed hold, Cycle start and Emergency stop pins and grounding them!!
But nothing changed! Even with everything stopped, when I press the stop button everything freezes!!
Everything else works! The motors run regularly, inputs and outputs, work!
I don't understand why it locks up when I press the stop button!!

[terjeio]

Can you try with ioSender? <Reset> is the same as <Stop> in LightBurn.
I was not able to cause a freeze with either sender. If you enable verbose logging in the ioSender console you may get clues for why it freezes.

[OrsoLaser]

Setting the parameter $14=64, It doesn't stop everything if I press the stop button....
But it has a strange behavior, pressing stop the work doesn't stop immediately, it continues to work for a few seconds and then stops the processing!

Registrazione.dello.schermo.2025-03-15.182157.mp4

[OrsoLaser]

Puoi provare con ioSender ? <Reset>è lo stesso <Stop>di LightBurn.

I haven't installed it, I'll install it now and let you know!

[OrsoLaser]

Hi
I tried with ioSender... it crashes with that too!
It doesn't output anything to the console!
Here too, to unlock I have to disconnect the board!
I wanted to ask you a question...
With the Grbl_Esp32 firmware this does not happen.....everything works!!
I'll start by saying that I'm not an expert in these things...
I took a look while compiling grblhal with VsCode and as a board Platformio chooses "esp32doit-devkit-v1"....Could it not be compatible with my board?
Or does it have nothing to do with it?

[OrsoLaser]

Good morning
I found out what creates the problem!!!
I added the plugins one by one inside the my_machine.h file...
#define LB_CLUSTERS_ENABLE
#define EVENTOUT_ENABLE
So far so good!

When I add the #define FEED_OVERRIDE_ENABLE
The problem occurs again!!!!!
Is it possible that by adding this plugin without the dedicated pin outs being configured in the pin map, everything will conflict!??

[OrsoLaser]

After a morning compiling firmware I still managed to find out what was causing the anomaly!!
I hope everything is fine now, I will continue to do the bench tests and then I will install the board on my laser again!
Sorry if I wasted your time....
Thanks for your support!!