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.
GitHub - bdring/FluidNC: The next generation of motion control firmware, Github
3 Likes
I saw that while researching his GRBL boards.
1 Like
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.
2 Likes
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.
2 Likes
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.
1 Like
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.
2 Likes
O.k. so now this makes more sense to me. Reminds me alot of how I configured Klipper for my 3d printers recently!!!
@vicious1