A plugin for OctoPrint used to convert G0/G1 commands to G2/G3 commands. Reduce the size of your gcode files, and reduce number of gcodes per second sent to your printer.
Other
444
stars
25
forks
source link
Under OctoPrint 1.10, ArcWelder deletes original .gcode file from filesystem, but OctoPrint UI folder still shows the file. #266
I have ArcWelder set to convert a file, then delete the original.
Since upgrading OctoPrint to 1.10, I've noticed that files I send from ORCA via the API appear in the OctoPrint folder specified, ArcWelder automatically processes them, and deletes the original .gcode file from the Linux filesystem, but leaves the representation of the file in the OctoPrint UI.
No amount of attempting to delete the OctoPrint representation using the OctoPrint UI will get it to go away. The solution is to log into the Linux machine, touch the filesystem in the appropriate folder with the exact filename featured in the OctoPrint UI. That means there's now a (0-byte) file that can be deleted. Then in OctoPrint UI, I can delete the file I've created with touch.
The error message from OctoPrint is: "Failed to remove entry. Could not remove entry. Please check octoprint.log for possible reasons."
Running a Raspberry Pi 4 with 4GB RAM, and the OctoPi distribution 1.0.0 with camera stack from 5/2023, upgraded with OctoPrint 1.10, latest Linux updates.
"feels" like a race condition: like the file gets deleted from the filesystem by ArcWelder before OctoPrint knows there's a file to delete or something.
FYI, I've been working with a "small" file today while this has been occurring. The gcode is 2.2MB before ArcWelder processing. The small file might trigger a race, where a large one might not. That again, is just a guess.
Update: More interesting, it appears you might be able to "cut" the nonexistent file, while you can't "delete" it.
I have ArcWelder set to convert a file, then delete the original.
Since upgrading OctoPrint to 1.10, I've noticed that files I send from ORCA via the API appear in the OctoPrint folder specified, ArcWelder automatically processes them, and deletes the original .gcode file from the Linux filesystem, but leaves the representation of the file in the OctoPrint UI.
No amount of attempting to delete the OctoPrint representation using the OctoPrint UI will get it to go away. The solution is to log into the Linux machine,
touchthe filesystem in the appropriate folder with the exact filename featured in the OctoPrint UI. That means there's now a (0-byte) file that can be deleted. Then in OctoPrint UI, I can delete the file I've created withtouch.The error message from OctoPrint is: "Failed to remove entry. Could not remove entry. Please check octoprint.log for possible reasons."
Running a Raspberry Pi 4 with 4GB RAM, and the OctoPi distribution 1.0.0 with camera stack from 5/2023, upgraded with OctoPrint 1.10, latest Linux updates.
"feels" like a race condition: like the file gets deleted from the filesystem by ArcWelder before OctoPrint knows there's a file to delete or something.
FYI, I've been working with a "small" file today while this has been occurring. The gcode is 2.2MB before ArcWelder processing. The small file might trigger a race, where a large one might not. That again, is just a guess.
Update: More interesting, it appears you might be able to "cut" the nonexistent file, while you can't "delete" it.