RepRapFirmware 3.2 planned improvements

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

[A Former User]

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

[Edgars Batna]

Don't get upset, I'm just being direct here.

It appears to me as if the Duet team randomly jumps from one board to another. That's certainly not what the Duet team intended. There is great hardware designer and programming talent here, but, sorry, it's all just excuses. We do in part pay for the software when buying the hardware. Yes, it's open source software, but a requirement to hire a developer is not what's on Duet's product page. This approach is somewhat... Chinese. You buy a cat in the box and have to hope they will fix the missing legs. It's still a cat that can purr, but it's missing its legs and all you got to complain to is some overloaded Chenglish speaking guy 12 time zones away. You sorta bang at the door until you're tired. The only difference is that the forums are English.

Well, I won't buy or recommend a single Duet board until Duet 2 works 100.000000000000% and I mean all the tiny last corner cases directly or indirectly related to motion. Everything else is just the rate of odor decay of the icing on the cake. I couldn't care less for many improvements already done.

Yes, I "hired a programmer", i.e. myself and got it working to 99.9999%, but it's not good enough for me.

In total the Duet 2 is the workhorse on my printer, so, yah, OPEN SOURZ YEEHAH. ¯\(ツ)/¯

EDIT: Forgot to mention that in China you don't need open source. You just steal the product and you're fine. I'm not saying this is a negative or a positive.

[A Former User]

@Edgars-Batna said in RepRapFirmware 3.2 planned improvements:

Well, I won't buy or recommend a single Duet board until Duet 2 works 100.000000000000% and I mean all the tiny last corner cases directly or indirectly related to motion.

with that requirement then going with a different vendor is probably a good idea; however i suspect it'll be a challenge in its own right to find a suitable vendor for that requirement?

[Edgars Batna]

@bearer said in RepRapFirmware 3.2 planned improvements:

@Edgars-Batna said in RepRapFirmware 3.2 planned improvements:

Well, I won't buy or recommend a single Duet board until Duet 2 works 100.000000000000% and I mean all the tiny last corner cases directly or indirectly related to motion.

with that requirement then going with a different vendor is probably a good idea; however i suspect it'll be a challenge in its own right to find a suitable vendor for that requirement?

Now try that AFTER you've designed and built a printer around a vendor. I'm a vendor too and have to rely on other vendors. The discussion is near pointless. As people have said, it is what it is. The Chinese don't care either.

[dc42]

@Edgars-Batna said in RepRapFirmware 3.2 planned improvements:

Well, I won't buy or recommend a single Duet board until Duet 2 works 100.000000000000% and I mean all the tiny last corner cases directly or indirectly related to motion.

I'm sorry, IMO you have an unrealistic expectations, especially in the middle of a pandemic which has seriously affected electronics manufacturers, including Duet3D.

Motion-related issues are of course our priority. I am not aware of any significant motion control issues, apart from a recent report of a small (3% in RRF 3.1.1) over-extrusion when a high value of pressure advance (1.0) is used.

So please do take your business elsewhere, because it's clear that you will never be satisfied. Good luck finding a supplier who can satisfy you. Maybe if you pay 2-3x the price for your boards and also pay a hefty support contract, you will find a manufacturer who will provide you with a fix for 3% over extrusion with high PA less than two weeks after a user has reported it as a problem in current firmware.

[A Former User]

I think everyone needs a hug ...!

[Edgars Batna]

@dc42 said in RepRapFirmware 3.2 planned improvements:

@Edgars-Batna said in RepRapFirmware 3.2 planned improvements:

Well, I won't buy or recommend a single Duet board until Duet 2 works 100.000000000000% and I mean all the tiny last corner cases directly or indirectly related to motion.

I'm sorry, IMO you have an unrealistic expectations, especially in the middle of a pandemic which has seriously affected electronics manufacturers, including Duet3D.

Motion-related issues are of course our priority. I am not aware of any significant motion control issues, apart from a recent report of a small (3% in RRF 3.1.1) over-extrusion when a high value of pressure advance (1.0) is used.

So please do take your business elsewhere, because it's clear that you will never be satisfied. Good luck finding a supplier who can satisfy you. Maybe if you pay 2-3x the price for your boards and also pay a hefty support contract, you will find a manufacturer who will provide you with a fix for 3% over extrusion with high PA less than two weeks after a user has reported it as a problem in current firmware.

