Eine kleine Log für alle, die es interessiert, aber hauptsächlich für mich selbst als Merkhilfe

Ich hab nochmal große teile des GCode-Seriell-Lese-Codes abgeglichen und mir ist kaum noch was aufgefallen.
Übertragungs-Fehlerbehandlungen waren bei uns noch leicht anders als im aktuellen Repetier.
Der ASCII-Lese-Code war anders, aber soweit ich weiß nutzen wir den nicht. Ich habe den Abgleich in meine persönliche Development übernommen und drucke aktuell damit. (V 1.38.12.Mod oder später)

Das waren so Patches, die man eigentlich nicht zwingend übernehmen müsste, aber meine Einstellung ist, dass mehr Nähe zur aktuellsten Repetier-Firmware grundsätzlich Fehlersuche vereinfacht.
Ich kann somit Sachen reparieren, die mir selbst nie aufgefallen wären, die aber irgendwer aus irgendeinem Land dieser Welt an Repetier meldet.

Repetier hat noch einen zweiten Code der aktiviert wird wenn man NEW_COMMUNICATION aktiviert. Der Hauptaugenmerk liegt aber wohl auf einer globalen IO-Schnittstelle, die nicht rein auf serielle Kommunikation angewiesen ist. Quasi eine Abstraktion.

Die Sache mit dem MOVE_CACHE sieht man auch hier beim Repetier-Konfigurator:
Unter Umständen löst das unsere Probleme? Wessix hat mir gestern nochmal erzählt, was ich schon mal wusste.
Wenn der PC an dem gedruckt wurde etwas zu langsam ist, kann das auf den Druck ebenfalls eine Wirkung haben. Er sprach von seinem Raspberry PI 1, der mehr Probleme gemacht hatte wie der Raspberry PI 3.
Eigentlich müsste man nun knallhart hingehen, einen Raspberry PI 3 kaufen, eine SD-Karte dazu, mein System klonen und AtlonXP zwingen von nun an damit zu arbeiten zu prüfen, obs dann funktioniert. Geht damit das was vorher nicht ging, dann ist die Kommunikation nicht wirklich unser Problem.

Es gibt noch eine Sache, die man als Rotteln oder Stottern interpretieren könnte, was aber in dem Fall nicht so ist: ADVANCE! Der Extruder hört sich dann teilweise stotternd an, weil er mit dem Filament weit zackiger umgeht, als ohne ADVANCE.

LG

Nochmal ich:

Das ausbremsen bei kleinerem Cache ist tatsächlich schon eingebaut:
(BeispielLinks zeigen auf die 1.37/1.38 Conrad Firmware)
https://github.com/RF1000/Repetier-Firm ... 000.h#L893
Dieser Wert stellt umgerechnet die minimale Zeit dar, die ein Pfadstück im Cache verbrauchen muss, sodass dieser nie leer läuft.

Mit diesem Wert wird die jeweils aktuelle Feedrate manipuliert, also verkleinert.
https://github.com/RF1000/Repetier-Firm ... n.cpp#L389 Wir im Mod haben den Wert von 400000 auf 250000 angepasst. (Conrad hatte den Wert normalerweise auf 400000!)
Grund fürs Senken: Weil Repetier das auch so um-/eingestellt hat.

Der Code selbst hat sich bezüglich dieser Sache in den letzten Jahren kaum geändert.
Zwei Vorschläge gegen stockenden Druck:

RFx000.h: #define LOW_TICKS_PER_MOVE 250000 erhöhen!
RFx000.h: #define MOVE_CACHE_LOW 10 testen, ob 11, 12, 13, 14 als Wert eine Verbesserung bringt.

-------------------


Das alles was ich nun recherchiert habe, begrenzt diese Sache mit dem Stocken auf dieses Ausschlussverfahren:

- Prüfen ob von SD die fehler nicht auftauchen. Wenn doch, ist der Hund tiefer begraben.
- Prüfen, ob die Log von Verbindungsfehlern oder "Resend: " sauber ist.
- Sicherstellen, dass Advance nicht die Rottel-Töne macht, die man für Stocken hält.
- Prüfen ob ein anderer PC (/alternatives USB-B-Kabel zum Drucker, mit/ohne Hub) eine Verbesserung bringt.
- Prüfen ob STEP_DOUBLE_FREQUENCY korrekt eingestellt ist (Neuere Versionen vom Mod/Conrad 1.39 sind ok).
- Prüfen ob LOW_TICKS_PER_MOVE MOVE_CACHE_LOW mit anderen Werten eine Verbesserung bringt (Wenn Bug in Serieller Kommunikation)

Damit lasse ich euch alleine, bis ich vom Thema wieder was höre

LG

Danke Nibbels,

dass sind die Infos wo ich für wichtig halte.
Ich habe als erstes an meiner Laptop Gurke die USB Stecker anders verteilt.

