M200 Volumetric extrusion bug

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.