tinkergnome

Pah! Haarlineal grenzt ja schon an unlauteren Wettbewerb! 🧐 🙂 Selbst wenn die Platte perfekt eben ist, können immer noch die (paarweise verbauten) Führungsstangen für X und Y - Achse leicht "bananenförmig" sein. Dann hat man keine Chance, egal wie gut man "levelt". Menno, der komplette Drucker kostet < 280 EUR (Versand aus China inklusive) - da kann man schon mal ein paar Kompromisse mit Bluetape eingehen.... 🙂 Mit Cura-Einstellungen hat das allerdings jetzt nix mehr zu tun - und da ist auch in dieser Hinsicht nicht viel zu machen (IMHO).

Sure - building a well adapted firmware should be part of the team project anyway, shouldn't it? The usual steps for this case are: download the firmware source files from https://github.com/Ultimaker/UM2.1-Firmware make your changes to Configuration.h compile a new *.hex file upload the new firmware to the printer But you're not limited to the Ultimaker Marlin. One can use newer Marlin versions (or even a completely different firmware) that support more features (think of additional sensors, assisted leveling, filament detection and such stuff...) Since you obviously have a team and a fablab at hand... let it grow and think bigger! 😁

Ein bisschen "off-topic" (hier im Ultimaker-Forum), aber egal...: Das ist ziemlich üblich bei diesen günstigen Druckern. Wenn "mesh bed compensation" nicht zur Verfügung steht, bastelt man sich das oft mit ein paar Lagen Klebeband so weit zurecht, das es einigermassen funktioniert. So wie hier in dem Video (ist nur ein Beispiel - davon gibt es massenweise...) Z-Hop würde ich auch wieder ausschalten, der wird eigentlich nur für Delta-Drucker wirklich gebraucht. Schau Dir mal die Hilfetexte zum "Combing Mode" an. Ich glaube der Suchbegriff in der deutschen Version ist "Kamm" oder so ähnlich. (ich glaube, der original-Begriff ist auch schon irreführend - "combining" würde besser passen - aber das ist wohl "historisch gewachsen"...)

in addition: all parts of the print cores are documented (if you want to dig deeper...): https://github.com/Ultimaker/Ultimaker3#ultimaker-3

Mea culpa..., it seems the definitions were added in version 4.7 Download link is in the announcement topic:

Hi Chris, welcome to the forum! Some possibilities: choose one of the other Tronxy printers and modify the machine settings where needed add it as a custom printer https://support.ultimaker.com/hc/en-us/articles/360012370160-How-to-add-a-custom-printer-to-Ultimaker-Cura create a complete new set of definition files https://github.com/Ultimaker/Cura/wiki/Adding-new-machine-profiles-to-Cura Good luck!

There are some explanations about the "stacked profile system" on the developer-wiki: https://github.com/Ultimaker/Cura/wiki/Profiles-&-Settings The material settings are on the very bottom of the stack, so it's very likely that - in your example - the temperature is overridden by a profile with higher priority. The whole calculation depends on the chosen printer definition (and quality profile). Most of the non-Ultimaker profiles are contributed by the community (or more rarely by printer manufacturers). Which printer is it? Isn't there a reset icon visible like explained in the manual (6)? https://support.ultimaker.com/hc/en-us/articles/360012028419-How-to-use-the-custom-print-settings-in-Ultimaker-Cura

If there are errors in the Python code the script will not show up. You have to restart Cura after every change on post-processing scripts. All scripts are only read during the start of Cura. After the start of Cura: take a look at cura.log and search for error messages that are related to your script. It's safe to delete the log file before starting (shorter file -> more clarity) I'm not aware of other ways to debug post-processing scripts.

You only need to do this for the section that is related to "MOTHERBOARD == 72" Just swap the defined pin numbers for: Y_STEP_PIN <-> E1_STEP_PIN Y_DIR_PIN <-> E1_DIR_PIN Y_ENABLE_PIN <-> E1_ENABLE_PIN Leave Y_STOP_PIN alone. That's all.

