TODO

Some ideas. Won't necessarily all be implemented.

Printing something from Cura while another print is running does not work properly.
It talks about queuing,...
Need to take care to not overwrite the gcode file currently being printed.

I've noticed that if I print from SD card and then try to connect with marlinfeed the
printer resets and gets a new tty device (ttyUSB1 vs ttyUSB0). An idea to cope with this:
If the printer path passed to marlinfeed is a path of a directory under /sys, do a breadth first
search starting from that directory for the first directory (or symlink pointing at a directory)
matching the pattern ttyUSB* and use that as device name in /dev.
Best path for the default marlinfeed.service file is probably /sys/bus/usb-serial

SIGUSR1: pause current print or resume if currently paused
SIGHUP: abort current print, set nozzle temperature to 0, continue with next infile even if ioerror==quit.
        If no current print is running, restart the most recent print (during this session of marlinfeed,
        not from a previous session) regardless of whether that print was just aborted or finished normally.
SIGINT: abort print, set temperatures to 0, exit without waiting for cooldown
        NOTE: If there is no current print running, temperature won't be set to 0. The program will
        just exit.
SIGQUIT: wait for the end of the all queued prints, cool down printer, call /sbin/poweroff
SIGTERM: abort all prints, cool down printer, then terminate; be prepared to be shot down
         by SIGKILL before cooling down has finished.

Send M81 (Power Off) via API to trigger SIGQUIT. This allows shutting down the Raspberry Pi via Cura.

If G28 is encountered, adjust expected print time (if the GCODE contains a ;TIME comment) by the
time it took to get to G28 minus 10s (because 10s seems to be what Cura assumes for heating)

Torture test generator that runs the head in a 1s circle with binary search of 
segment size to determine the segment size at which the time starts to increase
over 1s.
  * generate torture test GCode
  * output if baud rate is limiting factor
  * outputs the determined resolution (i.e. microseconds time of determined segment)
  * output should be to stdout with informational stuff as comments in the end so that
    you can either pipe into a file or just read on console.
  * if --torture is passed, first send all listed infiles to the printer, so you can
    have a gcode file with code to setup jerk,... settings as output by your slicer
    before the torture test measurings take place.

Support for Unix Domain Sockets as infiles. That way one could easily make an interactive session
via socat. If a UDS is infile, then data received from the printer as well as error messages
need to be copied to the UDS, too.  

While idle, check temperatures every few seconds, maybe only if API queries are occuring, so that
we don't interfere with a print from the SD if Cura and the plugin aren't talking to Marlinfeed.

Let M117 set Job Name so that you can see the message in Cura. Very useful when using the Display Filename and Layer
Script.

Print a few megabytes via Marlinfeed at different verbosity levels (especially verbosity 0 and verbosity 4)
and check if memory usage keeps increasing => Memory leak

We should probably clear Marlinbuf when an Error is received because we can't expect ok's to match up in
that case.

We may even want to clear Marlinbuf under some other circumstances, e.g. after a small time with no
message from Marlin. I'll need to check Marlin's code to see if it's possible that a long-running command like G28 can
leave stuff in the serial buffer. Or maybe just implement it and see if we get any errors. The line number
counter and checksum should catch any data loss caused by this.
This should probably wait till the torture test is implemented so we can test if this change can push the
limit further.

Idea for identifying buffer underruns and helping optimize the program:
MarlinBuf registers the time next() is called for each line.
When ack() is called the time difference is computed and stored.
Min/Max/Avg time differences are tracked both globally across the whole print (reset on new print)
and over the last N lines.
By looking at the graphs of these times it should be possible to spot bottlenecks.
If the times are around the minimum for a while that means Marlin ack's every new line we send it immediately,
meaning Marlin is waiting for us. That's bad. The buffer is empty.
If the times are over a certain threshold (some constant k times the minimum time)
everything is fine because it means we are waiting for Marlin which means Marlin's buffer is full.

What happens in case of filament runout? Does the printer handle that? Does the printer communicate that
over the wire so marlinfeed can react?

Abort code should move the nozzle home and disable the steppers to make it easier to remove the faulty print.

Queuing (i.e. selecting Print to Octoprint while a print is running in Cura) doesn't seem to work.