Hallo Matthias,

dann warte ich mal bis Ihr alle Eure Vellemanns zusammengebastelt habt und dann den Kopf und Schreibtisch wieder frei habt um die hier diskutierten Dinge in die Praxis umzusetzen.

Bin schon sehr gespannt was da von Euch kommt.

Viele Grüße
Joachim

Ich habe schon "Repetier" deswegen angeschieben. Mal sehen, was er meint (außer dass es wieder zusätzliche Arbeit ist)

Hi Sivar,
ich fürchte das wird nichts. Der "Flow-Regler" den du meinst ist doch die Konfiguration von Slicr3 oder Skeinforge. Also der Software, die den G-Code erstellt. Danach wird der G-Code von Repetierhost an den Drucker geschickt. Da ist dann schon alles zu spät.
Am leichtesten dürfte es tatsächlich sein es direkt in den Board-Computer des Druckers zu geben und in der Firmware auszuwerten (das ist mein Plan). Deshlab auch die Hardware mit dem Zeilensensor. Der lässt sich besser "embedded" verarbeiten als die USB-Kamera mit Visual Basic Auswertesoftware (so spannend das auch ist).
Gruss
Matthias

Hallo Matthias,

da bist Du leider nicht gut genug informiert:

In Repetier Host ist eine Flow-Regler integriert, der den Flow umgehend gemäss eingestelltem Wert regelt.

Ok, den hab ich noch nicht gefunden. Das ist natürlich was anderes.

Jepp, ich meinte schon den Regler in der Repetier-Host

---

Gruß
Boris
--
DIY Mendel90
Gen7 1.4.1 mit Repetier Firmware 0.91 + Repetier Host
Gen7 Extension Board mit LCD, SD-Card, Bluetooth und FAN-Control

Wo ist denn der Regler?

Unter "Manuelle Kontrolle" unterhalb des Geschwindigkeitsreglers. Bezeichnet mit "Flussrate"

---

Gruß
Boris
--
DIY Mendel90
Gen7 1.4.1 mit Repetier Firmware 0.91 + Repetier Host
Gen7 Extension Board mit LCD, SD-Card, Bluetooth und FAN-Control

Flowrate - rechts in der Mitte auf dem Screenshot:

[www.kalazzerx.com]

Hmm, den hab ich bisher übersehen... Heute Abend muss ich mal sehen ob der auch auf meinem Drucker-Rechner da ist.... *schäm*.

Hi Matthias,

wenn nicht einfach updaten auf den aktuellsten Softwarestand.

Gruß
Joachim

Wenn es in der Drucker Firmware wäre hätte es den vorteil das es auch mit octoprint funktionieren würde oder über ein LCD Controller Modul mit SD Karte.

@eytec You got it!

1-mal bearbeitet. Zuletzt am 12.09.13 08:08.

Schön wäre es wenn es erstmal überhaupt wäre....

Jack_n Wrote:
-------------------------------------------------------
> Schön wäre es wenn es erstmal überhaupt
> wäre....

---

Gruß
Boris
--
DIY Mendel90
Gen7 1.4.1 mit Repetier Firmware 0.91 + Repetier Host
Gen7 Extension Board mit LCD, SD-Card, Bluetooth und FAN-Control

Ja, da hast du recht Jack_n

Immer ruhig mit den jungen Pferden, das wird schon

Ich hab gerade mal n die Repetier-Host/Firmware geschaut. Sieht gut aus. Der g-Code "M221 Sn" mit n dem Extrusion flow multiplier in percent ist schon da wo er hingehört. Damit sollte die Änderung nicht mehr so schwierig sein (weit aus dem Fenster gelehnt).

Ziel ist es also aus welcher Maschine auch immer eine prozentuale Abweichung vom Sollwert herauszubekommen. Jetzt müssen wir nur noch wissen ob es die prozentuale Abweichung vom Soll-Durchmesser oder der Soll-Fläche ist.

Die Einspeisung in die Repetier-Firmware stelle ich mir trotzdem leichter auf dem Printer-Board vor, als in der Repetier-Host-Software. Immerhin haben wir es da nur mit einer Firmware zu tun und nicht mit Windows/Lunix/Mac.Wir werden sehen.

