Black Corner

Hallo Zusammen,



Ja nachdem ich endlich mal ein paar Tage Urlaub hatte, habe ich angefangen einen neuen Drucker (mein 6. ) zu bauen. Wenn man so viele Drucker baut birkt ein Neuer kaum noch Herausforderungen.
Mein Augenmerk bei diesem Projekt liegt darauf das von Anderen erfundene Rad im Alleingang selbst mal aus dem Eckigen zu schnitzen.
Ich will also versuchen den Drucker von A-Z selbst zu entwickeln:

1. Konstruktion
2. Elektronik
3. Firmware
( 4. Hostsoftware , 5. Slicer ) Bin ich noch am Überlegen ob ich mir das antue



Punkt 1 und 2 sind nichts Neues für mich . Punkt 3 ist Neuland. Mir geht es in erster Linie nicht um das perfektes Druckergebnis sondern eher darum das komplette System zu Begreifen und zu Verstehen. Ich erfreue mich eher an dem zusätzlichen Wissen.

1. ) Konstruktion:
Ich hab 2 Tage konstruiert . Den mechanischen Aufbau wollte ich schnell erledigt haben. Teile wollte ich auch keine neuen kaufen deshalb hab ich versucht alles was ich auf Lager habe zu verwenden. Der Aufbau ist dem Prusa nach empfunden . Und ich wollte Ihn unbedingt hässlich haben. Bei meinen anderen Druckern kam immer "Design vor Funktion" und ja das hemmt.



X und Y Achse sind nahezu identisch aufgebaut . Als Antrieb kommt ein Nema23 zum Einsatz. Das Umlenkritzel ist an einem Nema17 Motor geschraubt der nicht bestromt wird. Vielleicht ist das für Manche Geldverschwendung aber ich hab über 20 Nema 17 in ner Kiste rumfliegen also was solls.



Ansonsten...Über Z hab ich auch einen Riemen laufen der von 2 Nema17 gezogen wird mit einem einfachen Flachenzug . Gewindespindeln mag ich in Druckern nicht mehr.
Der Rahmen besteht aus 20er Aluprofilen immer mit nem PVC Frästeil verschraubt. Der Mechanische Aufbau hat auch 2 Tage gedauert dann stand er . Extruder hab ich mir noch keinen ausgedacht . Ich wollte schnellstmöglich mit dem Programmieren beginnen.



2. ) Elektronik:

Ja schnell schnell sollte es gehen.. Also erstmal nur das nötigste verdrahtet für erste Test als Motor Endstufen für X und Y verwende ich DQ860MA Endstufen wegen dem hohen Microstepping hab ich mit ruhigem Lauf gerechnet ...
Naja von Leise kann keinesfalls die Rede sein. Für den Rest ( 2x Z + E ) halt TB6600 Endstufen. Hab ich alles Mehrfach daheim rumfliegen (was man halt so kauft über die Jahre ) . Dann noch China große China Endschalter .
Als Controller ein Due Clone mit ner gelöteten Platine mit +5V Level-Convertern.



Ich gehe davon aus das meine Firmware nicht so viel Performance bietet , deshalb hoffe ich einfach das der ARM Controller genug Rechenleistung mitbringt. Weiterhin glieder ich die PID-Controller für Düse und Bett aus. Bedeutet die Temperatursteuerungen bekommen jeder ein eigenen Arduino Nano. Aber das ist noch Zukunftsmusik.

Ja nach 2 Tagen verkabeln Kann X und Y angesteuert werden. Danach ging es sofort aus der kalten Werkstatt raus , rein in die Stube zum Programmieren





3. ) Firmware:

Seit 4 Tagen bin ich am Firmware programmieren und es macht richtig viel Spaß. Unterstützt wird bis jetzt nur G0 / G1 und G28 .
Angefangen habe ich damit das Serielle Befehle in Variabeln übersetzt und in einen Buffer geschrieben werden.
Der Mainloop arbeitet dann Stückweise die Befehle ab .

Danach kam das Setup für G1 .

Errechnen der Deltas . Setzen der Direction Pins. Breseham wurde implementiert . Über eine Lookup Table hab ich das Ermitteln der Schritt-Frequenz gelöst. Danach kam die Beschleunigung dran.

Im Moment arbeite ich am "look ahead planner" . Das wird mich auch noch einen Moment kosten.

---

Mein Club: [hackerspace-ffm.de]
RADDS-Shield -> Commercial [max3dshop.org]

Hallo Zusammen,

