Smoothieboard für SparkCube XL ?

Moin,
hat jemand schon Erfahrungen mit dem Smoothieboard für den SparkCube ?
Die Suchfunktion fördert nur im Englischen Forum dazu was ans Tageslicht.
Mir gefällt die 32Bit Architektur die stromprogrammierbaren Treiber und die Anschlussmöglichkeit über Ethernet.

Bin für jeden Beitrag dankbar...

Gruß aus dem Kohlenpott

Dieter

Jep, läuft wunderbar.
Das einzige: Du bist halt mehr oder weniger auf die eingebauten Treiber beschränkt (A4988), also wenn du geplant hattest andere zu verwenden, musst du entweder ein Add-On bauen (die nötigen Pins sind rausgeführt) oder darauf verzichten.
Spielt für mich keine Rolle, deshalb bin ich überaus zufrieden.
Nur die platzierung der Anschlüsse ist etwas blöd gewählt (einmal außenrum), wodurch es schwieriger ist, ein schönes Gehäuse dafür zu erstellen.

Falls du spezifische Fragen hast, frag gern.

A4983

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Schande über mein Haupt, danke fürs Verbessern

Wenn wir aber schon dabei sind, sagt die offizielle BOM A4982

Im Endeffekt sind das AFAIK allerdings alles sehr ähnliche Chips mit nur geringen Unterschieden...

was mich an diesen Lösungen stört ist das sie irgendwie keine "ganze" Lösung sind.

Ich mein wenn schon wieso nicht gleich einen ARM® Cortex-A8 der hätte gleich PRU's mit drauf.
Der wurde für solche anwendungszwecke gebaut .... der M3 hingegen nicht, da läuft alles auf dem einen "nicht Echtzeit" Core.
Der Gedanke das mein 30MB Gcode upload auf den webserver inkl. ETH Stack und der "echtzeit task" für das generieren der Step pulse auf demselben core laufen ist nicht wirklich prickelnd.

1-mal bearbeitet. Zuletzt am 20.07.15 11:51.

Ja, warum da gleich nen ganzer Server mit rauf musste verstehe ich auch nicht.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Also bezügl. des Ethernets gebe ich euch recht, ist irgendwie n bissi unnötig und frisst sinnlos RAM (den die Jungs mittlerweile Byteweise zählen, weils zu wenig ist).

Was das Echtzeitthema angeht muss ich aber widersprechen: Der Cortex-M3 ist genau dafür gebaut. Der Task, der die Schrittimpulse generiert, ist tatsächlich die ISR eines Hardware-Timers, der mit höchster Priorität konfiguriert ist und genügt somit sogar den Anforderungen der harten Echtzeit - ein Überschreiten des Zeitrahmens wäre gleichbedeutend mit einem effektiven hängen des Prozessors und damit ein Versagen des Systems.

Durch diesen Timer werden alle anderen Prozesse unterbrochen um die entsprechenden Schrittimpulse zu erzeugen, d.h. in der Hinsicht gibt es da eigentlich nichts zu meckern.

Die sogenannten PRUs der modernen Prozessoren sind ja auch häufig genug einfach Cortex-M3 Prozessoren auf denen ein RTOS läuft - so, afaik, auch die im BBB. Ansonsten sind es aber auch nur DSPs, also Mikrocontroller mit einem etwas spezialisierterem Befehlssatz.

D.h. das SmoothieBoard unterscheidet sich Architekturell eigentlich nicht von den allseits beliebten Ärmel basierten Plattformen - lediglich in den Spezifikationen wie z.B. Geschwindigkeit.
Trotzdem hat Smoothie IMO die sehr viel bessere Softwarearchitektur - tut mir leid, und ich will hier nicht die erbrachte Leistung schmälern, aber der Source von Marlin ist schlicht und ergreifend schlecht.

Trotzdem, absolut, Smoothie ist nicht das Ende und auch keine erfrischend neue & andere Technologie - IMO sehr wohl aber ein großer Schritt vorwärts.

So viel zu meiner Meinung

