bdring / fluidnc Goto Github PK

Is there currently support to add a control pendant for manual jogging and basic controls? Ideally it could also have an lcd display with some general info.

My main problem that I'm trying to solve is that esp3d can be quite inconsistent with the processing times when jogging or sending commands through the terminal. I've crashed the machine on a number of occasions because I ended up sending the same command too many times while it was already in the "buffer".

A control pendant hard-wired to the esp32 would presumably be almost instantaneous, and would provide a lot better feedback to avoid overtravel into obstacles.

One of those jogging handwheels would be the icing on the cake if there was a way to implement that.

Please describe the feature you would like implemented
Be able to probe a map of points based on the GCode's outer edges in order to compensate for height differences on conductive material

Why do you think this would improve FluidNC?
It would make PCB milling much easier and avoid the requirement of a special gcode sender that supports this

What do you need the feature for?
PCB milling

Do you know of other users who need this feature?
Probably anyone milling a PCB?

Version: FluidNC v3.2.7 (wifi)

I have 4 limit switches on gpio 34, 35, 36 and 39. All with external pull ups.

When I test the switches with $limits, all working fine. Homing works also.
But when i enable hard_limits, only 34 and 35 are working.

The limit switches on gpio 36 and 39 immediately report alarm1 when I clear the alarm after startup.

log:

[MSG:INFO: '$H'|'$X' to unlock]
[MSG:INFO: Caution: Unlocked]
ALARM:1
[MSG:INFO: Reset to continue]

Config for gpio39:

  z:
    steps_per_mm: 800
    max_rate_mm_per_min: 2000
    acceleration_mm_per_sec2: 25
    max_travel_mm: 1000
    homing:
      cycle: 1
      mpos_mm: 10
      positive_direction: true

    motor0:
      limit_all_pin: gpio.39:low
      hard_limits: true
      pulloff_mm:1.000
      stepstick:
        direction_pin: gpio.33
        step_pin: gpio.25
    motor1:
      null_motor:

It could be a bug, or did I miss something?
Any ideas?

Hello,
I'm facing a strange behaviour with fluidnc 3.2.1.
With GRBL, when I ask for a probe test (G38.2Z-10F10), I can see the position in realtime during the probe in my sender, but with fluidnc, when I send the gcode, the motor moves until the bit touch but during move, there is no message (tested with usb, wifi and web ui).
Messages seem to be sent after the move end (maybe with a delay after).
Is it a normal behaviour?

Can you provide the source code to compile index.html.gz?
Need to change language

Hi
Is the bug with grbl-esp32 and TMC5160 still present in FluidNC? I would like to use stealthchop but with higher Amps than allowed with TMC2130. (I do not have the drivers for now)
Thanks !

Default password for wifi AP 123456768 is not working. Any solutions?

Please only submit bugs for the latest version of the code. You can check the version number in the startup messages.

Please answer the following questions.

What version of the firmware are you using?
3.2.2

Is the problem repeatable?
Yes

Under what conditions does the bug occur?

If you send the Feed Hold Command (!) while the machine is cycling GCode, Fluid stacks into HOLD:1 state and doesn't respond to any commands after that.
I am using serial connection.
After that I am not even able to connect to the board. I have to remove it from the USB port and then plug it back in, in order to connect

  #define EASIER_TO_READ true

Please describe the feature you would like implemented

MachineConfig.cpp contains a defaultConfig compiled in as a string, but this is a little inaccessible.

I'd like to move it out into DefaultConfig.cpp where it can be more easily found and edited.

I don't expect this would replace the upload flow, but would complement it for some kinds of developer.

Why do you think this would improve FluidNC?

One of the most frustrating parts of dealing with FluidNC is getting configs delivered to the machine.
The workflows for this aren't well surfaced via platformio.ini, and it's easy for the config to get out of sync with the code.

What do you need the feature for?

Rapid development of new code and associated configs.

Do you know of other users who need this feature?

I think it may help some people to get started more easily.

It was very difficult to figure out how the config should have been delivered, if it was delivered, and when delivered what was actually in it

Compiling the config in avoided all of these issues, and allowed working from a known basis.

My config is the following

name: "4-Axis CNC Motherboard v1.2"
board: "4-Axis CNC Motherboard v1.2"

stepping:
  engine: RMT
  idle_ms: 255
  dir_delay_us: 1
  pulse_us: 10
  disable_delay_us: 0

axes:
  shared_stepper_disable_pin: gpio.15:low
  
    x:
        steps_per_mm: 400
        max_rate_mm_per_min: 4000
        acceleration_mm_per_sec2: 80
        max_travel_mm: 302
        soft_limits: true
        homing:
          cycle: 2
          mpos_mm: 0
          positive_direction: false
          seek_mm_per_min: 1500.000
          feed_mm_per_min: 200.000

        motor0:
          limit_all_pin: gpio.36:high
          hard_limits: false
          pulloff_mm: 2.000
          
          standard_stepper:
            direction_pin: gpio.33
            step_pin: gpio.0
            
        motor1:
          null_motor:

    y:
        steps_per_mm: 400
        max_rate_mm_per_min: 4000
        acceleration_mm_per_sec2: 80
        max_travel_mm: 202
        soft_limits: true
        homing:
          cycle: 2
          mpos_mm: 0
          positive_direction: false
          seek_mm_per_min: 1500.000
          feed_mm_per_min: 200.000

        motor0:
          limit_all_pin: gpio.39:high
          hard_limits: false
          pulloff_mm: 2.000
          
          standard_stepper:
            direction_pin: gpio.26
            step_pin: gpio.25
            
        motor1:
          null_motor:

    z:
        steps_per_mm: 400
        max_rate_mm_per_min: 3000
        acceleration_mm_per_sec2: 80
        max_travel_mm: 180
        soft_limits: true
        homing:
          cycle: 1
          mpos_mm: 180
          positive_direction: true
          seek_mm_per_min: 1500.000
          feed_mm_per_min: 200.000
          

        motor0:
          limit_all_pin: gpio.34:high
          hard_limits: false
          pulloff_mm: 2.000
          
          standard_stepper:
            direction_pin: gpio.14:low
            step_pin: gpio.27
            
        motor1:
          null_motor:
      
    a:
        steps_per_mm: 800.000
        max_rate_mm_per_min: 5000.000
        acceleration_mm_per_sec2: 100.000
        max_travel_mm: 300.000
        soft_limits: false
        homing:
          cycle: 3
          positive_direction: true
          mpos_mm: 150.000
          feed_mm_per_min: 100.000
          seek_mm_per_min: 800.000
          debounce_ms: 500
          seek_scaler: 1.100
          feed_scaler: 1.100

        motor0:
          limit_neg_pin: NO_PIN
          limit_pos_pin: NO_PIN
          limit_all_pin: NO_PIN
          hard_limits: false
          pulloff_mm: 1.000
          standard_stepper:       
            step_pin: gpio.12
            direction_pin: gpio.13
      
