An ongoing problem with the printer doing weird things

General
1

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)

2

Just to make sure this is understood - the model was sliced once in Cura and then 'print via octoprint', it did it's thing, stopped normally, I would go back into the Cura window and just hit 'print via octoprint' again.
That is when the printer went off to la-la land

The two bits of g code that seem to be most telling:
first the code that works ok:
2019-01-16 04:21:29,771 - Recv: X:150.00 Y:150.00 Z:0.52 E:0.00 Count X:12000 Y:12000 Z:0
2019-01-16 04:21:29,774 - Recv: ok
2019-01-16 04:21:29,779 - Send: N10 G1 Z15.0 F600025
2019-01-16 04:21:29,788 - Recv: ok
2019-01-16 04:21:29,792 - Send: N11 G92 E0119
2019-01-16 04:21:29,816 - Recv: X:150.00 Y:150.00 Z:15.00 E:0.00 Count X:12000 Y:12000 Z:0
2019-01-16 04:21:29,819 - Recv: ok
2019-01-16 04:21:29,823 - Send: N12 G1 F200 E325
2019-01-16 04:21:29,869 - Recv: ok
2019-01-16 04:21:29,873 - Send: N13 G92 E0117
2019-01-16 04:21:29,897 - Recv: X:150.00 Y:150.00 Z:15.00 E:0.00 Count X:12000 Y:12000 Z:0
2019-01-16 04:21:29,899 - Recv: ok
2019-01-16 04:21:29,904 - Send: N14 G92 E0114
2019-01-16 04:21:29,928 - Recv: X:150.00 Y:150.00 Z:15.00 E:0.00 Count X:12000 Y:12000 Z:15
2019-01-16 04:21:29,929 - Recv: ok
2019-01-16 04:21:29,933 - Send: N15 G1 F2400 E-26
2019-01-16 04:21:29,944 - Recv: ok
2019-01-16 04:21:29,948 - Send: N16 M10718
2019-01-16 04:21:29,961 - Recv: ok
2019-01-16 04:21:29,965 - Send: N17 M204 S100097
2019-01-16 04:21:29,976 - Recv: ok
2019-01-16 04:21:29,980 - Send: N18 M205 X30 Y3028
2019-01-16 04:21:29,992 - Recv: ok
2019-01-16 04:21:29,996 - Send: N19 G0 F3600 X57.674 Y51.094 Z0.041
2019-01-16 04:21:30,024 - Recv: ok
2019-01-16 04:21:30,027 - Send: N20 G92 Z0.2*118

2019-01-16 04:21:30,053 - Recv: X:57.67 Y:51.09 Z:0.20 E:-2.00 Count X:12000 Y:12000 Z:246
2019-01-16 04:21:30,056 - Recv: ok
2019-01-16 04:21:30,065 - Send: N21 M204 S50080
2019-01-16 04:21:30,084 - Recv: ok
2019-01-16 04:21:30,088 - Send: N22 M205 X20 Y2021
2019-01-16 04:21:30,101 - Recv: ok
2019-01-16 04:21:30,109 - Send: N23 G1 F2400 E044
2019-01-16 04:21:30,132 - Recv: ok
2019-01-16 04:21:30,138 - Send: N24 G1 F1800 X58.775 Y49.843 E0.0526654
2019-01-16 04:21:30,149 - Recv: ok
2019-01-16 04:21:30,155 - Send: N25 G1 X59.172 Y49.454 E0.07022*82
2019-01-16 04:21:30,181 - Recv: ok

and then the section that did not work ok:

2019-01-16 05:15:19,426 - Recv: X:150.00 Y:150.00 Z:0.52 E:862.21 Count X:12000 Y:12000 Z:0
2019-01-16 05:15:19,431 - Recv: ok
2019-01-16 05:15:19,440 - Send: N9 G1 Z15.0 F600033
2019-01-16 05:15:19,474 - Recv: ok
2019-01-16 05:15:19,478 - Send: N10 G92 E0118
2019-01-16 05:15:19,505 - Recv: X:150.00 Y:150.00 Z:15.52 E:0.00 Count X:12000 Y:12000 Z:0
2019-01-16 05:15:19,508 - Recv: ok
2019-01-16 05:15:19,513 - Send: N11 G1 F200 E326
2019-01-16 05:15:19,522 - Recv: ok
2019-01-16 05:15:19,526 - Send: N12 G92 E0116
2019-01-16 05:15:19,550 - Recv: X:150.00 Y:150.00 Z:15.52 E:0.00 Count X:12000 Y:12000 Z:1
2019-01-16 05:15:19,553 - Recv: ok
2019-01-16 05:15:19,558 - Send: N13 G92 E0117
2019-01-16 05:15:19,581 - Recv: X:150.00 Y:150.00 Z:15.52 E:0.00 Count X:12000 Y:12000 Z:25
2019-01-16 05:15:19,585 - Recv: ok
2019-01-16 05:15:19,589 - Send: N14 G1 F2400 E-27
2019-01-16 05:15:19,598 - Recv: ok
2019-01-16 05:15:19,601 - Send: N15 M10717
2019-01-16 05:15:19,614 - Recv: ok
2019-01-16 05:15:19,618 - Send: N16 M204 S100096
2019-01-16 05:15:19,630 - Recv: ok
2019-01-16 05:15:19,634 - Send: N17 M205 X30 Y3019
2019-01-16 05:15:19,645 - Recv: ok
2019-01-16 05:15:19,649 - Send: N18 G0 F3600 X57.674 Y51.094 Z0.040
2019-01-16 05:15:19,678 - Recv: ok
2019-01-16 05:15:19,682 - Send: N19 G92 Z0.2*124

