[FR] filament odometer + M600 (filament telemetry)

[empakoso]

What are your thoughts on creating a filament consumed value either by LCD or preferrably by serial output. I do not have a programming expertise, but would be interested in creating a data output to measure and compile via serial output to monitor part quality to filament quality. I understand this is a lofty idea with very low priority. It just came to mind hoping others might be interested.

I am fascinated by the filament since it is the primary to printing. I have a filament width sensor. It would be neat to have a serial output with this data. An interval of layer height or length consumed could be used to base the measurements.

example of serial output: "filament: [height or consumed mm] [optional: filament width]"

Maybe along with an updated length on the LCD for reference during printing.

[Sebastianv650]

The idea behind this data is to see if the filament is thinner or thicker than the reference value?

Maybe OT, but I was thinking about building a filament width sensor on my own. All projects I have seen had one mayor fault: The sensing tolerance was equal or even bigger than the tolerance usual filament has. So the sensed value would be worth nothing. Are you sure the data you cold get out of this statistic would be meaningful at all?

[empakoso]

Yes, two-fold; A) filament quality report to test for direct relationship with quality of print, and B) my evil by-product of octopi reacting to a filament sensor value that is way out of tolerance or possibly even reacting with an M600 response when I know it ran out...

I have been talking to a couple of people who manufacture with big industrial printers. Coming from manufacturing and data related engineering, it seems that they suffer from one very important key performance indicator = filament quality in real time. I thought this could start something at the Marlin level and get bigger from there.

I see what you are saying, the method of measurement is not granular enough. However, I've been getting repeatable values down to +- .02 mm using http://www.thingiverse.com/thing:454584 It was one of the original pull requests that started the FWS option in Marlin.

[ghost]

I hve referenced another topic that can be linked with this One PR , for two requests If someone have time to start or make it 👍

[ghost]

And you can change your title [FR] Filament ODOMETER + M600 Filament distance before trigging

A dream !

[empakoso]

Thanks for your input. That is a cool idea to log when the M600 was triggered - telemetry is a powerful tool.

[empakoso]

OK I've been doing way too much thinking/reading on this. If this odometer/telemetry idea has any merit then please consider some of my ideas below.

This new value would be the length of filament fed into the extruder. It would be an accumulation of all the G1/G0 E0.0000 values. It could start with an M75 and reset on an M77 code.

A) Serial values telemetry_auto_report:

• the ground work has been laid for "auto_reporting" to allow for periodic serial reports

• serial output may look like this: Telemetry: [PrintTime or PulseCount] [Odometer] [Width]

• auto_reports_telemetry values could introduce a number of very interesting Host(OctoPrint) Plug-Ins

B) telemetry created and used by Marlin

• LCD could flash periodic odometer readings (like my Filament Width Sensor)

C) Filament length sensors as already discussed:

1558

8062

Comparing these sensor pulses to this new Odometer value could add some interesting telemetry data. i) If these sensors were well calibrated we could trigger the host serial telemetry report on each pulse ii) the pulse counter would be included with the telemetry serial report. ii) This could lead to some interesting host plug-ins to calculate cog-slippage or extruder effeciencies.

D) Improved runout sensors: I know its likely been overkilled with time-based set/reset sensors. But this new Odometer could now be used for a hands-off approach to runout sensing.

E) New feature for Marlin: "RunOut Odometer" Which would be used to measure end of filament, entanglement, clogs and react with an M600

1. New runout variable like "OdometerTrip" could start when print timer begins

2. OdometerTrip is reset to 0 each time a signal is received from a sensor like this one and as mentioned here

3. Config value: #OdometerTripWatchDog=5.00 //mm maximum length afterwhich M600 is issued

All of a sudden a simple filament Odometer reading may be the missing link to creating a whole new set of options in Marlin.

[Roxy-3D]

I think this approach will be easier and cleaner to implement. Right now the M600 is triggered by the filament run-out sensor. If we kept that the same, we would have to start tracking how much filament has been extruded before we really did the M600.

But do what you suggest is much easier (and cleaner) to implement. If we have the filament run out sensor clear the counter (every time it is checked) if everything is OK, then we can can trigger the M600 code any time the counter gets above the specified amount.

[thinkyhead]

4352

[ghost]

Be carefull.

• Odometer = volumetric adjustement + firmware retract + firmware retract swap
• No tool change while 'm600 telemetry ' or memorisation of each tool extrusion length
• Not possible to unload ' if long bowden' , once the sensor is passed , you cant go back or on somes sensors , you can explose it
• On machines that are direct drive , large format , once the sensor passed , the filament is on the buildplate , you can continue the print ' probably no risk' , but no tool change or filament ejection possible , because a long looped filament will be on the bed
• If tool change appeards while telemetry , you will eject the bad filament , reinsert it , return to print , wait , the old filament run , and more breaks

Programming is really possible for odometer , and , like MAKERBOT , to store this in EEPROM at the first adress of memory to never touch it , and have the ' LIFE of the machine ' always shown But programming , a M600 extrusion count .... need to make a sacrifice of the filament if a tool change appears for configuration that have more than one extruder and immediatly stop the printer for filament change .

[RossosHEX]

Yes, please add filament "Odometer". I would like to know how much meters of filament my printer ate up. I know it may not be accurate, due to risks of stepper motor skipping, or filament grinding, but hey, it would be nice to see the numbers. Also, maybe even "total hours of printing" for good measure. Wouldn't hurt in my opinion. Does EEProm get erased when re-flashing firmware? I hope not. Also a manual edit of the value, for at least adding all those spools that went by prior to recording. Thanks!

[Roxy-3D]

Yes, please add filament "Odometer". I would like to know how much meters of filament my printer ate up. I know it may not be accurate, due to risks of stepper motor skipping, or filament grinding, but hey, it would be nice to see the numbers.

It would not be perfectly accurate... But we could bump and save the amount of filament used every time we got a G0 (or G1) that only had a Z component to it. In other words... when ever there is a Layer change.

Does EEProm get erased when re-flashing firmware? I hope not.

No... But we invalidate the settings part of the EEPROM. We would need to put this information somewhere it is safe. (We put the mesh point data at the end of the EEPROM so it can survive across different versions of the EEPROM configuration data.)

[empakoso]

I like the bump and save on Z change!! That would consider all the ‘careful’ considerations as mentioned above.

Hmmm, just a thought, thing outside the box. Could we add a more simplistic option? Thinking of a secondary option which measures extruder steps or converted a value converted to millimeters. It would be irregardless of direction or special consideration.

Where I am ultimately going with this is to make a filament-driven pulse generator (as was mentioned by @thinkyhead in a previous post above. It would be directionless wheel which is driven by the motion of the filament (wether backward or forward). We could create that ‘Odometer Trip’ reset I mentioned above.

Currently working on making this pulse input for my filament ... (as mentioned above in my post above “E) 2.” )

[Roxy-3D]

I think two different things are being discussed here. Maybe we can do one implementation that handles both. One thing that is being discussed is how much filament has been used. When I put a new spool on the printer, it might be good to know how much I have left before I start a print.

The other thing being discussed is making sure the filament is moving and is not jammed up. If it is jammed up, or the extruder has run out of filament, it might be good to pause the machine and let the user switch rolls of filament.

Both ideas probably have merit.

[empakoso]

I can definitely hang on with the jam detector.

Let’s build the odometer first, then build on that idea!

Agreed, one idea first. (Indefinitely don’t want to divert this idea, my apologies)