I came across something lately that may be of help to someone.
Octoprint (and possibly Simplify3D too -- I had similar issues with it) has a problem with long running commands when printing over USB. Octoprint doesn't inspect the commands being sent to the printer so it has no idea how long a command takes. It has a constant timeout value in its settings that defaults to 5 seconds. Any command taking longer gets timed out and the next command ends up being sent before the printer is ready.
The printer will ask for resends, but there is a bug with that in Octoprint. Possibly in Simplify3D also because I had the same or similar issues with it.
Eventually the firmware gets confused enough to become completely unresponsive.
The solution I have for now is to calculate my longest possible move and change the communication timeout value in Octoprint. It was moving about 400mm (near the full length of the bed) creating a raft generated by Simplify3D at 470 mm/min. That math works out to about 51 seconds, so I set my timeout to be at 60 seconds for a little padding and a nice round number.
I am also going to look into improving Octoprint's command timeout to be smarter (the timeout value in the settings should be added onto the calculated time it takes to move the distance specified by the command).
Octoprint (and possibly Simplify3D too -- I had similar issues with it) has a problem with long running commands when printing over USB. Octoprint doesn't inspect the commands being sent to the printer so it has no idea how long a command takes. It has a constant timeout value in its settings that defaults to 5 seconds. Any command taking longer gets timed out and the next command ends up being sent before the printer is ready.
The printer will ask for resends, but there is a bug with that in Octoprint. Possibly in Simplify3D also because I had the same or similar issues with it.
Eventually the firmware gets confused enough to become completely unresponsive.
The solution I have for now is to calculate my longest possible move and change the communication timeout value in Octoprint. It was moving about 400mm (near the full length of the bed) creating a raft generated by Simplify3D at 470 mm/min. That math works out to about 51 seconds, so I set my timeout to be at 60 seconds for a little padding and a nice round number.
I am also going to look into improving Octoprint's command timeout to be smarter (the timeout value in the settings should be added onto the calculated time it takes to move the distance specified by the command).