M200 Volumetric extrusion bug

ChrisP

I use Duet boards on a number of systems with different material sources (not just filament diameters) and am looking at ways to make the G-Code I (and the others that use these systems) make system agnostic. As such, I want to be able to use volumetric extrusion (and eventually firmware retracts etc). However, I've yet to manage to print using volumetric extrusion and not have the output be massively over-extruded.

I use the filaments functionality of the Duet extensively and therefore it makes sense to have the M200 command in the config.g file. An alternative arrangement that is slightly less clever but also allows the use of standard length extrusion is to have a macro that is called from the start code in the slicer to enable volumetric extrusion for that particular file.

After a bit of testing today I've discovered that the only place I can put the M200 command to enable volumetric extrusion is in the print's gcode file. If I attempt to put it in either the config file for the filament or in a macro that the gcode file calls, the extruder is advanced as if in normal 'length mode' rather than volumetric... resulting in just over twice the amount of material being extruded that should be - my mystery is solved.

IMO, the one place where using M200 isn't particularly useful is in the gcode file itself. It'd be great if we could use M200 in at least a filament's config file, if not also in a macro that's called from the gcode file.

mrehorstdmd

Which slicer are you using?

I used to use slic3r in volumetric mode as default. My filament profiles were all set to 1.128 mm for volumetric extrusion. If, by some chance, the "use volumetric extrusion" box got unchecked, it would then use the 1.128 mm as the filament diameter and think it needed to move a lot more filament to deliver the specified line width and thickness resulting in massively overextruded prints.

When I started using Duet boards, there was some issue with using relative E distances that made slic3r's volumetric extrusion not work properly. I never did spend any time trying to figure out a work-around.

deckingman

This post is deleted!

bot

This is a great thread, as I'm about to implement volumetric extrusion into a RRF printer profile I'm creating for IceSL-Slicer. The profile will be released freely and is intended to be configurable for any printer running RRF with any configuration, with up to 27 24 maybe 14 tools (discovering limitations), firmware retraction, pressure advance, acceleration and jerk control, optional debug info calculating move length and other statistics, etc.

IceSL is a free research-based modeller and slicer from a french group called Inria. The IceSL-Slicer portion is my main focus, though the modelling seems neat. One of the neat things about IceSL-Slicer is that the printer profile is required to define how the gcode is formatted. It uses Lua scripting to do this.

If you need more control over how your slicer issues commands, I recommend looking into IceSL-Slicer. It has most of the basic features anyone would need, but it also has lots of crazy experimental advanced features that seem neat.

Bla bla, long story short, it would be nice to determine if volumetric extrusion works properly!

ChrisP

@mrehorstdmd said in M200 Volumetric extrusion bug:

Which slicer are you using?

My main slicer is Simplify3D and yeh, with that I use a filament diameter of 1.128 mm. I've also looked at moving to PrusaSlicer because it naively supports volumetric extrusion and object labelling for object cancellation... but I haven't made the jump yet as the few times I've tried it's produced some properly dumb gcode.

While I've tried a few slicers with this, today I ended up writing some print files manually and have discovered that (IMO) it's a bug with RRF (or DCS) that's causing the issue rather than a slicer issue.

@bot said in M200 Volumetric extrusion bug:

Bla bla, long story short, it would be nice to determine if volumetric extrusion works properly!

IceSL-Slicer looks interesting.... I shall check it out.
Volumetric extrusion does work, but currently only if the the M200 command is in the print file... which I'd argue kinda defeats its purpose.

dc42

@ChrisP said in M200 Volumetric extrusion bug:

After a bit of testing today I've discovered that the only place I can put the M200 command to enable volumetric extrusion is in the print's gcode file. If I attempt to put it in either the config file for the filament or in a macro that the gcode file calls, the extruder is advanced as if in normal 'length mode' rather than volumetric... resulting in just over twice the amount of material being extruded that should be - my mystery is solved.

There are two features that relate to this:

Each GCode input channel has a separate volumetric extrusion flag. Sending M200 only affects the flag for the channel that the M200 command was received on.
Values that are held per input channel are generally saved when you start running a macro and restored to their original values when the macro completes. This is so that macros can mess with feed rates, relative/absolute extrusion, inches/mm etc. without affecting the GCode file that calls them.

I think the real issue is that the command to set the filament diameter is the same one that enables or disables volumetric extrusion. What I think you need is a command that enables volumetric extrusion without setting the filament diameter, that you can use in the GCode print file. Does that sound reasonable to you?

ChrisP

@dc42 said in M200 Volumetric extrusion bug:

There are two features that relate to this:

Each GCode input channel has a separate volumetric extrusion flag. Sending M200 only affects the flag for the channel that the M200 command was received on.

Values that are held per input channel are generally saved when you start running a macro and restored to their original values when the macro completes. This is so that macros can mess with feed rates, relative/absolute extrusion, inches/mm etc. without affecting the GCode file that calls them.

