Simplify3D - Übertragungsfehler?

[Zaldo]

Ich habe das schon verstanden Ralf, aber ich glaube (meine persönliche Meinung) das die Firmware (alleine) nicht der Grund für das Problem sein kann. Und zwar aus dem Grund bzw. dem gleichen gemeinsammen Nenner, auf den immer wieder alles rückführbar ist: Mit Repetier geht es! Es muß also irgendwas, was auch immer, noch mit in diese ganze Geschichte einspielen. Die Software versendet immer genau diese Zeichenfolgen, die Du im Machine Control Window von S3D sehen kannst. Wenn also Repetier die Zeile "G1 X84.72 Y86.48 E7.7288" sendet, dann sendet S3D die Zeile ebenso. Es ergibt schlichtweg keinen Sinn, warum es (alleine) Firmwareabhängig sein soll, dass der Drucker immer nur dann "G84" versteht, wenn S3D die Zeile "G1 X84.72 Y86.48 E7.7288" abgeschickt hat (Die Befehle sind natürlich ein exemplarisches Beispiel.)

@RF1000: Mal ne Überlegung. Die Firmware plappert doch auch in die Gegenrichtung. Hat sich da seit der .34 vielleicht was geändert? Wobei das abschalten der Statusmeldungen in der Configuration.h hatte auch nichts gebracht. Gibts da vielleicht noch mehr, was wir nicht auf dem Schirm haben? Dass das Problem vielleicht erst bei einer bestimmten Konstellation von Senden und Empfangen auftritt?

[Zaldo]

Noch etwas was mir gerade in den Sinn kommt: Ich habe jetzt auf meinem (XP) Rechner nur einen FTDI Treiber in der Version 2.8.30.0 gefunden. Ein Versuch wäre vielleicht mal den aktuellen Treiber direkt von FTDI runterzuladen, und den virtuellen COM Port damit neu zu installieren. Vielleicht ist ja jemand so mutig (Ich hab ja selber kein S3D mehr)

[RF1000]

Hallo Zaldo,


wann man Repetier-spezifische Kommunikation möglichst ausschließen möchte dann kann man in der V 0.91.59 den Wert von ALLOW_EXTENDED_COMMUNICATION auf 0 setzen - damit wird von der Firmware dann nur noch das Notwendigste gesendet.
Wobei es mir nicht ganz schlüssig erscheint, dass Kommunikation in die eine Richtung (Firmware -> PC) Bits bei der Kommunikation in die andere Richtung (PC -> Firmware) kippen soll.

3D-Doodler:

Ich bin hier vielleicht der einzige, der längere Zeit (knapp 3 Wochen) mit S3D und dem RF1000 mit 250000 Baud ausschließlich über USB über jeweils mehrere Stunden problemlos gedruckt hat. Das war allerdings mit der Firmware 0.91.34.

druckttoll hat hier http://www.rf1000.de/forum/slicer-softw ... rt=70#8782 ... rt=70#8782 mit S3D fehlerfrei gedruckt, nachdem er die USB Hardware im PC getauscht hat. Vor dem Tausch der USB Hardware hat das Drucken mit S3D ja nicht geklappt. In dem Beitrag steht leider nicht, welche Baudrate verwendet worden ist und welche Version der Firmware das war. druckttoll, kannst du das vielleicht noch nachreichen?
Hier http://www.rf1000.de/forum/slicer-softw ... rt=80#8930 ... rt=80#8930 hat es dann angefangen bei druckttoll nicht mehr zu funktionieren, nachdem das Betriebssystem aktualisiert worden ist. Soweit ich das verstanden habe war die Firmware von schlecht (altes Windows, USB intern) auf gut (altes Windows, USB extern) und zurück auf schlecht (neues Windows, USB extern) immer die gleiche.

Vor allem wegen deiner Beobachtung kann man daher zwar davon ausgehen, dass die Firmware irgendwie an dem Verhalten beteiligt ist, aber evtl. kann das Verhalten nicht nur durch die Firmware gelöst werden. Was spricht dagegen, dass du (3D-Doodler) einmal einen Druck mit S3D und 115.200 statt 250.000 Baud machst?


mfG
RF1000

[3D-Doodler]

Hallo RF1000,

gesagt, getan. Ich habe das gerade mal mit 115.200 Baud probiert. Im 2. Layer ist der Extruder dann nach knapp 3 Minuten nach y min gefahren, fuhr wieder in die alte Position zurück und wollte dann dort den Druck fortsetzen. Damit geht es also auch nicht.+

Gruß, Ralf

[druckttoll]

Blub, wieder aufgetaucht ...

Hi there!

Die Frage nach Baudrate und Firmwareversion: 250000 und 0.91.59

Da es mit Repetier Host und der Arduino IDE bisher NIE Probleme gab, liegt der Verdacht sehr nahe, dass die Kollegen von S3D Code verwenden, der noch Verbesserungspotential hat.
Das Thema Baudrate und Firmwareversion habe ich auch in diversen Variationen getestet. Das Ergebnis war stets zwisch keine, oder immerhin eine gefühlte Verbesserung.
Was definitiv etwas Verbesserung bringt - auch unter Windows 10 - ist die Wartezeit für den COM-Port etwas zu verringern:

Geräte-Manager / Anschlüsse (COM & LPT) / USB Serial Port (COM x) / Eigenschaften von ... / Anschlusseinstellungen / Erweitert... / BM Einstellungen / Wartezeit: 8 ms (statt 16)

Mit diese Einstellung klappen dann auch Probeausdrucke von einer Stunde. Längere Druckjobs mache ich nur noch von SD-Card.

Ciao for now
druckttoll

[3D-Doodler]

Da es mit Repetier Host und der Arduino IDE bisher NIE Probleme gab, liegt der Verdacht sehr nahe, dass die Kollegen von S3D Code verwenden, der noch Verbesserungspotential hat.

Der Verdacht liegt so gesehen schon nahe. Aber warum funktioniert das denn mit der FW 0.91.34 immer ohne Probleme?

Gruß, Ralf

[druckttoll]

Hallo Ralf,

das ist eine berechtigte Frage, die möglicherweise RF1000 beantworten könnte. Ich kann mangels der erforderlichen Programmierkenntnisse nicht feststellen, ob in den späteren Versionen andere Routinen für die Kommunikation verwendet werden. Oder ob etwas anderes die Kommunikation beeinträchtigt.
Und, Repetier Host so wie die Arduino IDE haben keine Probleme; bei mir zumindest nicht. Auch mit der aktuellsten Firmware.

Vermutlich tritt das Problem nur bei wenigen Anwendern auf, weshalb der Leidensdruck bei den Herstellern nicht so groß, oder sogar gar nicht vorhanden ist.
Ich befürchte wir dürfen uns damit arangieren und hoffen, dass sich das Thema irgendwann mit einem Update erledigt. Oder mit einem anderen PC. Oder einem anderen Drucker.

Ja, schade! Stimmt!

Ciao for now
druckttoll

[Zaldo]

Vermutlich tritt das Problem nur bei wenigen Anwendern auf, weshalb der Leidensdruck bei den Herstellern nicht so groß, oder sogar gar nicht vorhanden ist.

In Anbetracht der Tatsache, dass der Hersteller bei jedem, der dieses Problem bei ihm meldet so tut, als sei er der allerallererste, der jemals von diesem Problem berichtet hätte (während wir im Forum ja wissen, dass es nicht so ist) würde ich eher annehmen, man versucht jedem weißzumachen das es an seiner Hardware hängt und selbstverständlich nicht am Produkt. Ich habe selber schon im Helpdesk gearbeitet und weiß wie es ist. "Nein, Sie sind der allererste, der so ein Problem hat, und glauben Sie mir, ich sitze ja hier an allererster Front, ich würde als einer der ersten wissen, wenn Probleme dieser Art gehäuft auftreten würden...." Kraaaaaaaatz, nächste Kerbe im Tisch...

[RF1000]

Hallo Zaldo,


ich denke, dass wir beim Thema und konstruktiv bleiben müssen wenn wir bei diesem Thema weiterkommen wollen.

In Anbetracht der Tatsache, dass der Hersteller bei jedem, der dieses Problem bei ihm meldet so tut, als sei er der allerallererste, der jemals von diesem Problem berichtet hätte (während wir im Forum ja wissen, dass es nicht so ist) ...