Ja Mechanisch hat sich nichts verändert deswegen heute keine Bilder.

Im Moment mache ich es so, dass sobald eine große neue Funktion in die Firmware implementiert wurde, ich alle Dateien unter einer neuen Version speichere. Für den Fall das ich mal Müll programmiere greife ich dann auf das Backup zurück. Im Moment gibt es 3 Versionen . In jeder hab ich die Beschleunigungsberechnung für die Achsen anders umgesetzt.

Angefangen hab ich damit einen Interrupt im Interrupt zu generieren der immer im gleichen Takt die Geschwindigkeit um 1mm/s verändert sollte die aktuelle Geschwindigkeit nicht der Zielgeschwindigkeit entsprechen. Leider war die Berechnung für den Abbremspunkt nicht 100% . So kam es das die Motoren immer Abgebremst haben auf Minimalgeschwindigkeit (10mm/s) und dann ich dieser Geschwindigkeit noch 2 -5mm weitergefahren sind.

In der zweiten Version hab ich nochmal das Physikbuch aufgeschlagen und die Geschwindigkeiten im Hauptinterrupt ausgerechnet. Ich hab versucht alles soweit wie möglich auszuklammern. Jedoch musste ich am Ende immer nochmal Dividieren und die Wurzel aus einer Variabel ziehen. Und siehe da schneller als 80mm/s konnten die Achsen nicht mehr fahren. Also war das Due überlastet.

In der jetzigen Version hab ich es ganz ganz ganz einfach gemacht nach einem nach einer bestimmten Anzahl von Interrupts wird Speed erhöht oder eben gesenkt. Das funktioniert wunderbar aber die Beschleunigung ist eben nicht mehr gleichbleibend sondern sie nimmt zu mit steigender Geschwindigkeit. 100% glücklich bin ich damit nicht aber es bleibt jetzt erstmal so.

Die Z-Achse hab ich jetzt auch mal angesteuert und sie schafft immerhin 125mm/s . Vielleicht werde ich wirklich mal wieder mit Z-Lift drucken :-)

Der "look ahead planner" ist auch ganz ok noch nicht perfekt aber brauchbar.

Also ich weiss nicht ob es an meiner "Super tollen" Firmware liegt oder an dem Due oder an den Nema23. Aber so schnell konnte sich bis jetzt noch kein Drucker von mir bewegen . :-) X Schafft 300mm/s Y 260mm/s und die Beschleunigung entsprechen ca. dem Wert von 4000mm/s² . Aber gedruckt hat er noch nicht deshalb will ich mich nicht zu sehr loben. Aber das Potenzial lässt sich sehen.

MFG UEBE

Großen Respekt!
Abonniert!

Benutzt du die Arduino-Umgebung oder programmierst du "native"?

Ich benutz die Arduino-Umgebung. Hab auch alles in Ino Dateien gespeichert. Ich hatte zwar zuerst begonnen die Tabs als C-Quelltexte zu speichern .h , aber mit dem Include hat es dann nur bis zu einem gewissen Punkt funktioniert. Ich hab dann irgenwann die Geduld verloren und es alles umgewandelt. Ich muss gestehen das ich eigentlich nur Python richtig gut beherrsche C und C++ sind mir noch nicht so in Mark und Bein übergegangen. Gerade diese Libary Import und Klassen hab ich noch nicht 100% verstanden.

Durch mein eigenes Unwissen programmiere ich aber auch Recht simple und denke, hoffe das ich den Leuten die jetzt nicht so die C-Spezialisten entgegen komme.
(Wenn sie dann fertig ist)

Sehr empfehlen kann ich Dir den Atom Editor mit Arduino Toolchain. Der beherrscht z.B. Autocomplete und unterstützt recht umfangreiche Projekte weit besser als die Arduino Umgebung (inklusive GIT)

Hier mal der Link zum downloaden und lesen:

Atom mit PlatformIO

2-mal bearbeitet. Zuletzt am 15.01.18 17:16.

---

Wer freundlich zu mir ist zu dem bin auch ich freundlich. Wer Schreibfehler findet darf sie gerne behalten / Geeetech Prusa I3 ProX extended / Repetierhost / Mattercontroll / Slic3r

Wie kommt man auf die Idee sich seine eigene Firmware zu schreiben? Also verstehe das nicht falsch, ich finde das sehr beeindruckend, da ich nicht mal wüsste, wo bzw. wie ich anfangen könnte...

