I'd be very surprised if that was something you could change, but I'm also not familiar with that printer so no idea really.
I see. I'll just stick to uploading the log tomorrow, then.
I printed it with Octoprint again. Exactly the same thing as usual. Here is the log: serial.log (305.8 KB)
Video of the print: Google drive (video)
Sounds like a stepper motor. Have you been able to locate the source of the noise?
The X,Y or Extruder motor (for Tool T0 or T1). I do not assume that it is the Z motor.
I'm pretty sure it's the extruder for T1, which is located at the back. It's only happening when I'm printing from Octoprint, though (there are two videos comparing at the beginning of my post).
Huh, I'm stumped by this. The serial.log looks completely unsuspicious, the commands are sensible, no weird communication issues or anything in there.
I have absolutely no explanation how sending your file through OctoPrint could be causing this kind of behaviour. The only idea I have left is somehow trying to get something similar to a serial.log out of S3D when printing through that without the issues and comparing the two, but other than that I have absolutely no idea how to proceed here.
OctoPrint doesn't modify active GCODE in any way, apart from stripping away comments which the firmware wouldn't evaluate anyhow - unless you tell it to that is. It simply sends the file over to the printer, line by line, as it reads it from disk. From what I see in your serial.log, there's nothing unusual about it. X, Y, Z and E are all set to absolute coordinates in mm, E is reset to 0 a bunch of times, but that's all normal.
Does this also happen when printing with T0?
Aw, I see. I'll look into obtaining something similar to serial.log for S3D (would some sort of usb serial port sniffing or logging work?). The T0 is currently not calibrated, but I'll try to run it and just listen for the sound. Thank you anyway for the response.
Hopefully. Maybe S3D also has some setting to create a log. To be honest, while I have a license for that slicer myself, I've never to this day even looked into printing through it.
@eastspawn: BTW, have you adjusted the flowrate in the OctoPrint control panel?
It occurs to me that the stepper skipping only takes place when the head is moving slow and/or tiny amounts.
I'm not sure how helpful this is... but here's the usb serial port activity while printing with S3D dropbox (html file)
Here's a video
@Ewald_Ikemann I will look into this after some food!
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.