Best posts made by dc42

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.

The TCT show takes place from 24-27 September, and I have a lot of firmware to finish before then so that we can demonstrate some exciting new hardware! So I hope you will accept my apologies for being less responsive over the next 3 weeks. Fortunately there are several other experienced Duet users who are providing excellent advice on this forum.

On behalf of the Duet3d team I am pleased to announce this last-minute Christmas present to our users. Those of you brave enough to unwrap it can find the files for standalone systems at https://github.com/Duet3D/RepRapFirmware/releases/tag/3%2C5beta1 and the files for SBC systems on the unstable feed of the package server.

This is the first release since major changes to the motion planning system (to accommodate multiple asynchronous motion systems) so I am expecting bugs to turn up, despite the testing we have done on multiple printers covering the most popular kinematics.

Feel free to post your experiences in this thread; but please don't post long problem descriptions that require a response here. Instead, describe them in a new thread with [3.5beta1] in the title. Bear in mind that support from Duet3D will be limited until 3 January, so you may need to revert to release 3.4.5 to continue using your machine.

SBC users can find instructions for switching to the unstable package server and reverting if necessary at https://docs.duet3d.com/en/User_manual/Machine_configuration/DSF_RPi#switch-to-unstable-packages.

RRF release notes: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-350beta1
DWC release notes: https://github.com/Duet3D/DuetWebControl/wiki/Changelog-DWC-3.x-Beta#version-35-b1
DSF release notes: https://github.com/Duet3D/DuetSoftwareFramework/wiki/Changelog-DSF-3.x-Beta#version-35-b1

Happy holidays!

I have created a repository at https://github.com/Duet3D/RRF-machine-config-files to host configuration and related files for RepRapFirmware. User contributions are encouraged. See the README file there for more details.

We have some exciting new hardware prototypes arriving at the end of this week, and I need to have the firmware ready for them. So I won't be spending much time on the forum this week. My apologies to those who are waiting on me to investigate issues. @droftarts and @Phaedrux will be around to handle questions about warranty returns, and of course they and our many valued community members will be around to help on a wide variety of topics.

Here is a summary of development work on RepRapFirmware planned for the near future.

RRF 3.01, expected early March 2020

New firmware features:

• GCode meta commands complete, but no support for variables yet
• Object model mostly complete
• GCode (M409) and HTTP (rr_model) commands provided to retrieve parts of the object model
• Daemon GCode task

New Duet 3 hardware support:

• Tool Board
• Enumeration of connected expansion and tool boards
• Triggers (M581) and wait-for-input (M577) supported on expansion and tool boards
• Emergency Stop to shut down expansion boards and tool boards

RRF 3.02

New firmware features:

• Variables in GCode meta commands
• Support object model expressions in 12864 display menus
• Support image buttons on 12864 display
• Support cancelling some objects on a build plate (M486)
• Support configuration of aux serial port either not at all (for Duet 3), in PanelDue mode (default), or in raw mode
• Improved M303 heater tuning algorithm
• Improved laser rastering support (multiple laser power values per G1 movement)

New Duet 3 hardware support:

• Support M303 on Duet 3 expansion and tool boards
• Support filament monitors connected to expansion and tool boards
• Support switch-type Z probes on expansion and tool boards
• Report stalls from expansion and tool boards

Later

RPi connection option for Duet 2

I've been thinking about how to make it easier for me to investigate possible firmware issues on the forum. Each time I need to set up an SD card with the new config and homing files on it; or overwrite the existing ones on my bench system, but then I lose the old ones unless I back them up separately. So I've worked out a scheme to support multiple configurations more easily, and I wonder whether there are other Duet users who might find this useful.

What I have in mind is that each configuration would be stored in a subdirectory of /sys on the SD card. There would be a new M-code to change the system directory from /sys to a specified subdirectory of /sys. After that, all system macro files would be fetched from that folder instead of /sys. Likewise any files in M98 commands that don't provide a full path.

My master config.g file in /sys would then just contain two lines:

Mnnn "/sys/xxxx" ; where xxxx is the subfolder I want to use
M98 P"config.g"

To switch configurations, I would edit the first line in System Editor of DWC and allow it to restart.

Would anyone else find this useful? Does anyone have a better suggestion?

https://youtu.be/KgzKo0NRWrA

Apologies for the poor video quality, I filmed it on my smartphone.

Some of you may have seen Tom Sanladerer's video https://www.youtube.com/watch?v=8O9E9rcH6Us in which he showed a device he built to swap magnetic beds automatically, so that he could start printing a new file as soon as the previous print is finished.

This obviously needs a print queue system to allow it work unattended without having to combine the GCode files for each print into a single file.