Falls du noch nach Funktionen suchst, die du in die Firmware einbauen kannst, ich habe mal gelesen, dass man unbestromte Schrittmotoren als Encoder benutzen kann. Ich schreibe das auch nur, da du zwei unbestromte Nema 17 Motoren eingebaut hast und somit theoretisch die X- und Y-Achse überwachen könntest.

---

Grüße
Martin

Ich hab dabei ja auch meine Hintergedanken. Ich will dieses Jahr noch einen Plasma-Schneider und eine CNC-Fräse bauen. Da ist es natürlich schön eine eigene Firmware zu haben die speziell auf genau ein Gerät zugeschnitten ist. Aber beides noch "Ferne Vorhaben". Meine jetzige PVC-Fräse läuft zwar auch mit Repetier jedoch musste ich die Firmware immer anpassen , genauso wie bei dem großen LRP800 wo ich das Ausfahren der Düsen implementiert habe. Mich hat immer gestört das es alles so unübersichtlich ist . Weil eben Repetier, Marlin etc. die ganzen anderen Drucker formen und Aufbauten unterstützen. Und mittlerweile traue ich es mir zu, also warum nicht ?

Also Encoder für X und Y, selbst wenn ich die Nema17 verwenden halte ich für unnötig. Sobald man Schrittverluste hat, überlastet man einfach. Aber ich überleg ob ein Encoder beim Extruder Sinn machen würde. Meine Überlegung ist einen Bowden-Extruder zu bauen und ein Encoder kurz über die Düse zu setzten. Dieser misst dann den Drahtvorschub. Vielleicht erhält man so einen Extruder der den Gewichtsvorteil eines Bowden und die "Ansteuergenauigkeit" eines Direct Drive hat. Komischerweise hab ich bis jetzt so einen Extruder noch nirgends gesehen ???

Ich hab die Idee mit dem Bowden erstmal zurückgestellt. Mit Direct Drive bin ich erstmal auf der sicheren Seite. Es ist ein sehr kompakter, kleiner Extruder darunter das Petite Shark von Reprap-Fab. Wenn der Drucker gut läuft werde ich wahrscheinlich auf den neuen Titan-Booster mit WaKü setzen und vielleicht mal mit einer Airbrushdüse.



Weiter Oben an den Drucker kommen 3 CPU-Kühler die das Wasser herunter kühlen sollen. Das Wasser Fließt durch Aluminiumblöcke. Zwischen Block und CPU-Kühler Sitzen Peletier-Elemente. Ist mehr so ein Gag denn das Hot-End gibt kaum Wärme ab.



Und ja mal sehen ob ich das bis zum Wochenende gebaut bekomme. Und natürlich hoffe ich das die Filabase bald eintrifft.

1-mal bearbeitet. Zuletzt am 16.01.18 18:13.

Quote
Uebe
Also Encoder für X und Y, selbst wenn ich die Nema17 verwenden halte ich für unnötig. Sobald man Schrittverluste hat, überlastet man einfach.

Was meinst du mit man überlastest einfach?

Quote
Uebe
Aber ich überleg ob ein Encoder beim Extruder Sinn machen würde. [...] Komischerweise hab ich bis jetzt so einen Extruder noch nirgends gesehen ???

Vielleicht hat es ja wirklich noch niemand versucht, Encoder sind im 3D-Druck (noch) nicht so weit verbreitet. Jedenfalls bei den Hobbygeräten.

---

Grüße
Martin

Moin. Der Encoder muß ja auch in der Software ausgewertet werden. Dazu muß es auch Anschlüsse am Board geben.
Ich meine, wenn man seinen Drucker innerhalb der möglichen Betriebsleistung betreibt, braucht man das nicht. Ich habe jedenfalls seit Jahren keine Schrittverluste gehabt.

---

Liebe Grüße aus Kaltenkirchen.
Frithjof
Meine Seite
[www.facebook.com]

Quote
Zizibee
Was meinst du mit man überlastest einfach?

Naja, es kommt eben nur zu Schrittverlusten wenn das benötigte Drehmoment größer als das aktuelle Moment des Motors ist. Das Nennmoment ist abhängig von der Drehzahl. Ist bei Schrittmotoren immer so eine Sache bis 100rpm bleibt das Moment fast gleich dem Haltemoment. Danach sinkt es rapide ab. Meist hat man bei 200rpm noch die Hälfte. Alles über 300rpm ist praktisch kaum noch nutzbar. Trotzdem kann man die Schrittmotoren mit ner guten Steuerungen auch bis zu 10000rpm laufen lassen. Was ich allerdings für Quatsch halte.

