tinkergnome

ok, mal angenommen es geht um einen Ultimaker2(+) der mit Cura verwendet wird - und es wurde kürzlich ein Update auf Cura 3.2 installiert... ...dann findest Du hier eine Erklärung (mit Link zum originalen Thema): https://community.ultimaker.com/topic/21564-ultimaker-setzt-am-ende-einen-batzen-filament-drauf/?do=findComment&comment=202604 Einfachste Lösung bis der Fehler behoben ist: die ältere Version Cura 3.1 verwenden, oder die Firmware von Cura 2.5 (oder älter) wieder installieren.

How do you compile it? Here is a great description from @gr5 - in case you missed it. The "ArduinoAddons" folder is not needed for the Ultimaker firmware, i think it is a relict from the originally Marlin. Which directions? Where does those come from? That sounds odd... whatever you have done - i would revert this step. AFAIK "sanguino" is a hardware variant that has nothing to do with the Ultimaker mainboard. "SdFile" inherits from "Print" ("Print.h"), which resides in a subfolder of the Arduino compiler installation (.../hardware/arduino/avr/cores/arduino) BTW: which compiler version do you use? I use 1.8.1 at the moment, this works like it is described in the link from above.

I found out that most of the settings can have a "minimum_value_warning" and a "maximum_value_warning". Here is an example: https://github.com/Ultimaker/Cura/blob/master/resources/definitions/fdmprinter.def.json#L652

Well... you said you made a fresh install of Cura on a new hard drive and this subfolder appeared by magic - through no fault of one's own...? Whatever: i doubt that Cura has interactive import or export functions for these kind of files. I have no clue, where these files come from or how Cura assigns settings from there, sorry.

Ok, with other words - one can use the layer view as a tool to measure the model... I had never thought to use it this way... thank's for the explanation - i accept this as a valid use case

Sorry, i have an exact opposite opinion... Why the "layer number"? If i have a need to pause a print at a certain point - i always know the exact z-position. Who cares about what layer this is? Why should someone want to calculate a layer number every time? The layer number will change every time i modify the layer height, but the z-coordinate is always the same - that's much more convenient, reliable and save. If i don't know the z coordinate (for whatever reason) - it would be nice, if the layer view would display the z-position, ok, but that's it. Perhaps i understand something completely wrong - i just don't see a use case where i need a layer number as a pause "position"...? (all above is IMHO of course). @cajodo One weird thing is, that the post processing script subtracts the first layer height to calculate the current height in the gcode. There's a comment: # use offset to calculate the current height: <current_height> = <current_z> - <layer_0_z> If i were you - that's a question i would ask the developers on Github at the next opportunity.

I may be wrong, but AFAIK CuraEngine always generates (at least) one pass per shell. It doesn't matter, how thick the wall is designed in your model, it will ever have two shells (an inner and an outer face). That's not a bug, it's just the way the CuraEngine works. The only way to get a single pass for the outer wall is a completely solid model that you slice with "Wall line count"=1 (or "Spiralize") and with zero top and bottom layers and zero infill. That should be easy for simple geometries like shown here. Of course that's no solution for your "single pass" requirement if your models are getting more complex. In this case you can try different slicers (or re-write the CuraEngine... )

Nope - i'm lost... @CCA1 you wrote "Resources" - that's in the Cura program folder on your harddrive, right? Wait... doesn't matter: there are no predefined .cfg files in the Mark2 definition files. If one creates a custom profile in Cura, it will get this extension, but those are not stored in the program folder, but in the config folder of the current user. And the config folder has no subfolder "Resources"...? I must admit, that I've only experiences with the Windows version of Cura, it seems to me that you're talking about something completely different.... How about one or another screenshot? That could be helpful....

probably this one: [info] automatic_update_check = False

Are you sure that this printer has the origin of its coordinate system in the center? That would be very unusual for this kind of printer... What happens if you uncheck "Origin at center" in the machine settings?

Daid has found the explanation: https://community.ultimaker.com/topic/21651-um2-huge-blob-grinding-at-end-of-print/?do=findComment&comment=202239

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

