Die Z-Achse. Ein Faß ohne Boden ?

[AtlonXP]

Gut ich fange an!

FW 1.37X8, bin sehr zufrieden, bis auf ein paar Kleinigkeiten.
Da meine Kompenstion meistens nur +/- 0.02 mm hüpft kann ich dazu nichts sagen.
Ich war der Meinung die Schleicht aus. Bin mir aber nicht sicher!
Laut Peter tut sie das aber offensichtlich nicht!
Um es noch besser zu machen habe ich CMP auf 0.5 mm gesetzt.
Z Lift ist immer aus!
Die alte FW 91_48 meine ich hatte ausgeschleicht!
Die ist aber mit Arduino-1.0.6 meine ich zu flashen.

LG AtlonXP

[PeterKa]

Da ich ja mehrfach auf die Kühlung des Hotends angesprochen wurde habe ich jetzt eine kleine Reihe aufgelegt, die Solche Probleme in Angriff nimmt.

Der Trick den ich angewandt habe bestand darin, einen Luftwürfel zu drucken, sprich einen Würfel 2 cm überhalb der Platte. Geht wunderbar mit dem Slicer. Um nicht zuviel Material zu verbrauchen habe ich eine Pause von 12 Sekunden nach jedem Layer eingefügt, so daß der Druck etwa eine Stunde dauert. Das ist in Etwa die Druckzeit für meinen Flügel, der gegen Ende mit -10000 Digits daherkommt.

Ich habe dann immer die F-Werte aufgeschrieben (jeweils den niedrigsten Wert in jeder Runde).

Der Start war 2100 Digits + (was der Wert aussagt sei erstmal dahingestellt), nach 5 minuten +1100, nach 15 Minuten +760, nach 45 Minuten +520 und nach 1 Stunde +500.

Unter diesen Bedingungen hat als in einer Stunde der Innendruck um ca. 600 Digits erhöht. On der gleichen Zeit sinken bei meinem Flügrel die Digits von -3500 auf -10000. Das ist eine ganz andere Größenordnung bei vergleichbarer Extrusionsgeschwindigkeit.

Mit diesem Ergebnis weigere ich mich, die sehr minimale Umlenkung der Abluft an meinem Hotend als Ursache der Misere anzuerkennen, insbesondere werde ich sich nicht ausbauen, nur um mit meiner Erkenntnis anerkannt zu werden.

Ich habe den Gcode meines Flügels untersucht, was der so in der Z-Achse zu bieten hat.... er läift absolut sauber von 0,1mm bis 10mm hoch, da ist nichts falsch was die Z-Achse betrifft.

Schrittverluste in Z kann ich eigentlich weitgehend ausschalten, denn die Druckerzeugnisse sind maßhaltig. Die Untersuchung wäre auch schwierig. Auch einen wackeligen Z-Schalter oder Anschlag kann es nicht geben, erstens wackelt da nix und zweitens haben die langen Meßreihen (vor jedem Meßpunkt mache ich Home Axes !!!!) keine Hinweise darauf ergeben.

PeterKa

[AtlonXP]

Hallo PeterKa,
du hast leider einen sehr ausgeprägten Eigensinn.

Das Aufspielen mit der Mängeln behafteten FW 1.10, ohne dies Kund zu tun, war ein Schuss in den Ofen!

Aus diesem Grund muss ich leider fast deine gesamten vorgestellten Ergebnisse anzweifeln.
Das einzige was mir glaubhaft erscheint ist die Nachlängung deines E3D.

Schade um die vergeudete Zeit.

Ich gebe dir den Rat, deine Versuche so Praxisnah wie möglich umzusetzen.

LG AtlonXP

[PeterKa]

Mann mann, ich habe keine Fw 1.10 aufgespielt, sondern ich habe von Beobachtungen berichtet, die mir vor einem Jahr aufgefallen sind. Vermutlich ist sie sogar mit der 09.48 gemacht worden, zu der Zeit war mir das alles sehr egal, ich hatte einen Drucker gekauft, und benutzt. Mängel habe ich so gut ich konnte umschifft. Was für einen Strick willst Du mir daraus drehen ? Seitdem habe ich keine Flügel mehr gedruckt, weil mir zuviele kaputt gegangen sind.

