This page describes the differences between RRF2 and RRF3 and the changes needed to configuration and other system files when upgrading to RRF3.
Important! These instructions relate to RRF3.0 and to some extent to later versions of RRF3 however they are not kept up to date. Please refer to the Gcode Dictionary and use the RepRapFirmware configuration tool to migrate from RRF2 to RRF3.
RepRapFirmware 3 is the next generation version of RepRapFirmware for Duet 3, Duet 2 WiFi/Ethernet/Maestro, and some other 32-bit motion control electronics. There are significant configuration differences from version 2, so upgrading from RRF 2.x to RRF 3.x is not plug-and-play.
RRF3.x uses the GPIO concept extensively. GPIO (General-Purpose Input/Output) is an digital signal pin on a circuit board or processor that can act as an Input or Output, as controlled by the Firmware. GPOUT = output, GPIN = input.
RRF3 uses these programmable pins to allow much greater flexibility and enhanced expansion for the future. The configuration files must define the uses of these pins first, then their assignments
The primary benefits of RRF 3 are:
The primary configuration differences compared to RRF 2 are:
RRF3 always uses a real time operating system (RTOS). It does not support legacy version 0.6 or 0.8.5 Duets.
The latest releases are on github here:
Do read the whole of this guide to understand the configuration changes required if migrating from RRF2.
Note: it is not possible to upgrade a Duet WiFi, Ethernet or Maestro directly from firmware 1.x or 2.x to 3.01 or later by uploading the new firmware file over the network. You must upgrade to firmware 3.0 as an intermediate step. Alternatively, you can erase the existing firmware using the erase button or jumper, and then install your chosen RRF 3.x firmware directly using Bossa.
The following Gcode and Mcode commands have changed. Please refer to the Gcode dictionary for details.
G0 and G1 - Rapid move and Controlled (linear) move.
G31 - Set or Report Current Probe status
M36 - Return file information
M42 - Switch I/O pin
M98 - Call Macro/Subprogram
M106 - Fan on
M115 - Get Firmware Version and Capabilities
M122 - Diagnose
M143 - Maximum heater temperature
M280 - Set servo position
M291 - Display message and optionally wait for response
M305 - Set temperature sensor parameters
M307 - Set or report heating process parameters
M452 - Select Laser Device Mode
M453 - Select CNC Device Mode
M500 - Store parameters
M501 - Read stored parameters
M550 - Set Name
M551 - Set Password
M558 - Set Z probe type
M563 - Define or remove a tool
M571 - Set output on extrude
M574 - Set endstop configuration
M577 - Wait until endstop is triggered
M581 - Configure external trigger
M584 - Set drive mapping
M585 - Probe Tool
M591 - Configure filament sensing
M670 - Set IO port bit mapping
M997 - Perform in-application firmware update
M999 - Restart
This command creates a sensor, or modifies an existing sensor, or reports the parameters of an existing sensor. It replaces the M305 command of RepRapFirmware 2.
In earlier versions of RepRapFirmware, sensors only existed in combination with heaters, which necessitated the concept of a "virtual heater" to represent a sensor with no associated heater (e.g. MCU temperature sensor). RepRapFirmware 3 allows sensors to be defined independently of heaters. The association between heaters and sensors is defined using M950.
M950 is used to create heaters, fans and GPIO ports and to assign pins to them. Each M950 command assigns a pin or pins to a single device. So every M950 command must have exactly one of the H, F, J, P or S parameters.
If a M950 command has C and/or Q parameters, then the pin allocation and/or frequency will be configured accordingly. Otherwise, the current configuration will be reported.
A pin name is a string of characters enclosed in double quotation marks. It is not case sensitive. All instances of _ and - characters are stripped from pin names before comparing them.
These two names refer to the same pin because of the comparison rules.
Some pin names have the form "connector.pin" or "board.pin" where *connector *or *board *identifies the connector on the Duet or the expansion board, and *pin *identifies the pin within that connector or on that expansion board. Sometimes a pin has multiple names.
These four all refer to the heater3 pin, either on the expansion connector (where it is pin #8 of 50) or on the heater output terminal block of a DueX2 or DueX5. However, there is a difference. The DueX boards buffer and invert the signal. Therefore, when you use one of the forms prefixed with DueX the firmware knows it has to invert the signal, but it doesn't invert it if you use one of the other forms. In contrast, when you referred to logical pin 3 in previous versions of RRF, the firmware always inverted the signal - so if you were driving a servo or BLTouch from this pin you would have needed to use the I1 parameter in your M280 command.
You may occasionally need to invert sense of a pin - for example, if you use a fan output to control the PWM input of a 4-wire fan instead of using it to switch the ground supply. You can indicate inversion by prefixing the pin name with exclamation mark.
This means the pin labelled FAN2 on the Duet, but with the drive signal inverted.
When declaring an input pin (e.g. in the M574 command), a '^' character before the name indicates that the pullup resistor should be enabled. Otherwise it is not enabled.
Some GCode commands accept more than one pin name. For example, the M453 command allows you to specify both forward and reverse spindle ports, the M574 command allows you to specify multiple endstop switches per axis, and the M558 command allows you to specify both input and output pins for the Z probe. You can use the + character to indicate multiple pins.
Note, if you provide more pin names than the command accepts, the extra ones are likely to be ignored.
For each Duet board, see the hardware pages for a list of pin names and function.