Coming soon to a PanelDue near you...

On behalf of the Duet3D team I am please to announce the release of RepRapFirmware, Duet Web Control and Duet Software Framework 3.4.0 stable.

RepRapFirmware 3.4.0 brings more than 90 new and improved features and around 80 bug fixes. New features include:

• Input shaping, to allow faster print speeds without exciting ringing
• Thumbnail image display of print files in Duet Web Control and on PanelDue (requires a compatible slicer and PanelDue firmware 3.4.1-pre2
• Heater feedforward, to maintain more even nozzle temperatures on high flow rate extruders
• More flexible control of power supplies
• More control over machine behaviour when heater faults, stepper driver warnings etc. occur
• Support for the new Duet 3 MB6XD main board for use with external drivers, and the EXP1HCL closed loop stepper motor control board
• Coordinate rotation in the XY plane

Duet Web Control and Duet Software framework now provide:

• Thumbnail image display
• Improved plugin support and new plugin guides for DWC and DSF
• A new HTTP class library for remote control of Duets in standalone and SBC mode
• 12864 display support in SBC mode

Important! If you are upgrading from software 3.3 or earlier, read at least the upgrade notes section of the RRF 3.4.0 release notes to see what alterations if any you may need to make to your configuration and macro files. Users already running 3.4.0RC2 can instead check the abbreviated release notes.

Upgrade instructions:

• For Duet in standalone mode you can find the upgrade files here. Most users can just upload the Duet2and3Firmware-3.4.0.zip file.
• For Duet with attached Single Board Computer, upgrade from the stable feed on the Duet3D package server using apt-get as usual.

Please do not use this thread to report issues with this release that require a response; start a new thread for those instead.

On behalf of the Duet 3D team I am pleased to announce RepRapFirmware 3.2 stable. Here are the upgrade instructions:

• If you are running RepRapFirmware 3.0 or later in standalone mode, download Duet2and3Firmware.zip from https://github.com/Duet3D/RepRapFirmware/releases/tag/3.2 and upload it to your Duet via the web interface
• If you are using Duet + SBC, update from the package server in the usual way (sudo apt-get update followed by sudo apt-get upgrade)
• If you are running RepRapFirmware 2.x you will need to upgrade to firmware 3.0 first, then you can immediately upgrade to 3.2. Alternatively, if you are comfortable using Bossa, you can upgrade directly to 3.2 using Bossa.

Upgrade notes and change lists:

• RRF: https://github.com/Duet3D/RepRapFirmware/blob/v3-dev/WHATS_NEW_RRF3.md
• DWC: https://github.com/Duet3D/DuetWebControl/blob/master/WHATS_NEW.md
• DSF: https://github.com/Duet3D/DuetSoftwareFramework/blob/master/WHATS_NEW.md

If you encounter problems with this release, or problems upgrading to it, please start a new thread to describe those issues.

Edit: If you are on the unstable package feed (Duet + SBC), you can update to the latest version as usual again. The corresponding packages have been fixed.

These are our current plans for RRF over the next few months:

RRF 3.2: release candidate 2 appears to be very stable so we plan to release 3.2 final very soon.

RRF 3.3: this is planned to be a short cycle. Work on it has already started. The focus is on making Duet main boards easier to test using our new CAN-based automatic test equipment. As a side-effect of this work, there may be experimental support for using a Duet 3 Mini as a Duet 3 expansion board (see the M954 command), however functionality will probably be limited to driving motors and reading/writing GPIO ports. RRF 3.3 will also increase the maximum number of axes supported to 15, and I expect to provide support for tuning heaters on regular Duet 3 expansion and tool boards. Some other easy-to-implement features may be included. I hope to have a release candidate available by the end of January.

RRF 3.4: the focus of this will be the motion system. We will be looking at input shaping, S-curve acceleration, better cornering algorithms, and other mechanisms to improve print quality. Alongside this we will remove the limitation on using endstops connected to Duet 3 main boards to control motors connected to expansion boards. We expect to start work on this in February. We have a long list of other new features for consideration in this release, including further improvements to the performance of the Duet 3 MB6HC board.

I finally found time to implement the new heater tuning algorithm. This algorithm is more accurate than the old one (especially in measuring the dead time), often completes more quickly than the old algorithm, and is more portable to expansion and tool board firmware.

The new algorithm also tunes the heater with related fans both off and on. The purpose of this is to allow the heater control to implement feedforward, which monitors fan PWM changes and adjusts the heater power in advance of the PID algorithm spotting that something has changed. Here is a temperature plot showing the effect on reported hot end temperature when a print cooling fan is turned on and then off, with and without feedforward.

The new algorithm is implemented in RRF 3.2beta3.2 which I hope to release later today. Subject to the feedback I receive from beta testers, I hope to include it in tool and expansion board firmware too in the RRF 3.2 final release.

I am pleased to announce the release of RepRapFirmware 3.0, the first stable release in the RepRapFirmware 3 series.

Users of Duet 3 with attached Raspberry Pi can upgrade to it using apt-get update and apt-get upgrade as usual, from either the stable or the unstable package feed.

Duet 2 users and Duet 3 users running in standalone mode can download it from https://github.com/dc42/RepRapFirmware/releases/tag/3.0. Most users should be able to upgrade just by uploading the .zip file to /sys in Duet Web Control.

If you are currently using RepRapFirmware 2.x, you will need to make significant changes to your config.g file when upgrading to RRF3. See https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview#Section_Summary_of_what_you_need_to_do_to_convert_your_configuration_and_other_files for details. You should read this thoroughly and plan your migration to RRF3.

Now that RepRapFirmware 3 is released, I do not plan to do any further releases of RepRapFirmware 2.x or 1.x. But of course it is possible for others to fork the repository and do their own amendments to 1.x and 2.x.

On behalf of the Duet3D team, I am pleased to announce the release of software package 3.3beta3. This release brings the following:

• Global variables are now included in the object model. This means they can be viewed in the DWC Object Model browser and can be accessed by SBC add-ons.
• The DWC Object Model browser now provides a summary of what each value means
• RRF and DWC now support accelerometers (currently in standalone mode only) in preparation for the forthcoming support for input shaping. See https://duet3d.dozuki.com/Wiki/Accelerometers.
• Many other minor improvements and bug fixes

RRF release notes: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta-&-RC#reprapfirmware-33beta3
DWC release notes: https://github.com/Duet3D/DuetWebControl/releases/tag/v3.3-b3
DSF release notes: https://github.com/Duet3D/DuetSoftwareFramework/releases/tag/v3.3-b3

Users of Duet + SBC can upgrade from the unstable package server.

Users of Duet in standalone mode can upgrade using the files at https://github.com/Duet3D/RepRapFirmware/releases/tag/3.3beta3. The IAP files have not changed but they are included in this release because some users may need to re-upload them to put them in the correct folder on the SD card.

A genuine Einsy Rambo board is $120 on Ultimachine's web site, and it has only 4 stepper drivers, an 8-bit processor and no web interface. So I think $130 is in the right ball park for a high-quality board that comes with support and a warranty. In time I expect the price will come down.

MKS can only sell boards as cheaply as they do by parasitising open source designs, violating the open source license agreements, offering no support and little or no warranty, and selling boards before they have got the design right (as happened with the SBase). We're not like that.

Our latest thoughts about this are to embed a MQTT client in RRF that publishes messages about the current state of the printer e.g. printer powered up, print started, print completed, print paused by filament monitor.

@JetClay one option may be to use G30 S-1 to do manual probing without setting the Z height to zero. Then run this:

G10 L2 Z{sensors.probes[0].lastStopHeight}

This will set the Z offset of the workplace to that height. Or you could use:

G10 L2 Z{move.axes[2].userPosition}

since the current Z position will be the same. Or even:

G10 L20 Z0

You can include

G10 L2 Z0

in your homedelta.g file to reset the offset to zero when you home the printer again.

@MurphDurtay said in Printer won't extrude walls of prints.:

Everything seems to be working as usual now with the 0.4mm nozzle. Could I just ratchet up the nozzle temp to like 270 to print with the 0.8 and 1.0mm nozzles?

You can try that, but you may also want to look at https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m309-set-or-report-heater-feedforward.

@DIY-O-Sphere MQTT is supported on Duet 3 boards with Ethernet interfaces in RRF 3.6.0-beta.1 and later.

@qlqlo, the 6HC will draw from the 48V supply only a small fraction of the current that they supply to the stepper motors. This is because the drivers reduce the voltage from 48V to the voltage actually needed by the motors (which at standstill is just a few volts) and the current drawn from 48V reduces in the same proportion. When the motors are moving fast they need more voltage, but the phase angle between voltage and current also has the effect of reducing the net current drawn from 48V. So your six stepper motors will likely draw only about 3A total from 48V when they are at standstill, and a bit more when they are accelerating.

If your SSRs will work with control voltages down to 3V then they will probably just about work with the IO_OUT outputs. Some alternatives include:

• Use the LASER/VFD output for one of them, which is 5V
• Use the PS_ON output for one of them, which is open drain and can conveniently be used with 5V
• Use high current OUT ports to drive them, with series resistors to reduce the output voltage from 48V to be within the working range of the SSR
• Use low current OUT ports to drive them with the voltage selection jumper on those ports set to 12V.

HTH David

@audryhome I believe this is already fixed in 3.6beta3. The object model returns 3 decimal places for both user and machine position of all axes (with trailing zeros in the decimal part suppressed); however DWC only displays 2 decimal places.

m409 k"move.axes[].machinePosition"
{
    "key": "move.axes[].machinePosition",
    "flags": "",
    "result": [
        0.045,
        -7.955,
        9.894,
        129
    ],
    "next": 0
}

@audryhome this is a bug in 3.6beta. Axis positions are supposed to be reported to 3 decimal places, although trailing zeros in the decimal part are always omitted in the JSON response. I will fix it in the next build.

For those testing beta 3 there are now beta3+1 builds of the main board firmwares at https://www.dropbox.com/scl/fo/bx70c7u0bshq79ez83mnn/AKMj4UCEimtQuGYxRj_d0ew?rlkey=7yiq3x5fcae3v2ogslfocx1op&dl=0. The most important bugs fixed in this version are:

Duet 2 Ethernet only: network connection was unreliable
Duet 3 6XD only: at high step rates the minimum interval between steps was not honoured, leading to steps merging

See https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-360-rc1-in-preparation-changes-since-360-beta3 for other fixes and changes.

@mikeabuilder said in WHILE loop acts like an IF statement:

if there is some lag in getting the object model updated, it could give the result you are seeing.

There is no lag in reading OM values within macros when running in standalone mode. Even in SBC mode there is usually no lag because the SBC asks RRF to evaluate expressions.

@Guus the index pulse is generated once every pole pair (see page 10 of the datasheet), so it's not much use as an endstop. I guess you could use it to detect the passing of a magnet, but a Hall effect device would do that more simply.

@Paski there is no facility to read from a general text file, however you can read from a single-line CSV file. See function fileread at https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands#functions.