UM2+: Huge blob + grinding at end of print

[Blizz 53]

Since a week or so (nothing changed except maybe newer cura version), my UM2+ finishes a print by starting to grind the filament at the end at higher speed whilst pushing out a huge blob of material on top of my print. Any ideas where I need to start looking to see what happens? I use Cura 3.2 to slice my models.

[jerooney 6]

Hello Blizz,

How unfortunate to hear your Ultimaker 2+ has this end of print issue. Could you maybe verify:
Do you use Cura 3.2 or Cura 3.2.1?
Have you seen this behavior before Cura 3.2?
Did you change/update the firmware of your Ultimaker 2+, right before this happened?

Would you be able to share a gcode, for us to investigate?

 

Regards,

 

Jeroen

[tinkergnome 927]

@jerooney i think the reason is this commit (read the comments):

 

https://github.com/Ultimaker/Ultimaker2Marlin/commit/aa89f34a056a5192923e06842e4919ceedc933fd

 

(the quickstop function is called at the end of an UltiGCode print)

[Bienenstocker 1]

I have the same issue with my Ultimaker 2 plus. The print job works terrific until the end when it the build plate does not lower and the extruder keeps on extruding with all might ruining the print. I have Cura 3.2.1 and the latest firmware on the printer which is an Ultimaker 2 upgraded to 2+. Hmmm. It didn't do that before the update to 3.2 Anybody know why or have a clue how to fix that?

 

All the best Kurt

[Bienenstocker 1]

I have the same issue with my Ultimaker 2 plus. The print job works terrific until the end when it the build plate does not lower and the extruder keeps on extruding with all might ruining the print. I have Cura 3.2.1 and the latest firmware on the printer which is an Ultimaker 2 upgraded to 2+. Hmmm. It didn't do that before the update to 3.2 Anybody know why or have a clue how to fix that?

 

All the best Kurt

 

I failed to mention that it didn't do it on all the prints.It did it on the files"Eierrutsche" and Birdfeeder. It didn't do it on the bulbadrain and Kingkoert.  

08PLAEierrutsche.gcode

08PLABulbaDrain.gcode

04PLAKingKoert.gcode

08plaD_birdfeeder_4_0_thingiverse.gcode

[Bienenstocker 1]

Tried again and it made the blob again. There seems to be problem related to the extruder stepper motor control. I still use the original stepper motor for the UM2 which seems to have half the extrusion rate. Until now I just used material flow 200 percent and everything was fine. Now when I change material it only forwards half the way. There rest has to be pushed forward by alternate means (push in the filament with the extruder disengage button pushed or wait) When the print finishes it tries to push half a Bowden length through the nozzle creating the blob. then it finishes like it should by lowering the z axis and parking the printhead. This is rendering the printer useless when unattended. I caught it this time and just pushed the disengage button on my sanjui in the back and only got a small blob. Maybe this helps in addressing the problem.

 

Thanks in advance for thinking the whole thing through and maybe finding a solution to the problem 

 

Kurt

 

[Blizz 53]

My UM2+ also still uses the extruder from my original UM2, if that is any help. Sounds like it might be the same issue.

 

[DidierKlein 729]

Hey guys did you see the answer @tinkergnome posted? It seems it can be related to the latest firmware. Also, i'm not sure but i have seen similar cases lately and it seemed to me that all the slicing was done on MAC with the 3.2 Cura is it the case for you guys?

[Bienenstocker 1]

Hey Didier! Thanks for getting back to us. It seems to have to do with the Mac Version of Cura 3.2.1 and not with the printer what is generally good. I sliced a print yesterday with my Win10 PC and everything worked fine. I just wanted to replicate it with another print on either to confirm my suspected cause. I read what tinkergnome posted however I couldn't really grasp what it meant :-S Kind of too much code for a non code guy like me. ;-) I will be back once I know more. @Blizz do you use a Mac also?

 

[Blizz 53]

Yes, Mac here as well. Haven't been able to check yet if I have 3.2.1 or 3.2 but I usually update to the last version right away when I get the notification.

 

[Bienenstocker 1]

I also have graphics issues with the MAC version on Cura with my 15´ MacBook Pro Retina which I couldn't explain myself. It misses round sections in the font.... None of my other machines does that, so I attributed it to the Retina display, but it wasn't my primary concern... Could find some old issues with the Retina display but nobody with that same problem...

 

[hugoboc 0]

Hello!

 

I am also having the same problem. I am also using Mac Os and Cura 3.2.1

 

Is there any solution available?

 

The attached gcode had this problem.

 

Thanks.

bujo5.gcode

[DidierKlein 729]

some users have resolved it by using cura 3.1 but some also say the latest firmware causes this, so i would suggest to try with 3.1 and if it doesnt work change the firmware

