[FR] Please consider implementing an "M503 Info" screen

[Thinkersbluff]

As the UI becomes enhanced with new configuration functions like esteps, PID, Retract/Restore, etc.., Users who do not use their USB serial interfaces are going to have increasing need to be able to somehow read-back the current configuration settings on their printers.

It may be practical and beneficial, at that point, to create a screen that can be populated with at least the relevant parameters from an M503 command.

The report screen could be located somewhere under Control>INFO.
If there is too much info for one page, the data could be structured into multiple pages, according to the M503 reporting structure and according to our Users' anticipated needs.

Ideally, the M503 function could be invoked from the report screen (e.g. "Refresh" button) or from any of the tuning pages (PID, eSteps, future TBD screens), to help a User verify that the new values have been stored.

For "bonus points", it would be cool if a User could tap to modify any of the displayed parameters (e.g. X, Y, Z steps/mm) on the M503 report page.

[Thinkersbluff]

NOTE: It would NOT be necessary to include any of the data that is already available on other screens by the time this FR was being actioned. (e.g. View Mesh would obviate any need to display the G29 data received from M503)

[Ranney1]

I really like this suggestion. I don’t know hoe difficult it is to implement, but it is one of the commands i use very often.

[Sebazzz]

I think a first good step is to identify which information you'd display there. Some information like steps/mm might be better off to be split to full features. Things like PID are better left to be calibrated when needed.

[Thinkersbluff]

I think a first good step is to identify which information you'd display there. Some information like steps/mm might be better off to be split to full features. Things like PID are better left to be calibrated when needed.

Agreed. I will take a shot at that.

BTW - Would it be possible to dump an M503 response to an SD card as a .txt file? That might be even better for users who do not use a Host Software.

[Sebazzz]

I don't think Marlin has a redirect for the serial buffer to SD unfortunately.

[Ranney1]

Maybe with the #define BINARY_FILE_TRANSFER option?

[Thinkersbluff]

Maybe with the #define BINARY_FILE_TRANSFER option?

I don't speak python, but this discussion suggests that transfer.py is not yet ready for primetime.. MarlinFirmware#14817

[Sebazzz]

Maybe with the #define BINARY_FILE_TRANSFER option?

That is regarding host-to-printer file transfer if I'm not wrong. I don't think it has anything to do with logging.

[Thinkersbluff]

I think a first good step is to identify which information you'd display there. Some information like steps/mm might be better off to be split to full features. Things like PID are better left to be calibrated when needed.

As promised, I have now reviewed all of the data reported in an M503 report.
Looking at CF6 Prel3 as the current UI design, I observe the following parameters are currently not viewable on the stock CR6 TFT display:

Parameter(s) | Gcode

1. Units (mm/in) | G21
2. Filament settings (dia) | M200
3. steps/unit | M92
4. max feedrates | M203
5. Max Accel - X,Y,Z | M201
6. Max Accel - Print, Retract, Travel | M204
7. Advanced travel parameters | M205
8. Home Offset | M206
9. PLR state (enabled/disabled) | M413
10. Filament Runout sensor | M412

G21 & M200 are probably rarely if ever changed. There seems little/no value to displaying or modifying these via the UI.

Items 3-8 seem to be the subject of Issue#189, at the moment. If so, there would be no need for a separate report in the UI

If users need to modify PLR multiple times during any particular use case scenario, then a dedicated function could be provided, under the "Configure" menu I have proposed in issue #121 . I myself can not think of any such scenario.

If users are having difficulties with their filament runout sensors, and need to be able to monitor or modify its state as part of a troubleshooting scenario, then a dedicated function could be provided, under the "Configure" menu I have proposed in issue #121

Unless another stakeholder reviewing this Issue can think of a reason to pursue this request further, I recommend closing it and tracking the implementation of items 3-8 under issue#189.
M503 Report Use Case Analysis.xlsx

[Sebazzz]

I don't see the value for (1), inch mode support is real obscure.
(2) is generally also not used by most users.

(3),(4)(5)(6)(7) are handled through #189

(9) and (10) would be nice one to have.

[Thinkersbluff]

Agreed.

[Sebazzz]

PLR/runout being handled through #193