So a test print failed due to layer shifting which indicated a stepper/driver issue. At first I tried reducing the speed and acceleration settings and as expected it made no difference. After reading the klippy log it seems the drivers aren’t initialising in UART mode.
I have the board logic set to 5v, is this right for UART mode?
The board came with two trees V2.0 tmc2209 drivers even though it’s an MKS board, I don’t know if that matters. I have checked the pinouts on the MKS and two trees TMC 2209 drivers and they are labeled differently but the UART pins seem to be in the same position on both of them.
I’ve read quite a few other posts about this type of issue and they seem to suggest incorrect jumper settings or wiring which I’m (almost) certain is not my issue.
I did a DUMP_TMC on all the drivers if that’s any help, it’s in the klippy log
I’m not sure what else to check, any suggestions would be appreciated.
I did see that failed to init line in the log a few times for all the axes but there was no error reported during the print through mainsail.
It was only layer shifting on the Y axis, so I suspected the run current could be a bit low for it too. It has a glass ultrabase on it & it weighs a ton.
I rebuilt the whole thing as a standalone to get the board out of that dinky little box and so I could design it with better airflow to the drivers, so now it’s setup with a fan blowing directly at the stepper drivers and it has really good airflow across the drivers and their heatsinks and they’re staying cool to touch when the layer shifts occur.
The motor on the Y axis is running cool to touch too, so I was planning on increasing its run current in small increments but I thought I’d check the log for any problems first.
Something didn’t sound right on that axis though, I can hear it when it changes modes and it gets much louder than it did with an MKS Gen L and TMC2208 drivers. It doesn’t feel like it’s binding when the motors are off but I’ll strip it down give everything a good inspection.
So I’ve double and triple checked the jumpers and there’s no wiring to be done so it looks like I’m in no mans land. The printer has been power cycled quite a few times too so from what I’ve read the drivers should have reset if they were programmed in a different state when I got them.
All I can think of is setting just one driver to run in UART mode and try to get it to initialise to eliminate any possible addressing conflicts and maybe assign an address to each driver if I can get one running properly. Maybe I’ll just be on a wild goose chase doing that, from what I’ve read and been told here I shouldn’t need to assign an address to them.
Maybe the log will reveal something if I run it with only one driver in UART mode. If I see anything noteworthy in the log I’ll post it here.
Edit: If I jump the diagnostic pins does that generate a hex dump through UART or SPI or is it readable information that will appear in the klippy log?
I haven’t included any macros myself, I think they’re the ones from the mainsail config. I suppose I could backup that file and modify it but I didn’t want to play with that unless it’s absolutely necessary.
I’ve read quite a few of your posts about the Robin nano over the last week or so and my setup was based on some of the information you’ve posted.
So I removed all the jumpers on the UART pins except the one on the Y axis and edited my printer.cfg to remove the UART config for the X,Z and extruder and ran a DUMP_TMC on the Y axis which seemed OK.
Then I ran a test print and downloaded the klippy log and there is still a failed to init message for the Y axis when it’s only running the Y axis in UART mode.
It caused a crash on X max and stretched the X axis out by a factor of 2 (just guessing that figure) so it needs a different config on the X rotation or microsteps. That was purely operator error on my part and a lack of due diligence there.
Edit: I replaced the X UART jumper and config settings, the DUMP_TMC seems OK for the X driver too. Now I have two failed to init messages, one for the X and one for the Y.
I’m at a bit of a loss to understand exactly what’s going on, I can hear the motors change tone as the drivers change step modes and the DUMP_TMC seems OK, so it appears to be working as intended, it’s just that failed to init message bugging me & I’m not sure if I have control of the motor current through the UART settings. The drivers are on their own control pins, so it really shouldn’t be an addressing conflict as I understand it.
I’m tempted to replace the board with an SKR E3 mini V3 I have in the parts bin which is hard wired for UART out of the box just so I have something to compare the log to.
The first is, I run the TMC2209s on 3.3V, not 5. I’m wondering if this is your issue.
Secondly, you can see that I’ve jumpered three of the pin sets and not one. I know there’s a reason for that but, for the life of me, I can’t remember what it is. It may be unimportant but it’s a visible difference.
I know the board I’m showing you is a 3.0, but the motor socket wiring is identical between it and the 3.1.
I suggest you try changing the TMC2209 voltage selection and if that doesn’t fix anything add the additional jumpers on each socket.
Thanks @mykepredko, I’ll try the voltage setting first & then I’ll try adding the other two jumpers like you have yours set. I’m in a habit of only introducing one new variable at a time so I know what to suspect if a new problem arises.
I did mention the voltage earlier but no-one else mentioned it, I suppose they already have enough on their plates reading through everyone’s klippy logs and and analysing them…
I don’t know how they find the time to do it all TBH.
Cheers.
I marked your post as a solution, thanks @mykepredko .
I changed the board voltage to 3.3v and just left it with a single jumper on each UART pin.
A search through the log shows the failed to init message up to the point where I changed the board voltage and then that message never appeared again.
I don’t know where I got the idea to set it 5v to begin with, I must have read several thousand pages of text in the last week and made a false conclusion based on something I read.
Thanks for the help guys.
Good to know and thanks for sharing.
Although it is quite strange: VIO for these steppers is indeed between 3V3 and 5V and somewhere I read that 5V is indeed preferred but I do not know exactly why.
I run my board with 5V and never had issues with it.
Do you have a reference for that? I’ve never seen anything indicating that one voltage is “preferred”.
I just did a quick scan of some different controller board schematics that I have handy and there’s a mix of VIO at 3.3V and 5.0V:
Robin Nano V3.x - 3.3V or 5.0V
Octopus (Pro) - 5.0V
Manta M8P - 5.0V
EBB42 - 3.3V
The TMC2209 datasheet indicates that VIO needs to be in the range of 3.0V to 5.25.
I believe the real issue is what the MCU’s IO pins can handle with respect to the logic levels and whether or not there needs to be in line current limiting resistors to avoid the IO pins’ ESD protection diodes from being saturated (and affecting the operation of the MCU) when driving them at 5.0V.
But, that theory doesn’t quite hold water when you look at something like the Manta M8P (VIO 5.0V) and the EBB42 (VIO 3.3V) which both use variants of the STM32G0B1 MCU.
Regardless, in this case (Robin Nano V3.x) , the TMC2209s have to have a VIO of 3.3V.
After that epic thread with Gene about the same board I bet when you first saw my post, you were thinking - here we go again., maybe it’s time for that vacation on Mars.
After several days trying to isolate my problem I was thinking maybe I need a vacation on Mars too when Myke suggested such a simple solution.
I really appreciate you guys tolerating my incompetence, thanks for the help.
