Best posts made by Edgars Batna

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

@bot said in Enhancing pressure advance:

@Edgars-Batna I'm not saying to reduce the PRINT speed... PA reduces the extruder speed, not the XY feedrate, unless applying the amount of PA requested exceeds the extruder jerk, then the x/y acceleration is adjusted. I'm saying to adjust the extruder position during retraction when moving from two vastly different feedrates.

The speeds can be matched up to equalize the feedrate. It's a computation detail.

Approximations are fine. Tinkering around to get it right is also fine. It might be a time waste in the grand universal equation scheme of things, but whatever. After all, 3D printing is itself based on approximations, so add or remove one or a thousand - doesn't change the soup overall.

I got 2.05.1 to compile today, might see what I can do for fun.

Is a Duet 2 with more oomph remotely plausible? I mean any sort of oomph, including, but not limited to, CPU, connectivity, stepper drivers etc. I didn't see anything being actively discussed anywhere.

Just a thought, if Duet 2 had more CPU and RAM and supported interpolation from any microstepping, that would halve the magnitude of my own usual headaches. it's not a complaint, just there are limiting factors.

I do like the self-contained nature of Duet 2. I could go Duet 3, but it's adding way more variables than advantages from my point of view.

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

This used to happen to me all the time. I went to https://akismet.com/contact/ and chose "I think Akismet is catching my comments by mistake". They got back quite quickly and resolved the problem within a day...

@bot said in Enhancing pressure advance:

@Edgars-Batna Nice work. Are you modifying only the unretract move or are you injecting movement somewhere else? The results look promising!

The unretract move acts as you described it, but the extrusion rate of last move and the created underextrusion were also a factor that required some more implementation or it ended up ugly. I think I implemented it this way:

1. The average extrusion rate of last 5 seconds is stored.
2. Unretraction move applies your formula.
3. The remainder of extrusion is stored for later.
4. The next moves are adjusted by the remainder, factored by move time. 5 second moves get the most of the extrusion remainder. Remainder is passed on from move to move.

Result is a small fixed amount of total underextrusion. There you see the time constants that could also be adjustable.

I can definitely share a gcode file that I am using to troubleshoot this. It's the top part of a real-world print I'm attempting. The problem occurs at the very first move after the skirt (which made it convenient for testing), but it also happens at other spots in the file where a slow perimeter is preceded by a fast print move like support or infill, namely on layers form about 94 and up, where the tops of the letters are being formed as individual islands.

Gcode here.

I'll try it as soon as my other test is finished.

@Phaedrux said in Enhancing pressure advance:

I can't help but notice the words non-newtonian haven't come up yet.

You mean we'll need a GUI to plot a graph when tuning filament by hand? Jokes aside, you mean that there might be no PA required up to a certain pressure or from a certain pressure depending on material and such? Honestly, I'm as good as Google on this topic, because I have to Google it all.

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

@bot said in Enhancing pressure advance:

@Edgars-Batna Nah dude. It works fine. Trust me, it's been tested thoroughly.

My extruder microstep resolution is about 0.00025 mm

[Edit: I mean, everything else works fine and there are no hugely obvious errors. For PA, I dunno maybe this messes it up but it doesnt seem like it.]

Alright, my extruders go at 0.00236 mm, but be warned. I also didn't understand why S3D only outputs 4 digits after comma...

I'd also be interested to see if my implementation does anything for you. For me it greatly reduced blobbing/stringing at the start of a move with C0.4, but I only ran two tests.

@bot said in Enhancing pressure advance:

As for trying the firmware, I'd love to but I'm scared!!! This is my only printer right now and if I mess it up I'll be crying more than covid-19 has be crying already.

Understandable, I usually have the hard power button in my hands when testing new stuff. Most of it is no longer new to me due to extensive trial & crash through my other topics, so I feel comfortable implementing this part of the firmware and the printer has enough flex already to not break entirely, but, yeah, every line of code is a bug.

@dc42 Could you please take a look if there is something hugely illegal:
https://github.com/mdealer/RepRapFirmware/commit/841e38d9ad39dc408d785f6b75ab3e6182344f02

0 mdealer committed to mdealer/RepRapFirmware

Implement dynamic unretraction.
https://forum.duet3d.com/topic/14927/enhancing-pressure-advance/76?_=1584866367558

@NitroFreak said in Layer shift detection?:

I have long asked dc42 why he focuses so much on integrated stepper drivers.
A cheaper board with no stepper drivers and only the pinouts for external drivers would be a real seller.
I am so happy with my nema23 servos, my next printer will have all axes equipped with it.
The servo is so powerful, it can accelerate my 5kg gantry with 5g (~50.000 mm/s²) if i want it to, and not a single skipped step in sight.

I think it´s a shame that the industry is moving towards linear servomotors already, and we can´t even adapt normal rotational servomotors yet.

I've had tons of discussions with people using servos who have never used an integrated stepper driver before. What they don't realize is that these integrated drivers already work close to how a closed loop system would, because they, pardon my Chinese, adjust the control parameters on the fly based on the back EMF and they are darn good at it. So good at it, that it's creepy.

You are right about servos, but integrated drivers have a place and are the cozy future. I'm impressed what they can do on my printer with Nema17. I think dc42 didn't think most people would try slapping multiple 10kg gantries onto them, and I think most people don't.