Nope, everything in your file is the same as Ryans except this:
1 Like
ABC all share a lane they are all 1,3 but have a CS pin address.
Thank you. Won’t change that then.
Can someone bake up a config file that doesn’t talk to the drivers at all?
It is possible they are affecting the power, or shorting something.
Or they are perfectly fine, and when they are present, the esp32 does something else and that causes it to hang.
If we run fuildnc with the same electronics, but configured to ignore the tmc uart, and it works, then we have even more evidence to scratch our heads with.
You can take the esp off the jackpot and test it that way.
Let me try
No, that won’t test the electronics. I was thinking the exact same electronics, but none of the SW logic trying to talk to TMC.
O.k. so, drivers installed, but no boot, but when fluidterm starts, it boots. Is there a way to get a log file of before fluidterm connecting?
config.zip (1.3 KB)
This boots with no errors for me, Cleared out all drivers.
@dgkeith237 do you have anything else plugged into your board whatsoever other than power and USB (and the drivers)?
If so unplug it all.
Probably not without custom compiling FluidNC to redirect output to the SD card, and storing all messages up to the point where the SD card is initialized into a buffer to be written.
Of course, that’s assuming it gets far enough to get the SD card initialized properly.
Other than that, USB terminal is the only way, but I think the USB connected causes his problem to go away
Bingo - that’s the problem. The one thing I could do to try and see what’s going on fixes the problem and the boot log looks fine.
I did sneak out and put the testconfig.yaml on the board and it boots fine as long as I don’t install those drivers. If I install both drivers it does not boot.
Then I needed to get back to work… sorry. I still need to determine if I could boot with one of the two, if I could still boot with RST. All sorts of testing.
The only thing currently connected to the board are the end stops. I’ll pull those too in the next round. I couldn’t get my fingers in to pull the drivers with the motors plugged in, so I had already unplugged them.
The USB is currently not plugged in (and has not been since I pulled the drivers initially this morning.)
Interesting. So not stepper related. Firmware doesn’t seem to change it. I need to test that a bit for more info myself.
Yes please unplug the endstops.
Okay so even with the test firmware the drivers still get enabled automatically. Should not do much if a stepper is not plugged in (not pulling much extra power).
SO now I have another test firmware idea. Make sure they do not enable at boot. Give me a few minutes to try another one.
So here is one with the drivers still defined but not power to them at boot,
config2.zip (1.5 KB)
That seems like a huge hole in the FluidNC debug capabilities. When it fails to boot all the way up is when you most need to dump the log to some kind of serial output or persistent storage. Even just blinking out a fail pattern on a LED would be better than nothing.
Honestly, I knew it was a longshot when i asked. I really in my head could not a think of a way it could. Think of all it already is doing.
There is no change with that firmware. It won’t broadcast with a driver in either spot.
The power supply also arrived. I get the exact same behavior on the 24V PSU that I purchased from V1E. No boot with drivers in Y1 or Z1. Boots fine without drivers there but with the other spots filled.
Specifically I see in the firmware that it is labeled Test2.
I also see that there are still idle values. Is it that the drivers are not initialized?
What’s the source of the drivers? Are these the ones that came with the board from Ryan?
Is it the individual driver? Or is it the slot?
I take it as all 5 drivers work in any combination of X, Y2, or Z2, but any of them in Y1 or Z1 make it fail? Is that correct?
As of right now, we don’t know exactly what’s causing it, and it seems like a hardware issue and it’s not booting up. If it’s not booting, then the software isn’t running. We can’t blame the software if the hardware won’t allow the software to run.
FluidNC has the ability to log to a terminal on boot, and the messages are stored in memory. It just so happens that in this particular edge case, connecting the terminal makes the problem go away. I’m would guess this is something that they haven’t run into often, if ever.
These are the drivers that Ryan shipped with the board. Out of curiosity, I did put a new one (from V1E) in and it prevented boot. All drivers seem to be able to be swapped into any of the X, Y2, and Z2 spots.
Out of curiosity I subbed in a TMC 2209 V1.2 that came with my SKR Pro. Same result. It’s gone - back to the box with the SKR. (I straighten the UART pin, so I’m sure it was not touching anything.