Probleme mit dem Heat Bed Scan

[trilobyte]

Hallo Zusammen

ich habe einen RF 1000 gebraucht gekauft und in Betrieb genommen. 1.75er V2 Extruder montiert, FW Kompiliert und drauf gemacht. (1.42.22)
danach habe ich schon ziemlich viel gedruckt. geht ganz gut wenn die paramter stimmen.

etwas geht aber noch nicht so richtig und zwar der Heat Bed Scan.
Ich habe den Heat BED Scan PLA ausgeführt. Das dauert ca 1h und danach habe ich auf dem Drucker keine Fehlermeldung gesehen.

Wenn ich dann aber einen Druck starten will kommt die Meldung:
13:06:12.861 : setupForPrinting(): invalid active heat bed z matrix detected: 13

Ich habe dann versucht einen Z-Offset Scan durchzuführen. Da musste ich an der Schraube für den Z Referenzschalter drehen. Danach ging das durch.
Aber seit da steht die Düse zu weit über dem bett und der Druck haftet nicht.

Die Meldung:
13:06:12.861 : setupForPrinting(): invalid active heat bed z matrix detected: 13

kommt immer noch.

Kann mir jemand nochmals erklären wie ich vorgehen muss damit das mit dem Heat bed scan klappt?
Was muss ich alles wann ausführen? Brauchts den Z Offset scan?

Kann ich nachschauen wie die Z Matrix Aussieht?

gruss
siegi

[Nibbels]

Hallo trilobyte,

dieser verdammte 13er Fehler
Kannst du bitte mal in die Konsole den GCode M3013 P1 eingeben und die Antwort hier posten?

LG Stefan

[Nibbels]

Und nachdem du den Output von M3013 hier gepostet hast, könntest du mal folgenden Code ausführen:

Code: Alles auswählen

M3009 S1

Eigentlich reicht es wenn du den M3009 S1 siehe http://www.rf1000.de/wiki/index.php/GCo ... erden_soll ausführst. Damit änderst du die Zahl 13 auf 1. Dann einen neuen HBS machen und es sollte gehen.
Die große Frage ist aber, wie es dazu kommen konnte, dass du diesen Wert im externen EEPROM mit der vermutlich wilkürlichen Zahl 13 überschrieben bekamst. Ich recherchiere das gerade.

LG

[AtlonXP]

Hallo,
ist das nicht schon der Zweite wo da so daher kommt?

@ trilobyte,
verrate uns doch bitte welche alte FW vorher drauf war, die du überspielt hattest?

@Nibbels ich schätze genau hier könnte ein Problem vorliegen,
da bei den älteren FW´s die ganze Matrix anders war.

LG AtlonXP

[Nibbels]

Mich wundert das auch sehr.
Soweit habe ich in schon den (Mod-)Code geschaut:

Diese Matrix-Auswahl-Zahl g_nActiveHeatBed beinhaltet normalerweise 1 bis 9, hier aber 13.
Sie steht normalerweise an "Adresse 0x04" im externen EEPROM.
Diese "g_uZMatrixMax[Y_AXIS] = 13" (Man sieht bei M3013 unten, dass die Anzahl der Matrix-Positionen/Höhe der Matrix-Tabelle in Y = 13 ist.) steht normalerweise an "Adresse = uAddress + 0x04".

-> Man kann die Zahl also nachvollziehbar mit exakt 13 überschreiben, wenn man
void saveCompensationMatrix( unsigned int uAddress );
oder auch void clearCompensationMatrix( unsigned int uAddress )
als uAddress eine 0 übergeben hätte.
In diesem Fall wird im externen EEPROM direkt an Adresse 0+ losgeschrieben, was aber nicht passieren dürfte.
So landet der Inhalt von einer Matrix dort wo eigentlich die Config zu den Matrizen stehen sollte.

Aber warum kann uAddress = 0 sein?

Das kann laut Code eigentlich nur passiert sein, wenn eine Matrix geschrieben wurde, während g_nActiveHeatBed == 0 war. Es stellt sich also die Frage, wo g_nActiveHeatBed geändert oder beschrieben wird. Denn diese wird normalerweise mit 1 initialisiert. Sie wird auch, bis auf an einer Stelle, (die aber keine Probleme bereiten sollte) immer auf Wert 1..9 abgeprüft.

Was ältere Firmwares gemacht haben oder wie dort die Struktur war, habe ich nicht geprüft.

LG

[AtlonXP]

Was ältere Firmwares gemacht haben oder wie dort die Struktur war, habe ich nicht geprüft.

LG

Kann es ein, dass Reste im EEPROM nicht korrekt überschrieben werden?

LG AtlonXP

[Nibbels]

Also ich hab was gefunden, aber nicht weiter reingeschaut:
https://github.com/RF1000/Repetier-Firm ... 130d6991b2
V RF.01.27 (2016-05-25)

Zitat:
- There were situations where the wrong heat bed matrix could be loaded.

Aber wenn ich weiter drüber nachdenke, wäre in dem Fall einfach nur die Matrix 1 geladen worden.
Das sichert eigentlich das hier ab:
https://github.com/RF1000/Repetier-Firm ... da00dR1193
Und warum man das überhaupt brauchen sollte, habe ich bisher nicht verstanden.
(Zumindest im aktuellen Mod wird immer ein Betriebsmodus über "SetupForPrinting" bzw. "-Milling" aufgerufen und darum die Matrix geladen.
Also denke ich, dass ich "nur wegen Z-Mode Surface" nicht doppelt die Matrix laden muss, das könnte ich nun im Mod ausbessern.)

--> ???? Ich lasse das Thema links liegen.

LG

Einige Links:
http://www.rf1000.de/viewtopic.php?f=67 ... ted#p24364
http://www.rf1000.de/viewtopic.php?f=4& ... ted#p23352

[hal4822]

... Ich habe den Heat BED Scan PLA ausgeführt. Das dauert ca 1h ...
... Brauchts den Z FOset scan?
gruss
siegi

Mir dauert das auch viel zu lange - aber eine Stunde ?
Und was ist bitte "Z FOset scan" ?

[trilobyte]

hmm... ich habe nachdem ich das geschrieben hatte noch einen scan gemacht. ich hatte einiges zum thema gelesen und also das filament und den transparenten schlauch zum druckkopf entfernt und es nochmals versucht mit kaltem drucker.
bis jetzt kam die meldung nicht mehr!

muss ich nach dem heatbed scan einen Z Ofset scan machen?

oben war noch die frage zu meinem vorherigen firmwarestand: da war wohl eine uralt original firmware drauf. mein vorbesitzer hat den Z endschalter geschrotet und dann die freude an dem drucker verloren. der stand jahre rum und wurde dann verkauft (an mich)
ich habe die 1.42.22 druaf gemacht.

gruss
siegi

[hal4822]

... mein vorbesitzer hat den Z endschalter geschrotet ...
gruss
siegi

Das besorgt der Drucker schon selbst ohne Zutun des Benutzers !