Kopf hoch, Nibbels wird dir helfen.

LG

Sodele

Es gibt da ein paar Hinweise, die ich noch loswerden könnte

Temperatur
Einer der Bugs war folgender: Im EEPROM ist z.B. Drive-Min = 40 und Drive-Max = 40 gelandet. Wenn das EEPROM nicht verworfen wird, wird der Bug übernommen. Ich habe da mal überlegt, eine Abfrage auf genau diesen Bug einzubauen, es aber seingelassen.
I-Drive-Max beschränkt die Summe des Integratoranteils auf "40" (Einheit/Skalierung weiß ich gerade nicht mehr)

Folgender Fix könnte dir helfen:
EEPROM bearbeiten und .... Teste mal, ob nach Änderung der Werte wie hier im Bild gezeigt deine Temperaturprobleme verschwinden.
Zudem ein Tipp: Menü -> Temperatures -> Extruder 0 -> PID-Pessen-Rule -> Ja.
Das führt ohne lästigen G-Code für ein Hotend den meiner Meinung nach besten Autotune aus und speichert den auch danach automatisch.
Das was du eben ändern solltest, "PID-I-Drive-Min und PID-I-Drive-Max" bedeutet, dass dein Integratoranteil in seiner maximalen Wucht beschränkt wird. Damit kannst du z.B. das Überschwingen etwas abdämpfen. Ist der Max-Wert zu klein, hast du quasi wieder einen PD-Regler der aber als PID ausgelegt ist und nicht gut funktioniert.
Ist der Min-Wert zu klein wird die Temperatur im Betrieb evtl. leicht oberhalb der Zieltemperatur verbleiben. 5 ist für mein Hotend perfekt. Trage zur Not 10 ein (oder mache 6..8 aus der 5) wenn deine Temperatur nach der Einschwingphase anschließend nicht ca. +-0.5 um die Zieltemperatur schwingt.

Dein zweites Problem kommt mir etwas unbekannt vor. Startest du "Scan", "Scan ABS", "Scan PLA"? .... oder Z-Offset-Scan? Der Z-Offset-Scan korrigiert deine Matrix nur auf die aktuelle Zieltemperatur, der verschiebt diese nur in ihrem Grundoffset. Das ist eine ganz schnelle Anpassung von z.B. ABS auf PLA oder andere Temperaturen. Ich scanne meist nur noch mit "Scan" und passe dann diese Grundhöhe mit dem Offset-Scan an.

Es gibt übrigends Wenn ich das richtig verstanden habe, macht diese bereits eingebaute Steuerung das was du wolltest - oder fast. Ich weiß aber nicht ob das funktioniert. Ich habe das auch nie getestet.

LG

Danke für die Infos, zum PID ich werde mich morgen drum kümmern. Ich hatte schon das Gefühl, daß die Grenzwerte für den I-Teil zu knapp bemessen sind, aber natürlich hatte ich mich drauf verlassen, daß es einfach so funzt.

Ich führe die Probleme mit dem HBS darauf zurück, daß ich XMax für den HBS Scan auf 240 gesetzt hatte. Denn dieser Wert wird selbstverständlich mit der Matrix mitgespeichert. Wenn sich der Max xWert verringert verschieben sich auch die Matrix elemente im Speicher und dann kann es zu Problemen kommen. Ich denke ich werde die Z-Matrix zuerst aus dem EEprom löschen und es dann nochmal versuchen.

Übrigens die neuen Grenzen für den HBS werden nicht separat im EEProm gespeichert, das heißt, beim nächsten Scan gelten wieder die Config werte. Das passt mir nicht, weil ich dran denken muß. Ich werde die Configwerte in meinem Changes einfach anpassen - wenn ich sie finde versteht sich

Ich habe PLA Scan und nur Scan versucht. Mit der alten Firmware hatte das geklappt, daher hatte ich ja auch den Mut weiter zu machen.

Was die Steuerung betrifft.. könnte sein aber mein kleiner Code tut niemandem weh.

Ich bleib am Ball

