Presently, when you connect to a printer using pronsole, one sees
something like:
uninitialized>start
uninitialized>Printer is now online
uninitialized>echo: External Reset
printer>Marlin 1.0.0 RC2
...
With a few carriage returns and some string hackery, we clean up
the output so that one sees:
No port specified - connecting to /dev/ttyACM0 at 115200bps
start
Printer is now online
External Reset
Marlin 1.0.0 RC2
Much cleaner!
The monitor command now:
* Has more pythonic code
* Limits precision of progress elements (12.3% instead of 12.347812...%)
* Uses a carriage return to have print progress replace the previous
progress line.
For example:
Monitoring printer, use ^C to interrupt.
Updating values every 5.000000 seconds.
Print progress: 0.3%
Previously, the line "Print progress: 0.3%" was "Print progress: 0.2%",
etc.
* Prompts are now generated based off of string templates,
for example: "%(bold)sT:%(extruder_temp_fancy)s %(progress_fancy)s
>%(normal)s "
* We have a dictionary of prompt string templates for different
situations.
* We have bold support for the prompt.
* We have extruder temperature support for the prompt.
* We have progress support for the prompt.
In order to do this, we consolidate handeling of printer status
with a Status class. The status class is updated by recvcb.
This has the side effect of simplifying the implementation of gettemp.
We also detect whether there is a heated build platform or not, and
don't display info about it if there isn't.
The extra data while interesting, belongs in a deliberate command to show stats.
summary line reads:
Estimated duration (pessimistic): 187 layers, 00:29:42
Accounts for G4 Pxxx
Accounts for Z moves as well.
Also prints out duration for each layer while calculating the total time.
Does not use individual axis acceleration, only uses sprinter default acceleration 1500.0 mm/s/s
Does not count E for timing... so if E is slowing down the move, we're not accounting for that.
** fixed: 2x distance to reach full speed, because accel and decel to 0.0 at each move.
TODO:
Get Device Caps (per axis acceleration, per axis speed limits)
anything else...?
at beginning of move set feedrate to average of last and current feedrate. do move with that feedrate.
then set the feedrate to the current feedrate.
if it's just a feedrate change, then the feedrate will become the feedrate.
if there is no feedrate in current move, feedrate will be last feedrate
if there is a move and a new feedrate then the move will take however long the average feedrate would take.
estimation is a bit more optimistic than pessimistic. however it seems to be a lot more accurate.
Christopher Olah