Timelapse und Repetier Command Buffering

[gergap]

Hallo Freunde der Community Firmware,

ich habe mir mit einem kleinen Atmega8 + IR LED einen Fernauslöser für meine alte Nikkon D80 gebaut.
Ein kleines Perl Script schickt das Kommandp "snap" via UART an den Atmega und die Nikkon macht brav ein Foto.
In OctoPrint rufe ich mittels GCode System Commands (OCTO12) das Perl script.

Im Slicer nutze ich dann das LayerChange Script um den Druckkopf aus dem Weg zu fahren, Foto zu machen, und weiter zu drucken.
So weit so gut, nur das Timing stimmt nicht. Das Foto kommt zu früh.

Ich denke mal das liegt am Kommando Puffer in der Firmware.
Octoprint schickt gleich mal einige Kommandos an die Firmware. Wenn da OCTO12 dabei ist gibts ein Foto,
obwohl die Firmware noch gar nicht zu dem Befehl gekommen ist. Jetzt kann man sich mit Pausen wie "G4 S2" weiterhelfen,
das gefällt mir aber nicht. So eine Art Flush Kommando, dass erst OK returned, wenn es fertig ist, bevor OCTO12 ausgeführt wird, wäre gut.

Ich dachte erst M400 macht das, aber das funktioniert nicht wie erwartet. Vielleicht wartet hier die Firmware nur intern bis die Bewegung zu Ende ist?
Scheint aber keinen Einfluss auf den Befehlspuffer zu haben, zumindest was Octoprint betrifft.

Irgendwelche Ideen?
Vielleicht besser mit SD-Karte drucken?
Wäre schon schön wenn das mit Octoprint geht.

Community Firmware Version: 1.45.00

Layer Change Script:

Code: Alles auswählen

G1 X0 Y200 F20000 ; move out of the way
M400 ; wait until command is complete
OCTO12 ; trigger picture
G4 P200 ; Wait for 200ms

Gruß,
Gerhard.

[rf1k_mjh11]

Hallo gergap/Gerhard,

Du wirst recht haben, Octoprint schickt an den Drucker, bis der Puffer voll ist. Wenn du Pech hast, geht somit der 'OCTO12'-Befehl schon an dein ATMega, bevor der Drucker die Befehle ausgeführt hat (auch bis zu 16 Befehle davor).

Die "G4 S2" Lösung wird fast immer klappen. Käme, als letzte Raupe eines Layers eine oder mehrere sehr lange Raupen, sagen wir einmal diagonal, und noch dazu mit NinjaFlex als Material (was recht langsam gedruckt werden muss), könnte auch das zu wenig sein.

Eine andere Lösung wäre vielleicht, den Puffer garantiert voll zu machen. Beispielsweise mit 16 Mal "G4 P1". Im Gegensatz zum "G4 S2" wird insgesamt nur 16 Millisekunden gewartet, dafür aber der Puffer (hoffentlich) voll belegt. Es fragt sich bloß, ob man die 16 Befehle vor der Zeile mit G1 X0 Y200 F20000 ; move out of the way oder nachher platziert. Es kommt da vermutlich darauf an, ob die FW ein "G4" als eine Bewegung interpretiert , die bei "M400" abgeschlossen sein muss, oder nicht.

Einen Versuch wäre es Wert.

Gesundheit allerseits,

mjh11

[gergap]

Danke für den Tipp:

Beispielsweise mit 16 Mal "G4 P1"

das werde ich morgen gleich mal testen. Momentan drucke ich gerade und das dauert noch ein paar Stunden.

[gergap]

Hallo nochmal,

ich versuche gerade den Code zu verstehen.
Woher hast du das mit den 16 Befehlen?
Ich finde im Code nur diese GCode Buffer Size.

Code: Alles auswählen

/**
 * \brief Cache size for incoming commands.
 * There should be no reason to increase this cache. Commands are nearly immediately sent to
 * execution.
 */
#define GCODE_BUFFER_SIZE                   2

Das ist denke ich die Anzahl der Befehle und das wären dann nur zwei.
Es gibt da noch

Code: Alles auswählen

grep CMD_SIZE -n gcode.h
21:#define MAX_CMD_SIZE 96
340:    static uint8_t commandReceiving[MAX_CMD_SIZE];    ///< Current received command.

Aber das ist wohl die max. string länge eines kommandos so weit ich das verstehe.

Gibt es noch wo anderes eine commandqueue außerhalb des GCode Parsers?

[rf1k_mjh11]

Hallo gergap/Gerhard,

Tja, da bist du mir um einiges voraus. Ich hätte den Eintrag in der Firmware gar nicht gefunden. Kann sein, dass es wirklich nur 2 Befehle im Puffer sind. Andererseits machen die 16 Stück insgesamt, wie gesagt, nur 16 Millisekunden Pause aus.

Ich kam auf die '16' weil ich oft in Repetier-Host beobachte, dass die Anzeige um ca. 16 'Liniensegmente' vorläuft. Das heißt, in der "3D View", unter "Manual Control" sieht man schön Linie für Linie, wie der Druck voranschreitet. Dort habe ich schon hunderte Male beobachtet, wie die Vorschau um ca. 16 Liniensegmente dem Drucker vorläuft. Ich drucke meist über USB (und bin damit hier im Forum in der Minderheit, vermute ich).
Nehmen wir an, ich drucke 2 Würfel. Bei jedem Layer werden zuerst die Umrisse (Perimeter) von einem Würfel gedruckt, dann der Infill. Danach, bei zweiten Würfel dann das gleiche nochmals. Bei einer Einstellung von z.B. 2 Perimetern sieht man in der Vorschau schon alle 8 Segmente der Perimeter des zweiten Würfels als bereits gedruckt, obwohl der Drucker noch am Infill des ersten Würfels arbeitet.
Druckt man NICHT über USB aus Repetier-Host heraus, kann man das wahrscheinlich nicht so beobachten.

Kann sein, dass es nicht exakt 16 Befehle sind, aber mehr als 8 auf jeden Fall. Ich dachte halt, 16 ist 'ne binäre Zahl.

Wie gesagt, wenn du den Befehl 16 Mal wiederholst, investierst du nur 16 Millisekunden und ein wenig Schreibarbeit (mit 'Cut & Paste' kaum was).

Eine weitere Möglichkeit wäre vielleicht eine oder mehrere zusätzliche Fahrwege um 0.1mm in X oder Y absichtlich einzupflegen, samt jeweiligem M400. Das kostet auch kaum Zeit, füllt aber ebenso den Puffer.

Details über die Abarbeitung von GCode Befehlen, bzw. welche gepuffert werden und welche nicht, findest du hier. (Hinweis: die RFx000 Drucker verwenden eine Repetier-Variante). Aus dem Link ist zu entnehmen, dass G1 gepuffert wird, G4 und M400 hingegen nicht (falls sich unsere Firmware strikt an Repetier-Vorgaben hält...).

Abschließend muss ich noch sagen, dass ich keine Ahnung habe, wie beim Druck mittels SD-Karte die Befehlsabarbeitung abläuft (Pufferung, usw.).

mjh11

[AtlonXP]

Hallo zusammen,
ich kann zwar nicht folgen um was es hier genau geht.

@ rf1k_mjh11, du liegst richtig mit der 16 im Move Speicher.

Das ist mein Auszug aus der Community FW 1.45.0:
Der steht in der RF1000.h
#define MOVE_CACHE_SIZE 16
Ich meine es ist der Standard Wert.
_________________________________________________________________________
/**
* \brief Cache size for incoming commands.
* There should be no reason to increase this cache. Commands are nearly immediately sent to
* execution.
*/
#define GCODE_BUFFER_SIZE 2

_________________________________________________________________________
Ehrlich gesagt, ich kenne diese Zeilen nicht!

LG AtlonXP

[gergap]

Hallo ihr zwei,

vielen Dank für den Input.
Also dann gibt es doch noch einen sekundären Cache (der Move Cache),
der auch die Aussagen von mjh11 untermauert. Binärzahl 16 und so ...
Ich weiß was du meinst, musste nur kurz schmunzeln, als ich das gelesen habe.

Langsam verstehe ich den Code.
1.) GCodeSource ist die Basis-Klasse für das Empfangen on GCode Befehlen.
SDCardGcodeSource und SerialGCodeSource. Der Name sagt schon alles.
2.) MAX_CMD_SIZE definiert wie schon erwähnt die max. Länge eines Kommandos
3.) GCODE_BUFFER_SIZE definiert die Anzahl der Befhle die in der GCodeSource gepuffert werden.
4.) MOVE_CACHE_SIZE defineirt wie viel Move Befehle gecacht werden. Das scheint je nach Drucker anders zu sein.
Aus rf2000.h entnehme ich folgendes:

Code: Alles auswählen

#if SDSUPPORT
#define MOVE_CACHE_SIZE 17
#else
#define MOVE_CACHE_SIZE 24
#endif

D.h. das ist auch nochmal anders je nachdem ob man SDSUPPORT aktiviert hat oder nicht.
Wohl gemerkt, nicht ob man gerade von SD-Karte druckt, sondern nur ob man das rein kompiliert hat oder nicht .
Ich gehe mal davon aus, dass das immer aktiviert ist. Also gilt 17.

Unabhängig davon habe ich heute in der Mittagspause ein bißchen experimentiert.
Komischerweise geht folgendes Script sehr gut:

Code: Alles auswählen

M401 ; save current position
G1 X0 Y200 F20000 ; move out of the way
M400 ; wait until all buffered commands have been executed
G4 P0 ; dummy wait to flush queue
OCTO12 ; trigger picture
G4 P100 ; Wait for 100ms
M402 ; restore position

Heute mittag dachte ich noch, ein "G4 P0" reicht aus, und das klappt auch. Passt nur nicht wirklich zu dem Move Cache.
Vielleicht war das auch nur Zufall.
Nun ja, ich bin erst mal zufrieden damit, aber ich verstehe halt auch gerne was ich mache. Deswegen macht es schon Sinn der Code besser zu verstehen.

Apropos: Manuelle Tests über das Octoprint Terminal haben gezeigt das M401, G1 ..., M402 nicht funktionieren.
Die Position wird nicht wiederhergestellt. Ist aber nicht weiter schlimm, da der Druckcode ohnehin absolute Positionen nutzt und keine relativen.

Werde demnächst vielleicht mal eine Timelapse hier verlinken, wenn was gscheites dabei raus kommt

[AtlonXP]

Hier noch mal die drei Zeilen wo zusammen gehören:
#define LOW_TICKS_PER_MOVE 250000 // ich weiß nicht genau, es dürfte die Geschwindigkeitsreduzierung sein.
#define MOVE_CACHE_SIZE 18 // hier werden max. 18 G Code Zeilen gepuffert.
#define MOVE_CACHE_LOW 14 // wenn 14 G Code Zeilen unterschritten werden im Puffer, dann fährt der Drucker langsamer.

Die Zahlen können schon unterschiedlich sein.
Wir haben zwei Probleme in unserer FW.
1.) S3D verschwendet wegen seiner Echtzeitvorschau in Windows, System Ressourcen bis es zu USB Pausen kommt.

2.) Die Kommunikation allgemein könnte besser sein.
Die Idee, je höher der MOVE_CACHE_SIZE 18 ist, desto mehr Reserve.

3.) Entgegen steht die Tatsache, dass eine Erhöhung gewaltig auf Kosten des Hauptspeichers geht.

Unsere FW lässt das erhöhen des MOVE_CACHE_SIZE von weit über 20 zu.
Der Hauptspeicher aber nicht.

Wenn man nun zum Beispiel den Milling Mode deaktiviert, kann man den eingesparten RAM, dem MOVE_CACHE zuordnen.

Bei mir stehen die Werte so wie hier beschrieben, der Milling Mode ist deaktiviert.

Wenn man den Drucker mit einem PI füttert, könnte man den MOVE_CACHE_SIZE bestimmt sogar unter 10 drücken.

LG AtlonXP

[gergap]

Hier der erste Versuch mit den neuen Settings.
Vom Gcode her hat's super geklappt.
Beleuchtung und so ist noch ausbaufähig
https://youtu.be/le6B3MD92WQ