Das bringt mich auch gerade auf einen Gedanken.

F = M x a

Die Masse ist konstant . Da das Drehmoment aber abbaut müsste die Beschleunigung mit steigender Geschwindigkeit abnehmen um die gleiche Kraft zu gewährleisten. Ich werde das mal versuchen in die Firmware zu implementieren.


Nun gut ich hab den Extruder fertig. Ich musste leider etwas nachfeilen und da ich mir anscheinend bei so etwas nie Mühe geben kann, hab ich richtig hässliche Macken reingefeilt. Ich hab den Stärksten Nema17 verbaut den ich habe. Deshalb wiegt der Extruder mit Hot-End auch 600g. Aber die Nema23 scheinen das ganz gut mitzumachen.



Leider ist in meinem Durcheinander die zweite Feder abhanden gekommen. Ich hoffe ich finde sie wieder. Funktioniert aber auch mit einer. Ich hoffe ich bekomm diese Woche noch die Wasserkühlung und die PID-Regler hin . Dann kann ich das Hot-End mal testen. Jedoch kam die Fila-Base noch nicht.

Quote
Fridi
Moin. Der Encoder muß ja auch in der Software ausgewertet werden. Dazu muß es auch Anschlüsse am Board geben.

Natürlich muss man die Encoder-Motoren an das Board anschließen, Marlin 2.0 nutzt dafür - laut Quellcode - den I2C-Bus. Das ist hier aber wohl eher umständlich.

Quote
Fridi
Ich meine, wenn man seinen Drucker innerhalb der möglichen Betriebsleistung betreibt, braucht man das nicht. Ich habe jedenfalls seit Jahren keine Schrittverluste gehabt.

Prinzipiell gebe ich dir da recht, allerdings hatte ich auch ewig keine Schrittverluste und seit ein paar Drucken tritt ständig Layer-Shift auf. Aber das ist eine andere Geschichte und sollte ein anderes mal erzählt werden.

---

Grüße
Martin

So ich hab mit der Wasserkühlung angefangen,



Für die kleine Pumpe habe ich einen Halter gefräst. In diesen konnte man ein Teelichtglas umgedreht einstecken, was ich als Ausgleichsbehälter nutzen wollte. Leider ist mir nach wiederholter Montage das Glas zerbrochen und ich finde auch kein Ersatz im Haus. Ich hab mir jetzt ein Acrylglas Rohr gekauft was ich einkleben werde.

Das Wasser geht von der Pumpe in eine Y-Verbindung und läuft parallel durch zwei Aluprofile. Peletier-Elemente entziehen über zwei CPU-Kühler die Wärme aus dem Aluprofil. Das "gekühlte" Wasser fließt dann weiter zum Hotend und danach zurück in den Ausgleichsbehälter.



Mit einem Arduino Nano ist ein Regler realisiert, die aktuelle Temperatur wird auf der Segmentanzeige angezeigt beim erreichen einer bestimmten Temperatur wird gekühlt. Im Moment sitzt der Temperatur Sensor im Kühler. Vielleicht macht es mehr Sinn diesen ins Coldend zu setzen.

Leider kann ich noch nicht viel über die Kühlleistung sagen. Bis jetzt habe ich den Regler nur mit nem Labor-Netzteil getestet ( das begrenzt auf 5A ). Die Peletier-Elemente ziehen jeweils 5A bei 12V. In meiner Werkstatt herrschen im Moment nur 10°C, auch deshalb eher ungeeignet zum testen von Kühlungen.

Ich weiss aber auch nicht welche Temperatur das Coldend haben sollte.

Bin jetzt leider bis Ende der Woche beruflich unterwegs . Deshalb wird es dauern bis ich wieder Zeit für das Projekt habe.

Ich halte euch auf dem Laufenden.

LG UEBE

Ich bin mal wieder ein bisschen voran gekommen.




Konnte leider nicht warten bis das Acrylglasrohr kommt. Deshalb Cola Flasche halbiert und mit Heisskleber in an die Pumpe "gepraxt". Richtig dicht ist es nicht. Es sieht so "Schei...e" aus das ich verpixeln musste.

Ich habe ein Arduino Mega installiert was sich rein um die Temperatur für Extruder und Heizbett kümmert. Die Temperaturen werden auf den 4 Segment Displays angezeigt. Über Taster lassen Sie sich bequem SOLL-Temperaturen einstellen. Rechts zur Mitte hin die Düse , rechts außen das Heizbett. Weiterhin hab ich jetzt den Temperaturfühler der Wakü auf das Cold-End des Hotends gesetzt. Eine zweites Netzteil für die Peletier-Elemente verbaut.

