Open agrif opened 6 years ago
You are right currently the plugin expects linear extrusion in mm. But it should be quite easy to extend it for volumetric extrusion. The parse()
function just needs to recognize the M200 and set a flag. When the filament weight is calculated we just skip the calculation of the volume if the odometer found the M200.
Providing any kind of setting is not necessary, because, as I understood it, the M200 command must be in the gcode file to enable volumetric extrusion.
The auto pause feature also has to be modified, of course.
I have no idea how common (or useful at all) it is, but it would be possible to use both volumetric and linear extrusion in a single gcode file. Maybe as the result of a tool that joins two gcode files together. If you choose to ignore this, that's totally reasonable, I just thought I would mention it.
Removed this feature from the milestone for now. I took a look at OctoPrint and it doesn't seem to support volumetric extrusion as well. I have to think it through a bit more if it would make sense in this case to implement this.
For what it's worth: I have successfully printed volumetric gcode files with octoprint before, and it seemed to work fine. Just the filament odometer failed to update correctly.
Yes, printing might work, but OctoPrint will show wrong information about the filament usage. This plugin will then subtract a different amount than what's shown and this is not desirable. This will most certainly lead to issues like "... showed X but subtracted Y".
I think the proper way to support volumetric extrusion is to implement this feature in OctoPrint itself first and then using the provided information.
Just for reference the feature request on the OctoPrint issue tracker foosel/OctoPrint#1432
Right now, the odometer ignores M200 Set Filament Diameter commands in the gcode, and thus doesn't work with volumetric extrusion.
I took a brief look at the odometer implementation, and it looks like the FilamentOdometer class currently measures extruder distance directly. My guess for the best way to add volumetric support would be to give the odometer enough info to figure out volume from linear extrusion distance, then change the odometer to track volume rather than distance. Then, it would be pretty easy to handle M200 by switching how extrusion is interpreted.
I would like my printer to default to volumetric extrusion: providing an odometer option to also default to volumetric would be nice.
I would make these changes myself but I'm unsure if my implementation idea works. Also, I am busy until 2018, so I thought I would open an issue first.