Hallo,
dieses Problem ist bekannt und wurde bereits an die Entwickler weitergegeben.
In einer früheren Firmware Version trat es ebenfalls auf, dass der Drucker stehen blieb
und nicht mehr reagierte.
Dies konnte ich damals nachvollziehen und es wurde behoben.
Damals trat es auf, wenn man mit 60% Geschwindigkeit gedruckt hat.
Nach dem Update der Firmware konnte ich es nicht mehr nachvollziehen.
Offenbar gibt es das Problem aber immer noch, hatte hier 2 Kundengeräte die zumindest sporadisch diesen Fehler hatten.

Bitte schick mir mal die Datei (STL und gcode) die Du drucken willst und die Slicer Einstellungen.
Ich werde es dann weiterleiten, danke.

PS: Das uns bekannte Problem mit "Knubbel" tritt bei Kreisen auf da der Drucker hier viele kleine Geraden
drucken muss (wird vom Slic3r so erzeugt). Das Problem kann man lösen wenn man die Geschwindigkeit der Wände
auf 30mm/s reduziert.

MfG

Danke!

Der schnelle Testfall, da Fehler ihn erster Lage:

Gcode:

Gekürzter Gcode, der Fehler tritt auf, wenn der erste Perimeter gefahren wird, nach den Kreisen:
http://www.rf1000.de/download/file.php?id=4060
Volle Länge:
http://www.rf1000.de/download/file.php?id=4059
in Kombination mit Speed-Multiply = 100%, sonst nicht.

Bei der STL und den Settings gibts ein kleines Problem:
Als der Fehler nach einer Änderung auftrat und ich garnichts zuordnen konnte, habe ich die Änderungen verworfen. Ich war in Zeitnot und das Teil sollte gedruckt sein.
Was ich noch sicher weiß, ist die Geschwindigkeit von 50mm/s.
Möglich ist:

1) Perimeter = 50mm/s,
oder
Autospeed (advanced) -> Max print speed = 50 && Perimeters = 0

2) First Layer speed = 40% oder 50% (sehr wahrscheinlich), 70% weniger wahrscheinlich. (Fehler in first Layer!)

3) Druck mit nur Extruder 0, Extruder rechts nicht aufgeheizt.

4) Profil für PLA_0,2mm oder PLA 0.2mm_10Brim

Die STL wurde ebenfalls mit einigen Updates verändert. Macht es noch sinn, die zu schicken?

Hier der zweite Versuch: Der Staubsaugeradapter.

Dort trat das Problem bei 45mm/s und vermutlich bei diesen aktuellen Profilen auf.
Irgendwo bei Layer 385/501 (Laut Repetierserver, heißt im Bereich +-1). Ich hatte das in einem Video erwähnt genau nachdem es zum zweiten Mal an vermutlich derselben Stelle auftrat (https://www.youtube.com/watch?v=8MjBQ1T76fs).

Hier ist die Playlist aller komischer Fehler. Wenn ich diese Videos löschen kann, einfach melden
https://www.youtube.com/playlist?list=P ... ugMoisASm_

Meine Vermutung: Da ich mit "Autospeed" unter Angabe eines Maximums experimentiert hatte, kann es gut sein, dass schädliche Geschwindigkeiten rein statistisch irgendwo auftreten.

LG

Das Problem mit dem Absturz sollte
http://www.rf1000.de/viewtopic.php?f=7&t=1610
mit Firmware-Version 1.35 behoben sein. Mehr Tests stehen bei mir aber noch aus.


Um den Suchenden hier im Forum eine Antwort auf die Originalfrage zu geben:
Firmware:

HAL.h hat geschrieben:[...]
#define SERIAL_RX_BUFFER_SIZE 128
#define SERIAL_RX_BUFFER_MASK 127
#define SERIAL_TX_BUFFER_SIZE 64
#define SERIAL_TX_BUFFER_MASK 63
[...]

LG

Wenn ich im RepetierServer
Drucker -> Druckereinstellungen -> Allgemein

"Größe Eingangspuffer" = 63 einstelle
und den MCode mit mehr als 63 Zeichen sende, bricht die Kommunikation zusammen.

"Missing ok ... resend"
usw.

Besser scheint die Einstellung 127 zu sein.
"Größe Eingangspuffer" = 127

In der Firmware steht auch:
#define MAX_CMD_SIZE 128
#define SERIAL_RX_BUFFER_SIZE 128
(usw.)
Hinweis: In der originalen Repetier ist MAX_CMD_SIZE auf 96 festgestellt. https://github.com/repetier/Repetier-Fi ... code.h#L21
Der RX-Puffer ist dort gleich wie bei uns.

Seit ich RepetierServer auf 127 Bytes eingestellt habe, crashed das nicht mehr. Ich kann (glaube ich) so lange Befehle senden, wie ich will
Evtl. könnte das auch ein Fix für die Personen sein, die mit Simplify3D nicht ganz gut zurechtkommen. Das ganze kann aber auch einfach am RepetierServer liegen!

LG