Also ich muss da Zaldo recht geben. Die Firmware verhält sich nicht so, wie man es erwarten würde. Je nach "Vorgeschichte" (aber ansonsten gleicher Konfiguration) fährt sie beim Befehl "G00 Z0" an unterschiedliche Positionen. Das ist nach allen gängigen Definitionen ein Bug.

Mit Absicherung gegen Crashes bei Fehlbedinung hat das alles überhaupt nichts zu tun, denn beim ersten Mal fährt die Firmware ja an die erwartete Position. Das dürfte sie dann ja auch nicht tun.

Dass ein korrektes Verhalten in der (wirklich nicht gerade übersichtlichen) Firmware nicht leicht umzusetzen ist, hat niemand bezweifelt. Allerdings interessieren Implementationsdetails den Anwender herzlich wenig. Bug bleibt Bug, Workarounds zählen nicht. Die gehen nur für bestimmte Situationen. Der Bug ist in der Firmware, nicht im Slicer, denn der gibt ja die richtige Z-Position an. Sorry, RF1000, das sind doch alles nur Ausreden!

mhier hat geschrieben: Die Firmware verhält sich nicht so, wie man es erwarten würde. Je nach "Vorgeschichte" (aber ansonsten gleicher Konfiguration) fährt sie beim Befehl "G00 Z0" an unterschiedliche Positionen. Das ist nach allen gängigen Definitionen ein Bug.

Regel Nr. 42: G0/G1 kann Z-Min nicht überfahren, das ist kein Bug sondern eine ganz einfache, kristallklare Regel. Wenn man diese Regel im G-Code berücksichtigt dann bereits die aktuelle Firmware mit aktiver Z-Kompensation einen 1. Layer von (fast) beliebiger Höhe drucken.

mhier hat geschrieben: Mit Absicherung gegen Crashes bei Fehlbedinung hat das alles überhaupt nichts zu tun, denn beim ersten Mal fährt die Firmware ja an die erwartete Position. Das dürfte sie dann ja auch nicht tun.

In der aktuellen Firmware darf G0/G1 Z-Min nicht überfahren, die Z-Kompensation darf das aber schon. Von daher darf man erwarten, dass die Reihenfolge hier eine Rolle spielt und die "Vorgeschichte" sehr wohl relevant ist.
Dass es Anwendungsfälle gibt wo man diese Verhalten gerne geändert haben wollte heißt nicht automatisch, dass das bisherige Verhalten ein Bug ist. Es gilt weiterhin:

Wir prüfen bereits ob wir den Ansatz mit dem Überfahren von Z-Min durch G0/G1 umsetzen können oder nicht, weitere Überzeugungsarbeit ist vorerst also nicht nötig.

mhier hat geschrieben: Bug bleibt Bug, Workarounds zählen nicht. Die gehen nur für bestimmte Situationen. Der Bug ist in der Firmware, nicht im Slicer, denn der gibt ja die richtige Z-Position an. Sorry, RF1000, das sind doch alles nur Ausreden!

Ich denke nicht dass ich irgendwann von einem Bug in einem Slicer gesprochen habe.
Die Firmware ist so aufgebaut, dass bei einem Druckvorgang der folgende Ablauf erwartet wird:

- Z-Homing
- Z-Kompensation einschalten
- Z-Achse nur noch nach unten fahren

Dieser Ablauf funktioniert mit und ohne Z-Kompensation einwandfrei, soweit stimmen wir noch überein, oder?
Jetzt macht jemand folgendes:

- Z-Homing
- Z-Kompensation einschalten
- Z-Achse runter fahren (z.B. zum Erzeugen der Kalibrations-Raupe)
- Z-Achse wieder rauf fahren (zum Anfahren der Höhe des 1. Layers)

