Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

File metadata not getting properly reset on file overwrite with a new version #1822

Closed
rewolff opened this issue Mar 16, 2017 · 14 comments

Comments

Projects
None yet
5 participants
@rewolff
Copy link

commented Mar 16, 2017

I have reported having trouble in this area before. Having worked some more with Octoprint, I think I understand better what I would like to happen....

When working on a 3D print, I might start a print, and then before or after it has finished, I tweak a few parameters in my slicer (Slic3r) and hit the "send to printer" button again.

Previously I was told I cannot overwrite the "active" file.

Still, this is annoying: work in the slicer to change parameters I need to change, then I have to switch to octoprint, load a random model I do NOT want to print, (*) Then back to the slicer to hit "send to printer", then back to ocotoprint to load and print the new version.

At the point marked (*) I often delete the model on Octoprint as well, to make sure that the upload happened and succeeded.

Even though I followed this procedure, I managed to print a model AGAIN with a bottom-shells=0 setting instead of the 3-5 that I wanted. So this is error prone.

FYI, I think it's a bug that I can hit "upload" in my slicer, the slicer reports "succesfully sent" but Octoprint still shows "file printed successfully" (i.e. green in the file list), and probably didn't update. There should be SOME feedback when things fail....

How about:
When an upload happens to a filename that is currently loaded, the loaded file is renamed to ...-old.
The printing-process uses that -old version until it becomes idle. Then it might prompt the user: "A new version of your model is available. Load that now?".

(you (foosel) have indicated before that overwriting the active file is problematic).

This would mean I can just adjust the parameters in the slicer and hit upload, then switch to octoprint and hit print. Shorter, easier, less error-prone.