Vielleicht weißt du da mehr als ich und vielleicht kann uns da eine kurze Umfrage helfen:

1) Wer alles hat den Zustand, dass es überhaupt Kommunikationsprobleme zwischen PC und Firmware gibt?
2) Bei wem treten Kommunikationsprobleme mit S3D auf?
2.1) Welche Version von S3D wurde da verwendet?
2.2) Welche Version des FTDI Treibers wurde da verwendet?
3) Bei wem treten Kommunikationsprobleme mit dem Repetier-Host auf?
4) Bei wem treten Kommunikationsprobleme mit dem Raspberry Pi auf?
5) Bei wem sind die Kommunikationsprobleme abhängig von der Version der Firmware?
6) Ist das Verhalten gleich, egal ob ALLOW_EXTENDED_COMMUNICATION auf 0 oder 2 steht?
7) Ist das Verhalten gleich, egal ob FEATURE_HEAT_BED_Z_COMPENSATION auf 0 oder 1 steht?
8 ) Wer hat bisher keinerlei Kommunikationsprobleme mit S3D festgestellt?

Soweit mir bisher bekannt ist gilt (diese Liste wäre bitte von den jeweils betroffenen zu ergänzen bzw. zu korrigieren, falls ich mich vertan habe):
1) druckttoll, MrMmmKay, Oo, Cyco, Zaldo, delta_2000, F22-Raptor, Ande, 3D-Doodler, JoBo
2) druckttoll, MrMmmKay, Zaldo, delta_2000, F22-Raptor, Ande, 3D-Doodler, JoBo
3) Oo, Cyco (siehe http://rf1000.de/forum/slicer-software/ ... uf-0-91-48 ... uf-0-91-48, wobei es da seit 10 Monaten kein Update gibt wie es mit der aktuellen Firmware aussieht)
4) druckttoll
5) 3D-Doodler (V 0.91.34 klappt mit S3D, V 0.91.48 und höher nicht)
6) Diesen von mir vor 6 Wochen vorgeschlagenen Test und vor einer Woche noch einmal wiederholten Test hat leider noch kein Betroffener ausprobiert.
7) 3D-Doodler hat ein verbessertes Verhalten wenn die Z-Kompensation aus ist, aber ganz weg sind die Kommunikationsfehler auch damit nicht.
8 ) Diese Art von Information gibt es in den Beiträgen in der Regel nicht (Ausnahmen wären z.B. RAU und Digibike (der allerdings mit einer modifizierten V 0.91.48 für seinen Dual-Extruder)), sie würde uns an dieser Stelle aber trotzdem helfen.

Zusatzfragen und Anmerkungen:
A) Für 2): Treten wirklich keine Kommunikationsprobleme mit dem Repetier-Host auf oder werden die nur besser behandelt, z.B. weil der Repetier-Host das betroffene Kommando erneut sendet?
B ) Hat jemand Kommunikationsprobleme festgestellt und diese anschließend gelöst bekommen? Falls ja - wie (also z.B. durch Änderung der Baudrate, durch Änderungen in der Configuration.h, durch Änderungen am Betriebssystem, ...)?
B.1) Zaldo scheint mit einer Baudrate von 9600 Baud erfolgreich gewesen zu sein.
B.2) druckttoll hatte mit einem zusätzlich gesteckten USB 3.0 Kontroller kurzfristigen Erfolg (bis zum nächsten Update von Windows, ab da waren die Kommunikationsprobleme wieder zurück).
B.3) druckttoll hat die Kommunikationsprobleme wieder wegbekommen, indem er die Wartezeit von "Geräte-Manager / Anschlüsse (COM & LPT) / USB Serial Port (COM x) / Eigenschaften von ... / Anschlusseinstellungen / Erweitert... / BM Einstellungen" von 16 auf 8 ms verringert hat.
C) Zaldo beschreibt, dass der RF1000 Bewegungen ausführt die nicht im G-Code enthalten sind. Das sollte im Grunde nicht möglich sein, wenn der PC die Kommandos mit Prüfsumme sendet. Wenn die Kommandos ohne Prüfsumme gesendet werden wäre das aber theoretisch möglich - unter der Voraussetzung, dass die Kommunikation auf der Verbindung PC->RF1000 tatsächlich gestört wird und dadurch Bits umfallen.
D) Ich habe vor ca. 2 Wochen (siehe http://www.rf1000.de/forum/slicer-softw ... rt=60#8742 ... rt=60#8742) schon mal versucht, mehr Informationen zu bekommen. Gemeldet haben sich daraufhin Zaldo und 3D-Doodler, allerdings nicht mit neuen Informationen. Vielleicht zeigt unsere kleine Umfrage ja, wer konkret aktuell noch von diesem Verhalten betroffen ist.
E) DigiBike hat vorgeschlagen, dass 3D-Doodler seine modifizierte V 0.91.48-Dual ausprobiert um zu prüfen, ob er damit auch Kommunikationsprobleme hat. Wurde das gemacht?

