RepRapFirmware 3.2 planned improvements

T3P3Tony

I absolutely get the frustration of seeing important features being delayed from 3.2 to 3.3 (and especially in @deckingman case, features similar to ones you used on Duet 2 that have been pending for a while). We don't make these decisions lightly.

During the update from 3.0 to 3.1 we had quite a drawn out period of betas and RCs -it was clear the release process needed to be improved. You will have seen that in 3.1.1 where RRF, DSF and DWC are now on the same firmware build versions, released at the same time. The key change was to reduce the time between releases, which necessarily reduced how many new features are on each release.

We have a finite amount of software development time. That said, certain things that members of this community already do absolutely help maximise what we can achieve, things like:

Testing beta builds and reporting issues, especially on a wide variety of machines.
Helping new users with issues.
Contributing bug fixes and features.
Posting examples of your machines and projects that show all of the many types of configurations using RRF.
All the other activity that makes this a good place to interact and learn.

wilriker

@deckingman said in RepRapFirmware 3.2 planned improvements:

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

I can only answer that for the tool board here. When it started it used to be as low as 10-12kHz. A first improvement increased this to a still low 20kHz. Latest firmware increased it to around 110kHz.

A Former User

@OwenD said in RepRapFirmware 3.2 planned improvements:

Whilst I'm disappointed that my Wishlist items ( variables & multi-choice messages boxes) aren't in the mix for 3.2, we need to remember a few things.

Let’s just break this little fawning fandom down a bit, and provide an opinion from the other side of the coin.

You made a critical Faux Pas I’m afraid, I will explain why at the bottom in reply to your final point.

We all purchased the boards based on the functionality as at that day, and anything further is a bonus

INCORRECT.
Maybe YOU did, but you CANNOT know what ANYONE else based THEIR reason for purchase on. It is not unreasonable (And certainly NOT a bonus) for those who were early adopters to at the very least "expect" the very same "functionality" of the Duet-2 Equipment from what is/was being pushed as "next-gen" equipment.

The vendor has to make a living in order to continue development, so sometimes that's going to alter the development path.

You could construe that as throwing the current "loyal" user base under the bus for the sake of future sales, a very dangerous game and a double edged sword. Alienating some of your greatest technical bleeding edge power users for the sake of the guy fitting a duet to his Ender-3 is a very good way to lose support very quickly. Remember even the Roman Empire fell....

The firmware is open source, so there's plenty of scope for people to help development if there's something that's critical to them. If it's critical to your business, then hire a programmer.

This has already been covered above and also covered very well By Ian "Deckingman" suffice to say it is NOT unreasonable for the end user to "expect" what was/is listed as a premium product to AT THE VERY LEAST have the same functionality of equipment on the Duet-2 platform

Even this forum has a cost to the vendor

Prey tell who is holding a Gun to their head to force them to provide a forum?

On the other side of that coin you could say that the forum allows them to gauge and collate large amounts of marketable data which could allow them to improve their profit margin, so it could be argued that a forum is a positive cost expenditure. Just as you cant make money unless you spend money.....

Everyone has the right to ask about promised features and especially bug fixes, but the above are the cold hard facts.

This is where you committed the major Faux Pas. The above are:

YOU’RE OPINION (which you are entitled to) but you are not entitled to try to call them facts.

And the last time I looked at the definition of "opinion" in the dictionary it doesn't contain anything about "cold hard facts" as you so eloquently "tried" to put it, unless of course you are placing yourself in the category of being an "expert" in which case such an "opinion" is based on the following :

a statement of advice by an expert on a professional matter.

And if that is the case, my question would be: What allows you to place yourself in the category of "expert"?

I personally never even knew there were ANY Firmware/Functionality limitations when I started purchasing Duet-3 Ecosystem equipment.

For both my personal and work units I had personally budgeted (and had obtained my work budget) to transition everything over from all Duet-2 to Duet-3 with tool boards, that equates to 7 personal machines and now a total of 21 work machines which are replaced on a fixed short term cycle, duet control boards on work machines are utilized by my university students to design/build/test & tune their own 3d printers in small groups and those printers are provided to local schools in the surrounding community after graduation of the current intake, and then the cycle repeats. My budget is already in place, my contract is up for renewal early next year and as an engineering educator I think I will take a sabbatical, so yet another reason to use the Duet ecosystem will be removed.

I had made my duet-3 hardware purchase based on the minimum "expected" functionality with that "expectation" being based upon the functionality of the Duet-2 Eco system. I don’t think it is unreasonable to expect the very same functionality AS A MINIMUM.

I had purchased a small number of Duet-3 boards to allow familiarization with the functionality of the hardware in readiness for the full transition over to the ecosystem. I was initially prepared to wait a certain amount of time for the functionality to come online.

But the continual :

adjective

forming a sequence in which the same action or event is repeated.

