Hi all - I took bits of all your responses and ended up making a tuning macro that brings the chamber temperature to my normal printing temperature first and then runs the autotune. When actually printing, I've adjusted my gcode to bring the chamber to temperature first (in serial) before heating the bed, rather than in parallel as I did previously. Overall print time has gone up a bit, but a single heatup in the morning and then leaving it like that all day isn't too bad.
Thank you!
After playing with it a bit, I've been able to reproduce the problem using both Marlin and RRF M221 syntax, so I don't think that's it.
Any other ideas about what this might be?
I think you might be right - Ideamaker is targeted at Marlin, and M221 T0 is the correct syntax for Marlin gcode. I will play with it a little and then open a bug with them if that is what it turns out to be.
Good catch!
Re: Extrusion factor in DWC overrides slicer flow rate %
I am able to sporadically reproduce what OP in the above thread was talking about - a Duet 2 Wifi and RRF 3.4 will occasionally (I can't tell what conditions must exist for it to happen) override the extrusion factor in the gcode file used by Ideamaker. By default, Ideamaker uses a M221 command to set the extrusion factor at the beginning of the gcode file rather than adjust the individual G1 E values (although, this can be changed in settings).
When the gcode file works as designed, I can observe that the extrusion factor is at 90 (or whatever is called for) in DWC. Other times, the extrusion factor will stay at 100 and it would appear that the M221 command is ignored; in these cases, over-extrusion is visible.
The same gcode file will yield different results depending on...something. I'm not exactly sure what.
Sample gcode with M221 command at beginning:
default-box_FI_POSG2_ASA+GF_nd0-3.0mm_nd1-2.5mm_lh-2.0000mm.gcode
Note that this is a pellet extruder and E-steps are set at the factory (and I'm not entirely sure how I'd go about doing that calibration anyway to be honest). Flow rate calibration is the only way to control the relative amount of polymer being extruded on a move.
Any ideas as to why this happens?
Hi all - I took bits of all your responses and ended up making a tuning macro that brings the chamber temperature to my normal printing temperature first and then runs the autotune. When actually printing, I've adjusted my gcode to bring the chamber to temperature first (in serial) before heating the bed, rather than in parallel as I did previously. Overall print time has gone up a bit, but a single heatup in the morning and then leaving it like that all day isn't too bad.
Thank you!
Hello,
I've got a 1000mmx1400mm aluminum bed in an enclosed chamber with a 4400 watt heater on a Duet 2 WiFi running RRF 3.4.0.
I've noticed that when running autotune (M303 H0 S100), the first few measurement cycles take significantly longer to oscillate between 95 and 100 when compared to later cycles (which can take advantage of a 20C increase in chamber temperature, just based on how long the heater has been active) which are much shorter. As a result, when the tuning completes, it warns me that heater performance has been inconsistent and provides the new tuning values. When I apply those tuning values and run a print from a cold bed, it always throws a heater fault, presumably because those tuning values are favoring the later heating cycles during the autotune, which are taking advantage of much warmer ambient temperatures when compared to the beginning of the cycle, and thus the firmware is expecting it to act as if ambient is 20C warmer than it actually is.
My question is this - what is the technically correct way to account for this during the tuning process? I have had some success just leaving all of the doors on the enclosure open to allow the heat to dissipate during tuning, but it seems like there should be a more elegant solution.
Any tips are appreciated,
TIA!