RepRapFirmware 3.2 planned improvements

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

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.