tinkergnome

t.b.h. - i have no clue which changes were made to the DXU firmware... It's a different approach, if you have a good source for the needed hardware it's probably worth a try.

Da wählst Du am Besten einen Standardtyp aus, der eine ähnliche Drucktemperatur braucht. In diesem Fall einfach Nylon oder CPE. Das wird nur beim Laden des Materials verwendet, ist also nicht so kritisch. Das Übertragen von eigenen Material-Profilen auf den Drucker soll auch irgendwann möglich sein, aber das braucht wahrscheinlich noch ein oder zwei Cura-Versionen. Ich verwende in Cura ausschließlich die generischen Materialien, die auch der Drucker kennt, dann passt es zusammen. Eigene Cura-Materialprofile machen im Moment für UM3 und S5 keinen Sinn (IMHO). Außerdem gibt es offenbar in Cura 3.6 einen (neuen) Fehler, der dazu führt, das die Warnung auf der "Monitor"-Seite von Cura nicht ignoriert werden kann. Da soll es helfen, auf die "Cura-Connect"-Seite im Browser zu wechseln (ich glaube, in Cura gibt es auch einen Link dafür...?). Dort soll es dann funktionieren. https://github.com/Ultimaker/Cura/issues/4897

Well, Cura will not change your model (besides of scaling and rotating... and some special settings that doesn't matter here...). In your case, it will always try to print the walls like they are modeled. The term "wall" in Cura is the printed "shell" around your modeled walls. If the latter are too thin to print, it will not work. For the shown geometry you can try to model the part as a closed solid (without walls - only a single closed outer shell). Then you can actually choose the wall, bottom and top thickness in the slicer.

I guess the demand is not very high, 'cause using the web interface is easier and works with every printer. But technically it should be possible with "Action Commands" nowadays. http://docs.octoprint.org/en/master/features/action_commands.html

You have full control to the configuration, if you feel comfortable about developer mode, ssh and some simple Linux commands:

Wenn ungültige Koordinaten aus der gcode-Datei gelesen werden, wird die Bewegung gar nicht erst ausgeführt. Es ist also normal, das der Drucker bei diesem Fehler an der letzten gültigen Position stehen bleibt. Es könnte sein, das die gcode-Datei tatsächlich ungültige Koordinaten enthält. Wurden die mit Cura erstellt? Sind noch irgendwelche Post-Processing-Skripte aktiv? Wenn der gcode als Datei gespeichert wurde, kann man die direkt in Cura wieder einlesen, vielleicht sieht man dann schon was...? Falls damit alles normal ist, können es eigentlich nur noch Datei-Lesefehler sein. Wenn vom USB-Stick gedruckt wurde, kannst Du mal einen anderen ausprobieren (bzw. die Datei auch mal direkt vom USB-Stick in Cura anzeigen lassen)

RepRap firmware is very open and flexible, runs on modern ARM processors, but is - of course - not polished for an Ultimaker out of the box. Though it's very easy to add (so called) macros for all kinds of stuff like this. As soon as one starts to add those specific functionality for the particular printer it can become even more convenient then the stock firmware. It's not limited to (pre-) compiled things like Marlin, one can expand it on its own. Well someone has to do it - and to share it - of course... For example: i use it on a different printer, added a BLTouch for mesh bed compensation and a filament sensor - makes life so easy... Such things are not possible with Marlin without recompiling.

just choose the right option and you're not bothered with additional questions (red marker):

Gute Frage, aber für den Materialwechsel wird dieser Maximalwert vorübergehend geändert, dafür wird im Gegenzug "acceleration" und "jerk" sehr niedrig eingestellt. Im Prinzip das Gleiche, was man auch per gcode machen könnte (M203, M204 und M205). Das hab ich übrigens nicht dazu "erfunden", das macht die Standard-Firmware schon immer so. Daher kommt auch das markante auf- und abschwellende Motorgeräusch bei dieser Funktion. Ansonsten bin ich der gleichen Meinung wie mein Vorredner: 😏 Die Vorhersage der Druckzeit ist nicht sehr genau (immerhin ist das nur ein 8-bit Microcontroller der mit dem eigentlichen Drucken schon gut ausgelastet ist). Ich hab mich entschieden, die Zeit auszublenden, wenn die prognostizierte Restzeit abgelaufen ist. Das erschien mir irgendwie sinnvoller, als die ganze Zeit eine Null anzuzeigen... Das ist also auch normal. Die Prozentanzeige errechnet sich ausschließlich aus der aktuellen Position in der Datei, das ist einfacher und passt deshalb immer. Die "zuckende" Anzeige hatte ich auch von Anfang an, also noch bevor ich überhaupt angefangen habe, die Firmware auszutauschen. Ich bin immer davon ausgegangen, das das vermutlich leichte Spannungsschwankungen sind, die das Display kurzzeitig aus dem Takt bringen. Bist Du ganz sicher, das es erst mit der geänderten Firmware angefangen hat, oder ist es evtl. vorher nur nicht so aufgefallen? (ich hab nur den einen UM2, kann also schlecht vergleichen...)

Oh, prima, ein freiwilliges Opfer... ähh Tester! Behalt im Hinterkopf, das dieses (Pre-) Release praktisch nicht getestet ist, also wenn irgendetwas seltsamer aussieht als gedacht, dann sag Bescheid und installiere solange die V17.10.1 Die 50 mm/sec beziehen sich auf die Geschwindigkeit beim Laden / Wechseln des Materials. Das hängt momentan direkt von den steps/mm ab und lässt sich nicht separat ändern. Das dürfte dann eher so bei 85 mm/sec liegen. Für den Ultimaker 3 soll man es seltsamerweise auf 70 ändern - und der Feeder ist mechanisch identisch. Vermutlich wird es auch so einfach funktionieren. Ich hab diese Material-Wechsel-Assistenz-Funktion allerdings noch nie benutzt, mit dem "plus-" oder dem DDG-Feeder kann man das Filament prima per Hand ein- und ausfädeln (oder ggf. mit der "Move material" Funktion für die Feinarbeit). Dafür brauchst Du eigentlich überhaupt keine andere Firmware, das geht auch mit drei Zeilen gcode, in eine Datei geschrieben und "gedruckt", oder per USB gesendet: M501 ;aktuelle Parameter aus EEPROM lesen M92 E311 ;E steps/mm aendern M500 ;Parameter speichern Das bleibt dann gespeichert, nur nach einem "Factory Reset" müsste man es wiederholen.

for the next time:

Usually not, the value is saved to EEPROM and stays there - until the next factory reset. And you can set and save it with two lines of gcode - like explained in the Bondtech FAQ, no need to turn the wheel for an hour... 🙂 The build script and the Makefile on GitHub are (out of the box) only suitable for my individual installation (which is also changing now and then...) and mainly there to compile all variants in one go. I admit that it can be pretty hard to modify it to your needs, if you've never done it before.

Normalerweise ist das auch so.. wobei "ähnlich fest" zu ungenau definiert ist... Es gibt Druckfestigkeit, Zugfestigkeit, Biegesteifheit, Schlagfestigkeit, Abriebfestigkeit... und bestimmt noch ein paar mehr... 🙂 In diesem Fall gibt es offenbar immer noch ein Problem mit der Layer-Haftung. Es kann auch einfach sein, das das Material zu viel Feuchtigkeit gezogen hat, PETG wird dann schnell brüchig. Liegt das schon länger offen herum, oder war das neu und eingeschweißt? Wenn mechanisch am Drucker alles in Ordnung ist und trotzdem so auffällige "Fehlstellen" sichtbar sind, kann es auch am Materialtransport liegen (Spule nicht sauber gewickelt oder der Durchmesser ist nicht konstant?) - das ist "Stochern im Nebel", aber durchaus etwas, was Du mal kontrollieren kannst. Extrudr PETG hab ich noch nicht ausprobiert, aber ähnliches Material drucke ich mit: - so wenig Lüfter wie möglich - 0.1mm Layerhöhe - 35mm/s oder langsamer - Temperatur ca. in der Mitte des Bereichs, der vom Hersteller angegeben ist, für den ersten Layer oder im Zweifel ein paar Grad höher Bei größerer Layerhöhe würde ich es langsamer oder heißer drucken. PLA benutze ich fast gar nicht mehr.

What is not working regarding to the firmware? It should not be necessary to compile your own variant. If you use the tinker firmware, you can change the steps/mm and the rotation direction in the preferences menu.

The build script is a linux shell script. I start it in a "git BASH" console, but there may be other options like mentioned by @gr5 https://gitforwindows.org/

no way... because.. it depends... ? (mainly on the firmware that you want to use with your mod...) In case of Marlin firmware one can remove the feeder motor, fans and heaters - basically everything but the temperature sensor. If all heaters are disconnected one can even safely replace the temperature sensor with an adequate resistor. And if one is willing to modify the firmware the only limit are the mechanical properties of the device.

Which browsers have you've tried? I remember that i had a similar problem back then with the UM3 and Firefox. I made a try with Internet Explorer and it worked flawless and at the first time. I don't know, if it helps in your case, but a different browser can obviously make a difference.

Dann würde ich die Temperatur erstmal so lassen. Aber wie schon in dem anderen Beitrag erwähnt, funktioniert es am Besten ganz ohne Lüfter. Das hängt aber von der Geometrie ab. Anhängig von der Größe des Objektes ist ja auch noch die (minimale) Zeit pro Layer interessant. Wenn es bei kleineren Teilen oder wegen der Überhänge ohne Lüfter nicht geht, würde ich als Richtwert bei einem UM2 10% als regulären Wert vorschlagen, beim UM3 noch weniger (5%). Außerdem als Maximalwert für die Lüfter 50% und minimale Zeit pro Layer ca. 10s.

For RepRap-Firmware nearly everything is configured with gcode scripts (without the need to re-compile the firmware). That means, using it with the tool changer is a matter of: "edit the pre-defined tool change macros in a way that it works like you want ..." For example: it has some "slots" to save (and restore) the current position and temperatures with a gcode command. This is used for the pause function, and can be useful for the tool changes as well. A whole new playground, if you want so... ?

Don't get me wrong, but i think you are asking at the wrong place... This is a forum for the community and it is unlikely that someone here can solve your hardware problem. All official support for end-users is done by the resellers and distributors of your country. You don't mentioned if you already have tried the official way? You can ask here too of course, but how likely is it that you get qualified answers from other users...? Your chances are much higher if you pass the question (or the machine) to your reseller (IMHO).

seems like the system can not even read from the EEPROM, the comment in eeprom.py say: # Location of the EEPROM in the filesystem (eeprom is exposed as a file-like object by linux) __SYSTEM_EEPROM_FILE = "/sys/bus/i2c/devices/1-0050/eeprom" Your friend can check, if this "file" exists on the printer, but to me it looks more and more like a hardware error of the Olimex board?

It's just an idea, but doesn't have the S5 the same API as the UM3? One can control the pre-heating and the main lights of the UM3 with small python scripts (amongst other things). It would not be very handy for a big printer farm, but works great for single printers. Though, this needs a running computer instead of a simple switch... ? Not sure, if this is still possible on the S5... but if, would this be an option?

mmmh, and why is the prime tower so far away? I guess it would be better to place the tower closer to the printed object, this would avoid such long travel paths.

with other words: "Behaviour" = "Single Layer" doesn't work like one would assume?

Yep. the correct ID should be "9511" (for an UM3ext) Authorized resellers from your country should be able to configure it for you, or can provide you with detailed instructions. Good luck!