Beitrag #99 von Zaldo » Di 17. Nov 2015, 17:48
Das ist schon richtig, aber ich glaube halt nicht so recht daran, das das Problem auf dem USB Bus entsteht, da es ja grundsätzlich möglich ist fehlerfrei zu drucken (mit einer anderen Software). Nur die Software kommuniziert ja nicht direkt mit dem USB Port, sondern mit dem FTDI Treiber, der einen virtuellen COM Port über den USB bereitstellt.
Ich glaube man muss sich das räumlich etwas anderes vorstellen. Das Prinzip hier ist exakt dasselbe, wie wenn man einen der handlsüblichen USB-RS232 Adapter verwendet, nur mit dem Unterschied dass der UART nicht direkt hinter dem USB Stecker ist, sondern in den Drucker ausgelagert ist. Der 2560 im Drucker versteht in Wahrheit ja nur RS232. Man muss sich also den Drucker eher als einen Drucker mit RS232 Schnittstelle vorstellen, welcher mit einem solchen USB-RS232 Adapter am Drucker angeschlossen ist.
Kommunikationseinstellungen im Treiber (wie die Baudrate) betreffen demnach also auch garnicht den USB Bus, sondern sagen dem UART, wie er sich auf der RS232 Seite zu verhalten hat. Timingprobleme auf dem USB Bus dürften somit außen vor sein (oder müssten unabhängig von der verwendeten Software auftreten).
Warum es dann bei 9600 Baud funktioniert hat? Keine Ahnung. Zufall? Glück gehabt? Ich denke, ohne einen USB Sniffer wird man hier nicht weiterkommen, und auch der wird m.E. nur zutage fördern, dass bereits auf dem USB Bus die falschen Kommandos übertragen werden.
· Besserer Z-Referenzschalter · Druckbett Feinjustage · Platinenkühlung · Weiße Bauraumbeleuchtung · Not-Aus
· Dauerdruckplatte · Temperaturgeregelte Einhausung · Repetier Server auf Raspberry · MK8 Vorschubritzel