Modify running print

Development
1

I want to add functionality to switch out the current print, mid print.

My usecase is for someone who is mid way through printing some item, and they decide they want to change some options - for example, adjust the infill density, the layer height, or they have realised the house they are printing really needs a chimney!

The user interface, for example from Cura, which has octoprint integration, would involve the user adjusting the settings they want to change, then clicking "print" again. If the filename currently being printed matches the filename of the new document, then cura would pop up a dialog saying "Print already in progress. Either abort the print and start again, or modify remainder of existing print. [Abort] [Modify]".

Implementation-wise, the octoprint POST /api/files/local API would be updated to allow the currently printing file to be uploaded again (it currently returns an error). The API call would have an extra field added called modify_print_changeover_marker. This is a string that uniquely exists in both the original file, and the modified file. For example ;Layer:57. At that point in the print, octoprint would switch from the old file to the new. It would be up to the slicer software to decide what markers to insert and where.

If the marker had already been passed, octoprint would return an error. The error would contain the current byte position in the file, allowing the client to retry with a later marker. If the client desires, they can leave out the content of the uploaded file, and get an error response which also includes the current byte position in the file, allowing the client to avoid double-uploading the data.

So... Is the above design reasonable? It tries to touch as few components as possible to enable the usecase. Are there better approaches?

2

[quote="Hello1024, post:1, topic:52546"] the octoprint POST /api/files/local API would be updated to allow the currently printing file to be uploaded again (it currently returns an error).
[/quote]

The current implementation only returns an error if the file you are trying to replace is currently being printed. If the file is being printed, the file is open for reading. You can not write to a file that is open for reading.

Why not instead upload a whole new file with a different filename, and then have octoprint (or a plugin you write for octoprint) find a suitable position in both files to switch from the old file to the new file. Once switched, you could remove the old file, but I would keep that as an option.

3

If the file is being printed, the file is open for reading. You can not write to a file that is open for reading.

This isn't an issue, because the file can be unlinked and replaced while the original is still open for reading. The question is which design is least 'surprising'.

your proposal raises the question of how to ensure that the file being uploaded is a suitable replacement for the file being printed - although the client could download the file and do some compatibility test.

4

Isn't it that what @fieldOfView suggested?

5

OctoPrint is - by design - system agnostic. Can you do this on windows too?

I don't see how my proposal changes that in any way.

To prevent concurrency-like issues, I think this should be checked on the server (OctoPrint), not the client.

1 Like