when I print a gcode file via Octprint I see print artifacts not seen printing the same fil directly from the printer's SD card.
Specifically, on a flat surface, including the base first layer, I'll see 4 or 5 good runs of filament, followed by 1 or 2 lines of very thin filament, which creates a gap leading to poor finish and weakness. See a picture here.
This is completely absent when I print the same gcode file direct from the printer's SD card.
I changed the print bed surface (magnetic pad then blue tape), the nozzle, the filament (1.75mm PLA) and the slicer (Cura and Rep[etiere) before trying this direct-print workaround.
Although I have a workaround, I like the convenience of WiFi access to the printer so I'd like to fix this if possible,
Has anyone see this?
I am on an Ender 3 running TH3D Marlin 1.2.11 & I have Octoprint 1.3.11. I have not changed any configuration settings. I don't see anything odd in the log, which I would include except I get a warning about not being able to inseert more than 2 links as a new user.
The photo tells me more than anything (thanks). The Control tab of OctoPrint has two sliders which allow you to adjust the speed and extrusion. What you've shown in the photo could be under- or over-extrusion. Likewise, the Temperature tab allows you to tweak the temperature of the hotend. Note the temperature on the filament manufacturer's box; it's usually a ridiculous wide range and it's your job to figure out what it should be for your printer and for this part.
The slicer plays a big role in this, too.
All that said, some layers look great and then if suddenly the next layer is under-extruded then this could be the gear that grabs/advances the filament (slipping), it could be the filament is getting stuck in the PTFE tubing, it could be that the filament on the spool is cross-threaded or otherwise stuck to itself, it could be that the spool isn't higher than the printer itself and is being forced to lift the filament all the way...
I've seen problems like this caused by a warped bed. I've seen problems like this caused by having the wrong z-offset stored in the EEPROM. I've seen problems like this caused by a z-sensor seeing too much reflection from the wrong-colored bed tape and getting confused.
Note that TH3D bundles OctoPrint, charges money to customers and then most of them end up here for support.
If you're using the TH3D firmware because you're using one of their products (sensor) then you'd need to tell us.
If it were me, I'd print this multiple times. If it's always layer 3 on this part then it's probably the slicer's configuration. If it's hit-or-miss on which layer is acting up, then it's probably filament delivery. Watch the print job while it's acting up, especially watching the filament path and whether or not the filament is advancing past the gear or just notching there. Also note the gap distance from the part that it's printing on top of. If the nozzle is now jammed into the plastic with barely any gap then this would misbehave.
Guru thanks for making time to send me your reply.
The centrally-relevant fact is that printing from the printer's SD card works flawlessly yet printing identical gcodevia Octoprint shows this problem. It's solid. Every time from Octoprint - this proiblme. Every time form SD card - not this proiblem.
So this eleiminates a sticky Bowden tube and a jumping extruder drive, warped bed, wrong Z offset, spool cross-threading, EEPROM settings and every other hardware factror.
And as I also mentioned, thi sproblem is not slicer-dependent. It does it when I slive in Cura and Repetiere.
I have not used the Octoprint sliders to change anything, so the naked gcode is in charge here.
I am using TH3D with no additional hardware only because it gives me the thermal protection code which improves safety.
I've watched the print job in action with my fingers on the filament, checking for correct feed, and with a bright lamp watch ing the print nozzle in action. There's nothing off that I can see.
As I understand it, Octoprint just reads the gcode from its DC card and sends it via the USB to the printer for execution. But maybe it does some reset coding between each command or something subtle which I cannot see which causes this problem. Maybe an interaction with the heater controls is causing the block to cool down periodically, causing the under-extrusion.
Anyone know if I can log all of the gcode gong through the SUB port?
Anyway, thanks again, Guru, for trying to help me.
Well, in Safe Mode, it does. There's little to prevent other plugins from grooming the gcode stream sent to the printer... slowing down the sending of gcode to the printer... And yet, OctoPrint probably generates both line numbers and checksums.
Before:
G28 X Y
After:
N4 G28 X Y *38
Look at the contents of your current serial.log. It tells you how to enable the serial log for debugging purposes. This would contain everything going through your USB cable.
You could somehow do that only in a case you are using Klipper - it runs controller on raspberry with Octoprint together and only sends basic commands to 8 bit/ARM host
Thank you. I've made general maintenance of the printer and find out that PTFE tubing was dirty and there was small leakage between nozzle and heatbreak. New nozzle, new PTFE tube, whole hotend reassembled and now all is ok