Das war nur nach dem normalen Druck-Ende, soweit ich weiß (und auch nur mit "Ultimaker 2" GCode-flavor). https://github.com/TinkerGnome/Ultimaker2Marlin/issues/98 "während des Drucks" hab ich auch noch nicht gehört. 🤷‍♂️ Ich halte es aber auch für recht unwahrscheinlich, das es an einer Cura-Einstellung liegt.

I'm not sure what you consider a "relatively painless way", i think only a few things are important: give it distinct "name" and "key" - settings (in function getSettingDataString) save the modified script inside the configuration folder in the sub-folder "scripts" (create the "scripts" folder first, if it does not exist) Restart Cura if applicable and the script should now be visible in the list of post-processing scripts with it's new name. Subsequent installations of newer Cura versions will copy it automatically to their particular configurations, no manual steps needed.

Well, there's an additional relay on the mainboard that switches the 24V loads (AFAIK) - this may be a clue. But this is not my field of expertise. The schematics are published: https://github.com/Ultimaker/Ultimaker2/tree/master/1091_Main_board_v2.1.1_(x1)

Klar, @Smithy kennt doch mich! 🙂 Technisch ist mein Mark2 quicklebendig und funktioniert auch nach Jahren noch genauso wie es soll. Mangels Nachfrage ist scheinbar der Verkauf von "Expansion-Boards" inzwischen eingeschlafen, aber das ist nur eine Option, die man nicht unbedingt braucht. Außerdem lassen sich die heutzutage produzierten UM2+ nicht mehr so einfach umrüsten, weil das Mainboard nur noch mit 4 Anschlüssen bestückt ist. Einen UM2 aus den ersten Jahren könnte man aber immer noch auf diese Weise umrüsten. Es macht halt nur kaum noch jemand, vermutlich weil es inzwischen genügend Dual-Drucker fertig zu kaufen gibt.

Autsch... davon hab ich auch noch nichts gehört - vielleicht waren die "Spratzen" am Printcore vorher schon da und sind nicht die Folge sondern die Ursache? Vorsicht - ist reine Spekulation von mir... Naja - "etwas abbekommen" ist die falsche Formulierung, aber es ist schon soweit plausibel. Wenn die Kommunikation zu einem peripheren System nicht hergestellt werden kann, bleibt der Startprozess an der Stelle normalerweise mit einer Fehlermeldung stehen. Dann geht es schlicht nicht mehr weiter und zeigt deshalb das normale Menü am Display nicht an. Willst Du es denn selbst reparieren? Sorge dann auf jeden Fall für einen ESD-sicheren Arbeitplatz, nicht das dann doch noch die richtig teuren Sachen Schaden nehmen... Laut Ultimaker gibt es ein paar Innereien, die in der Hinsicht recht empfindlich sind. Am Olimex-Board (nicht am "Ultimainboard") kann ein normaler HDMI-Monitor angeschlossen werden, dann kannst Du die Meldungen beim Systemstart verfolgen. Ich weiß aber nicht, ob das für die Diagnose in diesem Fall etwas nützt. Die Pläne sind alle im Git-Repository zu finden: https://github.com/Ultimaker/Ultimaker3/tree/master/PCB files Ausnahme ist das Olimex-Board, das müsste dieses hier sein (das ist aber vermutlich in Ordnung): https://www.olimex.com/wiki/A20-OLinuXino-LIME2 Auf jeden Fall - viel Erfolg! Edit: Du hast übrigens schon wieder vergessen zu erwähnen, um welchen Drucker es geht... 😁 Gibt es dafür nicht diese "Tags"? Das würde reichen...

