Using two pen plotters to make artworks.
The issue is that despite my prints finishing perfectly, the web interface almost always hangs at 99%. The only way to get the machine ready for a next print is to reboot the Pi. I am able to perform any task, except the cancellation of the current print (that is finished in reality) and the selection of a new file. In other words: the queue gets stuck.
I just noticed that after a few minutes of waiting, the last print that got stuck at 99% did in fact finish in the Octoprint web GUI.
I do not understand why there is sometimes a long delay, and sometimes it immediately displays it's finished. Maybe I haven't waited long enough sometimes to see it actually eventually finishes. But restarting the Pi is often faster. In between prints this can amount up to over five minutes of waiting before I can do the next print making it more time consuming than I'd like it to be.
I haven't been able to pinpoint the cause, but it's happening on two machines I run and both machines with gcode files generated by the same program. I suspect there may be hidden characters in the files, or a mix of LF/CRLF that could be the cause. I sadly was not able to find out if this was the issue.
I checked the terminal in Octoprint after the printing queue got stuck and the terminal shows less than what was actually executed by the machine in the end.
Here is a gcode file as an example:
box_side_hatch_4_Pow_N_A_M_A4_molotow_inks_molotow.gcode (152.9 KB)
I have been looking for certain logs that might shine a light on the reason why the prints don't finish within Octoprint but do finish in real life. However, I have not been able to find the relevant logs, so I would gladly be pointed to that direction.
I am not aware of safe mode actually being able to show me how the print could work. My machines are not 3D printers but pen plotters and I am depending on one specific plugin for this process to work at all. This is the Enclosure plugin.
octoprint-systeminfo-20220106154942.zip (14.7 KB)
This is a bundle of the machine that isn't updated to the latest wares, but my other machine has the same issues and that one is updated to the latest ware and plugins. So this doesn't make any difference.
Machine A uses an RPI 4B 2Gb with a Ramps 1.4 communicating over UART
Machine B uses an RPI 3B plus with an SKR 1.3 comminucating over UART as well
I should also note that Machine A has a long 5 to 6 second delay between pausing and resuming a print, where Machine B has no delay. I'm using [at]pause and [at]resume in my files for this purpose. If anyone knows why Machine A halts for 5 to 6 seconds each time I pause or resume a print, that would be great too as it's time consuming on prints with more pauses.