[Bug] Random "unload filament" during print

[skywodd]

Hi,

After upgrading to v01-1.2.5, I've experimented a very strange bug with my Sigma R16.

Sometime, during a print, the "unload filament" procedure seem to start for no reason.
The extruder stop and the filament run backward into the spool forever.
When this happen, I can only press "stop" on the screen to unfreeze the firmware.

I'm using BCN3D-Cura 0.15-beta2, with the fans and silent steppers upgrades installed.

PS Here the gcode file of failed print, if this can be useful : Master_Body_REV2.txt
The print failed at 9 minutes left ... grrrrrrr!

[AlejandroGarcia92]

I will take a look your gcode file. I can say you that once we experimented a similar issue and we realized that cura was generating corrupt gcodes , I don't know why, but after the PC was restarted this issue doesn't happen anymore.

On my first look, the gcode looks fine. I will test it.

[skywodd]

Something fishy with the 1.2.5 release (or my R16 motherboard is going crazy).
Only 18 hours of printing after the upgrade and I already see three majors misbehavior...

Here what I did today:

• Restarted my computer and printer to get a fresh cold start
• Plugged the printer to my computer through an USB hub (direct USB connection doesn't work with my computer)
• Re-downloaded the 1.2.5 firmware archive from github
• Opened Cura, started the "install custom firmware" utility with the 1.2.5 hex file
• Got a timeout error, USB cable was faulty (lucky day ...)
• Restarted the firmware upload utility, got success
• Opened a serial terminal, cleaned eeprom with M502
• Unplugged the USB cable and restarted the "Setup wizard" from the printer menu
• Got all the calibration steps done
• Auto-tuned the hot-ends (after the 1.2.5 upgrade, with the default PID settings, my hot-ends undershot like crazy, with 200°C set: get up to 185°C, stop, go down to 180°C, then finally got up to 200°C)
• Sliced another model I needed quickly with Cura (spoiler: didn't end well)
• Started the print from sdcard

The part printed without problem to the last layer.
I was really happy to hear the final homing sound.
Then suddenly ... the print head came back right into the print area and crashed into the printed part.
I was in front of the printer, so I quickly cut the power and restarted the printer to avoid breaking the glass bed.

Some screaming and insults followed during the painful (and stressful) process of removing the printed part stuck between the hotend and the bed without breaking anything.

Here the newly failed gcode file (not the same model as the previous one) :
Slave_Body_REV2.txt

I've checked the end of the file for any obvious slicer-related problems but found nothing.

Side note: I've upgraded the bootloader of the motherboard at the instructions of the support (ticket 1717) because after the steppers upgrade, I've got the "random motors moves" at boot problem. Eeprom got erased during the process, may this be the source of the problem ?

[skywodd]

Cold restart. New print. Got another glitch.
The print just before (a 20mm calibration cube) was good.
It's driving me crazy.

The file: Slave_Body_REV3.txt

The first layer:
(I've got lucky this time, the glitch strike one the very first layer)

It's definitely sound like a interpreting/planning algorithm going wrong somehow.
I've check the gcode in S3D preview, the glitch does not seem to be in the file.

[skywodd]

I'm going down the rabbit hole, but I don't see any logic in this misbehavior.
I'm starting to think something is wrong with the new stepper drivers upgrade and/or my motherboard.

Same file as my previous post, on the same SD card.
Cold start, no operation after boot expect starting the print : no glitch on the first layer.

Well ... let's try again.
Cold start, start print, no glitch on the first layer.

I've let the print continue to see if things will go wrong and at the middle of the print the printer just stop.
Motors were still energized but not moving. Screen was responsive (can stop the print normally from the menu).
When stopping the print from the menu, the motors did home normally and stop.

I think I will downgrade to 1.2.4 just to be sure this is related to the 1.2.5 release, not to the stepper drivers upgrade itself.

PS I've found a minor bug in the new bootloader code. I've sent a PR for this in BCN3D-Utilities repo.

[skywodd]

I've downgraded to 1.2.4 (previously working fine with the old steppers drivers) and redo the whole "setup wizard" calibration to get a clean start.

Using the same file as previously, I got a glitch again. This time during the perimeters of the first layer:

So ...
It's look like the bug is somehow related to the stepper drivers upgrade and/or the bootloader upgrade.

It's a really strange bug.
It look like something (Marlin or maybe the stepper drivers themselves) glitch and do a spurious XY movement before going to the next position.
In the picture above, you can clearly see the head going into the start of the arc, then go crazy, then return the to end of the arc and continue.

[AlejandroGarcia92]

I answered you on the bootloader pull-request subject.

I think that the issues that you are reporting won't be fixed by downgrade to 1.2.4 or later FW versions.

Issue per issue:

1. Stepper divers: I can help you with this problem, I hope that Support will help you on it.

2. Gcode: Friday, I told you that we had a problem once with Cura on one PC(windows) and the problem disappears by restarting. In my issue we saw that the gcode was incomplete.
   So, you attached before some gcodes but with .txt extension. Can you upload them on a ZIP? I can convert your .txt gcodes to .gcode but I will be sure. Meanwhile, I will be testing Master_Body_REV2.txt.

@skywodd Sorry for that.

[skywodd]

1. No worry, I will mail the support.
2. Github was not accepting the .gcode files, that's why I renamed them .txt.

Here a zip with all previously failed files, made directly from the SD card used to print them :
BCN3D.zip

[AlejandroGarcia92]

@skywodd thank you. I will report you my results.

[svengl]

It seems that this bug is still active. I run 1.2.7 Firmware on a Sigma R17 and Cura 1.1.0. After around 45mm print height the printer suddenly retracted the filament and kept printing empty.
Very annoying. I have the gcode file, but I cannot publish it. Is there something I can look for?

thanks

[AlejandroGarcia92]

@svengl Can you use zip to share me the gcode?

[svengl]

I hope you received the file. I sent it by mail. Today we printed the same part but two times on the build plate and the print again failed at around 113mm height. Again the same, the filament was suddenly retracted.

[AlejandroGarcia92]

Received

[AlejandroGarcia92]

The filament is over and the model was almost done. I did not see any strange behaviour. Also I took a look at the gcode and it's fine for me. Did this issue happens frequently during others print jobs?

Any way, I will print again the model just in case.

[svengl]

ok strange we printed it again with two of those on the plate (other gcode file) and it happened again. but at a higher level. I even have a video of it. Do you want those? Alejandro Garcia Moreno <notifications@github.com> schrieb am Do. 15. Feb. 2018 um 09:32:

…

[image: 20180215_092124_preview] <https://user-images.githubusercontent.com/17469944/36246860-fc9d69f6-1231-11e8-8f80-8b3bf776b508.jpeg> The filament is over and the model was almost done. I did not see any strange behaviour. Also I took a look at the gcode and it's fine for me. Did this issue happens frequently during others print jobs? Any way, I will print again the model just in case. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#155 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AVNU92ETO4_taEEZwBcdl6oOXUaf5pCJks5tU-uZgaJpZM4PnaBI> .

[AlejandroGarcia92]

@svengl Can you share the video?

[svengl]

It happened again today. It suddenly retracted during the print. This time with Cura 2.0.1... But as it seemed the gcode was fine the last time and it was fine here again. I understand that this is hard to fix...

[svengl]

I reinstalled the firmware 1.2.7 to the printer and printed again wth the same gcode and it is still printing fine. So this sudden retraction is really hard to reproduce. I will keep you updated when it occurs again.

[svengl]

An interesting observation to this issue:
I posted the issue https://github.com/BCN3D/Cura/issues/104 with the crashing head at the end of the print. When we came to the printer, we saw that it also has retracted the filament! So maybe a crash or some peak current or whatever might trigger this retraction (however that might be possible) and this also occurred during the print in the first try.

[svengl]

Another sudden retraction yesterday. Any ideas?

[skywodd]

@svengl For me, the "bug" was resolved by replacing the SD card reader of the printer (big thank to the support team by the way).
I also changed my SD card and USB SD card reader, just in case.

No more random things after that.
The bug may be hardware related or a mix of hardware + software mishandling.

[svengl]

Ah Ok. The support had written me that also. I then talked to our vendor and sent him this info. He however also couldn't see that the card reader is an issue. But if this really helped you, then we will try that for sure.
Did you also experience sudden axis shifts? Because I see that also beside the sudden retraction.

Thank you for the comment!

Sven

[skywodd]

Yes, axis moves and filament retract.
One time, it even get really close to a complete disaster (Z going up on the head with partially printed stuff on bed).

Disclaimer: I've a R16 with upgrades. I don't known if the R17 hardware was revised to fix the following problem(s) after reporting it to the support team. I hope it's fixed, but it may not.

I've tested and concluded that my R16 was not tolerant to radio interference because of the lack of RF shielding on the cables (motors, screen and especially the SD card reader).
In addition to some missing pullup resistors on the motherboard (a big design flaw), it was a nightmare for me.

Any pickup RF will move the motors on my printer when the outputs are in high-impedance (like during programming or just after powering up for example).
A bootloader fix (from me by the way) partially fixed the problem but without proper hardware pullup resistors, software can't do miracle.

Maybe a strong RF interference can also mess up with the (really) fast signals of the SD card reader and make the motherboard go crazy.
The new BCN3D SD card reader seem to be way more reliable than the cheap blue one.
It's worth a try I think.

PS I hope the technical report I've sent to the support team a year ago reached the R&D team and didn't get lost (or worst, ignored) ...

[svengl]

As reported in issue #193 our printer received new stepper driver with a correctly adjusted voltage.
We will observe if the sudden retraction will reappear or if it was somehow an interference from the corrupt stepper driver.