Update DisplayInfoOnLCD.py

[GregValiant]

Bug fix for "remaining_time". Affected M118 and M73_time Bug was pointed out in #18766

Description

This repairs a problem with M118 lines being added if "remaining_time" was not selected. The bug affected M118 and M73_time insertions. There was a request to add the "A" and "P" parameters to the M118 lines as they might be required by Octoprint. Adding M117 is now an option.

This fixes... OR This improves... -->

Type of change

• [ X] Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Cura 5.7beta and 4.13.1

Test Configuration:

• Operating System: Win 10 Pro

Checklist:

• [ X] My code follows the style guidelines of this project as described in UltiMaker Meta and Cura QML best practices
• [X ] I have read the Contribution guide
• [ X] I have commented my code, particularly in hard-to-understand areas
• [ X] I have uploaded any files required to test this change

[GregValiant]

Most of these changes were requested by #18766 while other are because I'm unable to keep my fingers out of it. The changes have missed 5.7.0 so I will move it back to active when I eventually quit fooling with it.

[GregValiant]

I see no reason why Remco and Casper have to be the only ones horrified by my coding style.

[HellAholic]

I see no reason why Remco and Casper have to be the only ones horrified by my coding style.

Did a quick check to share the horror :P But I'm not familiar enough with the code to make a full review on it.

[GregValiant]

Thanks for looking anyway. I'll make changes locally until a full review. Maybe I can get by with just a single additional commit.

[github-actions[bot]]

Test Results

0 tests   - 23 953   0 ✅  - 23 951   0s ⏱️ -48s 0 suites  -      1   0 💤  -      2  0 files    -      1   0 ❌ ±     0 

Results for commit 8c3c36b2. ± Comparison against base commit 4e04d06d.

:recycle: This comment has been updated with latest results.

[HellAholic]

Strings like "M118 ", "M117 ", and "M73" are repeated through the code. You could define these as constants at the top of the script for easier maintenance. For example:

M117_COMMAND = "M117 "
M118_COMMAND = "M118 "
M73_COMMAND = "M73"

[GregValiant]

Per a suggestion in #20509 I added the profile name to the other settings being inserted at the beginning of the gcode.

[GregValiant]

After working on PrintSkew and seeing that different printer names can be involved I changed this script to alter the Cura inserted "TARGET_MACHINE.NAME" line. Commit 17 example of the new line: ;TARGET_MACHINE.NAME:Creality CR-10 / BMG CR-10 So it would become "Printer_Model / Users_Printer_Name"

[GregValiant]

@HellAholic I remembered seeing a PR for "Electricity Cost" (#14952 ). DisplayInfoOnLCD was already adding some stats so I threw in "Electricity Cost" as well. If you approve this then I think 14952 can be closed.

;FLAVOR:Marlin
;TIME:5507
;Cura Time Estimate: 1hr 31min 
;Extruder 1 (T0)
;  Filament used: 8.15m
;  Filament Type: PLA
;  Filament Dia.: 1.75mm
;  Nozzle Size  : 0.6mm
;  Print Temp.  : 205.0°
;  Bed Temp.    : 50°
;Electric Cost: $0.07
;Layer height: 0.25
;Initial Layer Height: 0.25
;Base Quality Name  : 'Standard Quality'
;Custom Quality Name: 'GV PLA 75'
;Model List: ['GV_CalibrationShape V2.stl']

[HellAholic]

I'll take a look. 👍

[GregValiant]

I see the AI threw out the extraneous imports. Regarding the "Scroll" and "Format" thing, it seems to me that it was "Scroll". I'm not sure where "Format..." came from.

Right now, all the "stats" are being inserted in lower case. That's fine and matches a gcode file, but UFP files are in UPPER. Should I make that change? Should I change insertions like ";model list:" to ";BUILD_PLATE.MODEL_LIST:" or something similar for UFP files? How would I be able to tell how the file is being saved?

I'll refrain from adding a new commit until you get back to me.

[HellAholic]

Format vs Scroll: mainly internal names so as long as it's consistent and clear, either one should be fine.

You can complicate things by getting the preferred format mime_type from the writer that each machine uses (tells you if it's gcode / ufp / ...) and format the text based on that. For that you can take a look at how the RemovableDriveOutputDevice does it in the requestWrite. But this will not guarantee 100% accuracy as user can select .gcode export when the default is UFP for example.

https://github.com/Ultimaker/Cura/blob/8aa5c41c960cf92b71ef058e46c766833f54b27a/plugins/RemovableDriveOutputDevice/RemovableDriveOutputDevice.py#L32

OR, just add a boolean checkbox that the users can select which style they want to use. Based on the boolean you either format things in lowercase as is or convert it to uppercase.

I have not used the script on different machines so I cannot say with certainty that one style is better than the other, it's also user preference.

I would call this feature format_option, and the other one that ties to the scrolling, scroll_firmware or something that indicates the connection to the scrolling and firmware.

[GregValiant]

I think I'll leave it as it is. Those stats are handy when looking at a file that was sliced by someone else, or sliced a year ago, and deciphering what was originally done. How many people actually do that though.

Commit 22 contains the requested changes.