PeterKa

Ok

Ich glaube die veränderten Grenzen werden in der Config notiert, wenn man sie immer so haben will. Die Matrix ist so aufgebaut, dass die Grenzen und Punkt-Abstände mit im EEPROM gespeichert werden. Dem Z-Scan sollte also egal sein, ob die jeweils geladene Matrix zu alten oder neuen Scangrenzen passt.

Wir müssen beim Begriff EEPROM zwischen 2 EEPROM unterscheiden: Es gibt Speicher im Chip, der ist für die Settings für PID-Regeler, Z-Offset, ... und so.
Und es gibt einen extra aufgelöteten Chip: Da sind die Matrizen drin.
http://www.rf1000.de/wiki/index.php/GCo ... nes_EEPROM
Mit diesem Code habe ich mal versehentlich meinen aufgelöteten chip mitsamt aller HBS-Scan-Daten gelöscht. Das war bei mir n Vertipper: M3901 wurde zu M3091 und ich hab damals echt fast n Wutanfall bekommen, weil ich alles neu scannen durfte

So sieht übrigends der 40-40-Autofix aus: Ich teste das noch und spiele es hoch, sodass dieser Mist niemandem mehr den Tag verhagelt.

LG

Funktioniert.

Du kannst diese Werte übrigends auch jetzt schon einfach im Menü ändern:
Menü -> Temperatures -> Extruder 0 -> Ab Version 1.37w4 wird automatisch korrigiert, wenn diese zwei nun verbotenen Werte (-)40 und 40 parallel auftauchen.
https://github.com/Nibbels/Repetier-Fir ... 99e6118782
Klar hätte man das nicht tun müssen, aber so ist es am bedienerfreundlichsten, glaube ich.
Das ist ein Fix, den sich selbstverständlich auch Conrad abschreiben könnte

LG

Respekt, mechanisch und bzgl. Kontaktierung des e3d Hotend + Lüfter etc. eine gelungen Lösung würde ich von den Bildern her sagen.

So eine ähnliche Kontaktierung habe ich mir für den RF500 mit e3d inzwischen auch ersonnen.

VG,
Plastiker

Guten Morgen,

noch schlaftrunken habe ich heute morgen den Drucker angemacht und nach dem PID Autotuning gesucht... -5 bis 120 stand drin und das war ok. Tuning über das Menu gestartet, alles bestens. Die Aufheizkurven für Bett und Extruder sind jetzt einfach perfekt... Gemacht hatte ich in Wahrheit nix, nur einmal die EEProm Werte zurückgesetzt.

So, das ist ein eigentlich ganz toll, aber für mich als Programmierer (und Physiker) sehr unbefriedigend, und natürlich scheint es der Installationsanleitung zu widersprechen.

Ganz offensichtlich macht das Tuning über das Menu etwas anderes, als wenn man es per gcode anwirft. Erste Zweifel waren mir gekommen, als ich für das Bett "No Overshot" gewählt hatte, und mir die Heizkurve satte 10 Grad Überschwingen präsentierte, irgendwie passt das nicht in mein Weltbild.

Ich unterstelle mal, daß die Interpretation der GCode Parameter irgendwie fehlerhaft ist, insbesondere steht der Reglertyp in Verdacht. Könnte sein ,daß der über X0 nicht ins EEProm geschrieben wird sondern nur die Gains ? All sowas geht mir durch den Kopf.

Da ich nun mehr oder weniger unfreiwillig zum "Beta Tester" avanciert bin, könnte ich das als Bug an die Kommandozentrale melden Ich könnte aber auch versuchen der Sache auf den Grund zu gehen, vorausgesetzt, daß ich das reproduzieren kann. Ich finde es nämlich unbefriedigend wenn solche Dinge im Code stehen bleiben und nur Workarounds angeboten werden, auf die man ja ohne fremde Hilfe sowieso nicht kommt.

Ich kümmere mich jetzt erst einmal um den HBS.

PeterKa

