Another crack at extruder problems

Edgars Batna

@bot said in Another crack at extruder problems:

@Edgars-Batna 2.05.1 seems fine, but I would not go to 3.0 if you are "not happy" with how your printer acts with 2.05.1. You'll have so many more "unknowns" that it will be even worse to try and troubleshoot.

Quick test with the EccentrigGearTest GCode on 2.05.1 actually appeared to run way smoother. Will run more tests with it. The "problems" are so deceptive I'll need a few kilos of filament before knowing if it actually works.

bot

@Edgars-Batna I know how it is man. The past two months I've been printing the same stuff non-stop trying to converge on the perfect balance of speed vs quality... and it's driving me insane. I'm getting close to accepting a set of values.

It's all about compromise. Choosing values to optimize for and then accepting the reality that nothing will be perfect. I mean... I can print an absolutely PERFECT print... it'll just take days longer than ~~it should~~ I would like.

Edgars Batna

@bot said in Another crack at extruder problems:

@Edgars-Batna I know how it is man. The past two months I've been printing the same stuff non-stop trying to converge on the perfect balance of speed vs quality... and it's driving me insane. I'm getting close to accepting a set of values.

It's all about compromise. Choosing values to optimize for and then accepting the reality that nothing will be perfect. I mean... I can print an absolutely PERFECT print... it'll just take days longer than ~~it should~~ I would like.

I just printed a small test figurine and it was PERFECT at 60mm/s and 1.25 PA. I went on to print a bigger piece that's been failing and it clogged itself on gyroid infill, as it appears. It's a print with very long 120mm/s moves and it appears as if extrusion was inconsistent around beginning of perimeters, but went to be really consistent in the middle of the perimeter moves.

Afterwards I ran M122 and saw peculiar things in the log: console.txt

Running 2.05.1.

This and other variations where config.g does not make it to its destination keeps happening:
19.3.2020, 21:17:35: : Error: Failed to rename file or directory 0:/sys/config.g to /sys/config.g.bak

Can we please get screw terminals already, I'm tired of these crimp connections:
20.3.2020, 00:32:41: : Warning: motor phase A may be disconnected reported by driver(s) 1
Warning: motor phase B may be disconnected reported by driver(s) 1

What happened here, I saw my printer reset yesterday evening for no apparent reason, and here it is, didn't know a heat task can get stuck:
Last software reset at 2020-03-19 19:29, reason: Heat task stuck, spinning module Platform, available RAM 10536 bytes (slot 1)
Software reset code 0x40a0 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f80f BFAR 0xe000ed38 SP 0x200049ec Task 0x4e49414d
Stack: 0044d797 0043f178 01000000 3f800000 40418666 00000000 00000000 3ff78a38 41400000 3e178897 3e1cd04f bd564f13 3e3a336f 3e638e76 3e924953 3b33684c 395debbd 3f800000 3f800000 20000011 0043f01b 00000000 00424ba3

Is this alright:
Slowest loop: 143.02ms; fastest: 0.07ms

How about this, does it mean something? This is the first firmware that I see reporting hiccups:
Hiccups: 5120, FreeDm: 160, MinFreeDm: 113, MaxWait: 285267ms

Post mortem of the print: a whole layer is missing. Multiple blobs in layers below. Then the printer recovered and printed 3-4 layers mid air before I came over to check on it. Is it trolling me? Should I drive it to a recycling dump?

bot

@Edgars-Batna The hiccups are because you are running too fast.

Your PA/Accel/Jerk/Feedrate values are commanding too much movement. It's too much to physically handle (extruder) and it's too much for the pulse generation.

That's not to say that it's unable to read the gcode lines fast enough, but that it can't generate steps fast enough for what you are asking.

Edgars Batna

@bot said in Another crack at extruder problems:

@Edgars-Batna The hiccups are because you are running too fast.

Your PA/Accel/Jerk/Feedrate values are commanding too much movement. It's too much to physically handle (extruder) and it's too much for the pulse generation.

That's not to say that it's unable to read the gcode lines fast enough, but that it can't generate steps fast enough for what you are asking.

I understand, BUT how should one know when this will happen? The machine should have some sort of logic in place to slow down or state clearly that a section is too fast when this happens. There is absolutely no indication that it goes too fast until it's too late and kilos of filament are wasted. I'm not sitting 40 hours in front of a print, and, with all the fine tuning required, it's harder to know where it's too fast than it should be.

bot

@Edgars-Batna The hiccups are exactly the firmware indicating and dealing with the problem.

The hiccups are delays of 50 microseconds in order to attempt to delay enough to have time to catch up.

Essentially, the firmware is acting as best as it can given all the circumstances. Now that you know there is a problem it is up to you to slow things down when there is a problem.

I suggest you periodically send M122 during a long print to see when the hiccups are occuring, if you don't wish to try slowing down random parts first.

But let's talk about pressure because I think this proposed change could actually help a lot.

I think the proposed change to pressure advance could basically only be placed where a retraction is -- in between the retract and unretract movements.

This is essentially dynamic retraction but for only a specific circumstance: feedrate change of print moves.

Edgars Batna

@bot said in Another crack at extruder problems:

@Edgars-Batna The hiccups are exactly the firmware indicating and dealing with the problem.

The hiccups are delays of 50 microseconds in order to attempt to delay enough to have time to catch up.

Essentially, the firmware is acting as best as it can given all the circumstances. Now that you know there is a problem it is up to you to slow things down when there is a problem.

I suggest you periodically send M122 during a long print to see when the hiccups are occuring, if you don't wish to try slowing down random parts first.

But let's talk about pressure because I think this proposed change could actually help a lot.

I think the proposed change to pressure advance could basically only be placed where a retraction is -- in between the retract and unretract movements.

This is essentially dynamic retraction but for only a specific circumstance: feedrate change of print moves.

I see what you mean, but I suggest at least a list of offsets in the gcode file so that one can analyze this better.

In any case, your proposal is reasonable, now we need a firmware with this change implemented to test it.

dc42

@Edgars-Batna, I apologise for the long delay in returning to this thread. COVID-19 resulted in a huge increase in forum traffic, and at the same time one of our support engineers had to greatly reduce the hours he works for us in order to look after children who were no longer able to go to nursery. The forum is now back to a more normal level of traffic.

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

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

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.

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.

HTH David

Edgars Batna

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.

droftarts

@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

Edgars Batna

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