Bei der Temperaturdüsenmessung hab ich mir noch etwas besonderes einfallen lassen. Ab 100°C schaltet sich der Vorwiderstand vom NTC um von 4,7K auf 860Ohm. So wird die Messauflösung in den höheren Temperaturbereichen deutlich vergrößert . Und damit verbunden die Regelung.

Ich muss jetzt noch die Kommunikation zwischen den beiden Controllern herstellen. Bin mir allerdings nicht sicher ob ich einen Levelconverter brauche. Wegen dem 5V Mega und 3,3V Due.

Auf das Ausrichten des Betts hab ich noch gar keine Lust. Mein 3D-Touch-Sensor ist nun auch gekommen. Ich weiss leider noch nicht wie das Ding angesteuert wird. Mal sehen .

Man darf gespannt bleiben

Achso ganz vergessen zu Erwähnen die Wakü schafft im besten Fall 6°C unter der vorhanden Raumtemperatur.

So seit Anfang der Woche bin ich dabei den Drucker zum Drucken zu übereden.

Das ist so ne Sache durch die eigene Firmware kommen noch ziemlich viele Fehlerquellen hinzu. Zuerst konnte ich meinen Extruder kaum richtig einstellen . Meine Errechneten Steps/mm passten einfach nicht zu dem Druckbild . Ich hab dann ewig an der Firmware rumgeschraubt .
Schlussendlich war die Schrittmotorkarte das Problem . Den Extruder hab ich jetzt auch mit einer DQ860MA am Laufen . Gut ist das nicht wirklich. Ich musste Widerstände Parrallel zum Motor löten da dieser sonst gekocht wird.

Weiterhin hatte ich das Problem das der Drucker während des Drucks einfach sich aufhängt . Wenn ein G1 F1500 und danach ein G1 X... Y.... kam blieb er stehen und war in irgendeinem undefinierten Zustand. Leider kam dieser Bug aber nur in 1 von 100 Fällen vor. Ich hab dann immer wieder Dinge probiert und war oft am manchmal wirklich am Verzweifeln. Irgendwann hatte ich mir meine Firmware Version 4 so kaputt programmiert das nichts mehr wirklich funktionierte . Ich hab Version 3 wiede aufgespielt und die sicheren Teile von Version 4 übernommen und Siehe da die ersten Ergebnisse.



Ich hab diesen Würfel 30x30x30 gedruckt. Infill hat nicht wirklich funktioniert deshalb ist die Deckschicht löchrig. Und für die Überhänge müsste ich eigentlich das ABS kühlen hab hier aber noch keine Lösung. Ich drucke im Moment mit 240°C vielleicht ist das auch etwas zu heiß. Ich kann das neu gekaufte NoName Material ganz schlecht einschätzen.

Das der Travel mit 200mm/s ohne Schrittverluste funktioniert freut mich.

Die Beschleunigung musste ich von 4000 auf 3000 mm/s² drosseln einfach weil es mega Schläge gab und es alles so unkontrolliert war. Aber selbst die 3000 machen sich schon schwer bemerkbar.

Das Nadelöhr ist der Extruder . Deshalb fertigt Wolfgang mir noch ein H2O Booster mit Sonderwünschen. Bin mal gespannt wie weit ich noch komme

Quote
Uebe
...
Ich kann das neu gekaufte NoName Material ganz schlecht einschätzen.
...

Ich finde, dass das sehr suboptimal ist. Damit kämpfst Du an mindestens 2 Fronten, ohne definitiv erkennen zu können, an welcher.
Die Würfeloberseite zeigt auf halb-acht m.E. Aussetzer, das wäre schon fast typisch für Extrusionsprobleme (Wipe bei S3D, Beschleunigung bei kurzen Strecken usw. ) aber auch Filamentprobleme, Hotendprobleme, Temperaturprobleme und die speziell im Zuführröhrchen - wie immer Dein Hotend aufgebaut sein mag.

