Adding build status on LCD while printing from host

One of the basic features which seems missing from current systems is support for the build status, name and remaining build time to be displayed on the printer's front LCD when printing from the host. Sure, it displays the build status when printing from SD card but you don't always want to do that.
This functionality would require the addition of a new G-code.
So I thought I'd put together a strawman proposal.

What are some of the properties that we want from a solution:
- consumes virtually no bandwidth during printing (as the serial link is already pretty much fully utilized) [in other words, you do not want to have to update the LCD from the host all the time]
- allows (at minimum) the display of operation (e.g., object name or print activity), % complete & remaining build time.
- gracefully handle the pause, resumption or abort of a print

Notes on estimating build completion and remaining time.
- a simple way of calculating build completion is to count the number of Gcode lines in a file but this is not necessarily accurate (consider printing a pyramid).
- build completion is ideally an expression of remaining build time compared total build time.
- build time is harder to calculate/estimate accurately (and may not be implemented by all host programs)
- so, you want the host to be able to use either Gcode lines or remaining time based on its level of sophistication
- neither approach requires the host to send frequent updates to printer.
- a host may not be able to predict remaining build time until the print has progressed for a certain time.

Proposed G-code:

Mxxx [S:a] [D:"abcdef"] [SL:uuu] [EL:www] [TT:mmmm] [TR:nnnn]

Mxxx new M code.
S:a . State: 0 = new print activity, 1 = print update, 2 = paused, 3 = aborted, 4 = complete
D:"abcedef" description of activity (could be filename, object name, etc)
SL:uuu start GCode line number
EL:www end GCode line number
TT:mmmm total estimate build time (in XXhYYmZZs where seconds & hours are optional)
TR:nnnn total remaining build time (in XXhYYmZZs where seconds & hours are optional)

Any parameter which is missing is assumed unchanged from the last instruction (except when starting a new print activity when they are all cleared).

The firmware is free to choose what or how it displays the information based on the available LCD space.

Recommendations:
- Build % Complete calculation should be as follows:
If only SL and EL are supplied, then build completion % is calculated from (CurrentLine - SL)/(EL - SL).
If TT and TR are supplied, then build completion % is calculated from (1 - TR/TT).
- Remaining built times can be specified in seconds (to get good synchronization with the host) but normally times would be displayed to the user only in minutes.
- The description string should be limited to 35 characters on the sending side (to ease max line lengths problems).

Questions:
- do people see this as something which needs fixing?
- do people think this is the right way to go about it? (if not, why not)
- suggestions

Edited 6 time(s). Last edit at 11/13/2012 03:43PM by buildrob.

Whatever the reason is you don't want to look at your PC's screen while printing from the PC, I'd consider a G-code for generic messages to be more useful. Wishes change, introducing a new G-code every time tends to give a mess.

The firmware knows the G-code line number already, as it's part of every line sent. It also knows wether it's preheating, waiting or printing. So it might be mostly a matter of simply generating more messages from inside the firmware. Plus perhaps a generic message showing the total number of lines and the estimated total print time. The latter two are known only by the host.

my $0.02

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Traumflug Wrote:
-------------------------------------------------------
> Plus perhaps a
> generic message showing the total number of lines
> and the estimated total print time. The latter two
> are known only by the host.

I agree that only the host knows this which is why it needs a Gcode to communicate it.
The problem with just sending a generic message is that the host needs to continually refresh that message (down the fully utilized serial link for most Arduino based controllers) in order to update it.

> Whatever the reason is you don't want to look at your PC's screen
> while printing from the PC, I'd consider a G-code for generic messages
> to be more useful.

The printer may be connected via bluetooth to your computer (so that for instance you can put your printer in the garage where you can't hear or smell it). Or the case where you have multiple printers all connected to the same PC. Consider also the idea of a "LCD implementation over Bluetooth" so that you can monitor the print progress from your phone (something I started writing the other day). Besides, I think a lot of people would just like to see the LCD that they bought used a bit more than just when you are printing from SD card.

Edited 2 time(s). Last edit at 11/12/2012 07:32AM by buildrob.

Quote

The problem with just sending a generic message is that the host needs to continually refresh that message (down the fully utilized serial link for most Arduino based controllers) in order to update it.

Not neccessarily. If the host sends a message with the total number of G-code lines, this is only once per file. The firmware can write the current number independently. You could even allow generic printf-style messages, the firmware would have to recognize a few variables.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I think there are a number of reasons that having a generic (even templated) message is not a good idea.

The firmware knows how much screen real estate there is. The firmware also remains responsible for dynamically displaying and updating x/y/z position and temperature displays without intervention from the hosts (if the screen is big enough). The host doesn't know for example how the screen is going to be arranged and therefore can't (or shouldn't) attempt to format information into a generic message. In other words, lay out of information (including choosing how much information to display) should be the domain of the firmware (IMHO). If you only have a 2 line display then the only thing it may display is just a % completion value (for instance).

Besides, displaying a message like "Printing line 2347 of 5937" (where the host has provided a message of "Printing line %L of 5937) isn't exactly the most useful or professional looking progress indication, hence, at the very least you need to provide a start and ending line number so that the firmware can calculate a % completion. At that point then, you are not that far away from my original proposal of providing an option to include remaining build time and filename as well (which the firmware can choose to ignore if it doesn't want to display).

I think the following would be a more consistent G-code encoding (I was forgetting that G-code is not a line based protocol). [I can't edit the original post any more]

Mxxx [Sa] [Dnnn aaa bbb ccc ddd eee fff] [Rrrr] [Bttt | Lppp qqq]

Mxxx new M code.
Sa - Host print state: 0 = new print activity, 1 = print update, 2 = paused, 3 = aborted, 4 = complete (assume S1 if missing)
Dnnn aaa bbb ccc ddd eee fff - Description of activity (could be filename, object name, etc): nnn is number of numbers to follow, aaa bbb ... are the decimal encoded UTF-8 values of the string. This will append the new string value to the end of the previous received string fragment to get around line length limitations (see note regarding S0 below).
Rrrr = remaining build time in seconds
Bttt - Calculate build % completion using build time: ttt = total build time in seconds [% = 1 - rrr/ttt)]
Lppp qqq - Calculate build % completion using GCode lines: ppp = total Gnn code lines, qqq = remaining Gnn code lines [% = 1 - qqq/ppp]

D/R/B/L parameters are assumed unchanged if missing (unless a new print activity is indicated with S0 which clears all values).
The firmware is free to choose what or how it displays the information based on the available LCD space.

Recommendations:
- Total or remaining build times would normally be displayed to the user only in minutes (seconds are provided to get a reasonable synchronization with the host).
- Line lengths (including line number, checksum & EOL) should be kept to <=96 characters.

Edited 8 time(s). Last edit at 11/19/2012 05:13AM by buildrob.