I was aware that each input channel had it's own separate volumetric extrusion flag as I think you'd mentioned this before in another topic a while ago. This is also clear to see in the OM - nice Therefore I knew that sending M200 from the console wouldn't affect the volumetric status of a print file. What I hand't considered is that a macro called from the print file would be treated independently of the print file in this respect. Though I guess it makes sense.

The comment about changing feedrates and absolute/relative extrusion etc was a thing I've thought about before, but I hadn't realise that changes would be restored after the macro exits - that's neat. Is this also true for G90/G91?

@dc42 said in M200 Volumetric extrusion bug:

I think the real issue is that the command to set the filament diameter is the same one that enables or disables volumetric extrusion. What I think you need is a command that enables volumetric extrusion without setting the filament diameter, that you can use in the GCode print file. Does that sound reasonable to you?

This was exactly the conclusion I came to last night on the assumption I wasn't missing something in my setup. Would this be implemented simply by using an extra parameter in M200 to keep things tidy? My initial thought was that M200 Dx.xx would change the current diameter globally for all input sources, but still only enable volumetric extrusion for the input source it was entered on (to maintain existing compatibility), but an M200 S1 (with or without a D value) would enable volumetric extrusion on all input sources. I guess if you wanted to be really fancy, the S value could be a bitmask of all the available input sources so that some are affected and others not?

I guess eh question is what should the behaviour be when the print file ends? Disable because the file has ended or remain enabled because it was set in a macro/console/wherever? I think I'd lean towards the former.

dc42

@ChrisP said in M200 Volumetric extrusion bug:

Is this also true for G90/G91?

Yes.

I see no reason to have a way to set volumetric extrusion set not not globally. Whether volumetric extrusion is in use or not is a property of the GCode file being printed. You may have some GCode files that use volumetric extrusion, and other that don't. OTOH, the diameter of each filament is a property of the extruder.

I think a solution to your issue might be to implement M200 S1 as you suggest, then you can use it in your slicer start GCode.

ChrisP

@dc42 said in M200 Volumetric extrusion bug:

@ChrisP said in M200 Volumetric extrusion bug:

Is this also true for G90/G91?

Yes.

I see no reason to have a way to set volumetric extrusion set not not globally. Whether volumetric extrusion is in use or not is a property of the GCode file being printed. You may have some GCode files that use volumetric extrusion, and other that don't. OTOH, the diameter of each filament is a property of the extruder.

I think a solution to your issue might be to implement M200 S1 as you suggest, then you can use it in your slicer start GCode.

I think this would work well.
One thought I had - I think I'm right in saying that as M200 is currently only enabled per input, that a macro which is called from the main gcode file that has some E values will be treated as an extrusion length rather than a volume. Presumably with this proposed modification to the behaviour, the two options would be for the user to either provide volumetric E values or disable volumetric extrusion at the beginning of the macro and re-enable at the end?
However, then there would need to be some way for the user to remember whether or not volumetric mode was enabled at the beginning of the macro. When variables are available for meta commands this will be easy. In the mean - time would the best way to be to use a fake axis or fake heater set point as variable storage?

dc42

@ChrisP said in M200 Volumetric extrusion bug:

One thought I had - I think I'm right in saying that as M200 is currently only enabled per input, that a macro which is called from the main gcode file that has some E values will be treated as an extrusion length rather than a volume. Presumably with this proposed modification to the behaviour, the two options would be for the user to either provide volumetric E values or disable volumetric extrusion at the beginning of the macro and re-enable at the end?
However, then there would need to be some way for the user to remember whether or not volumetric mode was enabled at the beginning of the macro. When variables are available for meta commands this will be easy. In the mean - time would the best way to be to use a fake axis or fake heater set point as variable storage?

The volumetric flag will automatically be restored to its original value when the macro completes, just as happens now.

bot

Can I request a modification or addition to the way volumetric extrusion is defined for each extruder?

I'm trying to create a slicer output script that will automatically insert the proper M200 command for each tool in use. However, there becomes a possibility that several tools are in use that are not consecutively numbered, IE T0 and T2. In the worst case, we could be using T0 and T11 (or T151 if duet3).

So, can we have a way to set the filament diameter for just a specific extruder? Maybe how pressure advance selects which drive to affect?

M200 Dn Snn

This would allow the slicer script for IceSL more easily generate the proper output. It would also allow for one to dynamically change the filament diameter more easily, without having to define all extruders in between, whether or not they are all in use.

bot

Well, I figured out an easy workaround with LUA's math.max(unpack(NAME_OF_TABLE))

So, disregard my suggestion except if you feel this is necessary. It might make some situations easier, but I'm now able to discover the highest index of an extruder that is used and set all extruders from 0 to max in the slicer script.

ChrisP

While I know this topic is a few months old now, I'm not sure whether it was decided that the proposed solutions were sufficient to be included in the next FW release. It's still a feature I'd love to see updated to enable slicer-based enabling of the feature.

stewwy

@chrisp

Second this it's a feature I'd like to have, or at least try out.

dc42

@stewwy I've added this to the work list for RRF 3.4.