Standardize pinout alisases and store board config in a separate file

Features
1

Imagine a world where you don’t need to find the correct pinout for your board, imagine a world where you could build let’s say a Voron 2.4, download the correct config file for your printer, and have the choice of the control board independently of the printer config file. Just imagine :slight_smile: This is the purpose of this proposal.

What is needed :

  • Settle on a list of pin’s aliases. I’d use the existing Marlin constant names, like X_STEP_PIN, X_DIR_PIN, X_ENABLE_PIN etc…
  • Create a config file for each board klipper supports with pin aliases, for example (Generic SK3):

boards/generic-skr3.cfg

[board_pins]
aliases:
    X_STEP_PIN=PD4,  X_DIR_PIN=PD3, X_ENABLE_PIN=PD6, X_MAX_PIN=PC1
  • Create printer config files using only the pin aliases :
[include boards/generic-skr3.cfg]

[stepper_x]
step_pin: X_STEP_PIN
dir_pin: X_DIR_PIN
enable_pin: !X_ENABLE_PIN
microsteps: 16
rotation_distance: 40
endstop_pin: ^X_MAX_PIN
position_endstop: 0
position_max: 200
homing_speed: 50

Does it make sense?

2

The assumption with this approach makes is that someone who is replacing the main controller board will not be replacing anything else in the printer.

There are two (maybe three) problems with this assumption. The first is that the board will have the same functionality as the original. This is not realistic because a user may be replacing a board with enhanced capabilities compared to the original. An obvious situation would be replacing a main controller board with traditional EN/STEP/DIR stepper drivers with manually set current values (ie with a screwdriver) with one with TMS220x which can have the current set using a serial interface in the printer.cfg file.

The second issue here is that this approach makes the assumption that the user would only be replacing the main controller board and not touching anything else in the printer. If somebody is going through the hassle of changing their main controller board (even if the previous one is fried) they’re going to be changing out different parts of the printer as well - like going from a microswitch for the Z-axis endstop to a BL Touch.

Finally, I’m thinking back to one of the first times I replaced a main controller board in a printer (my old Sapphire Plus) and I found that it was more convenient to use different ports for different functions - ie rearranging the stepper port assignments simplified the wiring and, for the extruder, gave me some sorely needed extra slack.

Rather than relying on set configurations that somebody thinks is “correct” for a printer, I think that having a guided tool which creates a printer.cfg using inputs from the user regarding their printer set up would probably be more useful - but it would be a lot of work to build and maintain.

1 Like
3

This brought me nostalgic memories of when Plug and Play first came out in Windows 95.

Which immediately reminded me of the horrors in DOS with trying to get your new devices to work and having to mess with the Autoexec.bat and Config.sys

CONFIG.SYS:
DEVICE=C:\DOS\HIMEM.SYS
DEVICE=C:\DOS\EMM386.EXE RAM
DOS=HIGH,UMB
DEVICEHIGH=C:\DOS\ANSI.SYS
DEVICEHIGH=C:\CDROM\CDDRIVER.SYS /D:MSCD001
FILES=40
BUFFERS=30

AUTOEXEC.BAT:
@ECHO OFF
PROMPT $P$G
PATH=C:\DOS;C:\UTILS
SET TEMP=C:\TEMP
SET BLASTER=A220 I5 D1 H5 P330 T6
LH C:\DOS\MSCDEX.EXE /D:MSCD001
LH C:\MOUSE\MOUSE.EXE
LH C:\DOS\SMARTDRV.EXE

Edit: I just realized I’m old :cry:

2 Likes
4

To mangle an aphorism:

Some people are born old
Some achieve oldnees
Few have oldness thrust upon them.

5

There have already been a lot of discussions around this topic and unfortunately it is far more complex than it initially might seem. To list a few:

There are multiple challenges involved:

  • @mykepredko listed a few
  • RatRig already tried such an approach with their config. Nicely engineered but IMHO it leads to very obfuscated configs, giving the novice user a very hard time
  • Something most users are not really aware of: Most of the config settings are tied to the board and only very few actually represent the given type of printer. So, by far the asiest approach is:
    • Start a cfg with the bare board as basis, e.g. from the given examples or the board’s manufacturer GitHub
    • Add the few printer specific items like endstop positions, min / max movement ranges and accelerations / velocities from your current config
  • Yet another challenge is that you actually “modify” your board when pushing in stepper drivers. There are models using SPI or UART. Both scenarios lead to different pin usages and settings
6

I’m happy to see this has already been discussed. I did not find the previous discussions, sorry for reopening the discussion :slight_smile:

I guess where I could help is to add missing pin definitions in plain board config examples. My use case that triggered the proposal was “how can I bloody attach a bltouch to my ramp 1.6+ board and configure it in klipper” :slight_smile: Maybe it’s a too exotic edge case.

I still think that having the basic pins aliased (maybe simply in the top on the example files for each printer even if it means a lot of copy paste) would be of help for tinkerers. I think the boards config example files are a good place to document how a specific board connects to klipper.

But but but! “Always trust the community”, everyone here has more experience than me, so thank you for the feedback and explanations.

7

No worries. I think any discussion on how to make things easier for new users to set up their boards and printers is warranted.

Adding a BL Touch (and its clones and wannabes) to an existing board is not an “edge case” - it’s something that basically everybody will go through at one point or another and while, for most boards, it’s pretty straightforward to set up, there are some eccentricities (for lack of a better word) that must be navigated to get a specific device working in Klipper with a specific controller.

Maybe this is an area that AI could be of use - have it figure out the printer.cfg and wiring for a specific user configuration.

8

I don’t even know how this would be implemented successfully and it might be too big for the flash memories of a lot of mcus. But it would be pretty cool to have a build config option for board makers to use to preflash their boards with the board info.

In other words, pretty much what you’re saying directly from the OEM.

In other words, On connecting to Klipper it “reverse feeds” a data dictionary basically saying:

“Hi, I’m an EBB42 Board.
I have FAN0 on Pin PA1.
I have FAN1 on Pin PA2.
My Stepper Driver is setup like this:
Enable is on PA10
Step is on PA9
DIR is on PA8
UART is on PA13”

etc. etc.

Then you could just do

[fan]
pin: EBB42:FAN0

That’s probably a pipe dream, but would be pretty cool.
But that would assume board manufacturer compliance too which there is no way to enforce.

It would have to default right back to where we are now.
Plus, With how many board manufacturers screw up their own documentation I’m not sure I trust them to define their own board.

9

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.