Alles, alles was ich von Meßergebnissen berichtet habe ist mit der aktuellen Community FW gemacht. Den Bruch habe ich nur aufgeführt, damit er im Zuge der aktuellen Firmware bestätigt, oder widerlegt werden kann. Wenn ich das nicht vernünftig übergebracht habe bitte ich das zu entschuldigen.

Deinen Ausbruch verstehe ich nicht ich finde das total unfair, aber gut es ist wie es ist. Icch hab sowieso die Nase voll von dem Drucker.

PeterKa

PS: Wenn Columbus nicht so einen ausgeprägten Eigensinn gehabt hätte, wäre Amerika nicht entdeckt worden..

[PeterKa]

Ok, mag sein daß es niemanden interessiert, aber mich sehr...

Es geht um die Verifizierung, ob die Sollbruchstelle die ich vor etwa einem Jahr immer wieder beobachtet hatte nur Einbildung war.

Ich habe diese Messung sehr praxisfern gemacht. Aber jeder kann sie an seinem Drucker nachvollziehen. Es dürfte sehr schwer fallen dies zu ignorieren oder gar in den Bereich des Märchens zu verbannen, und es erklärt meine Probleme zum Großteil.

Die Idee: Wenn die Z-Kompensation ausschleicht, müsste ja ab irgendeinem Punkt die Differenz zweier kompensierter Werte exakt gleich der Schrittweite sein. Nun kann ich das sehr schwer in der Praxis messen, aber ich kann es nachstellen.

Ich wähle irgendeinen Punkt auf meiner Platte, hier habe ich meinen Standardpunkt gewählt, dessen Koordinaten und Z-Lage ich genau kenne.

Drucker ist kalt.. Meine Matrix und mein Ofsetscan stimmen überein und. Nach einschalten der Z-Kompensation fährt der Kopf an die Stelle Z-Comp, die man in der Scan Matrix als Z-Ofset findet. Außerdem habe ich um ganz sicher zu gehen und nicht angreifbar zu sein, den Z-Ofset im EEPROM (== M3006) auf 0 gesetzt.

Ich weiß aus den Parametern, daß die Kompensation bei Z= 3 beendet wird. Da da noch möglicherweise Ofsets dazugerechnet oder abgezogen werden, mag die Höhe etwas variieren.

Also habe ich ganz einfach die Höhe von Z=0 bis Z=4 in Zehntelschritten abgefahren, und mir die errechnete Z-Komp notiert. Diese wird auf dem Display angezeigt. Ist etwas mühsam, aber nach 20 Minuten ist man am Ziel.

Hier das Protokoll zum Nachvollziehen.

Z-Break.txt

Wer genau hinschaut, kann hier bereits das Problem erkennen. Aber ich habe es per Excel verdeutlichen können.

ZBreak.JPG

Der Peak... der dürfte nicht sein.. Das ist die Sollbruchstelle. Sie ist immer noch da. Die Kompensation schleicht nicht vernünftig aus.

Mein Verdacht hat sich also bestätigt. In der Firmware ist ein Bug, der dafür sorgt, daß dünnwandige Teile in 3mm Höhe eine Sollbruchstelle haben. Bei meinem flachliegenden Flügel ist der Peak in die andere Richtung, und die Digits steigen extrem an, und werden bis zum Ende des Drucks nicht mehr abgebaut.

Ich verzichte jetzt auf jeden irgendwie gearteten Kommentar. Aber berichten davon werde ich hier nichts mehr. Ich werde mit Nibbels daran arbeiten, daß das behoben wird, und dann seid ihr meine Litanei endgültig los.

PeterKa

[Jünni]

