Add M3, M4 & M5 spindle/laser commands

[thinkyhead]

Rebase, cleanup of #6221 by @Bob-the-Kuhn

[Bob-the-Kuhn]

Should I close 6221?

[thinkyhead]

Either close #6221, or you could replace the commits in #6221 with this…

git remote add thinkyhead [email protected]:thinkyhead/Marlin.git
git fetch thinkyhead
git checkout spindle-2-nov-try-4 -b spindle-2-nov-try-4-backup
git checkout spindle-2-nov-try-4
git reset --hard thinkyhead/rc_spindle_m3_m5
git push -f

If that works, it's an interesting way to update a PR. But then, in that case, this might as well be a PR to your branch (esp. since you know how to squash commits).

[Bob-the-Kuhn]

Superseded by PR #6268

[thinkyhead]

This is #6268

[Bob-the-Kuhn]

Apparently I'm not fully awake yet. I've made a couple of silly mistakes this morning.

[thinkyhead]

@Bob-the-Kuhn

I'd like to find a way to get rid of lines like these in the pins files. We've been trying to make the pins files as agnostic as possible about what features are enabled, so they simply supply the recommended (or required) pins for each feature. We aren't checking the presence of a pin to enable code (as the old Marlin code did). We just check for the enabled feature, and then use whatever pins are assigned.

We've tried some different approaches to this, but generally the idea is to make sure we don't need a lot of #if clauses in the pins files that relate to features.

[Bob-the-Kuhn]

Do you want me to go through the files & eliminate the added #if clauses?

[thinkyhead]

Yes, let's just set the most sensible default pins, remove the #if clauses referring to the spindle-laser feature, and see what we have left in the pins files after that. There was a movement against requiring too many pin assignments in the main configuration files, which is why we started making the pins files more "exhaustive" on their own.

I'd say, for these pins, wrap each one in an #ifndef clause so they are easily override-able.

#ifndef SPINDLE_DIR_PIN
  #define SPINDLE_DIR_PIN 16
#endif

…etc.

We still haven't settled on how best to handle pin overrides. One universal method would be to have every pin definition be conditional on #ifndef, but that would add a lot of noise to the pins files. The extruder auto fan pins (E0_AUTO_FAN_PIN, etc.) follow a pattern that gives more control from the configs (since these pins also act as enable switches), but it's not the kind of technique you'd want to use for all pins.

[thinkyhead]

For reference, here's how I implemented laser (including software PWM) for the MakerArm branch:
thinkyhead@27eeca8

The branch has later commits expanding on the multi-tool idea.

[thinkyhead]

Split up the commit into 3 so it's easier to view the implementation by itself.

[thinkyhead]

@Bob-the-Kuhn I just did a rebase, so check the pins file and make sure it's intact, exactly what you want. Particularly the last several lines.

[thinkyhead]

This past week I implemented LASER using Timer 5 with a resolution of 80 levels of PWM current.

[thinkyhead]

@Bob-the-Kuhn

I'm getting this ready to merge. I moved the documentation from the lengthy comment in the configuration file to a Laser/Spindle page on the website. It's pretty much the same text, just reformatted with Markdown into a more readable form. The table, especially.

I'd like to have your opinion on how we might combine this PR with multi-tool support, which I've reduced to the main skeleton in this commit:

6c4b9ed

Mainly I want to include it because it implements the laser with some more options. It can be a simple on/off laser or one that operates with both a 12V on/off power pin plus a 5V 25KHz PWM signal pin. It also includes another simple "foam cutter" tool that operates with M3/M4/M5 — but it simply switches a 12V heater pin on or off (no PWM). Placeholders for other tool modes are included also.

[Bob-the-Kuhn]

FANTASTIC!!!