Oh, except that I reported the problem years ago and actually no word for an actual fix was in any release notes. Again, just excuses.

I am my own support contract.

[dc42]

@Edgars-Batna said in RepRapFirmware 3.2 planned improvements:

Oh, except that I reported the problem years ago

Are you referring to the same problem, or a different one?

[Edgars Batna]

@dc42 said in RepRapFirmware 3.2 planned improvements:

@Edgars-Batna said in RepRapFirmware 3.2 planned improvements:

Oh, except that I reported the problem years ago

Are you referring to the same problem, or a different one?

The same problem. Older firmwares it was worse than 3% and if you're not careful the number goes up. The 3% is just what that particular user reported. My tests show like 200%, but I don't have fancy tools spitting out numbers and I've been complaining for long enough to be dismissed.

[Phaedrux]

@dc42 said in RepRapFirmware 3.2 planned improvements:

@Edgars-Batna said in RepRapFirmware 3.2 planned improvements:

Oh, except that I reported the problem years ago

Are you referring to the same problem, or a different one?

https://forum.duet3d.com/topic/14969/another-crack-at-extruder-problems?_=1600197084248

[dc42]

I've reread that thread. Ths jist of it sees to be that @Edgars-Batna thinks that with certain prints using gyroid infill, the CPU can't parse the GCodes fast enough to keep up with the print speed. This in turn causes jerky movement, which PA tries to compensate for but doesn't do very well because of the short moves.

I also see a M122 report with a fairly high hiccup count. However, I didn't see a config.g file included in that thread. Without that, I can't see whether the microstepping has been set too high, which might explain a lot.

The other thing I would like to see is an analysis of the feed rates within the sequences of short moves. Some slicers are very bad at maintaining constant feed rate within sequences of short moves, and that will also lead to jerky movement, especially when high values of PA are used.

[Edgars Batna]

@dc42 said in RepRapFirmware 3.2 planned improvements:

I've reread that thread. Ths jist of it sees to be that @Edgars-Batna thinks that with certain prints using gyroid infill, the CPU can't parse the GCodes fast enough to keep up with the print speed. This in turn causes jerky movement, which PA tries to compensate for but doesn't do very well because of the short moves.

I also see a M122 report with a fairly high hiccup count. However, I didn't see a config.g file included in that thread. Without that, I can't see whether the microstepping has been set too high, which might explain a lot.

The other thing I would like to see is an analysis of the feed rates within the sequences of short moves. Some slicers are very bad at maintaining constant feed rate within sequences of short moves, and that will also lead to jerky movement.

That thread is related, but it's more about the image here: https://forum.duet3d.com/topic/16840/printer-refuses-to-do-a-certain-print/6
I created threads well before that on this topic. Without any hard guarantees from the Duet team it's impossible to navigate out of this error.

So it's alright that @Edgars-Batna has problems? He's insignificant, after all.

[bot]

@dc42 I made a custom build/branch of PrusaSlicer that remedied exactly this extrusion rate inconsistency.

I have other problems, most of which seem to be slicer related, to deal with before I can make any conclusive-sounding statements, but I, too, have always struggled to get the results I expect with PA.

I think there are many pieces to the puzzle that are problematic, many of which are not Duet's fault: faceted STLs of poor resolution, Gcode with inconsistent rates and poorly-rounded X/Y coordinates, janky hardware using not-even-close to appropriate construction methods and/or materials.

So, let's give the Duet team a slight break and give them the credit they are due: Duet and RRF are an amazing achievement already as-is. Let's try to make it better together.

I'm starting with the slicer. With garbage GCode we can get nothing but garbage prints. Once we have purely perfect GCode sliced with a methodology that is sound, we can start pointing the fingers at other things.

[dc42]

@bot said in RepRapFirmware 3.2 planned improvements:

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

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

• RRF3 is much more flexible and extendable than RRF2 was
• We don't have the resources to continue developing two distinct firmwares
• We've already done one maintenance release of v2 (2.05.1) and will likely do another
• RRF is open source, so anyone who wants to is free to continue developing v2