Feature request: material weight and print time at layer x in layer view

[ozfunghi]

I own 3 printers, but none of them have a filament run-out-sensor, that would make my printer pause when the filament runs out. On the other hand, i frequently print big models (up to 40cm tall) and being able to predict (ballpark) when my filament will run out, would be a godsend. I think the code for this might already be present in the cura engine, since it needs to calculate all the layers for the total amount of filament and time anyway.

I usually weigh the filament i have left over on a spool (and detract the weight of the actual spool) to know how much i have left. Sometimes i also print stuff that needs more than 1 spool to complete as well. In both cases it would be interesting to be able to see, in layer view, how much filament has been used and how long it took for the print to reach a certain layer.

Not only would it be interesting to see which parts of a print take longer or need more filament (for learning/referencing purposes), but you could manage your dayplanning around a point where your print might run out of filament, or use a plugin to pause the print at that layer, without needing to be watching the printer like a hawk, in order to be able to swap spools.

Something like this:

[Thisismydigitalself]

This reminds me my simpler suggestions for having layer height in mm as well and to to be informed on gross/net/supprt weight in total. I asked for these during Oct 2017 and then got rejected 4 months later. I wish for you to have better luck.

https://github.com/Ultimaker/Cura/issues/2536 https://github.com/Ultimaker/Cura/issues/3514

[ozfunghi]

Well, to be fair, i'm not sure your suggestions were easier, because basically, the amount of time and material per layer has to be calculated anyway, in order to calculate the total amount of time and material for the entire model. Especially your suggestion for the gross weight / support material, doesn't necessarilly seem much simpler (imho).

The layer height in mm, on the other hand, may be easier, but could also easily be calculated by yourself. Layer number * layer height = model height at layer. You could also calculate the weight of your support material by yourself, by slicing twice, once with supports, once without supports, and deduct one from the other. It's a workaround, maybe a bit tedious, but if really needed, you can calculate both yourself.

The feature i'm asking for, has no way of being calculated by yourself, but might be simple to activate (i'm not saying it will be, but i could see that it might not be that difficult for reasons stated above).

Anyway, i also hope i will have better luck :-)

[ozfunghi]

Am i really the only one who would find this interesting? Or is this really so much harder to implement than i'm assuming?

[nallath]

The only one who would find this interesting I'm afraid. As you might have noticed, we get a lot more feature requests than we can actually handle, and that's without taking internal feature requests into account.

[ozfunghi]

The only one who would find this interesting I'm afraid. As you might have noticed, we get a lot more feature requests than we can actually handle, and that's without taking internal feature requests into account.

I honestly find that a bit hard to believe tbh. Maybe people never really thought about it, but this could be very handy in many situations. More like a feature you would miss after having used it, but not thinking about needing it before having used it. It also seems like it would be easy to implement given that the calculations are being done anyway. Though i'm not a programmer and could be wrong about that.

Say you get an error halfway in your print and need to print it again in order to see what is going wrong in order to trouble shoot. But you don't know if this is 20 hours into your print or 30 hours. If the slicer could give you this info, that would be very valuable. Same thing with predicting when filament will run out (will it run out in the middle of the night, or when i'm away from home...). You could plan the print into your schedule much better, or plan your schedule around your print.

If this is as easy to implement as i would believe it is, it would be silly not to so imho.

[Ghostkeeper]

Currently the front-end doesn't have the information about how long each layer takes to print. CuraEngine does have that information, so we'd need to send that along with the layer information. However that won't work if you're loading in a g-code file directly into Cura so there we'd need to have a Python implementation of the time estimator from CuraEngine. That could be a bit of work, but it's been done before.

Neither the front-end nor the back-end has information about material usage per layer. That is luckily fairly simple to calculate but could be prohibitively expensive for the front-end to calculate since it involves going over the entire g-code. For CuraEngine it's pretty doable though, but it would need to be sent again with the layer metadata and we'd again need a separate implementation in the g-code reader.

There is also the issue of fitting the information on the screen. Our layout has changed since you made that original screenshot.

I wouldn't say it's hard, but it's not easy either. Since the use case for this feature is fairly limited, I think we'll defer this issue until we have more time or more stringent use cases are found.

