Cannot set custom pin mappings when upgrading to 2.0
I get the error "Alias z2_step_pin mapped to PE6 - can't alias to PF9" when I actually do try to use PF9 as the z2_step_pin. This worked ok with Ratos1.x, but seems 2.0 is not exactly the same.
18 Replies
yeah, you should not be redefining aliases. Just directly use the pin name in the config where needed instead.
DO NOT DO
x_step_pin=PF13
WHAT YOU SHOULD DO
SOMETHING_pin: PF13But the thing is that I specifically want to redefine/change the alias. One of the driver sockets on the octopus pro board does not work, so I need to use another one. That should be possible just by changing the aliases, as the aliases are used (or at least should be used) in configs, not the pin names themselves. Or would there be a better way to select another socket to use instead of the broken one?
Just write out the stepper and tmc section in useroverrides with the new pins. No point in trying to modify the alias, you can't just override single pins, it's the entire alias or nothing.
I did override the whole alias, just with a few pins redefined, i.e. most pins were just copies of the originals. But fair enough, I will work around this some other way. It might have been interesting to understaind why the same approach worked fine with 1.x but not w 2.0. But I’ll survive without that piece of info 🙂
It does work with 2.0, it's just bad practice
the reason you're getting an error is because you didn't use the correct alias. You're including the octopus 1.1, but the alias you copy pasted and modified is for the octopus pro 446.
Yes, I noticed and fixed that, thanks for looking into this! My board is 446, so I am not sure where I got the 11 from, user error would my guess 🙂 The overriding works as intended. About the best way to select another driver socket: I would say it is a judgement call. For me, personally, since I do not know all the places where the alias is used now or in the future, the path-of-least-surprise would be to change only the alias. That way I cannot accidentally miss an override I should have done, and the change is only in one place. For others better aquainted with how the value is - or will be - used it might be better to explicitly override the specific values, as overriding the alias means that everything in the alias will be overridden.
I think this is a bit different from just using a custom pin to drive a fan, where changing the alias brings no value.
For me, personally, since I do not know all the places where the alias is used now or in the future, the path-of-least-surprise would be to change only the alias. That way I cannot accidentally miss an override I should have done, and the change is only in one place.I understand the train of thought here, but it's actually the other way around. If you override the entire alias you risk bricking your setup in a future update. Let's say i change the naming of the uart pin aliases, because they're also used as cs_pins. Now your config is dead. If you just overwrote the tmc and stepper sections with the pin name it would continue working.
Regardless, soon it'll be as easy as this, and nobody will have to worry about that anymore 🙂
For corexy can you use A/B motor naming? People get confused since it is named x and y that only one motor controls x or y when actually both are needed
Technically yes, but klipper doesn't, that's why i have the description there
It's confusing for sure
unfortunately there are no [stepper_a] and [stepper_b] in klipper
Yeah, but you're abstracting that away aren't you?
For the interface yes, i can write anything i want, but the config wouldn't make sense
It's still klipper afterall
Lol, no one be looking at the config afterwards!
I wish 😄
Not quite there yet, but trying 😄
Anyways I've hijacked this thread enough
No problem, good discussion! Ok, got the point about the alias not being the ”immutable API”, I was indeed making an assumption where I should not have. (Note to self: stop doing that). And I guess I be no one, since I do look at the configs afterwards 😁. I’ve klipperized my earlier marlin-base printer from scratch, and wrote custom klippy modules, so I do appreciate keeping RatOS compliant with the vanilla klipper, even with its quirks. The slot selection looks awesome!
Awesome! Thanks for the feedback 🙂 Hopefully 2.1 will feel like it's closer to "normal" klipper configs but at the same time way easier to set up and modify than it was in 2.0 🙂
The biggest critique i've had (at least that's what i've personally taken from it) is the abstraction layer (the includes and the pin aliases), so 2.1 tries to do away with as much as that as possible.
Ok, will be interesting to see how you’ll pull that trick 🙂