Community Mod RFx000 Firmware :: Neue Stable (Stand 1.43.13 / 30.11.2018)

[rf1k_mjh11]

Hallo Nibbels,

Mein Verdacht ist, dass Arc-Support wirklich keiner braucht

Tja, ich habe mich vor kurzen wieder damit beschäftigt - mit G2 & G3.

Die vier häufigsten Dateiformate, mit denen man einen Slicer füttern kann (zumindest die mir bekannten gratis-Slicer), sind: *.STL, *.OBJ, *.AMF, und *.3MF.
Googlet man sich da rein (auch mit Wiki) kommt man darauf, dass alle diese Formate doch wieder nur auf einem Mesh aufbauen (Mesh = eine Fläche, bestehend aus vielen kleinen Flächen, oft in dreieckiger Form, mit der man komplexe Oberflächen recht genau nachbilden kann).
Da alle Formate im Endeffekt Meshes sind, kommen erst wieder nur im GCode lauter kurze Geraden heraus und keine echten Kurven (wie sie mit G2 oder G3 erzeugbar wären). Das habe ich hier schon einmal vorgebracht.
Die derzeitigen Slicer schaffen es noch nicht, echte Kurven im GCode zu erzeugen. Da käme einiges an Mathematik für den Slicer heraus - im einfachsten Fall wären das die Kegelschnitte, falls sich jemand noch daran erinnern kann (na ja, die jüngeren schon...).

Daher ist der Arc Support ein 'nettes Feature', dass, so wie bei vielen elektronischen Geräten, zwar vorhanden ist, aber derzeit nicht genutzt wird.

Ich bin bei mir letztens über eine Python-Datei gestolpert, die G1 Befehle in G2- oder G3-Befehle umwandelt. Es heißt G1toG23 und es gibt eine relative aktuelle Version auf GitHub, hier. Das könnte man als post-processing Script einbinden und automatisch alle GCode-Dateien umwandeln. Habe ich noch nicht probiert.

mjh11

[Nibbels]

Hallo,
ich hatte vor einiger Zeit bei meinem RF1000 die 1.43.20 getestet und heute die 1.43.80 (normaler Druckerbetrieb).
Bei beiden Versionen habe ich das Problem, dass der Tisch nach einiger Zeit während des Drucks einfach nach hinten fährt. Als ob er in dieser Bewegung festhängt.
Sind die Versionen nicht mehr für den RF1000 gedacht?

Hallo CrazyJ,

ich hab schon mal von so einem Problem gehört, es selbst aber nie erfahren dürfen.
Besonders das folgende Szenario 3 (oder evtl. Szenario 2?) hat mich schon mal beschäftigt. Ich habe nur bisher kaum Anhaltspunkte, wie ich danach suchen soll.
Inzwischen meine ich aber, dass zumindest die Berechnung der "Relativ-Bewegungsschritte" ab Gcode-Parsing nicht das Problem sein kann.
Ich habe extra zwischen der 1.43.20 und 1.43.82 quasi alles im Code nochmal durchgesehen und ganz viel Code eliminiert.

Es gibt zu deiner Beschreibung einige mögliche Szenarien,
darum sag mir bitte welche der folgenden Beschreibungen deinem Problem am nächsten kommt:

1) Dein Drucker hat die Auto-Pause eingeleitet und geht "tatsächlich nur" in die Pause, weil die Kraft zwischen deinen DMS-Streifen zu hoch wurde.
Dann Piept der und fährt das Bett etwas weiter nach unten und nach hinten. Drückst du die Taste Play macht der weiter. (Stand der länger rum, senkt der in der Pause die Temperatur um -100°K, dann musst du zum Fortsetzen nochmal PLAY drücken, wenn der wieder aufgeheizt hat.)
2) Dein Drucker druckt einfach nicht weiter und fährt den Tisch vor dem Abbrechen wirr irgendwohin.
3) Dein Drucker hat ein Problem mit der Gcode-Verarbeitung und es scheint so, als würde ab und an Y auf 0 angefahren? Er macht aber anschließend korrekt weiter, (weil du vermutlich für XYZ ein absolutes Koordinatensystem nutzt und der nächste GCode wieder korrekt verarbeitet wurde?)
4) Es ist ganz anders als hier drüber mit 1..3 beschrieben.


