Oh, I have never touched the feed or flow rates in the control panel. Both are at the default 100%.
1 Like
A complete shot in the dark, but I notice that the S3D log doesn't show any line numbers or checksums on the sent lines, whereas OctoPrint uses those by default.
You can disable the use of those in the Settings, then save and reconnect to the printer:
I'm very doubtful that this is the actual reason for the weird behaviour, but better to rule it out.
edit
Another difference:
M107
M104 S215
T1
G28
G1 Z5 F5000
M900 K0
M109 S215 T1
That M900 K0 there is definitely not part of what OctoPrint sent over to the printer. So either this is a different file, or S3D injected this there.
G1 Z0.300 F7800.000
The first line of the actual print also differs, the version in the serial.log went to Z0.350. All following lines also differ which makes me think this is another model being printed. However, the M900 and the lack of line numbers is still significant.
I'm terribly sorry, I forgot that I attempted another gcode in between where I had added the M900 K0 line to somewhere in the beginning. The result was still the same, and the last print used that file. I will try to disable those settings now.
It didn't work, sadly. I tried again using the newest gcode (the same as the one sniffed). Here's the serial log serial(2).log (235.3 KB)
Then I'm sadly all out of ideas now. There's no difference between what OctoPrint sends vs what S3D sends from what I can see. I'd normally recommend to test different hardware, especially another power supply to rule out any wonky brown-out problems, but you already tested this on the same machine that runs S3D, so not even that is an option anymore.
I've never seen such behaviour and have absolutely no explanation for it other than gremlins living inside your printer.
Maybe I should have mentioned those gremlins.. I knew it was strange...
Anyhow, thank you for the response (and everyone else). I'll give up on using Octoprint for that printer (for now). This problem has been driving me mad for the last couple of days, and resulted in me consulting a forum for the first time as well. Oh well..
Hang on @eastspawn ... I was just giving foosel a chance to look at the serial logs and such.
I routinely have filament notching problems myself, especially lately. I've picked up a batch of Shaxon filament of every variety and in some cases:
- the diameter tolerances are not as good as some of the other filaments I've used and this leads to it getting stuck in the PTFE tubing. when it does, the driving gear in the bowden can't pull it and it starts to make noises and to grind into the filament there at the top
- I don't know this for sure, but I'm guessing that the Shaxon filament is softer somehow, leading to more grind-throughs like that
I've spent a fair amount of time re-engineering the feedpath. Lately, I've been running a gravity feed from directly above the printer and this seems to help. I've completely removed the PTFE tubing for a bit and it's removed the problems related to the filament getting stuck in there.
I do think that I should re-introduce a short stub of filament at the top of the bowden so that the filament is always directed straight into the gear.
The print speed seems to be a factor in all this as well. The amount of filament on the roll is also a factor; it takes more to rotate a full roll than a partially-full roll.
To troubleshoot, remove the PTFE tubing, start the job from OctoPrint, grab the filament above the bowden and push it in for the first layer. Apply plenty of pressure. If all this is due to a feedpath-related problem, your troubles will go away. If you're pushing the filament hard down into the bowden drive and it still acts up, then you can rule out feedpath.
1 Like
But shouldn't any kind of mechanical issues also manifest when printing from S3D? The fact that OP doesn't have any issues printing from S3D or a USB stick (what would be the SD card for other machines) but runs into these kind of issues when printing from OctoPrint makes it sound to me not like a mechanical but rather either a communication or an electrical issue.
1 Like
Just tried with Astroprint as well (on the laptop). Same problem. Switched back to S3D, and no skipping.
I'm not surprised, AstroPrint is a fork of (a by now ancient version of) OctoPrint after all.
Could you try Pronterface? That's also Python based. If this shows the same behaviour, maybe it's got something to do with PySerial which all of the three use but S3D surely doesn't.
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