False "jam detected" at the start of a print, all fine afterwards

[skohls]

This is a curious one...

Currently using the 2.1.6 software build 280 in the MMU2 and the 2.1.6 BN2378 with my speedy-unload-fix in the MK3.

Each and every print starts with a jam detected - and runs fine afterwards.

https://youtu.be/hRVLdsb20xg

Log from Octoprint serial.log

example GCODE from Slic3r 1.41.2+

MK3 PETG_Rotation Visualizer.gcode.zip

The example above is from a single-color print, I have the same when using multi-color prints tho. Testprint yesterday hat 44 tool changes w/o problems apart from the "fake jam" at the beginning...

The filament-sensor is fine and free from debris.

[TheZeroBeast]

Hey @skohls can you please try with Slic3r 1.42.0-Alpha3 as this is the only slicer supported with 2.1.6-8(RC1-2)?

[skohls]

Same problem with the Alpha 3 slicer - as expected since the gcode up to the actual printing of the object is pretty much identical. The fake jam is even before the filament is loaded.

MK3 PETG_Rotation Visualizer alpha.gcode.zip serial.log

[TheZeroBeast]

Thank you for the fast response. Very interesting indeed, definitely false positives for some reason, any changes to your extruder? BMG?

I'll see if I can find a way to enable once initial purge is done.....

[skohls]

