Skip to content

Documentation/Configuration Validation #3

@shaneodd

Description

@shaneodd

The issue I would like to raise is in regards to the documentation and configuration validation.

I was upgrading the version of klipper and beacon firmware. In the past I had issues upgrading klipper so I usually spend a bit of time making sure what ever new I am trying to do exists before committing fully to updating all the configs. My first change in the configurations to make sure things may be good was drop the ol' home_method: contact in my config. If everything updated I was going to expect it to complain about safe_z_home or complain about other missing config entries. Instead I got Option 'home_method' is not valid in section 'beacon' this leads to setup issues not I am missing a config entry when reading the error message.

Here are some suggestions

  • On the config validation maybe throw some logic in there. People may be starting with an existing config
  • Call out the brand new items to point out the minimal configs. IE home_xy_position got rid of "the not valid error"
    • home_xy_position - this appears to be required
    • home_method: contact - this and the other 2 home_ configs might be new for contact.
  • On the Print Start GCODE, I would suggest calling out specific items needed. My Start config does not look like this, it is broken out. For example here is a similar config to what I have: PRINT_START
    • M109 S150 might be an item to call out, I did not have this setup, there are things to look out for here.
    • I would Highlight the G28
    • The SET_GCODE_OFFSET are something new as well.
  • contact_max_hotend_temperature - this took a bit of trial error to get working, might be due to my configs not originally having a probe temp. Not sure what to suggest here since I have not gotten my brain wrapped around it yet.
  • I would also would like to mention maybe run through configurations and just omit stuff and see what errors you get. This could help with a troubleshooting section and maybe help with seeing what errors are not being handled.

Notes for highlighting and ordering of docs

You could utilize the diff syntax highlighting within markdown, for example showing that the config they may already have within safe_z_home would be moved to the beacon config would be a good way to help people understand that change. It would be a visual change, it highlights what is new, existing and removed

[beacon]
+ contact_max_hotend_temperature: 180 # increase to probe at print temps

+ home_xy_position: 117.5, 117.5 # update with your safe position
home_z_hop: 5
home_z_hop_speed: 30
home_xy_move_speed: 300
+ home_method: contact # use proximity for induction homing
+ home_method_when_homed: proximity # after initial calibration use induction
+ home_autocalibrate: unhomed # contact will calibrate beacon on first home

-[safe_z_home]
-home_xy_position: 117.5, 117.5 

When putting describing something new ordering the config to have new things in a specific spot. When something could be in a config already do not mix new and old. What is there now you have new configs, some items that exist and then new configs.


[beacon]
contact_max_hotend_temperature: 180 # increase to probe at print temps

home_xy_position: 117.5, 117.5 # update with your safe position
home_z_hop: 5
home_z_hop_speed: 30
home_xy_move_speed: 300
home_method: contact # use proximity for induction homing
home_method_when_homed: proximity # after initial calibration use induction
home_autocalibrate: unhomed # contact will calibrate beacon on first home
[beacon]

home_z_hop: 5
home_z_hop_speed: 30
home_xy_move_speed: 300

contact_max_hotend_temperature: 180 # increase to probe at print temps
home_xy_position: 117.5, 117.5 # update with your safe position
home_method: contact # use proximity for induction homing
home_method_when_homed: proximity # after initial calibration use induction
home_autocalibrate: unhomed # contact will calibrate beacon on first home

You may be bouncing up and down and screaming "RTFM! RTFM!" while reading this, well that is part of the issue. People are quick to say this and share links to documentation with no additional information. Take a good hard look at yourself if you do this. Usually when working with new features I will step through all the configurations once I know I am not chasing something not being installed. The error would lead someone to thinking they did not install something correctly.

You eat an elephant one bite at a time.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions