tinkergnome

Hi @thrmttnw, welcome and a quote at first: I presume it works in the same way for all extruder specific settings. You can even combine it with the '....extruder_nr' placeholders instead of hard-coded digits if you like. For example: M104 T{adhesion_extruder_nr} S{material_print_temperature_layer_0, adhesion_extruder_nr}

How do you change the flow rate? In the "Tune" menu during a print, in the material settings (on the printer) or somewhere else with a gcode command? And out of curiosity: why so much? Is it a special material? Anyway: the standard firmware does not reset the extrusion multiplier at the end of a print, only at the beginning. It should be possible to add an explicit gcode to the end-script (somewhere in the slicer settings - depending on the slicer you use). M221 S100 ; reset extrusion multiplier https://reprap.org/wiki/G-code#M221:_Set_extrude_factor_override_percentage

Nein, es ist genau andersherum. Hier wird ausgewählt, mit welchem Extruder die "wall lines" gedruckt werden. Da kann es nur eine globale Einstellung geben. Das erkennt man an dem kleinen Kettensymbol. In diesem Beispiel können die Wandlinien entweder in weiß oder in rot gedruckt werden, aber doch nicht beides....? Das "T0" vor dem Startskript hat mich auch schon gestört, Cura trägt dort immer ein, was es als "inital extruder" erkannt hat. Falls Skirt oder Brim nicht explizit ausgeschaltet wurde, sollte das immer die {adhesion_extruder_nr} sein. Also sollte es eigentlich helfen, als "Adhesion extruder" auch den T1 auszuwählen. Das Startskript von oben enthält offenbar keine explizite Tool-Auswahl (T0 oder T1) und auch keine Temperatur-Befehle - das wurde doch davor und danach von Cura implizit dazu generiert, oder nicht? Wenn nur mit einem bestimmten Extruder gedruckt werden soll, kann der andere in Cura deaktiviert werden. Ich habe es noch nicht ausprobiert, aber damit müsste das deaktivierte Tool eigentlich auch komplett aus dem generierten gcode verschwinden. Wenn alles nichts hilft, würde ich an den Anfang des Startskriptes noch eine Zeile setzen mit: T{adhesion_extruder_nr} Wie hast Du dafür das "Temperaturproblem" im Dual-Druck gelöst? Cura selbst bietet ja bisher noch keine Unterstützung für so eine "shared-heater" Installation. Setzt Du dann einfach in Cura alle Temperaturen auf den gleichen Wert, oder ist der Geeetech schlau genug, das jeweils passend für den aktiven Extruder selbst zu regeln? Nur aus Neugier: Wie funktioniert das denn im späteren Verlauf, wenn zwischen den Extrudern gewechselt wird? Ist dann der "Materialvorlauf" länger als die 20mm aus dem Startskript, oder gibt es einfach einen sehr großen Purge-/Prime-Tower, oder wie funktioniert das? Macht der Drucker den Farbwechsel automatisch beim Werkzeugwechsel, oder sind dafür auch Skripte in Cura hinterlegt?

Another promising approach is this one (IMHO): https://www.instructables.com/id/3D-Filament-Fuser/

i guess, the site is still a "work in progress" and not all compatible materials are up-to-date yet, but it seems there is a plan to add a flag called "Optimized for Material Station". See: https://marketplace.ultimaker.com/app/cura/materials/EASTMAN/AMPHORA3300 or https://marketplace.ultimaker.com/app/cura/materials/eSUN3DPrinting/eSUN_ePACF_2019

There are exceptions (different topic), but in general the slicer does not change the model but tries to calculate the toolpath in a way that it stays as close as possible to the given mesh geometry. From the perspective of a slicer, a "wall" in the model always consists of two "shells": inner and outer shell. That's one of the reasons why it is so important that the model has to be "watertight" and must not contain any additional faces inside of solid walls. Depending on the line width and the shell thickness the maximum number of "wall lines per shell" is calculated. If the wall of the model is thinner than the two "shells", the line count is reduced and the whole wall is printed with a proper amount of "wall lines". If the wall of the model is thicker than two times of the "shell thickness" the gap in between the "shells" will be printed as infill (or "gap fill" if the gap is small and if the according option is enabled). You can always check the generated toolpath in the "Preview" before printing, that's the best opportunity to compare different settings visually (although... i guess you already know this). Hope that helps!

Well, technically it's easy to answer. The "old" API (.../api/v1/) needs digest authentication (*). Cura Connect (.../cluster-api/v1) was added in a later firmware version and works without authentication. (*) Anyone with physical access to the printer can confirm its own account at any time on the printer. That means: it is not of much help in an office environment anyway. So i guess that the authentication part was not left out by accident, or because it's hard to implement (it was already there, right?) - but for a specific reason. Maybe @nallath can share some inside knowledge? 🤷‍♂️

@traderhut - be aware that Cura has no support for this setup yet ("shared heaters"). There are signs on Github that this will change in the near future, but - for now - such a setup would need some "post-processing" on the generated gcode file. (not sure, but it think there was an example somewhere here in the forum...?) The shown gcode sequences are perfectly suited for Ultimaker printers (with two print cores and a nozzle lifting mechanism). The temperatures are probably the configured "initial" and "final printing temperature".

This sounds more like a problem with the lifting switch than with the leveling procedure? Does the lifting mechanism for the second print core work at all? And: there's a calibration function for the lifting switch in the maintenance menu, it's worth a try.