Quote
irrenhaus
Was das Echtzeitthema angeht muss ich aber widersprechen: Der Cortex-M3 ist genau dafür gebaut. Der Task, der die Schrittimpulse generiert, ist tatsächlich die ISR eines Hardware-Timers, der mit höchster Priorität konfiguriert ist und genügt somit sogar den Anforderungen der harten Echtzeit - ein Überschreiten des Zeitrahmens wäre gleichbedeutend mit einem effektiven hängen des Prozessors und damit ein Versagen des Systems.

Durch diesen Timer werden alle anderen Prozesse unterbrochen um die entsprechenden Schrittimpulse zu erzeugen, d.h. in der Hinsicht gibt es da eigentlich nichts zu meckern.

doch sogar sehr klar ist das so gelöst anders wärs ja noch schrecklicher, aber trotzdem ist das "nicht sauber"

Quote
irrenhaus
Die sogenannten PRUs der modernen Prozessoren sind ja auch häufig genug einfach Cortex-M3 Prozessoren auf denen ein RTOS läuft - so, afaik, auch die im BBB. Ansonsten sind es aber auch nur DSPs, also Mikrocontroller mit einem etwas spezialisierterem Befehlssatz.
D.h. das SmoothieBoard unterscheidet sich Architekturell eigentlich nicht von den allseits beliebten Ärmel basierten Plattformen - lediglich in den Spezifikationen wie z.B. Geschwindigkeit.

Trotzdem hat Smoothie IMO die sehr viel bessere Softwarearchitektur - tut mir leid, und ich will hier nicht die erbrachte Leistung schmälern, aber der Source von Marlin ist schlicht und ergreifend schlecht.

Trotzdem, absolut, Smoothie ist nicht das Ende und auch keine erfrischend neue & andere Technologie - IMO sehr wohl aber ein großer Schritt vorwärts.

So viel zu meiner Meinung

also von besserer Software architektur sprechen und dann einen ETH stack, Webserver, ...... und ISRs für steps auf dem.... ahhhhhhh

klar sind PRU's auch wieder nur prozessoren .... was auch sonst aber eben ein spezieller bereich der eben nur für die echtzeit anwendungen da ist .... viel viel sauberer einen A8 auf dem z.b. ein Debian läuft wo ich alles draufpacken kann was ich will, wo ein bewährtes system läuft das eben genau dafür gedacht ist, und das ein sehr performantes interface zu den PRUs hat die eben genau das tun wofür sie gemacht wurden, und nicht auch so nebenbei noch den ganzen ETH und Server mist ....

ich mein und jeder glaubt immer er muss das rad neu erfinden, octoprint oder Repetier-Server kann ich nicht wirklich auf dem Smoothie installieren, genausowenig wie einen webcam-sw, .......
Wenns einen A8 genommen hätten bräuchten sie sich darum gar nicht kümmern, debian drauf und jeder soll sich installieren was er gerne hätte, dann könnte mir der server auch mails schreiben wenn der druck fertig ist, ohne wirklich aufwand.
Durch all diese einschränkungen seh ich einfach keinen mehrwert, wenn schon 32Bit dann doch lieber Due + RADDS + Raspberry Pi dann hast alles was du brauchst, bist mit der FW weniger eingeschränkt, und kannst auf deinem "Server" alles installieren was debian so hergibt.
Wenn mein Drucker fertig ist bekomme ich auf meinem Kodi eine nachricht .... aufwand ~10min ..... bei SmoothieFW bräuchte ich vermutlich tage um das ein zu bauen.

1-mal bearbeitet. Zuletzt am 20.07.15 12:31.

ReprapFirmware ist in der Tat sehr sauber und gut programmiert. Ich wollte selbst mal die Firmware auf den Due poriteren und dabei den ganzen Balast was Server etc. angeht runterschmeißen. Vielleicht komme ich auch irgendwann mal dazu. :/

Webserver etc. machen da drauf keinen Sinn. Aber für ISR etc. ist der M3 auf jeden fall gemacht. Ich habe im letzten Urlaub sogar mal ein wenig rumgesucht und habe nen schicken M4 gefunden. Wenn ich keinen Job hätte, würde ich vor arbeit zu nix mehr kommen

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Wie gesagt, denke wir sind gar nicht so weit auseinander mit den Meinungen - soetwas wie Ethernet & einen Webserver da mit zu integrieren, war denke ich eine falsche Entscheidung. Ich denke, da sind sie einfach dem Feature-Creep erlegen.

