Und schon wieder ein Crash

Hier könnt Ihr Probleme und Fragen zum Antrieb des RF1000 behandeln. Damit sind ausschließlich die Schrittmotoren, Kugelgewindetrieb und Zahnriemen gemeint
Benutzeravatar
Zaldo
Globaler Moderator
Globaler Moderator
Beiträge: 629
Registriert: Do 24. Sep 2015, 10:38
Wohnort: Raum Frankfurt
Hat sich bedankt: 38 Mal
Danksagung erhalten: 50 Mal

Re: Und schon wieder ein Crash

Beitrag #31 von Zaldo » Sa 10. Okt 2015, 22:14

Stefan baut Zeug hat geschrieben:
Wieso Bug ? Wenn der Heatbead Scan ergeben hat -0.2 (vom Endschalter) und ich will einen 0.3mm Layer dann muss der Kopf auf 0.1mm Fahren.. Bei mir geht das auch mal auf - ohne Probleme .

Alle anderen haben warscheinlich keinen erfolgreichen Scan gemacht oder den danach nicht ins EEPROM gespeichert :)


Das ist sicherlich richtig, dann dürfte der Extruder aber nicht auf der Platte schleifen.
Und den Heatbed Scan musst Du nicht manuell im EEPROM speichern (würde auch garnicht gehen, wenn das EEPROM in der configuration.h deaktiviert ist).
· Besserer Z-Referenzschalter · Druckbett Feinjustage · Platinenkühlung · Weiße Bauraumbeleuchtung · Not-Aus
· Dauerdruckplatte · Temperaturgeregelte Einhausung · Repetier Server auf Raspberry · MK8 Vorschubritzel

Gemelon
3D-Drucker
3D-Drucker
Beiträge: 80
Registriert: Di 9. Sep 2014, 07:22
Wohnort: nähe Regensburg
Danksagung erhalten: 5 Mal

Re: Und schon wieder ein Crash

Beitrag #32 von Gemelon » So 11. Okt 2015, 14:52

Hallo,
ich habe jetzt noch einige versuche gemacht. Es liegt scheinbar an meinen Slicer Profilen. Ich habe es wohl mit der First Layer Width etwas übertrieben. Ich habe den Wert etwas zurück genommen und jetzt scheint es zu funktionieren.
Seit 18.09.2014 Besitzer eines RF1000 Bausatzes.

Stefan baut Zeug
Developer
Developer
Beiträge: 103
Registriert: Mi 25. Nov 2015, 14:35
Hat sich bedankt: 5 Mal
Danksagung erhalten: 3 Mal

Re: Und schon wieder ein Crash

Beitrag #33 von Stefan baut Zeug » So 11. Okt 2015, 15:27

Noch eine Kleinigkeit zum Nachdenken..

So wie die Wiegezellen verbaut sind, stimmt der Abstand beim ersten Layer sowieso nicht wenn Ihr sagen wir 4000 Digits habt dann sind das ca. 0.1mm die es den Kopf nach unten drückt.. Somit wäre es klar dass er kratzt..

Blöd natürlich wenn man einen 0.1mm ersten Layer drucken will. (Abhilfe im Slicer 0,1mm Offset angeben)

mfg,
Stefan

RF1000
Developer
Developer
Beiträge: 340
Registriert: Fr 10. Okt 2014, 16:31
Hat sich bedankt: 40 Mal
Danksagung erhalten: 78 Mal

Re: Und schon wieder ein Crash

Beitrag #34 von RF1000 » So 11. Okt 2015, 16:53

Hallo Stefan,


So wie die Wiegezellen verbaut sind, stimmt der Abstand beim ersten Layer sowieso nicht wenn Ihr sagen wir 4000 Digits habt dann sind das ca. 0.1mm die es den Kopf nach unten drückt.. Somit wäre es klar dass er kratzt..


Die Digits haben keinen Einfluss auf die Z-Kompensation. Der Digit-Wert wird zwar beim Heizbett-/Werkstückscan verwendet um festzustellen, wann die Oberfläche erreicht worden ist. Währen dem Druck-/Fräsvorgang hat er aber keinen Einfluss auf die Kompensation - diese wird dann ausschließlich auf Basis der gescannten Matrix durchgeführt. Und, wie mjh11 richtig angenommen hat, wird für die Z-Kompensation zwischen den ermittelten Messpunkten linear interpoliert.


mfG
RF1000

Benutzeravatar
rf1k_mjh11
Developer
Developer
Beiträge: 1704
Registriert: Di 6. Jan 2015, 19:44
Wohnort: Autriche
Hat sich bedankt: 214 Mal
Danksagung erhalten: 434 Mal

Re: Und schon wieder ein Crash

Beitrag #35 von rf1k_mjh11 » So 11. Okt 2015, 17:51

RF1000,

Ich glaube auf was der Stefan anspielt ist die Thematik die in diesem Thread angesprochen wird.
Die Messzellen erzeugen ihr Signal als Folge einer (minimalen) Durchbiegung. Zeigt das Display einen hohen F-Digit-Wert (im Vergleich zum Ruhezustand), bedeutet das eine erhöhte Durchbiegung mit einhergehender Verminderung des Düsen-Bett-Abstands.