Ich weis nicht wie intern an dem Ding die USB Anschlüsse verdrahtet sind.
Ich sage dazu: Wehe wenn ein USB Port intern geteilt wird!

Im Moment surfe und schreibe ich hier und es druckt problemlos (einfache Teile mit wenig Radien),
das Log wird mit geschrieben und das Word ist 2 x offen.
Einen MPG Video habe ich vorhin auch noch angeschaut.

Mein Mainbord Chipsatz im Laptop ist ein nForce und dieser ist bekannt für unterirdische Datenübertragung.

Meine CPU ist eine Core 2 Duo mit 2.0 Mhz.
Die sollte jeden Raspberry in den schatten stellen.

Mein moniertes Problem war ein wirkliches stehen bleiben des Druckers, gefühlte 5 sec. lang und kein leichtes Stocken,

Vielen Danke hier erst mal, ich werde hier weiter berichten.

LG AtlonXP

Hallo zusammen,
hier ein kleines Resümee über das bereits Geschriebene.

Meine Schlepptop CPU hat natürlich 2,0 GHz, das war ein Fehlerteufel.
Seit dem ich meine USB Stecker anders verteilt habe, sind bis jetzt keine Probleme mehr aufgetreten.

Von hier:
Flow Control mit dem Faktor mal 10 mehr, halte ich für einen guten Kompromiss.

Wem die Geschwindigkeitsrücknahme zu viel sein sollte, der kann sich den einprozentigen Bereich auswählen.
(10% entspricht nun 1% nach der neuen Einstellung).

Bei den Test Drucken von dem schlecht verarbeitbaren PETG, da war ich froh etwas mehr Gas zurück zu nehmen zu können.
Meine Überlegung:
Zuerst mehr Geschwindigkeit weg, bevor die geförderte Materialmenge zu stark reduziert wird.
Wenn dies nicht mehr funktioniert, ist der Druck sowieso im Eimer.

LG AtlonXP

Es gibt mit der Firmware 1.38.21.Mod
einige Neuerungen, die ich hier erwähnen will:

1) Die Aktivierung von SenseOffset reiht sich nun sauber in den Move-Cache ein. Das heißt, sie arbeitet so wie die Aktivierung der Z-Kompensation. Ohne, dass intern (oder im Startcode) mit diesem "M400" getrickst bzw. gemurkst werden muss.
Ich kann nun nach weiteren bisher suboptimal gelösten Anwendungsfällen suchen, die diesen Fix auch brauchen, da ich verstanden habe, warum das gut ist.

2) Ich habe herausgefunden, wie ich die Druckgeschwindigkeit live beeinflussen kann. (Viel reaktiver als durch Feedrate-Einstellung im Menü)
Dadurch kann der Geschwindigkeits-Teil von AtlonXP's Digit-Flow-CMP nun exakt regeln. Das System reagiert demnach unabhängig von den Pfadstücken im Cache, selbst wenn man ein Viereck im Vase-Mode druckt.
Mit dieser Technik kann man auch dieses Problem hier http://www.rf1000.de/viewtopic.php?f=24 ... ate#p17572 lösen.
Das hilft extrem bei Punkt 3:

3) Der Firmware-Mod wird von nun an automatische Startmaden unterstützen. Diese Startmaden haben einige Vorteile, die ich bereits nach 3 Tests nicht mehr missen will:

• Ein einziger Startmaden-GCode für fast alle Materialien im Startcode - das reicht.
• Die Geschwindigkeit während der Startmade bremst automatisch ab, wenn die Digits zu hoch werden. Das verhindert Probleme:
• -> Keine Flex Ausbrüche mehr.
• -> Kein Überdruck (mit bleibend hohen Digits) in Full-Metal-Hotends bei zu dicken/schnellen Startmaden mit z.B. PETG
• Nie mehr rumprobieren mit G92 E0, M400, Startmadenlänge, usw.
• Die Auto-Startmade kennst die Länge der X-Achse des Druckers aus dem EEPROM.
• Der Drucker weiß, dass gerade die Startmade gedruckt wird und schließt SenseOffset sauber aus.
• Es wird in jedem Fall die Standard-0.35er Z-Höhe verwendet (bzw.: AUTOADJUST_STARTMADEN_AUSSCHLUSS aus RFx000.h).

