Jump to content
Ultimaker Community of 3D Printing Experts
Blizz

UM2+: Huge blob + grinding at end of print

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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?

 

Share this post


Link to post
Share on other sites

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...

 

5a93d8108f475_Bildschirmfoto2018-02-26um10_47_19.thumb.png.84f7833d895894a1ec6bf3876d89615c.png

Share this post


Link to post
Share on other sites

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:

 

  • Thanks 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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 by tinkergnome

Share this post


Link to post
Share on other sites
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...

 

5a93d8108f475_Bildschirmfoto2018-02-26um10_47_19.thumb.png.84f7833d895894a1ec6bf3876d89615c.png

 

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.

 

Share this post


Link to post
Share on other sites

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

 

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Our picks

    • Introducing Ultimaker Cura 3.6 | Beta
      Ultimaker Cura 3.6 | Beta is available. It comes with new features, bug fixes, and UX improvements. We would really like to have your feedback on it to make our stable release as good as it can be. As always, you can download the beta for free from our website, for Windows, MacOS, and Linux.
        • Like
      • 92 replies
    • Print Core CC | Red for Ruby
      Q: For some users, abrasive materials may be a new subject matter. Can you explain what it is that makes a material abrasive when you are not sure which print core to use?
      A: Materials which are hard in a solid piece (like metals, ceramics and carbon fibers) will generally also wear down the nozzle. In general one should assume...
        • Like
      • 30 replies
    • "Back To The Future" using Generative Design & Investment Casting
      Designing for light-weight parts is becoming more important, and I’m a firm believer in the need to produce lighter weight, less over-engineered parts for the future. This is for sustainability reasons because we need to be using less raw materials and, in things like transportation, it impacts the energy usage of the product during it’s service life.
        • Like
      • 12 replies
×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!