Change the "Display Progress On LCD" plugin to have an option to update every X lines or at time intervals.

[Ravenex]

Is your feature request related to a problem? Please describe.
The "Display Progress On LCD" plugin is a fantastic feature I have been desiring since I started 3D printing. Though on really large prints it is much less useful as a single layer can take a very long time. Checking the time remaining still leaves a lot of uncertainty about how long it has been since the layer started and the message changed.

Additionally the message doesn't show until after the first layer is complete. So when loading a program I sliced days before if I don't remember the print time and no longer have setup in Cura I can't calculate the finish time until I see the first layer print.

Describe the solution you'd like
I would also like additional options: "Update every X lines", and "Update every X seconds". I understand the later could add a fair amount of processing but it would be worthwhile to trade processing time for it on prints with long layers or on production prints where scheduling is important. It is possible the first option would be enough to cover the second option with a fine enough setting since any one line is limited in time.

Also, I would the time progress message output at the beginning of the first layer.

Affected users and/or printers
I think this would benefit all users but in particular users with large prints or production prints.

[konskarm]

I added the 3rd-Party category, since the "Display Progress on LCD" post-processing script is mainly maintained by the community.

@Ravenex your suggestions sound reasonable, but considering that this PP script is contributed to us, I do not think that your requested feature will get high enough priority within our team. Nevertheless, we would be happy to review the code in case you or someone else decides to add this feature!

[Ghostkeeper]

Updating at time intervals would require porting the time estimation algorithm to Python. We already have such a port, albeit in a modified state, but it's going to take minutes to execute that on a medium-sized g-code file. During this time, the Cura interface will be frozen. Windows and Ubuntu will indicate that the application crashed. Windows will startcontinue sending data to Microsoft again, etc.

[Ravenex]

What about the every x lines variant? Would this be more reasonable?

I'm also wondering if this could be built as a standalone post processing program instead of a post processor inside Cura.

[KimmoHop]

@Bostwickenator seems to be contributor of the script?

I have been tinkering with a script based on "Display Progress On LCD" that uses M73 R for remaining time (Marlin 2, Prusa, my custom Marlin 1.1.9 ;) ), and then to update remaining time at 1 minute intervals (like PrusaSlicer does) using mechanism similar to what original script uses for progress bar (calculating layer time and injecting commands in between layer lines at about correct places).
So it is doable in post-process script. Not as accurate as time estimator could do it, but in the ballpark.

[Ghostkeeper]

What about the every x lines variant? Would this be more reasonable?

We can maybe implement it through linear interpolation between the data points that CuraEngine puts in the g-code for each layer? So during each layer it would linearly interpolate the time estimate. So if your layer starts with a bunch of tiny segments for the walls, and then follows up with long straight lines for infill, then it would be going fast at the start of the layer and slow at the end of the layer, but it would be closer at least.

This is basically what the Ultimaker printers do for their time estimation, aside from a linear compensation factor that they fit to the actual printing time.

[KimmoHop]

Here is one way to do it.

PP script already had interpolation for progress bar, so I added it to remaining time as well.

[Bostwickenator]

@KimmoHop looks reasonable to me but line 70 might have an error s / 30 instead of s / 60

[Ravenex]

I made the s / 60 change in a local copy and tested this on my last two prints using the every 15 seconds option. I didn't notice any change in the processing time and it seems to work fine on my CR-10.

[KimmoHop]

@KimmoHop looks reasonable to me but line 70 might have an error s / 30 instead of s / 60

@Bostwickenator It is to round minutes to the nearest integer for M73 R: 1m29s .. 0m30s -> 1, 0m29s .. 0m0s -> 0.
It could be simply
mins = int(60*h + m)
without (almost) anyone noticing a difference.

I made the s / 60 change in a local copy and tested this on my last two prints using the every 15 seconds option. I didn't notice any change in the processing time and it seems to work fine on my CR-10.

Good to know :) I didn't test performance too much, but xyz calibration cube scaled up to 3-4 hour print size didn't make my Athlon II P320 cough. Logging might show how much it affects saving time.