So I've knocked up some quick-and-dirty print spooler macros for RRF which you can find at https://www.dropbox.com/sh/xygtlsyvn2ludn0/AADVxBYxWkcf1v8PuOtwq1kva?dl=0. Feel free to try them if you have a suitable printer! They are a bit clunky because RRF condition GCode doesn't yet support array-valued variables, so the print queue is limited to 5 files. Also the print queue is not saved if you cycle the power; but that will be easier to implement in RRF 3.4.

If you don't like having to send M98 P"/macros/Queue file to print" S"benchy.gcode" to queue a new print file, remember that you can define new GCodes by creating a suitable macro file. For example, if you rename or copy file /macros/Queue file to print to /sys/M990.g then you can send M990 S"benchy.gcode" to queue a file instead.

Santa has produced a RepRapFirmware 1.23 binary for Duet 06 and 085 users, based on the 2.02 firmware source, and snuck it into my github at https://github.com/dc42/RepRapFirmware/releases/tag/2.02. His elves have tested the parts that were most at risk of being broken, and have checked it with DWC 1.22.6. However, as his toy factory no longer makes 3D printers controlled by older Duets, he hasn't been able to do a test print. So please try it out very carefully, and be generous with the mince pies tonight even if something doesn't work properly!

@natthapol-vanasrivilai, thanks for your thoughts.

As @oliof said, I am well aware of the type of development process used in aerospace and some other fields of safety-critical software development (though sadly not always in the automotive industry, as seen from the legal cases faced by Toyota and others). Even now, car recalls for safety-related software updates are fairly common - and who knows how many OTA updates Tesla has pushed for safety-related reasons.