Yes continual, "deferment" of some basic functionality means that I have become unwilling to keep waiting until "who knows when" for some of that basic functionality to be rolled out.

The whole reason for using the Duet Ecosystem is functionality and ease of use, remove those aspects and the ecosystem no longer stands head and shoulders above other equipment.

In light of this I have taken the decision to abandon the use of the Duet Platform for work related projects and we will switch to suitable quality Marlin based Hardware with the integration of an Rpi with Octoprint, The students wont know any different and it means i have to sit down and work out a marlin/octoprint template instead.

This also means I will re-direct the annual financial offset towards other aspects of the project. I will continue with the Duet-2 Platform on home machines as I like the ease of functionality but the Use case & purchases for Duet-3 has been put on hold and the projects that they were to be used on is now on hold too, I do not wish to spend the extra time undertaking temporary hardware modifications or spending the extra time doing something manually with something that is for the most part an automated process with a Duet-2

deckingman

@wilriker said in RepRapFirmware 3.2 planned improvements:

@deckingman said in RepRapFirmware 3.2 planned improvements:

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

I can only answer that for the tool board here. When it started it used to be as low as 10-12kHz. A first improvement increased this to a still low 20kHz. Latest firmware increased it to around 110kHz.

Thanks Manuel. No wonder it has been kept secret and no wonder my Z axis with 1mm lead screws choked at anything other than a crawl! The last figure I had for Duet 2 was 200kHz. So it has improved from being one tenth the speed of Duet 2 to around half the speed. Which probably explains why buying three new 2mm lead screws (more expense) with half the steps per mm allowed me to run my printer Z axis at the speed I used with Duet 2.

When you say "latest firmware", is that 3.1.1 or the forthcoming 3.2.? Just wondering if there might be further improvements planned for say another years time.

I guess I can forget running my extruders at the micro-stepping required to get the necessary resolution with a mixing hot end whilst still being able to retract at a reasonable speed. With Duet 2, I used to get hiccups at 128x so had to settle for 64x and was rather hoping that gen 3 with its faster processor would allow me to run that 128x. But it seems the opposite is true and now with Duet 3, I'll be limited to 32x or half what I had before.

wilriker

@deckingman Hey Ian, you might have missed that I was talking exclusively about tool boards when it came to step rates. As you do not have tool boards (single driver, tiny form-factor) but expansion boards (3 drivers, larger) this does not apply to you. Nor does it apply to the main board. For both expansion boards and main board the step rates have been increased as well but not even near as much as for the tool boards. But they should be able to run your extruders with x64 I'd assume (might need some testing though).

I was referring to the upcoming RRF 3.2 since this bug was only found after RRF 3.1.1 had been released.

deckingman

@T3P3Tony said in RepRapFirmware 3.2 planned improvements:

I absolutely get the frustration of seeing important features being delayed from 3.2 to 3.3 (and especially in @deckingman case, features similar to ones you used on Duet 2 that have been pending for a while). ..............................

.............That said, certain things that members of this community already do absolutely help maximise what we can achieve, things like:

Testing beta builds and reporting issues, especially on a wide variety of machines.

Helping new users with issues.

Contributing bug fixes and features.

Posting examples of your machines and projects that show all of the many types of configurations using RRF.

All the other activity that makes this a good place to interact and learn.

Tony, is that some sort of a joke? - if so it's in very bad taste. How many hundreds of hours did I spend testing the original beta 3 firmware before the last TCT show? And 5.9k posts and reputation of 992 since June 2016 shows that I've contributed greatly to all the other points you listed.

In return all I get is questions left unanswered, earlier advice being retracted, and basic functionality being repeatedly deferred, so that I have to come up with my own workarounds at not inconsiderable expense, both in terms of cash and time. "Frustration" doesn't begin to describe how I feel.

oozeBot

@T3P3Tony

We have a finite amount of software development time. That said, certain things that members of this community already do absolutely help maximise what we can achieve, things like:

Testing beta builds and reporting issues, especially on a wide variety of machines.

Helping new users with issues.

Contributing bug fixes and features.

Posting examples of your machines and projects that show all of the many types of configurations using RRF.

All the other activity that makes this a good place to interact and learn.

I'd like to request Duet implement some form of defect tracking system where users know their issues have been captured and can track progress. I thought that was github but was told that the forums are the correct place.. So far, we have several issues that we've reported but have no clue if they've actually been captured anywhere other than the forum post.. which is frustrating to say the least. Thanks

T3P3Tony

@deckingman absolutely not a joke, your contribution is unquestioned! My point was that the work that you (and others) have been doing to test the firmware and highlight issues etc helps massively! We would be further way from having these features added if it was not for that.

Where I can answer your questions I have. Its not always possible to commit to a timeline for new features, especially as some of the more complex CAN related features are not necessarily simple to implement.

T3P3Tony