Aber ich denke der Rest unterscheidet sich von der Funktionalität her nicht wirklich von Marlin & Co, ist aber IMO einfach besser designed & ausgeführt. Sozusagen ein: In dieser Klasse von Controllern ist das SmoothieBoard IMO das am besten ausgeführte.

Bezügl. A8: Ein großes Problem was ich sehe, ist, dass wir uns dabei in die Ecke bewegen, wo das Platinenlayout nicht mehr einfach mal so machbar ist. Soll heißen extren kleine Steukturen dank BGA Gehäusen (nicht mehr einfach so lötbar), Hochgeschwindigkeitsnetz ging für z.B. DDR(2?) RAM und ähnliches. Da kosten Leiterplatten in kleinen Stückzahlen dann mal schnell mehrere hundert Euro pro Stück.
Will einfach nur sagen: Extrem viel Aufwand & Geld Einsatz, nichts mehr für den Hobbyisten.

Aber wenn man sich freiwillig in diese Richtung bewegt: Warum nicht gleich nen Zynq Dann hat man 1-2 Cortex-Ax Cores (ich glaube A8) und gleich noch nen FPGA dazu, sodass man Dinge wie die Schritterzeugung einfach in Hardware gießen kann, was noch besser wäre, als es auf "Echtzeitkernen" laufen zu lassen. Sowas würde mir mal gefallen

Quote
irrenhaus
der Source von Marlin ist schlicht und ergreifend schlecht.

Marlin ist in Sachen Softwarequalität ja nicht gerade das Mass der Dinge. Es gibt eine Reihe Leute, die sehr viel Engagement in die Teacup investieren, weil der gleiche Controller mit Teacup drauf die Schrittmotoren deutlich ruhiger laufen liesse. Ich selber halte mich da zurück, weil sonst wieder die Wunschlisten-Rufer um die Ecke kommen ("Ich habe ein Display XYZ und Knobelpopel Endstops, wann endlich läuft das?")

Neulich meinte Einer, dass diese induktiven Endstops vor Allem deswegen so beliebt sind, weil die Marlin keine Tastenentprellung eingebaut hat, die man für mechanische Endstops braucht.

Aber 2736 Features, das hat die Marlin natürlich. Unterstützt auch XYZ-Displays und Knobelpopel Endstops. Wenn man denn den richtigen Fork wählt.

Quote
mantus

Quote
irrenhaus
Durch diesen Timer werden alle anderen Prozesse unterbrochen um die entsprechenden Schrittimpulse zu erzeugen, d.h. in der Hinsicht gibt es da eigentlich nichts zu meckern.

doch sogar sehr klar ist das so gelöst anders wärs ja noch schrecklicher, aber trotzdem ist das "nicht sauber"

Das macht eigentlich jedes Echtzeit-Betriebssystem so. Das Wichtige direkt, der Rest wenn Zeit übrig ist.

"Abhilfe" schafft da nur ein zweiter Prozessor. Wobei es dann egal ist, ob der huckepack auf dem Hauptprozessor drauf ist oder nicht. Also z.B. Arduino Nano + RaspberryPi. Es mangelt eben noch an einfachen ARM-Boards. Dauert noch ein Weilchen, so Leute wie der Wurstnase hat sich erst lang und breit beraten lassen und dann doch nichts oder nichts verwertbares gemacht. Jetzt habe ich das selber in die Hand genommen: [github.com]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
Das macht eigentlich jedes Echtzeit-Betriebssystem so. Das Wichtige direkt, der Rest wenn Zeit übrig ist.

ein klares ... jein

Quote
Traumflug
"Abhilfe" schafft da nur ein zweiter Prozessor. Wobei es dann egal ist, ob der huckepack auf dem Hauptprozessor drauf ist oder nicht.

naja genau das wäre ja der A8

@irrenhaus:
ja genau das meinte ich ja, so wie es jetzt ist sind der server usw. einfach die falsche entscheidung gewesen, sie hätten sich darauf konzentrieren sollen den Core richtig für die FW auszunutzen und dort mehr features einbauen sollen .... verschiedene ABL, ..... gibt ja genug optimierungs potential.

