If an ufp file is uploaded to OctoPrint the Cura thumbnails plugin replaces the file with the extracted gcode file. This new gcode file isn't automatically processed with Arcwelder.
My guess is that the method used by the Cura thumbnails plugin to save the gcode file sidesteps the point where the post-processing plugins are called, maybe because it is itself a post-processing plugin.
Is this a bug in one of the plugins or an unfortunate result of the plugin engine? Or are my expectations wrong ?
I've been asked to look at the various thumbnail plugins to get them to work with ArcWelder, but have not done that since I'm still focusing on the initial release. I will take a look at some point and will try to get this working.
FYI, to my knowledge, all gcode analysis should run on the files generated by arcwelder, so I'm not sure what's going on right now.
My problem is the other way around. Arcwelder isn't run on the gcode generated by Cura thumbnails. So methinks the causation isn't in Arcwelder, but my knowledge of the plugin interface would fit with a large font in a tiny thumbnail.
I'm using the standard add file command here from within OctoPrint when extracting the thumbnail from ufp format @FormerLurker so the standard callbacks should still be processed. Let me know if there's anything I need to adjust...
That is correct. It's the same method used internally by octoprint when uploading files and it does trigger the fileadded event callbacks in all plugins that register them.
I've added compatibility for the cura thumbnail plugin and the prusaslicer plugin. However, there are some race conditions I cannot mitigate without some changes to both plugins, but I don't expect to hear many issues since pre-processing takes a bit of time for all but the smallest gcode files.
My plugin will now attempt to fetch either the cura or prusaslicer plugin impementation, grab the data directory, copy and rename the thumbnail, and add the appropriate metadata to the arcwelded file. It seems to work well for all my tests, even for gcodes with a single layer, which is why I don't expect too many race condition issues.
I started to use ArcWelder recently and it's great. I also typically push my jobs from Cura with a thumbnail, which is then handled by jneilliii's plugin and the resulting gcode then gets processed by ArcWelder and adds a separate gcode file with extra .aw in the name ... So far, so good, but it would be really great if that generated file would also have the same thumbnail as the original. Any idea whether that is possible (other than with overwriting the original gcode file)?
@FormerLurker the thumbnail plugins just set two metadata properties in octoprint that point to the file that is uploaded/extracted and stored in the plugin's data folder. You might be able to use the get_metadata methods to extract this information from the file and then set the metadata on the new file, and potentially create copies of the images in case the original file gets deleted and that thumbnail gets removed from the system. Be glad to point you to the code if necessary where/how I'm doing that.
@jneilliii and @MrK, this has been implemented and working in the devel branch. Been scrambling to put a full release together and get it all tested (many changes and new features to test). If anyone wants to help, let me know.
FYI, I do copy the images and do what I can to make sure everything happens just as you'd expect. However, there can be race conditions where my preprocessor finishes before the metadata/thumbnail are added. It should be EXCEEDINGLY rare since the preprocessor generally takes seconds to minutes, so practically there will be no issues unless you are using tiny test files like I was.
?
