Issues with mix ratio and feedrate
-
@bwoods That sounds like a very difficult thing to do. I can see how you might be able to synchronise your "decoupled" extruders with the robot axis when the feed rate is constant, but how do you synchronise the extruder accelerations and decelerations, with the robot axes accelerations and decelerations?
-
@deckingman short answer is we don't really consider the extruder's acceleration/deceleration; it simply hasn't been an issue for us yet. Slightly longer answer is we queue up extrusion commands before they are required to run; the benefit of this is that we never drop to 0 feedrate so the duet doesn't slow extrusion near the end of the movement, but the downside is that the synchronisation between the robot and the duet is incredibly important and has to be very precise. A good amount of work went into the streaming setup, and we are able to achieve very low latencies with it.
We also only use one actual stepper motor (for the fiber), the paste extruder uses different drives that are better at instantaneous speed changes (i.e., see the M566 settings for extruder drives 2 and 3 in the config).
-
@bwoods Understood. I would hazard a guess that you'd obtain best results by running as near constant speed as is practical (i.e high jerk, high acceleration, lowish speed).
-
@deckingman Your guess would be correct. We run near constant (~15 mm/s movement) speed while taking the hit on surface finish due to it, our application is not about pumping out as many models as possible so it's not a huge deal to us.
Hopefully in the future I'll be able to show publically some of what we are doing; I think it would be interesting to this group, and I'm sure it would bring about discussions about how we can do stuff better...but for now all I can say is we can print conformally with thermoplastics, UV-curable or reaction-curable thermosets, ceramics, pastes, etc., and (hopefully) soon any of those materials with continuous fibers for extra strength. Should be pretty cool....when I finally get it all working correctly lol -
@bwoods You sound like a man after my own heart. There has to be a better way than what is effectively just moving a hot melt glue gun around. I for one would be interested to see what you are up to, as and when you have something that you feel you could share.
Let me know if I was anywhere near the mark with my theory and suggestion about feedrate.
-
@bwoods said in Issues with mix ratio and feedrate:
My question is, what should the feedrate be when extruding two materials? I cannot find much, if any, documentation on this. Or am I going about this completely wrong?
In RRF 3.4, the time taken by an extrusion-only move when mixing is in use should be 60 * E_parameter/F_parameter. So if you have a mix ratio of 1:0.7698 and you execute G1 E100 F3000 then it should extrude 100mm from the first extruder and 76.98mm from the second extruder, in 2.0 seconds. RRF 3.3 was different, it would have taken the total extrusion amount as 176.98mm and taken longer.
-
@dc42 This does not seem to be true, atleast when sending G1 Exxx:xxx Fxxx commands (are these treated differently than G1 Exxx Fxxx commands with a mix ratio defined in the config?)
-
@bwoods yes it's different for G1 commands with multiple E parameters. For those commands, the move time should be based on the total extrusion because the mix ratio sum is not relevant.
BTW, RRF 3.5 supports inverse time mode experimentally.
-
@dc42 I can confirm that works! Does RRF 3.5 support inverse time mode for printing as well? The duet gcode dictionary says it is coming to 3.5 for CNC only.
For anybody that has this issue in the future that wants to use G1 Exxx:xxx instead of a mix ratio, you can calculate the feedrate by adding both E values then dividing by the expected movement time (in my case this is in seconds, so divide my 60 to get it in mm/min).
feedrate := (extruder1_E + extruder2_E) / (movement_time_sec / 60);
-
@bwoods inverse time mode will be supported in all modes, not just CNC.