[ozfunghi]

Currently the front-end doesn't have the information about how long each layer takes to print. CuraEngine does have that information, so we'd need to send that along with the layer information. However that won't work if you're loading in a g-code file directly into Cura so there we'd need to have a Python implementation of the time estimator from CuraEngine. That could be a bit of work, but it's been done before.

Neither the front-end nor the back-end has information about material usage per layer. That is luckily fairly simple to calculate but could be prohibitively expensive for the front-end to calculate since it involves going over the entire g-code. For CuraEngine it's pretty doable though, but it would need to be sent again with the layer metadata and we'd again need a separate implementation in the g-code reader.

There is also the issue of fitting the information on the screen. Our layout has changed since you made that original screenshot.

I wouldn't say it's hard, but it's not easy either. Since the use case for this feature is fairly limited, I think we'll defer this issue until we have more time or more stringent use cases are found.

Thanks for taking the time to respond, Ghostkeeper. Now i do have some idea about how likely/difficult it is.

As for the new lay-out, personally, i'm not a fan (and i'm a graphic designer/lay-outer by trade ;-) ). However, it could also be done with a "mouse-over/hover" info box.

Anyway, thanks again, it's good to know you guys take ideas/input/feedback to heart before dismissing it or committing to it.

[wesmat]

ozfunghi I would find this very useful and for the same reason you do

[bluecaleb]

@ozfunghi @nallath I would find this very useful for the same reasons. Having to discard a print 7 days in on a 10 day print because I got busy and missed the filament swap point by a couple layers is very frustrating. Being able to accurately place pause points in my G-code would be amazing!!

[Ghostkeeper]

Note that you can place pause points in the g-code with the Pause At Height script. I don't think it really has anything to do with having time/material estimates per layer.

[wesmat]

For me the primary reason for this feature is filament change planing. If I need to change filament 250g into the print how can I find what layer to pause and change?

[ozfunghi]

Yes, obviously Westmat, you are 100% correct. The entire concept was to be able to see exactly when you would need to plan or manage your filament changing for longer prints. I thought i explained this clearly in the opening post over 3 years ago. That way you could insert the g-code to pause printing in time when needed. Without knowing when/where to pause, having the option to pause it is like flying blind and guessing where the landing strip is. Personally i can't figure out why my feature request isn't pursued since i think it would be useful for a lot of people, as well as interesting information regardless.

[wesmat]

Yep, we agree. Clearly filament use is calculated since it is shown when slicing is complete. I'd be happy with a gcode comment at the end of each layer displaying total filament used to that point. For an even better solution create a gcode post-processing script called "pause at filament used" and allow a weight to be entered. The script determines where in the gcode that much filament has been used and stops at that point or the start of that layer.

[PhilBaz]

@wesmat

I would find this extremely helpful for the same reason. Planning.

Comment at the end of each layer would be great. Post processing script would also be great.

[ozfunghi]

@wesmat

I would find this extremely helpful for the same reason. Planning.

Comment at the end of each layer would be great. Post processing script would also be great.

Well, we had developers coming into this topic 3 years ago claiming i would be the only one who would find this interesting. It's been over 4 years since i made this request now and they still have not considered it. I think the ship has sailed by now, lol. I have stopped making feature requests for Cura since. They rather waste time adding shiny features than add something that would actually be helpful.

I was thinking about requesting a "wipe after retract" feature, where the nozzle would do a quick wipe over the printed trajectory of the current layer (basically backtrack for a few centimeters/inches) to make sure there is less stringing and less blobbing and that any oozing filament would be spread over the printed layer before moving the printhead to a new location or new layer. That could make z-hop unneeded in certain cases, and drastically reduce stringing for z-hop in other cases. Maybe even reduce z-seam all together. The user could chose the distance which the nozzle is wiped and speed of movement, which would obviously impact print time. Basically not unlike how the "ironing feature" works for top layers, but now for basically every layer to reduce stringing and blobbling (which would in turn lead to the nozzle knocking over the print). Though i haven't used Cura in over a year now.

So i doubt i should bother.