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

@bot I'm testing something on my side. Would you share a test gcode that demonstrates your use case, preferably with many layers. I sorta implemented what you suggested, but it's not that simple in the grand scheme of the firmware, so I would like to make sure I got it right before sharing code and firmware file.

Basically, I took your formula and added some averaging to the computations, since the whole thing has to be time-based to accommodate both long and short moves. Maybe I'm thinking too far, anyways, here are my test results:

Before:

After:

And I'm using a constant value of 0.5 - 0.4 (plus some other time constants because I think I had to).

On the side note: 2.05.1 is so much smoother when running near max step rate and high PA. Good work!

I followed some advice from here and got some results to report for reference:

1. Switching to a zero-crossing from random-crossing SSR did not visibly affect the light flicker issue.
2. Switching from bang-bang mode to PID at the bed heater did not affect the horizontal banding issue.
3. I was able to further tune the PID and keep light flicker to a minimum.
4. The Z axes construction was worse than I expected. I could measure +/-50% variation every Z motor revolution with just a basic electronic caliper. Apparently the Z screw rods were misaligned so just a little rod bend was being exaggerated.
5. The weight of the bed was high enough to press the Z stepper rotor downwards on high acceleration moves (this obviously depends on its construction), so I added some flange bearings at the bottom.
6. The Z smooth rods were not really smooth in the Z direction and needed some 800 or more grit sanding.
7. I remodeled and fitted bigger, bulkier variants of all brackets, couplings, etc on the Z axis.

Now after improving 2 out of 4 Z axes the banding is nearly gone!

I did a quick search, but didn't find anything regarding this. Let me know if this has been discussed.

The current implementation is good for most prints (simply perfect first layers), but there are cases when an elongated object has to be printed on a large, but not all too even bed. I've got a 500x500 sheet aluminum bed which is +/-0.2mm on good days and +/-0.8 if I had a few beers and working on the machine.

If I understand correctly, grid compensation is applied at all times in the current implementation (v2.02). This causes objects to be always skewed depending on the height map. If this is true, then I propose a new mode for the mesh grid compensation where it would gradually decrease the height map to 0 by some configurable_amount * current_Z_height.

Actually, my immediate assumption when first reading about compensation was what I'm proposing. I think it's more intuitive. The first layer adhesion is 99% of why I'm using the compensation.

I do not consider myself an expert, but, since there are quite a lot of users of 1.x and 2.x now, perhaps a tool that upgrades the configuration automatically or semi-automatically would be useful? It could be embedded somewhere in the online configuration tool.

This is rather easy for you to test. You'll see the bed moving up and down.

I don't entirely understand how using magnets below an inductive sensor is a good idea at all. The magnetic field is escaping from the metal.

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.

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.

It didn't occur to me at first, but just wanted to add that I also had this issue when originally trying to use igus Drylin LMXUU bearings. What you're seeing is the axes trying to overcome the standstill friction. From what I learned so far, CoreXY is very susceptible to this since play in X and Y carriages allows the axes to momentarily shear instead of moving in the desired direction.

If you grab the belts on both sides with motors de-energized you should feel equal amounts of resistance while moving the belts by hand in all combinations and there should be no noticeable standstill friction when changing direction. I found that one of the symptoms that stuff is too tight is that the print head may entirely or momentarily move straight instead of diagonal when moving just one motor by hand.

Needless to say, I switched to el cheapo Chinesium LMXUU and got instant results...

@dc42 said in Duet 2 Pro 4 U:

The processor will have about the same power as Duet 2 but more flash memory and RAM to make room for firmware improvements.

Is there a significant reason to not upgrade the CPU further? It's better to have the power and not need it. Also, you know this better than I do, but more features / bigger code usually means longer critical path.

I've also seen Atmel offering dual core SAMs. That would be quite fun having some tasks not blocking each other so much.

Just brainstorm/-farting here.

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.