Der GCode funktioniert in seiner ersten Version ab 01.38.21 und hat aktuell folgende optionale Schalter:
M3912
+ I2 für 2 Linien [1..5]
+ F18 für max. 18mm/s [5..50]
+ E20 für die Extrusionsmenge [10..30
+ S1500 und P4500 für den Digit-Bereich in dem abgebremst wird. (das ist dasselbe wie beim Digit-Flow-CMP)

Kurz - mein Simplify3D-Startcode sieht nun so aus und funktioniert: (Temperaturen braucht Simplify3D nicht, Slic3r evtl schon. / M84 und G90 fügt Simplify3D ebenfalls selbst ein.)

LG

Hallo Nibbels,
das hört sich gut an.

Die Höhe der Startmade sollte jedoch aus folgendem Grund weiter beeinflussbar bleiben.
Eine 0,2 mm Düse ist mit deiner Standart Höhe überfordert.
Irgendwann werde ich noch kleiner Düsen benutzen.
Ich persönlich habe nicht immer die beste Haftung im Startmadenbereich, da hier schon mehrfach ohne Nachbesserung meiner ABS Beschichtung überdruckt wurde.
Einfach gesagt, ich brauche eine gewisse Menge Anpressdruck.
0,28 mm Madenhöhe haben sich bei mir bewährt, auch mit einer 0,2mm Düse.

LG AtlonXP

Stell das einfach in deiner RF1000.h ein, wie du es brauchst!
Die Definition heißt: Quelle: https://github.com/Nibbels/Repetier-Fir ... 000.h#L983

Wenn du dort die Startmade von 0.35mm auf deine 0.28mm umstellst hast du sowohl die Auto-Startmade auf der Höhe und die Erkennung der ersten Lage durch die Mod-Firmware schießt diese auch automatisch Höhe aus. Wähle also nicht 0.20 oder sonstige "bekannte erste Layerhöhen", sondern schön krumme Höhen wie 0.28 oder 0.2789mm.

Wenn du mir die Auto-Startmade mal testest und optimierst, höre ich mir gerne von dein Ergebnis an
Für mich hat 0.35 immer funktioniert - das scheint DAS Standardmaß zu sein. Doch manchmal kann man seine Made damit "nur langsam" drucken, wenn das Material in der Düse schwergängig ist.
Du brauchst für den Startmadencode sowohl G28 als auch M3001, also ein aktiviertes Homing und zCMP!

LG

Video von der automatischen Startmade:


https://www.youtube.com/watch?v=eYBnGFlT1bA

Das ist der Code für genau diese Startmade:

G28 ; home all axes
M3001 ; activate Z-Compensation
M3909 ; activate SensiblePressure
M3912 I2 E20 ; Startmade

Das Digit-Flow-CMP funktioniert jetzt genau gleich gut - aber nur der Teil, der die Geschwindigkeit regelt.
Ich schalte im Grunde intern während der Startmade Digit-Flow-CMP mit angepassten Einstellungen an und anschließend wieder aus.
Beim Filament-Flow besteht noch das Problem, dass die Änderung des Flows eine Verzögerung in der Länge des Move-Cache besitzt. Ich finde die Flow-Anpassung im Normalfall aber sowieso nicht die beste Idee (Ausser der Slicer verrechnet sich im Vollmaterial und Perimeterschönheit ist egal).

LG

Hallo,
die gelegentlichen Aussetzer nerven langsam.

Das Drucken über SD Karte funktioniert ohne Probleme.
Für mich sieht es so aus, als ob mein Schlepptop manchmal hackt,
so wie auch der Pufferspeicher im Drucker etwas vergrößert werden sollte.

Oder kann ich mir das Sparen, wenn der Drucker dieses mit der SD Karte problemlos packt?

Konkret: Bei einem zusätzlichen öffnen einer Rechenintensiven Anwendung bleibt der Drucker kurz stehen.

Bei filigranen Drucken mit vielen Rundungen ist es auch sehr merklich.
Da ist es sogar geschwindigkeitsabhängig. (Mein Beöler zum Beispiel).

Zu Übertragungsfehlern, da kann ich nur sagen:
Es werden keine Error Meldungen im Log geschrieben.

Dies mag auch an den Einstellungen liegen.
Ich weiß dass, weil ich einen Übertragungsfehler provoziert habe!
Ich hatte einfach den RF1000 mit 250 000 Baut betrieben.
Der Finger war immer am Stecker!

Der Drucker wollte gegen die Wand fahren, da habe ich ihm den Stecker gezogen!
Das traurige Ende des Log habe ich gespeichert, falls es jemand sehen möchte.

Meine Treiber Einstellung im Gerätemanager haben auch nicht rühmlich ausgesehen.
Es ist aber egal, was und wo ich einstelle, der Drucker bleibt gelegentlich für eine knappe Sekunde stehen.

An Nibbels:

Ich werde versuchen die Sandart Einstellungen von Conrad beim nächsten Flaschen mit einzupflegen, falls das Sinn macht?

Kommende Woche möchte ich eine aktuelle FW aufspielen, mit den Standart Parameter der Datenübertragung.
Es kann sein, dass ich mich per PN melde.

LG AtlonXP

Ich muss mich korrigieren, bei einem Druck über SD Karte bleibt der Drucker auch manchmal stehen.
Etwa so eine halbe Sekunde lang.

Es wurde das Einhausungsscharnier gedruckt mit langsamer Geschwindigkeit (um die 30 mm/s).
Meine FW ist nicht ganz aktuell.

LG AtlonXP