Marlin

Marlin copied to clipboard

Description

This is a documentation-only PR to improve comments relating to DEFAULT_MAX_FEEDRATE in order to reflect the impact of XY values on INPUT_SHAPING ram usage.

There are ZERO code changes in this PR.

Requirements

No.

Benefits

Improved documentation, easier configuration by users, avoiding research and false starts at alternative memory optimisations.

Configurations

N/A

Related Issues

None.

technically Note: should be NOTE: like the others.

@classicrocker883

Actually in Configuration.h there are 8 cases of "NOTE:" and 10 cases of "Note:" (excluding this one).

I have no axe to grind either way - and since this is a documentation only PR I don't mind whether I leave it as is, change just this new "Note:" to "NOTE:", or make the entire file consistent to one or the other.

But since it is unclear, I won't do anything until there is a consensus on which way to go.

Adding a note to the Input Shaping-specific section (or Marlin’s hosted docs instead if not already mentioned) might be a better idea since we can call out other config items that can affect RAM usage like microstepping, steps/mm, etc. instead of sprinkling Input Shaping comments all over the config files.

@thisiskeithb Yes - I fully understand the issue of comments creep. However I submitted this based on my own learning experience, whereby despite having read the online docs before enabling input shaping, it took me a while to work out why my firmware was rebooting. I still believe that a hint here can be very beneficial to users, though I can certainly shorten it to one line that summarises the issue and points to documentation.

This note is good in that is says this effects RAM usage, but it doesn't explain how. So for someone with ram issues, should they increase or decrease here. This is a common piece of info missing in all the ram usage warnings in Marlin that makes them minimally useful.

Thanks for this! I know from a users perspective it is easy to assume lower value always decrease ram usage, but this isn't aways the case, which can be confusing. For example when the configurable values represent precision thresholds. IMHO this is very helpful.

I still think that adding a note to the Input Shaping-specific section (or Marlin’s hosted docs instead if not already mentioned) would be a better idea since we can call out other config items that can affect RAM usage like microstepping, steps/mm, etc. instead of sprinkling Input Shaping comments all over the config files.

@thisiskeithb I genuinely understand where you are coming from:

1. Because the code could get inundated with comments addressing tiny minor issues; and equally
2. Because the Input Shaping web page should indeed have everything there is to know about it (which I agree with).

However, I personally feel that this area is important enough to justify both a code comment and something on the Input Shaping web page.