Ich habe einen Weistek WT150 sehe günstig erstehen können. Heisst das so? Nunja wie dem auch sei, er kam an, ich wollte ihn ausprobieren und was war? Nix. lsusb und dmesg melden sich ordentlich. /dev/ttyACM0 wird auch angelegt.
Ich habe jegliche Software durch. Cura, OctoPrint und zich andere ergoogelte. Nix zu machen.
Von selbst build bishin zu fertigen Releases. Keine Chance. Also mal eine x3g mit ReplicatorG erstellt, ab auf die SD Karte und rein in den Drucker.
Er druckt. Aber naja.. Also mal ein Windows Notebook beim Nachbarn organisiert, DoraWare drauf, Drucker kalibriert. Testdruck über DoraWare einwandfrei. Nochmal x3g file auf Debian erstellt, ab auf die SD Karte, perfekt. Klappt. Klar, er ist ja auch kalibriert.
Nur zum Fillament wechsel etc brauche ich ja wieder eine Verbindung...
Ich habe alle durch. Vor 3 Jahren (2015) hatten auch genug die Probleme und manche haben das mit GPX und OctoPrint lösen können.
Serialport auf /dev/ttyACM0 und Baud auf 115200. Der Drucker "piebt" komisch und dann kommt error open serial timeout.
Hallo @DmanT Also für das wechseln des filaments brauchst Du keine Verbindung, da habe ich hier im Forum einen gcode. Die erstellte x3g kann man somit immer zur reinigen oder filament wechsel nehmen und auf der SD lassen.
Was die Verbindung angeht, welche einsellungen hast du für die "RS232" verwendet? Nur die Geschwindigkeit als info, ist etwas spärlich :-( Gibt es WT150 Treiber für Linux? Sind die anderen Tools vorhanden? Dürfen die Programme mit der Schnittstelle kommunizieren oder sind da eventuelle rechte nötig? Linux ist nicht mein Ding, meine aber das es gerade bei Zugriffsrechten sehr verzwickt ist.
Also Linux Treiber habe ich so keine gefunden. Jedoch wird, wie erwähnt, alles richtig erkannt.
Ich habe jetzt auch eine Verbindung bekommen, aber wieder sehr problematisch...
Ich versuche mal zu erklären...
Ich starte OctoPi, also OctoPrint und bekomme das Device angezeigt. (/dev/ttyACM0). Wenn ich nun auf Verbinden klicke bekomme ich eine Verbindung zum Drucker und kann auch den Extruder aufheizen. Filament vor- und zurück fahren.
Super. Kommen wir zur Steuerung.
Z funktioniert top. Also Hoch und Runter. Y war "falsch" herum also musste ich dort die Steuerung invertieren. Das hat auch funktioniert. Aber X bleibt falsch herum. Ob ich die Steuerung invertiere oder nicht. Sage ich links geht X nach rechts und umgekehrt.
Nun gut. Die manuelle Steuerung sollte ja nicht den gcode beeinflussen (so steht es auch drunter).... tatsache ist, ich spiele den gcode hoch und nur Z ist richtig. X und Y sind "falsch" herum. Da der Drucker beim Start zu 0 0 fahren will, das aber falsch herum ist, kommt er dort natürlich nie an. im gegenteil. Die Motoren machen sehr laute Geräusche. Nur ein Abbruch hilft dann noch. Das gleiche passiert auch wenn man bei der manuellen Steuerung in "Home" Position fahren möchte.
Mit DoraWare klappt aber alles bestens. Also muss das irgendwie man gcode liegen.
Das nächste Problem ist, das, wenn ich die Druckerverbindung trenne, keine neue Verbindung mehr bekomme. Hier hilft nur ein neustart des Systems. Nicht des Druckers. Hier denke ich wird es ein Bug von OctoPi sein. Solange ich jedoch verbunden bin bin ich verbunden.
Also schon einmal ein Teilerfolg.
Ich weiss jedoch immer noch nicht woran es lag. Plötzlich nach X neustarten bekam ich eine Verbindung.
Nun das mit der Verbindung habe ich auch unter Windof bei Simplify3D was trotz richtiger Parameter den Drucker erst nicht findet und nach etlichen Versuchen und Änderungen der Einstellungen plötzlich doch geht? Die Einstellungen der dortigen "Programm" Schnittstelle, dürfen nicht zu hoch aber auch nicht zu langsam gestellt sein, auch die Flusskontrolle ist wichtig! Stellt man z.B. bei S3D nicht auf RTS/CTS gibt es je nach dem zwar eine Verbindung, aber der gesendete Code wird vom verbauten Board nicht erkannt und es gibt keine Rückmeldung, so das kein Druck oder Steuern möglich ist? Die Virtuelle Serielle Schnittstelle in Windof "MightyBoard, S3G via Serial" Treiber Hersteller "MakerBot Industries" hat aber nur die Win Standardeinstellungen "9600/8/non/1/non" und die braucht man auch nicht ändern.
Du siehst also, es gibt solche Probleme auch unter Windoooof und anderen Programmen
Was das Einfrieren des Systems verursacht, kann ich nur Spekulieren: Es scheint als würde die Serielle Schnittstelle beim beenden oder trennen, nicht wieder ordnungsgemäß geschlossen = was am Programm, Treiber oder am Linux liegen könnte? Beim trennen und wieder anschließen, wird ein Fehler ausgelöst der nicht sauber abgefangen wird und das System zum Absturz bringt "nicht schön, könnte aber möglich sein". Welche Linux Version ist das, eine ältere oder eine neuere und verwendest Du USB 2.0 oder 3.0 ?
Kommen wir zum Verfahren der Achsen "wie es in Octo ist?, daher hier am Beispiel von S3D: Die Z Achse hat sagen wir mal 140mm, hier ist 0 = ganz oben und 140 = ganz unten, das scheint ja zu stimmen.
Bei den Achsen X und Y hat man 150mm aber die beginnen nicht bei 0 bis 150 sondern NULL = MITTE, was bedeutet Du musst irgend wo -75 <-> +75 einstellen und bei Druckvolumen 150
Als nächstes hat man noch die Richtung nach HOMING, was den Endanschlag bedeutet, also beim WT150 ist das bei X und Y (links & hinten) und bei Z (unten) Im falle von S3D ist X = MINIMUM / Y = MINIMUM / Z = MAXIMUM
Jetzt kommen die Richtungen der Achsen, falls keiner der Motoren an den Anschlüssen vertauscht wurde "hat der Vorbesitzer was verändert?" wird nur Y bei S3D umgekehrt. Man kann das natürlich auch im GCode ändern und später mit GPX umwandeln, aber Komfort ist was anderes
Hast Du mal eine erzeugte GCode von Octo? Da kann man sehen wo der Fehler liegen kann, es reicht der erste Part bis der Druck beginnen müsste und ein zwei Zeilen vom eigentlichen Druck, also nicht den ganzen Code. Am besten hier als Text einfügen, das ich schneller als eine Datei