@oozeBot fair point. the forum is to raise issues - some of which turn out to be bugs and are tracked by @dc42 and @chrishamm . Feature requests are a bit more varied, a lot of core feature requests are tracked in the same manner. We will look into ways to make this clearer.

deckingman

@wilriker said in RepRapFirmware 3.2 planned improvements:

@deckingman ...............But they should be able to run your extruders with x64 I'd assume (might need some testing though).

Well prior to 3.1.1. I couldn't test because hiccups for expansion boards were not reported. That at least has been fixed so I just tested by running repeated G10/G11 cycles (no filament loaded in the extruders). Using a retraction speed of 360 mm/min (60mm/sec) I can use 16 x but not 32x because that gave me 2684 hiccups. In fairness, I think I used 180mm/min (30mm/sec) before with Duet 2 so I tried that and I can use 32x micro-stepping but not 64x due to high hiccup count.

So my conclusion is that the step pulse frequency for expansion boards (using current latest stable firmware) is around half what it was with Duet 2 (based on the fact that I could use double the micro-stepping before high hiccup counts are reported) .

I don't see this on any published list of limitations nor is that listed in any of the documentation. Nor is there any official answer to repeated questions asking what the step pulse frequency actually is.

When comparing products, users would likely assume that the faster processor and generally higher specification of the generation 3 products would give higher performance, when in fact the tests I did above show that the opposite is true.

deckingman

@T3P3Tony said in RepRapFirmware 3.2 planned improvements:

..............Its not always possible to commit to a timeline for new features, especially as some of the more complex CAN related features are not necessarily simple to implement.

But that's the problem. The firmware is being driven by "new features" rather than restoring functionality for basic tasks. Maybe it's just me but I'd rather be able to do basic stuff like tune a heater or run higher than 16X micro-stepping on extruders connected to a mixing hot end, or use any end stop switch/motor combination, than create fancy lighting effects with Neopixel or DotStar LEDs (just one example of "new features" which have been given priority over the basic stuff ).

A Former User

@deckingman said in RepRapFirmware 3.2 planned improvements:

@T3P3Tony said in RepRapFirmware 3.2 planned improvements:

..............Its not always possible to commit to a timeline for new features, especially as some of the more complex CAN related features are not necessarily simple to implement.

But that's the problem. The firmware is being driven by "new features" rather than restoring functionality for basic tasks. Maybe it's just me but I'd rather be able to do basic stuff like tune a heater or run higher than 16X micro-stepping on extruders connected to a mixing hot end, or use any end stop switch/motor combination, than create fancy lighting effects with Neopixel or DotStar LEDs (just one example of "new features" which have been given priority over the basic stuff ).

As the saying goes : Fur coat and no knickers.......

gtj0

@T3P3Tony said in RepRapFirmware 3.2 planned improvements:

@oozeBot fair point. the forum is to raise issues - some of which turn out to be bugs and are tracked by @dc42 and @chrishamm . Feature requests are a bit more varied, a lot of core feature requests are tracked in the same manner. We will look into ways to make this clearer.

I did suggest a while back that Atlassian's Jira (including the cloud hosted versions) are free for open source projects.

A Former User

@CaLviNx said in RepRapFirmware 3.2 planned improvements:

Fur coat and no knickers...

thats not always a bad thing

In any case there are no two ways about it there has been a miss-match between expectations and deliverables for Duet3+RRF3 and a unfortunate dependency between the two. Clearer communication of limitations would probably have helped, but hindsight will always be 20/20.

3.2beta1 is just out, so there is that!

arhi

@gtj0 said in RepRapFirmware 3.2 planned improvements:

I did suggest a while back that Atlassian's Jira (including the cloud hosted versions) are free for open source projects.

issues on the github work rather good without all the overhead and bloat atlassian likes to add. and if ppl don't want to report a bug on the github issue I doubt they will do it on the jira

T3P3Tony

@arhi I expect we would still report the issues on the forum and then only add them to whatever issue tracking system that was used once accepted

The problem with github issues up to this point is we have people asking for support due to configuration problems on github rather than on the forum.

arhi

@T3P3Tony well I'm not a github guru but I'v seen this set pretty nicely on other projects where you easily shoot a "canned answer" to those asking for support to "go post on forum" and mark the feature request and bugs accordingly with tags ..

T3P3Tony

@arhi yes for sure that is possible, we can consider it.

arhi

@T3P3Tony said in RepRapFirmware 3.2 planned improvements:

@arhi yes for sure that is possible, we can consider it.

good example is octoprint .. very lively forum and very lively github...

smoothieware is also an interesting example, they go to extreme's to shut down any non bug related talk on the github

dc42

To those who have complained that we haven't published maximum step rates for a while: why don't you measure them yourselves? Or if it's for a planned purchased of a board you don't have, ask someone else to. It's not difficult:

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.