After switching to slic3r-PE I DWC stopped showing filament usage.
I was pretty bummed about that as i find the estimate based on filament usage fairly accurate.
After I reformatted the SD-card, I started playing with the gcode itself and was able to fix it manually.

this is the relevant gcode generated by slic3r:

; filament used [mm] = 4235.9
; filament used [cm3] = 10.2
; filament used [g] = 13.1
; filament cost = 0.4
; total filament used [g] = 13.1
; total filament cost = 0.4
; estimated printing time (normal mode) = 46m 49s

DWC seems to look for:

; filament used = 4235.9

So, after modifying the file accordingly DWC recognizes the filament usage correctly.
I'd be much appreciated, if this could be fixed in an upcoming release.

In the meantime, is it possible for me to edit the parser, so it'll do that automatically for me?
So changing the parser code to look for

; filament used [mm] = xxxx.x

instead of

; filament used = xxxx.x

I have no idea where these instructions are stored, so any help would be appreciated.

Also, I'd like request maybe allowing us to change which columns are displayed in the gcode browser.
I don't really need the info to which slicer was used generate the code visible, I'd much prefer something like cost.

Thanks for your help

The fix you implemented regarding filament usage when using Prusalicer 2.0.0 works like a charm.
I'll let you know if I encounter any bugs.

@totalos

Now is 100 and 60 - in my opinion it is not safe

I second that! It really should be 5 and 5 at default, better to extrude too little and too slow than too much and too fast.

IIRC there once was a filament odometer suggested i.e. a figure what length of filament was extruded since the machine first went online/the last reset.
While thats kinda neat, I'd find another one really amazing:

We already have "Filament" config files vor loading and unloading (iirc we also had a "config.g" file per filament but I cant find that anymore), what if we could have an odometer for every spool?
We'd need to have a config file for every color/spool that specifies filament diameter, etc. maybe like this

;fil_type = PETG
;fil_manufacturer = XXXX
;fil_color = Blue transparent
;fil_dia = 1.75
;fil_density = 1.29
;fil_amount = 800
;cost = XX.XX

maybe we could even add

;fil_loadtemp = 230
;fil_unloadtemp = 200

and ditch the load.g and unload.g macros for each filament with one that specifies wait times, amount of filament extruded etc.

or maybe a .csv that acts as a "database".
as long and you'd use the load and unload function in DWC the firmware could keep track of how much filament was used for each color/roll of filament.

This would enable having a vage idea how much filament is left on your spool and maybe a warning if you are low on filament/do not have enough for your print.

Having diameter, amount of filament, density and cost in there would also enable accurate weight and cost per part as long as filament usage metadata is accurate.
These values could be displayed under "Job Information" in DWC.

Thoughts or suggestions?
Or is this a dumb idea/way too much work?

-JV

When I start a new spool of filament I weigh it and mark the empty spool weight on the spool. When I'm going to start a print and it isn't obvious that there's enough filament on the spool, I weigh it again and subtract the empty spool weight. It works every time. I haven't run out of filament during a print in years.

I'm aware that's possible, I just think having an estimate of the amount of filament left on my spools would be neat, what if I'm not in the mood to break out a scale and my calculator?

Descriptions like "blue transparent" are nice, but you'll need a more positive identifier than that. What if you have more than one spool of "blue transparent" filament? I'd assign a serial number to each spool so I can be sure exactly which spool I'm looking at in the controller.

That's true, but I'd wager most people dont have multiple partly used spools of the same material, manufacturer and color in use at one time. Adding an ID for each spool could easily solve that but only an ID would be to cumbersome IMO.

It would be much better to integrate filament accounting into the slicer so it can warn you that there isn't enough filament left on that spool to finish the print.