Quote
Traumflug
Es mangelt eben noch an einfachen ARM-Boards. Dauert noch ein Weilchen, so Leute wie der Wurstnase hat sich erst lang und breit beraten lassen und dann doch nichts oder nichts verwertbares gemacht. Jetzt habe ich das selber in die Hand genommen: [github.com]

Ja, habe deswegen auch schon wirklich nen schlechtes Gewissen.
Ich habe mich einfach zu sehr in Marlin reingefressen :/ Aber man soll ja niemals nie sagen. Der Stil von Teacup gefällt mir auf jeden Fall. Und das was ich ungehinder gerade mit Marlin mache würdest du eh nie mit Teacup machen lassen

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
mantus
naja genau das wäre ja der A8

... oder der Raspberry nebenan oder der Normal-PC nebenan oder der BeagleBone, der einen Signalprozessor auf dem Board hat. Die können das alles schon, einen Controller mit A8 müsste man erst noch entwerfen. Was mit den etwa 300 Pins des A8 Chips und externem RAM nicht gerade trivial und billig ist.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

... ich habe irgendwo noch einen UDOO rumliegen, den/die ich bei Gelegenheit für diese Art 'Arbeitstrennung' ausprobieren will ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote
Wurstnase
Der Stil von Teacup gefällt mir auf jeden Fall.

Mag daran liegen, dass in die Teacup nur ordentlicher Code rein kommt. Die Konfiguration ist im Configtool besser aufgehoben, so fallen schon mal die ganzen M200 aufwärts weg.

Quote
Wurstnase
Und das was ich ungehinder gerade mit Marlin mache würdest du eh nie mit Teacup machen lassen

Wenn das nicht in die Teacup passt kann's nichts Vernünftiges sein.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Ja mein Programmierstil ist noch am entwickeln. Aber langsam kommt die Routine und dabei auch schon mal ein wenig mehr Ordnung. Aber gut Ding braucht Weile. Ich habe auf jeden Fall das Falsche dafür studiert

Marlin ist deutlich einfacher Aufgebaut als Teacup. Deutlich weniger richtiges embedded Design. Daher ist das für meinen Einstieg ins programmieren einfacher gewesen. Und da am Anfang viel Blingbling wie Display wichtig war, hat mich Teacup nicht gereizt.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Traumflug

Quote
mantus
naja genau das wäre ja der A8

.... oder der BeagleBone, der einen Signalprozessor auf dem Board hat. Die können das alles schon, einen Controller mit A8 müsste man erst noch entwerfen. ...

Quote
beaglebone.org
Processor: AM335x 1GHz ARM® Cortex-A8

*hust* ... wie meinst du das jetzt?

1-mal bearbeitet. Zuletzt am 20.07.15 16:14.

Quote
mantus

Quote
beaglebone.org
Processor: AM335x 1GHz ARM® Cortex-A8

*hust* ... wie meinst du das jetzt?

Damit meine ich, dass der BeagleBone, anders als das Smoothieboard, kein dedizierter Controller ist, mehr nicht. Anfangs wolltest Du ja so einen Controller mit einem A8 drauf.

Wenn Dir der BeagleBone mit einem Cape drauf gut gefällt, nimm den. Da gibt's auch schon eine Firmware für. Freilich ist das weder Marlin noch Teacup noch Smoothieware.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

ja genau das ist ja das Problem was bringt das beste board ohne FW.
Ich verstehe eben nicht wieso sich alle im 32bit segment so "zerstreuen" im 8Bit bereich hast eigentlich X Boards die alle auf dem MEGA2560 basieren, und sich eigentlich "nur" durch das pins.h unterscheiden
im 32Bit Segment kocht plötzlich jeder seine eigene suppe, jeder macht etwas gutes aber die community profitiert davon nur wenig weil sie alle zueinander nicht kompatibel
sind.

