RepRapFirmware allows for gcode sequences, called macros, to be stored on the SD card. these macros can then be called by using M98, for example:
Macros can be called from any source of gcode: the console, from a gcode printing off the SD card, from the PanelDue and from another user or system macro. Duet Web Control makes it easy to upload, edit and create new macros.
Macros also allow for naming gcodes with easier to remember names. For example you can create a Macro for "Allow Cold Extrude" to call M302 P1.
The macro folder can divided into sub directories to more easily organise your macros by type.
For more information see Setting up macro files for common tasks.
System files are also effectively macros, for example homing files are a sequence of gcodes to run the specific homing sequence for a specific printer type. See here for information on using tool change macros.
The RepRap wiki also contains a page of useful macros.
RepRapFirmware configuration tool will produce appropriate system macros for most basic printer types. These are generally a good start point.
There are a couple of github repository for macros; see here or here. They are a work in progress. Please submit pull requests or comment on the forum if you have example macros to share.
Macros can be used to complement printer "start gcode" and "end gcode", for example if you have different printers, with different start and ends sequences, but you want to use the same sliced gcode, you could use:
see Filaments, specific load and unload macros can be defined by filament type.
Calibration and tuning printer settings often requires repeating the same steps repeatedly, changing one variable at a time. Macros can help automate this.
As set of simple short cuts for tuning various settings like acceleration, jerk, retraction, pressure advance, etc, see this forum thread (from forum user Phaedrux).
Here is an example macro that uses the M500 function to measure and save the length of the Z axis using the Z max endstop.
; 0:/macros/Bed Leveling/0_Set Zmax height.g ; Automates measuring the Zmax height ; M291 P"This will set Z0 and calibrate Zmax height" R"Proceed?" S3 M291 P"Heating and Homing all axis. Remove filament." T5 M190 S60 ; Set bed temp to 60 and wait M109 S215 ; Set nozzle temp to 215 and wait G28 ; Home all G90 ; absolute positioning G1 X155 Y140 F6000 ; move probe to center M291 P"Print head will now raise until the Z Max endstop is triggered" S3 M913 Z50 ; drop the motor current of the z axis motor G1 H3 Z300 F400 ; Z up until triggered. set M208 Z max M500 ; save m208 value for z axis to config override M291 P"ZMax homing will now be tested, starting with homing Zmin" S3 M291 P"Homing to Zmin" T5 G1 Z100 F6000 ; move z down a bit quickly M558 F600 A1 ; set single fast probe settings G30 ; probe the bed at center M558 F120 A10 ; set slower multi probe G30 ; probe the bed at center M291 P"Ready to test Zmax homing?" R"Proceed?" S3 M291 P"Homing to Zmax" T5 G28 Z ; home to zmax M291 P"Verify that Z max height is correct by moving to Z0" S3 G1 Z0 F400 ; move the Z axis to Z0 M291 "The nozzle should now be just touching the bed." S3 M913 Z100 ; return z axis motor current to normal M140 S0 ; turn bed heater off M104 S0 ; turn hotend heater off
It is possible to use macros to make the PanelDue beeper play simple tunes by using the M300 (play beep) gcode and the G4 (dwell) gcodes. See examples in this forum thread.
RepRapFirmware uses gcode files to script many user configurable printer actions. The use of these system macros and opposed to hard coding the functionality is one the reasons RepRapFirmware is so flexible. It is recommended to start with a configuration from the RepRapFirmware configuration tool or a known good configuration as a start point.
Note, all these macros are in /sys/ on the SD card unless otherwise stated
Homing macros depend on the type of printer you are using. See:
If you have a z probe that must be deployed before probing and retracted afterwards use deployprobe.g and retractprobe.g to call the appropriate deploy and retract commands. These are called by M401 - Deploy z probe, M402 - Retract z probe.
If you are running RepRapFirmware 3.1 or later and you have more than one Z probe, then use deployprobe0.g and retractprobe0.g for probe 0, deployprobe1.g and retractprobe1.g for probe 1 and so on.
Note: If you do not have a Z probe that needs to deploy or retract you must not have these files in the /sys/ directory
bed.g is run in response to the G32 command. See delta calibration and Bed levelling using multiple independent Z motors.
In RepRapFirmware 3.2 and later, mesh.g is run in response to a G29 command with no parameters. If file mesh.g is not found then it behaves like G29 S0 instead.
With RRF 3.4, a new 'Events' system allows for more granular control of errors. See the Events page for more details. The following macros can be created for control of specific events.
There are normally three specified tool change macros (any of which can contain no commands if desired) that execute in this order:
See Selecting a tool for more details.
The Duet can be configured to detect a power failure and store the current state once the power returns if a user wants to resume the print resurrect-prologue.g is run that would contain user commands to home the printer etc before resuming.
M581 can be used to setup the external triggers (switches etc). These triggers carry out actions defined in trigger#.g
See User manual: Using triggers to control the Duet for an example of usage.
M752 runs two macros before and after a 3d scan: before the SCAN command is sent to the scanner, the macro file scan_pre.g is executed and when the scan has finished, the macro file scan_post.g is run.
From RRF3.1.0 and later the file /sys/daemon.g can be used to execute regular tasks. The firmware looks for the file, if the file exists it executes it and once the end of file is reached it waits. If the file is not found it waits and then looks for it again. In RRF 3.3 The wait time was increased form 1 second to 10 seconds. If you want a shorter update time then put a while loop inside the daemon.g with
G4 S1 in it for 1 second repeats.
This can be used in combination with Conditional Gcode to check the object model to look for a particular condition, and then take an action.
Caution must be taken not to start a loop that takes a long time to complete, without having a
G4 P500 or similar command to hand control back to the main process every half a second or so.
You can't directly edit a daemon.g file that is running on a Duet. To edit, right click on daemon.g in the SD card /sys folder and rename it to something else. This will stop the daemon.g file from running, and allow editing. Once the file has been edited, rename it back to daemon.g.
File runonce.g is supported from RRF3.1.0 and later. If this file is present at startup, it is run after running config.g and activating the network, and then deleted.