There’s an inconsistency in how board_pins aliases work compared to regular pin names. In short, this works: [tmc2209 stepper_x] uart_pin: PC11 [tmc2209 stepper_y] uart_pin: PC11 But this doesn’t. [board_pins test] aliases: x_uart_pin=PC11, y_uart_pin=PC11 [tmc2209 stepper_x] uart_pin: …

The alias function is implemented pretty rudimentary only. There are numerous posts here that discuss similar topics: [image] Intentional or an aliasing related bug? Developers I had originally posted this in the general discord, but it wa suggested this might be a better…

I am aware, and there hasn’t been a sufficient answer before either. This is weird, confusing, and resembles a bug, more than something intentional. It’s not explained in the docs, and no sufficient workaround is offered. Furthermore, it seems like the primary reason nothing has been done about this…

Best thing to do is to check with @koconnor . If you read the other threads his enthusiasm to change this seemed, let’s say, “limited”. For me personally the aliases could go away altogether. It just obfuscates the configuration and the only goal that RatOS reached was to make the cfg completely inc…

Best thing to do is to check with @koconnor . Hence the post. For me personally the aliases could go away altogether. Honestly, that would probably be better than the current situation. It would’ve prevented countless new users from learning klipper though. Having aliases allow for abstraction…

I copied your example board_pins alias into my srk-mini-e3 printer config and it works for me. If there’s an error you should attach the full Klipper log file from the event (while running the pristine Klipper code). -Kevin

You’re right, my sample code was incorrect. [board_pins test] aliases: x_uart_pin=PC11, y_uart_pin=PC11 [tmc2209 stepper_x] uart_pin: x_uart_pin [tmc2209 stepper_y] uart_pin: y_uart_pin Should do it. There are no modifications to klipper in RatOS. There are a few extras though (gcode_sh…

Okay, but an error is the intended response in that case. It’s not possible to use the same pin for two different modules, unless those modules have been explicitly coded to handle the complex synchronization necessary to “share” a pin. I know that is confusing for users, because they think “it’s …

I would also add that I’m not sure what the gain of x_uart_pin and y_uart_pin aliases that point to the same pin is. Ultimately one would still need to declare different uart_address fields anyway. So, these boards can’t be treated as similar regardless of pin aliases. Cheers, -Kevin

Thank you for taking the time to explain. I’m with you, i understand the problems you’re listing, I just don’t understand why the alias lookup has to interfere with any of it, since it works fine without aliasing. No alias) Pin PC11 → We’re already using that → Special behavior Expected alias beha…

[image] miklschmidt: You don’t need to contact the micro controller to resolve an alias, it’s a simple map, right? Why isn’t that a step before the pin validation that happens anyway? The simple answer is, “it wasn’t implemented that way”. Ultimately, the micro-controller is not sent a pin n…

BUG: Multi use pins / shared pins don't work if aliased

General Discussion

Sineos December 4, 2022, 5:24pm 3

The alias function is implemented pretty rudimentary only. There are numerous posts here that discuss similar topics:

Topic		Replies	Views
Intentional or an aliasing related bug? Developers	7	1581	January 13, 2022
Multiple aliases referencing the same pin Developers	3	2272	April 26, 2022
Reworking example config files to have pin aliases at top of file Developers	20	5722	December 23, 2022
Pin aliases bug, please reopen issue Developers	1	355	July 26, 2025
Standardize pinout alisases and store board config in a separate file Features	8	315	July 16, 2024

BUG: Multi use pins / shared pins don't work if aliased

Related topics