Okay, ich habe jetzt notgedrungen auch die Version 01.31 installiert. Aber irgendwas stimmt hier nicht!

Z-Indexschalter ist auf Bettmitte auf 0,5mm eingestellt
Ich habe HBS-PLA gemacht.
Dann habe ich die Bettmitte auf Höhe Z=0.20mm angefahren
Mittels Fühlerlehre habe ich per statischem Z-Offset am Drucker die Höhe korrigiert (-25µm).

So. Ich sende nun den folgenden G-Code an den Drucker:
Stecke die Fühlerlehre zwischen Bett und Extruder, und es sind exakt genau 0,2mm. Soweit so schön, aber:

Nun sende ich GENAU DEN SELBEN GCODE EIN WEITERES MAL AN DEN DRUCKER

Und der Abstand beträgt nun 0,7mm
Das Z-Display (Eingestellt auf surface) zeigt jedoch die korrekte Höhe an (0,20 - 2,5 offset = 0,17) - Wobei die Frage erlaubt sein darf, ob es korrekt ist, den Offset abzuziehen, denn der ist ja eigentlich da um die Höhe zu korrigieren, somit ist die 'bereinigte' Anzeige von 0,17 ja auch falsch...

Weiteres Wiederholen des GCodes ändert hieran nichts mehr.

Erst nach einem Neustart des Druckers, oder "Output Object" führt dazu, dass der vorstehende GCode auf 0,2mm fährt.
Wiederholtes ausführen dieses GCodes führt abermals zu einer Höhe von 0,7mm

Ab da wiederholt es sich, das Spiel kann beliebig reproduziert werden.

Hallo Zaldo,

Interessante Feststellung.
Das einzige, dass mir dazu einfällt, ist, dass du eigentlich zwei mal hintereinander den Code an den Drucker sendest.
Das ist nicht unbedingt üblich (nicht direkt falsch, einfach ungewöhnlich). Kann es sein, dass hier die Firmware falsch (verbugged) reagiert?
Alle anderen GCode Befehle werden üblicherweise öfters an den Drucker gesandt.

Versuche, beim zweiten Senden des GCodes, vorher mittels M3000 die Z-Kompensation auszuschalten. Wenn der Fehler nicht mehr auftritt, hätte man den Fehler zumindest eingegrenzt.

mjh11

Das ist auch mein Gedanke. Müsste der FW aber eigentlich egal sein.

Der Hintergrund (bei mir) ist, dass ich diesen Codeschnipsel im Repetier Server als Befehl abgespeichert habe. Nach dem aufheizen führe ich den Befehl aus, und kontrolliere dann die Höhe mit der Fühlerlehre. Starte ich danach meinen Druck (ohne Output Object zu machen) hat der dann natürlich die 0,5mm Versatz drin, da der Slicer ja auch ein M3001 in den Code schreibt.

Testweise kann ich das mal probieren, in meinem Befehl ist das natürlich nicht praktikabel, denn wenn der die Kompensation gleich wieder abschaltet kann ich ja meine Höhe nicht messen. Dann müsste man schon wieder mit Pause/Continue oder einem Extra Befehl zum ausschalten der Kompensation arbeiten (und den niemals vergessen)

Zaldo,

Zaldo hat geschrieben:Starte ich danach meinen Druck (ohne Output Object zu machen) hat der dann natürlich die 0,5mm Versatz drin, da der Slicer ja auch ein M3001 in den Code schreibt.

Den zusätzlichen M3001-Befehl kannst du natürlich aus dem Start-GCode des Slicers streichen. ... Aber nicht gleich ...

Man sollte zuerst feststellen ob das Problem wirklich vom (überflüssigen) zusätzlichen M3001-Befehl verursacht wird. Dazu müsstest du nur den Test einmal machen, um zu sehen, ob dort wirklich der Hund begraben liegt.

Ich habe eben deinen GCode-Schnipsel 2 X in eine Datei kopiert und über Repetier-Host ablaufen lassen. In der Tischmitte habe ich 8 Sekunden warten lassen, um Messen zu können.

Ich konnte keinen deutlichen Abstandsunterschied feststellen (ohne Fühlerlehre - ich habe 'nur' eine Visitenkarte + 1 Blatt Papier verwendet). Ich habe die RF.01.31 in Verwendung.

mjh11

