E-Axis Compensation MCode Proposal

This proposal was originally posted on the main Teacup thread. However, the main developers of Teacup don't really care for the idea so I've created this thread for any additional discussions.

The original proposal can be found here.

At this point I imagine the following MCodes (I'm somewhat thinking out loud at this point):

M210 - E Volume Compensation Setting
Sn - The diameter of the filament on which the E distances used in the GCODE are based.
Pn - The diameter of the filament actually being used in the machine.

Note that S and P may be set in different lines of M Code. This allows Skeinforge to generate a M210 Sn line and the user to manually specify a M210 Pn line. M211 must be used to enable/disable the feature, M210 only sets the values to be used if the feature is enabled. If enabled, this compensation occurs before the M212 distance compensation.

M211 - E Volume Compensation Control
S0 - disable M210 compensation.
S1 - enable M210 compensation.

M212 - E Distance Compensation
Sn - The distance requested of a test extrusion (with M210 compensation disabled)
Pn - The distance actually the filament actually moved as measured.

S and P must both be supplied. Note that the values are use to modify the current E distance compensation, so the standard extrusion test can be executed more than once without starting over. E Distance compensation is automatically enabled when this MCode is used.

M213 - Clear E Distance Compensation
Clears all E Distance Compensation.

M214 - Extrude Test Filament
Sn - The requested distance to extrude.
Pn - Specifies the feedrate to use for this command. If not specified the current feedrate for G1 is used.

This function automatically disables the E Volume Compensation for the duration of the test extrusion. I'm not certain if E and F should be used instead of S and P or not...

Thoughts? Suggestions?

Edited 1 time(s). Last edit at 08/07/2011 10:38PM by madscifi.

I didn't get the point at first, but this is going to be necessary for multiple extruders to work well.

As you said in the other thread, feed skeinforge a bogus diameter so it spits out E in some volume unit (mm^3 would probably be good), then do volume->length conversion in firmware using a conversion factor provided in g-code, or associated with a particular toolhead and recalled with M6 T1 etc.

I think we should require users to calibrate properly, so instead of "compensating" for poor calibration, we're "converting" volume to distance in firmware. For this we could perhaps coin the term, "volumetric firmware" ?

If we follow this path, I think we would only need one M-code for the conversion factor, and some instructions for how to discover or calculate it.

This will also be useful for printing filament that varies.

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

Triffid_Hunter Wrote:
-------------------------------------------------------
> I didn't get the point at first, but this is going
> to be necessary for multiple extruders to work
> well.
>
> As you said in the other thread, feed skeinforge a
> bogus diameter so it spits out E in some volume
> unit (mm^3 would probably be good), then do
> volume->length conversion in firmware using a
> conversion factor provided in g-code, or
> associated with a particular toolhead and recalled
> with M6 T1 etc.
>
> I think we should require users to calibrate
> properly, so instead of "compensating" for poor
> calibration, we're "converting" volume to distance
> in firmware. For this we could perhaps coin the
> term, "volumetric firmware" ?
>
> If we follow this path, I think we would only need
> one M-code for the conversion factor, and some
> instructions for how to discover or calculate it.
>
> This will also be useful for printing filament
> that varies.


This would also allow us to measure the filament on the fly while printing with a simple cam and flex sensor or other sensor at a set distance from the hotend so no matter how the filament varies the firmware could compensate.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

So, why not just make it simpler and make the e_steps_per_unit a variable that can be changed with an M command. This idea has been proposed before but for some reason, people keep wanting to use more complicated means to achieve the same goal.

If the firmware need to have fixed e_steps_per_unit value, then Madsci's proposal can also be siimplified into one parameter instead of two: a correction factor like the filament packing density ratio in Skeinforge 40+ calculated from the ratio of the actual displacement/requested displacement.

By making it a variable, it would allow us to just edit a g-code file to change the M variable in one command if we want to save on running SF once again.

brnrd Wrote:
-------------------------------------------------------
> So, why not just make it simpler and make the
> e_steps_per_unit a variable that can be changed
> with an M command. This idea has been proposed
> before but for some reason, people keep wanting to
> use more complicated means to achieve the same
> goal.

Because E = filament input length and once set correctly it should never be changed. It is the diameter that we need to compensate for not the length.

> If the firmware need to have fixed
> e_steps_per_unit value, then Madsci's proposal can
> also be siimplified into one parameter instead of
> two: a correction factor like the filament packing
> density ratio in Skeinforge 40+ calculated from
> the ratio of the actual displacement/requested These are the two parameters he proposed
> displacement.
>
> By making it a variable, it would allow us to just
> edit a g-code file to change the M variable in one
> command if we want to save on running SF once
> again.

This is what I was suggesting and Triffid also proposed. Have the variable the actual filament diameter because it is easily measured and if we output a volume like mm^3 from skeinforge it will not be hard to calculate. ( And no guessing or math on the part of the user )

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Sublime Wrote:
-------------------------------------------------------
> brnrd Wrote:
> --------------------------------------------------
> -----
> > So, why not just make it simpler and make the
> > e_steps_per_unit a variable that can be changed
> > with an M command. This idea has been proposed
> > before but for some reason, people keep wanting
> to
> > use more complicated means to achieve the same
> > goal.
>
> Because E = filament input length and once set
> correctly it should never be changed. It is the
> diameter that we need to compensate for not the
> length.
>

The e_steps_per_unit does change when you change feed. ABS is softer than PLA so the filament drive teeth digs in deeper into ABS than PLA, effectively making the diameter of the drive smaller for ABS than PLA. That's why Enrique suggested 0.85 and 0.99 for the values of filament packing density ratio for ABS and PLA, respectively.

brnrd Wrote:
-------------------------------------------------------
> Sublime Wrote:
> --------------------------------------------------
> -----
> > brnrd Wrote:
> >
> --------------------------------------------------
>
> > -----
> > > So, why not just make it simpler and make the
> > > e_steps_per_unit a variable that can be
> changed
> > > with an M command. This idea has been
> proposed
> > > before but for some reason, people keep
> wanting
> > to
> > > use more complicated means to achieve the
> same
> > > goal.
> >
> > Because E = filament input length and once set
> > correctly it should never be changed. It is the
> > diameter that we need to compensate for not the
> > length.
> >
>
> The e_steps_per_unit does change when you change
> feed. ABS is softer than PLA so the filament drive
> teeth digs in deeper into ABS than PLA,
> effectively making the diameter of the drive
> smaller for ABS than PLA. That's why Enrique
> suggested 0.85 and 0.99 for the values of filament
> packing density ratio for ABS and PLA,
> respectively.

This isn't to deal with packing density but actual filament diameter.

I have three rolls of PLA from ultimachine and they're all different diameters which = different volume per mm of filament. And all three of the rolls vary along its length so after using 50 feet off the roll the diameter is different and instead of changing the diameter in skeinforge and re-slicing ( some times 1hour each ) we slice all models with a filament diameter of 1.128mm which equals 1 cubic mm of plastic per mm feed in. Then enter the filament size being used in the firmware right before hitting print to calculate the length needed to achieve the volume requested.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Quote
Sublime
This isn't to deal with packing density but actual filament diameter.

The original proposal by Madsci specifically deals with the feed length pulled into extruder, not the filament diamenter.

The intent of the FPDR is clearly explained in the Skeinforge blog:

Quote
http://fabmetheus.blogspot.com/
Dimension

Filament settings have been added to dimension. This is very loosely based on Rob Giseburt's Volumetric 5D plugin:
[tinkerings.posterous.com]

The 'Filament Diameter' should simply be set to the measured filament diameter in millimeters.

The tricky setting is the 'Filament Packing Density'. The default is 0.85, this is for ABS.

The default value is so low for ABS because ABS is relatively soft and with a pinch wheel extruder the teeth of the pinch dig in farther, so it sees a smaller effective diameter. With a hard plastic like PLA the teeth of the pinch wheel don't dig in as far, so it sees a larger effective diameter, so feeds faster, so for PLA the value should be around 0.97. This is with Wade's hobbed bolt. The effect is less significant with larger pinch wheels.

Overall, you'll have to find the optimal effective 'Filament Packing Density' by experiment.

Edited 2 time(s). Last edit at 08/08/2011 05:15PM by brnrd.

brnrd Wrote:
-------------------------------------------------------
> The original proposal by Madsci specifically deals
> with the feed length pulled into extruder, not the
> filament diamenter.

Quote
Madscifi
M210 - E Volume Compensation Setting
Sn - The diameter of the filament on which the E distances used in the GCODE are based.
Pn - The diameter of the filament actually being used in the machine.

Note that S and P may be set in different lines of M Code. This allows Skeinforge to generate a M210 Sn line and the user to manually specify a M210 Pn line. M211 must be used to enable/disable the feature, M210 only sets the values to be used if the feature is enabled. If enabled, this compensation occurs before the M212 distance compensation.

M211 - E Volume Compensation Control
S0 - disable M210 compensation.
S1 - enable M210 compensation.

The problem is that if you calculate it with 2.8mm input in skeinforge it produces a length based on the volume of 2.8mm filament. But what happens when you measure your filament right before printing and its actually 2.73? You go into skeinforge and change the diameter NOT the packing density then sit and wait for it to re-slice it.

>
> The intent of the FPDR is clearly explained in the
> Skeinforge blog:

And yes the following part of his proposal is supposed to deal with Packing density correction outside of skeinforge.

Quote
Madscifi
M212 - E Distance Compensation
Sn - The distance requested of a test extrusion (with M210 compensation disabled)
Pn - The distance actually the filament actually moved as measured.

S and P must both be supplied. Note that the values are use to modify the current E distance compensation, so the standard extrusion test can be executed more than once without starting over. E Distance compensation is automatically enabled when this MCode is used.

M213 - Clear E Distance Compensation
Clears all E Distance Compensation.

M214 - Extrude Test Filament
Sn - The requested distance to extrude.
Pn - Specifies the feedrate to use for this command. If not specified the current feedrate for G1 is used.

This function automatically disables the E Volume Compensation for the duration of the test extrusion. I'm not certain if E and F should be used instead of S and P or not...

This means the Gocde still has the correct volume being generated not a compensated volume for the inaccuracies of the day. And when you change filament you can reuse the gcode by recalculating this and it modifies your E_steps to be correct for the current filament.

Edited 1 time(s). Last edit at 08/08/2011 05:45PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

Oops. I quoted the wrong part of his proposal. The one I wanted was later in his post:

Quote
Madsci
M212 - E Distance Compensation
Sn - The distance requested of a test extrusion (with M210 compensation disabled)
Pn - The distance actually the filament actually moved as measured.

Quote
Sublime
The problem is that if you calculate it with 2.8mm input in skeinforge it produces a length based on the volume of 2.8mm filament. But what happens when you measure your filament right before printing and its actually 2.73? You go into skeinforge and change the diameter NOT the packing density then sit and wait for it to re-slice it.

If your feed varies so much that it affects the quality of your prints, then you need to find another supplier instead of complicating matters by adding more parameters. I don't think that a variation of 2.5% in the diameter would make a huge difference in my prints at 0.3 mm layer thickness so I won't change anything.

With small pinch wheels like the Wade's hobbed bolt the amount of spring tension applied affects the feed rate for ABS. The more pressure the further it digs in and the slower it goes. It also depends on the diameter, smaller diameter sinks in more so feeds slower. It's all a bit of a nightmare.

---

[www.hydraraptor.blogspot.com]

brnrd Wrote:
-------------------------------------------------------
> If your feed varies so much that it affects the
> quality of your prints, then you need to find
> another supplier instead of complicating matters
> by adding more parameters. I don't think that a
> variation of 2.5% in the diameter would make a
> huge difference in my prints at 0.3 mm layer
> thickness so I won't change anything.

I am in Canada and I use PLA. This means buying from one of the U.S. suppliers who all buy from one of two companies who extrude the material. All of mine is from ultimachine and it varies from 2.68 to 2.89. Plus if you have two machines, one with 1.75mm filament and one with 3mm you could use the same Gcode.

And this does not complicate anything at all. It eliminates the input value of diameter in skeinforge and moves it to the firmware. Same number just in the right place for volumetric which is what skeinforge has moved to. Why export a length when we are using volume now.

And 2.5% is alot:
If you request 1mm of filament assuming its 2.8mm you get 6.1599mm^3
But if the filament is actually 2.73 you only get 5.8558mm^3
A difference of 0.3041mm^3 per mm of feed
Over a model requiring 4meters of filament you will have 1216.4mm^3 missing from the proper volume required. This is the same as being short 20cm of the 2.73 mm filament. I wouldn't call this nothing.

Edited 1 time(s). Last edit at 08/08/2011 07:43PM by Sublime.

---

FFF Settings Calculator	Gcode post processors	Geometric Object Deposition Tool Blog
Tantillus.org	Mini Printable Lathe	How NOT to install a Pololu driver

I don't envision this proposal as a replacement for Sprinter's M92. I'll try to include an implementation of M92 when I submit these features (assuming someone else does not beat me to it). While it is true that all of these functions can be replicated with M92 and some functions in the client I still think these provide a useful abstraction of two related problems - variable filament diameter and variable filament travel due to variations in how far the drive gear/teeth bite into the filament.

I'm coming at the problem with the following in mind:

* The operator should not have to perform any math when changing from one filament to another (measurements are necessary - either before hand if the filament is very consistent or at the time the filament is used). Any computation should be left to the computer.

* It should be easy to do make the necessary adjustments even if your client is nothing more than a simple telnet style client (that is, the necessary measurements should be recorded in gcode and any necessary computations should be done by the gcode interpreter).

* While it is not possible at this time to completely eliminate issues due to filament diameter variation, assuming the variation withing a spool over the amount needed to print a single object is small the problem can be greatly reduced via a couple of simple measurements.

* Running Skeinforge to make adjustments necessary due to filament diameter or softness differences is not reasonable (it can take a long time).

* If you don't want to use these functions you will not have to do anything. The functionality will be disabled by default.

* It is not necessary to have code changes pushed into Skeinforge (although it would be nice if it would generate an MCode that specified the filament diameter on which the generated GCODE was based, it is not necessary for these functions to be useful).

From my perspective (which is not necessary any more or less correct than another, it is just the one I'm using) M92 should be used to set the steps_per_m for an idealized filament - that is, calculated based on the diameter of the teeth and drive system. Consequently, when all of the compensations are disabled the E drive wheel will always turn the same amount for the same requested distance.

The problem that the distance compensation functions are attempting to address is really the variation in amount of linear distance a real piece of filament moves as compared to an idea filament given the same rotation of the drive gear. Assuming that a piece of filament is mostly constant over the length of a single print (I know this is not the case but to fix this would require some rather complex automatic measuring components), simply running a test extrusion just before printing and setting the compensation values adjust for a whole host of issues including hardness, temperature and diameter (as it affects distance). It is not perfect, but it is a lot better than doing nothing. The same effect can be achieved via M92, but the process is a little more complicated. Maybe a better name is E drive filament bite compensation? Adding this feature does not mean that anyone is required to use it, it can be ignored and would be disabled by default.

The volume compensation function can certainly be called a conversion function. Measuring the diameter of the filament is necessary, but the operator should not have to perform any calculations based on the measurement. Again, the same effect can be achieved with a bit of math and the M92 function, but I think it is simpler and clearer if specified as a discrete GCODE operation.

---

Use scenario:

Generate GCode from Skeinforge using a known filament diameter.

Decide you want to use blue instead of yellow PLA.
Set up yellow PLA in extruder.
Issue an "M211 S1" to enable E distance comp.
Mark a point on the filament.
Issue a "M214 S50" line to the firmware to run the test extrusion
Measure the distance the mark moves (repeat mark and measure if desired)
Issue a "M212 S50 Pn" (where n is the distance moved) to the firmware.
Measure the diameter of the filament
Issue a "M210 Sn Pm" (where n is the diameter used by Skeinforge and m is the diameter of the filament as measured).

At this point everything should be adjusted about as well as can be expected. Run the print job. GCode can be reused with any reasonably similar filament. The definition of reasonable here is really unknown at this point.

---

What I'm not particularly happy with is the definition and interaction of the various MCode - i think they are too inconsistently specified at the moment.

i am for any standard for m codes, as long as they are a standard and differences are well defined and located at the very least in the wiki [reprap.org]. Also i care that the settings for such codes are preset to a reasonable working value , in case someone does not know about them, or the controlling software does not know of the settings, it works in a default way....

also m226 has been requested to be added to teacup...

Edited 1 time(s). Last edit at 08/09/2011 03:22PM by jamesdanielv.

From a tool flow perspective I am not sure where sliced gcode compensation goes. Maybe having filament diameter in skeinforge is a bad idea and having compensation for those right at slicing time, but wrong a printing time in the firmware feels not idea either.

If skeinforge output volume then we could have volume to filament feed all in one place and no compensation required, just conversion. Having to know/remember what size filament a gcode file was sliced with so you can do the compensation correctly is prone to errors.

Perhaps one solution would be to have Skeinforge slice with a nominal filament diameter, then have the printer measure the filament as it enters the print head and the firmware can dynamically adjust the volumetric parameters.

You could measure the diameter either by monitoring idler wheel deviation, or a line camera.

It's a complex solution that would need some initial tuning but would adjust dynamically to filament variations.

JB

---

--
Check out my blog: AdventuresIn3-DPrinting

I've run into one issue and I cannot decide how to deal with the problem.

Problem: The values specified on the Dimension tab of Skeinforge for the extruder retraction/restart are both distances. I think they should probably remain distances as I expect that the distance used for retraction/restart with a 3mm filament is about the same as with a 1.75mm filament. Can anyone confirm or deny this? I've only used 3mm filaments so I don't have any experience with 1.75mm filaments.

Assuming the values should remain distances, I see the following ways to deal with the problem:

1) Let the firmware automatically assume the values are volumes when E is specified along with any other axis in a G1 command, but assume the values are distances when E is specified alone in a G1.
+ Requires no changes on the Skeinforge side
- Is a bit obscure and breaks if someone attempts to merge a retraction/restart with a XYZ move

2) Propose a new V tag to be used in place of E when Skeinforge intends the value to be volumetric.
+ Easy to see what is going on
- Requires changes to Skeinforge
- the function (when enabled) would not be in any way backwards compatible with existing firmware

3) Modify Skeinforge to generate an MCode that turns the volumetric conversion off before issuing an E move when a distance is really intended and turn it back on when the move is over.
- Requires changes to Skeinforge
- State is unclear if a script is paused

Any opinions on how to resolve this (if, in fact, it needs to be resolved)? Have I missed a better approach? Or is this why this whole idea was doomed from the start?

I think approach #1 would work for the short term but I think for the long term it is not a particularly good idea. Approach #3 is a bit ugly - if you pause the execution of some code you don't know if an G1 Ex command would execute in volumetric or distance mode without knowing exactly where you paused.

As much as I did not want to need to get a modification into Skeinforge I'm favoring #2. As a temporary work around a simple python script could be used to convert E to V using the approach in #1, at least until a Skeinforge patch could be written and accepted.

Any one want to venture an opinion or three?

4) tell people to use teacup's built in retraction instead of skeinforge retraction, perhaps get skeinforge to emit retract/reload markers

---

-----------------------------------------------
Wooden Mendel
Teacup Firmware

I don't think people use the retract distance as knowing I want to turn back 1mm, then know there is a good range to set it too. If that were volume based the range would just change again. The feedrate on the retract only move would be kinda weird if in mm3/min.