[ndimensional 7]

For my UM2+ - Firmware 2.6.2 and Cura 3.2.1 the following steps worked:

Configure Cura (Preferences - Configure Cura - Printers - Machine Settings - End Gcode) to add the following -4- lines of text:

 

;Comment to stop blob and grinding

;Comment to stop blob and grinding

;Comment to stop blob and grinding

;Comment to stop blob and grinding

 

See also discussions:

 

[gr5 2,173]

So this is looking more and more like a bug in the 2.6.2 firmware (note it may be there are two different 2.6.2 firmwares and the one with cura 3.2 has the bug and not in cura 3.0).  I suggest you install cura 2.5 and install the firmware from that onto your printer.  And let us know if that fixes it.  Also switching to reprap style gcode instead of ultigcode will fix it but that's not as good a solution.

[Bienenstocker 1]

Thanks for all the replies and solution suggestions. It appears to have to do with Cura for Mac. I downgraded to Cura 3.1 and all is fine. 3.2.1on my pc worked fine also... Thanks again. Hope they fix this issue with the next firmware update...

 

 

[gr5 2,173]

@ghostkeeper take note - it seems to be mac only and 3.2 only as you can see in above post.  I'm thinking some bad character (a tab, a missing carriage return) shows up from MAC but not PC version of cura.

[ghostkeeper 105]

On 26/02/2018 at 10:51 AM, Bienenstocker said:

I also have graphics issues with the MAC version on Cura with my 15´ MacBook Pro Retina which I couldn't explain myself. It misses round sections in the font.... None of my other machines does that, so I attributed it to the Retina display, but it wasn't my primary concern... Could find some old issues with the Retina display but nobody with that same problem...

Yeah, we've heard about this more often. Something is up with the way that fonts are rendered on some MacOS computers, but it doesn't seem to be related to specific MacOS versions. It's quite hard to reproduce and we haven't found a solution for it yet. We're switching to a different font face for 3.3 (Noto Sans instead of Open Sans) so maybe that is better, but we won't know until these people can try it out when the beta for 3.3 is ready.

 

On 26/02/2018 at 12:16 PM, DidierKlein said:

some users have resolved it by using cura 3.1 but some also say the latest firmware causes this, so i would suggest to try with 3.1 and if it doesnt work change the firmware

I'd like to refute this. The firmware delivered with Cura 3.1 is exactly the same as the firmware delivered with Cura 3.2. Byte-for-byte. But maybe the mere act of re-flashing the firmware might fix things since the NAND chip in the UM2 was sometimes a bit glitchy.

 

I'm now slicing a cube using 3.1.0 and 3.2.0 and seeing what the difference is in their g-codes. This is the result:

Quote

6,7c6,7
< ;Generated with Cura_SteamEngine 3.2.0
< M82 ;absolute extrusion mode
---
> ;Generated with Cura_SteamEngine 3.1.0
> M82 ; absolute extrusion mode
6283c6283
< M82 ;absolute extrusion mode
---
> M82 ; absolute extrusion mode
6284a6285,6290
> ;SETTING_3 {"global_quality": "[general]\\nversion = 2\\nname = empty\\ndefiniti
> ;SETTING_3 on = ultimaker2_plus\\n\\n[metadata]\\nquality_type = normal\\ntype =
> ;SETTING_3  quality_changes\\n\\n[values]\\n\\n", "extruder_quality": ["[general
> ;SETTING_3 ]\\nversion = 2\\nname = empty\\ndefinition = ultimaker2_plus\\n\\n[m
> ;SETTING_3 etadata]\\nquality_type = normal\\ntype = quality_changes\\nextruder
> ;SETTING_3 = fdmextruder\\n\\n[values]\\n\\n"]}

So to summarise: The Cura_SteamEngine version changed, the comment for M82 has a space less, and the settings at the end are missing.

That last bit together with @ndimensional's findings gets me thinking that maybe the UM2 firmware isn't flushing its g-code buffer at the end properly. There is a buffer of 8 (?) lines of g-code in Marlin's memory that allows the printer to read and parse the g-code in advance so that it's ready on time for when the printer needs to execute it. Maybe the g-code parser says that the file is done already, the print stops, and the last few lines that were in the buffer aren't executed any more. Just a hypothesis. This is the sort of thing that only @Daid still knows.

If this is the case, we could fix it by outputting some arbitrary comments at the end for UM2-family printers, though it would of course be better to fix it in UM2's firmware.

 

Perhaps you could try ndimensional 's fix. But just to be sure, instead of adding 4 lines, add 8.

[ghostkeeper 105]

I talked to Daid and he did some very impressive debugging and tracing from my description and found 2 bugs in the firmware that led to this together with a bug in Cura.

1. There's a bug in Cura 3.2 that it doesn't output the custom settings in the g-code any more. We knew about this one and it'll be fixed for 3.3.
2. In the firmware, it would check for the file being completely read and the g-code buffer being empty. If both are true it would call an abort function on the print that would stop the print and set the correct status flags and such. However, there are still moves in the motion planner, and it didn't check for those. So it would abort too early.
3. The abort function still completes the current move. It computes the necessary motion to complete the move, however there is a compensation factor to account for the filament volume vs. length and this wasn't applied in the abort function.

Daid fixed 2. and 3. and they're now investigating how to test this.

[ghostkeeper 105]

Workaround for now is to put at least 512 bytes at the end of the file (in comments). Because the firmware reads 512 bytes at a time from the file, so if you put that at the end of the file it'll think that the print hasn't finished yet...

[Daid 306]

There seems to be 3 bugs:

1. Cura didn't emit the profile string
2. UM2 firmware thinks the print is finished before it actually is
3. The UM2 "print finished" code calls the "abort print" code, aborting a few final moves, and then sets the current filament position incorrectly.

Combined they provide this behavior.

 

I think the fix for 2 and 3 are relatively easy:

diff --git a/Marlin/UltiLCD2_menu_print.cpp b/Marlin/UltiLCD2_menu_print.cpp
index e3cd69a..5755583 100644
--- a/Marlin/UltiLCD2_menu_print.cpp
+++ b/Marlin/UltiLCD2_menu_print.cpp
@@ -104,7 +104,7 @@ static void checkPrintFinished()
         lcd_menu_print_pause();
     }

