tinkergnome

Sorry, but i can not get the Win64-Version to run. It crashes immediately after a printer is selected. Log file: cura.log

Ist das im Hintergrund eine Tastatur? Dann sind die beiden Türme vermutlich sehr klein? Möglicherweise zu klein, um auf einem FDM-Drucker überhaupt vernünftig gedruckt werden zu können? Was ist der Durchmesser der Düse (Nozzle)? Falls es überhaupt geht, müssen so kleine Objekte sehr langsam (20mm/s), so "kalt" wie möglich (180-190°C) und mit so viel Lüfter wie möglich gedruckt werden. Es hilft auch mehrere kleine Teile gleichzeitig zu drucken, damit die kleinen Flächen zwischendurch Zeit zum Abkühlen haben. Der Bauteil-Lüfter auf dem Bild sieht allerdings nicht sehr effektiv aus... das wird auf jeden Fall schwierig mit diesem Drucker. Kannst Du zum Testen nicht erstmal mit einem Teil in "normaler" Größe anfangen?

Hi ElClipo, can you show a screenshot of your settings for the post processing script? The symptom sounds like you forgot to define a "Resume Temperature"...

Hallo Christian, willkommen im Forum! Es ist sehr unwahrscheinlich, das das etwas mit dem Material zu tun hat. War das die exakt gleiche Datei, die Du vorher mit dem anderen Material gedruckt hast? Wie sieht die Layer-Ansicht in Cura aus? Wenn es dort auch schon den 3mm Abstand gibt, hat es nichts mit der Kalibrierung vom Drucker zu tun. Du kannst auch Bilder oder die erzeugte gcode-Datei hier hochladen, wenn es kein geheimes Projekt ist.

first question: S3D should have predefined printer profiles for the Ultimaker printers, have you choosen the right printer in S3D? next - check the process settings:, especially nozzle diameter, flow multiplier and material diameter(!)

I don't think so, i use Cura 3.2.1 as well. It depends... if Cura has imported (copied) the machine configuration from an older version, it may be not using the new start script. You can temporary add a new (fresh) Mark2 machine to Cura and compare the start-scripts. If it doubt, post it here.

@gr5 - the keyword is: Ultimaker 3 - i guess that's a completely different topic and probably not even possible without some modifications to the printer...?

I think that's the crucial point. Disassembling a print core, replacing of the consumable parts and finally reassembling it... This needs a skilled employee, the right tools plus the spare parts... I'm sure, this would be much more expensive than simply throw it away and buying a new one. (who wants a refurbished printcore that is more (or equally) expensive than a new one...?) It's a pity sometimes, but the reality for many products nowadays.

This should be already done at startup (if the correct pin numbers are defined): https://github.com/Ultimaker/Ultimaker2Marlin/blob/master/Marlin/stepper.cpp#L698 pin numbers in your case should be 54 to 56 for x-axis and 59 to 61 for y-axis, right? ...but there are perhaps some more things to consider: https://github.com/Ultimaker/Ultimaker2Marlin/blob/master/Marlin/Configuration.h#L310 https://github.com/Ultimaker/Ultimaker2Marlin/blob/master/Marlin/Configuration_adv.h#L165

in addition: read the comments on thingiverse... The file "cura.log" in the configuration folder should contain appropriate error messages (or warning), if a script can not be loaded.

Ganz so schlimm ist es nicht - es haben sich nur noch nicht besonders viele Freiwillige gefunden, die damit weitermachen wollen... Zum größten Teil sind es deshalb Änderungen, die ich für mich selbst implementiert - und danach mit der Welt geteilt habe. Prinzipiell sehe ich das aber eher als "Community-driven". Ich kann ja unmöglich auf Dauer alles selbst machen. Wenn jemand eine tolle Idee implementiert hat, die für die Allgemeinheit von Interesse ist, dann sehe ich keinen Grund, warum er das nicht einbauen dürfte. Natürlich darf die "normale" Funktion davon nicht gestört werden, aber das würde die Community sowieso schnell herausfinden... Und für spezielle Erweiterungen kann man ja jederzeit "branchen" und "forken" und so... ....ich stelle grad fest, das wir von der eigentlichen Frage langsam ziemlich abweichen... macht aber nix - ist ja Dein Topic!

@printDude die meisten Unterschiede sind eher kosmetischer Art. Die Tinkerfirmware baut hauptsächlich die Menüs am Drucker um und macht (für die Bastler) ein paar mehr Parameter direkt einstellbar, ohne jedesmal die Firmware neu kompilieren zu müssen. Der größte sichtbare Unterschied ist wohl die Anzeige während des Druckens. Die wichtigsten Druckparameter werden permanent angezeigt und können direkt "getunt" werden. Das eigentliche Drucken sollte genauso funktionieren, wie mit der Standard-Firmware (zumindest ist das der Plan... ) Fehler gibt es bestimmt auch in der Tinker-Firmware - nur eben vielleicht an anderen Stellen... Du kannst einfach wählen, was für Dich bequemer in der Bedienung ist. Nur beim Hin- und Herwechseln zwischen der Standard- und der Tinker-Firmware sollte anschließend ein "Factory-Reset" gemacht werden, weil sich inzwischen bestimmte Bereiche der gespeicherten Einstellungen überlappen (zumindest beim UM2+). Zur Dual-Standard-Firmware kann ich nichts sagen, ich bin auf "Mark 2" umgestiegen.

Den "Blob" gibt es mit der Tinker-Firmware nicht. Das Einzige, was noch geändert werden muss, ist dieses (ur-alte) Verhalten: (die Korrektur können wir natürlich kopieren - am Besten sobald Ultimaker den Fix erfolgreich getestet hat... )

