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 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.
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:
$MI
[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]
ok
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.
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.
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.
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.
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?
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.
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.