FluidNC: Troubleshooting $MI / $MD commanding weirdnesses

Picking up from here:

I’ve started testing this with the Jackpot on my JL1, which has beta firmware and beta UI.

I need to do a bit of driving of this for a bit, but at least with my JL1 config everything seems happy.

[MSG:INFO: FluidNC v3.7.12 (WebUI3Support-b2ab8a62-dirty) https://github.com/michmela44/FluidNC.git]
[MSG:INFO: Compiled with ESP32 SDK:v4.4.4]
[MSG:INFO: Local filesystem type is spiffs]
[MSG:INFO: Configuration file:config.yaml]
[MSG:INFO: Machine JL1_Laser]
[MSG:INFO: Board Jackpot TMC2209]
[MSG:INFO: UART1 Tx:gpio.0 Rx:gpio.4 RTS:NO_PIN Baud:115200]
[MSG:INFO: I2SO BCK:gpio.22 WS:gpio.17 DATA:gpio.21]
[MSG:INFO: SPI SCK:gpio.18 MOSI:gpio.23 MISO:gpio.19]
[MSG:INFO: SD Card cs_pin:gpio.5 detect:NO_PIN freq:20000000]
[MSG:INFO: Stepping:I2S_static Pulse:4us Dsbl Delay:0us Dir Delay:1us Idle Delay:255ms]
[MSG:INFO: User Digital Output:0 on Pin:gpio.26]
[MSG:INFO: Axis count 3]
[MSG:INFO: Axis X (0.000,220.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     tmc_2209 UART1 Addr:0 CS:NO_PIN Step:I2SO.2 Dir:I2SO.1 Disable:I2SO.0 R:0.110]
[MSG:INFO:  X Pos Limit gpio.25]
[MSG:INFO: Axis Y (0.000,280.000)]
[MSG:INFO:   Motor0]
[MSG:INFO:     tmc_2209 UART1 Addr:1 CS:NO_PIN Step:I2SO.5 Dir:I2SO.4 Disable:I2SO.7 R:0.110]
[MSG:INFO:  Y Neg Limit gpio.33]
[MSG:INFO: Axis Z (-1000.000,0.000)]
[MSG:INFO:   Motor0]
[MSG:INFO: X Axis driver test passed]
[MSG:INFO: Y Axis driver test passed]
[MSG:INFO: Kinematic system: Cartesian]
[MSG:INFO: Laser Ena:gpio.2 Out:gpio.27 Freq:5000Hz Period:8191]
[MSG:INFO: Using spindle Laser]
[MSG:INFO: AP SSID FluidNC IP mask channel 1]
[MSG:INFO: AP started]
[MSG:INFO: WiFi on]
[MSG:INFO: Captive Portal Started]
[MSG:INFO: HTTP started on port 80]
[MSG:INFO: Telnet started on port 23]


[MSG:INFO: Disabling all motors]

[MSG:INFO: X Axis driver test passed]
[MSG:INFO: Y Axis driver test passed]

The steppers actually changed, from energized to not and back?

You don’t have a Z in that config?

Near as I can tell, yes. I was going to drive it around a bit, but took a little detour through upgrading to the latest candidate FluidNC on the JL1. Was about to go jog it around.

No Z in the JL1.
I do plan to put the MPCNC and LR3 configs on my spare jackpot, and on the USB-C and USB-Micro versions of the ESP32- but that might be tormorrow. It’s currently set up as Marlin and using a USB-C ESP32. there’s some pin bending to make things fit.

I’ll get to it tomorrow somtime. Will report in a bit how things go driving the JL1 around between $MI and $MD sends.

I am on 3.7.13 and I am on WebUI v2.

I just now added a new macro button for $MI positioned near my macro button for $MD.

I can home Z to the max, then disable the steppers, and my LowRider drops. If I press my $MI button mid-drop, the LowRider stops dropping. It’s as responsive as when I press the “Home Z” button mid-drop, except that not only stops the drop but starts raising again.

At least on my test, the Z stepper is getting power when I do $MI.

Seems to only affect the Z.

When you get a chance can you try tying them in the terminal. On my LR config (v12) $MD rarely worked typed in, it worked as a button a couple times.

So that means it might be fixed in V13 I have also heard no issues in V14. I will try it out when I head out to the shop.

Thank you thank you thank you for taking a look everyone.

For testing this way, is the #3 step below correct?

  1. disabling steppers (LR will drop)
  2. type $MI into command bar
  3. Try to manually lift gantry? Check for resistance?

I’m unsure of what I should be looking for.

I ran $MD, my LR3 dropped.

I manually typed $MI in the command bar, and then checked for resistance when manually trying to move the Z, and the Z stepper was definitely enabled and holding. The following showed in the command history area:

[MSG:INFO: X Axis driver test passed]
[MSG:INFO: X2 Axis driver test passed]
[MSG:INFO: Y Axis driver test passed]
[MSG:INFO: Z Axis driver test passed]
[MSG:INFO: Z2 Axis driver test passed]

That always shows correctly, just the Z steppers did not always disable and re-enable. Try both multiple times. Manually in the terminal, and buttons

Yes. On my LR config, sometimes the Z would not disable. On the MPCNC config it would not enable. Z only, very weird. I am assuming they fixed it. I will check newer versions soon.

Still happens on 3.7.13 for me.

I just tried a fresh esp32 and new board and drivers, MPCNC config.

$MD does not always disable the steppers.
$MI will enable the steppers sometimes and when it does the Z stepper is not enabled, even though the terminal says it is.

Just a thought, but have you tried it in STA mode? I use STA and it works for me.

If you’re worried about wifi or webui, skip all the tests through the webui and just use fluid term. If you still get the problem there, then it is probably not wifi or webui. If you really want to be certain, try it in the version where wifi is compiled out.

1 Like

I’ll be checking today. Yesterday I went down a bit of a rabbit hole trying to get my spare Jackpot board set up. I pulled off the USB-C Marlin test ESP32, and dropped on the USB-micro ESP32 that originally came with the Jackpot.

I couldn’t figure out why I kept ending up flashing Marlin onto it instead of FluidNC. Turns out it’s because I cheated and renamed the Marlin binary to match the name used by the FluidNC installer. Only took me a few hours to figure out my own stupidity.

Then, I had some weird issue going up to 3.7.13 / 3.7.14 candidate where I couldn’t get UIV3 to work correctly. Almost certainly something dumb I’m doing. So I’ll start picking away at the spare Jackpot again in a little bit.

1 Like

Did you delete the preferences.json? I had some strange behavior on one upgrade and deleting the preferences.json got things working again.

Yes, I tried that along the way and it didn’t seem to help.

Reports from today:

With the LR3 config.yaml file loaded, I"m able to repeat on 3.7.12 and 3.7.14 webui test there is misbehavior with $MI/$MD, but with slightly different observations than Ryan.

These tests were performed with fluidterm on USB, with my spare jackpot. It is a blue early revision Jackpot board, without the change to add a pull-up resistor. This has the USB-micro ESP32 in it that the jackpot originally shipped with.

On boot, both of these firmware version configure the TMC2209s on the jackpot, and I see the EN pin go to 0.0V.

  • Most of the time, the first $MD correctly inhibits the drivers and I see them all go to 3.3V. One time out of maybe 30 tries it didn’t, leaving the EN on all 5 TMCs at 0.0V.
  • Most of the time, the first $MI after that correctly initializes all of the drivers, and reports it as such. I got a couple of ERROR:1 results. I dont think i mistyped, but that’s a possibility.
  • Almost every time, the second $MD reports that it is disabling the drivers, but it does not, and the EN pin remains at 0.0V on all 5 TMCs,
  • After that, $MI reports that it re-enables the drivers. It isn’t possible to know if $MI worked as the EN pin never went to 3.3V on the preceeding $MD- so the EN signal didn’t change.
  • Sending $MD after the first failure to disables continues to report the drivers are disabled, but the EN pins remain at 0V. Not one time in about 30 did it go to 3.3V after it had failed to disable.

Rebooting the board by disconnecting the USB cable and then disconnecting jackpot board power then results in the next boot coming up and correctly enabling all the steppers. The scenario above then repeats.

All my tests were done with a DMM measuring the EN pin on the TMC2209s. I don’t have any steppers currently connected to my test jackpot. In the next day or so, I’ll dig into my box of old Lulzbot parts and fish out 5 steppers to hook up to this board so I can try to move the motors aside from just measuring the voltages.

One outcome of this testing is that I can say 3.7.12 and 3.7.14 webui3 test both have the bug where $MD does not always disable the stepper EN pin on the driver as measured with a DMM.

I did not see this with the DMM, as the EN pin always went to 0.0V on all 5 TMCs every time $MI enabled the steppers.

That doesn’t mean there isn’t a Z motor problem.
I’m not currently able to move any steppers as none are attached on my spare board. There could still be some kind of motion control issue where either the driver INIT over the UART fails, or perhaps one of the STEP/DIR pin doesn’t behave properly. I can’t really test this part with my setup yet.

Does anyone else have any suggestions for other things to try?

@vicious1, @MakerJim

I tried it again just now. I plugged in the USB and connected to the wifi. Then I powered up the board and steppers. I moved the motors, but they didn’t have the correct settings. When I moved Z 10mm up, it didn’t move the correct amount. I ran $MD and then $MI. All motors were active and I moved them. They all moved the correct amount. I ran $MD and then $MI. All motors were active and I moved them. They all moved the correct amount again. I ran $MD. I moved all the motors 10mm and they all moved the correct amount.
After the first $MI, I could run $MD and then move each axis without running $MI. They all moved the correct amount.
I have the newest version of the Jackpot and Ryan’s new ESP32 board.

Wow even on fluidterm…There is a bug for sure. I need to test that. I assumed it was a UI thing.

Thank goodness I am not crazy.

Hmmmm, this is odd.


Do you want me to try something else?

1 Like

can you get a $ss from the boot where it moves incorrectly?

This confirms my finding with the DMM that the 2nd and subsequent $MD commands don’t disable the steppers. This is a clear bug. It’s probably not the only bug at play.

It is very odd to me that we all kinda see different things. I am wondering if this is an $MD $MI issue or something else.