Well, just like in the other issue (#92), this is with the Bondtech Kit for the MK3 - I only have one printer ;)

[TheZeroDay]

I hate to jump on this issue and sorry for intrusion. I have the same problem but multiable times in one print. After printing is stopped and the filament is pulled and the printer beeps, i cut the filament tip then pull it back and resume. The printer will purge on the edge as a normal filament change just fine. However when it tries to continue in the pruge tower it will detect a new jam and so on for 20 or even more. Sometimes it will continue fine but after some filament changes it will go through is problem again. I suspect that the filament sensor is to blame and cleaning it did not do the trick. I ordered the small bearing to make mechanical filament sensor which is mentioned in your prusa fourms thread. But is it really related? I want to thank you for your effort. Without your firmware i only completed one print without missed layers, for me it is a big improvment even if i have to do 20 filament changes due to fake jams. It felt half backed and not prusa like.

[TheZeroBeast]

I hate to jump on this issue and sorry for intrusion. I have the same problem but multiable times in one print. After printing is stopped and the filament is pulled and the printer beeps, i cut the filament tip then pull it back and resume. The printer will purge on the edge as a normal filament change just fine. However when it tries to continue in the pruge tower it will detect a new jam and so on for 20 or even more. Sometimes it will continue fine but after some filament changes it will go through is problem again. I suspect that the filament sensor is to blame and cleaning it did not do the trick. I ordered the small bearing to make mechanical filament sensor which is mentioned in your prusa fourms thread. But is it really related? I want to thank you for your effort. Without your firmware i only completed one print without missed layers, for me it is a big improvment even if i have to do 20 filament changes due to fake jams. It felt half backed and not prusa like.

Hey @TheZeroDay can you provide gcode for the print you're referencing so I can investigate?

[Mjankor]

Ahhh cool. I'm getting this as well on a fairly stock Mk3. I was thinking I'd have to replace my filament sensor cable but looks like it's software. I've taken to disabling the sensor to start a print, and turning it on once the print has begun.

[TheZeroBeast]

The solution will be the put M220 at the start then end of "printer start gcode" in Slic3r, "M220 B", "M220 R" respectively. Please test and advise.

[Mjankor]

Just had two false detections during the first layer. :(

[TheZeroBeast]

@Mjankor you will need to check your hardware then. No sensor movement, picking up filament colour well and clean and clear sight to filament. Any slipping at the bondtech will eventually trigger a Jam.

[Mjankor]

I'm using a proxy sensor and it's been 100% robust. It found a genuine jam this morning, but then dropped into this false jam sequence. I thought it may be hardware - cable trouble - but everytime I pop the filament and check the sensor, it reads perfectly.

I suspect it's the same underlying cause as the false jams at the start.

Note: I'm not yet on the latest version. I'm one behind (9 days old?). I'll install the latest this afternoon.

[skohls]

Unfortunately still the same with M220B and M220R in place. Jam detected before the filament even loads.

serial.log MK3 PETG_Rotation Visualizer alpha3 m220.gcode.zip

[TheZeroBeast]

@skohls nice work, thank you. Looks like it's only blocking tripping but still incrementing the error counter. Can you try the same gcode with the bellow MK3 changed?

MK3-2.1.8-RC2-TZB77-BN2386.hex.zip

[skohls]

Sorry to report this but it still shows the fake jam with the new build...

serial.log

[TheZeroBeast]

The only possible reason is the Prusa code doesn't compensate their fsensor block code for different extruder e-steps.

I'll do a test build with it compensated for, what steps are you running? 280*6?

[skohls]

I've set it to 1660 according to Bondtech's manual.

[TheZeroDay]

For me i have thought that by the newest Slic3r version meant on the website but after installing the version from github and trying it out currently i have no problems so far. It looks with the filament proxy which i assambled and calibrated stable. Thanks again for your firmware and i will keep testing and letting you know if there is any problem

[skohls]

@TheZeroDay what kind of filament proxy are you using if I may ask?

[TheZeroBeast]

@skohls & @TheZeroDay what do you guys mean by filament proxy?

[skohls]

@skohls & @TheZeroDay what do you guys mean by filament proxy?

I presume he is using one of the indirect filament sensor mods. They mostly use a ball-bearing to indicate if filament is loaded. The sensor is actually made for steel and can detect the bearing very well - this way you can use any filament, even transparent ones, w/o detection problems.

[TheZeroBeast]

@skohls thank you, that's what I was thinking. The problem with those mods are if the bearing slips on the filament, this needs to be prevented so jams aren't wrongly detected.

printed tpu sleeve maybe.

[TheZeroDay]

This is the one i used which actually works very well. The small bearing i bought from ebay took two days to arrive costs 1.2€ and this is virtually is all i needed.

www.thingiverse.com/thing:3129921

[skohls]

Ah yes - I thought about that one but it extends so far to the back. I see problems with high prints and the MMU holders. Was thinking about https://www.thingiverse.com/thing:3091625 instead. Same basic idea but no extension to the rear of the extruder as far as I can see.

[TheZeroDay]

Or instead of tpu sleeve i hardend the outer surface with sandpaper as the creater of the thing suggested. In combination with the ptfe cutted tube the is no slip and the dust from the filament is not a problem anymore

[TheZeroDay]

The one you have mentioned uses the same bearing as well. I could just as easy print the new one ;) thanks for the info

[Mjankor]

I had a false jam on start of my last print, immediately after installing that latest firmware (2386). However, I'm not going to register that as a bug until it does it again. I'm using this sensor, with a stock Mk3 motor, and stock e-steps. https://www.thingiverse.com/thing:3223513 Latest firmware, and slic3r 1.41.2 I'm curious about the requirement to use the alpha slic3r. What does it change?

[TheZeroBeast]

@Mjankor the alpha using M220 B and M220 R which I use to disable jam detection during any loading/unloading. Slic3d with 1.41.2 and Jam detection is always on and you're most likely going to have a bunch of jams during loads that wreck your purge block.

[Mjankor]

Ah, righto. Yeah, my jams were occurring during start Gcode, and during single material prints. Each time I got it to "jam" consistently, I'd clear the extruder and check the filament sensor, and it would respond properly. Anyway, at the moment I have no bug to report. I'll wait till I do some more testing. I need something repeatable to show up. :D

[skohls]

So, by chance I used some other profile for single material PETG prints yesterday. I toyed around a bit (enabling all extruders to get to more settings) and it doesn't jam at all. Funny enough it has some custom unloading sequence as well - eliminating all those problems for single material prints at least. I think this has been derived from Chris's Pretty PLA MMU profile... Now we have something to compare with the jamming gcode at least.

MK3 PETG_Rotation Visualizer v2.gcode.zip serial.log.zip

[gizzburn]

I have just updated to the latest version, every now and then it stops printing and retracts the filament back then moves the carriage to another slot, but it then extrudes about six inches of filament out of the MMU2 to the side of the selector, I have to cut the 6" off and then press the led control button, it then preheats the nozzle, then purges and then carry's on printing till it does it again. 2.5 hour print and its done 6 times up to 30% in to the print.

Using the new Slicr3 Alpha 3 to slice the model and print.

[TheZeroBeast]

@gizzburn, totally not an issue, more likely doing it's job, detecting jams.

Where the tips any larger than 1.8mm dia?

[gizzburn]

No the tips seem fine, but before the update it did not do this, is it a faulty sensor, I even tried it with the sensor off and it still did it.

[gizzburn]

Hi I just realized that its only the white filament that's doing it, so that points to the sensor does it not?..

[TheZeroBeast]

Hi @gizzburn yes, sure does. Your extruder can be changed to combat the colour sensitivity, there are a number of indirect modifications.

[gizzburn]

I have the new BMG bondtech extruder to go on my Mk3, but I am just waiting to see if it all works with your new firmware before I do the mod, as I dont want to change to many things at once and end up going down the wrong route to rectify the problem. I have a new spare sensor so will replace it when I update the extruder.

Great work on your firmware Robert. Does your firmware work with the new geared BMG extruder setup and what to change if anything.

Also I changed my bowden tube for the pass through top and removed the short ptfe tube from the top of the extruder, so my ptfe tube from my MMU2 to my extruder is one piece now, do I need to change the length setting somewhere to reflect this?. I have done the calibration on the tube with it disconnected and thats fine.

[TheZeroBeast]

@gizzburn I don't see any reason why it wouldn't, just need to make a couple small changes to step amounts.

yes, length settings might need to be changed via cal to still get to fsensor but if it still does just see how you go👍

I am also closing this issue as in official 2.1.8-RC2 I have changed Jam Detection to only be enabled when you add M219 E to filament start gcode Nice when you have a white/flex that you don't want Jam Detect running on.

This was done after I found that the gcodes in Slic3rPE-Alpha (M220 B/M220 R) builds don't always get added to the output, especially multilateral.

BONUS No longer do you need to Slic3 with an Alpha!!! Just make sure you add the M219 E