Odd skipping sound leading to low extrusion only when using Octoprint

Get Help
1

What is the problem?
Updated:
The printer behaves differently when Octoprint is being used. When doing curvy areas (possibly with retractions) the extruder starts making a skipping sound, shaking the printer. When the printer is laying down support structure, it seems to move too fast, essentially peeling off the support (on the first layer). This ONLY happens when I use Octoprint, and it happens every time. When using Simplify3D's control panel, or an USB stick, everything prints fine. I've also tried running Octoprint from the laptop that I use the control panel, and experience the exact same problem.

Old:
When printing with Octoprint, it seems to ignore speed settings and move too fast (similar to this thread). The result is a clicking noise at the extruder during certain operations (probably filament skipping?). The clicking noise seems to mostly happen at locations with many curves. When printing supports, the nozzle moves too fast, pulling the filament back up. Everything works fine when printing with Simplify3D's control panel or an USB stick.

Edit:
At first I thought the filament was skipping because the printer was trying to extrude too fast, but this doesn't seem to be the case after looking at the videos. The filament skipping seems to happen at the same speed.

Videos:
When running the gcode from Octopi (Safe Mode): Dropbox
When running the gcode from USB: Dropbox

What did you already try to solve it?
I don't have the Exclude Region plugin installed, but tried to uninstalling all other non-essential plugins anyway. Ran octoprint in safe mode (probably redundant?). I've tried printing the same parts from an USB stick and the Simplify3D control panel, which worked fine. Tried changing gcode flavor and lowering the print speed in Slic3r PE.

Gcode: https://www.dropbox.com/s/x90cii263gjsn41/rpi3-bottom_netfabb%281%29.gcode?dl=0

Edit (Additional things attempted):

  • Tested the same printer running Octoprint from a laptop instead (works perfectly fine with the same laptop running the S3D control panel).
  • Checked GCODE Scripts. Only the cancel script is there.
  • Tried to disable Linear Advance with M900 K0
  • Tried a different version of Octoprint (1.3.4,6,8 and 9rc2)
  • Installed a fresh new Octopi again
  • Different slicer

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)

Printer: Creatr HS (Firmware 2.5)
Raspberry Pi Model B+
Octoprint Version 1.3.8
Octopi Version 0.15.1
Slic3rPE 1.40.1
No plugins

2

Are you sure you weren't just lucky when you tried printing from other interfaces? Or, is your printer stuttering when printing from OctoPrint? Also, you might want to check your 'GCODE Scripts' within the OctoPrint settings to make sure you don't have anything in there that's interfering with your print.

3

Very sure. I repeated the experiment many, many times. It's the same for other prints as well. I've never experienced any of those phenomena while printing with the S3D control panel or an USB stick.

I don't have access to the printer or the server at the moment, but I'll check out the GCODE Scripts tomorrow!
Would printer stuttering cause the filament to skip like that? Genuine question. The behavior when doing supports is also different (seems to move faster).

4

Thanks for convincing me that you have indeed tested many times on all platforms with consistent results! Pardon me, but I had to ask :slight_smile:

I've had some minor jamming issues before when I had serial issues (stuttering). In my case it was due to poor bandwidth and a power hungry plugin (is your PSU adequate for your Pi?). In the worst case the 'clicking' noise leads to a total jam, and no more printing. I was printing with a bowden at the time, and the stuttering eventually lead to a bulge of plastic in my extruder that wouldn't fit into the bowden tube, causing the clicking (filament grinding) during retraction. This was with my Prusa Mk2MMU, which is infamous for these kinds of jams.

That being said, it's totally possible that your issue is different entirely, but I've not heard of such a thing with stock OctoPrint before, so I bet it's something that can be corrected.

5

Thanks for offering possible solutions!

Total jams have happened on that printer before, however it was because the extruder area was heating up too much, causing the PLA to soften. I was also using an enclosure during those times (also happened on sunny warm days). It has never happened again after adding a fan to that area, though. What you described sounds very similar to those times. I'm pretty sure it's different this time, and it's only happening with Octopi for some reason...

I'm using a 2.5A PSU for my Pi. I'm also only running Octoprint in Safe Mode at the moment.

I hope so!

6

Ok, thanks for the update. So, I watched your videos side by side, and I think you'll find that the OctoPi version is actually printing slower when it makes those grinding noises. This sounds to me like you are using linear advance, but maybe not. I believe your printer is based on Marlin, so it might be set. Linear advance and usb printing don't play well together due to processing limitations. Fortunately this is easy to test. Add the following line to your start gcode:

