search

bdring / FluidNC

The next generation of motion control firmware
Other
1.59k stars 383 forks source link

Problem: Interruptions in motion during Jogging #678

Open ModuloFS opened 2 years ago

ModuloFS commented 2 years ago

Controller Board

selfmade CNC-Controller_V2.pdf

Help From Board Vendor

Machine Description

Gantry router Ratrig Killerbee with DM556T stepper driver, dual y motors and limit switches.

Input Circuits

No response

Configuration file

name: "ModuloController"
board: "ModuloControl V1"

stepping:
  engine: RMT
  idle_ms: 255
  dir_delay_us: 5
  pulse_us: 5
  disable_delay_us: 5

start:
  must_home: true
  deactivate_parking: true
  check_limits: true

axes:
  shared_stepper_disable_pin: gpio.23

  x:
    steps_per_mm: 400.000
    max_rate_mm_per_min: 5000.000
    acceleration_mm_per_sec2: 150.000
    max_travel_mm: 510.000
    soft_limits: true

    homing:
      cycle: 2
      mpos_mm: 510.000
      feed_mm_per_min: 200.000
      seek_mm_per_min: 400.000
      positive_direction: true

    motor0:
      limit_pos_pin: gpio.35:low
      hard_limits: true
      pulloff_mm: 5.000
      standard_stepper:
        direction_pin: gpio.27
        step_pin: gpio.26

  y:
    steps_per_mm: 400.000
    max_rate_mm_per_min: 5000.000
    acceleration_mm_per_sec2: 150.000
    max_travel_mm: 750.000
    soft_limits: true

    homing:
      cycle: 3
      mpos_mm: 750.000
      feed_mm_per_min: 100.000
      seek_mm_per_min: 400.000
      positive_direction: true

    motor0:
      limit_pos_pin: gpio.34:low
      hard_limits: true
      pulloff_mm: 2.000
      standard_stepper:
        direction_pin: gpio.18:low
        step_pin: gpio.19

    motor1:
      limit_pos_pin: gpio.36:low
      hard_limits: true
      pulloff_mm: 2.000
      standard_stepper:
        direction_pin: gpio.22:low
        step_pin: gpio.21

  z:
    steps_per_mm: 400.000
    max_rate_mm_per_min: 5000.000
    acceleration_mm_per_sec2: 150.000
    max_travel_mm: 150.000
    soft_limits: true

    homing:
      cycle: 1
      mpos_mm: 150.000
      feed_mm_per_min: 100.000
      seek_mm_per_min: 400.000
      positive_direction: true

    motor0:
      limit_pos_pin: gpio.39:low
      hard_limits: true
      pulloff_mm: 5.000
      standard_stepper:
        direction_pin: gpio.32
        step_pin: gpio.25

probe:
  pin: gpio.4:high

control:
  safety_door_pin: gpio.33:low
  reset_pin: NO_PIN
  feed_hold_pin: NO_PIN

10V:
  forward_pin: gpio.5
  reverse_pin: NO_PIN
  pwm_hz: 5000
  output_pin: gpio.13
  enable_pin: NO_PIN
  direction_pin: NO_PIN
  disable_with_s0: false
  s0_with_disable: true
  spinup_ms: 1000
  spindown_ms: 1000
  tool_num: 0
  speed_map: 0=10.000% 3000=10.000% 24000=90.000%
  off_on_alarm: false

Startup Messages