Ich habe die letzten 2 Tage mit einer alten Filamentrolle mit einem PLA-Label zu kämpfen, die sich alles andere als "anständig" benimmt. Das Zeug hat sich beim Einlegen mit den üblichen 195-200° richtig gut drucken lassen, beim nächsten Durchgang des gleichen Objekts - löchrig, große Aussetzer, ruckartiges Austreten des Materials. Düse (0,25) verstopft. Beim Freibrennen rot-gelbliche, stark rußende Flamme, nachdem es sich auch gut biegen lässt und sich nicht glasartig starr anfühlt, ist das viel eher ABS als PLA (Acetontest steht noch aus). Jetzt drucke ich es mit einer 0,40er Düse mit 230 ° und läuft wieder bestens. Bis zum nächsten Mal.

Ich habe keine Ahnung, wo ich das Zeugs her habe, seit Jahr und Tag habe ich einen Lieblingslieferanten und bei dem bleibe ich, gerade wegen der Konstanz seiner Filamente.
Wenn Du Dir einen Gefallen tun willst, verwende ein Markenprodukt, bei dem man mit sehr hoher Wahrscheinlichkeit mit den Herstellerempfehlungen gut auskommst. Nur so kannst Du den mutmaßlichen Hard- und Softwareproblemen auf den Pelz rücken. Für Materialexperimente ist später, wenn alles gut läuft, auch noch Gelegenheit.



H.

Hallo Zusammen,

Da es mir im Winter in meiner Werkstatt zu kalt ist, steht das RED CUT Projekt erstmal. Der Black Corner passt jedoch in mein Zimmer also hab ich mich an eine Generalüberholung gemacht.

Da mir die 5 Arduinos im Red CUT auch schwer auf die Nerven gehen, war ich vor kurzer Zeit mal auf der Suche nach einer neuen CPU die genügend Performance und GPIOs besitzt . Gefunden habe ich den STM32F767ZI , den man auf dem Nucleo F144 Board findet.
Und ich hab mir gedacht meine Frimware nochmal auf dieser CPU umzusetzen.



Dabei handel es sich um eine CPU mit CORTEX M7 Architektur (Vorstufe vor Handy CPUs ) . Nett ist das über 160 Pins nach außen geführt sind und das die CPU mit 216Mhz taktet . Auch der Flash und RAM lassen keine Wünsche übrig.

Der größte Vorteil ist jedoch gegenüber den Arduinos die Debug Schnittstelle . Man kann seine komplette Firmware mit BreakPoints versehen und an jede Stelle der Applikation hüpfen und sich alle Register in Echtzeit ansehen.

Da ich auf meiner Arbeit sehr viel mit RTOS 'sen zu tun habe , habe ich mich auch dafür entschieden die Drucker Firmware auf Basis eines RTOS zu betreiben. RTOS = Echtzeitbetriebssytem .

So ein RTOS hat riesige Vorteile und genau so riesige Nachteile. Die Vorteile sind das man "scheinbar" mehrere Tasks (Funktionen) parallel abarbeiten kann . Was die CPU oder besser gesagt der Scheduler wirklich macht ist ,zwischen den Funktionen im Microsekundenbereich hin und herzu springen . Das ist jedoch auch der Nachteil eben weil man nicht weiss wann die Aufgabe unterbrochen wird muss man die Funktionen in sich schützen (um keine Variabeln im RAM zu verlieren ) . Außerdem hat so ein RTOS wie jedes andere Betriebssystem auch eine gewisse Grundlast . Deshalb sind sie in der Embedded Welt eher unbeliebt .

Ich hab mich für das RTOS von SEGGER namens EmbOS entschieden , da es einen sehr kleinen Footprint hat und meines Erachtens mehr Performance als das FreeRTOS (Amazon ) oder RTX (Keil ) bietet . SEGGER bietet zudem noch viele weitere Tools und eine sehr schicke Entwicklungsumgebung an . Alles kostenlos solange man es nicht Kommerziell verwendet. Kaufen ist für Privatleute keine Option (>9000€). Aber schön das Sie es so erlauben mit diesen industriellen Tools zu arbeiten.

Soweit so gut . Bis jetzt hab ich mir erstmal einen UART Treiber geschrieben der die Befehle interpretiert und in einen Queue (Buffer ) schreibt. Event basierend wird dann der Commander Task angetriggert . Dieser interpretiert die Befehle und führt sie aus. BIs dahin erstmal seit heute Läuft mein I2C Display Treiber und auf einem kleinen 0.96" Display lasse ich mir Temperatur Speed und Druckfortschritt anzeigen . Ich überlege noch ob ich mir statt dem Fortschritt nicht lieber die CPU Auslastung anzeigen lasse . Wäre für mich interessanter. Ansonsten klemm ich mich die Tage jetzt noch hinter den SD-Karten Treiber . Ich werds erstaml über SPI versuchen , jedoch wäre SDMMC natürlich schöner .

