Newest octoprint problem
Newest octoprint problem
Ok so I am running the newest octoprint and it will not work with the auto level mod. It loads and runs the print till it hits the G29 then hangs with checksum errors. This same gcode prints fine from S3d . Any ideas ? I did read a suggestion to try the development branch. Or to run G28 and G29 before heating anything and leave it out of the start script. Not tested yet.
Re: Newest octoprint problem
S3D doesn't do checksums. Octoprint obviously does do checksums.
Re: Newest octoprint problem
It is off by default. Turning it on doe not change the results. Removing all homing code from startup lets the print run ok though.
Re: Newest octoprint problem
What is "it"?It is off by default. Turning it on doe not change the results
Where does the auto/level/homing G-code come from? Does it have checksums?
Re: Newest octoprint problem
Added to start of s3d gcode. G28 then G29 . And I do not believe they have checksums.
Re: Newest octoprint problem
I don't use Octoprint, so I'm not sure how it works. I have seen some output on the forum here that shows Octoprint using checksums.
I have discussed checksums with the S3D people and they said that they don't use them (that was pre- version 3).
So, Octoprint is adding the checksums to send to the printer. To do this it would have to assign a line number to the G-code lines and calculate the checksum for each line before passing it to the printer.
Marlin will not check the checksum unless the G-code line begins with a line number (N1, N2, etc). If the G-code line does begin with a number then Marlin will check the checksum and if it is not correct it will error out (may request the line again several times before it errors out, or maybe not I haven't checked that).
So, I think the problem is in Octoprint. I don't know why it would do it correctly for most of the file, but not the auto level lines.
I have discussed checksums with the S3D people and they said that they don't use them (that was pre- version 3).
So, Octoprint is adding the checksums to send to the printer. To do this it would have to assign a line number to the G-code lines and calculate the checksum for each line before passing it to the printer.
Marlin will not check the checksum unless the G-code line begins with a line number (N1, N2, etc). If the G-code line does begin with a number then Marlin will check the checksum and if it is not correct it will error out (may request the line again several times before it errors out, or maybe not I haven't checked that).
So, I think the problem is in Octoprint. I don't know why it would do it correctly for most of the file, but not the auto level lines.
Re: Newest octoprint problem
It hangs as soon as the G29 gets issued. If I manually enter G28 then G29 from terminal and then issue a print command and the print starts before motors time out it will run fine. As long as the s3d file does not have those commands at the beginning. Need grab a nightly build and try that I guess.
Re: Newest octoprint problem
Ok so I know I tried this already. But for giggles I swapped out the usb cable this morning and all is well !!! Fricky Frack !!!!
Re: Newest octoprint problem
Glad things are working. I never knew that USB cables could refuse one program but not another. Are you running on a HAL 9000?
Re: Newest octoprint problem
I wish !!!! lol wait... maybe I do not wish on second thought !!! Well I did reinstall 1.2 again .....maybe I will try the old cable next print to confirm.