Ich weiß was ich falsch gemacht habe. Die GCode Befehle im WIKI sind nicht korrekt beschrieben. Die einzugebenden Werte verstehen sich als Abstand von den Endwerten, ich hatte sie als absolute Werte angesehen, so hatte ich den WIKI Eintrag interpretiert. Ich habe bisher noch nie etwas da geändert, traue mich auch nicht^^ mag das jemand tun (M3024+3025).

PeterKa

So der Drucker ist fertig. HBS PLA, also das vorgefertigte Programm ist jetzt völlig problemlos gelaufen. Bisher hat er noch kein PLA in den Kocher bekommen.. Ich bin sehr neugierig wie das Kaugummitestprogramm von Nibbels funktioniert. Das steht jetzt auf der Agenda. Ich erhoffe mir davon konkrete Hinweise auf die optimale Temperatur.. errmmm also... wenn ich den wissenschafltichen Exkurs darüber richtig interpretiert habe

PeterKa

Cool

Ok, etwas weiter unten bei dem fettgedruckten Text ist evtl. schon die Lösung, aber dennoch:

Mal schnell die betreffenden Stellen raussortiert:
Dass es verschiedene Methoden in der Firmware gibt, stammt von mir, wenn wir hier noch einen Fehler eliminieren könnten, wäre es genial.

Die Einstellregeln sind von hier:
http://www.mstarlabs.com/control/znrule.html
Hier ist die Ausgabe der Methode als Text für die Logfile.
https://github.com/Nibbels/Repetier-Fir ... .cpp#L1344
Hier ist die Auswahl der Methode anhand des Schalters J.
https://github.com/Nibbels/Repetier-Fir ... .cpp#L1435
Hier wählst du per GCode die Parameter:
https://github.com/Nibbels/Repetier-Fir ... .cpp#L1289
Hier wählst du über verwirrende umwege der Menüstruktur übers Menü aus:
https://github.com/Nibbels/Repetier-Fir ... .cpp#L4221

Kurz erklärt: uid.menuPos[uid.menuLevel-2] ist die Position des ausgewählten Menüs von 0 beginnend 2 Menüs drunter: z.B. ist 0 = "Extruder 0"
(Der erste Extruder ist 0, Der letzte Extruder ist n-1, das Bett ist n.)
Das nächste "uid.menuPos[uid.menuLevel-1]" ist auch 0,1,2,3 .. die Stelle im Menü eins drunter, da hat man im Menü die Methode ausgewählt.
Das ist kompliziert, aber so konnte ich beliebig viele Hotends mit demselben Code unter Dach und Fach bringen und musste nicht alles doppelt im Klartext bauen. Das Bett ist immer bei. -> Ich sehe spontan auch jetzt mit etwas Abstand hier keinen Fehler.

Dass No Overshoot nicht so sauber funktioniert, wie ich das zuerst wegen des Namens dachte, war mir auch schon aufgefallen. Beim Hotend funktionierts nicht, beim Bett eher schon. Fehler konnte ich damals nicht finden, ich habs dann auf die Einstellparameter geschoben - dass die einfach nicht so gut sind.
Pessen Integral Rule war gut! Darum hatte ich die als Tipp für Hotends notiert.
Wenn du einen Unterschied zwischen Menü und GCode feststellen konntest: Kannst du das nachstellen?

Da gibts noch eine Sache: maxCycles mit GCode Schalter R.
Normalerweise war der immer auf 5 (Conrad, original Repetier). Ich habe aber gesehen, dass die Werte bis dahin noch nicht fertig konvergiert waren. Und darum macht das Menü automatisch immer R10 rein, wenn es ein Hotend ist. Und es macht R15 rein, wenn es ein Heizbett ist.
https://github.com/Nibbels/Repetier-Fir ... .cpp#L4234
https://github.com/Nibbels/Repetier-Fir ... .cpp#L4238
Reicht es evtl. den Standardzyklen-Zahl für immer und jeden auf Minimal 10 zu stellen, dass die Regelparameter niemals halbfertig erfasst werden?

LG