RepRapFirmware 3.2 planned improvements

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 ).

@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.

@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.

dc42

@deckingman said in RepRapFirmware 3.2 planned improvements:

...or run higher than 16X micro-stepping on extruders connected to a mixing hot end

You may find that you can do that with the 3.2beta1 expansion board firmware.

esphome or homeassistant(?) has a thing on their github requiring any issue to conform to a template, and some voodoo to weed out "it doesn't work" and "its the wrong flavour".

in the near term, having developers register bugs and posting to the forum threads where an forum topic has been escalated to a bug might be a start to avoid the issue oozeBot raised. power users will likely pick up on the trend and register issues themselves when bugs are confirmed to offload the developers?

dc42

What I would really like is to be able to restrict creating issues to particular users/email addresses only. That way we could add users to the allowed list when they have shown on the forum that they really do understand when they have found a probable bug.

As it is, there are so many issues posted on github that are really support requests that I rarely look at github issues. Just occasionally I am surprised to find a new real bug report when I do.

@dc42 it might be low hanging fruit to just add a template?

maybe users would self redirect if they that was part of the template, as opposed to a blank slate?

example https://github.com/esphome/issues/issues/new?template=bug_report.md

dc42

@bearer said in RepRapFirmware 3.2 planned improvements:

@dc42 it might be low hanging fruit to just add a template?

maybe users would self redirect if they that was part of the template, as opposed to a blank slate?

example https://github.com/esphome/issues/issues/new?template=bug_report.md

Maybe, but I don't have time right now to read enough of the documentation to understand github templates and design one. I would be happy for someone else to do that.

deckingman

@dc42 said in RepRapFirmware 3.2 planned improvements:

To those who have complained that we haven't published maximum step rates for a while: why don't you measure them yourselves? ................

Because until very recently hiccups for expansion boards were not reported. OK, so it's fixed in 3.1.1. but prior to that, I had no way to test because I couldn't get a hiccup count. Hence the reason that for 12 months or so, I had to keep asking the question (but never got an answer).

Or if it's for a planned purchased of a board you don't have, ask someone else to................

Seriously? That's your answer to the question "what is the maximum step pulse frequency"? - Get a forum member to test it and report back!

Methinks if I was an OEM looking to purchase (say) a few hundred units per month and received that response to the question, I'd be dropping Duet as potential candidate faster than a hot brick.

bot

And I'm here just like "what about RRF 2?" lol.

Why did we throw that baby out with the bath water?

gtj0

It's also hard for normal users to file a github issue because you have to know which github project to create issues in. RRF? DSF? DWC?