spi:
  miso_pin: NO_PIN
  mosi_pin: NO_PIN
  sck_pin: NO_PIN

sdcard:
  cs_pin: NO_PIN
  card_detect_pin: NO_PIN

coolant:
  flood_pin: NO_PIN
  mist_pin: NO_PIN

        
probe:
  pin: gpio.32:low:pu

PWM:
  pwm_hz: 5000
  output_pin: gpio.21
  enable_pin: NO_PIN
  direction_pin: gpio.2
  disable_with_s0: false
  s0_with_disable: true
  spinup_ms: 0
  spindown_ms: 0
  tool_num: 0
  speed_map: 0=0% 10000=100%

Axis X,Y and Z are working fine. Axis A is not even visible in the status report message
<Idle|MPos:0.000,0.000,0.000|FS:0.000,0>

Any ideas?

Right off the wiki this is what i see,
"Use this one for external drivers or when only step direction and enable are needed.

example

motor0:
  standard_stepper:
    step_pin: I2SO.5
    direction_pin: I2SO.4
    disable_pin: gpio.16:low"

Are you using I2SO pins for a reason? I thought from what i understand in the wiki those were for some kind of IO extenders?
and otherwise i should use GPIO pins?

I'm using DM542T drivers. hopefully end result i can use squaring. I guess it's not totally necessary because i have 2 1605 ball screws for my Y/Y2 axis. Iv'e got everything running off the latest Precompiled version, but Im having so many issues intermittently (not wiring) pretty confident on that. both Ys work then 1 Y works then no motors work. If i change step pulse config to 0 in my config.Yaml the motors wont respond. If I Leave it set to 2 and change it to 0 in webui and it works.
I'm almost positive it's my Config..

Is this ganged right?
y:
steps_per_mm: 800
max_rate_mm_per_min: 2000
acceleration_mm_per_sec2: 25
max_travel_mm: 1000
homing:
cycle: 2
mpos_mm: 10
positive_direction: false

motor0:
  limit_all_pin: gpio.4:low:pu
  stepstick:
    direction_pin: gpio.15
    step_pin: gpio.26
motor1:
  limit_all_pin: gpio.16:low:pu
  stepstick:
    direction_pin: gpio.33
    step_pin: gpio.27

I have been driving these off 3.3v without issue. Not saying it cant have an effect. Just hasn't yet.

What version of the firmware are you using?
3.2.4

Is the problem repeatable?
Yes

Under what conditions does the bug occur?
I just tried to install 3.2.4 and it does not work for me :/ If I install 3.1.6 back it works(stepper moves). I have only one stepper connected on x axis for testing.
I changed config to new style from example "6_pack_external_huanyang.yaml". Renamed to config.yaml. I just use RMT engine.
Does anyone knows where could be a problem? Does something changed that could cause this?

Configs below:
configs.zip

Hi,
i just bricked a voidmicro.com laserenvraver board by flashing fuidnc using the windows batch script.
After uploading the esp stuck in a boot loop:

ets Jun  8 2016 00:22:57

rst:0x10 (RTCWDT_RTC_RESET),boot:0x37 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371

The upload went flawlessly and i was able to verify the flash contents by using esptool.exe.

The issue is caused by secureboot and flashencryption set by the manufacturer.
These options do not prevent the user from flashing the device.
Flashing unencrypted binarys will render the device useless.
These security options cannot be disabled once activated.

Please refer to:
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/secure-boot-v1.html
https://docs.espressif.com/projects/esp-idf/en/latest/esp32/security/flash-encryption.html
https://limitedresults.com/2019/11/pwn-the-esp32-forever-flash-encryption-and-sec-boot-keys-extraction/

After flashing the esp32 the original flash-contents are no longer present. Using the described attack vector to obtain the AES Keys is no longer possible (and far to complicated).

I end up replacing the esp32 on that board.

The flash-scripts should be extended to use expfuse.exe prior to flashing the device.
If security options are set, inform the User:
This chip is not able to run any other firmware than the original due to security options set by the manufacturer!
Using other flash methods may seem to work, but will brick the device!
Don't do it, SERIOUSLY!

Here is a espfuse-summary of my bricked esp32:

C:\Users\m-sja\Downloads\fluidnc-v3.2.5\win64>espefuse.exe -p com7 -b 115200 -c esp32 summary
Connecting...
Device PID identification is only supported on COM and /dev/ serial ports.
...........
espefuse.py v3.2
EFUSE_NAME (Block) Description  = [Meaningful Value] [Readable/Writeable] (Hex Value)
----------------------------------------------------------------------------------------
Calibration fuses:
BLK3_PART_RESERVE (BLOCK0):                        BLOCK3 partially served for ADC calibration data   = False R/W (0b0)
ADC_VREF (BLOCK0):                                 Voltage reference calibration                      = 1100 R/W (0b10000)

Config fuses:
XPD_SDIO_FORCE (BLOCK0):                           Ignore MTDI pin (GPIO12) for VDD_SDIO on reset     = False R/W (0b0)
XPD_SDIO_REG (BLOCK0):                             If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset    = False R/W (0b0)
XPD_SDIO_TIEH (BLOCK0):                            If XPD_SDIO_FORCE & XPD_SDIO_REG                   = 1.8V R/W (0b0)
CLK8M_FREQ (BLOCK0):                               8MHz clock freq override                           = 50 R/W (0x32)
SPI_PAD_CONFIG_CLK (BLOCK0):                       Override SD_CLK pad (GPIO6/SPICLK)                 = 0 R/W (0b00000)
SPI_PAD_CONFIG_Q (BLOCK0):                         Override SD_DATA_0 pad (GPIO7/SPIQ)                = 0 R/W (0b00000)
SPI_PAD_CONFIG_D (BLOCK0):                         Override SD_DATA_1 pad (GPIO8/SPID)                = 0 R/W (0b00000)
SPI_PAD_CONFIG_HD (BLOCK0):                        Override SD_DATA_2 pad (GPIO9/SPIHD)               = 0 R/W (0b00000)
SPI_PAD_CONFIG_CS0 (BLOCK0):                       Override SD_CMD pad (GPIO11/SPICS0)                = 0 R/W (0b00000)
DISABLE_SDIO_HOST (BLOCK0):                        Disable SDIO host                                  = False R/W (0b0)