I'd rather have that on my printer as I'm frequently switching slicers or device the slicer runs on, but not my printer. I think most people use multiple slicers/slice on different machines and not one slicer on one machine for multiple printers. Even IF I'd be only using 1 slicer I don't want to update a database on multipe machines everytime i slice a model.
Also what if I just slice a file and dont print it? what if I print the same gcode twice? what if a print fails and i have to restart it?
Only way that would make sense if you had a machine dedicated for sending out the gcode to the controller of your machine(sounds a bit like my Duet )
Implementing this in the Duet FW rather than a slicer makes way more sense IMO.
Also, IIRC this is the duet forums not the forum for some random slicer?

Hardware DUet2Wifi v1.03
Firmware: 2.03RC5
WiFI Firmware: 1.23

My Duet worked fine for quite some time now, I did some prints 2 days ago.
When I tried connectng to my rinter today to print something I could not connect to DWC.

After multiple powercycles and resets I tried connecting over USB which worked fine but my duet would not let me connect to my network.
I tried restarting/resetting my router and deleting and adding my network again, no luck unfortunately.

I have included the log from my terminal in this post. the only edits are private data and a bunch of repeated messages denoted with "[...]".

Any suggestions to get my board working again?
I just received 5 more spools of filament..

Terminal Log

@notausername please take a look at the link David posted

@sputnikoc3d Please check out the changelog here

The fix you implemented regarding filament usage when using Prusalicer 2.0.0 works like a charm.
I'll let you know if I encounter any bugs.

@hbrownell
Motors:

• for the motors you mentioned I'd start with 1200-1300 mA

• 100 steps/mm doesnt look right to me please refer to this calculator to get the relevant values for your specific setup.
  same goes for Z steps/mm

• steps/mm on your extruder can be calibrated after you are setup:

1. measure and mark 150mm of filament from a fixed point (i.e. extruder body)
2. tell your printer to extrude 100mm of filament
3. measure again to determine the actual amount of filament extruded
4. calculate your new steps/mm using this formula: <current steps/mm> / <actual amount of filament extruded> * <length you wanted to extrude(100 mm in this example)>

Heater config

• for your V6 if you got the standard kit the values should be R25=100000 B=4725 C=7.06e-8
  But please look here for more detailed information to double check.

• for your heatbed, you will have to look up your specific model and the type of thermistor used. Check the datasheet of that thermistor to get your values.

BLTouch:

• Probe X and Y Offsets are the distance from your nozzle to the BLTouch, this depends on your mounting solution

• Trigger height is the distance from your nozzle to the bed once when the BLTouch triggers, this is also unique to your config and needs to be measured.

Fans:

• Fan0 should be your part cooling fan and should not be thermostatically controlled
• Fan1 config looks fine, if it does not work, try changing the PWM frequency.

@fma I wasn' talking about a corrupted sd card, but a corrupted file (maybe after unexected power loss during edit?)
M0 will work with no cancel.g/stop.g present and default behaviour is to shut off all heaters.

@gnydick I definately agree it would be better to put the gcode in the macro itself rather than having it be empty by default and have some other code run when no actual gcode is present in that macro, maybe @dc42 can give some insight why it was implemented this way (maybe for safety reasons if stop.g or cancel.g are not present/readable or corrupted in some way).
You're posting in tuning and tweaking, so I thought you mainly wanted to make it work.
In that case my suggestion would be to create cancel.g and add your code.

For fundamental changes to RRF I'd suggest you post in Firmware Wishlist.
David is currently working on RRF 3.0 and I think that thread is open for suggestions too.

@manne_sahne wouldnt a simple inverter IC work?
maybe get a hex inverter IC or a breakout board if you dont want to mess with small smd stuff

If the SD card you were trying to use works in another of your duets and cards working in those are not recognized on that board it looks like your slot is broken and you may need to RMA the board.

Another thing you could try is erasing the chip and doing a fresh firmware installation, maybe something is messed up with your firmware?

@gnydick running M0 with no H1 parameter shuts all heaters off. This is normal behaviour for any FW based on the RepRap FW and always worked that way afaik. I never used any other FW except for marlin, which is also based on RepRap, so i can't comment on the behaviour of other firmwares when executing M0.
This behaviour is documented on the RepRap wiki as well as the Duet documentation, so it does exactly what you instructed it to do?