[2.0.x] Macro G-codes

[revilor]

This PR adds g codes M810 to M819 which allow to define g code macros.

Example usage:

• Define macro 0
  M810 G1 X0 Y0 Z0 F200|G4 S10|G1 X10 Y10 Z10

• Use macro 0
  M810
  will enqueue the g code commands
  G1 X0 Y0 Z0 F200
  G4 S10
  G1 X10 Y10 Z10

Background: for my multi-material setup based on a Prusa stepper multiplexer and a self-designed 4x Y-Splitter I needed material change procedures which are more complex than what M701 and M702 provides. As it is a very specific requirement for my setup it makes no sense to extend M701 and M702 accordingly. Instead I added a way to create macros which may be a useful feature for other Marlin users and different use cases, too.

[Sebastianv650]

Just because I'm curious: Wouldn't it be easier in your case to use slicers gcode on tool change section?

[revilor]

@Sebastianv650 I did exactly that so far. But let me add two more pieces for the complete picture. First, my printer has interchangeable hotends, and a E3D Volcano requires a different material change procedure than a regular E3D hotend. Second, there is a post-processing script involved which adds all the required purge tower stuff to the g code generated by slic3r.

The script does automatic placement of the towers and I want the tool change to happen at the position of the purge towers. So far I used self-defined placeholders in the slic3r tool change g-codes which were replaced by the post-processing script with the coordinates of the purge towers. But this way the script has to scan lots of g code lines for the placeholders to replace them. To fasten things up I decided to have the script handle the complete tool change/purge tower procedure. That's where the g-code macro idea came into play because this way the script just places a single M810 when the material change should happen. What M810 means for the current print is defined in the slic3r start g-code section.

Maybe this macro stuff is complete nonsense, and I'm not sure it's a general purpose feature for Marlin, either. But it's implemented now, so if anyone has use for it, there you go.

[thinkyhead]

Hmm, I see that actually this cannot work without further additions.

First of all, if you use enqueue_and_echo_command and the command queue is full, the command will just be dropped.

If, as I attempted to do, you instead use enqueue_and_echo_command_now and the queue is full, the machine will go into an infinite loop and stop. This is because the next command cannot be removed from the queue until after the M810 command has returned back to the main loop.

The correct way to deal with multiple commands is to use enqueue_and_echo_commands_P, which will drain them as part of the main loop. But there is no equivalent function taking non-PROGMEM strings.

So, in order to support this feature, the G-code core parser would need to be extended with an additional variable (injected_commands_SRAM) to contain the multi-line command to be queued by the main loop, and an additional function call (drain_injected_commands_SRAM) would need to be added to get_available_commands.

[revilor]

@thinkyhead thank you for the feedback. I'll have a look at enqueue_and_echo_commands_P and will implement an SRAM equivalent in the way you suggested.

And I understand from your changes that configuration for this kind of feature should be placed into Configuration_adv.h and not Configuration.h. I'll keep that in mind.

[thinkyhead]

Most new options should go in Configuration_adv.h. The main configuration is gradually reducing to the settings that apply to most typical setups.

[thinkyhead]

@revilor I've finished this up but haven't yet given it a test run. Have a look at your earliest convenience. If it works as-advertised then it can get merged soon.

[revilor]

@thinkyhead I've been working on more complex extension of the command queue. To not mix it up with this PR I created a separate PR #9479. I can of course also integrate my queue extensions into this PR in case you prefer it that way.

[revilor]

@thinkyhead Thank you for your latest additions to this PR, everything works fine for me. Feel free to merge and deal with PR #9479 independently.

[thinkyhead]

I can of course also integrate my queue extensions into this PR in case you prefer it that way.

Let's keep that separate. It needs to be more carefully considered. We have very limited SRAM to use, and the current PSTR-based method works well to keep RAM use low. A "command stack" is going to involve another large, persistent buffer, which never makes us happy. Obviously for 1284p with its generous 16K or SRAM, no problem. But most of us are still using Mega2560, and are already very close to limits.

Use M100 a lot to evaluate its behavior.

[dot-bob]

I have most of my printers are tuned very similar and can use the same print profile other than the start and stop g-code. I have been toying with the idea to have the start and end g-code of each of my printers embedded in the machine/firmware.

This may be a good use case for this pull request. I could embed M810 in my start script and M811 for my stop script. This would make my sliced g-code universal across all my printers similar to tool paths for CNC.

[thinkyhead]

I've rebased this and updated the code to use the process_subcommands_now method, added by @marcio-ao quite a while ago. This method will run everything in the macro immediately, ahead of anything else that might have been added to the queue before the M81x command gets to the front of the queue. So it effectively makes M81x an alias for the commands it contains.

Also:

• Updated all example configs added since this PR was introduced.
• Moved the Travis CI test into the Teensy tests file (which has the fewest tests).
• Moved the example config updates to a separate commit.

To obtain the updated code in your working copy…

git fetch origin
git checkout macro-gcodes
git reset --hard origin/macro-gcodes