Hallo,
hier einmal meine Gedanken zu dieser Idee:
Also die Messung sollte so gemacht werden, dass sie auf einem Mikrocontroller stattfinden kann. Hier sollten Filamentdurchmesser und transportierte Menge gemessen werden. Diese beiden Werte könnten in der Firmware ausgewertet werden, um die Anzahl der benötigten Schritte zu berechnen. Dieser Regelkreis würde als Sollwert den Extrudervorschub mal einem festgelegten Vorschub als Volumen berechnen, und dann dementsprechend den Motor mit der korrekten Schrittanzahl ansteuern. Dies würde dann mit jedem Filament funktionieren, (egal welcher tatsächliche Durchmesser, denn der wird ja gemessen) So könnte man den Slicer konstant mit 3mm z.B. slicen lassen, und die Firmware stellt sicher, dass so viel Plastik aus der Düse kommt wie gewünscht.
Eine solche Regelung sollte in der Firmware einfach sein, wenn man die Rohdaten bekommt.
Eine Regelung nach der Firmware bei den Motorteibern halte ich für unpraktisch, da hier nicht bekannt ist wieviel Material aus der Düse kommen soll, sondern "nur" eine Anzahl Schritte über einen Zeitraum.
Aber wie man dies genau in der Firmware implementiert sollte man gucken, wenn man erst einmal die beiden benötigten Messwerte vernünftig bestimmen kann.
Hier finde ich die Kamera ganz nett, aber für nen Mikrocontroller wird das schwierig. Und den PC mit Windows zu nutzen ist Overkill. Allenfalls zum Testen der Grundidee dass man die Flußrate im Repetier Host nachregelt.
Dies hat aber auch den Nachteil, dass dieses Nachregeln einen nicht definierten Zeitversatz hat, da es in der Befehlsverarbeitung erst abgearbeitet werden muss. Einen direkten Eingriff in der Firmware könnte man so aufbauen, dass dieser auch den Abstand der Messstelle zum Schmelzpunkt mit einbezieht, und so die Werte auch wirklich im richtigen Moment verarbeiten kann.


cu

Michael

mcp Wrote:
-------------------------------------------------------
> Allenfalls zum Testen der Grundidee dass man die Flußrate im Repetier Host nachregelt.

So meinte ich das auch, erstmal schauen ob das überhaupt funktioniert.
Interessant wird das ganze dann auch im Zusammenspiel mit der Autotemp Funktion.

Im Endeffekt übernimmt die Firmware immer mehr und mehr die Aufgaben die sonst dem Slicer zukommen.

---

Gruß
Boris
--
DIY Mendel90
Gen7 1.4.1 mit Repetier Firmware 0.91 + Repetier Host
Gen7 Extension Board mit LCD, SD-Card, Bluetooth und FAN-Control

@mcp Du hast meine Argumentation sehr gut zusammengefasst Nur das (in meiner Planung) aus dem Microcontroller für Längen (Vorschub) und Dickenmessung nur ein Wert berechnet wird, nämlich das Volumen. Für die RepetierFirmware ist dann das Einspeisen des Wertes in die Berechnung "einfach", weil es ja schon die zentrale Stelle für eine Korrektur gibt. Das ganze bleibt dann auch kompatibel zum RepetierHost in dem ja auch die Flowrate Änderung eingestellt wird. Der Hook in der Firmware existiert schon
In der Datei Commands.cpp wird die Funktion change_flowate_multiply(prozentInInteger); aufgerufen. Die ändert die printer_state.extruderMultiply das ganze wird dann in der Datei motion.cpp ausgewertet. Der Wert wird z.B. in der Zeile 735 ausgewertet:

p->delta[3]=(long)((p->delta[3]*(float)printer_state.extrudeMultiply)*0.01f);

Ebenso in der Zeile 1008 der Funktion calcutate_dir_delta. Und in queue_E_move Zeile 1009 mit gleicher Berechnung.

Das sind die Fundstellen bislang. An genannten Stellen muss dann "nur" noch die zusätzliche Korrektur des gemessenen FilamentVolumens erfolgen.

Da die Längenmessung im Messgerät ein "retract" des Filaments mitbekommt, kann man die Korrekturdaten gleich entsprechend des bislang durchgelaufenen Filaments im Messgerät bereitstellen. Damit braucht man die Firmware nicht extra "belasten". Das Messgerät merkt sich eine Folge von Messwerten und behält noch einige der schon "rausgelaufenen" im Kopf, die es dann bei Retracts einfach wieder ausspielt (zu passender Zeit).

Konfuzius sprach...

Oh, oh, oh,

