Another crack at extruder problems



  • @bot @Phaedrux This is an acknowledgment of attempted unintentional thread hijack, sorry.

    This is a continuation of the big old threads about extruder skipping steps. For those up for a long story (in reversed chronological order):

    1. https://forum.duet3d.com/topic/11386/duet2-cpu-struggling-to-keep-up-with-this-gcode/19
    2. https://forum.duet3d.com/topic/10435/still-can-t-print-due-to-extruder-steppers-skipping-steps/12
    3. https://forum.duet3d.com/topic/8672/extruder-motors-skip-steps-with-pressure-advance-enabled/72

    @dc42 My case is that the Duet 2 may run out of CPU with PA set on high value on small segments. My analysis with poor man's debugging from last year showed that DDA ring gets exhausted and new GCodes cannot be processed fast enough to replenish it, hence the extruders receiving stuttery steps and eventually losing them. The GCode parsing takes longer than the step execution. On my printer with current settings it occurs nearly always on Gyroid infill mostly somewhere above 60mm/s. Reducing speed just reduces the CPU load and probability of this issue occuring, it does not fix the problem completely. I tried alleviating the problem but found out I'd need multiple GCode states and buffers, which would fill up the RAM and even then the CPU would be too slow. Additionally, there is some error accumulating and causing extruders to turn backwards. Read the information below first, tho.

    @bot said in Enhancing pressure advance:

    For @Edgars-Batna, I would suggest trying a much lower E jerk value.

    With M566 E100:100 the printer is much more silent, almost purrs like a cat, but this is mighty slow on them corners. But again, it's only slow if pressure changes... I had to also change PA to 1.5 for the start & end segments to be tidy.

    @deckingman said in Enhancing pressure advance:

    @Edgars-Batna Just a random(ish) thought but that combination of lowish extruder acceleration and especially that low "jerk" might be limiting the pressure advance which is why you need such a high value. What happens if you double the extruder jerk and acceleration but halve the PA? But then IRC, don't have your extruders in push-pull configuration? In which case, I'm wondering if they might get a bit out of sync when PA is applied so end up fighting each other? Can you run with just one extruder to test? Just another random thought.....

    If I increase the E jerk then the printer sounds a like a self-hammering ticking nuclear bomb. The extruders are 5cm apart, it's basically a multi hobb configuration. I've tried single motor before and saw no difference regarding the issue.

    Now, all things considered, I'm running my own 2.02.3 firmware with some changes. If I install official 2.02+ then the printer explodes spectacularly, mostly on first layer. Right now I don't know what next. I could tidy up my local changes and put up a patch, but how comes I'm the only one with the problem...



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

    but how comes I'm the only one with the problem...

    Random ideas

    1. % of ppl using high PA is low
    2. % of ppl using moves under .1mm is also low

    combining [1] and [2] gives only you



  • @arhi said in Another crack at extruder problems:

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

    but how comes I'm the only one with the problem...

    Random ideas

    1. % of ppl using high PA is low
    2. % of ppl using moves under .1mm is also low

    combining [1] and [2] gives only you

    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 do not doubt in capability of Duet's programmers, just that the method is getting older by the day and it's infuriating on my end. Just what are we trying to save here? Cents on the CPU? The printer already runs at multiple hundreds of Watts and any reoccurring error wastes kilos of filament. Please, not the rant again... I'd rather focus how this can be fixed. Personally I'd never use a CPU below 4GHz and 8GB RAM these days.


  • Moderator

    Can you post your config and a sample gcode file that produces the issue?

    Can you provide some details on the extruder arrangement. Motors, etc.

    I know lots of that info is in the other threads but having the latest info all together here would be helpful.

    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 have been printing at high speeds, with tiny segments and have not experienced this issue.

    You have to face reality: PA applies an artificial, instant adjustment to the extruder position. You are selecting a combination of settings that is asking the extruder to move fast enough to sound crazy. Whatever changes you made to the firmware must have reduced the magnitude or frequency of your settings requesting moves that sound like hammer drills.

    I'm not sure why you think you are encountering limits with parsing g-code or the like... I don't think that's the case. I think you're simply (like I've said in other threads a year ago) asking your extruder to do things it physically can't. Period.



  • @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 🙂



  • 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



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



  • 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! 😊



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



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



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



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



  • @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?



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



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



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



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


Log in to reply