Das klappt exakt dann nicht, wenn die Höhe vom 1. Layer geringer ist als der Abstand zwischen Extruder und Heizbett bei der Z-Position 0 (also vorwiegend bei einem sehr großen Abstand und/oder bei sehr geringer Höhe vom 1. Layer. Es klappt dann deswegen nicht, weil Z-Min ausgelöst wird bevor die Z-Achse um den von G0/G1 gewünschten Weg nach oben gefahren worden ist (wegen Regel 42). Klar soweit?

Für dieses Scenario habe ich verschiedene Ansätze beschrieben, wie der 1. Layer korrekt gedruckt werden kann ohne dass Regel 42 verletzt werden muss. Wenn diese Ansätze (= "Workarounds") für dich bedeutungslose Ausreden sind dann kann ich da auch nichts machen. Ich hoffe aber, dass sie anderen Anwendern weiter geholfen haben.


mfG
RF1000

RF1000 hat geschrieben:Jetzt macht jemand folgendes:

- Z-Homing
- Z-Kompensation einschalten
- Z-Achse runter fahren (z.B. zum Erzeugen der Kalibrations-Raupe)
- Z-Achse wieder rauf fahren (zum Anfahren der Höhe des 1. Layers)

"Jemand" ist in diesem Fall der standardmäßig mitgelieferte Start-GCode. Genau dies tut er.

RF1000 hat geschrieben: Für dieses Scenario habe ich verschiedene Ansätze beschrieben, wie der 1. Layer korrekt gedruckt werden kann ohne dass Regel 42 verletzt werden muss. Wenn diese Ansätze (= "Workarounds") für dich bedeutungslose Ausreden sind dann kann ich da auch nichts machen. Ich hoffe aber, dass sie anderen Anwendern weiter geholfen haben.

Also zunächstmal lautet die Definition des Begriffs "Workaround" wie folgt:

Ein Workaround (englisch: für um etwas herum arbeiten; Behelfslösung) ist ein Umweg zur Vermeidung eines bekannten Fehlverhaltens eines technischen Systems.
Wikipedia

Ein eine fehlerhafte Funktion in einem Programm umgehendes Verfahren, das zum gewünschten Ergebnis führt, aber den Fehler nicht beseitigt
Duden

Das Problem bei den genannten Workarounds ist, dass sie alle nur einen Kompromiss aber keine zufriedenstellende Lösung darstellen.

Entlüftungsraupe flacher drucken, weglassen, stattdessen brim drucken: All dies geht einher damit, dass die zum entlüften erforderliche höhere Feedrate der Raupe nicht mehr gegeben ist (es hat ja einen Grund warum die besonders hoch mit hohem Materialfluß gedruckt wird).

Mechanischen Abstand verringern: Geht nur wenn das Bett sehr eben ist, Crashgefahr besteht zudem durch die thermische Extruderlängung.

Statischer Z-Offset: Fährt (zumindest mit der .59) ebenfalls nicht unter Z-Min.

...

Und so weiter.
Und diese ganze halbgare Bastelei nur, weil der Drucker aus welchen Gründen auch immer nur den ersten Fahrbefehl unter Z-Min erlaubt und alle weiteren nicht. Ich warte übrigens immernoch auf die Erklärung, wozu dieses "Feature" (ein Bug ist es ja angeblich nicht) gut sein soll.

Zaldo hat geschrieben: "Jemand" ist in diesem Fall der standardmäßig mitgelieferte Start-GCode. Genau dies tut er.

Das tut er unter bestimmten Voraussetzungen. In gewisser Weise liegt dieser Auslieferstand außerhalb des Wirkungsbereichs der Firmware. Wobei man an dieser Stelle die Abstimmung zwischen Firmware und mitgelieferten Start-GCode definitiv noch verbessern kann.

Zaldo hat geschrieben: Also zunächstmal lautet die Definition des Begriffs "Workaround" wie folgt:

Ich habe diesen Begriff exakt einmal verwendet, Bezug nehmend auf einen vorherigen Beitrag.

Zaldo hat geschrieben: Entlüftungsraupe flacher drucken, weglassen, stattdessen brim drucken: All dies geht einher damit, dass die zum entlüften erforderliche höhere Feedrate der Raupe nicht mehr gegeben ist (es hat ja einen Grund warum die besonders hoch mit hohem Materialfluß gedruckt wird).

Mechanischen Abstand verringern: Geht nur wenn das Bett sehr eben ist, Crashgefahr besteht zudem durch die thermische Extruderlängung.

Statischer Z-Offset: Fährt (zumindest mit der .59) ebenfalls nicht unter Z-Min.

Dann bliebe noch:
- Entlüftungsraupe drucken
- x/y/z homing
- Z-Kompensation ein
- mit dem Druck des 1. Layers beginnen

Zaldo hat geschrieben: Und diese ganze halbgare Bastelei nur, weil der Drucker aus welchen Gründen auch immer nur den ersten Fahrbefehl unter Z-Min erlaubt und alle weiteren nicht.

Kein G0/G1 kann Z-Min überfahren. Nicht der erste, nicht der zweite und auch sonst keiner. Regel 42. Die Z-Kompensation kann Z-Min überfahren. Die Z-Kompensation wird erst aktiv wenn per G0/G1 auf eine Z-Position > 0 fährt, von daher kann es für den schnellen Betrachter vielleicht so aussehen, als ob sich der erste G0/G1 Fahrbefehl anders verhalten würde als die nächsten. Tut er aber nicht.

Zaldo hat geschrieben: Ich warte übrigens immernoch auf die Erklärung, wozu dieses "Feature" (ein Bug ist es ja angeblich nicht) gut sein soll.

Regel 42. Wurde so definiert und ist im Moment daher so. Es gilt weiterhin:

Wir prüfen bereits ob wir den Ansatz mit dem Überfahren von Z-Min durch G0/G1 umsetzen können oder nicht, weitere Überzeugungsarbeit ist vorerst also nicht nötig.


mfG
RF1000

RF1000 hat geschrieben:Kein G0/G1 kann Z-Min überfahren. Nicht der erste, nicht der zweite und auch sonst keiner. Regel 42. Die Z-Kompensation kann Z-Min überfahren. Die Z-Kompensation wird erst aktiv wenn per G0/G1 auf eine Z-Position > 0 fährt, von daher kann es für den schnellen Betrachter vielleicht so aussehen, als ob sich der erste G0/G1 Fahrbefehl anders verhalten würde als die nächsten. Tut er aber nicht.

Es tut mir leid, aber das stimmt definitiv nicht. Ich hatte genau dies explizit getestet, eben diese Beobachtung gemacht, diese Beobachtung hier gepostet, und Du hast sie bestätigt!

http://www.rf1000.de/viewtopic.php?f=7& ... hren#p9784

Aber wir können ruhig Haare spalten, dann formuliere ich die Frage um: Warum kann die Z-Kompensation beim ersten Fahrbefehl unter "Z-Min" fahren, und beim zweiten nicht mehr?

RF1000 hat geschrieben: Wir prüfen bereits ob wir den Ansatz mit dem Überfahren von Z-Min durch G0/G1 umsetzen können oder nicht, weitere Überzeugungsarbeit ist vorerst also nicht nötig.

Hast Du Dir den Satz mittlerweile auf eine F-Taste gelegt? Diese monotone Wiederholung klingt wie eine Email vom Ebay Kundenservice...

Hallo RF1000

RF1000 hat geschrieben:

RFrank hat geschrieben:

RFrank hat geschrieben: Bei meiner Testerei habe ich jetzt wenigstens den Fehler isoliert, der mir soviel Stress macht, betrifft alle die Z-Schalter im Kreisbetrieb fahren.

Was genau meinst du damit?

mfG
RF1000

Mein RF1000 im Kreisbetrieb macht sich selbstständig, heißt ist einer der Z-Sensoren beschaltet, fährt er diesen frei (Das Bett fährt ca. 0,5mm nach oben Richtung Düse). Dieser Vorgang kann sich wiederholen, wenn der Schalter immer noch nicht frei ist, solange bis es knallt.
Beim Heat Scan wird ebenfalls oft gehomt (sieht doof aus), dies und ein Abruch des Scans kann an die Programstelle springen, wie nach dem START und fährt ggf. wie oben beschrieben.
Aufgefallen ist es mir das erste Mal als ich den Z-Schalter einstellen wollte, da sich da auf einmal der RF1000 bewegte.
Ich habe gelesen das eine Variable das STOPPEN kann, bei Z-Arbeiten am Schalter stelle ich vorher auf NORMAL bei den Endschaltern.
Ich hoffe das reicht um die Problematik zu erkennen.

Mit freundlichen Grüßen
Frank

Sorry RF1000, das stimmt so nicht. Vielleicht überfährt "G0 Z0" den Referenzschalter nicht, "G0 Z0.2" tut das sehr wohl bei eingeschalteter Z-Kompensation (sonst wäre die irgendwie sinnlos). Und das tut er eben nur beim ersten mal. Wenn ich zwischendurch wieder wegfahre (z.B. "G0 Z10") und dann nochmals "G0 Z0.2" sende, stoppt er beim Referenzschalter. Du kannst es drehen und wenden wie du willst, das ist nicht das Verhalten, dass man dem gesunden Menschenverstand nach erwarten würde. Wenn Software sich entgegen dem gesunden Menschenverstand verhält, ist das der gängigen Definition nach eine Bug. Mich hat dieser Bug schon mehrere Stunden Zeit und Meter Filament gekostet.

mhier hat geschrieben: Sorry RF1000, das stimmt so nicht. Vielleicht überfährt "G0 Z0" den Referenzschalter nicht, "G0 Z0.2" tut das sehr wohl bei eingeschalteter Z-Kompensation (sonst wäre die irgendwie sinnlos). Und das tut er eben nur beim ersten mal. Wenn ich zwischendurch wieder wegfahre (z.B. "G0 Z10") und dann nochmals "G0 Z0.2" sende, stoppt er beim Referenzschalter.

G0 Z0.2 kann nach UNTEN fahren, z.B. wenn die aktuelle Z-Position laut G-Code Z = 0 ist (also die Z Home Position). Beim nach UNTEN fahren wird Z-Min natürlich nicht geprüft.
Es ist nicht möglich, mit dem ersten G-Code nach dem Z-Homing nach OBEN zu fahren (weil nach dem Z-Homing ist Z = 0), und nur wenn der G-Code nach OBEN fahren will wird Z-Min geprüft.

Die Z-Kompensation läuft unabhängig von der Abarbeitung der G-Codes, von daher sieht es dem schnellen Betrachter vielleicht so aus, also ob "G0 Z0.2" Z-Min überfahren könnte. Kann es aber nicht, das Überfahren kommt von der Z-Kompensation. Das kann man nun gut, schlecht, logisch oder falsch finden, Regel 42 gilt in der aktuellen (und jeder vorherigen) Firmware trotzdem weil es nun einmal irgendwann so definiert worden ist.

Irgendwo habe ich es schon erwähnt: Wir prüfen bereits ob wir den Ansatz mit dem Überfahren von Z-Min durch G0/G1 umsetzen können oder nicht


mfG
RF1000


PS: Diese Z-Kompensationsthematik ist umgezogen und jetzt hier zu finden: http://www.rf1000.de/viewtopic.php?f=7&t=1242

It's not a bug, it's a feature. Ja genau. Jetzt sieh es endlich ein, das Verhalten ist falsch. Egal ob es dem definierten Verhalten entspricht, es ist nicht das Verhalten, was man erwartet. Egal wie das jetzt genau zustande kommt.

Die Beschreibung zu M3001 (übrigens sehr versteckt im C-Code, wer soll das eigentlich finden?) sagt nur "turn the z-compensation on". Das impliziert für mich erstmal keine Bewegung. Wenn ich mich gerade richtig erinnere, wird dann auch keine ausgeführt, sondern die nächste Bewegung durch einen G-Code entsprechend korrigiert. Letzlich ist es auch egal. Wenn ich folgendes hinschreibe:
dann fahren die beiden Befehle "G Z0.2" an unterschiedliche Positionen. UND DAS IST EIN VERDAMMT FIESER BUG! Auf den ersten Blick wirkt das wie unreproduzierbares Verhalten. Selbst für jemanden wie mich, der auf jahrzehntelang auf analytisches Denken trainiert ist, dauert das eine ganze Weile (sprich Tage, Wochen...?), das zu verstehen. Und jetzt wäre es vielleicht mal angebracht wenn ihr das offiziell als Bug anerkennen würdet. Ich erwarte ja gar nicht, dass ihr das sofort behebt...

Hallo zusammen
So ich habe fertig mit dieser Version, nachdem ich den Drucker im Pause Modus stehen sah, die Düse tief ins Bett eingetaucht.
Die Pause wurde durch Überlasterkennung eingeleitet. Bild muss 90° nach rechts gedreht werden.
Ich bin jetzt wieder auf Version 91.48. Gerne würde ich eine eine spätere (91.52-53) falls diese als STABLE gelten, installieren wollen. Auf Repetier finde ich nur ältere oder neuere Versionen (sofern ich sie überhaupt finde).
Schön wäre eine Download-Möglichkeit im Forum.
Ich fühle mich schon wie in der Apple Welt, wo ein Downgraden fast unmöglich ist.
Schade um die Zeit, die bei dieser Software Version schon geopfert wurde.
Der Crash erfolgte im 2. oder 3. Layer mit der alten Version lief es wieder rund.
Schön wäre eine Anleitung wie man ggf. an eine ältere Version kommt (bei mir wäre schön, wenn sie schon für das Fräsen vorbereitet wäre).

(Z-Endschalter Kreisbetrieb)

Gruß Frank