also bevor wir uns im kreis drehen und wirklich nicht mehr weiter wissen und noch monate damit verbringen darüber zu diskutieren wie, was und überhaupt sinnvoll, und auch machbar ist, sollte man einen kleinen blick in den schaltplan von RAMPS 1.4 werfen. Ich glaube, ohne dass ich jetzt in die tiefe gestiegen bin, zu glauben dass hierzu gar kein anschluss mehr frei ist oder zumindest nicht ausreichend anschlüsse vorhanden sind.

In wie weit mein unqualifizierter blick natürlich der wirklichkeit entspricht, naja, ich lasse mich des besseren belehren.

Ansonsten das toolhead über den schrittmotortreiber anzuschließen und hier einen übersetzer rein zu machen macht ja auch sinn für weitere funktionen die noch implementiert werden könnten.

Aber wie gesagt, ich lasse mich eines besseren belehren. I2C wäre noch eine möglichkeit, aber auch dafür benötigt man einen 2. controller ><.

Das was Joachim (habe jetzt nochmals nachgeschaut, nicht dass sich der Achim meldet), jetzt macht ist voll OK und wird zeigen in wie weit eine qualitätsverbesserung eintritt. Auf dieses ergebniss bin ich selbst schon gespannt. Er lebe hoch, sehr gut!!!! Ehrlich gemeint. Ich finde er macht sich sehr viel arbeit und wird hoffentlich das erhoffte erreichen. Es hilft uns allen.

Danke und Gruss
Mirco

Hi,
damit könntest Du aber nur die Dickeänderungen ausgleichen, dafür aber zeitlich korrekt ;-) Wenn nun aber der Vorschub aufgrund von Materialeigenschaften oder Verschmutzungen oder... nicht korrekt ist, so kannst Du dies dann nicht korrigieren, da du das Sollvolumen nur berechnet hast aus der Bwegung und dem Solldurchmesser. Deswegen würde ich in der Firmware beide Werte auswerten wollen. Dann kann an einfach in den Drucker stecken was man will.

Sag mal mir würde I2C als Kommunikation zwischen den beiden Controllern einfallen, ist in Repetier drin, und geht auch auf nem GEN7 wo nicht mehr so viele Leituingen sind, um ne Kommunikation aufzubauen...

Die Korrektur des Filamentdurchmesser gehört nicht wirklich in den Slicer, der soll doch nur das Modell in Scheiben zerlegen, und diese dann geschickt mit einer Plastikwurst füllen. Die Manipulation der Flußrate ist doch nur ne Krücke um das Problem in den Griff zu bekommen, das die echte Welt sich anders verhält als die Mathematik dies erklärt. Wenn wir den Drucker dazu bekommen auf Kommando die korrekte Menge zu drücken macht dies nicht den Slicer arbeitslos, noch nichtmal wird es für den Teil einfacher

cu

Michael

Also, ganz weit und tief und sowieso ausgeholt.

Ich weiß zwar nicht warum Du die dicke und den vorschub trennen würdest, für mich sind das die zwei geschichten die, die funktion ergeben. Also, dicke und vorschub auf einen controller, nennen wir ihn mal excon1.
Also excon1 nimmt die steuersignale vom repcon1 (tolle namen, reprap controller auf dem dann auch die repetier, marlin oder sonst was für firmware läuft). So verwurschtelt der excon1 nur das was den extruder angeht. Ob hier jetzt noch düsenreinigung, oder absperrung oder heben und senken der extruder mit dazu gemacht werden kann oder nicht, lassen wir uns mal überraschen, möglich wäre es.
Das system jetzt, in dem zustand, lässt nur begrenzt erweiterungen zu.
Das mit den slicer und filament und sowieso, ich glaube das ist klar, und war auch von anfang an klar.
Gruß
Mirco

Dem Slicer ist es bestimmt nicht egal ob 3 mm oder 1.75 mm verbraten werden. Bei dem dünneren Filament muss er sicherlich mehr Bahnen legen.

Und zur Frage des Anschlusses, da reicht ein freier Pin (digital I/O). Das Chip Select für die SPI. Clock und Signal können da problemlos geteilt werden und SPI wird sicherlich für LCD und SD Karte benutzt und die können ja noch an das Board gehängt werden. SPI Kommunikation von Arduino zu Arduino ist "einfach" das haben die Atmels von Haus aus "drauf".

Und JA Gratulation zu Joachims Einsatz und Software (Visual Basic ist nur so gar nichts für mich am Mac ). Aber Joachim will ja auch erstmal eine Lösung für sich bauen und das ist auch völlig ok und es zeigt uns ja auch reichlich was es überhaupt bringen kann.

