Docs: prefer Marlin (legacy) over Marlin 2 where available

[strayr]

Marlin 2 option in prusaslicer produces gcode with an M204 that Klipper doesn't interpret correctly

[JamesH1978]

Thankyou for submitting a PR, please can you refer to https://github.com/Klipper3d/klipper/blob/master/docs/CONTRIBUTING.md paying particular attention to the signed-off-by line.

Thanks
James

[strayr]

Sorry, the notification about this disappeared into the ether. I've cleaned this up down to one commit and sorted the sign-off, and cleaned up the commit messages. Was a very quick "arrgh, why am I still answering these support questions" fix and i should have taken more time.

Not sure if I should call out Prusa Slicer by name as needing Marlin (legacy), or that's going to age badly?

[Sineos]

prusa3d/PrusaSlicer#3452 (comment)

There is hope 😄

[KevinOConnor]

Thanks. I don't really have an opinion on this change. Maybe @JamesH1978 or @Sineos can provide their feedback.

For what it is worth, it seems kinda confusing to say "use marlin or smoothieware" - wouldn't just saying "use marlin" be simpler for users?

-Kevin

[strayr]

I don't know the history of why that was originally chosen. I think it's there because smoothieware turns off machine limits sections in prusa slicer, at which point if there's a good use case for it remaining then we should explain why rather than give users a blind choice.

More invasive to as it changes a few lines of toolhead.py but how would you feel @KevinOConnor about handling prusaslicer's marlin 2 output with lone M204 P without an M204 T by setting the P value as acceleration? It would take a slightly cryptic step out of setting up slicer profiles for Klipper and make klipper a little more slicer agnostic. Yes, that could be done in a macro, but that would be a much bigger user task than setting up a slicer profile and this behaviour is most painful getting up and running. I don't know if that would break output from another slicer or if there's another reason why we don't do this?

I'm all for further simplifying the docs and going with the following, particularly as there's a chance prusaslicer will have some level of klipper support soon.

Many slicers have an option to configure the "G-Code flavor". Choose Klipper if available, otherwise choose Marlin, preferring Marlin (legacy) over Marlin 2

or even 

If you can set the G-Code flavour, choose Klipper or Marlin (legacy) 

and hope users are smart enough to figure out that Marlin is a good enough match if not given the choice.

I went for the change proposed as it was the least invasive change that could make a positive difference. I'm happy to do more if its a BETTER solution.

[strayr]

https://github.com/prusa3d/PrusaSlicer/releases/tag/version_2.6.0-alpha6

Yeah, this changes quite a bit.

[github-actions]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review
   If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[github-actions]

Unfortunately a reviewer has not assigned themselves to this GitHub Pull Request and it is therefore being closed. It is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[Piezoid]

I accidentally made M204 P/T work while moving the acceleration state from toolhead.py to gcode_move.py. This makes acceleration behave more like the gcode velocity.
It's a major change that will have implications for numerous extra modules, but I can tidy it up for upstream if you're keen on this approach.