Function to adjust printing temp relative printing speed
-
Are there any functionality in the FW today that can set the extrusion temperature between two limits depending on extrusion speed?
An example of what I want:MXXX D20 L1300 H9000 alternatively, an even better solution would be:
MXXX D20:15:8:5:3 L1300 H9000 (see below)
L is the lower print speed limit/break point
H is the upper print speed limit/break point
D (single parameter) is maximum temperature number of °C subtracted from the current extruder setpoint. This happens when
printing speed goes equal to or below the L parameter.Inside the speed interval there is a linear relationship between the amount of degrees °C subtracted from the current setpoint.
Below L, the D amount is subtracted in full. Above H, the setpoint stays untouched.D:t1:t2:t3:…. A list of breakpoints evenly distributed over the speed interval to enable a non-linear relationship relationship
between speed breakpoints and temperature reduction. The reduction between list breakpoints is interpolated.
The list can be of fixed/max size or arbitrary.This would come in handy when fast printing irregular parts that ends with a small "pointy" detail where the slicer slows the printer down
and the temperature are too hot for that speed resulting in that detail being deformed at best or a blob of plastic at worst./Thom
-
At first glance that looks like it might be a useful feature to have. The only issue I see is that within a move, there is an acceleration phase, a constant speed phase and then a deceleration phase. So for any given move, the extruder will see a range of speeds and of course the heater cartridge won't react fast enough to respond. Then we have retractions and unretractions as well. I guess what I'm trying to say is that the extruder speed might be constantly changing and the actual temperature will always lag behind the demand temperature by quite a few seconds due to the thermal inertia of the system. Especially when the hot end has to cool.
-
Is this similar to velocity painting method?
-
At first glance that looks like it might be a useful feature to have. The only issue I see is that within a move, there is an acceleration phase, a constant speed phase and then a deceleration phase. So for any given move, the extruder will see a range of speeds and of course the heater cartridge won't react fast enough to respond. Then we have retractions and unretractions as well. I guess what I'm trying to say is that the extruder speed might be constantly changing and the actual temperature will always lag behind the demand temperature by quite a few seconds due to the thermal inertia of the system. Especially when the hot end has to cool.
I'm aware of that and I was a bit short on time so I didn't explain as much as I should have. It's a slow process with considerable dead time. This function is intended to step in when the slicer reduces the overall speed to maybe 40% (my setting for PLA) when the layer time goes under a specific time limit. I was thinking that you could can use the "F" parameter in the G1 command that the host is constantly feeding into the printer. Design a FIR, IIR or Kalman filter to average the speed parameter over time using a time constant (this can maybe also be set in the same command) and feed this integral into the algorithm. I think that the time factor for the averaging filter should be in excess of maybe 10-15 seconds to be of practical use thereby matching the step response time of the hotend itself.
I have done this manually on the fly many times successfully, watching the print progress but it's tiresome and could be automated relatively easy.
-
The problem I see with doing that is that the firmware needs to know whether or not a speed increase is coming up. if a lot of small moves cause the temperature to be reduced and then suddenly there is a fast move, the temperature will be too low, the nozzle won't heat up fast enough, and the extruder may skip steps or grind filament due to the extra back pressure.
I can see two solutions:
1. Do this function in the slicer instead, or in a GCode post processor.
2. Have the firmware read ahead a long way. I already have this planned for the future because it has other applications, e.g. advancing filament mix changes as Ian has described, and heating tools up in advance of switching to them (Cura does this already, but it would be more accurate if done in the firmware). But I won't be implementing this at least until after RRF version 2.0 is released, and perhaps not until the next generation Duets are available because of the increased RAM it will need.
-
The problem I see with doing that is that the firmware needs to know whether or not a speed increase is coming up. if a lot of small moves cause the temperature to be reduced and then suddenly there is a fast move, the temperature will be too low, the nozzle won't heat up fast enough, and the extruder may skip steps or grind filament due to the extra back pressure.
I can see two solutions:
1. Do this function in the slicer instead, or in a GCode post processor.
2. Have the firmware read ahead a long way. I already have this planned for the future because it has other applications, e.g. advancing filament mix changes as Ian has described, and heating tools up in advance of switching to them (Cura does this already, but it would be more accurate if done in the firmware). But I won't be implementing this at least until after RRF version 2.0 is released, and perhaps not until the next generation Duets are available because of the increased RAM it will need.
You're right. But, if you have a "waist" in your object with steep overhangs you will likely have supports surrounding it and that will prevent the slicer from decreasing speed. If the overhang angle doens't require supports the hotend will catch up in time because the layer time will increase gradually due to the leaner angle until it has reached the layer time breakpoint. A special case can arise when the separation layer between the body and the support causes the layer time to abruptly go down but the next layer will be bridge or perimeter so it won't affect the averaging filter too much.
I here make the assumption that the perimeter/bridge is covering the same the same area as the supports do. Unfortunately, this cannot be taken for granted as most people strive to fit as few support pillars as possible so going that way is not exactly perfect or fool proof…
Simplify 4.0 3D has a feature for this called multiple profiles. It can perform this task but tends to be cumbersome to manage because of all the profiles involved. Once you change a "global" setting you will have to make changes to all profiles for the particular job. Having this function in the FW would solve this issue elegantly. But, until then S3D will be the fallback solution.
-
The S3D Slicer used with multiple processes isn't as smart as I thought. It just shifts the setpoint the moment the print sequence is transferred from the current process to the next. If this implies a speed increase and a temperature rise the slip/grinding problem will present itself the moment the transfer takes place as speed changes are immediate. The result is a clearly visible band in the layer where the transfer is made making it useful only when the transfer is placed co-linear to horizontal edges in the object, thereby hiding it.
-
Yes. I can't help thinking that, for this to work effectively you need to somehow measure or otherwise ascertain the thermal inertia of the hot end. Or more precisely the rates of change of temperature when the heater set point changes both upwards and downwards, and then be able to look far enough ahead in the gcode file to be able to initiate the temperature change early enough in the file so that the correct temperature gets used at the point where it is needed. Then you'd need the different sections of the object to be printable within the temperature change time window and even then, there will be sections that get printed during the temperature transition period. It would work if we had a fast response way of melting the filament but I think it's unlikely to work well with our current cartridge\block technology. We are also up against the thermal conductivity of the filament itself, which isn't good but of course that's the whole reason behind why you want to run higher temperature at higher speed.
-
Agreed. It's one complex challenge. One posible way to workaround is employing the same technique as when using dual extruders. Setup a small priming pillar and when a speed/temp change is executed (the Mxxx command is present in the start script), the head retracts/moves to the priming pillar and waits for the temperature to reach the desired level. Then performs
unretract->prime->nozzle wipe->retract->Z-hop>moveX/Y and continues print where it left off.Cura uses a variation of this method to prevent curling/warping when the layer time goes below the preset time,allowing the filament to cool a bit before continuing printing the next layer. The downside is that print time will increase and possible visible banding.