Ich bin eher an einer etwas allgemeineren Lösung interessiert (bin halt ein Ingenieur), die auch von "jedermann" nachbaubar und einsetzbar ist. Deshalb meine Suche nach Standardteilen mit lötbaren Pins und einer Betriebssystem neutralen Lösung. Das ich die Firmware anpasse ist für mich auch logisch (technischer Informatiker) und darum kommt man ja auch kaum herum. Die Verbindung des zu bauenden "Messgerätes" (für durchgelaufene Länge und Durchmesser (3mm oder 1.75mm)) mit dem Printerboard via SPI ist auch eine Standardschnittstelle für Mikroprozessoren und man kann am Messgerät auch genauso eine Variante mit I2C oder RS434/RS232 oder CAN Bus anbauen/ausdenken. Das ist dann nicht mehr das Problem.

P.s.: Ich verdiene mein Geld mit einer Firma für Web Applications, hab also keine kommerziellen Interessen (mich würde es aber auch nicht stören mit 3D Druckern Geld zu verdienen das ist aber definitiv nicht mein Plan).

Also die Filamentdicke ist der Software doch egal, oder irre ich mich da?
Entscheidend ist der Düsendurchmesser und welchen Volumenstrom man durchjagt.

Ich würde vielleicht eine weniger elegante Möglichkeit andenken: Man nimmt irgend einen extra Controller der die Messerei macht, der empfängt die Pulse die eigentlich der Stepper-Treiber bekommt, und je nach Filamentdicke manipuliert er de Pulsfolge (strecken oder stauchen) und gibt die korrigierten Pulse an den Stepper weiter. Das hätte den Vorteil, dass man die Firmware nicht manipulieren muss.

@Itzi
SAG ICH DOCH SCHON DIE GANZE ZEIT!
Übrigens ist das die elegante lösung.

Übrigens, stimmt dem slicer ist das egal, wobei die kalibrierung des slicers davon abhängt. Die muss nach wie vor passen, aber, jetzt kommt das aber, wie wir alle wissen ist das filament nicht immer konstant und, jetzt kommt nochwas, hat der blöde extruder auch manchmal seine fehler. Und damit können wir diese dann auch erschlagen.

Ja natürlich dürfte es der Düsendurchmesser sein... sorry Man soll ja auch nicht arbeiten und nebenbei seinen Senf in einem Forum abliefern...

Hi,
also
1) Pulse Strecken oder Stauchen bringt nichts. Es zählt nur die Anzahl der Pulse und die Zeit.
2) SPI vom Atmel ist meist durch SD-Karte belegt und sollte auch dieser gehören.
3) Anzahl der Bahnen hängt nur an der Düsengröße.
4) Ich verdiene mein Geld als Dipl. Inf. Univ. (Bayern) mit der Entwicklung von embedded Steuerungen und nicht mit RepRap, kein Ingenieur, halt Informatiker.
5) Man muss halt doch gucken welche Schnittstellen man hat, und ob man diese ohne großen Zeitbedarf auf dem Drucker Kontroller bearbeiten kann. Kein Pollen eines IO-Pins... Dafür hat nen AVR im RepRap keine Zeit.
6) Mein Ziel ist es trotz widriger Umstände gute Druckergebnisse zu bekommen. Diese werden durch das Volumen pro Zeit bestimmt. Dieses ergibt sich aus Durchmesser und Vorschub. Ziel muss es sein, dieses Volumen den Vorgaben des Slicers möglichst genau anzupassen. Diese Information hat nur die Firmware, nicht der Teil der den Extruder Motor ansteuert. Um aus den Motordaten auf das Volumen zu schließen, mußt Du auch die Bewegungsdaten der Achsen haben.
Was wir erreichen wollen ist, daß der Drucker, das vom Slicer vorgegebene Volumen innerhalb einer Bewegung liefert. Dies macht die Firmware schon wenn sie Beschleunigung der Achsen mit in die Anzahl der Schritte pro Zeit in den Extruder einfliessen läßt somit kannst Du an der Stelle nur ungenau eingreifen.
7) LCD ist meist parallel angeschlossen, oder per I2C. CAN und RS485 sind meist nicht verbaut bei den
RepRap PCBs. RS232 ist meist min. 1 durch USB belegt. (FDTI, MCP2200, Atmega16Ux ...)

cu

Michael

PS: E l e k t r o n i k e n scheint ein böses Wort zu sein...

3-mal bearbeitet. Zuletzt am 12.09.13 17:59.

Hi Michael,
zu deiner Liste:

zu 1: sehe ich genau so
zu 2 und 5: SPI soll auch weiterhin der SD Karte dienen. Aber SPI kann ja auch mehrere Bausteine bedienen. Jeder brauch ja nur seinen eigenen Chip Select und dafür wird der IO (genauer der O) Pin gebraucht."
zu 5: nix pollen nur Chip Select für die SPI Kommunikation mit dem Messgerät. Das Messgerät ist dabei ein "Slave" wird also "ab und zu" per SPI abgefragt. Dabei werden ja nur einige wenige Bytes übertragen. Es sollte also wirklich schnell gehen und durchaus "abgestimmt" mit den Zugriffen auf die SD Karte.
zu 7: ist schon klar aber wer weiss welche Controller noch mal so verbaut werden

Ein Beispiel für SPI der mit mehreren Bausteinen ist z.B. das Ethernet Shield mit SD Karte für den Arduino. Jede Komponente hat ihren eigenen Chip Select in teilt sich das SPI.

Gruss
Matthias

Nett ideen, die hier ausgetauscht werden. Hier mal ein paar anmerkungen zu r Umsetzung

1. Der flow multiplier ist schon mal ein netter Ansatz, aber man sollte dabei wissen das die Genauigkeit hier begrenzt ist und nur längere strecken korrekt mehr flow erhalten. Das warum ist recht einfach. Für jeden move wird die Anzahl der steps genommen und mit dem flow multiplier multipliziert. Ergibt sich aufgrund einer kleinen Schrittzahl keine Änderung, wird die additiion ignoriert. Ich denke ich sollte da noch einen Fehlerterm einfügen, der den rest bei der nächsten berechnung wieder hinzuaddiert und so das problem mathematisch korrekt löst, was allerdings wieder mehr rechenzeit benötigt.

2. Flow erhöht das Volumen linear, der Druchmesser quadratisch, muss also bei der Anpassung des multpliers berücksichtigt werden.

3. Die Änderungen host seitig mitzusenden scheint zwar die eingachste Lösung zu sein, ist aber eher ungenau. Dank Pfadplannung und buffer müst ihr davon ausgehen das erst noch 20 moves abgearbeitet werden, bis die Änderung wirksam wird. Ändert sich der Durchmesser nur sehr langsam spielt das natürlich keine Rolle, aber ansonsten müste der Abstand zur Messung mit den extruder steps synchrinisiert werden. Wenn also der abstand Düse - Messtelle 10000 steps beträgt, könnte man alle 1000 steps eine neue Messung machen und in einem Array speichern. Mit jedem Schritt werden die runtergezählt und der mit dem kleinsten Abstand bestimmt den multplier.

4. Wie bekommen wir daten in die Firmware? Egal wie, es muss im Hauptthread geschehen, da wir im Timerinterrupt kein spi, i2c etc nutzen dürfen. Dies würde die abfrage im Hauptthread stören und zum Absturz führen. Auch ist der flow multiplier genau so schwer zu setzen wie im host, da der multiplier im Pfadplanner ausgewerted werden würde. Im neuen Host könnte man das ganze elegant lösen, indem man den multiplier in den step befehl verschiebt. Hier sollte der Multiplier dann idealerweise unter 100 liegen um nur schritte auszulassen, da die Routine nicht häufiger aufgerufen wird, wenn das nötig wäre. In dem Fall müsste dann ein Doppelshritt ausgeführt werden oder die echte Motorsteuerung des Extruders in den Extruder interrupt verlagert werden. Dann wären auch multiplier größer 100 möglich.

5. Wo bekommen wir die Daten her? Hier gibt es ja schon einige Ideen die alle mehr oder weniger einfach umzusetzen sind. Kameraauswertung ist nett um die tatsächliche Schwankungsbreite zu beobachten, aber als alltagslösung für die meisten zu umständlich. Einfacher wäre eine Messung von Magnetstärken. Meine Idee, falls noch nicht vorgestellt, wäre zwischen federnd zusammengepressten rollen einen Magnet am beweglichen Teil zu befestigen und gegenüber einen Magnetfluss sensor. Mit entsprechender Calibrierung könnte man aus der Magnetfeldstärke die Dicke ableiten.

Da ich im Mment ziemlich Eingespannt bin mit anderen Problemen, kann ich hier derzeit nicht richtig aktiv werden, aber bei Fragen stehe ich gerne zur Seite.

---

Repetier-Software - the home of Repetier-Host (Windows, Linux and Mac OS X) and Repetier-Firmware.
Repetier-Server - the solution to control your printer from everywhere.
Visit us on Facebook and Twitter!