mjh11
Merke, am PC gibt es immer einen Weg!
Schafft es der Mensch, einmal etwas idiotensicher zu machen, kontert die Natur sofort mit einem besseren Idioten.

Stefan baut Zeug
Developer
Developer
Beiträge: 103
Registriert: Mi 25. Nov 2015, 14:35
Hat sich bedankt: 5 Mal
Danksagung erhalten: 3 Mal

Re: Und schon wieder ein Crash

Beitrag #36 von Stefan baut Zeug » So 11. Okt 2015, 18:59

Korrekt erklärt.

Aber meine Zahlen im Post waren falsch 4000-5000 Digits beim Druck sind in etwa 0,05mm die sich die Wiegezellen durchbiegen und somit den Abstand zur Druckplatte verringern. Bei einem ersten Layer von 0,1 schon ca. 50%

mfg,
Stefan

Benutzeravatar
riu
Administrator
Administrator
Beiträge: 1289
Registriert: Do 4. Sep 2014, 23:48
Wohnort: Düsseldorf
Hat sich bedankt: 48 Mal
Danksagung erhalten: 162 Mal
Kontaktdaten:

Re: Und schon wieder ein Crash

Beitrag #37 von riu » Mi 14. Okt 2015, 11:09

Gibt es eigentlich Neuigkeiten was die Firmwareversion angeht? Ich habe ja den Hinweis auf der Startseite mit der 0.91.48 - mich beschlaicht das Gefühl dass diese Firmware und auch die danach das Problem nicht beheben oder?

Lieben Gruß,
Udo

T1230
Developer
Developer
Beiträge: 139
Registriert: So 5. Apr 2015, 14:29
Hat sich bedankt: 11 Mal
Danksagung erhalten: 18 Mal

Re: Und schon wieder ein Crash

Beitrag #38 von T1230 » Mi 14. Okt 2015, 11:36

Hallo Udo /riu,

ich verwende seit ca. einem halben Jahr die FW .48, und habe seitdem ca. 10 Headbed Scans gemacht, alle mit
originalen Endstopschalter, und hatte bisher keine Probleme.
Ich denke nicht, dass man das generelle Problem des Überfahrens mit FW Änderungen lösen kann, sondern nur mit Hardware-Änderungen

http://rf1000.de/forum/elektronik/15-en ... mitstart=0 ... mitstart=0

Was aber (zumindest mMn) theoretisch funktionieren müsste, wäre die Homing Funktion so zu ändern, das bei aktiven Endschaltern ein Homing in die entsprechende Richtung nicht ausgeführt wird (z.B.: z-Endstopp Schalter ist gedrückt -> ändere die Z-Position beim Homing nicht).
Ich habe mich aber noch nicht genauer mit der FW beschäftigt, und kann daher nicht sagen, ob so etwas überhaupt möglich ist.

LG Thomas

Benutzeravatar
Zaldo
Globaler Moderator
Globaler Moderator
Beiträge: 629
Registriert: Do 24. Sep 2015, 10:38
Wohnort: Raum Frankfurt
Hat sich bedankt: 38 Mal
Danksagung erhalten: 50 Mal

Re: Und schon wieder ein Crash

Beitrag #39 von Zaldo » Mi 14. Okt 2015, 11:46

Der Drucker müsste in diesem Fall einfach 1mm LANGSAM nach unten fahren. Wenn dann Z immer noch geschlossen ist, mit Fehlermeldung anhalten (z.B. "Platform manuell aus dem Schalterbereich fahren"). Bei Fräsumbau und wenn die Plattform am unteren Schalter steht, dürfte nicht so viel passieren, wenn er versucht noch einen Millimeter tiefer zu fahren.

Aber vielleicht will C das ja garnicht ändern? Ist ein perfekter Absatzmarkt für Keramikplatten und Z-Schalter...
· Besserer Z-Referenzschalter · Druckbett Feinjustage · Platinenkühlung · Weiße Bauraumbeleuchtung · Not-Aus
· Dauerdruckplatte · Temperaturgeregelte Einhausung · Repetier Server auf Raspberry · MK8 Vorschubritzel

Benutzeravatar
Digibike
Globaler Moderator
Globaler Moderator
Beiträge: 2184
Registriert: Sa 6. Sep 2014, 13:19
Wohnort: Bei Heilbronn
Hat sich bedankt: 253 Mal
Danksagung erhalten: 373 Mal

Re: Und schon wieder ein Crash

Beitrag #40 von Digibike » Mi 14. Okt 2015, 12:02

Die idee ist gut Zaldo, aber was macht der, der auch Fräst...? Da ist es genau das Verderben...

Gar nichts in Z mit homing sobald ein Z Überfahren ist und im Display ´ne Fehlermeldung, unplausible Höhe wäre wohl am
sichersten... Dann ist egal, ob Zmin oder Zmax betätigt ist, bzw. gedruckt wird oder gefräst....

Gruß, Christian
Du suchst Hilfe bei Druck(er) Problemen? Dann lies bei der Anfrage hier "Lösung für Druckeinstellung/Hardwareprobleme gesucht?" durch und beantworte die
Fragen in deiner Anfrage - so wissen wir recht schnell, wo der Schuh drücken könnte!


Zurück zu „Antrieb“