Ich habe es jetzt nochmal ausprobiert, und es scheint wahrlich am einschalten der bereits eingeschalteten Z-Kompensation zu liegen. Wenn ich den (jeden) Code mit M3000 beginne, also sicherstelle dass die Z-Kompensation auf jeden Fall ausgeschaltet ist bevor sie eingeschaltet wird, tritt das Problem nicht mehr auf.

Das deckt sich mit der Beobachtung, das "Output Object" die Kompensation (deren Status man ja nun auch am Display ablesen kann) ebenfalls ausschaltet.

Hallo,


wir haben das mit der RF.01.33 korrigiert. Siehe http://www.rf1000.de/viewtopic.php?f=67&t=1456.
Das bisherige clean-up nach dem Homing der Z-Achse war für dieses Szenario falsch. Jedes Homing der Z-Achse schaltet die Z-Kompensation nun aus, was den gleichen Effekt wie euer Workaround mit M3000 hat.


mfG
RF1000

Hallo an die Spezialisten,

ich würde gern die neueste Firmware auf meinen RF1000 aufspielen, habe aber, nachdem sich das Original-Hotend verabschiedete
und dieses sowieso Probleme mit ABS hatte, nun einen E3D montiert. Mein Problem: Was muss ich nun in der Configurations.h
ändern, bzw. wo trage ich die nun fällige neue Temperatur/Widerstandstabelle für den im E3D montierten
Thermistor 104-GT2 ein? Bisher konnte man ja einfach einen anderen Sensortyp auswählen, diese Zeilen existieren aber in
der neuen Configurations.h nicht.

Die alte Configurations.h habe ich nach einem PC Absturz leider auch nicht mehr, wahrscheinlich würde sie aber
auch nicht korrekt compilieren, oder?

Kann jemand helfen? Ich habe inzwischen leider Null Durchblick...


Herzlichen Dank schon jetzt
Peter

Peter/RFPitter,

Viele der Einstellungen, die früher in der Configuration.h untergebracht waren, haben in den neueren Firmware Versionen (ab RF.01...) ein neues Zuhause in der RF1000.h gefunden. Unter Anderem auch die Einstellung für den Thermistor des Hot Ends und des Betts.

In den neueren Versionen wurden auch die alternativ möglichen Einstellungen durch den Rost fallen gelassen. Der Grund könnte sein, dass sich 'C' sagt, "in meinem Gerät gibt es nur den einen Sensor, wieso eine Liste mit zig anderen dauernd mit schleifen?". Jedenfalls waren in den älteren Versionen noch folgende Sensortypen angeführt (Auszug aus der Configuration.h der Version 0.91.53):

// What type of sensor is used?
// 1 is 100k thermistor (Epcos B57560G0107F000 - RepRap-Fab.org and many other)
// 2 is 200k thermistor
// 3 is mendel-parts thermistor (EPCOS G550)
// 4 is 10k thermistor
// 8 is ATC Semitec 104GT-2
// 5 is userdefined thermistor table 0
// 6 is userdefined thermistor table 1
// 7 is userdefined thermistor table 2
// 50 is userdefined thermistor table 0 for PTC thermistors
// 51 is userdefined thermistor table 0 for PTC thermistors
// 52 is userdefined thermistor table 0 for PTC thermistors
// 60 is AD8494, AD8495, AD8496 or AD8497 (5mV/degC and 1/4 the price of AD595 but only MSOT_08 package)
// 97 Generic thermistor table 1
// 98 Generic thermistor table 2
// 99 Generic thermistor table 3
// 100 is AD595
// 101 is MAX6675
// 102 is MAX31855

#define EXT0_TEMPSENSOR_TYPE 3

Der Liste nach müsstest du in der RF1000.h den entsprechenden Wert der Zeile (ca. die 273. von oben) von 3 (Standard) auf 8 ändern. Es gibt schon einige im Forum, die den E3D im Einsatz haben. Vermutlich könnten die das bestätigen.

mjh11

kann ich so bestätigen:

#define EXT0_TEMPSENSOR_TYPE 8

gilt für den Cartridge und den alten glasthermistor sensor
wie es beim PT100 ausieht müsste man noch schauen

Hallo Leute,

ich bekomme jedesmal die Fehlermeldung beim kompileren folgende Fehlermeldung

exit status 1
pasting "/* PINB.3, 22, MISO*/" and "_DDR" does not give a valid preprocessing token

was mach ich falsch?

Kann mir jemand helfen?

Gruß Megaastro