RepRapFirmware 3.2 planned improvements

SpoonUnit

Could the option be added to set the min limit for behaviours similar to that controlled my M190. A default of 41 seems fine, but ultimately arbitrary, and having the option to hand control of this value to the operator would be nice. M143 sets max limits, perhaps it could be overloaded to support specifying min limits also?

droftarts

@dc42 really looking forward to playing with G5 Bezier curves!

Ian

dc42

@copystring said in RepRapFirmware 3.02 planned improvements:

Please add inverted M80/M81 for meanwell PSUs.
I know. I'm inpatient. Is it a lot of work to implement this?

This is included in the planned work to make the PS_ON pin configurable.

arhi

@dc42

Support G5

Does this involve maybe also G15 / G16 ? (I don't know if any slicer know how to use them, I only used them when I wrote code manually on my old milling machine)

DaveA

Maybe I'm just more confused than normal but I don't understand the versioning system.
Is 3.1.0, soon to be 3.1.1, not the latest stable release? If so, why is the next version going to be 3.02?

A Former User

@DaveA understandable confusion; the current 3.1.0 was supposed to be 3.01 until about the day it was released, presumably what would be 3.02 will be 3.2.0.

dc42

@DaveA said in RepRapFirmware 3.02 planned improvements:

Maybe I'm just more confused than normal but I don't understand the versioning system.
Is 3.1.0, soon to be 3.1.1, not the latest stable release? If so, why is the next version going to be 3.02?

The next stable release, not counting patch releases such as 3.1.1, will now be called be 3.2.0. I have changed the title of this thread.

garyd9

I'm hoping requests for 3.2 will also be entertained: Extend M409 to allow multiple keys to be requested.

For example, assume something embedded that wants to determine how much time is probably left in a print (using the simulated time) would need to request job.file.simulatedTime as well as job.duration. Having to request the entire 'job' key to 3 levels deep can result in a large buffer. Having to make 2 M409 requests doubles the time needed to get the information.

On the other hand, if M409 supported multiple keys, the request and response could be simplified:

M409 K"job.duration","job.file.simulatedTime"

(For discussion, I've also started a new thread: https://forum.duet3d.com/topic/16450/m409-multiple-keys-at-once)

oliof

Regarding line item 48: According to Marlin docs, UBL does support loading an existing mesh and applying 3-point or grid based tilt adjustment.

jay_s_uk

Is the spreadsheet in the first post still being maintained?
Does the equivalent exist for 3.3?

dc42

@jay_s_uk said in RepRapFirmware 3.2 planned improvements:

Is the spreadsheet in the first post still being maintained?
Does the equivalent exist for 3.3?

Many of the items that were planned for 3.2 have been deferred to 3.3. You can see what's implemented in 3.2 in the RRF3 whatsnew file.

A Former User

@dc42 said in RepRapFirmware 3.2 planned improvements:

Many of the items that were planned for 3.2 have been deferred to 3.3. You can see what's implemented in 3.2 in the RRF3 whatsnew file.

why the continual push back ?

dc42

It's hardly a continual push back. The 3.2 release includes nearly 40 improvements, not counting bug fixes.

A Former User

@dc42 said in RepRapFirmware 3.2 planned improvements:

It's hardly a continual push back. The 3.2 release includes nearly 40 improvements, not counting bug fixes.

let me re-phrase then : why the push back ?

Phaedrux

@CaLviNx Market conditions?

A Former User

@Phaedrux said in RepRapFirmware 3.2 planned improvements:

@CaLviNx Market conditions?

which means what exactly ?

I think there is more than a few users waiting on functionality fixes (which in my opinion should have be a priority) which would allow the correct use of pre-purchased equipment to be used/maintained properly/easily

Phaedrux

In short, there is a global shortage of 2660 drivers used in the duet 2 (turns out they are used in ventilators) and the Maestro is discontinued, so work on the mini5+ was pulled forward.

3.2 beta is in the works, so things are coming. We all appreciate the patience.

jens55

Could we gat a URL that lists the likely changes for 3.2?
I know DC42 said "You can see what's implemented in 3.2 in the RRF3 whatsnew file." but I have not been able to find that file ....

oozeBot

@jens55

https://github.com/Duet3D/RepRapFirmware/commit/ed1bb2a1924fea6308ee024d4142ed243d6358cb

0

dc42 committed to Duet3D/RepRapFirmware

Update WHATS_NEW_RRF3.md

deckingman

Two questions.

From the 3.2. planned improvements link it says - quote

"[Duet 3 expansion and tool boards] Increased performance, in particular the maximum step rate is higher than before"

I'm a bit fed up of asking the question because I've asked it multiple time over the last 12 months and never yet had an answer but I'll try one more time so here goes.....

Question 1. What is the maximum step pulse frequency for expansion and tool boards now, and what will it be?

There remains a long list of limitations for expansion boards which I have been trying to use for over a year. https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations

Some of the fixes have been pushed back to being planned for release 3.3.0 now while some don't have any planned release number assigned to them. So .....

Question 2. What is the likely release date for 3.3.0 and for those items on the list of limitations which are not planned to be fixed in 3.3.0, is there any plan to fix them and if so when, or will they be permanent limitations?