2019-01-16 05:15:19,708 - Recv: X:207.67 Y:201.09 Z:0.20 E:-2.00 Count X:12000 Y:12000 Z:271
2019-01-16 05:15:19,713 - Recv: ok
2019-01-16 05:15:19,733 - Send: N20 M204 S50081
2019-01-16 05:15:19,741 - Recv: ok
2019-01-16 05:15:19,748 - Send: N21 M205 X20 Y2022
2019-01-16 05:15:19,755 - Recv: ok
2019-01-16 05:15:19,763 - Send: N22 G1 F2400 E045
2019-01-16 05:15:19,772 - Recv: ok
2019-01-16 05:15:19,780 - Send: N23 G1 F1800 X58.775 Y49.843 E0.0526649
2019-01-16 05:15:19,803 - Recv: ok

Note the lines immediately below the dashed lines - this is where there is a huge difference. There are a few minor deviations which I don't understand but then there is this BIG discrepancy which seems to be where things go weird. Note that after that line , the x and y coordinates seem to be the same again but in the second code snippet the head never moves to the correct x and y coordinates again even though it is instructed to do so.

I also thought about initialization codes somewhere throwing things out of whack and requiring a reboot to reset but for the life of me I can't see where this would be happening.

3

Looks like I am having a conversation with myself here and demonstrating how old age can impair brain functionality .....
I noticed that the 'bad' log had an x/y coordinate that was exactly 150 mm off in both x and y. It occurred to me that an absolute vs relative positioning would cause such an error and after some digging I found a stray G91 code in my init string.
I have not yet confirmed this diagnosis but I suspect that is my probem!

Move along, nothing to see here folks, just someone having a seniors moment ... move along now (please) !

1 Like
4

Don't worry, even though I wouldn't call myself a senior when I started printing stuff, relative vs absolute moves have screwed me over many times.

That's why ALL my gcode comes from the slicer, I absolutely HATE hosts that inject their own gcode, and I detest slicers that do their own thing as well (simplify3d, cura) when not told explicitly not to. I stuck to skeinforge for the longest time just because it was reliable and never did anything without me telling it to.

5

LOL ... well I was aware of the code injected at start and at finish of the print. I had problems with something similar once before quite a while ago. I believe i commented out both g91 and g90 codes in the post print code but possibly inadvertently deleted the very first character in that post amble which was the ';' to comment out that line. It is very easy to mess this up in Cura as you don't have to actually save any changes. The same situation has happened when I inadvertently changed from Marlin to some other dialect which caused me quite a bit of time searching.
Oh, the bit about 'it never did anything without me telling it to' doesn't work for me because it is not unheard of that I tell it to do something that is stupid :frowning:
Anyway, I am happy to report that the issue has been resolved !

6

Weird weird things

I'll start with all the system info data I have.

  1. Raspberry Pi 3b rev 1.2, running the OctoPrint version from a few weeks ago.

  2. OctoPrint v. 1.3.10

  3. OctoPie v. 0.15.1

  4. Cura 15.0.2

  5. Monoprice 15365 - aka Mini v.1

  6. Serial port and Baud Rate set to AUTO.
    Logs to be attached.
    This thing printed the "cat" demo print perfectly. WOW

Weird 1: I'm constantly fighting with the temps on the extruder & the bed. Especially if I try to set from the OctoPrint GUI. If i manually set on the printer, it stays longer, but then changes. For PLA 160 head, 60 on bed are desired, but it pushes up to the ABS temps, 200 & 70... something like that. I push it down, it flips back up. I push it down to 162 & 63, it stays some times. Never through an entire print. I'm only trying to print PiZero cases, and PiCamera cases. Nothing big.

Weird Weird #2:

I check the level on the bed. Manually set printer to "home" correct extruder height. Start a PRINT job. (these are small jobs, 80x80) It starts by lifting the head 20mm, it bangs the head on X against the tower for 10-15 seconds. It then moves on Y 80mm back & all the way R on X. Then it bangs the X belt again. It lowers the head at that spot 120.80 but stops 5mm above the bead! WTF? Oops...
I can only get one file to upload, the other one I have from today is the "serial.log"

Comments/Suggestions on this weirdness. I've tried a few .stl files.

octoprint.log (103.8 KB)