@bradley the firmware should always wait for the target temperature of the particular extruder. You don't need to change the start script or the gcode. The question is: what is the target temperature? It should be displayed in the upper line, if you scroll to the temperature on the display at the printer (just to be sure). My suspicion: take sure that you use the correct definition files for Cura. There was a change in Cura 3.2, by default it initializes the target temperature of the inactive nozzle with the standby temperature now. There are new definition files for 3.2 (and upwards) in the folder "cura-3.2-resources" - take sure that you use these for Cura 3.2.

If you use an UM2+ with Cura, the retraction settings are configured on the printer. I would check the retraction speed and length. In newer firmware versions you find it here: MATERIAL -> SETTINGS -> Customize -> Retraction For 0.4 mm nozzle and PLA the defaults are 6.5 mm retraction length and 25 mm/s speed.

Those things are depending on the selected printer, resp. the GCode flavor (this can be changed in the machine settings). For an UM2(+): temperatures and start procedure are handled by the firmware. That's why these settings are hidden by default in Cura. For all other printers it should be possible to change these settings at will. About which printer are we talking and which specific settings do you miss? Edit: i read it again... are you talking about manual controls?

Have a look at this thread, and please report back, if it makes a difference

AFAIK your custom-made scripts should reside in your local configuration folder, subfolder "scripts". Or more specific: $USER/.local/share/cura/<Cura version>/scripts If your script does not appear in the list, there are perhaps some hints in the log file: $USER/.local/share/cura/<Cura version>/cura.log

Für UltiGCode wird die E-Koordinate als Volumen (in mm³) generiert, die Firmware rechnet das je nach konfiguriertem Materialdurchmesser um. Für die "quickstop"-Funktion (M401) wurde kürzlich hinzugefügt, das die aktuelle Position nach dem Quickstop neu berechnet wird Leider wurde dabei der Umrechnungsfaktor für die E-Achse vergessen M401 wird nach Druckende (nur bei UltiGCode) von der Firmware automatisch aufgerufen danach erfolgt die "end-of-print" Retraction je nachdem, was die aktuelle E-Position am Druckende war, hat das den "Blob-Effekt" (wenn E sowieso grad auf Null steht, merkt man es hingegen überhaupt nicht) M25 schließt die Datei vorzeitig, dann ist der Ablauf am Ende etwas anders, das kann evtl. "zufällig" den Fehler verstecken Evtl. kommt noch hinzu, das in früheren Cura-Versionen die E-Koordinate am Ende auf Null steht, und mit Cura 3.2 nicht mehr..., aber das habe ich nicht kontrolliert.

@DidierKlein https://community.ultimaker.com/topic/21686-nozzle-parking-and-oozing-at-end-of-print/?do=findComment&comment=201633 https://github.com/Ultimaker/UM2.1-Firmware/issues/2

My suggestion: temporary re-install the firmware version that came with Cura 2.5

In Cura you can influence this with the setting (Shell ->) "Initial Layer Horizontal Expansion" (read the comments).

@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)

The standby temperature for UltiGCode is a (fixed) calculated value - it depends on the printing temperature and the time of inactivity: after 30 seconds -> printing temp - 5% after 90 seconds -> printing temp * 0.8 (rounded down) after 5 minutes -> printing temp * 0.5 (rounded down) after 12 minutes -> 80°C I don't think that this is documented somewhere, it's just not the intended use. Interesting idea. It's worth a try.

That's a very old thread and a different issue. I'm pretty sure that this is a firmware glitch. Someone on the german forum solved it by re-installing the older firmware that came with Cura 2.5

resource files for Cura 3.2 (and upwards) are in a new folder on Github: https://github.com/foehnsturm/Mark2/tree/master/cura-3.2-resources For GCode-Flavor "Ultimaker 2" Cura does not generate the "temperature magic" - because this is quite important for dual color prints i recommend the "Marlin" flavor for single extrusion prints just use the stock Ultimaker 2+ machine in Cura as before (and remove the second printhead from the dock to free up the build area if necessary) Glad that you like it - Have fun!