Noch mehr Fragen:
- Druckst du ausschließlich von SD-Karte?
- Druckst du ausschließlich über USB?
- Hast du das bei beiden Varianten beobachtet?
- 1.43.8x: Hast du die Microsteps für Z bei 16 belassen, oder wieder hoch gestellt? (16 sollte tatsächlich viel besser sein!)
Oder auch: Hast du irgendwelche Microsteps höher eingestellt, als voreingestellt war?

LG

[Nibbels]

Hallo Nibbels,

Mein Verdacht ist, dass Arc-Support wirklich keiner braucht

Tja, ich habe mich vor kurzen wieder damit beschäftigt - mit G2 & G3.

Die vier häufigsten Dateiformate, mit denen man einen Slicer füttern kann (zumindest die mir bekannten gratis-Slicer), sind: *.STL, *.OBJ, *.AMF, und *.3MF.
Googlet man sich da rein (auch mit Wiki) kommt man darauf, dass alle diese Formate doch wieder nur auf einem Mesh aufbauen (Mesh = eine Fläche, bestehend aus vielen kleinen Flächen, oft in dreieckiger Form, mit der man komplexe Oberflächen recht genau nachbilden kann).
Da alle Formate im Endeffekt Meshes sind, kommen erst wieder nur im GCode lauter kurze Geraden heraus und keine echten Kurven (wie sie mit G2 oder G3 erzeugbar wären). Das habe ich hier schon einmal vorgebracht.
Die derzeitigen Slicer schaffen es noch nicht, echte Kurven im GCode zu erzeugen. Da käme einiges an Mathematik für den Slicer heraus - im einfachsten Fall wären das die Kegelschnitte, falls sich jemand noch daran erinnern kann (na ja, die jüngeren schon...).

Daher ist der Arc Support ein 'nettes Feature', dass, so wie bei vielen elektronischen Geräten, zwar vorhanden ist, aber derzeit nicht genutzt wird.

Ich bin bei mir letztens über eine Python-Datei gestolpert, die G1 Befehle in G2- oder G3-Befehle umwandelt. Es heißt G1toG23 und es gibt eine relative aktuelle Version auf GitHub, hier. Das könnte man als post-processing Script einbinden und automatisch alle GCode-Dateien umwandeln. Habe ich noch nicht probiert.

mjh11

Servus

Ich hab mir unseren FIrmware-Code zu G2 und G3 erst angesehen.
Die Startkoordinate ist die aktuelle Position.
Per G2/G3-GCode gibt man immer eine Ziel-Koordinate an.
Jetzt fehlt noch der Mittelpunkt des Kreises oder der Radius. Gibt man eins davon an, wird das jeweils andere errechnet.

Jetzt hat der Drucker also seinen Startpunkt und er sucht sich wie mit G1-Gcodes seinen Weg Richtung Zielpunkt - hier um den Kreismittelpunkt herum.
Das passiert je nachdem ob man G2 oder G3 benutzt hat mit oder gegen den Uhrzeigersinn.

Schaut man sich die Funktion
PrintLine::arc(float *position, float *target, float *offset, float radius, uint8_t isclockwise)
genau an, sieht man ein paar Dinge, die man evtl. nicht so erwarten würde:
- Auch hier wird die Bahn in kleinste Teilstücke zerteilt.
- Hardcoded: Ist ein Kreisstück < 0.001mm lang wird es ignoriert.
- Es wird anhand einer festen Feedrate-Konstante von 60mm/s unterschieden, ob größere oder kleinere Segmente verwendet werden.

/** \brief Step to split a circle in small Lines */
#define MM_PER_ARC_SEGMENT 1
#define MM_PER_ARC_SEGMENT_BIG 3

- Es könnte sein, dass ein kurzes Kreis-Teilstück nur aus einem Segment also einer kleinen Gerade besteht.
- Jede 25 Teilstücke wird die numerische Cosinus-Näherung korrigiert.

Wir haben also auch hier kleine Teilstücke. Das wird auch nicht mit hochpräzisen Sinus/Cosinus gemacht, sondern sehr gut angenähert.
Das ist wichtig, denn es wird ziemlich viel gerechnet. Ich hab dann mal die Geschwindigkeit erhöht und dann konnte ich "dieses Micro-Ruckeln" beobachten. Da war die Rechenleistung wohl am Limit -> Throttling. Es beginnt in diesem Fall wie beim Druck über SD/USB so ein Mikro-Ruckeln.
Nur diesesmal kann man die bekannten Verdächtigen wie "SD-Karte" natürlich gnadenlos ausschließen.

G2/G3 spart bei unserer Firmware/Repetier-Firmware/usw. also Gcode-Länge. Man muss nicht die ganzen Teilstücke einzeln in den Drucker schicken.
Aber ob es der Genauigkeit hilft bezweifle ich stark.

Für mich bleibt die Frage, was von der Firmware-Rechenleistung effizienter ist.
-> Ist es effizienter, die Teilstücke aus einem G2/G3 zu berechnen?
-> Oder ist es effizienter die fein gestückelten G0/G1 Gcodes aus der jeweiligen Datenquelle wie SD oder USB zu lesen.

[Wenn wir mehr Qualität und Geschwindigkeit aus den RFx000 holen wollten, ohne die Elektronik/ATMEGA2560 upgraden zu müssen, dann sollten wir Klipper einsetzen. Ich weiß aber nicht, ob ich das jemals anfangen werde. Python wollte ich eigentlich links liegen lassen und für mich funktioniert der Mod aktuell einfach zu gut. Der Vorteil wäre, dass man mit der Leistung eines RaspberryPI im Grunde alle Bewegungen hochpräzise "hinintegrieren könnte", also perfekt verrundete Beschleunigungen, Achsenbewegungen ... Haja.]

LG

[CrazyJ]

Hallo Nibbels,
1) Der Drucker geht definitiv nicht in die Pause.
2) Ja, das kommt hin. Der Druck wird nicht fortgesetzt, der Tisch fährt einfach mit seiner Geschindigkeit nach hinten bis ich abschalte. Die anderen Bewegungen werden nicht fortgesetzt. Bislang habe ich das nur in y-Richtung beobachtet. Hatte aber auch nur 2 Versuche (mit Version .20 und .80). Danach immer wieder die original 1.39. Damit keine Probleme.
3) Könnte sein, dass ich das bis zur Version .20 auch immer hatte. Da waren immer kleine Microstopps was den Druck unsauber machte. Deshalb habe ich immer mal wieder eine neuere Version probiert. Als die nicht funktionierte bin ich immer wieder auf die original 1.39 (druckte immer sauber durch). Soweit ich gesehen hatte, schien die 1.43.80 diesbezüglich aber auch sauber zu drucken.

Zu den anderen Fragen:
- Ja, ich drucke nur von SD- Karte (Test erfolgte immer mit der selben Datei, selbe Speicherkarte)
- Noch nie von USB gedruckt, deshalb konnte ich das noch nie beobachten.
- Bei der 1.43.80 hab ich nichts mehr eingestellt. Hab nur vor dem Flashen die Sprache auf Deutsch und den RF1000 parametriert.
- Nach dem Flashen wurden die Werkseinstellungen geladen und der PLA Levelscan erfolgreich druchgeführt.
LG

[Nibbels]

Danke für deine Vergleichsinfos und die Antwort!

Jetzt muss ich mal recherchieren ob meine bisherigen Bugmeldungen zum den Fahrausbrechern immer über SD-Druck passierten.
Wenn ja, könnte es am Tausch der SD-Library liegen.
Ich hatte ja mal die SD-lib von 2013 ausgebaut und die aktuelle Version eingefügt. Es ist gut möglich, dass ich entweder die Config, den SD-Lese-Code oder die SPI-Methode überdenken sollte.

Komisch finde ich nur, dass bei meinen beiden Druckern die Probleme noch nie sichtbar waren. Ich drucke aber auch kaum von SD. Nur über USB und dann mit entweder Repetier-Server oder Octopi.

(Bei der Druckqualität hast du recht. Wir hatten mal an Einstellungen gedreht, wegen der Ruckelproblematik, die aber nicht das Problem waren und keinen Effekt zu haben schienen - die blieben drin und das war fatal.
Zusätzlich habe ich den Advance-Bug beheben, die Pfad-Rundungsfehler eliminieren und die Z-Kompensation parallelisieren können. ..)

