RepRapFirmware 3.2 planned improvements

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

dc42

@Edgars-Batna said in RepRapFirmware 3.2 planned improvements:

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

All our users are significant. However, I give less credence to those who seem to be demanding 100.00000000% perfection.

I'm sorry that I didn't respond to some of your posts, in particular the one that @Phaedrux linked to.

Edgars Batna

@dc42 said in RepRapFirmware 3.2 planned improvements:

@Edgars-Batna said in RepRapFirmware 3.2 planned improvements:

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

All our users are significant. However, I give less credence to those who seem to be demanding 100.00000000% perfection.

It's a moving average. Once a huge print fails due to this 0.00001% use case the reliability falls to way lower momentarily. I see this very simply - if there is a problem, acknowledge it, document it, try fixing it. All we do here instead is wasting energy describing ins and outs of cake icing odor over and over again.

dc42

Maybe I've missed the relevant post from you, but i am not clear what problem you have reported that causes prints to fail.

Edgars Batna

@dc42 said in RepRapFirmware 3.2 planned improvements:

Maybe I've missed the relevant post from you, but i am not clear what problem you have reported that causes prints to fail.

That's part of the issue - Duet team is unable to reproduce some of the use cases reported. These are use cases, which the Duet enables. You should have a mechanism in place to investigate. I'm otherwise very confused at what information you really need, because I provided it all. I won't open yet another thread on this.

T3P3Tony

I think its clear that we have both issues that are known and need the time to fix, and some amount of issues that are not captured, or if captured we are not showing publicly that they are captured.

We will consider how to improve capture of issues and also issue visibility.

A Former User

@T3P3Tony said in RepRapFirmware 3.2 planned improvements:

We will consider how to improve capture of issues and also issue visibility.

On this point I think it's transparency and recognition that an issue is occurring that would help.

I also support the already mentioned point that the duet team should really be focusing on and prioritise getting the core functionality of the firmware for duet-3 ecosystem fully operational before diverting time and resources towards superfluous things.

But hey lets look on the bright as it stands it you might be able to have a led light show up and running before being able to run auto tune on heaters on a toolboard.....

NexxCat

There's a lot of negativity aimed towards the devs here. I just wanted to say that any time I've had an issue, the community and people like @dc42 and @T3P3Tony have always helped as best they could. No-one knows everything and no-one can be expected to filter through a huge forum and constantly keep track of every bug. Any time I've reported, or seen reported by others, a wide spread problem, it has been investigated and fixed very promptly, far faster than you get from 99% of companies out there.

I used to be a software developer. You can't always replicate a problem right away, and in general if you can't replicate it you can't fix it. That makes the people affected mad, of course, but most times those people are experiencing edge case problems with atypical setups.

You can't honestly expect the devs to have a Duet powered printer on hand for every type of kinematic the firmware supports, especially when you then add the myriad of different supporting electronics into the mix.

When it affects you, I know it feels like your problem is being ignored, but software development isn't easy at the best of times, let alone embedded development of something this complex.

bot

@NexxCat said in RepRapFirmware 3.2 planned improvements:

[...]

You can't honestly expect the devs to have a Duet powered printer on hand for every type of kinematic the firmware supports, especially when you then add the myriad of different supporting electronics into the mix.

[...]

Wait... what?

I guess it's not currently the case, but how could we not expect that? This is what is frustrating -- features are implemented with literally zero testing.

Making the cheapest-as-chips "RepRap" style machine in every supported kinematic is not at all a far-fetched idea. The devs should absolutely have an example of every kinematic on hand.

Really, there should be a big magical shelf. On this shelf is a janky but working example of every kinematic type, attached through a "KVM" switch for 3D printers, to every single supported electronic configuration.

I'm not going to prescribe a testing regimen, but at this point it's quite silly to not be able to test a range of setups.

These machines should have easily swappable components to accommodate a small but succinct range of extruders, stepper motors, etc.

