Interesting. I'll try!
Yep, same behaviour as the others (skipping).
Wow. So your printer doesn't like host software programmed in Python for some reason, maybe PySerial. That's... a new one.
I've tried to reach out to someone who might have an idea here, but not sure if that will bear fruits.
In the meantime you could ask Leapfrog themselves about this - maybe they have an idea. It certainly strikes me as very odd. You could also test if Repetier Host/Server shows the same behaviour - that would be another piece of host software that is (AFAIK) not Python based, so if does show issues as well, it would mean that it's not Python/Pyserial after all but possible some special stuff that your version of S3D does. Btw, is this a customized one included with your printer or the stock one?
Ok, so, I got a hint at what else to try.
Thing is, the serial connection inside your printer first goes to a built-in Olimex board and from there gets bridged to the motherboard. My buddy suggested to test if maybe the bridge is at fault here, by opening up the printer and directly connecting to the motherboard instead of via the Olimex board. Some stuff won't work this way (e.g. pre heating from the HS or anything else display related), but it would be a good test to see what's causing issues here. Here you can find a picture of motherboard and Olimex. You want to directly connect to the USB connector in the bottom right of the motherboard picture that says "Motherboard to OLIMEX Display Port".
Additionally my buddy said that there might be some special serial settings that are set in S3D that might be necessary for smooth operation. Can you maybe make a screen shot of the connection settings with which you are connecting from S3D and with which everything works? Maybe there's also a difference there from the "common printer settings" that could explain things.
I briefly tried setting it up with Repetier Server but encountered some problems with buffering (I think), because of some faulty settings. I'm leaving after today, so the time I can spend working on this is a bit limited. I will try this as soon as I get back (in about a month..).
Some settings:
Does this sound like the same issue?
I can not get the extruders work like they should!!! always intermittent under-extrusion.
Previewing that gcode in S3D and matching it up with your video the tool head is programmed to do an extremely fast extrusion (appears near instantaneous in the preview) where the skipping/ graunching sound occurs in the video. This is what I am seeing for the extruded paths and not the travel moves to be clear. It does appear that your printing at about 35-40mm/sec for all the other portions and travel moves greater than 130mm/sec. I don't know if this helps at all.
I have the same rpi case I printed some time ago saved on my octoprint. I downloaded this gcode and previewed that, I didnt see the same behaviour I did in your sample gcode.
@OutsourcedGuru I'm not seing anything about the skipping behavior, but possibly! I'll check it out.
@mungbean I've messed around with the printing speed settings to see if I could get a reasonable working profile to work with Octoprint. The skipping decreases at lower speeds (however still happens at 10mm/sec), and increases at higher. I haven't tried decreasing the travel speed for non-print movies, though. It does seem like it's doing some sort of retractions really fast.
I ran the same gcode on my home printer (prusa mk2s) using Octoprint just in case. No problems at all.
Re-read the last link I provided. Everyone seems to be suggesting that this is systemic with your printer and it's due to that interim Olimex board which foosel talked about.
I did see this. I will look into it when I'm back. Thank you
Hi All,
New member here. I just signed up because my Ender 3 is exhibiting this same issue only when printing in Octoprint.
Setup:
Printer: Creality Ender 3
-Uses Marlin v 1.0
Octopi version: 0.15.1 (stretch)
Octoprint version: 1.3.9
-Only Announcement and Core Wizard plugins enabled
Raspberry Pi 3 B
Cura 3.4.1
I've only had the printer for 5 days, but it has been running 24x7 in that time with no problems, until I setup octoprint and tried my first print. The loud extruder clicking becomes present, and it is absolutely modifying the extruder behavior. The feed becomes a very fast constant pull on the filament when printing at a speed of 60 mm. When it retracts, the retraction amount is at least double what it is from the SD card behavior, causing the clicking sound.
The print job also "burned" the print image into the stock bed, apparently melting the texture into a smooth area where the print was being laid. The filament was also very thin layered compared to the SD prints.
Finally, the height of the finished object was only half what it should have been.
Sorry if I'm hijacking, lmk and I can start a new thread on this issue. I can also provide more detail if needed.
TIA.
Hi there, I hope this will help someone I just solved it for me after 4 long fighting days.
First try to disable "combing" on your slicer.
Then replace the raspberry pi or even better install octo on you PC/Mac
For me these steps did the trick
Which Pi did you use before?
A RasPi 3 is quite sufficient for OctoPrint.
Pi 3B, pretty old though and had I may or may not damaged it while playing with GPIOs at the very beginning. connected to 3A power sup with heat sinks everywhere.
I have to say that from the very start it seems like the pi is printing worse then the SD but when I've installed BLTOUCH I had to let the SD go.
PI printed fine until it didn't.
Notice that my first suggesting it to disable "combing" (in CURA). this seems to made the bigger difference - even with octo on my mac when combing is set to "within infill" the prints are not perfect.
For me, I use "Not in skin"
Agree to that. In most cases I noticed that the culprits are either the slicer settings and/or the printer itself.
I have had exactly the same problems as described above and have also tried everywhere to correct the error.
I recently purchased a Bigtreetech touchscreen for mounting on my printer. In the box there was also a USB cable which was 3 times thicker than the one I used from my Raspberrry Pi for the printer.
I gave it a try and replaced it with my thin cable. To my great surprise, the result was a total cloning of the same print from an SD card. All the curves were neat and smooth without the strange knobs from lack of retraction.
Obviously, there must be a much better bandwidth in the thick cable, which undoubtedly affects the quality of a difficult print with a lot of information to send to the printer.
1 Like
It's not better bandwidth; it's the existence of metallic shielding inside the cable.
Back in the old days... you could faintly hear AM radio stations when you tried to talk on the telephone. The radio waves of the station were getting induced into the (unshielded) telephone lines and wires. In those days, they didn't understand how to limit interference. But today, we use twisted pairs of wires, metallic shielding and ferrite cores to do this. The type of amplifiers typical of a RAMPS board these days to drive stepper motors create very noisy/square waves signatures which are induced nicely onto any unshielded wires nearby.
It sounds very plausible, as I also broke the shield on my old cable and cutted the red wire to avoid the TFT screen to light up when the printer was off, because it got power through the cable from the Raspberry PI. On the new cable I found USB-A male plug pin isolator (back-power blocker) from thingiverse.com. This is an odd way to get data-only or power-only USB connections. It's a small "mat" that goes between the pins of the USB plug and the USB socket and disconnects some pins.
But it explains that it was noise from the broken shield that was the root cause for my Octoprint printing issues.
Thank you very much for the detailed explanation.
1 Like
I took the liberty of creating a direct link within your text to the project itself. It's a simple solution to a mousetrap which I've also attempted to build.
Alright, I just signed up as well for the exact same issue, using an Ender3 v2.
Octopi was running great until a couple of days ago. Since then every single print goes well for about 20 minutes, then this issue starts.
Next I'm going to try is reinstalling my octopi. If that doesn't do the trick, I'll install it on my unraid server and connect from there.
If you got any more tips, let me know!
ps: might be a while before I update this, but I will after vacation.