Efuse fuses:
WR_DIS (BLOCK0):                                   Efuse write disable mask                           = 388 R/W (0x0184)
RD_DIS (BLOCK0):                                   Efuse read disable mask                            = 3 R/W (0x3)
CODING_SCHEME (BLOCK0):                            Efuse variable block length scheme
  = NONE (BLK1-3 len=256 bits) R/W (0b00)
KEY_STATUS (BLOCK0):                               Usage of efuse block 3 (reserved)                  = False R/W (0b0)

Identity fuses:
MAC (BLOCK0):                                      Factory MAC Address
  = 40:f5:20:81:b4:04 (CRC 0xe0 OK) R/W
MAC_CRC (BLOCK0):                                  CRC8 for factory MAC address                       = 224 R/W (0xe0)
CHIP_VER_REV1 (BLOCK0):                            Silicon Revision 1                                 = True R/W (0b1)
CHIP_VER_REV2 (BLOCK0):                            Silicon Revision 2                                 = False R/W (0b0)
CHIP_VERSION (BLOCK0):                             Reserved for future chip versions                  = 2 R/W (0b10)
CHIP_PACKAGE (BLOCK0):                             Chip package identifier                            = 1 R/W (0b001)
MAC_VERSION (BLOCK3):                              Version of the MAC field                           = 0 R/W (0x00)

Security fuses:
FLASH_CRYPT_CNT (BLOCK0):                          Flash encryption mode counter                      = 1 R/- (0b0000001)
UART_DOWNLOAD_DIS (BLOCK0):                        Disable UART download mode (ESP32 rev3 only)       = False R/- (0b0)
FLASH_CRYPT_CONFIG (BLOCK0):                       Flash encryption config (key tweak bits)           = 15 R/W (0xf)
CONSOLE_DEBUG_DISABLE (BLOCK0):                    Disable ROM BASIC interpreter fallback             = True R/W (0b1)
ABS_DONE_0 (BLOCK0):                               Secure boot V1 is enabled for bootloader image     = True R/W (0b1)
ABS_DONE_1 (BLOCK0):                               Secure boot V2 is enabled for bootloader image     = False R/W (0b0)
JTAG_DISABLE (BLOCK0):                             Disable JTAG                                       = True R/W (0b1)
DISABLE_DL_ENCRYPT (BLOCK0):                       Disable flash encryption in UART bootloader        = True R/W (0b1)
DISABLE_DL_DECRYPT (BLOCK0):                       Disable flash decryption in UART bootloader        = True R/W (0b1)
DISABLE_DL_CACHE (BLOCK0):                         Disable flash cache in UART bootloader             = True R/W (0b1)
BLOCK1 (BLOCK1):                                   Flash encryption key
  = ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? -/-
BLOCK2 (BLOCK2):                                   Secure boot key
  = ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? -/-
BLOCK3 (BLOCK3):                                   Variable Block 3
  = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W

Flash voltage (VDD_SDIO) determined by GPIO12 on reset (High for 1.8V, Low/NC for 3.3V).

and a espfuses-dump of my bricked esp32:

C:\Users\m-sja\Downloads\fluidnc-v3.2.5\win64>espefuse.exe -p com7 -b 115200 -c esp32 dump fuse.hex
Connecting...
Device PID identification is only supported on COM and /dev/ serial ports.