Also, (this may be more impractical than I first imagine) there could/should be a "library" of stepper motors that can be "switched" easily into a test rig. Perhaps users could send a physical example of a specific motor that they wish the devs to explore (for, like, OEMs or something. Can't have everybody send their motors in).

I'm sure much of this is already happening, but if it isn't I'd be happy to help achieve this goal in any way that I can. I can design things in CAD, and, umm, use a calculator and almost understand basic c/c++ syntax.

gtj0

Aren't there stepper motor emulators that you can connect the output of a motor driver to and collect things like rotation angle differences, directions, etc and feed them back to a computer? The same computer could also simulate endstop activation, temp sensors, etc.

Luke'sLaboratory

I'll throw my hat in the ring here -

I too am a dissapointed that a few of the key features I was looking for(ward to) did not make the cut, namely variables, on-expansion heater tuning, on-expansion filament sensors. In my opinion, those are the key things that I'd like fixed/added, other than the bugs that were quashed (bugs are bad, mmk?). I'm personally quite pleased with the addition of plugins (pending review of how they're implemented) for DWC. That's nice.

I also find it a struggle to find bugs and see if they're caught/working on them. I greatly appreciate githubs for both Marlin and Klipper as I can quickly search for current issues and see if mine is related/similar to what others are using.

I'm also kind of blindsighted by the low steprates. Maybe Klipper on most of my machines has spoiled me, but 20khz seems like something that should be listed as its a significant drop from duet2 and as a clear limitation of the current firmware.

I do appreciate the combined approach updating all 3 of the very integrated services (3.1 was very painful for SBC+D3 Users) as it made understanding what is needed to run very easy - all 3! However- its also very difficult to find all the things that could be the issue, whether its RRF3, DWC, or DSF.

As for issues/bugs versus config issues, I think we could learn something from klipper - Klipper logs include not only the operation logs (and errors), but also have a copy of the configuration baked in. If you post an issue, but do not have the log attached, it gets tagged as it needs the log and isn't looked at. Similar things could be required for github for duet - Basically - have a template that lays out how you're expected to communicate your issue (board, firmware, etc) expected result vs actual, and then have a requirement for config.g and a M122 output (or more for D3+more users) otherwise the bot goes "you don't get to play until you attach" and that can keep it down. That way, without any human interaction, every post will be filtered, and those who have incorrectly configured their machine can be spotted because posting config.g is a requirement to be considered at all. If its config, they can be addressed quickly and closed as "config probs" or directed to the forums to post. Or Hell - Have something that write something similar, at least for SBC users - Dumps config (and any loaded macros from the config) and a M122 in a single easy-to-download file. Would make diagnosing from both a config and a bug-catching aspect much simpler if it was something that was enabled by default and the expected behavior to even post/acknowledge "bugs"

I feel that there should be polls/feedback requests for feature adds and focus, and that can then be weighed versus effort/time to implement, and then a clear path can be decided on in a per-patch basis. I really do appreciate that there are pretty good notes with history of changes and the effort that goes in to maintaining those documents.

Thanks for listening to my .02!

Veti

@bot said in RepRapFirmware 3.2 planned improvements:

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

can you post a picture comparison of a print (benchy) with normal and your version?

Edgars Batna

@NexxCat said in RepRapFirmware 3.2 planned improvements:

There's a lot of negativity aimed towards the devs here. I just wanted to say that any time I've had an issue, the community and people like @dc42 and @T3P3Tony have always helped as best they could. No-one knows everything and no-one can be expected to filter through a huge forum and constantly keep track of every bug. Any time I've reported, or seen reported by others, a wide spread problem, it has been investigated and fixed very promptly, far faster than you get from 99% of companies out there.

Constantly analyzing and adjusting to these processes is the job of the managers. If they cannot capture this with their own eye, then they get honest feedback. I didn't jump to conclusions here, I gave the Duet team enough credit before.

I used to be a software developer. You can't always replicate a problem right away, and in general if you can't replicate it you can't fix it. That makes the people affected mad, of course, but most times those people are experiencing edge case problems with atypical setups.

Well, then welcome to year 2020. Machine learning will kill most of the developer jobs soon and there's nothing that we can't reproduce, test or simulate. Excuses again.

You can't honestly expect the devs to have a Duet powered printer on hand for every type of kinematic the firmware supports, especially when you then add the myriad of different supporting electronics into the mix.

Sorry, it's year 2020. Just as there are tools to simulate the MCUs, it's EZ to just buy the machine with the right kinematics. Also, we started off with just a few boards here, it's just that now we've got many.

When it affects you, I know it feels like your problem is being ignored, but software development isn't easy at the best of times, let alone embedded development of something this complex.

No question about that - it's complex. I completely understand what and how the devs are doing. The Duet 2 is the invincible workhorse in my printer.

There's a point where a reality check needs to be done.