Eine Frage hab ich noch:
Wenn der Drucker mist baut, rattert der dann am Achsen-Ende oder bleibt der nur am Endschalter o.ä. stehen?

LG

[CrazyJ]

Hallo Nibbels,
da ich den Drucker sofort nachdem das Problem auftrat abgeschaltet hatte (nicht abgewartet was am Endanschlag passiert) musste ich erst noch einen Test ausführen.
Folgendes passiert:
der Drucker fährt den Tisch nach hinten (y-Richtung) (keine weitere Bewegung, weder x, z oder Extruder), fährt gegen den Endschalter, wechselt die Richtung (Tisch fährt nach vorne) und wenn er wieder über dem Punkt ist, wo das Problem anfing, druckt er normal weiter.

Eine bestimmte Höhe oder Zeit ist nicht zu erkennen. Beim Test, den ich gestern Abend noch gemacht hatte, gabs keine Probleme. Erst heute morgen wieder. Bislang auch nur bei der y-Achse festgestellt. Heute morgen hat er auch wieder einige Microstopps

[Nibbels]

Ok, das deckt sich mit einem anderen Bericht. Da war auch exakt und nur die Y-Achse mit dem Verhalten.
Das darf natürlich nicht sein, aber finde mal zufällige Fehler.

Festgehalten:
- Wenn der weiterdruckt: Es war kein Drucker-Reboot.
- Wenn er normal weiterdruckt: Es war ein einzelner GCode der nicht sauber aufgelöst wurde oder zwischendurch hats die Y-Achskoordinate genullt.
Das passiert aber nirgends im Code, ausser wenn man die Stepper abschaltet, danach habe ich schon gesucht.
- Overflow? Bisher ist das gleich passiert, dann habe ich die betreffende uint32_t Variable komplett ausgebaut und eine Float-Variable neu eingebaut, die sich von >V1.43.80 jetzt an die Koordinate merkt. Es tritt trotzdem auf. Also vermutlich kein Overflow. Ausserdem steht immer erst der X-Bereich vor Y im Ram. Overflows würden auch X verwirren.

Wahrscheinlich wäre also:
- Störung der Datenübertragung
- Lesefehler aus dem Puffer der Datenquelle. (Eine besondere Exception die nicht korrekt behandelt wird.)


Zu möglichen Lösungsstrategien:

Eingrenzen: Hättest du die Möglichkeit mit einem RaspberryPI zu drucken?
Wenn es mit derselben Firmware mit Repetier-Server/Octopi nicht mehr auftritt, dann weiß ich genau in welchem "Ast" des Codes ich suchen muss.

Schrotflinte: Evtl. könnte ich auch mal meinerseits hingehen und diesen "NEW_COMMUNICATION"-Teil von Repetier komplett übernehmen. Er hat den Kommunikationsteil komplett in Klassen eingebunden. Mit dem Hintergrund dass man beliebige Datenquellen als Source einhängen kann. Wir haben aber sowieso nur Seriell und kein Bluetooth etc. darum habe ich mich nicht weiter darum gekümmert.
z.B. https://github.com/repetier/Repetier-Fi ... rd.cpp#L28
Meine Idee wäre, dass das Problem mit der Umstellung zufällig rausfliegt ^^.

Versuchen die SPI-Modi zu wechseln und schauen ob das Problem weg ist:
https://github.com/repetier/Repetier-Fi ... rd.cpp#L77
Stichwort "ENABLE_SOFTWARE_SPI_CLASS"

Versionen abklappern: Ich persönlich gehe normalerweise so vor, dass ich mir beliebige alte Firmwarestände aufspiele und prüfe ob das Problem vorkommt, aber damit kommen wir vermutlich nicht weiter, wenn der Fehler nur ab und an auftritt.

?? ^^

[CrazyJ]

Hallo Nibbels,
wie du vielleicht gesehen hattest, hatte ich noch ein Video des Fehlers angehängt.

Einen RaspberryPI habe ich nicht.
Ein weiterer Testdruck über USB verlief aber aber ohne Probleme. (Keine Microstopps oder andere Unstimmigkeiten). Könnte Zufall gewesen sein.
Ansonsten würde ich aber auch ein Leseproblem von der Speicherkarte annehmen.

[zero K]

´n Abend allerseits

@Nibbels

Es gibt zu deiner Beschreibung einige mögliche Szenarien,
...
1) Dein Drucker hat die Auto-Pause eingeleitet und geht "tatsächlich nur" in die Pause, weil die Kraft zwischen deinen DMS-Streifen zu hoch wurde.
...

Es gibt noch eine Möglichkeit einer automatischen Pause - z.B. in Cura, wenn die für einen Layer benötigte Zeit zu kurz ist, also der nächste Layer auf ein noch zu frisches darunter liegendes Layersegment gedruckt werden sollte, zum Beispiel in der Nähe einer Kegelspitze.

Ist es sinnvol im Text des g-codes nach dieser vereinzelten Auslenkung nach Y-Max suchen und dann die Umgebung nach Auffälligkeiten abklappern?

Weil ich meinen Pi auch mal pflegen warten und updaten wollte, habe ich mit dem damals noch frischen mod.77 ein paar Modelle (rund 4h) von SD drucken lassen, dabei ist mir keine Fehlfunktion aufgefallen.

@ crazy J
Das mit dem Pi kannst Du mal erwägen,
dauernd eine Speicherkarte hin und her zu schleppen und um zu stöpseln wäre für mich nicht mehr zeitgemäß.

Ciao, zero K

[AtlonXP]

Hallo Zusammen,
heute ist bei mir Druck Tag.
Ich Drucke genau da weiter, wo es mir das letzte Mal den Drucker zerpflückt hat.
http://www.rf1000.de/viewtopic.php?p=25762#p25762

Was ist heute anders wie das letzte Mal?

Der Drucker ist repariert.
Es ist eine neue FW aufgespielt.
Ich verwende eine neue SD Karte mit 32 GB.
Die Kompleten Daten von der alten SD Karte wurden einfach auf die Neue Kopiert.
Somit drucke ich mit dem gleichen G.-Code.
Natürlich habe ich die Dateien und die Karten nochmals überprüft.
Es wurden keine Fehler gefunden.

Auch bei mir hat es zuerst gestockelt, bevor die Z Achse in den Himmel gefahren ist.
Ich kann zu meinem Problem nur Vermutungen aufstellen:
Ich behaupte mal das Stockeln und die Fehlfunktion haben eine gemeinsame Ursache.

Zur SD Karte:
Da die Datei in ordentlicher Form vorliegt, könnte es eventuell an der Zugriffzeit liegen.
Die 2 GB Karte war etwa zu 50 % voll.
Die Neue SD Karte ist größer und auch schneller, hoffe ich.

Zur FW, die ist mein Hauptfavorit:
Natürlich habe ich mit Nibbels über dieses Thema mündlich gesprochen.
Vielleicht ist der Hauptspeicher ausgegangen?
Dies könnte durchaus möglich gewesen sein.
@Nibbels, kann es möglich sein, dass wie bei Windoof, Ressourcen oder Speicher verloren gehen und dies sich zum Schluss auswirkt?
Wird der Hauptspeicher von unserem Drucker sauber gehalten, oder müllt der langsam zu?

Irgendwie sehe ich Parallelen von CrazyJ und mir.
Nur dass es bei ihm die Y Achse ist und beim war es die Z Achse,
das Stockeln kommt etwa 10 min vor der Fehlfunktion!
Ich denke es ist ein Muss, das unser FW die SD Karte fehlerfrei betreiben kann.
Es wäre sonst ein gewaltiger Nachteil zur originalen FW.


Und nun noch was zu G2 und G3.
Selbst mein billiges China Fräsle verwendet diese Befehle!
Ich denke zum Fräsen muss die FW, diese Funktionen unterstützen können.

@ CrazyJ, ich empfehle dir:
Sicher deine Daten von der SD Karte wo anders.
Formatier das Ding neu.
Halte die Datenmenge so gering wie möglich, auf deiner SD Karte.
In meinem obigen Link ist auch beschrieben wie man die SD Karte mit Windows Mitteln überprüfen kann.

LG AtlonXP