-    if (!card.sdprinting && !is_command_queued())
+    if (!card.sdprinting && !is_command_queued() && !blocks_queued())
     {
         abortPrint();
         currentMenu = lcd_menu_print_ready;
diff --git a/Marlin/stepper.cpp b/Marlin/stepper.cpp
index ff6e388..ebfbeff 100644
--- a/Marlin/stepper.cpp
+++ b/Marlin/stepper.cpp
@@ -933,7 +933,7 @@ void quickStop()
   current_position[X_AXIS] = float(st_get_position(X_AXIS)) / axis_steps_per_unit[X_AXIS];
   current_position[Y_AXIS] = float(st_get_position(Y_AXIS)) / axis_steps_per_unit[Y_AXIS];
   current_position[Z_AXIS] = float(st_get_position(Z_AXIS)) / axis_steps_per_unit[Z_AXIS];
-  current_position[E_AXIS] = float(st_get_position(E_AXIS)) / axis_steps_per_unit[E_AXIS];
+  current_position[E_AXIS] = float(st_get_position(E_AXIS)) / axis_steps_per_unit[E_AXIS] / volume_to_filament_length[active_extruder];
   plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);
 }

But I haven't tested those.

 

Adding a comment block at the end, of an M400 in at the gcode will most likely work around the 2nd bug. And thus not triggering the 3th, unless you do an abort, that can also trigger the 3th bug.

[tinkergnome 927]

@Daid have a look at this pull request - i think it is also important:

https://github.com/Ultimaker/Ultimaker2Marlin/pull/134

 

The int() conversion for the second part of the term is missing - you'll get a warning about the wrong datatyp for "printf" during compiling.

I'm curious how the generated G92 command looks...?

 

BTW: fun fact that a few comment lines have hidden the bug until now, and only because of another bug...

Edited March 1, 2018 by tinkergnome

[leliep 28]

On 26.2.2018 at 10:51 AM, Bienenstocker said:

I also have graphics issues with the MAC version on Cura with my 15´ MacBook Pro Retina which I couldn't explain myself. It misses round sections in the font.... None of my other machines does that, so I attributed it to the Retina display, but it wasn't my primary concern... Could find some old issues with the Retina display but nobody with that same problem...

 

 

Same annoying graphics problem for me: MacOS and Cura 3.2 as well as Cura 3.2.1

The problem did show up in an earlier (pre 3.1) version of Cura, but does not happen with Cura 3.1.

 

[ahoeben 1,949]

This issue at github has an (unofficial) build that fixes the font issue:

https://github.com/Ultimaker/Cura/issues/3277

[Pieter Kapteijn 0]

I am getting very disappointed by the UM2+ performance after the Cura Upgrade.

While it was working well with the last version (3.1) + firmware on my MAC, since the 'upgrade' the system has been misbehaving badly.

Apart from the pimple at completion, I can now only get fairly decent prints with a feedrates of 200-250%(!).

Have tried almost everything: factory reset, new PLA, new nozzle etc. It just isn't the nice (but expensive) machine I bought and used over the past 2 months.

I won't buy this machine ever again if this does not get fixed.......

 

Pieter Kapteijn