Das Cape ist nicht schlecht, aber wenn man ehrlich ist nur ein gutes RAMPS1.4 und die FW darauf läuft zwar hat aber kaum Features :/
und anstatt das die smoothie leute ihre zeit in die Verbesserung dieser FW fürs Beagle stecken, schreiben sie lieber eine eigene neue .... mit webserver ....
Oder ein günstigeres Cape mit mehr Features? .... nein man kocht lieber eine eigene suppe und schon hat man 2 lösungen die zwar nett sind aber beide eigentlich nicht wirklich gut .... anstatt das es eine gute Lösung ergibt

Uuuups, Leute,
was hab ich denn da losgetreten ...
Vorgestern abend noch keine Antwort und heute morgen ne heftige Controller Grundsatzdiskussion

Ich habe das Board nun auf dem Tisch und gehe mal die ersten Schritte.
RRD full grafic display ist dran, Spannungsversorgung noch über USB, der Encoder springt aber bei der Menüauswahl immer zwei Zeilen und der Displaykontrast ist mehr als dürftig.
Mal sehen wie das mit ner richtigen Spannungsversorgung aussieht.

Mein erster Eindruck ist, das die FW auf dem Smoothieboard viel rudimentärer ist.
Bei meinem RUMBA board mit Repetier gibt es viel mehr Konfigurationsmöglichkeiten über das Display.

Hat das Ding wirklich einen kompletten Webserver on board ?
Ich hatte die Doku so verstanden, dass man zB. Proterface nur per Ethernet connecten kann...
OK werde ich mal testen.

Gruß aus dem Kohlenpott

Dieter

@Irrenhaus,
Danke für Deine Rückmeldung,
ich suche nach einem Controllerboard das für meine Zwecke am geeignesten ist.
Ich muss in Zukunft für eine kleine spezialisierte Produktion immer wieder die gleichen, recht großen Teile in ABS drucken.
Dazu sollen mehrere Printer gebaut werden.
Ich suche ein Board, das ich dann in alle meine Drucker einbaue, und der erste Schritt sind zwei SparkCube mit größerem Bauraum als
Produktionsmaschinen.

Das Material für diese zwei Printer ist größtenteils schon geordert, und ich hoffe nächste Woche mit dem Bau des ersten beginnen zu können.

Zuerst einmal will ich das Smoothie-Board in meinen alten Ordbot Hadron einbauen, sozusagen als Prüfstand.
Weitere verschiedene Boards sind bestellt, ein RUMBA Board mit Repetier habe ich bereits im Einsatz.

Mal sehen wer das Rennen macht.

Gruß aus dem Kohlenpott

Dieter

@dj8ds
Um ehrlich zu sein: Ich denke, wenn es dir um Produktionsmaschinen geht, läuft es am ehesten darauf hinaus, welche Firmware (in Kombination mit welchem Board und welchen Stepper-Treibern) dir das beste Ergebnis liefert. Ich bin bisher nicht davon überzeugt worden, dass man dabei ernsthafte Unterschiede (von Deltas mal abgesehen) beim Druckergebnis sieht, weshalb ich der Meinung bin, dass du mit allen gut laufen wirst.
Ich persönlich würde kein 8-Bit basiertes Board mehr nehmen, einfach weil ich diese für veraltet halte. Die Laufen aber auch und sind schon lang erprobt und bekannt.

Über das Display kann man bei Smoothie nicht soo viel einstellen, das stimmt - dafür kannst du dir einfach über die Konfigurationsdatei jederzeit eigene Menüeinträge erzeugen, welche von dir definierten G-Code ausführen.

Bezügl. der Sprünge im Menü: Ich versuche heute Abend mal dran zu denken, es gibt eine bestimmte Konfiguration die man ändern kann, die aber recht versteckt ist, damit kann man kontrollieren, wie viele Schritte pro Menüeintrag vom Encoder kommen sollen.

Der Kontrast vom Display wird auf jeden Fall besser, wenn du eine "richtige" Stromquelle einsetzt, viele USB Schnittstellen sind schon fast überlastet - ich kann hier empfehlen entweder externe 5V einzubringen oder dir die 1A Version von dem Spannungsregler zu besorgen, für den Platz auf dem Board ist. Das hab ich so gemacht und das läuft super.