Ein Webserver könnte man auch einrichten , jedoch müsste ich dann mal Segger anfragen ob die mir ein Trial für Embos-IP geben .Zukunfts Musik könnte natürlcih sein sogar Teile des Slicer in der Firmware zu integrieren (wohl eher Spinnerei ) .


Die Frage ob das alles Sinn macht bleibt offen . Aber es lässt sich auf jeden Fall 1000mal besser programmieren als die Arduinos und der Upload des Programms dauert auch nur 2-3 Sekunden .

Ich lad morgen mal Bilder rauf und zeig euch meinen aktuellen Stand.

MFG UEBE

Hier mal mein Mini LCD auf dem ich mir aktuelle Werte ausgeben lasse.




Und in diesem Trace kann man schön sehen das es 110us Sekunden dauert um die Daten in den internen LCD Buffer zu schreiben (Lila). Danach wird ein Event ausgelöst und der LCD UPDATE Task (Blau ) überträgt die Daten via I2C an das Diyplay. Das dauert ca. 5,5 ms .

Quote
Uebe

Die Frage ob das alles Sinn macht bleibt offen . Aber es lässt sich auf jeden Fall 1000mal besser programmieren als die Arduinos und der Upload des Programms dauert auch nur 2-3 Sekunden .

Ich lad morgen mal Bilder rauf und zeig euch meinen aktuellen Stand.

MFG UEBE

Das macht Sinn. Wirst Du Daten mal öffentlich machen oder soll das doch eher komerziell genutzt werden?
Gruß
Georg

Quote
dragon3d

Das macht Sinn. Wirst Du Daten mal öffentlich machen oder soll das doch eher komerziell genutzt werden?
Gruß
Georg

Ne Kommerziell kann ich es nicht machen .Von daher kann ich wenn das Interesse stimmt auch das ganze Projekt mal online stellen . Aber ich stell es erst online wenn ich mit dieser Firmware auch schon was gedruckt habe .

MFG UEBE

@Uebe:

Erstmal großen Respekt alles selbst machen zu wollen

Ich komme persönlich nur mit dem Arduino (bzw. stm32duino) Framework klar und den darin enthaltenen fertigen Bibliotheken (z.B. für HardWareSerial für USART und Wire für I2C).

