RepRapFirmware 3.2 planned improvements

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.

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.

A Former User

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.