ne ne, nix ist endgültig.Ich verfolge das hier ja auch und sach mal: schön weiter machen.
Denn ich Druck seit gestern nur Flügel und staune was der verdammte Flügel für eine harte Nuss ist. Darum peterKa mach ja weiter ,mich interessiert das Thema sehr.
Mich reizt die Herausforderung und deshalb experimentiere ich hier fleißig rum . Ich hab bestimmt schon 20 Flügel gedruckt..... mein Schredder freut sich über das Futter
LG Jünni

[AtlonXP]

Hallo Peter,

diese Auswertung ist gut, wenn du auch die FW Version an gibst.
Dann, kann sogar ich was mit anfangen!

LG AtlonXP

[Digibike]

Na, dann seit Ihr ja wieder beisammen...! Nur so kommt man halt weiter. Kommunizieren ist alles, wenn man so
ins Eingemachte geht. Da ist essenziell, dass jeder vom gleichen Spricht und auch alle das wissen...! Da wurde dein
Einwandt halt falsch gedeutet, PeterKa, aber hat sich ja jetzt geklärt!

Gruß, Christian

[PeterKa]

Ich arbeite sein Wochen nur mit der letzten Firmware Mod, (das habe ich auch mehrfach erwähnt bzw es steht in den Prokollen) die ich mir als Betatester alle paar Tage von Nibbels herunterlade. Dieser Bug hier ist aber schon mindestens seit der 09.48 drin.

Ich habe mit Nibbels in den Code geschaut und auch die Stelle gefunden, was genau getan werden muß wird er sicher bald erzählen.

Wichtig ist nur zu wissen, daß diese Differenz nicht überall auf der Platte gleich ist. Die Stelle mit den kleinsten Z-Werten (Vorzeichen beachten!) ist die, an der der Fehler am signifikantesten auftritt. Die Auswirkungen auf das Modell habe ich in aller Ausführlichkeit weiter vorne beschrieben. Es ist umso schlimmer je schiefer das Bett und je größer das Bauteil ist... Logisch irgendwie. Ich habe instinktiv nach dem schlimmsten Punkt meines Bettes gesucht und so den Fehler deutlich machen können.

Jetzt aber genug.

PeterKa

[Nibbels]

Also das ist die Formel.
https://github.com/RF1000/Repetier-Firm ... .cpp#L2034

Etwas versinnbildlicht:

(long) nNeededZCompensation = g_offsetZCompensationSteps + (HöheÜberGrund_abh_XY - g_offsetZCompensationSteps) * (g_maxZCompensationSteps - angewieseneHöheZGCode) / (g_maxZCompensationSteps - g_minZCompensationSteps);

nNeededZCompensation -> Um diese Steps wird kompensiert.
g_offsetZCompensationSteps -> der höchste Punkt auf der Matrix. Der wirkt wie ein Offset.
g_minZCompensationSteps -> min Grenze 0.25 oder 0.33 o.ä.
g_maxZCompensationSteps -> max Grenze 3mm

In meinen Worten: "Wir begeben uns erst aufs Niveau des obersten Punktes der Matrix. Dann wird zwischen dem Oberflächenberührpunkt und diesem obersten Punkt der Matrix die Differenz gebildet. Diese Differenz wird mit einem Faktor multipliziert der die anteilige Länge (zwischen 3mm Höhe und kommandiertem GCode) / (3mm - 0.25mm) darstellt"

Der Fehler passiert wohl:
if( nCurrentPositionSteps[Z_AXIS] < g_maxZCompensationSteps )
{
... formel oben gilt hier, wenn ZGcode > g_minZCompensationSteps
}
else
{
nNeededZCompensation = g_offsetZCompensationSteps;
}

"Bei 2.9999mm gilt noch die Formel, bei 3.0 nur noch das Offset des obersten Matrixpunktes."

Da wird immer noch zusätzlich das M3006 Z-Offset draufgerechnet. Das verschiebt alles nach oben oder unten.
Meine Frage wäre nun, ob die Formel oben, als Long berechnet irgendwelche Probleme haben könnte??
Bisher scheint mir alles schlüssig. Gibts da irgendeinen Grenzfall, der nicht gehen könnte? Rundungsfehler bei kleinen Abständen?