I would love to have an independent V&V team working to validate RRF, DSF and DWC. If everyone using our software was prepared to pay a few £1000s for the privilege plus several £100s in annual maintenance fees, then we could no doubt afford such a team. However, we wouldn't have got where we are today if the software wasn't FOSS. Unfortunately we have to fund software development entirely from profits made on selling Duet hardware - and increasingly, RRF is run on cloned Duets (which we're not keen on, but is allowed because Duet hardware is also open source) and on non-Duet hardware (which we regard as a good thing - in particular, Team Gloomy has alerted us to a number of bugs in new code before we found them ourselves). So we have to make the best of a limited budget.

Regarding unit testing, this is useful for some types of modules, especially where the functionality is complex. DSF does have some unit tests, see https://github.com/Duet3D/DuetSoftwareFramework/tree/master/src/UnitTests. For RRF my preference is to perform formal verification of module properties. We're not there yet because the available tools do not yet cover some of the additions to the C++ language in the last 10 years that RRF uses; but we're working on it. Nevertheless, some critical modules have been formally verified; for example the fast 62-bit integer square root algorithm that RRF used to compute motion control up to and including version 3.3, and the table search function used to calculate PT100 and PT1000 temperatures. Many more modules have precondition and other annotations to facilitate formal verification. I hope that we will soon be able to perform full unit-level formal verification of RRF.

Looking at the bugs found in RRF 3.4.0RC1, these are listed in the "Bug fixes" section of the draft release notes for RC2 at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC#reprapfirmware-340rc2. Of these:

• #1 could possibly have been detected by an appropriately-constructed unit test, and certainly by a system test
• #2 was caused by a change made by a third party, so out of our control
• #3 would have needed a system test, plus additional specification of how accurately each component of the object model should report the underlying value
• Likewise for #4. In addition this only occurred with the combination of a rarely-used feature (use of M301 to override the model-generated PID parameters) and the P value being unusually low.
• #5 would only have been revealed by testing the changed functionality on all PWM-capable ports of the Duet 3 Mini. I tested it on one PWM-capable port on a Mini 5+ but that port wasn't IO1.
• #6 and #8 I did not have a suitable machine to test on. I currently have five 3D printers of which I test on four, plus two bench systems that I can reconfigure, but I did not have either of them set to a configuration required to detect these issues. Some other members of our team did have suitable machines, but none were available to run tests. The new feature causing #6 and #8 had already been released in beta7, so I was hopeful that any associated bugs would already have been reported. In retrospect I should perhaps have delayed the RC by several days to allow more tests to be run.
• #7 should have been detected by a system test.

So one of these issues might have been detected by a unit test, and the remainder only by system tests. This confirms my view that any additional testing we do would be best conducted at the system level. However, RRF supports a huge variety of systems, so we will only ever be able to test a tiny subset of the system space that RRF can be used in. In contrast, the software for a car only needs to support a few different trim levels, most of which are subsets of the top trim level.

My ideal would be to construct formal models of many system configurations, and run them to verify the required system properties. I know this is possible in principle, because I had a plan to develop tools to do this nearly 20 years ago. This would be a lot more cost-effective than setting up many different systems; but there could still be subtle timing issues that the model didn't capture, so it wouldn't be perfect.

Given the constraints we operate under, and that RRF 3.4 has (from the release notes) 86 new/changed features and 68 bug fixes since RRF 3.3 including major changes to the motion system to support input shaping, IMO recording only 8 new bugs in the first RC is quite good. Of course if we could afford to have an independent V&V team execute a lengthy test procedure on a lot of different machine configurations, we could do better.

Regarding the nature of our team: over 40+ years of software development working for several companies, I have learned that a small team of highly-competent developers with the right teamwork approach can accomplish the same productivity and the same or better code quality than about ten times the number of average software developers, provided the project is not so large that too many developers are needed. The investment banking companies were well aware of this - I worked for one for a while, and the number of interview candidates with Oxbridge PhDs we rejected was amazing!

I've started a spreadysheet to record approximate acheivable step rates at https://docs.google.com/spreadsheets/d/1AWA1wLbOaYzxzdQa5LRZvn9rgEk2BuluHy6-_OnD6FY/edit?usp=sharing.

EDIT: In case you want to test yourself.

• Work out a long move that you can use on your machine to test the step rate. It needs to be long enough that most of the move will be at the requested speed, not doing acceleration or deceleration
• Select x256 microstepping
• Send M122 to clear the hiccup count
• Execute that move
• Send M122 to read the hiccup count
• Repeat the last 3 steps at different speeds, to find the speed at which the hiccup count increases dramatically. For a 300mm move at x256 microstepping, I reckon that 50 to 100 hiccups is acceptable, more is not.
• Use the steps/mm and the speed you measured to work out the step pulse rate.

@doctrucker said in RepRapFirmware road map Q1 2021:

Is there a dynamic roadmap document that is periodically updated somewhere on the Github? I fully appreciate the complexities of working on projects like this and understand dates move, but perhaps a dynamic document with estimates for the next release date and a confidence level would save mods and Duet staffers fielding the same question repeatedly?

Not yet, but we're working on making our development more transparent after the 3.3 release.

I've just completed an initial implementation of the M486 code that Marlin introduced recently. See https://reprap.org/wiki/G-code#M486:_Cancel_Object for the specification. I will be looking for volunteers to test this, in particular on machines with multiple tools, because tool changes that were omitted while skipping the process of printing the cancelled object may need to be executed later.

The M486 code has the disadvantage that individual objects need to be labelled with M486 commands. AFAIK there are no slicers that do this yet, although some slicers can label objects using comments, and there are Python scripts to convert these labels into M486 commands. So I plan to supplement M486 with the following functionality:

1. RRF will look for comments in the GCode file that identify the object being printed. It will maintain a directory linking the object number with the object name. The object name is normally the name of the STL file being printed; except that when using S3D you have to use a different process for each object if you want to distinguish between them, so the object label is the process name.

2. RRF will also record the minimum and maximum X and Y coordinates where which extrusion has been seen for each object, to help with object identification.

3. The "job" object of the object model shall be enhanced to include the object directory.

4. This means it will be possible for DWC or another UI to query the object model, list the objects being printed along with their approximate XY centre coordinates, so that a user can select one. The UI would then issue a M486 command to cancel that object.

Can anyone see a problem with this? I'm aiming it mainly at Duet 2, because more sophisticated approaches will be possible when running Duet 3 with attached SBC.

I believe it is important that as far as possible, different 3D printer firmwares and CNC firmwares should ascribe a common meaning to each GCode command. Obviously not all firmwares will support all commands, but where they do the meaning should be the same across all firmwares, so that GCode is as far as possible portable between different firmwares.

There have been many cases in the past where firmware developers have ignored this principle. Sadly this seems to be increasing. Therefore I have posted a message at http://forums.reprap.org/read.php?1,820340 arguing for common standards to be used.

If you have a view on this matter, please consider replying to that post.

On behalf of the Duet3D team I am pleased to announce the availability of software 3.4.0 Release Candidate 1. Highlights of this release include:

• Thumbnail image display of objects to be printed. This requires support that has been implemented but not yet released in PrusaSlicer. A plugin for Cura providing equivalent support may be available soon.
• New notification system in DWC. In particular, messages are no longer stacked vertically, to avoid undesirable consequences such as hiding the Emergency Stop button hen using a narrow screen.
• For those not already on the 3.4beta cycle: input shaping
• Many minor new features and bug fixes

Please read at least the Upgrade Notes section of the release notes before upgrading:

• RRF release notes: https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-RC if you are coming from release 3.3, or https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x-Beta#reprapfirmware-340-post-beta7 if you are coming from 3.4beta7
• DWC release notes: https://github.com/Duet3D/DuetWebControl/wiki/Changelog-DWC-3.x-RC#version-34-rc1
• DSF release notes: https://github.com/Duet3D/DuetSoftwareFramework/wiki/Changelog-DSF-3.x-RC#version-34-rc1

For those running in standalone mode, the firmware files can be found at https://github.com/Duet3D/RepRapFirmware/releases/tag/3.4.0rc1.