Tuning the printing speed on fly

TuomasT

Hi,

We have a bit specific printing material (kind of a foam), which flow rate we cannot really control well. But we can (probably) measure the flow rate from the nozzle pretty accurately. Now we would like to be able to slow down or speed up the printer movements according to the flow rate. Even stop it completely for a short moments. So basically adjust the printing speed setting according to the external measurement.

Do you have any ideas on how this could be achieved most easily? Could we use some sensor connector to adjust the print speed, or would this be more like a software side thing to be done in rasberry pi?

Thank you in advance for all the help!

dc42

@TuomasT is your aim to limit the flow rate to a defined maximum? If so then we could add a firmware setting for that. It would need to be separate from M203 because the M203 command also limits the extruder speed for retract, reprime and filament loading moves.

You can adjust the printing speed on-the-fly using M220.

Tinchus

You have flow rate control on many slicers already (superslice foe example lets you set a max extrusio rate and set every type of path to use that max value. So in your case ofr example if you want to limit a 5 mm3/s of flow you can do it.

o_lampe

@Tinchus @dc42 I think, his intention is to constantly measure the slightly uncontrollable flow and change the printspeed instantly. (good bye planner queue)

fragrama17

@TuomasT thanks for posting this topic, I actually have a similar issue regarding print speed.

@dc42 we are already using M220 but we observed some delays even when printing straight lines;
we noticed though that, by assigning a really high jerk value using M566, we were able to reduce the delay to 2s;
without doing that, the algorithm takes a long time to change the speed of the print in order to preserve the jerk value of the machine (from what I read from RepRap docx file in GitHub).
is there a flag or configuration that we could enable to ignore/speed up the jerk check algorithm ? if that is not the root cause, is it related to how RepRap processes the g-codes queue buffer ?

dc42

@fragrama17 you should be able to speed up the response time when the machine is performing long moves by enabling segmentation. See the M669 command.

fragrama17

@dc42 I forgot to mention at the beginning that we had to enable segmentation (M669) in order to reduce the delay to 2s.

Are there any other options to reduce the delay ?

Tinchus

@o_lampe You cant do this. In the moment you measured the flow at the output of the nozzle, the gcode command will enter the queu... The flow modification wont be at the proper timming never ever.
In my opinion this is one of those request where the solution is being looked at the incorrect place. Just make sure you extruder works properly, your filament is in the proper state (dry) and you are done.

infiniteloop

@Tinchus

Just make sure (…) your filament is in the proper state (dry) and you are done.

What if the ”filament” isn’t dry but more or less ”foamy”? From the OP:

We have a bit specific printing material (kind of a foam), which flow rate we cannot really control well.

@fragrama17 Just my two cents: to reduce reaction times on flow rate measurements, you could perhaps try to shorten the movement queue length (see M595) or disable it completely with M555 ( M555 P6 - set nanoDLP compatibility mode). However, this can cause the printing movements to be a bit bumpy - sorry, never tried that myself, so this idea might not even be worth a penny.

MJLew

It sounds like it might not be possible to use the flow information to modify the print speed soon enough to work for you, but maybe you could use the flow rate information to modify the extrusion amount if you have a servo motor for the extruder instead of a stepper.

The inevitable delay between extrusion and the measurement of flow will be suboptimal for the control of the servo, but I dare say there are ways to deal with it.

Tinchus

@infiniteloop I have not tried this material of course, but I have indeed trying to shorten queu lenght in the past several times wheing trying make a macro introduce code faster in the queu for example. I can perfectly agree and confirm that printing becomes "bumpy". So, in the case of this talking about this material, if the movement suffers this kind of artifacts, for sure we can predict flow will be completly out of control because we can maka a paralel situation when you have moisture on you filement: can can get away sometiomes with lot of moisture, but at the moment the nozzle stops just for hal a second, you will see material being extruded A LOT.
From an engineering point fo view, when you face a develpment where at the very beginning the posible solution already faces a lot of problems... that is my sign to "ok, this solution will not end up well, lets look for another aprouch" and this is the case.
In this case, if you already recognize that the material has not a predictable flow, trying to control that chaos is something that will not get to a good solution. I would go towards try to get a better material, OR just not try to get a eprfect flow control.
Remeber this: this has already happened in the past. Maaaaany years ago, in the time where filament diameters where not as precise as today, opeple tried to use optical filament diameter sensor in order to measure diameter on the fly and adjust the flo on the fly. And that aprouch NEVER worked because you had to provide the firmware with the exact offset between the sensor position and the tip of the nozzle, and just an error of 0.2mm gives you more error on the flow calculation than a +-0.1 in fialment diameter so...
I still have one of those sensors by the way lol