@mantus
Ich denke dieses "Zerstreuen" ist nicht nur negativ. Es muss ein guter Mittelweg her. Zu wenig und die Variation leidet (ich mag es, zwischen mehr als nur 2 Produkten wählen zu können). Zu viel und der von dir beschriebene Effekt tritt ein.
Ich denke bei der 32bit Elektronik ist einfach gerade das "Problem", dass die Entwicklung davon relativ Jung ist. Also kann noch jeder versuchen, seine eigene Sache zu etablieren. Das wird sich über die Zeit hinweg aber ausdünnen und nur die guten (bzw. meist benutzten) Sachen bleiben dann übrig. IMO ist diese Entwicklung wichtig.
Der Fehler, der dabei gemacht wird, liegt meiner Meinung eher dabei, dass einfach die "alten" Firmwares auf die neuen Platformen portiert werden. Dadurch werden einige Features einfach nicht ausgereizt.
Die Cortex-Mx Reihe hat z.B. ziemlich mächtige DMA Controller & PWM Einheiten. Damit könnte man ziemlich viel in die Hardware auslagern, was jetzt von der Software gemacht wird. Auch gibt es hier viele & schnelle Interfaces, was neue "Add-On" Möglichkeiten ergibt.
Das wichtigste meiner Meinung nach aber: Alle, einfach alle, basieren im Grunde auf GRBL. Das ist zwar an sich eine gute Sache, da die Jungs von GRBL wirklich gute Arbeit geleistet haben, aber GRBL ist nunmal für relativ langsame 8-Bitter entwickelt worden. Wenn man hier neu ansetzen würde, könnte man sich z.B. die Hardware-Floatingpoint Einheit von den Cortex-M4F Prozessoren zunutze machen und einige der Berechnungen besser machen.

Am Ende muss man aber ehrlich sagen: Alle von den vorhandenen Möglichkeiten funktionieren und bieten mehr oder weniger Funktionalität - aber bei allen ist eine immense Menge an Arbeit und Freizeit hineingeflossen und es ist immer einfach drüber zu schwätzen was man besser & anders gemacht hätte .

Ich persönlich hätte schon Bock eine gute integrierte oder halb integrierte (mit Aufsteckboard für zt.B. BB Lösung zu entwickeln, die meinen Vorstellungen entspricht. Ich werds aber nicht tun, da das einen immensen Aufwand bedeutet und am Ende wahrscheinlich keiner meine Lösung nutzt

Erster Test des Smoothieboard war leider ein totaler Fehlschlag..Grrrrrrrr

Die Entwickler des Boards haben so schön mitgedacht und gute Hochstrom Steckverbinder auf dem Board vorgesehen, jedoch sollte man auch das richtige Kabel an den richtigen Platz stecken
Leider liegen 24V Versorgung und der 5V Eingang direkt nebeneinander.
Logisches Ergebnis wenn Murphy mit am Basteltisch sitz... Man nimmt trotz eindeutiger Doku den falschen Stecker....
Hoffe mal, dass die Jungs von FilaFarm das richten können.

Also erstmal wieder das Rumba reinschrauben und ein neues Hotend testen.....

Gefrusteter Gruß aus dem Kohlenpott

Dieter

1-mal bearbeitet. Zuletzt am 21.07.15 15:02.

@Irrenhaus
da hast Du bestimmt recht, ich möchte nur nicht auf alte Technik setzen, deshalb ist 32Bit eigentlich schon Pflicht, denn ich glaube, dass Weiterentwicklungen
der FW sehr bald nur noch auf den 32Bit Systemen stattfinden werden. Deshalb fiel meine Wahl auf das Smoothieboard.
Die integrierten Boards wie RUMBA(8Bit) und Smoothie gefallen mir vom Konzept, alles drauf was man für den Betrieb eines Druckers braucht und relativ aufgeräumtes Design. Für Stepper bis NEMA17 mit ca. 2A eine gute Lösung.
Auch die Anschlussmöglichkeiten sind sehr zahlreich...
Was mir bei beiden Boards eigentlich nur fehlt ist die direkte Anschlußmöglichkeit von Thermoelementen.
M.E. ein Muss bei der Temperaturmessung für die Hotends die mit immer höheren Temperaturen betrieben werden.
(Die Erweiterungsplatinen für TE kenne ich, haben mich aber nicht wirklich überzeugt...)

Gruß aus dem Pott

Dieter