This is a weird one that has been bugging me for quite a while and I am now at a point where I need some different eyes looking at this.
I am running Ubuntu 18.10, Cura 3.6.0, Octoprint on a pi3+. The link from computer to pi is wireless. In recent tests, octoprint did not show any power issues or heat issues in the task bar. The printer is a creality cr10s.
I have a small object that I print, it prints in about 38 minutes so it's not big by any means.
I have had this problem on occasion where I would start a print, the print head goes to the center of the build plate (init sequence, g28) and then, rather than going to the position where the model should start it goes to max x and max y, runs past the end (or to the end) of it's range and dumps a whole bunch of filament rather quickly.
This used to happen once in a blue moon and I was prepared to call it 'poor power' which is something well documented for pi's and I can see evidence of power issues in octoprint on occasion.
The problem now happens at a rate of just about 50%, it happens even when no power issues are logged in octoprint and a good number of times it results in a clogged extruder - it is driving me bonkers!
The curious thing is that looking at the commands going to the printer from octoprint show that it is printing in the correct location (but it isn't there physically)
I have turned on logging of all com messages and got a good log file for a proper print. I would then delete the log file, run another, identical print with no re-slicing and it pretty reliably fails now. Unfortunately no log file would be generated.
The log file attached here has a good print at the beginning and I believe a failed print at the very end. I do not know why the failed prints would not generate a log file by themselves.
Comparisons of the content of the built in command window showed some discrepancies but in both the proper print as well as the failed print the system commands are sent for the correct x/y coordinates.
If I get a failed print and then start the print again, it always initializes the printhead like it is supposed to do but then goes off to max x/y. The only way to get out of things at that time is to reboot octoprint.
It is driving me nuts !
The fact that a reboot of octoprint 'resets' things would seem to say that either the pi or possibly the printer electronics are off in la-la land but I am unclear how to localize the error to one or the other.
If anybody can see anything odd in the attached com log file I would appreciate your thoughts!
Well crap, the file is too big ... I have cut out the middle section of the comms of building the first sample, hopefully this will attach now.
serialgoodbadshortened.log (169.5 KB)