BLOCK0          (                ) [0 ] read_regs: 00130184 2081b404 00e040f5 0000a200 00001032 f0000000 000003d4
BLOCK1          (flash_encryption) [1 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK2          (secure_boot_v1 s) [2 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK3          (                ) [3 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

EFUSE_REG_DEC_STATUS        0x00000000

Here is a espfuse-dump of the new esp32:

C:\Users\m-sja\Downloads\fluidnc-v3.2.5\win64>espefuse.exe -p COM7 -b 115200 dump
Connecting.....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting...
Detecting chip type... ESP32
BLOCK0          (                ) [0 ] read_regs: 00000000 a49b4224 007a30ae 00008200 00000036 00000000 00000004
BLOCK1          (flash_encryption) [1 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK2          (secure_boot_v1 s) [2 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
BLOCK3          (                ) [3 ] read_regs: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

EFUSE_REG_DEC_STATUS        0x00000000

The first section of Block0 is the interesting one.

As one of your projects goals is lo lower the barrier to for new users, it should be obvious also protect them from bricking their devices wherever possible.

Thank you very much for all the effort you put in these cnc-projects!!!
If you have any questions, i'll try to help as best as i can.

Best regards
Marian

The ESPtool that is part of the release cannot find the SPIFFS.bin file as its not included in the download.

What version of the firmware are you using? V3.1.5
Is the problem repeatable? yes - the solution is to download SPIFFS.Bin from the previous release and add it in the Common folder and that seems to solve the issue.

Resolution - Copy spiffs.bin into the ..\\common\\spiffs.bin Folder

POG had an option to prevent single axis homing. Some people see single axis homing as dangerous because you can unlock the homing alarm by homing only one axis.

Version 3.1.3 Release

I am testing the latest release to see how it works compared to Grbl_Esp32. I have written a YAML configuration based off of the examples. No matter what I do, the configurations are not valid, but it does not show me any ERR messages to determine what they are.

I have reduced the YAML down to the most basic settings to see if I would be able to determine where the problem is. I find that it fails even with just Wi-Fi settings.

Example YAML:

name: Wi-Fi Test
board: Wi-Fi Test

comms:
  telnet_enable: true
  telnet_port: 23
  http_enable: true
  http_port: 80
  hostname: fluidnc
  wifi_sta:
    ssid: My Wifi Network

Here is what happens:

[MSG:INFO: STA SSID FluidNC DHCP]
[MSG:INFO: Connecting.]
[MSG:INFO: Connecting..]
[MSG:INFO: No SSID]
[MSG:INFO: WiFi off]

As you can see it tries to connect to a Wi-Fi STA called "FluidNC", not my specified Wi-Fi network.

I realize that wifi_ap may be a required key, so I add that back in and update the YAML.

name: Wi-Fi Test
board: Wi-Fi Test

comms:
  telnet_enable: true
  telnet_port: 23
  http_enable: true
  http_port: 80
  hostname: fluidnc
  wifi_ap:
    ssid: FluidNC
  wifi_sta:
    ssid: My Wifi Network

We then get a correct attempt at connection, followed by a failure and a fall back to the AP in test drive mode.

ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (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:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5856
entry 0x400806a8

[MSG:INFO: STA SSID My Wifi Network DHCP]
[MSG:INFO: Connecting.]
[MSG:INFO: Connecting..]
[MSG:INFO: Connected - IP is 192.168.0.XX]
[MSG:INFO: WiFi on]
[MSG:INFO: Start mDNS with hostname:http://fluidnc.local/]
[MSG:INFO: SSDP Started]
[MSG:INFO: HTTP Started]
[MSG:INFO: Telnet Started on port 23]

Grbl 3.1 [FluidNC v3.1.3 '$' for help]
[MSG:INFO: Configuration is invalid. Check boot messages for ERR's.]
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC      : 0x400e5443  PS      : 0x00060630  A0      : 0x800e5ebd  A1      : 0x3ffd1280  
A2      : 0x00000000  A3      : 0x3ffc5920  A4      : 0x3ffd12f0  A5      : 0x3ffccc74  
A6      : 0x00000003  A7      : 0x00000000  A8      : 0x3f800000  A9      : 0x3ffd1260  
A10     : 0x3ffd12f0  A11     : 0x3f409a1e  A12     : 0x00000000  A13     : 0x00000000  
A14     : 0x3ffe7194  A15     : 0x00000000  SAR     : 0x0000000a  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000010  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xfffffffe  

ELF file SHA256: 0000000000000000

Backtrace: 0x400e5443:0x3ffd1280 0x400e5eba:0x3ffd12c0 0x400e6bff:0x3ffd1320 0x400e52e1:0x3ffd1360 0x400dbde2:0x3ffd1380 0x40108b38:0x3ffd13d0 0x40092d16:0x3ffd13f0

Rebooting...
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (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:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:10124
load:0x40080400,len:5856
entry 0x400806a8

[MSG:INFO: Machine Default (Test Drive)]
[MSG:INFO: Board None]
[MSG:INFO: SPI SCK:gpio.18 MOSI:gpio.23 MISO:gpio.19 CS:gpio.5]
[MSG:INFO: Stepping:RMT Pulse:4us Dsbl Delay:0us Dir Delay:0us Idle Delay:255ms]
[MSG:INFO: Axis count 3]
[MSG:INFO: Axis X (-200.000,0.000)]
[MSG:INFO: Axis Y (-200.000,0.000)]
[MSG:INFO: Axis Z (-200.000,0.000)]
[MSG:INFO: No spindle]
[MSG:INFO: Using spindle NoSpindle]
[MSG:INFO: AP SSID FluidNC IP 10.0.0.1 mask 255.255.255.0 channel 1]
[MSG:INFO: AP started]
[MSG:INFO: WiFi on]
[MSG:INFO: Captive Portal Started]
[MSG:INFO: HTTP Started]
[MSG:INFO: Telnet Started on port 23]

Grbl 3.1 [FluidNC v3.1.3 '$' for help]

As you can see it connects to the Wi-Fi network specified in the YAML file. Then it determines that something is wrong with the configuration, so it decides to disconnect the Wi-Fi and broadcast the access point. This does not happen every time, sometimes it stays connected to the Wi-Fi in STA mode.

A problem arises when trying to adjust the settings after a configuration failure.

FluidNC commands and setting use a $ format. They can only be used in idle mode.

When the configuration fails, it produces the following error: 152: Configuration is invalid. Check boot messages for ERR's.

However, some things need to be changeable during a 152 error, but trying to make changes causes the following error: 8: Command requires idle state.

Examples of settings that may need to be changeable during a 152 error:

• $Sta/Password
• $Config/Filename

There may be others. The only way to recover from this problem was to use a $NXV and erase the configuration in whole, then start over by going into AP (test drive) mode and then setting the Wi-Fi password and updating the configuration file and trying again.

Trying to clear the alarm using $X does nothing. It just repeats the 152 error.

For full information the YAML I am trying to use is this:

name: Test
board: Test

stepping:
  idle_ms: 250
  engine: I2S_STREAM

axes:
  shared_stepper_disable: gpio.13:low

  x:
    steps_per_mm: 800
    max_rate: 2000
    acceleration: 25
    motor0:
      limit_pos: gpio.18
      stepstick:
        step: i2so.13
        direction: i2so.12

  y:
    steps_per_mm: 800
    max_rate: 2000
    acceleration: 25
    motor0:
      limit_pos: gpio.23
      stepstick:
        step: i2so.10
        direction: i2so.5

  z:
    steps_per_mm: 800
    max_rate: 2000
    acceleration: 25
    motor0:
      limit_pos: gpio.19
      stepstick:
        step: i2so.4
        direction: i2so.3

  a:
    steps_per_mm: 800
    max_rate: 2000
    acceleration: 25
    motor0:
      limit_pos: gpio.22
      stepstick:
        step: i2so.2
        direction: i2so.1

i2so:
  bck: gpio.2
  data: gpio.15
  ws: gpio.14

coolant:
  flood: i2so.11
  mist: i2so.15

comms:
  telnet_enable: true
  telnet_port: 23
  http_enable: true
  http_port: 80
  hostname: fluidnc
  wifi_sta:
    ssid: My Wifi Network
  wifi_ap:
    ssid: FluidNC

verbose_errors: true
NoSpindle:

I should mention that one of the example config files does not have the correct form. I had originally based my configuration on this file: https://github.com/bdring/FluidNC/blob/main/example_configs/3axis_v4.yaml

It appears to be based on an older schema.

Finally, this is just my opinion after struggling for several hours testing configurations:

Wi-Fi / AP / Bluetooth settings should go back to being configured in the memory variables. It is counter productive to have Wi-Fi password stored exclusively in the memory while all other settings are stored in the YAML. What I would like to see is a hierarchy such as this:

1. Wi-Fi settings, mode, password.. etc should be configured in memory using the previous Grbl_Esp32 style variables.
2. Wi-Fi, AP.. etc. can be superseded by YAML configuration.
3. If YAML is undefined. Settings in memory should be used (even in Test Mode).
4. If YAML STA mode fails, should fallback to YAML AP (if defined), then the memory variables.

My reasoning for this, other than the headache of dealing with the ESP32 connecting to STA then dropping back to AP mode during a failed configuration, is that I envision devices being used in environments where a Wi-Fi (or Ethernet) connection is required and AP mode would be unwanted due to security concerns. Yes I realize the access point can have a really complex password, but I imagine some do not want a forced fallback to an AP. Can access point fallback be an option, not something that happens by default?

Would it be possible for YAML files to write to memory (such as a Wi-Fi password) then erase the password from the YAML and save the updated file to the SPIFFs filesystem?

Example: If Wi-Fi password is found in YAML, copy to memory variable, then overwrite the YAML using $CD=(current config filename), or some other method to remove the line and overwrite the file.

I feel dumb, but i can't get it working...
A while ago i've build a simple 2-Axis Plasma-CNC (3rd Axis is planned) based on the grbl_esp32. After months of ignoring it, i decided to bring it back to life and found this awesome new version. So i tried to get it working.
Installed it (latest stable version) without issues and i can access the WebUI. Here looks everything fine, as i can see.

But i'm not able to write/find a (for me) working config.yaml so nothing happens when i try to move a axis.
I tried different versions from the example_configs-folder and tried to get them to work with no luck. For sure i changed the ports but nothing happens...

I'm using a esp32, directly wired to dm556 stepperdrivers - without any problems in the old version / grbl_esp32
Also there are no endstops in the system, like i said, really basic...

But i'm absolutetly not able to get at least one Axis working - it feels like i've tried every possible combination in the stepping and motor section, but with no luck

Could you give me kind of a minimalistic config file / the bare minimum - one Axis should hopefully be enough to understand...

0.96 OLED I2C display error, how to do?

Please describe the feature you would like implemented
I designed my one controller for Esp32 Grbl and there it was possible to attach both limit switches of a ganged axis to the same input. So my hardware has 3 inputs for XYZ with two motors on the y axis in mind. If I understand the new FluidNC documentation, this is not possible anymore in order to get a "stress free" homing. Which I can understand, but I think it would be good to allow that so that the user can choose if he wants to use the older procedure or the newer. Is that possible?

Why do you think this would improve FluidNC?
Because it makes it more flexible (and I can use my hardware like planned and don't need to use a "User Button" which i planned for Macros :P

Greets from Germany
Philipp

Please only submit bugs for the latest version of the code. You can check the version number in the startup messages.

Boot message:

[MSG:INFO: FluidNC v3.2.5]
[MSG:INFO: Compiled with ESP32 SDK:v3.3.5-1-g85c43024c]
[MSG:INFO: Configuration file:config.yaml]
[MSG:INFO: Machine ESP32 Dev Controller V4]
[MSG:INFO: Board ESP32 Dev Controller V4]
[MSG:INFO: SPI SCK:gpio.18 MOSI:gpio.23 MISO:gpio.19]
[MSG:INFO: SD Card cs_pin:gpio.5 dectect:NO_PIN]
[MSG:INFO: Stepping:RMT Pulse:2us Dsbl Delay:250us Dir Delay:1us Idle Delay:255ms]
[MSG:INFO: Axis count 3]
[MSG:INFO: Shared stepper disable gpio.13]
[MSG:INFO: Axis X (0.000,1000.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     Standard Stepper Step:gpio.12:low Dir:gpio.14:low Disable:NO_PIN]
[MSG:INFO:     All Limit gpio.17:low:pu]
[MSG:INFO: Axis Y (-1000.000,0.000)]
[MSG:INFO: Axis Z (-5.000,0.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     RC Servo Pin:gpio.27 Pulse Len(650,1700)]
[MSG:INFO: Kinematic system: Cartesian]
[MSG:INFO: PWM Spindle Ena:gpio.22 Out:gpio.2 Dir:NO_PIN Freq:5000Hz Res:13bits]
[MSG:INFO: Using spindle PWM]
[MSG:INFO: Connecting to STA SSID:3212]
[MSG:INFO: Connecting.]
[MSG:INFO: Connecting..]
[MSG:INFO: Connected - IP is 10.88.111.15]
[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]

Grbl 3.2 [FluidNC v3.2.5 (wifi) '$' for help]
[MSG:INFO: '$H'|'$X' to unlock]

Please answer the following questions.

What version of the firmware are you using?
UI: 2.1b72 / FW: fluidnc v3.2.5

Is the problem repeatable?
Yes

Under what conditions does the bug occur?
This happens when I create a macro under webui interface.
I uploaded macro0.g to esp localfs but whenever I click the button, nothing happens and after that, no other command would work.
Here is the log after I click macro:

$G
[GC:G0 G54 G17 G21 G90 G94 M5 M9 T0 F0 S0]
ok
<Alarm|MPos:0.000,0.000,0.000|FS:0,0|WCO:3.000,0.000,-2.500>
$X
<Alarm|MPos:0.000,0.000,0.000|FS:0,0|Ov:100,100,100>
[MSG:INFO: Caution: Unlocked]
ok
<Idle|MPos:0.000,0.000,0.000|FS:0,0>
[ESP700]/macro0.g
<Idle|MPos:0.000,0.000,0.000|FS:0,0|WCO:3.000,0.000,-2.500>
<Idle|MPos:0.000,0.000,0.000|FS:0,0|SD:100.00,/localfs/macro0.g>
<Idle|MPos:0.000,0.000,0.000|FS:0,0|SD:100.00,/localfs/macro0.g>
<Idle|MPos:0.000,0.000,0.000|FS:0,0|SD:100.00,/localfs/macro0.g>
<Idle|MPos:0.000,0.000,0.000|FS:0,0|SD:100.00,/localfs/macro0.g>
<Idle|MPos:0.000,0.000,0.000|FS:0,0|SD:100.00,/localfs/macro0.g>
<Idle|MPos:0.000,0.000,0.000|FS:0,0|SD:100.00,/localfs/macro0.g>
<Idle|MPos:0.000,0.000,0.000|FS:0,0|SD:100.00,/localfs/macro0.g>
<Idle|MPos:0.000,0.000,0.000|FS:0,0|SD:100.00,/localfs/macro0.g>
<Idle|MPos:0.000,0.000,0.000|FS:0,0|WCO:3.000,0.000,-2.500|SD:100.00,/localfs/macro0.g>
<Idle|MPos:0.000,0.000,0.000|FS:0,0|Ov:100,100,100|SD:100.00,/localfs/macro0.g>
<Idle|MPos:0.000,0.000,0.000|FS:0,0|SD:100.00,/localfs/macro0.g>

Here is the macro0.g content:

G91G0X0.1

Some screenshots:

Please describe the feature you would like implemented
Using the ESP32 camera mounted near the spindle it would be nice to be able to align the workpiece to be able to do 2 face operations without dowels.

What you do is make 2 holes through the workpiece at fixed locations, do the 1st job, flip it over and then find the 2 holes with the camera and use them to both find the new origin and compensate for any workpiece rotation that might have happened during the flip.

It would help to have zoom (digital), a crosshair and a circle in the camera view that should be able to match the registration holes done in the workpiece

Why do you think this would improve FluidNC?
Would make multi-face jobs easier

What do you need the feature for?
Double sided PCBs

Do you know of other users who need this feature?
bCNC has this feature and it works quite well

I recently purchased a brushless dc motor that has inputs for three different speed control levels (high, mid, low). Is there a way that I could assign these electronic "gears" to IO pins and activate the correct one based on the spindle speed?

I just picked up a few "TMC2209 4 Axis Grbl_ESP32 CNC Controllers" from Tindie.

I didn't see a template for this board under FluidNC/example_configs/ and wasn't able to get it working yet.

While there are a number of examples with the TMC2209, I can't seem to get them working. I'm I missing something obvious? I'd love to help contribute an example config once I have it working.

Connecting to a visible SSID works, hidden doesn't

Please describe the feature you would like implemented
A bar that sets the spindle RPM, not just on/off

Why do you think this would improve FluidNC?
Almost all spindle types that are supported by FluidNC have some kind of RPM setting, hence it's only logical to be able to control it via the web interface

What do you need the feature for?
Mainly to test the spindle but also sometimes I wanna cut something by hand so I put it under the spindle, turn it on and guide it. Like an upside down router table

Do you know of other users who need this feature?
Nop

Is the SD detect pin working?
If I define NO_PIN the SD card works perfectly, but if I assign a pin the card is not detected any more. I tried pulling the pin up or down and it doesn't detect it

Hi bdring,

I created a new opensource Motion Controller, NCMate-4, but before ordering the PCB's I wanted to ask you for feedback. It is made for FluidNC (which is awesome!), so I wonder if you have any comment on potential improvements. It is based on your 6-pack design, but less modular and with some small changes.

Core features:

• 150x100 mm 4 layer PCB
• 4 motor modules, having my personal 3 + 1 axis CNC machine in mind
• Motor signal passthrough to external drivers with solder jumpers
• Spindle header for DC spindles, 0-10V or ESC drivers, with 2 isolated outputs
• 2 high power outputs to connect external relays or other loads directly from the power-in
• 2 fan headers, power-in or 5V selectable, can be controlled by PWM or set to always-on with solder jumper
• 4 isolated, powered 5v outputs
• 6 isolated, powered inputs

Please let me know what you think, and if you are interested to received one assembled boards of the first order - you inspired me to this little project, so I will love to send you one.

Best regards
Christian

Schematic_NCMate_2021-12-04.pdf

Please only submit bugs for the latest version of the code. You can check the version number in the startup messages.

Please provide the FluidNC boot messages per this page.

Please answer the following questions.

What version of the firmware are you using?

v3.2.5

Is the problem repeatable?

Yes

Under what conditions does the bug occur?

While running a job from SD Card, if you connect to the Web UI the machine seems to reboot / reset.

Important If you paste firmware code, please use Markdown Code and Syntax Highlighting with language C++. Use the three back tick method.

  #define EASIER_TO_READ true

Please describe the feature you would like implemented
Ability to enter WIFI credentials at install to accommodate passwords with special characters

Why do you think this would improve FluidNC?
Make it easier to connect.

What do you need the feature for?
My wifi password ends with a '!'. This does not work currently.

Do you know of other users who need this feature?
Anyone who uses special characters in their wifi password.

What version of the firmware are you using?
FluidNC v3.2.4

Is the problem repeatable?
Yes

Under what conditions does the bug occur?
When no SDCard is present and you try to use the Upload button in the Dashboard.

ERROR:20
Unsupported or invalid g-code command found in block.

Also tries to redirect to upload_serial which doesn't appear to be a valid http path.

It took some time before my subconscious realized that the 'upload' area had the 'SD' label on it, I had first assumed it was uploading to flash like the config file. I proceeded to prune down my .nc file to very basics trying to find which GCode command was unsupported. Obviously, there was nothing wrong with the GCode, but rather it couldn't store to a non-present storage device.

Maybe the file area should be disabled with a message about not having an SD card reader attached?

Not a huge deal - I've ordered an SD card module. The error message just threw me off and sent me down the wrong path for a little while.

In GE $Spindle/Type changes the spindle. That persists after reboot. In FNC tool number is used, but that does not persist.

Please describe the feature you would like implemented

mc_line() is special in that it operates in a post-kinematic environment, while the other mc_ operations are in a pre-kinematic environment.

This means that code that calls, e.g., mc_arc() cannot also call mc_line(), but must instead call cartesian_to_motors().

Let's rename cartesian_to_motors() as mc_line() and rename mc_line() to something more like mc_move_motors().

This would fit with mc_move_motors() receiving the motors computation from cartesian_to_motors().

Why do you think this would improve FluidNC?

It was confusing to understand the special status of mc_line() vs mc_arc when reviewing the kinematic code, to understand which operations were operating in which coordinate spaces.

What do you need the feature for?

To make kinematic custom code easier to understand.

The separation between cartesian and motor planning would become clearer.

Do you know of other users who need this feature?

A number of custom kinematics would be made simpler to understand.

When two axes home in same cycle (e.g. X and Y both has /homing/cycle = 2 ) if one axis is ganged(has two motors) with independent limit switches on each motor and squaring enabled, FluidNC homing crashes and CNC becomes unresponsive . Serial output following

Backtrace: 0x401ae337:0x3ffb1d70 0x400d8f4d:0x3ffb1d90 0x400d904b:0x3ffb1dc0 0x400dc7ff:0x3ffb1df0 0x400e3832:0x3ffb1e10 0x400e38ad:0x3ffb1e30 0x401ae749:0x3ffb1e50 0x400e4226:0x3ffb1e70 0x400e4543:0x3ffb1ef0 0x400e456c:0x3ffb1f20 0x400e551c:0x3ffb1f40 0x400dbe32:0x3ffb1f60 0x40107e04:0x3ffb1fb0 0x4008be02:0x3ffb1fd0
  #0  0x401ae337:0x3ffb1d70 in Machine::Axis::pulloffOffset() at FluidNC/src/Machine/Axis.cpp:83
  #1  0x400d8f4d:0x3ffb1d90 in Machine::Homing::run_one_cycle(unsigned short) at FluidNC/src/Machine/Homing.cpp:304 

My configuration example

axes:
     x:
      homing:
           cycle: 2
    motor0:
      limit_pos: gpio.33
      hard_limits: false
      pulloff: 2.000

 y:
    homing:
      cycle: 2

    motor0:
      limit_pos: gpio.34
      hard_limits: false
      pulloff: 2.000

    motor1:
      limit_pos: gpio.32
      hard_limits: false
      pulloff: 2.000

Please describe the feature you would like implemented

When an axis is specified without homing it currently derives limits as though it had homed in a positive direction to 0.
This produces a viable range from -travel_max to 0.

If a system doesn't home, it seems more reasonable to assume symmetric travel around 0.
Giving a viable range from travel_max / -2 to travel_max / 2.

Why do you think this would improve FluidNC?

RcServos don't have reasonable homing, meaning that if you specify

  z:
    steps_per_mm: 1
    max_travel_mm: 100
    motor0:
      rc_servo:

then only Z-100 to Z0 will produce motion, which is moderately astonishing.

Using symmetric limits would give a range from Z-50 to Z50, centered at 0, which seems more reasonable.

What do you need the feature for?

I guess you could work around this issue in a number of ways, but it would make the base case more reasonable.

Do you know of other users who need this feature?

I assume people using RcServo would benefit from not needing to work around the negative range requirement.

I tried to flash the latest FluidNC on a ESP32 dev board. When I try to connect to it (AP) it says you need to log in and it opens a page that says "File index.html.gz is missing, please upload it".. Any advice?

Please describe the feature you would like implemented

The ability to include custom fields in the yaml configuration.

Maybe in some kind of custom field.

e.g.,

axis:
x:
custom:
anchor:
x: -240

etc

Why do you think this would improve FluidNC?

Code under Custom/ sometimes needs custom configuration.

What do you need the feature for?

I've just put together wall plotter custom kinematics in grbl esp32, and thought I'd see if I could port it across.

As part of this, I need to be able to configure the anchor points, which I previously did using a #define.

It seems like this is something that ought to be configurable, but I read in the wiki that unsupported keys will be dropped, which makes it sound currently impossible.

I can compile these fields directly into the Custom/wall_plotter.cpp, but that feels a bit like a regression.

Do you know of other users who need this feature?

No, but I can guess that most of the Custom/ code will want some kind of configuration support, otherwise it probably wouldn't be in Custom/ :).

when I try to stream gcode using LaserGRBL and BCNC via telnet connection, my FluidNC happens a long buffering when the Z Axis will move down towards the workpiece and not move, no alarm appears. I don't have this problem on GRBL ESP32 version 1.3, I'm using an ESP32 DevKit V1 board running on windows 10. Thank You

I wonder if there could be a config file for your MPCNC board?

Please describe the feature you would like implemented
A step by step guide to the installation process on Mac OS.

Why do you think this would improve FluidNC?
There's a lot to learn for a newbie.

What do you need the feature for?
I don't need it, I already invested the time to figure it out. I would have loved to have had it.

My markdown version is here:
https://github.com/Longus/FluidNC/wiki/Set-Up-FluidNC-Using-macOS

Please describe the feature you would like implemented
I'd like to be able to expand the GPIOs available on ESP32 with MCP23017/MCP23S17. It adds 16 GPIOs with internal pullups and pulldowns and has an interrupt lane to avoid pinging it periodically

Why do you think this would improve FluidNC?
It would add a ton of GPIOs, very cheaply in terms of cost, traces (SPI or I2C) and computing power (has interrupts)

What do you need the feature for?
I'm designing a board that it's meant for an MPCNC and its main concern is support for SPI/UART drivers and simplicity of the circuit so it can mostly be milled on a CNC

Do you know of other users who need this feature?
Probably? I think your other boards use a shift register to drive the step/dir pins but to my little mind is better to drive these with direct GPIOs and just use an expander (be it GPIO expander or shift register) for control/limit switches

How to set up two motors per axis if their drivers are using one direction pin?

  x:  
    motor0:
      stepstick:
        direction_pin: gpio.26
        step_pin: gpio.12
        
    motor1:
      stepstick:
        direction_pin: gpio.26
        step_pin: gpio.22

[MSG:ERR: Configuration error at /machine/axes/x/motor1/stepstick: ERR: Setting up pin [gpio.26] failed. Details: Pin is already used.]␊

Hi,
I am trying to write a python client application to send my commands through the wifi connection to the Fluidnc host.
I am not sure how I should setup the connection in the python client side.

Here's a brief description of my attempt:

1. I have setup Fluidnc connection to STA and in the boot message I get:

[MSG:INFO: Connecting to STA SSID:3212]
[MSG:INFO: Connecting.]
E (1057) wifi:AP has neither DSSS parameter nor HT Information, drop it
[MSG:INFO: Connecting..]
[MSG:INFO: Connected - IP is 10.88.111.15]
[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]

So in the python code I tried the following:

import websockets
import asyncio

async def hello():
  async with websockets.connect('ws://10.88.111.15/') as ws:
    await ws.send('HOW TO SEND COMMAND')
    greeting = await ws.recv() # HOW TO RECEIVE RESPONSE
    print(greeting)

asyncio.get_event_loop().run_until_complete(hello())

There are two points of uncertainties for me:

1. I am not sure if this is the right way to establish a connection to send g-codes to the esp32
2. Even if the connection is established successfully, how to send a gcode command to esp? Treat it as a serial interface?
3. When I use ws4py library (other than websockets), I get the following message after connect which gives me an impression that there's something missing:

ws4py.exc.HandshakeError: Invalid response status: b'200' b'OK'  

I'd appreciate any feedback if anyone has been able to get it working with a websocket client.
Regards

Does anyone have config example for MKS-DLC32 board? I'm using v.2.0. They have the schematic here but I'm not sure how to read the schematic and turn it into a working config for FluidNC. Really appreciate anyone's help on this.

FluidNC/src/Configuration/../MyIOStream.h:34:16: error: call of overloaded 'print(uint64_t&)' is ambiguous

What version of the firmware are you using?
v3.2.7
Is the problem repeatable?
Yes
Under what conditions does the bug occur?

Trying to enter wifi password, mine ends with a '!'. When I try $Sta/Password=(password)! it comes back with [feedhold] and hangs

  #define EASIER_TO_READ true

Couldn't set SSID with a ?, or some other special characters. No way to pass a quoted ssid?

$STA/SSID=NANI?
$STA/SSID=NANI
<Idle|MPos:0.000,0.000,0.000|FS:0,0>
$STA/SSID=NANI
ok

I am interested in expanding the IO in my project because I've run out of pins, and would like to know where I can find documentation about this. Also, if you can recommend a chip to use or a class of chips that would be suitable, it would be greatly appreciated. I already have a custom board that I'm using with darlington arrays to drive the output signals, but my thought is possibly replacing those with the IO expansion chips, assuming they can drive 5v IO on the output side.

I have a 4 Axis External Driver controller that i'm migrating from grbl_esp32 to fluidnc. Running the latest github release as of last night:

[MSG:INFO: FluidNC v3.2.5]
[MSG:INFO: Compiled with ESP32 SDK:v3.3.5-1-g85c43024c]

The issue i'm having is whenever i try to configure digital outputs, my board panics and gets into a reboot loop:

[MSG:INFO: Probe Pin: gpio.32]
[MSG:DBG: mc_reset()]
[MSG:ERR: gpio.21]
abort() was called at PC 0x401ab95b on core 1

ELF file SHA256: 0000000000000000

Backtrace: 0x40089fdc:0x3ffbfea0 0x4008a259:0x3ffbfec0 0x401ab95b:0x3ffbfee0 0x401ab9a2:0x3ffbff00 0x401aaf87:0x3ffbff20 0x40081981:0x3ffbff40 0x401b2273:0x3ffbff80 0x40089c1d:0x3ffbffa0 0x400eed9d:0x3ffbffc0 00

Rebooting...

The relevent chunk of my config file is as follows:

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: gpio.21
  digital1_pin: NO_PIN
  digital2_pin: NO_PIN
  digital3_pin: NO_PIN

If i change it to:

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

Boot completes successfully.

full config file:

board: Big CNC
name: Big CNC
stepping:
  engine: RMT
  idle_ms: 255
  pulse_us: 2
  dir_delay_us: 1
  disable_delay_us: 0

axes:
  shared_stepper_disable_pin: gpio.13
  x:
    steps_per_mm: 800.000
    max_rate_mm_per_min: 5000.000
    acceleration_mm_per_sec2: 100.000
    max_travel_mm: 300.000
    soft_limits: false
    homing:
      cycle: 2
      positive_direction: false
      mpos_mm: 150.000
      feed_mm_per_min: 100.000
      seek_mm_per_min: 200.000
      debounce_ms: 500
      seek_scaler: 1.100
      feed_scaler: 1.100

    motor0:
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      limit_all_pin: gpio.34
      hard_limits: true
      pulloff_mm: 1.000
      standard_stepper:
        step_pin: gpio.0
        direction_pin: gpio.2
        disable_pin: NO_PIN

  y:
    steps_per_mm: 800.000
    max_rate_mm_per_min: 5000.000
    acceleration_mm_per_sec2: 100.000
    max_travel_mm: 300.000
    soft_limits: false
    homing:
      cycle: 2
      positive_direction: true
      mpos_mm: 150.000
      feed_mm_per_min: 100.000
      seek_mm_per_min: 200.000
      debounce_ms: 500
      seek_scaler: 1.100
      feed_scaler: 1.100

    motor0:
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      limit_all_pin: gpio.35
      hard_limits: true
      pulloff_mm: 1.000
      standard_stepper:
        step_pin: gpio.26
        direction_pin: gpio.15
        disable_pin: NO_PIN
        
    motor1:
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      limit_all_pin: gpio.39
      hard_limits: true
      pulloff_mm: 1.000
      standard_stepper:
        step_pin: gpio.12
        direction_pin: gpio.14
        disable_pin: NO_PIN

  z:
    steps_per_mm: 800.000
    max_rate_mm_per_min: 5000.000
    acceleration_mm_per_sec2: 100.000
    max_travel_mm: 300.000
    soft_limits: false
    homing:
      cycle: 1
      positive_direction: true
      mpos_mm: 150.000
      feed_mm_per_min: 100.000
      seek_mm_per_min: 800.000
      debounce_ms: 500
      seek_scaler: 1.100
      feed_scaler: 1.100

    motor0:
      limit_neg_pin: NO_PIN
      limit_pos_pin: NO_PIN
      limit_all_pin: gpio.36
      hard_limits: true
      pulloff_mm: 1.000
      standard_stepper:
        step_pin: gpio.27
        direction_pin: gpio.33
        disable_pin: NO_PIN

spi:
  miso_pin: gpio.19
  mosi_pin: gpio.23
  sck_pin: gpio.18

sdcard:
  card_detect_pin: NO_PIN
  cs_pin: gpio.10

control:
  safety_door_pin: NO_PIN
  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.32
  check_mode_start: true

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

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

start:
  must_home: false

Huanyang:
  uart:
    txd_pin: gpio.17
    rxd_pin: gpio.4
    rts_pin: gpio.16
    baud: 9600
    mode: 8N1
  modbus_id: 1
  tool_num: 0
  speed_map: 0=0% 0=25% 6000=25% 24000=100%

Is there a way to set the debounce on each of the limit switches used for hard limits?

Thx
NB

Please describe the feature you would like implemented

There is currently a hard coded limit of 4 user definable macros. With work on developing support for I/O expanders , it would be good to increase this amount.

Why do you think this would improve FluidNC?

There are use cases where having more than 4 user definable button macros would be useful. For example -

1. If you have an ATC and would like to manually load a tool. Using a physical button for this task would be an ideal way to do this.
2. The possibility of directly wiring in a jog pendent for manual moves would be a good fit as the button macros are only available when the machine state is idle
3. GRBL ESP32 is often used non CNC standard projects. Many of these would benefit from an increase in usable tactile, offline controls.

What do you need the feature for?

To retro fit to a Roland pen plotter and keep functionality such as pen select

Do you know of other users who need this feature?

There is a growing community of people using GRBL with pen plotters. The current macro allocation can be quickly used up when this is used for any functions related to pen / tool change.