Fazit:
- Wenn es einen Hinweis darauf gäbe, dass die Firmware etwas gegen die beobachteten Kommunikationsprobleme tun könnte dann würden wir sehr gerne dagegen vorgehen. Im Moment ist aber noch kein Muster erkennbar, warum manche Anwender dieses Kommunikationsproblem haben und andere nicht. Da wir den Fehler bei uns nicht reproduzieren können sind wir alle auf die konstruktive Mithilfe der Betroffenen angewiesen, um weiter zu kommen.
- Wir kratzen keine Kerben in den Tisch. Wir sind hier weil wir euch unterstützen wollen. Wir könnten uns auch ganz einfach zurücklehnen und alles auf S3D schieben und euch damit alleine lassen, weil es ja erwiesenermaßen mit der Standardsoftware keine Probleme gibt. Tun wir aber nicht. Ich erwarte mir dafür keine Dankbarkeit oder Anerkennung weil schließlich soll der RF1000 ja einfach funktionieren, aber Bashing bringt uns auch nicht weiter.
- Ich schlage daher vor, dass jeder der zu den obigen Punkten hilfreiche Anmerkungen hat diese auch hier postet. Jeder, der die Kommunikationsprobleme hat kann auch prüfen, ob die Ansätze B.1, B.2 oder B.3 bei Ihm ebenfalls die Kommunikationsprobleme beseitigen.
- Es wäre auch hilfreich zu erfahren, wer mit S3D keinerlei Kommunikationsprobleme hat.
- Ideal wäre, wenn bei jeder Information genau dabei stehen würde welche Version der Firmware, des PC Programms und FTDI Treibers jeweils im Einsatz war.


mfG
RF1000

[Zaldo]

@RF1000: Ich meinte nicht das *IHR* Kerben in den Tisch kratzt, ich sprach vom S3D Hersteller, genaugenommen dessen Support, der offensichtlich immer wieder so tut als kennt er dieses Problem nicht.

Zu 2.2: FTDI Treiber war 2.8.28.0 oder 2.8.30.0 (sind beide installiert aber der Drucker hängt nicht mehr am PC, daher sehe ich nicht mehr welcher aktiv war)

Zu 6. Ich hatte ALLOW_EXTENDED_COMMUNICATION und auch ACK_WITH_LINENUMBER ausprobiert, hatte keinerlei Einfluss (hatte ich probiert und auch geschrieben)

Zu A) und C) Ich hatte bereits angemerkt, Wenn die Kommunikation zwischen Anwendung und Treiber nicht klappt, dann würde der Treiber einen falschen Befehl über die Schnittstelle senden, die Prüfsumme wäre aber korrekt, da sie für den falschen Befehl gebildet würde. Der Drucker würde demnach gar kein Resend anfordern, weil er den erhaltenen Befehl für korrekt hält. Ob er auch einen Sinn ergibt bewertet ja der Drucker nicht.

Zum Fazit: Ich hatte ja auch mal angeregt den aktuellen FTDI Treiber zu verwenden (Laut Changelog wurden durchaus Kommunikationsprobleme mit der 2.8.30.0 behandelt, ich weiß wie gesagt nicht welche Treiberversion Repetier Host installiert und verwendet hat, die .28 oder .30). Da ich kein S3D mehr habe, kann ich es selber leider nicht ausprobieren, und da keiner was geschrieben hat, hat es wohl auch niemand ausprobiert.