So eine kleine Schraube ist wahrscheinlich kein so gutes Testobjekt für den S5, ist der nicht eher für die großen Arbeiten gedacht? Aber egal: Metrisches-ISO Gewinde hat dann immerhin einen 60° Überhang. Ich vermute, das die bei PLA nicht schnell genug abgekühlt wurden und sich dadurch leicht nach oben gewölbt haben (das Foto ist wirklich nicht besonders gut... 🤷‍♂️). Ich würde zusätzlich - so weit es geht - die Drucktemperaturen noch weiter absenken und/oder die "minimal layer time" erhöhen (bei dem kleinen Durchmesser wird aber wahrscheinlich eh' schon sehr langsam gedruckt?) - auf jeden Fall mit maximaler Lüftereinstellung drucken (das dürfte aber Standard bei PLA sein) - und beim S5 die Bauraum-Türen offen lassen (die sind für einfaches PLA eher kontra-produktiv) George hat ja seine Lieblingsparameter 🙂 schon aufgelistet.

The whole Marlin configuration makes extensive use of the C preprocessor gcc documentation for #ifdef: https://gcc.gnu.org/onlinedocs/cpp/Ifdef.html#Ifdef

oh.. i remember... 🙂 As a rule of thumb: use only offset values that are a multiple of the step size.

HOTEND_OFFSET_Y has to be defined as well, it's used here (mind the #ifdef clause): https://github.com/Ultimaker/UM2.1-Firmware/blob/UM2.1_JarJar/Marlin/Marlin_main.cpp#L172 The offset is not stored in EEPROM AFAIK and there's no z-offset in this Marlin version. But you have to fine-tune (calibrate) the values in the start-script anyway (with M218), or do you plan to customize the firmware after every nozzle change?

Warnings and errors about printer definitions are usually extensively reported in "cura.log". That's probably the most useful place to look at. Or do a comparison with the provided files in the AppImage. For example: setting_version = 13 is suspicious - it should be 14 (as far as i can see)

side question: why not....? Does the AppImage not use the exact same configuration folder?

Erfahrungen hab ich nicht, aber es gibt auch spezielles 'Laser Marking PLA' - und ich denke es muss einen Grund haben, wenn so etwas extra entwickelt wird... 🤷‍♂️ Wen ich das richtig verstehe, kommt es besonders darauf an, wie die Additive im Material auf die spezifische Wellenlänge des Lasers reagieren. Da ist wohl tatsächlich Experimentierfreude (und der richtige Laser) gefragt.

Prusa firmware displays the filename in the status line while printing from SD-card. Other messages are ignored until the print finishes. With other words: this specific post-processing script is probably not very useful for original Prusa printers.

Normalerweise wird der verfügbare Druckbereich von der Drucker-Firmware begrenzt ("Software Endstops"). Überstehende Teile werden dann vom Drucker quasi "abgeschnitten". Es hat deshalb normalerweise keinen Zweck, im Slicer einen größeren Druckbereich einzustellen, als vom Drucker vorgegeben. Zum Experimentieren: Evtl. können die Software-Endstops bei deinem Drucker deaktiviert werden (mit dem verlinkten gcode-Kommando), aber das hängt davon ab, wie der Hersteller die Firmware konfiguriert hat.

Was steht denn in den anderen Log-Zeilen zu OpenGL (es müssten 4 oder 5 sein)? Passen "OpenGL Vendor" und "OpenGL Renderer" zum NVIDIA-Treiber?

Da kommen einige Dinge in Frage..., Mindestanforderung dafür ist OpenGL 4.1 (glaube ich...) welches Betriebssystem? ist das die einzige Grafikkarte, oder läuft Cura evtl. auf der "falschen" Grafik-Hardware? welcher NVIDIA-Treiber (genau) ist installiert? Der aktuelle Referenz-Treiber für Windows 10 ist auch schon ein paar Jahre alt, soll aber OpenGL 4.4 unterstützen: https://www.nvidia.de/Download/driverResults.aspx/110432/de Kompatibilitätsmodus in Cura ist nicht aktiviert? in der Logdatei (cura.log) einfach mal nach "OpenGL" suchen, das ergibt evtl. zusätzliche Hinweise Viel Erfolg!