search

intelligent-agent / redeem

Firmware for Replicape
http://wiki.thing-printer.com/index.php?title=Redeem
GNU General Public License v3.0
36 stars 44 forks source link

M27 replies inconsistent for OctoPrint #142

Closed goeland86 closed 5 years ago

goeland86 commented 5 years ago

See https://github.com/foosel/OctoPrint/issues/2910 for the problem. Seems that Redeem is sending current print byte and then the Not printing from SD.

Bonus: we now have a spec to follow for SD-card printing methods.

Wackerbarth commented 5 years ago

Trying to understand how the system is supposed to behave with respect to printing from a file.. Is this description correct? The SD Unit is a "black box" that provides a collection of available selections and commands to maintain that collection. It also provides a "portal" which supplies the contents of a selection. The M27 command provides the status of the portal. Initially, the portal is "detached". (M27 == "Not SD printing."). M23 "attaches" the portal to the designated selection (M27 == SD printing byte 0/235422). M24 starts printing (M27 == SD printing byte 1000/235422). When the print finishes, the portal returns to the "detached" state (again, M27 == "Not SD printing.").

goeland86 commented 5 years ago

@Wackerbarth the current code is basically jumbling its responses to M27 queries, sending back 2 status responses instead of a single one (SD printing byte x/xyz then Not SD printing instead of an XOR on the two).

I can fix this if it's not clear how SD printing was meant to work. In any case this will be moot when OctoPrint 1.4.x comes out and we have our own communication layer between Redeem & OctoPrint.

Wackerbarth commented 5 years ago

It's not hard to fix the multiple responses. The question is "how is the printer expected to behave after a file finishes printing?". At present, we leave the file "selected" which would imply a "0/xxx" response until we start printing again. I think that the behavior should be to have it automatically disconnect at the end. However, we might change "M24" to automatically imply a repeat of the previous "M23" (if there was one). But, it might also be more appropriate to REQUIRE another M23. (This has nothing to do with the Octoprint interface, per se.) How do we want the printer to function?

goeland86 commented 5 years ago

My understanding is that Marlin (which OctoPrint sort of expects, G-Code behavior-wise) does the latter, where a repeat print requires another M23.

The idea being that you can do M25 to pause a print from SD, interact outside the SD-file through normal GCode (i.e. filament switch, etc.), then M24 to resume the print.

Wackerbarth commented 5 years ago

I agree that "pause" leaves the file connected (at its present byte position). The question only concerns what happens once we reach the end. After cleaning the bed, can I print another copy by simply sending another M24? That would be a reasonable behavior for a stand-alone printer with a "Print" button.

goeland86 commented 5 years ago

So, OctoPrint (either from the web or through Toggle endpoints) issues a new M23 before a new M24 for printing a new copy of the file.

I suggest that we then disconnect the file after the print completes

goeland86 commented 5 years ago

Further discussion is ongoing in #145, closing here.