Erste Versuche mit Repetier-FW/Host und einige Probleme

n'Abend,

meine ersten Druckversuche laufen. Was die Druckergebnisse angeht bin ich für den Anfang sehr zufrieden. Probleme hab ich allerdings mit der Software bzw. der Verbindung oder oder Elektronik. Ich bin unsicher.

Setup:

- iMac mit Mac OSX 10.7.3
- Windows7 via VMWare
- USB-Verbindung zum RAMPS 1.4 auf Arduino Mega
- Repetier-Firmware
- Repetier-Host für Mac (alte und neue Alpha-Version) und für Windows

Beim 0.5thin wall testobjekt bin ich mit der Alpha-Version für den Mac gar nicht erst zum drucken gekommen - bereits beim versuch eines dry runs bleibt er drucker nach dem skirt stehen und hängt. Auch die Host-Software hängt dann (Beachball) und lässt sich nur noch abschiessen. - so sehr dass ich nur mit einem Mac-reboot und zahlreichen ramps-reboots wieder so weit gekommen bin dass er überhaupt wieder was tut (Home-Fahrt, etc.)

Danach Versuche mit er alten Mac-Version von Repetier-Host. Das hat grundsätzlich funktioniert. Allerdings blieb er gegen Ende des Drucks reproduzierbar (2 mal) an der gleichen stelle stehen - kurz vor Ende. Dort hing sich allerdings die Software des Clients nicht auf. Im Log waren zahlreiche "Resend"-Zeilen zu sehen. Da schwante mir, dass das Problem evtl. die serielle Kommunikation sein könnte. Auch hier half kein Board-Reset und kein Programm-Restart. Statt den Mac neu zu booten habe ich dann mal Windows in VMWare gebootet, den USB verbunden und Repetier-Host unter Windows gestartet. Siehe da, nach einem Board-Reset konnten die offenbar aufgestauten Befehle abgearbeitet werden und ich konnte anschließend in die Home-Position fahren. Anscheinend hängt sich auf dem Mac der USB->Serial-Treiber komplett auf. was er dann bei einem weiteren Drucktest unter Windows dort auch tat. Offenbar ein eklatantes Kommunikationsproblem, dass sogar den Treiber zum Absturz bringt.

Ist das ein bekanntes Problem? Kanns an meinem Setup liegen? Ich hab hier ein recht langes, aber sehr hochwertiges USB-Kabel, ein kürzeres werde ich gleich mal noch testen. Allerdings liegt es recht frei ohne große andere Kabel in der Nähe die irgendwie stören könnten meiner Meinung nach. Übertragungsgeschwindigkeit hab ich default auf 57600 gelassen. SD-Karte hab ich keine an Board - die könnte hier ja ggf. helfen oder?

Bin für jeden Tipp dankbar.

Grüße,
Frank

Da gibt es irgendwo eine Anmerkung zur Buffergröße in der Firmware bzw. Hostsoftware, die eventuell angepaßt werden muß.

Mit was für ein Quarz wird dein Board betrieben ?

Ich habe bei mir z.B. 20Mhz und mit 250000baud funktioniert die Kommunikation tadellos.

1-mal bearbeitet. Zuletzt am 25.02.12 15:14.

Hmm das ist ein Arduino Mega 1280 mit einem ATMega1280 der macht glaub ich 16 MHz. Ich probier testhalber mal eine langsamere Geschwindigkeit. Ich frag mich grad nur wo sich die wartenden Befehle ansammeln. Das klingt ja eher so als würde der Buffer voll laufen und die Abarbeitung ins Stocken geraten.... hmmmm.

Bei RAMPS musst du aufpassen, mit welcher Arduino version die Firmware kompiliert wurde. Bei 1.0 ist der Buffer nur 64 byte groß, bei älteren 128 byte. Das muss im Host korrekt eingetragen wein, sonst sind jede menge Resend-Anforderungen die Folge. Wenn du die Kommunikation testen willst, gibt es noch einen kleinen Trick. Vor dem eigentlichen Job

M111 S20

senden. Damit wird jede anfrage nach der Überprüfung direkt verworfen, so dass der Drucker nichts macht und nur die Kommunikation mit maximaler Geschwindigkeit getestet wird (Ausnahme neue M111 befehle um den Modus zu beenden, was auch passier wenn du z.b. Auf echo klickst). Die Übertragungsgeschwindigkeit würde ich auf 76800 oder 250000 setzen (bei 16 MHz) das ergibt die wenigsten Kommunikationsfehler. Genau genommen solltest du locker 1MB ohne ein einziges Resend rüberschaufeln können.

Das mit dem schweren Absturz ist schon komisch. Aber manchmal hatte ich schon Probleme mit meinem Mac. Auf einmal will er nicht mehr mit dem board reden, sowohl im Mac als auch unter Parallels Windows. Kabel raus/rein immer noch nicht. Und auf einmal kriegt er sich wieder ein als ob nie was war. Nur rebooten musste ich bisher nicht. Habe allerdings nach so einem problem mal den Treiber von FTDI für mac gezogen und neu installiert. Danach wollte er auch wieder.

Ich würde vorschlagen erst wie oben beschrieben testen ob du eine Fehlerfreie Kommunikation hinbekommst. Danach dann im Dry Run mode neu testen wenn es sonst klappt.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Hey Repetier,

danke für die Hinweise. Das klingt plausibel - werde das gleich mal alles überprüfen. Hab mal das kurze Kabel zwischenzeitlich getestet. Damit konnte ich auf der alten Software schon mal ein objekt fertig drucken und bei der neuen hat er sich kurz vor Schluß aufgehangen. Mal sehen....

Es sieht tatsächlich so aus als wären die FTDI Treiber das Problem und zumindest die Ursache für die Abstürze. Die neueste Version ist leider auch schon ein Jahr alt und nicht für Lion gemacht. Beim Versuch den Treiber zu installieren bleibt er nun bei der INstallation hängen - offensichtlich scheitert er am hängenden Treiber im Speicher.

Ok, der Buffer wars - danke für den Tipp. Ich hätte aber auch mal die Zeile unter der Einstellung lesen können :-S

Jetzt scheint's zu klappen. Morgen nochmal ausgiebiger testen...

Hatte den selben Fall.
Hat man Ruinen Nachteil mit dem geringeren Puffer?

Schönen Gruß

Die Nachteile halten sich in engen grenzen. Der Host benutzt den Puffer zur Datenübertragung und gleichzeitig als Puffer um mehr Befehle gleichzeitig übertragen zu können. Da der Drucker für gewöhnlich langsamer ist und mit weiteren Puffern arbeiten ist daher kein echter Nachteil zu erwarten. Das einzige was nicht möglich ist, sind befehle mit mehr als 62 Zeichen pro Zeile. Das wäre bereits ein Problem wenn der Host die Kommentare nicht entfernen würde, aber so scheinen bisher alle Befehle zu passen.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!

Ab okay dann mach ich mit der 1er Version von Arduino erstmal weiter solange es funktioniert.

Dankeschön