@Starwind0 - you will never see the "Printing out of printing area"-error while USB printing - because this check is only active during prints from sdcard.... Don't worry about the wires. Have you checked the stored "Print area" settings on the printer? (ADVANCED -> Preferences -> Print area) Yes, that's to be expected. DEFAULT_AXIS_STEPS_PER_UNIT is only used during a factory reset. Installing a new firmware alone does not change any stored value. That means: you can either do a factory reset afterwards (which resets all stored values to the defaults) - or store the new settings manually with M500. If i where you - i would double check all other stored settings in "Preferences" - just to be sure.

Eine Versionsnummer kann ich Dir nicht nennen, aber das "Commit" für die problematischen Änderungen ist vom 29.05.2017 Jede Firmware-Version, die ein älteres Datum hat, sollte unkritisch sein (das Datum wird im "Version"-Menu am Drucker angezeigt)

Does your printer have an extruder with bowden tube? In this case: IMHO a certain amount of stringing is unavoidable for flexible materials. (For a direct extruder you could simple turn on retractions...) You can fight against it (a bit) by printing as slow and cool as possible (but it needs some heat for a good layer bonding...). And choose the speed for travel moves as high as possible on your printer.

@PxC_3D gibt es einen bestimmten Grund, den armen UltiRobot mit Support und auf dem Rücken liegend zu drucken? Oder war das nur ein Test? Es könnten auch die "Anfahrpunkte" von den Düsenwechseln sein. Ist das mit Prime-Tower gedruckt? Du kannst es ja mal mit der Layer-Ansicht in Cura vergleichen. Dort müsste man (blaue) Travel-Moves sehen. Passen die zu den komischen Nasen? Wie ist denn die Skalierung? Sieht ziemlich klein aus, oder täuscht das? BTW: Wenn es nur um den Ultimaker Robot geht: der ist eigentlich dafür gedacht, aufrecht stehend und ohne zusätzlichen Support gedruckt zu werden. Es müsste auch eine Version mit integriertem Support geben... ah... hier ist er: https://www.youmagine.com/designs/ultimaker-robot

@gr5 - I assume you forgot the two preconditions: "TPU" and "no retractions"... If not... teach us the secrets! BTW: @amagro "Ultimaker TPU 95A" or something else?

The build area in your "Configuraton.h" looks suspicious. #define X_MAX_POS 215 #define X_MIN_POS 0 #define Y_MAX_POS 210 #define Y_MIN_POS 0 #define Z_MAX_POS 285 #define Z_MIN_POS 0 Is this a (modifed) "Extendend"? There's is a separate branch for the "Extended" - but it doesn't matter, because you changed it anyway... Your "Homing" position for z (301.xx) is not possible, if Z_MAX is set to 285. Can you check, which values are stored on the printer for "Print Area"? The default value for an UM2Extended is Z_MAX_POS = 330 (approx 30mm more than the maximum possible height of the printed object). And don't forget to re-level the buildplate, if you change this value. Regarding the extrusion: what about the rotation direction of the e-axis? Transports the "move" function the material in the right direction? This can be changed in the "Invert axis" menu. (both settings can be found in the "Prefeences" menu) Just to clarify: the values in "Configuration.h" are only the defaults (used after a factory reset). More importand are the actual values that are stored in the printer's EEPROM. Better check, if everything looks like you intented it.

This sounds like a use case for the "Maximum Resolution" setting - it's in the "Experimental" section of the custom settings. According to the tooltip it does exactly what you describe.

It seems like the final copy command in the build script is failing. Probably because the target folder ".../Marlin/resources/firmware" does not exist. You could create the folder (one time step) or change the "cp" commands or the path in "package.sh" to whatever you like. Good luck with the documentation!

ungefähr so wie hier? https://community.ultimaker.com/topic/21564-ultimaker-setzt-am-ende-einen-batzen-filament-drauf/

"Pause at height" does not much more than inserting a "M0" gcode command. It's up to the firmware of your printer, how it handles this command. The usual behavior of Marlin is, that it stops listening to the serial port (or reading from sd-card) and just waits until a button on the printer is pressed. That's why the print can not be resumed from an "external" source. You should ask the manufacturer how this works on your printer, if it has no display or buttons.

I'm not sure, if it is the same thing, but Cura always generates a move to the last position of the previous extruder after every tool change. That means: it does actually not "print" unwanted lines, but there are some unwanted travel moves. If it is this, what you noticed: that's the main reason for the existence of the postprocessing script. Have you used it for the shown prints? (Extensions -> Post Processing -> add the "Mark 2 Tweaks" script).

As you already found out: forget about the "readme.md", it's just inherited from the original Marlin repository and was already outdated a few years ago... (IMHO) ...mmmh - i don't know what this "CrossPack" thingy is - it should not be needed and is perhaps the root cause of your linker problem? It is this line from the Makefile (the "-Map..." - part) that generates the *.map file: $P $(CC) $(ALL_CXXFLAGS) -Wl,--gc-sections -Wl,-Map=$(BUILD_DIR)/$(TARGET).map -o $@ -L. $(OBJ) $(LDFLAGS) Perhaps your avr tools use a different syntax? The "AVR_TOOLS_PATH" should be "/Users/ddd/Downloads/Arduino-1.8.5/hardware/tools/avr/bin/" in your case. Why do you need the different tools from "CrossPack-AVR"? Has this changed for the new avr compiler version? BTW: the map-file option was added by @Daid a while ago, you can even remove it, if you don't want to fiddle around with it. This was the change: https://github.com/Ultimaker/Ultimaker2Marlin/commit/7408e32de2d4348a077c6b274af3635f022e1e6a#diff-04c206a8bd7b5cedd4c30700d062b19aL398