Another crack at extruder problems

arhi

@Edgars-Batna said in Another crack at extruder problems:

I know, but see it from another perspective. We're talking a not so big program, which reinvents the wheel at a few up to nearly all places just to accommodate a microcontroller. This should not be necessary anymore...

I dislike SAM MCU's but I love ARM core (both cortex m3, m4, m7 .. ), I also did not look in-depth into the duet source... The general view I made some time ago I did not like (tbh I don't remember why), and looking at few available cortex firmware's around I really only really like the smoothieware design, but it comes with a lot of limitation and also lacks bunch of features (no PA in any way there for e.g.)

Personally I'd never use a CPU below 4GHz and 8GB RAM these days.

Then the concept like Klipper is what you should look at. You ran all the calculations on the Linux computer that don't even need to have a real-time kernel and only the basic stepping is done by the MCU providing precise timings. You can run the basic setup on some SBC or you can use your 24 core 512G RAM desktop if you like

sebkritikel

Does this quick video (your EccentricGearTest 0 0.gcode file) represent the issues you face while printing (including the movement of the print head)?
https://www.youtube.com/watch?v=J-_RAQJW1kk&feature=youtu.be

I incorporated these lines into the GCODE file in an attempt to emulate your setup.
M207 S3 R0.0125 F20000 Z0.5 ;firmware retraction
M572 D0 S0.5 ; pressure advance (S) in seconds

Edgars Batna

@sebkritikel said in Another crack at extruder problems:

Does this quick video (your EccentricGearTest 0 0.gcode file) represent the issues you face while printing (including the movement of the print head)?
https://www.youtube.com/watch?v=J-_RAQJW1kk&feature=youtu.be

I incorporated these lines into the GCODE file in an attempt to emulate your setup.
M207 S3 R0.0125 F20000 Z0.5 ;firmware retraction
M572 D0 S0.5 ; pressure advance (S) in seconds

Thanks for trying it out. Yes, it sounds much like what I got, but less prevalent (probably due to different mechanics). For reference, the GCode:
EccentricGearTest 0 0 volumetric(1).gcode

The parts where we hear the "crackling" is basically undefined behavior.

In any case, here's a new vid of mine: (ignore the build crustiness): https://youtu.be/CddfoiOETS4

The loudness depends on the mechanics. I got these 3:1 reduction gears with a little backlash, so the mechanics sound like, I dunno, welding metal or percussion drill depending on listener position.

This is an extreme demo of a problem - Duet should slow down, but there's nothing implemented for it and it's actually non-trivial for the firmware. The worst that can happen is that the extrusion runs backwards enough to destroy a print.

In case someone is wondering about what the hell is going on in my build with the wood blocks, reduction gears, cables, paper, roll bearings etc, I went to lengths to ensure the machine works well, including no skips, no clogs, no grinding, true bed leveling and general well being in the mechanics before posting these topics.

@arhi said in Another crack at extruder problems:

I dislike SAM MCU's but I love ARM core (both cortex m3, m4, m7 .. ), I also did not look in-depth into the duet source... The general view I made some time ago I did not like (tbh I don't remember why), and looking at few available cortex firmware's around I really only really like the smoothieware design, but it comes with a lot of limitation and also lacks bunch of features (no PA in any way there for e.g.)

Then the concept like Klipper is what you should look at. You ran all the calculations on the Linux computer that don't even need to have a real-time kernel and only the basic stepping is done by the MCU providing precise timings. You can run the basic setup on some SBC or you can use your 24 core 512G RAM desktop if you like

Thanks, I'll check it out. I got a nearly 10 years old 4 Core 3GHz, 16GB RAM lying around without purpose and more scattered 16GB RAM sticks around the house, I could throw it all at the printer with enough force for it to weld to the Duet some time in the future.

@Phaedrux said in Another crack at extruder problems:

Can you post your config and a sample gcode file that produces the issue?
config_17032020.g
Can you provide some details on the extruder arrangement. Motors, etc.
2 extruders arranged 90 degrees to each other, driven by separate drivers in 50:50% mixing mode. Also, see the video.

At this point, development on RRF2 is slowed down to emergency fixes only. RRF3 is going to be the way forward. Have you tried testing RRF3 yet? Or even 2.05?

I think I tried up to 2.04, then gave up, because the firmware didn't actually get more efficient from my observations and I couldn't be bothered to unclog the printer every time.

sebkritikel

With that GCODE test we definitely have a lot going on.

Regarding the filament extrusion running backwards - It is my understanding (from what I have read here) that based on your (generic your, not saying specifically your system) system, it is perfectly acceptable to have the extruders running backwards during certain moves based on PA settings. However, 100mm is not normal, and I do NOT believe that is related to (or more specifically, DIRECTLY caused by) pressure advance. In my experience with BCN3D Sigmax machines, with bowden tubes of 865mm, a jam (or flow restriction) in the nozzle results in a high pitched squeal from the extruders, with the filament jumping backwards by a significant amount. The dual drive extruders on these machines are capable of compressing the fillament and stretching the tubes during a clog/jam, and when this back pressure is able to overcome the extruder motor. Based on your print temperatures (215°c or so right) I could definitely see jamming or clogging happening, but I'm sure you've looked at this.

Still a lot more to unpack but to be honest, I feel like its working as intended, that high value of PA should sound like gunshots going off (especially with NEMA23s). I'm far from an expert though!

Edgars Batna

@sebkritikel said in Another crack at extruder problems:

With that GCODE test we definitely have a lot going on.

Regarding the filament extrusion running backwards - It is my understanding (from what I have read here) that based on your (generic your, not saying specifically your system) system, it is perfectly acceptable to have the extruders running backwards during certain moves based on PA settings. However, 100mm is not normal, and I do NOT believe that is related to (or more specifically, DIRECTLY caused by) pressure advance. In my experience with BCN3D Sigmax machines, with bowden tubes of 865mm, a jam (or flow restriction) in the nozzle results in a high pitched squeal from the extruders, with the filament jumping backwards by a significant amount. The dual drive extruders on these machines are capable of compressing the fillament and stretching the tubes during a clog/jam, and when this back pressure is able to overcome the extruder motor. Based on your print temperatures (215°c or so right) I could definitely see jamming or clogging happening, but I'm sure you've looked at this.

I've taken care of all that multiple times.

Oh well, I'll bite the bullet again and update to latest firmware, fingers crossed. 2.05.1 first and if that goes well, then RRF 3.

bot

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

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.