Mr. Bart Dring is at it again! His new firmware is GRBL compatible with added benefits. The Config file is looking real nice to me.
I saw that while researching his GRBL boards.
I just switched over to fluidnc as part of my laser scan troubleshooting process. Transferring from grblesp32 was made easier with the " Translate Machine.h File to FluidNC" feature now found in the grblesp32 issue report section. However, it wasn’t just drop a file and cut… homing directions were wrong and autosquare wasn’t setup (also, esp3d wifi wasn’t configured precompile, but you can use the standard esp3d hotspot method to set it up). Since it’s not that long, I’m posting my working YAML here. This is for a 24"x24"x6" MPCNC with 6-pack using dual endstops, z-max stop, mist, flood, spindle, laser pwm, e-stop/pause/run buttons, a probe, and “running” LED indicator.
name: TrugMPCNC board: 6-pack kinematics: Cartesian: stepping: engine: I2S_static idle_ms: 255 dir_delay_us: 0 pulse_us: 4 disable_delay_us: 0 axes: x: steps_per_mm: 200.000 max_rate_mm_per_min: 7500.000 acceleration_mm_per_sec2: 127.000 max_travel_mm: 562.000 soft_limits: true homing: cycle: 2 mpos_mm: -562.000 positive_direction: false settle_ms: 250.000 seek_mm_per_min: 2000.000 feed_mm_per_min: 300.000 seek_scaler: 1.100 feed_scaler: 5.000 motor0: limit_neg_pin: gpio.33 limit_pos_pin: NO_PIN limit_all_pin: NO_PIN hard_limits: true stepstick: direction_pin: i2so.1 step_pin: i2so.2 disable_pin: i2so.0 ms3_pin: i2so.3 motor1: limit_neg_pin: gpio.32 limit_pos_pin: NO_PIN limit_all_pin: NO_PIN hard_limits: true stepstick: direction_pin: i2so.12 step_pin: i2so.13 disable_pin: i2so.15 ms3_pin: i2so.14 y: steps_per_mm: 200.000 max_rate_mm_per_min: 7500.000 acceleration_mm_per_sec2: 127.000 max_travel_mm: 562.000 soft_limits: true homing: cycle: 3 mpos_mm: -562.000 positive_direction: false settle_ms: 250.000 seek_mm_per_min: 2000.000 feed_mm_per_min: 300.000 seek_scaler: 1.100 feed_scaler: 5.000 motor0: limit_neg_pin: gpio.35 limit_pos_pin: NO_PIN limit_all_pin: NO_PIN hard_limits: true stepstick: direction_pin: i2so.4 step_pin: i2so.5 disable_pin: i2so.7 ms3_pin: i2so.6 motor1: limit_neg_pin: gpio.34 limit_pos_pin: NO_PIN limit_all_pin: NO_PIN hard_limits: true stepstick: direction_pin: i2so.17 step_pin: i2so.18 disable_pin: i2so.16 ms3_pin: i2so.19 z: steps_per_mm: 800.000 max_rate_mm_per_min: 2000.000 acceleration_mm_per_sec2: 80.000 max_travel_mm: 150.000 soft_limits: true homing: cycle: 1 mpos_mm: 0.000 positive_direction: true settle_ms: 250.000 seek_mm_per_min: 2000.000 feed_mm_per_min: 300.000 seek_scaler: 1.100 feed_scaler: 5.000 motor0: limit_neg_pin: gpio.25 limit_pos_pin: NO_PIN limit_all_pin: NO_PIN hard_limits: true stepstick: direction_pin: i2so.9 step_pin: i2so.10 disable_pin: i2so.8 ms3_pin: i2so.11 motor1: null_motor: i2so: bck_pin: gpio.22 data_pin: gpio.21 ws_pin: gpio.17 spi: miso_pin: gpio.19 mosi_pin: gpio.23 sck_pin: gpio.18 sdcard: cs_pin: gpio.5 control: reset_pin: gpio.16:pu feed_hold_pin: gpio.4:pu cycle_start_pin: gpio.26:pu coolant: flood_pin: i2so.24 mist_pin: gpio.15 delay_ms: 1000.000 probe: pin: gpio.39 check_mode_start: false macros: startup_line0: startup_line1: macro0: macro1: macro2: macro3: start: must_home: true check_limits: true deactivate_parking: false user_outputs: digital0_pin: i2so.25 laser: spinup_ms: 0 spindown_ms: 0 tool_num: 0 speeds: 0=0.0% 1000=100.0% output_pin: gpio.13 enable_pin: gpio.14 disable_with_s0: false s0_with_disable: false pwm_hz: 5000 arc_tolerance_mm: 0.002 junction_deviation_mm: 0.010 verbose_errors: false report_inches: false enable_parking_override_control: false use_line_numbers: false
Of course, with a 6-pack you can plug in your expansion boards wherever (more or less)… but I figured seeing a working config might help others adapt their rig to the new YAML method.
That should come in handy thank you!
mpcnc fluidnc config - for later searching.
I popped back in here to make changes to my posted config, after dealing with some issues with laser engraving (raster scanned images, etc). Basically, “I2S_stream” is the default and touted as the way forward, however it will cause problems with laser etches being offset (laser firing early, or steps coming too late). To fix this, I changed to “I2S_static”, and the problems went away. So I recommend anyone who plans to use a laser change to static, at least until these known bugs with stream are solved in development.
Besides this discovery, I thought I’d share how pleased I am with how fluidnc has changed vs grblesp32. Dealing with YAML config files may sound torturous to some, but it’s actually so much easier to test different configs now that recompile is not required for 99% of things you’d change. Also, the homing routine is improved… clean and efficient, just like Marlin now. For those not familiar, grblesp32 had a poorly optimized homing routine that would actually tweak the gantry as it homed each individual switch. Now it always moves in tandem, minimizing tweakage, and making the whole process faster/quiter/less scary looking. Also, I’ve run Marlin and GRBL on ramps (mega), grblesp32 and fluidnc on esp32… always the same drivers and motors, but now with fluidnc (using I2S_static), fast jogging is way smoother. All axis would stutter a bit, making a warbling sound when I jogged at medium speed (“2” in bCNC). Now it actually reaches full speed during the jog, sounds super smooth, and stops more predictably than before.
That is because of the 6 axis generic board, right? My MPCNC board config doesn’t have that:
I haven’t looked though the files in detail (and dont have a local copy in vscode to run a search on it), but AFAIK all of the default configs use stream:
[edit: Saw some using RMT… but that requires native esp32 pins so not a broadly applicable solution probably. At least things like autosquare that require tons of pins would probably not be feasible without the i2s… not that the stepper drivers have to be i2s… but guessing esp32 doesn’t have the pins to do 5 independent drivers like that.]
I’m curious on the nut/bolt differences between static, stream, and rmt (timed doesn’t sound fun). Have you had success laser etching with RMT so far? The github doesn’t describe much, but I’m guessing native pins would be better, lol.
Which board do you have? I am not aware of any reason I2S would be used on my board. On the newer 6 axis board, there is another processor (to expand the GPIO). My guess was that the I2S was controlling the interface between that and the ESP32.
I’m using Bart’s 6-pack, version 1.5:
1.8 is the latest on github, and it also uses an i2s expander:
Looking at those schematics, looks like the native pins are mostly endstops… I assume there’s advantages with interrupts using native pins there. I understand that i2s is the protocol used between the chip and esp32, but how it works as far as stream/static/rem is above my pay grade.