I suppose I can try this again with the MPCNC config on my test board. If I can’t get to it tonight, I’ll do the test tomorrow.
I’m going to put an order in this evening and will be picking up some V1 ESP32s. I’m planning to break out the CP210x UART GPIO and might play with making a test harness so that I can measure all of the enables under automated control. I’ll probably also modify a set of TMC2209s with long pins on the headers so that I can land logic analyzer and those GPIOs I mention above.
Everything inits OK with this config on boot.
If I then send $MD, all 5 drivers EN goes to 3.3V, and things are disabled.
I then send $MI, and all 5 drivers enable and the EN goes to 0.0V
I send a $MD, and the Z position EN pin on the jackpot stays at 3.3V while the other four go to 0.0V!
This is repeatable, I’ve now done this 15 boots in a row, and had this result each and every time.
Yes, this is quite weird. You have a board where the TMC driver UART communication is not working at least some of the time.
This means the TMCs should run with their default stored configuation, or if board power has stayed on they will stick with the last commanded settings.
Have you ever replaced/swapped a TMC driver on this board? It acts like you have one TMC driver with different stored settings than the others.
When this driver init failure happens, it seems FluidNC is still toggling the ste/enable/dir bits even though the driver init failed. That doesn’t seem right! More and more curious as we go.
I have 6 TMC drivers installed. The A axis is my rotary.
It only does the ERR: TMC driver not detected if I plug in the USB first. If I power it up and then plug in the USB it doesn’t show that error. I can run $MD and $MI without any errors.
I just retried $MD and the motors weren’t disabled. IDK!!!
OK, this part may be expected. There’s a diode on the Jackpot that prevents the board from being back-powered by the ESP32 USB as the USB port can’t source enough current to run the electronics.
If you power up the Jackpot board after connecting USB, but don’t do a $MI, then the TMC drivers will run with whatever their stored settings are. So your system not moving correctly at this point is actually somewhat expected. The perhaps mildly unexpected part is that FluidNC still sends EN/STEP/DIR for stepper drivers that are defined but which failed to initialize. I’m not sure this is intended behavior.
The question is, if you connect the USB, then apply Jackpot board power, then send $MI, then I think FluidNC is expected to be able to initialize the steppers. If you follow this sequence and then try motion, does it move correctly for you?
I’m realizing that $SS is only reporting the initial boot and doesn’t reflect the changes made along the way.
I did some more testing on this yesterday, after I received a shipment from V1.
I now have two test jackpot boards, and older blue one and a shiny new black one. I also have a collection of ESP32s. This includes USB-C, a no-name clone, the V1E white test ESP32, and a genuine ESP-32 dev board.
My test setup had the blue and black Jackpots, and all of the ESP32s described above. I tested 3.7.8, 3.7.12, 3.7.13 and the webuitest version of 3.7.14.
ALL of these various configurations are repeatable for me with the bug we’ve seen, which to summarize looks like the following: (LR3 config.yaml)
Power on a board from the external power supply. Board initializes fine. All stepper drivers enable.
Connect FluidTerm so I can watch all of this…
Send a $MD- all of the steppers disable as expected.
Send a $MI- all of the motors enable as expected.
Send a $MD- none of the EN pins on the TMC2209s toggle, they stay at 0.0V
Send a $MI- FluidNC reports the drivers have all initialized correctly, but I can’t notice any change- driver ENs were already at 0.0V
Send a Control-R (Restarts the MCU)- system resets, and FluidNC comes up happy.
Send a $MD- FluidNC reports the drivers are disabled, and I see the TMC2209s EN toggle to 3.3V
Repeat the rest of the sequence as above, and the behavior repeats.
I don’t see how this can be anything but a bug in FluidNC.