Posts made by Edgars Batna

I have such a setup and one thing I noticed is that the tube needs to rotate way more, so that the couplers need to be way better or they will grind themselves and the tube on the outside, causing excessive play. If you had clogging problems, forget this setup right away. An E3D V6 and the likes are unable to cope with such play due to internal notches around the heatbreak-nozzle transition, for example (that may well be because E3D changed their design without explicitly telling anyone and I've got mismatched parts).

@droftarts said in Another crack at extruder problems:

@Edgars-Batna While waiting for a firmware fix, for gyroid infill issues, there's also this, which converts all those little line segments to graceful arcs: https://github.com/FormerLurker/ArcWelderPlugin
I think it can be installed as a slicer post processor, though not sure how. Seems like the gyroid infill 'feature' causes issues in Marlin firmware too!

Ian

I already tried this, although that was roughly 1.5 years ago. I might try it again now that we've got a proper slicer fork. The GCode needs to have very good resolution in the first place for this to even have a chance, plus any tiny segments not converted to arcs will cause the problem to be even worse than without arcs, because the GCode is now in way higher resolution.

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

Based on what I've found out so far, the next issue to tackle is the over-extrusion with PA enabled. There's another thread on this which should be tackled before tackling this one: https://forum.duet3d.com/topic/18412/rrf-2-03-pressure-advance-causes-20-overextrusion/109

For consistent extrusion to work, there has to be a decent resolution in the GCode. This increases the over-extrusion from 3% to multiple times more (no fancy tools at hand, but optically it's over 50%, it used to be even worse in older firmwares). That's exactly the problem, is that it's not consistently just 3%. In the other thread it started off with 20% and with various changes it dropped to 3%, but it's just a single print, not a general reading.

@dc42 said in Another crack at extruder problems:

I'm glad to hear that upgrading the firmware to 2.05.1 solved some of the problems.

The extruders run way better indeed, but there's still room for improvement.

Regarding hiccups, please post your config,g file so that we can see whether you are using appropriate microstep settings.

I've followed every single recommendation multiple times already. Increasing E resolution to 64 does next to nothing.

config_01092020.g

Regarding screw terminals, I'm sorry, we will not revert to them because OEMs absolutely hate them. Connecting wiring looms to screw terminals is an expensive (in time) and error-prone process, and screw terminals can loosen. Crimp connections done properly with an appropriate crimping tool and an appropriate wire gauge are reliable.

It's alright, I've learned to live with it.

Regarding gyroid infill, I note that in a previous thread you seem to think that RRF can't parse the GCodes fast enough in some situations with pressure advance applies, because the print slows down. Does it only slow down when using pressure advance? Using PA causes only a small increase in processor load. OTOH gyroid infill results in lots of very short segments of GCode. We know that in these situations, some slicers fails to maintain a consistent extrusion rate, and that plays havoc with PA. If that's the problem, the fix is for the slicer to maintain a consistent extrusion rate. This may be as simple as adding one more decimal place to the extrusion distance in the GCode. One of our users has already done this in a fork of PrusaSlicer.

Part of changes in that fork are based on my recommendations. I use that fork exclusively since it got available.

The slowdown is the place to analyze the issue, as I believe it's related to over-extrusion. It's a crash/smoke test - just slap an insanely detailed GCode onto the RRF and see what breaks. All of it needs fixing.

I also have my own RRF 2.0 fork where I tried to fix the over-extrusion for my printer and add some experimental features. It might be hard for you to navigate for fixing just this problem, though: https://github.com/mdealer/RepRapFirmware/tree/simple_dynamic_retraction . The issues are not 100.0000000% fixed there, but alleviated to a usable degree on my printer.

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

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

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

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

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

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.

@jschall said in RRF 2.03 pressure advance causes 20% overextrusion:

@bot I tried to build PrusaSlicer before and gave up because of ridiculously huge numbers of dependencies on cutting edge versions of everything.

They have "noob guide" now. It's basically how it should be built, not really for noobs, but for anyone with a little bit of sanity left. I'm wondering why they even bother with having a guide; the steps can be semi-easily compressed into a batch file. Maybe they take pride in memorizing random things...

@jschall said in RRF 2.03 pressure advance causes 20% overextrusion:

@Edgars-Batna That's why I went to the logic analyzer, because I knew it would just be constantly dismissed as a mechanical issue if I didn't remove everything mechanical from the equation.

Forgot to mention that my observations also indicated that there's not enough CPU to keep up with tiny moves + PA on the Duet 2. This was also why I stopped debugging.

As for using Bowden, yeah, sort of "forget it". BUT, this issue is not limited to Bowden. As far as I could tell there is no way to completely avoid the issue, but resolution (and in turn the CPU usage) makes it worse.

It is possible that some trivial printers out there sort of work, but, the same way as my prints were dismissed as "not real", I'll just pretend those people don't exist either.

@jschall Yeah, I created various topics, but it wasn't easy separating printer from firmware, as my build wasn't as polished back then. It was mostly treated as a printer hardware issue. Just look at topics created by me and you'll see multiple threads.

This is the latest one: https://forum.duet3d.com/topic/16840/printer-refuses-to-do-a-certain-print

I added detailed logging to the firmware in the meantime and wrote a program which counts how much extrusion the movement planning actually wants to command and it added up. The only thing left were the step interrupts themselves and the barely understandable second part of DriveMovement::PrepareExtruder (PA step computation) in the code. Without means to analyze stepper signals I stopped debugging.

I had analyzed this issue multiple times before as well and 2.05.1 had only minor improvements related to PA. Based on my findings something happens on the step generation level, probably CPU running out, causing moves to be done before reverse motion (there is some code in there that basically aborts moves before they are done, you'd need to analyze it yourself as I've wasted more time than I'd like already and I have no means of analyzing stepper control). I eventually gave up using PA on my printer as it ALWAYS overextrudes for me and I've ruled out every mechanical issue, too.

I think that it will get worse, if you upgrade to 3.x, as it probably uses more CPU.

I have resorted to printing without PA now. In my case I observed that the extruder reverse motion gets skipped on consecutive small segments, thus all my over-extrusion issues ensued.

I also dug in the Firmware and at some point it just stopped being fun as there are multiple approximations related to step generation which smell bad. Having no handy HW simulation tools it just took too long to debug with all the variables.

I saw Klipper implements "smoothing" for PA, so I started moving to it to test it out. While there are pros and cons between Duet and Klipper (I still like the Duet), but at least in Klipper the CPU basically only runs the step pulses, so no need to deal with interrupts being late or whatnot.

Not finished yet, tho.

You can try carefully removing the sticker and see if there is a hole on the old fan. Oil it and it will work like new. Then tape it over with something that holds well.

But I suppose it's not necessarily a mechanical failure here...

@bot said in Volumetric extrusion vs. Standard extrusion:

In what cases do you use these volumetric amounts, Edgars?

It's easier to get to volumetric rate. I did a few scripts over time to test stuff and I usually let it output various information related to extrusion without having to specify extra parameters. But, all in all, it really doesn't matter that much.

The Chinese used to ship crappy filaments, so I used to change diameter in the firmware. The last few batches have been spot on 1.75, though.

Using volume to describe an amount of material feels natural. That the printer doesn't currently care and has to convert this value back is a technical detail not worth noting. If I use post-processing scripts, then it's easier to work with volume.

All just preference, I guess.

@Phaedrux Extruder motors are not affected by M569 B, F, Y, as the second part is commented out.

@theruttmeister I'm past this phase of troubleshooting. I was printing at basically 20-30mm/s. The hotend is rammed so hard that the molten plastic is flowing upwards, I'm sure of it.

Also, a low value of S0.05 should not cause so much extrusion.

Please, someone follow my request and try print this on a CoreXY Bowden.