RepRapFirmware road map Q1 2021

[dc42]

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.

[A Former User]

Duet 3 Mini as a Duet 3 expansion board

This is quite interesting! not sure i follow the limitations howerver - is it essentially the networking, LCD, SBC, etc interfaces that will be unsupported effectively turning it more or less into a sort of Duex 5 for Duet 3 Mini (and presumably for the 6HC) or are there limits with respect to heaters, thermistors, fans etc?

[DaBit]

Nice, thanks for the update. The speed of progress is quite insane, especially given the fact that it is not a team of 50 engineers developing all this.

I will go Duet3 for new stuff anyway, but can you also shed a light on features that will be present or dropped on older-gen hardware?

[JuJuDelta]

@dc42 said in RepRapFirmware road map Q1 2021:
"These are our current plans for RRF over the next few months:
....RRF 3.3: this is planned to be a short cycle. Work on it has already started....
....RRF 3.3 will also increase the maximum number of axes supported to 15,....
....I hope to have a release candidate available by the end of January....."

Thanks for all your hard work. This news is very welcome.

Regards,

Julian.

[JuKu]

Thank you! Your development is impressive, and this post put even more confidence to your company. I'm so looking forward to RRF3.4!

In the meanwhile, you said about RFF3.3:
@dc42 said in RepRapFirmware road map Q1 2021:

Some other easy-to-implement features may be included.

May I ask for yet another stop command? (See M112):

"M113: Not Emergency Stop
Any moves in progress are immediately terminated, honoring de-acceleration parameters. No other effect; motors stay on, heaters stay active etc."

The use case is CNC style jogging using a push button: Button down sends a command to move towards machine limits, button up sends this command to stop the machine.

[gringo]

@dc42

Will this be implemented in one of the next Firmware?
Magnetic Compensation

[NexxCat]

Thank you for your continued work on improving RepRapFirmware and the entire Duet ecosystem @dc42

Do variables fall on the roadmap anywhere yet? I know it's possible right now using fake axes / etc, and I don't have a use in mind yet, but I was just curious.

[dc42]

@NexxCat said in RepRapFirmware road map Q1 2021:

Do variables fall on the roadmap anywhere yet? I know it's possible right now using fake axes / etc, and I don't have a use in mind yet, but I was just curious.

Variables are a high priority, so they may be included in 3.4.

[CCS86]

Very excited for the motion developments slated for 3.4!

Any chance PA can get some love in 3.3 or 3.4? I'd love to test some of the suggestions I made here, if they are reasonable to implement:

https://forum.duet3d.com/topic/17752/pressure-advance-discussion-for-future-development

[chivel]

Dear Sirs
Please explain to me why in the Status section for the Delta printer at the HOME point, the head position X and Y coordinates are 0 and Z is 999.In Delta X,Y,Z are equivalent.
May be problem in Firmware version?

[Dougal1957]

@chivel said in RepRapFirmware road map Q1 2021:

Dear Sirs
Please explain to me why in the Status section for the Delta printer at the HOME point, the head position X and Y coordinates are 0 and Z is 999.In Delta X,Y,Z are equivalent.
May be problem in Firmware version?

Because on a delta you should always home to X0 Y0 Z(max) as this is the only way the kinematic can know where the nozzle is located I think the main confusion comes from the Towers often labelled as X Y and Z instead of A B and C.

This this subject should not be in this thread it is off topic.

[vistalert]

I'm very much looking forward to the next wave of upgrades on RRF and also physical upgrades to my machine. I'll be selecting https://main.eva-3d.page/ for my carriage, and note that one of the community members has already created a design which includes support for the ADXL sensor, used in input shaping calibration.

If you're not aware of the EVA modular carriage system I'd encourage you to take a look. Like the team here, there is incredible work being done there.

[compatibilizer]

I was wondering if the experimental M954 command does (or could) work for the 6HC board too? I have a spare one which I would love to use as a 6 drive expansion board.

[dc42]

@compatibilizer said in RepRapFirmware road map Q1 2021:

I was wondering if the experimental M954 command does (or could) work for the 6HC board too? I have a spare one which I would love to use as a 6 drive expansion board.

In the latest beta firmware, yes it does.

[jay_s_uk]

@dc42 is there a planned improvements spreadsheet for 3.3 similar to the one made available for 3.2? https://forum.duet3d.com/topic/16291/reprapfirmware-3-2-planned-improvements

[Diamondback]

Really looking forward to the input shaping work that is already happening!
I have a question though.
I'm currently building the wiring loom for my custom toolchanger and was wondering if there is any thoughts yet on whether or not the Duets will have the abilitiy to connect something like an ADXL345 sensor to them for auto calibrating the input-shaping parameters.
If so, is there any preferred connection method yet (I2C vs SPI), if there is, I'd directly include the necessary cables in my loom to the carriage head, which has a built-in mount for such a sensor and save me some headache of having to rebuilt the loom further down the line.

Thanks

[T3P3Tony]

We are considering how we support stand alone accelerometers connected to Duet 3 mainboards. It is likely to be over SPI connected to the Temperature DB connector as I2C is not appropriate for long distance, off board wiring runs.

[dc42]

@jay_s_uk said in RepRapFirmware road map Q1 2021:

@dc42 is there a planned improvements spreadsheet for 3.3 similar to the one made available for 3.2? https://forum.duet3d.com/topic/16291/reprapfirmware-3-2-planned-improvements

Not yet, because whether some improvements go into 3.3 and 3.4 depends on when DCS 3.3 is ready. But now that 3.3beta2 is out, we have a much better idea. RRF 3.3 is likely to include the improvements already in 3.3beta2, plus the ability to switch tool heaters between off/active/standby without selecting/deselecting the tools, and a few more bug fixes and minor new features.

[fcwilt]

This post is deleted!

[dc42]

@fcwilt said in RepRapFirmware road map Q1 2021:

@dc42

Any chance of having G30 accept X and Y parameters (when no P parameter is present) thus doing the math and movement needed to place the probe at X and Y without needing a preceding G1 command?

Frederick

If the printer has not been homed then moving to an XY position at the start of a G30 probe move is problematic on some types of printer, e.g. delta printers. So it's possible after Z homing has been done (and the print head would move rapidly to the specified position and dive height before probing), but potentially problematic for a G30 homing move.