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.