Issues with mix ratio and feedrate
-
@deckingman that makes sense, I'll give that a shot!
And just a bit more background, we are 3D printing with a robotic arm; the robot's motion is controlled with it's own controller and we stream extrusion commands to the Duet. The extrusion commands are calculated on the fly based on the desired layer height and road width, and the expected time it will take for the robot to make it to the next point (calculated by our custom slicer, taking into account the desired movement speed coupled with the robot's accel/decel rates when approaching corners and such). In essence, it is very similar to how a regular printer works, just with a separate controller doing the XYZ commands.@dc42 Because we calculate the flow/feedrate off of the time it will take the robot to move from point to point, supporting the upcoming G93 command for more than just 'CNC specific' systems would be very very useful....
-
@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.