M900 K0

Put it right after the T1 command and let me know if that does anything. You could also send the command via the terminal to see if your printer accepts the command.

It's a longshot, but I've heard that sound before, and it was when I was toying with linear advance on my Prusa.

7

Thanks! I will try that and reply as soon as I have access to the printer tomorrow!

8

If that's the case though, how does the Simplify3D control panel deal with it? Or is that a stupid question?

9

That's a great question, and I don't know the answer unfortunately. It may be that this is not the problem, or it could have something to do with the serial implementation. OR, maybe there is something in the start gcode within Octoprint. This is a very mysterious problem, and I'm really interested in the eventual solution now :slight_smile:

10

This may be a stupid direction to consider but what if it's heat creep at the upper end and it's interfering with extrusion? Maybe the filament gets hot up there and the driving gear makes that ratcheting sound because it's chewing a notch into the filament.

Maybe run it again and immediately pause when you hear the sound. If it actually pauses in a hurry then retract 150mm and look for an ugly notch in the unmelted section of filament.

I can't see the feedpath of the incoming filament but if there's no PTFE tubing then the filament can arrive at an odd angle to the actual teeth of the driving gear which is usually dead-center. The greater the deviation from center, the less bite those teeth have which then leads to more notching. (It might be good to rule out "other causes".)

11

Hi! Thanks for the response. I'm pretty sure that the driving gear is chewing into/skipping/slipping on the filament.There is PTFE tubing on both sides, and a fan there as well to cool it down, as I've already encountered problems with the PLA heating too much in the past.

Back then, I also made sure that the teeth were dead center by following this guide for the printer: http://support.lpfrg.com/support/solutions/articles/11000013896-creatr-hs-series-under-extrusion-explained.
I will check it again tomorrow, though. Still, I'm not sure how this would explain how it ONLY happens in Octoprint with a 100% consistency.

Or maybe I misunderstood?

12

Hi again! So I've checked the GCODE Scripts section, and there's nothing except for the normal "After print job is cancelled" script (everything else is empty).

I also ran the M900 K0 code in the terminal. I'm not sure what should happen, but at least I didn't recieve any errors? Here's a picture (also ran the code before/during printing):

linadv
linadv.png749×496 11.7 KB

I've also installed Octoprint on the laptop that I use S3Ds control panel from just to check if it had anything to do with the Raspberry pi, which it did not. Excactly the same thing happens when I run it from the laptop, and when I try again with S3D it runs normally again.

Also checked the driving gear again just to make sure, and it seems aligned.

13

Here are two bolts printed (same gcode) with Octopi and the S3D control panel. The one on the left was printed from Octopi.

20180711_105145
20180711_105145.jpg2560×1440 881 KB

I've also tried to downgrade to version 1.3.6 for the heck of it. I have no idea what can be wrong. I've been running Octopi with my home printer (Prusa mk2s) perfectly fine without any problems for almost a year. I'm pretty sure I haven't done anything differently.

14

I had a similar issue some time ago: During print, the x/y movement stopped but extrusion went on. That produces some nasty blobs.
The only cure was to make a complete new setup from scratch. (OctoPi -> SD card, and then the plugins...).
Now it's running fine again.

15

Hi, thanks for the response. I have experienced this before, although not when using Octoprint.

I feel like the fact that I already set up Octoprint again on my laptop, facing the excact same problem means that doing a new setup from scratch wouldn't work. However, I'll try it anyway.

1 Like
16

I installed a fresh new Octopi (on a different SD card even). Sadly it didn't work.

17

Two things to try:

  • Try printing from the printer's SD, but through OctoPrint (so, put the file on the SD, then select it in OctoPrint and start it from there instead of through the printer's controller)
  • Enable the serial.log, reproduce the issue, then upload the log here, maybe that contains some hints.
18

Hi! Thank you. I will try this tomorrow, once I have access to the printer again. The printer doesn't have an SD slot for prints, instead it's using a USB slot. Octopi currently doesn't automatically recognize this device. Could this be accomplished by a symlink in the USB stick?

19

Your printer's firmware would need to expose it as SD via a bunch of common gcode commands and it doesn't sound like it's doing that.

20

Is there anything I can do to make my printer do this? I'm not really sure how to approach this problem.