(Ich hab' schonmal versucht mit Atollic Studio einen STM32F103 zu programmieren, aber selbst UART oder I2C zu implementieren war dann doch jenseits meiner Fertigkeiten...)

Quote
Uebe

Aber ich stell es erst online wenn ich mit dieser Firmware auch schon was gedruckt habe .

MFG UEBE

Das kann ich gut verstehen, denn sonst macht's ja auch relativ wenig Sinn.
Hast Du schon mal darüber nachgedacht, so etwas auf dem RPI zu machen? Etwa das für den 3D-Druck-Bereich? http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RPi3BPreemptRT

oder

https://github.com/jameswalmsley/RaspberryPi-FreeRTOS

Wenn es von den Headern her Arduino kompatibel sein soll, allerdings mit Linux unter der Haube, geht auch
http://zedboard.org/product/minized

Dies sei nur beispielhaft erwähnt, da der Trend wohl (Gott sei Dank) immer mehr in Niedrig-Energie Lösungen zu driften scheint. Es gibt mittlerweile zig von solchen Boards, die alle enormes Potential haben, leider aber für den Massenmarkt einfach zu teuer sind.

1-mal bearbeitet. Zuletzt am 04.01.19 13:07.

Quote
dragon3d


Das kann ich gut verstehen, denn sonst macht's ja auch relativ wenig Sinn.
Hast Du schon mal darüber nachgedacht, so etwas auf dem RPI zu machen? Etwa das für den 3D-Druck-Bereich? http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RPi3BPreemptRT

oder

https://github.com/jameswalmsley/RaspberryPi-FreeRTOS

Wenn es von den Headern her Arduino kompatibel sein soll, allerdings mit Linux unter der Haube, geht auch
http://zedboard.org/product/minized

Dies sei nur beispielhaft erwähnt, da der Trend wohl (Gott sei Dank) immer mehr in Niedrig-Energie Lösungen zu driften scheint. Es gibt mittlerweile zig von solchen Boards, die alle enormes Potential haben, leider aber für den Massenmarkt einfach zu teuer sind.

Naja ich hab hier auch ein Raspberry rumfliegen . Aber ich kann keine Firmware dafür schreiben . Das Raspberry hat ja so nichts mehr mit einen Microcontroller gemein.
Ich finde es interessanter Microcontroller so intelligent zu machen das ein Raspberry überflüssig wird. Ich mag es allein schon wenn man keine Bootzeiten hat und ein Controller optimal auf ein Gerät zu geschnitten ist.

Ich habe heute gesehen das der STM auch HDMI und einen LCD Controller besitzt . Also könnte man auch größere Displays zum laufen bekommen. Bevor Ich mich damit befasse werde mich aber dann zunächst erstmal auf den Webserver konzentrieren.

Ja im Moment hänge ich immer noch an dem SD-Karten SPI Treiber . Da Segger leider ziemlich viele Setup und Startup so wie Vector Dateien anpasst kann ich leider nicht ohne riesen Aufriss die HAL (Standard Treiber Bibliothek ) einbinden. Deshalb muss ich jeden Treiber selbst schreiben.
Und obwohl SPI mit die einfachste Schnittstelle bildet ,macht es mir Probleme .

Kenn sich hier vielleicht jemand mit dem SD-Karten Protokoll aus ? Im Moment sende ich den Idle Befehl 0x40 0x00 0x00 0x00 0x00 0x95 und die Karte antwortet mit einer 0x1F aber ich erwarte eigentlich eine 0x01 .

MFG UEBE

Respekt und großes Kompliment für Deine Arbeit!

Quote

Naja ich hab hier auch ein Raspberry rumfliegen . Aber ich kann keine Firmware dafür schreiben .

Wo ein Willy findet sich ein Weg

Schau mal hier.

Das nette an der Himbeere sind die mehreren Cores, allerdings ist die Peripherie so bescheuert schlecht angebunden, dass man nix Vernünftiges mit dem Teil machen kann.
Ich weiß nicht, ob es Rtos für die Himbeere gibt, aber unter Linux (wo es ja RT-Kernel gibt) ist der system-counter versteckt, sodass man keine Zeiten "schnell" auslesen kann. Das bräuchte man aber, um exakte Timings für die Schritterzeugung zu erstellen.

Alternativ: schau Dir mal den LPC435x an. Weiß nicht, wie gut die Entwicklungsunterstützung bei nxp ist.
Ist ein Dualcore mit besserer Peripherie-Anbindung als bei der Himbeere. Dafür sind die Cores nicht ganz so schnell - ich denke aber ausreichend für CNC-Maschinen

Quote

Kenn sich hier vielleicht jemand mit dem SD-Karten Protokoll aus ?

Frag doch mal dc42 hier im Forum, den Macher von Duet3D
... oder ...
Arthur Wolf, den Autor von Smoothie - die Smoothieboards verwenden meines Wissens auch LPC-Professoren

So den SPI hab ich jetzt erstmal in den Griff bekommen . Lag zum Teil daran das ich einen SD-Ramps verwendet habe . Auf der PCB ja ein kleiner IC gelötet ist damit es mit 5V Ports funktioniert. Das ist bei einem 32Bit mit 3.3V natürlich unnötig .

Jetzt kommt schon das nächste Hindernis das FAT System .

Da muss ich auch noch ein paar Websites lesen bis ich verstanden habe, was Microsoft sich dabei gedacht hat

Aber es wird wohl irgendwie gehen ich beschränk mich wahrscheinlich erstmal auf die Dateien im Root Verzeichnis und deren Auslesen .



Hier mal meine Aktuelle Drucker Platine mit dem geraden neu verbauten SD-Karten Slot.

MFG UEBE

sensationell

---

Mein Club: [hackerspace-ffm.de]
RADDS-Shield -> Commercial [max3dshop.org]

So FAT16 hab ich so weit fehlt noch FAT32. Damit ich jedoch auch mit den Dateien arbeiten kann , darf die Anzeige nicht fehlen.

Deshalb arbeite auch zeitgleich an der GUI. Den Display hab ich ersetzt durch einen doppelt so großen . Von 128 x32 auf 128x64. Da der Treiber der gleich ist wurden beim Alten die Hälfte aller übertragenen Daten nicht verwertet . Somit ist der Traffic über i2C bei beiden genau gleich.

Natürlich ist das neue Display immer noch sehr klein , und man brauch gute Augen. Falls jemand ein größeres OLED SchwarzWeiss Display kennt würde ich mich über einen Link freuen.



Bis dahin

UEBE