The actually used OpenGL driver and version is written to the "cura.log" file (in the Cura configuration folder). Just search for "OpenGL" or for the "ERROR" keyword- this gives perhaps some hints. Here is an example of how it looks like: [...] - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [112]: Initialized OpenGL subsystems. [...] - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [113]: OpenGL Version: 4.1.0 NVIDIA 376.54 [...] - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [114]: OpenGL Vendor: NVIDIA Corporation [...] - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [115]: OpenGL Renderer: GeForce GTX 960M/PCIe/SSE2 [...] - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [116]: GLSL Version: 4.0.0 ...and just to be sure: does it work in compatibility mode or not at all?

The "variant" in Cura (name of the print core) has to match the id that is programmed into the print cores EEPROM (like "AA 0.4", "AA 0.8" and so on). Probably applies to the nozzle diameter as well (not sure). It's indeed the same principle as the material GUID. The printer displays the print core information (somewhere in the maintenance menu?). And Cura generates the appropriate header for the gcode file ("....NOZZLE.NAME" and "...NOZZLE.DIAMETER") Both has to be the same. That's all (AFAIK). Are there no provided instructions from the print core reseller that explain a proper configuration for Cura?

Many notebooks are equipped with more than one graphic processor. Is it possible that Cura does not use the NVIDIA chip at all?

Well, your model is not a solid. It consists of three (partially overlapping) shells. Your chances are higher, if all shells can be combined into one single solid (i don't know how to do this in Turbocad though). 1196351246_PrinterCabinetBumpOut_combined.stl

Another thingy from 3DLabPrint? Try this first:

mal sehen... Hier ist die Mathematik: https://math.stackexchange.com/questions/305642/how-to-find-surface-normal-of-a-triangle ...und hier (u.a.) eine php-Funktion zur Berechnung von Kreuzprodukten: https://www.geeksforgeeks.org/program-dot-product-cross-product-two-vector/ Das liegt wahrscheinlich nicht grundsätzlich an fehlenden Normalvektoren, sondern daran, das sich in deinen Modellen die Innen- und Außenflächen berühren, aber trotzdem eine gemeinsame Fläche bilden sollen.... Das versucht Cura irgendwie zu reparieren... mit wechselndem Erfolg.... Im Abschnitt "Mesh Fixes" ist standardmässig die erste Option aktiviert ("Union overlapping volumes"). Wenn die ausgeschaltet wird, sieht es schon besser aus. Viel Erfolg!

Ich glaube @Digibike ist auf der richtigen Spur. Schätzungsweise die Hälfte der Dreiecke zeigt mit der Innenseite nach außen. Wenn ich das obj-Format bei Wikipedia richtig verstehe, ist also entweder die Reihenfolge der Vertices falsch oder es müssen zusätzlich Normalen definiert werden.

Time estimation is only available after slicing and is not re-calculated from a (pre-sliced) gcode file - so that's normal (AFAIK) The warning message can be switched off in the preferences dialog ("Caution message in g-code reader"). Good luck!

"pause at height" fügt im Wesentlichen einen "M0" gcode in die Datei ein. Hast Du mal kontrolliert, ob die Zeile auch tatsächlich in der gcode-Datei zu finden ist? Wie hast Du das dort eingefügt? Im Zweifel kopiere die entscheidende Stelle aus der gcode-Datei mal hier rein, vielleicht sieht man da schon was...?

Well, I'm not that familiar with Cura, but what i noticed is: Cura always adds a toolchange command with the initial extruder number right at the beginning of the file - even before the start script. This does not work. The T1 command is needed "after" the start script. (I don't know if former Cura versions handled it different). I usually edit the gcode file manually if the print really needs to start with the second extruder. It may be a possible workaround to add an additional tool-change command at the end of the start script, but i have not tried it yet. ... G92 E0 T{adhesion_extruder_nr} ;end of startup sequence

Wie sieht denn die Druckvorschau aus? Cura versucht auch gern mal Support an Stellen zu drucken, wo man es nicht erwarten würde... Nicht das es dort am Ende "absichtlich" platziert wird?

Can you elaborate a bit - what you're trying to achieve? A (single material) print with the second extruder only will probably need a different start script.

I'm quite sure that at least the "garbled" display was fixed pretty soon, but besides that... i do not know. I don't use this firmware variant anymore - because my printer was converted to "Mark 2" in 2017 (i never used the material change procedure anyway). Perhaps someone else with an UM2 can check it?

It's perhaps still the same problem as mentioned here: 🤷‍♂️

P.S. - das würde man allerdings auch schon in der Druckvorschau sehen - hier etwas übertrieben: die blauen Linien sind Bewegungen ohne Retraction. Hast Du am "Combing Mode" irgendetwas geändert (ich glaube in der deutschen Übersetzung heißt es irgendwas mit "Kamm" oder so ähnlich)?

45mm/s ist das Maximum bei Ultimaker-Druckern. Selbst wenn Cura höhere Werte zulassen würde, begrenzt es die Firmware später doch wieder auf 45mm/s. Ich glaube, das ist in diesem Fall auch gar nicht das Problem. Stell das lieber wieder zurück auf den Standard, die 6,5mm bei 25mm/s reichen vollkommen aus. Ist das eigentlich PLA oder irgendwas exotischeres? Es vermute eher, das bei diesen kleinen Teilen irgendwann gar keine Retractions mehr ausgeführt werden, weil der "maximum retraction count" erreicht ist. Achte einfach mal drauf, ob das markante "beep-beep" überhaupt in jedem Layer stattfindet. Dann wären das hier eher die Kandidaten für einen näheren Blick: