Neue Development Firmware (RF.01.15)

[mhier]

Ok danke, liefere ich nach (morgen oder so)!

[mhier]

Also ich habe jetzt mal ein bisschen Debug-Output produziert, allerdings ohne wirklich zu fräsen. Ich habe zuerst per Menü meine absichtlich schiefe Platte gescannt (per Befehl ging nicht, da M3164 und M3165 nicht funktionieren -> noch ein Bug?). Dann habe ich folgende Befehle ausgeführt:

Code: Alles auswählen

M3005 S6 ; enable debug output
G28 ; home
M400 ; finish movement
M3153 ; output matrix
M3141 ; turn z-compensation on
G01 X120 Y120
G01 X107
G01 X135
G01 Y103
G01 Y136
G01 X107
G01 Y103
G01 X135

Der Debug-Output dazu ist folgender:

Code: Alles auswählen

21:25:19.702: M3005: new debug level: 6ok 1938
21:25:19.776: Warning: Missed line detected - correcting buffer usage.
21:25:20.280: nCPS X;0; nCPS Y;0; nCPS Z;8252; tCZ;0; cCZ;0; tPSZ;0; cPSZ;0; dZ;512000; cZ;512000; Int32;0; RAM;1948
21:25:22.400: nCPS X;0; nCPS Y;0; nCPS Z;46108; tCZ;0; cCZ;0; tPSZ;0; cPSZ;0; dZ;512000; cZ;512000; Int32;0; RAM;1948
21:25:24.598: nCPS X;0; nCPS Y;0; nCPS Z;85340; tCZ;0; cCZ;0; tPSZ;0; cPSZ;0; dZ;512000; cZ;512000; Int32;0; RAM;1948
21:25:27.757: loopRF(): driving free z-max
21:25:27.766: X:-4.99 Y:-54.99 Z:46.29 E:0.00
21:25:27.775: loopRF(): z-max is free
21:25:27.964: nCPS X;0; nCPS Y;0; nCPS Z;118338; tCZ;0; cCZ;0; tPSZ;0; cPSZ;0; dZ;510720; cZ;510720; Int32;0; RAM;1948
21:25:30.060: nCPS X;0; nCPS Y;0; nCPS Z;118002; tCZ;0; cCZ;0; tPSZ;0; cPSZ;0; dZ;512000; cZ;512000; Int32;0; RAM;1948
21:25:32.157: nCPS X;520; nCPS Y;0; nCPS Z;512000; tCZ;0; cCZ;0; tPSZ;0; cPSZ;0; dZ;512000; cZ;512000; Int32;0; RAM;1948
21:25:34.253: nCPS X;0; nCPS Y;57; nCPS Z;512000; tCZ;0; cCZ;0; tPSZ;0; cPSZ;0; dZ;512000; cZ;512000; Int32;0; RAM;1948
21:25:36.350: nCPS X;0; nCPS Y;215; nCPS Z;512000; tCZ;0; cCZ;0; tPSZ;0; cPSZ;0; dZ;512000; cZ;512000; Int32;0; RAM;1948
21:25:36.871: X:-4.99 Y:-54.99 Z:200.00 E:0.00
21:25:36.921: M3153: current work part compensation matrix:
21:25:36.932: front left ... front right
21:25:36.944: ... ... ...
21:25:36.955: back left ... back right
21:25:36.977: ;6;0;109;119;245
21:25:36.991: ;0;-172;-172;-924;-924
21:25:37.000: ;105;-172;-172;-924;-924
21:25:37.013: ;115;240;240;-608;-608
21:25:37.024: ;125;564;564;-312;-312
21:25:37.036: ;245;564;564;-312;-312
21:25:37.044: offset = 564 [steps] (= 0.22 [mm])
21:25:37.055: g_uZMatrixMaxX = 5
21:25:37.066: g_uZMatrixMaxY = 6
21:25:37.077: g_nActiveWorkPart = 1
21:25:37.096: scan start: x = 109.99, y = 106.00 [mm]
21:25:37.107: scan steps: x = 10.00, y = 10.00 [mm]
21:25:37.117: scan end: x = 135.00, y = 138.99 [mm]
21:25:37.142: M3141: enabling z compensation
21:25:38.480: nCPS X;7866; nCPS Y;11022; nCPS Z;512000; tCZ;-172; cCZ;-172; tPSZ;0; cPSZ;0; dZ;512000; cZ;512000; Int32;0; RAM;1948
21:25:40.544: nCPS X;18991; nCPS Y;26666; nCPS Z;512000; tCZ;-312; cCZ;-312; tPSZ;0; cPSZ;0; dZ;512000; cZ;512000; Int32;0; RAM;1948
21:25:42.641: nCPS X;21332; nCPS Y;24327; nCPS Z;512000; tCZ;-312; cCZ;-312; tPSZ;0; cPSZ;0; dZ;512000; cZ;512000; Int32;0; RAM;1948
21:25:44.738: nCPS X;17067; nCPS Y;29104; nCPS Z;512000; tCZ;301; cCZ;301; tPSZ;0; cPSZ;0; dZ;512000; cZ;512000; Int32;0; RAM;1948
21:26:24.177: :0.1994
21:26:24.202: T
21:26:24.212: 00 /0 B:0.00 /0 B@:0 @:0
21:26:25.290: Warning: Missed line detected - correcting buffer usage.

Hilft das so schon oder soll ich noch andere Einstellungen verwenden bzw. andere Befehle ausführen?

[mhier]

Noch ein (ziemlich schwerer!) Bug im Druck-Modus: Wenn ich einen Heatbed-Scan starte, misst er den ersten Punkt. Wenn er dann in z-Richtung eigentlich ein Stück nach unten fahren sollte um anschließend zum nächsten Punkt zu fahren, fährt er statdessen nach oben (also in das Heatbed hinein!) und wird nur durch die Sicherheitsabschaltung (Maximaler Druck überschritten) daran gehindert, das Bett oder den Extruder zu zerstören. Im Log steht mal wieder das berühmte "loopRF(): driving free z-max". Ich habe das jetzt bei meinen beiden einzigen Versuchen gehabt, mit RF.01.15 einen Heatbed-Scan durchzuführen. Ich vermute also, das ist reproduzierbar, sofern der Endschalter-Typ auf circuit steht. Irgendwie habt ihr das nicht richtig im Griff...

EDIT: Wenn ich den Z-Schalter auf Single stelle, scheint es zu gehen.

[Wessix]

da ich gerade einen Druck laufen habe und feststellen muss, dass die Z-Kompensation wohl irgendwie nicht an ist, könnte man vll einen Indikator dafür verwirklichen der das anzeigt, auch während des Druckes?

[mhier]

da ich gerade einen Druck laufen habe und feststellen muss, dass die Z-Kompensation wohl irgendwie nicht an ist, könnte man vll einen Indikator dafür verwirklichen der das anzeigt, auch während des Druckes?

Die Z-Kompensation beim Druck hat bei mir gut funktioniert, soweit ich das beurteilen kann. Ich habe den Auslösepunkt des Z-Referenzschalters recht weit vom Druckbett entfernt gelegt, so dass ich bei fehlender Z-Kompensation erheblich nachkorrigieren müsste. Mit der neuen Firmware habe ich aber schon 3-4 Ausdrucke gemacht, wo ich das nicht beobachtet habe. Zum Drucken habe ich den Z-Schalter-Typ jetzt auf Single gestellt, sonst geht ja der Heatbed-Scan nicht.

Wessix, bist du sicher, dass du die Z-Kompensation eingeschaltet hast zum richtigen Zeitpunkt im G-Code? Im Zweifel poste mal den Anfang deines G-Codes (bis der eigentliche Druck losgeht, erkennbar an den immer gleichartigen G01-Befehlen).

[Wessix]

Nein sie war nicht an, das hab ich dann auch rausgefunden M3001 muss am Anfang kommen, wollte blos als Verbesserung dies Vorschlagen, dass man das auch während eines Druckes sehen kann, z.b. mit einem * als indikator dafür o.ä.

[RF1000]

Hilft das so schon oder soll ich noch andere Einstellungen verwenden bzw. andere Befehle ausführen?

Also nach diesen Debugausgaben ist die Z-Kompensation ein, rechnet Z-Kompensationswerte aus und fährt auch dorthin. Wie hast du festgestellt, dass die Z-Kompensation nicht aktiv ist?
Solange sie aktiv ist sollte sich ja a) die Z-Position im Display leicht ändern und b) kann man sehen/spüren, dass sich die Z-Spindeln leicht bewegen.

da ich gerade einen Druck laufen habe und feststellen muss, dass die Z-Kompensation wohl irgendwie nicht an ist, könnte man vll einen Indikator dafür verwirklichen der das anzeigt, auch während des Druckes?

Das sollte möglich sein.

Noch ein (ziemlich schwerer!) Bug im Druck-Modus: Wenn ich einen Heatbed-Scan starte, misst er den ersten Punkt. Wenn er dann in z-Richtung eigentlich ein Stück nach unten fahren sollte um anschließend zum nächsten Punkt zu fahren, fährt er statdessen nach oben (also in das Heatbed hinein!) und wird nur durch die Sicherheitsabschaltung (Maximaler Druck überschritten) daran gehindert, das Bett oder den Extruder zu zerstören. Im Log steht mal wieder das berühmte "loopRF(): driving free z-max". Ich habe das jetzt bei meinen beiden einzigen Versuchen gehabt, mit RF.01.15 einen Heatbed-Scan durchzuführen. Ich vermute also, das ist reproduzierbar, sofern der Endschalter-Typ auf circuit steht.

Wir schauen uns das an.


mfG
RF1000

[RFrank]

Hallo zusammen

Noch ein (ziemlich schwerer!) Bug im Druck-Modus: Wenn ich einen Heatbed-Scan starte, misst er den ersten Punkt. Wenn er dann in z-Richtung eigentlich ein Stück nach unten fahren sollte um anschließend zum nächsten Punkt zu fahren, fährt er statdessen nach oben (also in das Heatbed hinein!) und wird nur durch die Sicherheitsabschaltung (Maximaler Druck überschritten) daran gehindert, das Bett oder den Extruder zu zerstören. Im Log steht mal wieder das berühmte "loopRF(): driving free z-max". Ich habe das jetzt bei meinen beiden einzigen Versuchen gehabt, mit RF.01.15 einen Heatbed-Scan durchzuführen. Ich vermute also, das ist reproduzierbar, sofern der Endschalter-Typ auf circuit steht. Irgendwie habt ihr das nicht richtig im Griff...

EDIT: Wenn ich den Z-Schalter auf Single stelle, scheint es zu gehen.

Diesen Fehler hatte ich schon bei der RF.01.11 beschrieben und mir war klar das dieser auch in dieser Software vorhanden ist.

Zur Zeit nutze ich die 91.51 die um Längen besser beim Bett-Scan ist (Bruchteil der Zeit, keine Fehlversuche, kein Überlasten der Wägezellen, kein wiederholtes Homing während des Scans, mehr richtige Punkte in der Matrix).

Schade das wir wieder die Testpersonen sind und wer ersetzt beim Test dabei zerstörte Teile .

Gruß

[mhier]

Also nach diesen Debugausgaben ist die Z-Kompensation ein, rechnet Z-Kompensationswerte aus und fährt auch dorthin.

Woran erkennst du das?

Wie hast du festgestellt, dass die Z-Kompensation nicht aktiv ist?

Weil er eben nicht dorthin fährt. Wie an der Matrix erkennbar müsste die Kompensation vergleichsweise stark ausfallen (einige 100 Steps). Die Z-Position im Display ändert sich gar nicht, die Spindeln bewegen sich kein bisschen. Der Abstand zwischen dem Tool und der Oberfläche ändert sich hingegen sichtbar, obwohl die Kompensation ja eben diesen konstant halten sollte.

[RF1000]

Zur Zeit nutze ich die 91.51 die um Längen besser beim Bett-Scan ist (Bruchteil der Zeit, keine Fehlversuche, kein Überlasten der Wägezellen, kein wiederholtes Homing während des Scans, mehr richtige Punkte in der Matrix).

Du beziehst dich vermutlich auf deinen Beitrag http://www.rf1000.de/viewtopic.php?p=12219#p12219. Weder wir noch rf1k_mjh11 konnten deine Beobachtung nachvollziehen/reproduzieren (siehe http://www.rf1000.de/viewtopic.php?p=12248#p12248).

Abbrüche des Scans, wiederholte Scans an der selben x/y-Position und Z-Homing während dem Scan deuten auf eine mechanische Ursache hin (wie sie auch rf1k_mjh11 während seinen Versuchen bei seinem RF1000 festgestellt und behoben hat). Hast du sichergestellt, dass es bei deinem RF1000 keine mechanische Ursache gibt?

Soweit ich das bisher überblicke funktioniert der Heizbett-Scan der RF.01.xx nicht schlechter als der Heizbett-Scan der V 0.91.yy.


mfG
RF1000