(the implementation can also be the other way around: Always upload to "...-new", and when there are no obstacles (i.e. file loaded and printing), rename to normal filename. That check and rename can also happen when the printing process becomes idle.

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 16, 2017

There's a couple of issues with this approach:

  1. Windows doesn't allow renaming files that are already opened for reading or writing, so what you propose is impossible on that OS - and OctoPrint is supposed to be able to run there too.

  2. Renaming the currently selected file to "-old" might be what the user wants. Or it might not be what the user wants because they actually only named the file the same accidentally and don't want stuff to be renamed happily just because of that. What I mean is: For you that specific workflow might work, but for others it might (or rather is) highly unintuitive and cause issues and confusion. It just feels iffy.

  3. Renaming the file in the middle of the print would also have consequences for any plugins or event hooks that might be doing something with the filename as it was reported during print start and might run into issues if said filename doesn't match the one reported at print end.

A better solution might be to copy the file that is selected for printing to a temporary folder and print it from there - but especially on a Pi large files can take a long time to be copied over (and a move is not an option here), so this doesn't scale very well and adds additional waiting time to the start of the print before we can even fire up the heaters.

From the workflow problem you are experiencing it sounds rather like maybe the upload button/API should be extended to (optionally) allow applying a rename pattern for the new file if it would need to overwrite an existing one. E.g. you are printing test.gcode and try to upload a file named the same, it would detect that and either prompt you for a rename or just append a suffix (test-2.gcode).

@nophead

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2017

@rewolff

This comment has been minimized.

Copy link
Author

commented Mar 16, 2017

It could be that IF you already know what happens exactly, THEN you can do things that are "supposed to work" .

I'm getting too little feedback to be confident that sending a new file will replace the old one. Foosel told me the current file cannot be replaced. Apparently the conditions seem to be "the currently PRINTING" file cannot be replaced. It's the lack of feedback that makes me unsure. It is the fact that I've been printing the wrong file (hours of wasted time) that makes me wary of trying suspected procedures again.

So, renaming the active file cannot happen for two reasons. That leaves my other suggestion: Giving the new version a new name. And just giving each file a sequential number would be fine too. Then I'd be able to see the <version 5> still printing while a black-unprinted <version 6> is in the uploads list. And when Octoprint finishes, the <version 5> in the file list would turn red or green depending on if the print ran to completion, and version 6 might auto-load.

It is about feedback. I've HAD things go wrong with the wrong version being printed, so I need clear feedback as to what's going on to believe that things are going the way I want them to.

The: "attach a version number" could be helpful in another workflow that I have not been able to do. (i.e. was cumbersome in the past, but might be useful with the version numbers).
Sometimes I create a model in openscad. The file is simply called say "train" (just a random word that comes to mind, not an actual example). I then can select whether I want to view the whole assembly or the subparts that need to be printed separately. The workflow would then be: select one subassembly, export to STL, slice-and-upload, select the next subassembly, slice-and-upload, and repeat.

Then, without having to change the filename I would get train-1, train-2, and train-3 as files-to-print on octoprint. Not ideal when developing: if subassembly 2 needs a change, things become complicated with the user having to remember that 4 is the changed 2.

It is the lack of feedback that makes me unsure. I have tried changing "timelapse" from "timed" to "on Z change", but the result didn't look as if the change had been applied.

I now see "timelapse: timed" in the status window. So the lack of feedback caused me to think: "OK, no error messages, seems to have worked, hope for the best", instead of the feedback I needed: "NO!! cannot apply your changes right now, come back later".

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 16, 2017

I just noticed that you said you are using Slic3r's "Send to printer" OctoPrint integration. The lack of feedback there (no "File currently printing, can't upload, rename?") is something that would need to be done by THAT. I can't do anything in OctoPrint about this. The API endpoints are there, so I suggest you also take that particular issue up with the Slic3r team.

The only thing I can do from my side regarding your particular request here is make the workflow in OctoPrint's own UI more transparent, but any connecting third party clients that utilize the upload API need to check current states properly and implement fallback workflows on their own. Attempting to do that in OctoPrint will break things left and right for other people's existing workflows, I won't do that.

@nophead

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2017

What I was trying to say is perhaps there is something wrong with "Send to Printer" button in Slic3r. The Upload button in OctoPrint seems to behave better and without any surprises. I get a clear indication when I upload a new version of a file I just printed because the print progress bar resets, and the Print Time, Print Time Left and Printed fields reset to blanks. If I have the gcode tab open it reloads. I.e it changes from the just printed state to the not started printing state.

I think older versions didn't behave this well but resent ones do. I recently spend a day printing calibration blocks and bridge tests and never got confused which version I was printing.

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 16, 2017

@nophead thanks for clarifying. Yes, there were some bugs in past versions with regards to updating the currently selected file, but I think that should now be mostly resolved. Offering alternative "upload as" names when you upload while still printing a file named the same might be interesting, maybe also allowing something like "select for printing after current print finishes", although the latter would proof tricky to implement.

But I certainly can't fix third party clients, and as far as I know the Slic3r upload functionality is very much only "push file to upload API and pray", no state check or anything like that, so that would explain bad experiences.

@rewolff

This comment has been minimized.

Copy link
Author

commented Mar 16, 2017

I suspect that those feedback thingies ARE there. But I have "slic3r" and "everything 3D" running on ONE virtual desktop, and my web browser and Octoprint on another. So when I hit the upload button and switch to my octoprint desktop, things look more-or-less unchanged for me. When you upload using the "upload button", you are on the octoprint page and the changes catch your eye.

@nophead

This comment has been minimized.

Copy link
Contributor

commented Mar 16, 2017

Yes, but again, that is a usability problem with the send button of Slic3r. If you use the upload button in OctoPrint everything is good. So you should request Slic3r to give better feedback.

@rewolff

This comment has been minimized.

Copy link
Author

commented Mar 16, 2017

No I don't think so.

IF slic3r tries to upload, but doesn't report the error, that's a slic3r problem. Agreed. That may have happened in the past. Maybe not.

But in the case that things WORKED or should have worked, ocotprint does not give me enough feedback to convince me things have worked. Only when I delete the file, verify that it is indeed gone, and then upload and see it back again, THEN octoprint manages to convince me that there is a new file.

@foosel

This comment has been minimized.

Copy link
Owner

commented Mar 16, 2017

OctoPrint tells you when a file was uploaded ("Uploaded: a few seconds ago"). And if it was already printed. And if it is the file that is currently selected. You can also sort by upload date. You can filter out files you already printed. I'm sorry, but what else should it be doing to help you in deciding what version of the file it is you are looking at when you upload it through a third party app?

@ntoff

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2017

But in the case that things WORKED or should have worked, ocotprint does not give me enough feedback to convince me things have worked. Only when I delete the file, verify that it is indeed gone, and then upload and see it back again, THEN octoprint manages to convince me that there is a new file.

How is octoprint supposed to respond? Let's say we live in a perfect world and I make a few assumptions about how octoprint and slicer work (even though I don't know 100% because I've never used it that way so please don't hate me @foosel :( )

Let's say the upload system works like this: Octoprint detects an upload, it detects the session used to upload that, and the way you uploaded it (via its own web interface or via 3rd party API interface).

Let's say it detected a 3rd party api upload, via slic3r, and there was an error in uploading so octoprint sends out a warning to the 3rd party interface because that's where the upload originated from.

It's then up to slic3r to deal with that error message, NOT the web browser you may or may not even have open, because that's NOT where the upload originated from.

The way your work flow currently is, it's up to slic3r to detect and present you with any error, since that's where the upload is originating from, for all slic3r knows you might not even have access to a web browser, for all octoprint cares that web browser session it sees might be a random person half way across the world you have allowed to watch a print in progress so there's no point presenting the error message through the web interface.

Now, as I said I don't know for sure whether or not octoprint sends out error messages for 3rd party API access, but whether it does or not, there's nothing it should display in a browser window if there's an error while uploading from a 3rd party app, as there's no way of knowing whether that browser session belongs to you, another admin, a random user who can't act on that error anyway, or whether it's just a browser window open on your work computer that you aren't even anywhere near. Outputting an error message there would be utterly pointless.

edit: And ok as a test I just tested slic3r version 1.33.8 prusa edition, and uploading a file while printing does send an error message back to slic3r. So I guess it does work more or less the way I thought.

image

@rewolff

This comment has been minimized.

Copy link
Author

commented Mar 20, 2017

I just tried it again this morning. One of the things Octoprint can do for me is to color the just-uploaded-not-printed file black instead of green (=print finished).

I typed that a few days ago, but since then have seen it multiple times: The "uploaded a few seconds ago" file remains green because a previous version printed to completion. The file got replaced, and THAT FILE did not print to completion.

This weekend I also did a few things with a friend of mine. It turns out he's thinking about 3D slicing and printing in a whole different way than I am. For me it is an iterative process in finding the right settings for a specific print to come out right, For him (and I'm starting to think you, foosel, as well) it is: you dial in the right settings, and out comes an acceptable print. So you have project A, B and C, you slice them and print them one after the other on octoprint. Filenames A, B and C reflect the projects and the green color indicates if they were printed or not.

I'm working on project A and try (and fail) to print it a bunch of times before I'm satsified. I could upload the files as "project A, version 23" and the next as "project A version 24", but that clutters up things (tens of versions of projects lying around) and is cumbersome as in openscad and slic3r: I get a perfectly fine "project A" default filename.

@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 10, 2017

I just tried it again this morning. One of the things Octoprint can do for me is to color the just-uploaded-not-printed file black instead of green (=print finished).

I checked and this was in fact a bug, now fixed on maintenance, soon devel and to be released with 1.3.3. Relevant commit is ef01560.

If a file is added, same name, different contents (determined by hash), the full set of metadata will be reset. That means that the file should turn from green (or red) to black, no past prints, no "last printed" etc. This should apply to files that came in through the API via file upload, from the watched folder or really any official way to add files to the system.

@foosel foosel added this to the 1.3.3 milestone Apr 10, 2017

@foosel foosel changed the title Uploading new versions of a model [request] File metadata not getting properly reset on file overwrite with a new version Apr 10, 2017

@foosel

This comment has been minimized.

Copy link
Owner

commented May 31, 2017

1.3.3 was just released.

@foosel foosel closed this May 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.