$SS
[MSG:INFO: FluidNC v3.6.4-pre1]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.1-1-gb8050b365e]
[MSG:INFO: Local filesystem type is spiffs]
[MSG:INFO: Configuration file:config_ratrig_killerbee.yaml]
[MSG:DBG: Running after-parse tasks]
[MSG:DBG: Checking configuration]
[MSG:INFO: Machine ModuloController]
[MSG:INFO: Board ModuloControl V1]
[MSG:INFO: SPI not defined]
[MSG:INFO: No SD Card CS Pin]
[MSG:INFO: See http://wiki.fluidnc.com/en/config/sd_card#sdfallbackcs-access-sd-without-a-config-file]
[MSG:INFO: Stepping:RMT Pulse:5us Dsbl Delay:5us Dir Delay:5us Idle Delay:255ms]
[MSG:INFO: Axis count 3]
[MSG:INFO: Shared stepper disable gpio.23]
[MSG:INFO: Axis X (0.000,510.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:gpio.26 Dir:gpio.27 Disable:NO_PIN]
[MSG:INFO:  X Pos Limit gpio.35:low]
[MSG:DBG:  X Pos Limit 0]
[MSG:INFO: Axis Y (0.000,750.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:gpio.19 Dir:gpio.18:low Disable:NO_PIN]
[MSG:INFO:  Y Pos Limit gpio.34:low]
[MSG:DBG:  Y Pos Limit 0]
[MSG:INFO:   Motor1]
[MSG:INFO:     standard_stepper Step:gpio.21 Dir:gpio.22:low Disable:NO_PIN]
[MSG:INFO:  Y2 Pos Limit gpio.36:low]
[MSG:DBG:  Y2 Pos Limit 0]
[MSG:INFO: Axis Z (0.000,150.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:gpio.25 Dir:gpio.32 Disable:NO_PIN]
[MSG:INFO:  Z Pos Limit gpio.39:low]
[MSG:DBG:  Z Pos Limit 0]
[MSG:INFO: safety_door_pin gpio.33:low]
[MSG:INFO: Kinematic system: Cartesian]
[MSG:INFO: 10V Spindle Ena:NO_PIN Out:gpio.13 Dir:NO_PIN Fwd:gpio.5 Rev:NO_PIN Freq:5000Hz Period:8191]
[MSG:INFO: Using spindle 10V]
[MSG:INFO: Probe Pin: gpio.4]
[MSG:INFO: Connecting to STA SSID:MW8s3mb43P5jtbZKJyom]
[MSG:INFO: Connecting.]
[MSG:INFO: Connected - IP is 192.168.178.93]
[MSG:INFO: WiFi on]
[MSG:INFO: Start mDNS with hostname:http://fluidnc.local/]
[MSG:INFO: SSDP Started]
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]
ok

User Interface Software

gSender, webUI

What happened?

If the controller is connectet to the gcode sender gSender 1.1.4 (https://github.com/Sienci-Labs/gsender) and i use a jogging function, the machine does start with the jogging motion but has some very hard interruptions in the motion. The interruptions are more frequently with higher speeds. I recognize interruptions from a speed of aprox. 3000 mm/min. It looses stepps during this interruptions because the home position at the limit switche is not the same after the interruptions. The interruptions during jogging occour if i use gSender as command source as well as with the webUI if i the controller is only connected with gSender at the same time. If i disconnect gSender and do the jogging either with the webUI or with fluidTerm everything works perfectly. I discoverd this behaviour since the FluidNC version 3.6.3 respectively 3.6.4-pre1. With FluidNC 3.5.1 I could not detect this behavior.

Does anyone use gSender as Gcode sender and has similar issues?

Other Information

No response

MitchBradley commented 2 years ago

Where are you establishing the speed of more or less than 3000 ? Is that in gSender's jogging presets, or in your FluidNC config?

ModuloFS commented 2 years ago

In gSenders jogging presets. The maximum speed in the FluidNC config is 5000 mm/min. Whats the root cause of your question? These interruptions happens, even if i send the jogging command with the webUI and gSender is only connected to FluidNC at the same time. If i disconnect gSender i can jog till 5000 mm/min without any interruptions.

MitchBradley commented 2 years ago

What is the host machine that is running gSender? I tried it on Windows and could not get it to connect to FluidNC until I made a change in the way gSender sets up the serial port. Prior to that change, gSender would cause the ESP32 to come up in bootloader mode.

ModuloFS commented 2 years ago

The host machine is Windows 11 or Ubuntu 22.10 at booth i have the same probelm. If i connect, it does not matter if the host is Windows or Linux, i do the following:

  1. Start gSender
  2. connect to the serial port of FluidNC in gSender
  3. Press Shift + 5 on the keyboard, This causes gSender to send a Ctrl+X command and reset FluidNC.
  4. The reset command causes FluidNC and gSender to synchronize and then you are able to use gSender togehter with FluidNC
ModuloFS commented 2 years ago

Just tried movements with G0 and G1 commands with gSender, there are the same interruptions in movement. So this problem is not direct related only to jogging but to basically all movements. If i first connect to FluidNC with FluidTerm (i have not to send a single command, just oben FluidTerm) and then close FluidTerm, open gSender, connect to FluidNC an do a Reset (Shift + 5) to sync gSender with FluidNC i see in the console of gSender aprox. every second the character "$G". Seems FluidNC is sending this the whole time. Maybe this Information is helpfull for you.

I shortly tried to move the machine with candle 1.1.7 too and i get the same behaviour with the interruptions during an movement.

MitchBradley commented 2 years ago

FluidNC is not sending $G - gSender is sending it. FluidNC responds to what gSender sends. Here is the line in the gSender source that does it https://github.com/Sienci-Labs/gsender/blob/fb6db1509fc8a01be6135f81eb36d450e3e3d5eb/src/server/controllers/Grbl/GrblController.js#L822

The enclosing function is called on a 250 ms timer, so you would think that $G would be issued 4 times per second, but if you dig down into queryParserState(), you see that it is throttled to execute no more frequently than every 500 ms. Furthermore, there is additional time-dependent code therein that does something different every 10 seconds, and a lockout that prevents execution when a GCode program is being streamed to the controller.

gSender is a fork of CNCjs and this part of the CNCjs code has barely changed since the fork. From my days as a CNCjs developer and maintainer, I recall some problems in this area. On the one hand, CNCjs wants to know the state of the GCode modals like G20/G21 and others that $G returns, so that it can properly displays things like units, work coordinate systems, etc. On the other hand, GRBL does not automatically report changes to them, so the sender has to ask. If it asks frequently, so as to maintain a display that does not lag behind state changes, it risks glitching fast operations. So there is a tradeoff.

It seems that you have found the boundary where the tradeoff starts causing trouble in your system.

ModuloFS commented 2 years ago

Is this explaining the motion interruptions? And why i have the same issue with the Candle gcode sender? It seems i am not the only one with this problem. How should i proceed now?

bdring commented 2 years ago

Do you get any interruptions when sending jogs or gcode motion commands from FluidTerm.

This will help debug the problem. I cannot run Candle or gSender on my machine. Candle won't start and gSender does not communicate. I think we know the problem with gSender.

ModuloFS commented 2 years ago

No with FluidTerm everything works perfectly. It makes me wonder because with version 3.5.1. i had no such issue.

MitchBradley commented 2 years ago

I have been trying to duplicate the problem but so far I have not succeeded. On a 6-pack, I can jog at 4000 mm/sec and 400 steps/mm using gSender with no interruptions. I will now try to duplicate your hardware more closely. All of this takes a lot of time.

ModuloFS commented 2 years ago

Thats strange. I do not think it is related to the hardware, because with FluidNC it works at my hardware without any problems. Only if i use gSender or Candle i get the interruptions. (up to now i have not tried other gcode senders)

ModuloFS commented 2 years ago

But the 6-pack is using I2S not RMT right?

MitchBradley commented 2 years ago

Yes the 6 pack is I2S. So now I have to find an RMT board and hook it up to a motor that can run that fast and ...

Time.

ModuloFS commented 2 years ago

Maybe just use the esp eval board and check the step pulses with an logic analyzer? Normaly you should see the interruptions clearly in the step pulses.

MitchBradley commented 2 years ago

I can't do the work and respond to your suggestions at the same time.

ModuloFS commented 2 years ago

love-you-more-keep-quite

MitchBradley commented 2 years ago

Bart and I are both having trouble reproducing the problem. We can jog at high speeds with no interruptions. Have you tried inverting the step pulse or increasing pulse_us ?

ModuloFS commented 2 years ago

No i have not tried, but i see the interruptions in the step signals straight out of the esp too.

MitchBradley commented 2 years ago

Okay

MitchBradley commented 2 years ago

This is really messed up. I duplicated the problem, using v3.6.4-pre1, on a bare ESP32, looking at the X step gpio with a scope. I could see interruptions in the step stream.

Then I took the same source code that was used to build v3.6.4-pre1, from the git tag, and compiled it locally. That version does not fail. I went back and forth several times to make sure - the release file fails, but the locally-compiled one does not. The two files differ in length by 208 bytes.

The release builder compiles in a Github Actions virtual machine under Linux, while the local build is on Windows. I verified that they are using the same version of the cross-compiler by extracting the .comment section from the ELF file; that section is identical between the two files.

I looked inside the binaries/ELF files to see I could spot an obvious difference. That is hard to do because the addresses inside the files quickly diverge due to a file pathname string that is embedded in an error report. The path is different so the string lengths are different. That pushes things around enough that comparison becomes difficult.

This is extremely annoying and will probably take a ridiculous amount of time to solve.

ModuloFS commented 2 years ago

Thank you for your persistent troubleshooting, outstanding work!! Is the 3.4.4 release stable enough to use it in the meanwhile? Or which release should i use? I almost destroyed my machine with the out of sync interruptions in the double y-axis and do not want such a situation again.

MitchBradley commented 2 years ago

Try v3.6.4-pre3. I think it fixes the problem. There was a conflict between interrupt service routines for UART and step timing. Moving the UART ISR to a different core seems to work. This one took a lot out of me.

ModuloFS commented 2 years ago

I have tried v3.6.4-pre3, seems it is working now. I could not hear any interruptions in the motion, i have not measured it with the oscilloscope but i think its ok. Good job Mitch!!!

The behaviour with the $G in the gSender console is still present. And it is only occouring if i run it from a windows host and first open fluidterm before opening gsender. If i open gsender and nothing else before everything is fine. On a Linux host these behaviour is not occurring. I know, maybee it is a boundary condition and it is not interfere with the normal usage but i just want let you know. The second thing i mentioned with the usage of FluidNC together with gSender is some strange disconection behaviour. If i disconnect FluidNC and gSender with the Disconnect Button in gSender or by closing gSender without disconnecting, i get some strange behaviour of FluidNC. Sometimes FNC disables all stepper and turns on gpio.5. Sometimes it does not disables the stepper but turns on gpio.5. And sometimes it does nothing and the steppers are still enabled and gpio.5 does not change. And sometimes it shortly enables gpio.5 and disables it after a second or so. Sometimes after i want to reconnect to FNC i have to reset FNC with FluidTerm to use it again without a powercycle. I have not figured out why and when exactly this happens and it is also not interfere with the usage at all. As by the topic above i just want to let you know.

MitchBradley commented 2 years ago

I can explain the $G in the console. It is an artifact of Advanced Terminal Mode. FluidTerm enables that mode, which causes FluidNC to echo characters that are sent to it. Then when you run gSender and FluidNC is not reset, the commands like $G that gSender auto-sends are echoed back to the console. This does not happen when you just run gSender, because FluidNC defaults to Grbl-compatible no-echo mode. You can disable Advanced Terminal Mode by typing CTRL-L before exiting FluidTerm.

The reset behavior of gSender has problems. In my setup, it would not connect to FluidNC at all because the JavaScript serialport module that gSender uses opens the port in a mode that results in the ESP32 restarting into bootloader mode, where it is expecting to upload new firmware. I solved that by modifying gSender to explicitly issue the proper hard-reset-into-run-mode sequence. I will tell the gSender folks about this. Meanwhile, if you want to patch it yourself, here is an easy way to do it without having to do a full recompile of gSender:

Edit the file C:\Program Files\gSender\resources\app\server\index.js - to do so you may need to edit as Administrator, or change the permissions on the file so an ordinary user can modify it.

Round about line 10242 you should see the line:

        _this2.emit('serialport:open', {

Just before that line, add this:

        _this2.connection.port.set({ dtr: false, rts: true });
        setTimeout(function() {
            _this2.connection.port.set({ dtr: false, rts: false });
        }, 300);

Save the file and restart gSender, and it should connect to FluidNC properly. At least that worked for me (and Bart too).

ModuloFS commented 2 years ago

I can explain the $G in the console. It is an artifact of Advanced Terminal Mode. FluidTerm enables that mode, which causes FluidNC to echo characters that are sent to it. Then when you run gSender and FluidNC is not reset, the commands like $G that gSender auto-sends are echoed back to the console. This does not happen when you just run gSender, because FluidNC defaults to Grbl-compatible no-echo mode. You can disable Advanced Terminal Mode by typing CTRL-L before exiting FluidTerm.

Ok that makes sense!

I will try the change at gSender tomorrow or the day after. I am mostly at a Linux host but i think the file tree should be for the most part the same. Thank you for your hint!!

Would be awasome if the controll functionality of gSender and FluidNC could be used together flawless!

MitchBradley commented 2 years ago

It would be awesome if there were fewer than 1000 different senders each of which has a fan base.

ModuloFS commented 2 years ago

:D Thats right but in addition to UGS i think gSender is the only one which is openSource, under active development, has a nice UI, make use of the grbl jogging funcionality and supports injected code at a M6 (tool change) command for example. So for a CNC Router this is not the badest choice i think.

ModuloFS commented 1 year ago

Just upgraded to V 3.6.8 and i got the same interruptions during jogging motion again. I will upload my startup message and the config file in the coming days. The only difference compared to the posted config file are the steps per mm which are upgraded to 800. This was no problem with V 3.6.4

ModuloFS commented 1 year ago

Here is my startupmessage as well as the config dump:

Startupmessage:

ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x12 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:12812
load:0x40080400,len:3032
entry 0x400805e4

[MSG:INFO: FluidNC v3.6.8]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.1-1-gb8050b365e]
[MSG:INFO: Local filesystem type is spiffs]
[MSG:INFO: Configuration file:config_ratrig_killerbee.yaml]
[MSG:INFO: Machine ModuloController]
[MSG:INFO: Board ModuloControl V1]
[MSG:INFO: Stepping:RMT Pulse:5us Dsbl Delay:5us Dir Delay:5us Idle Delay:255ms]
[MSG:INFO: Axis count 3]
[MSG:INFO: Shared stepper disable gpio.23]
[MSG:INFO: Axis X (0.000,508.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:gpio.26 Dir:gpio.27 Disable:NO_PIN]
[MSG:INFO:  X Pos Limit gpio.35:low]
[MSG:INFO: Axis Y (0.000,750.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:gpio.19 Dir:gpio.18:low Disable:NO_PIN]
[MSG:INFO:  Y Pos Limit gpio.34:low]
[MSG:INFO:   Motor1]
[MSG:INFO:     standard_stepper Step:gpio.21 Dir:gpio.22:low Disable:NO_PIN]
[MSG:INFO:  Y2 Pos Limit gpio.36:low]
[MSG:INFO: Axis Z (0.000,90.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     standard_stepper Step:gpio.25 Dir:gpio.32 Disable:NO_PIN]
[MSG:INFO:  Z Pos Limit gpio.39:low]
[MSG:INFO: safety_door_pin gpio.33:low]
[MSG:INFO: Kinematic system: Cartesian]
[MSG:INFO: 10V Spindle Ena:gpio.5 Out:gpio.13 Dir:NO_PIN Fwd:NO_PIN Rev:NO_PIN Freq:5000Hz Period:8191]
[MSG:INFO: Using spindle 10V]
[MSG:INFO: Probe Pin: gpio.4]
[MSG:INFO: WiFi is disabled]

Config dump:

$CD
board: ModuloControl V1
name: ModuloController
meta: 
stepping: 
  engine: RMT
  idle_ms: 255
  pulse_us: 5
  dir_delay_us: 5
  disable_delay_us: 5
  segments: 12

spi: 
  miso_pin: NO_PIN
  mosi_pin: NO_PIN
  sck_pin: NO_PIN

sdcard: 
  cs_pin: NO_PIN
  card_detect_pin: NO_PIN
  frequency_hz: 0

kinematics: 
  Cartesian: 

axes: 
  shared_stepper_disable_pin: gpio.23
  shared_stepper_reset_pin: NO_PIN
  x: 
    steps_per_mm: 800.000000
    max_rate_mm_per_min: 5000.000000
    acceleration_mm_per_sec2: 150.000000
    max_travel_mm: 508.000000
    soft_limits: true
    homing: 
      cycle: 2
      allow_single_axis: true
      positive_direction: true
      mpos_mm: 508.000000
      feed_mm_per_min: 100.000000
      seek_mm_per_min: 700.000000
      settle_ms: 250
      seek_scaler: 1.100000
      feed_scaler: 1.100000

    motor0: 
      limit_neg_pin: NO_PIN
      limit_pos_pin: gpio.35:low
      limit_all_pin: NO_PIN
      hard_limits: true
      pulloff_mm: 2.000000
      standard_stepper: 
        step_pin: gpio.26
        direction_pin: gpio.27
        disable_pin: NO_PIN

  y: 
    steps_per_mm: 800.000000
    max_rate_mm_per_min: 5000.000000
    acceleration_mm_per_sec2: 150.000000
    max_travel_mm: 750.000000
    soft_limits: true
    homing: 
      cycle: 3
      allow_single_axis: true
      positive_direction: true
      mpos_mm: 750.000000
      feed_mm_per_min: 100.000000
      seek_mm_per_min: 700.000000
      settle_ms: 250
      seek_scaler: 1.100000
      feed_scaler: 1.100000

    motor0: 
      limit_neg_pin: NO_PIN
      limit_pos_pin: gpio.34:low
      limit_all_pin: NO_PIN
      hard_limits: true
      pulloff_mm: 2.000000
      standard_stepper: 
        step_pin: gpio.19
        direction_pin: gpio.18:low
        disable_pin: NO_PIN

    motor1: 
      limit_neg_pin: NO_PIN
      limit_pos_pin: gpio.36:low
      limit_all_pin: NO_PIN
      hard_limits: true
      pulloff_mm: 2.000000
      standard_stepper: 
        step_pin: gpio.21
        direction_pin: gpio.22:low
        disable_pin: NO_PIN

  z: 
    steps_per_mm: 800.000000
    max_rate_mm_per_min: 5000.000000
    acceleration_mm_per_sec2: 150.000000
    max_travel_mm: 90.000000
    soft_limits: true
    homing: 
      cycle: 1
      allow_single_axis: true
      positive_direction: true
      mpos_mm: 90.000000
      feed_mm_per_min: 100.000000
      seek_mm_per_min: 700.000000
      settle_ms: 250
      seek_scaler: 1.100000
      feed_scaler: 1.100000

    motor0: 
      limit_neg_pin: NO_PIN
      limit_pos_pin: gpio.39:low
      limit_all_pin: NO_PIN
      hard_limits: true
      pulloff_mm: 2.000000
      standard_stepper: 
        step_pin: gpio.25
        direction_pin: gpio.32
        disable_pin: NO_PIN

control: 
  safety_door_pin: gpio.33:low
  reset_pin: NO_PIN
  feed_hold_pin: NO_PIN
  cycle_start_pin: NO_PIN
  macro0_pin: NO_PIN
  macro1_pin: NO_PIN
  macro2_pin: NO_PIN
  macro3_pin: NO_PIN

coolant: 
  flood_pin: NO_PIN
  mist_pin: NO_PIN
  delay_ms: 0

probe: 
  pin: gpio.4
  check_mode_start: true

macros: 
  startup_line0: 
  startup_line1: 
  macro0: 
  macro1: 
  macro2: 
  macro3: 

start: 
  must_home: true
  deactivate_parking: true
  check_limits: true

parking: 
  enable: false
  axis: Z
  target_mpos_mm: -5.000000
  rate_mm_per_min: 800.000000
  pullout_distance_mm: 5.000000
  pullout_rate_mm_per_min: 250.000000

user_outputs: 
  analog0_pin: NO_PIN
  analog1_pin: NO_PIN
  analog2_pin: NO_PIN
  analog3_pin: NO_PIN
  analog0_hz: 5000
  analog1_hz: 5000
  analog2_hz: 5000
  analog3_hz: 5000
  digital0_pin: NO_PIN
  digital1_pin: NO_PIN
  digital2_pin: NO_PIN
  digital3_pin: NO_PIN

10V: 
  forward_pin: NO_PIN
  reverse_pin: NO_PIN
  pwm_hz: 5000
  direction_pin: NO_PIN
  output_pin: gpio.13
  enable_pin: gpio.5
  disable_with_s0: true
  s0_with_disable: true
  spinup_ms: 1500
  spindown_ms: 1500
  tool_num: 0
  speed_map: 0=10.000000% 3000=5.000000% 27000=95.000000%
  off_on_alarm: false

arc_tolerance_mm: 0.002000
junction_deviation_mm: 0.010000
verbose_errors: false
report_inches: false
enable_parking_override_control: false
use_line_numbers: false
planner_blocks: 16
ok

As i downgraded today to version 3.6.4. the failure persists until i made a power cycle with the esp32 or until i restarted the controller with the $Bye statement, sadly i am not shure anymore... Anyway since the downgrade to the 3.6.4, the machine is working perfectly again.