Pollin AVR NET-IO als Motherboard für Repmaschinen

Wenn bei Gen2 nur Z angeschlossen ist, heißt das wohl, dass da nur Z ein- und ausgeschaltet wird. Das ist ja die Achse, die mit einer Schnecke betrieben wird. Das verstellt sich nicht, wenn der Motor stromlos ist. X und Y hingegen laufen über Zahnriemen und lassen sich z.B. auch mit der Hand verschieben, wenn kein Saft drauf ist. Ist also völlig logisch.

Der Arduino Mega hat keine SD-Card. Wenn man das will, muss man die auf einem zusätzlichen Board anschließen. Die sind zur Zeit erst am Entstehen, da experimentieren verschiedene Leute mit unterschiedlichen Varianten herum, die aber mehr die Kühlung als sonstige Neuerungen betreffen. LCD und SD-Card und Ethernet und Bedientasten am Arduino Mega sind alle noch neuere Sachen als bleeding edge, auch wenn einzelne Leute sowas vielleicht schon gebaut haben.

ENC ist vermutlich für einen Encoder, also einen Sensor, der Rückmeldungen über die tatsächliche Position gibt. AUX sind Zusatzgeräte, die möglicherweise noch gar nicht definiert sind.

Lüfter hatte ich bisher noch gar nicht auf der Rechnung, aber es stimmt, manche Leute bauen sich Lüfter an verschiedene Stellen des Geräts, mit unterschiedlichen Funktionen.

Das Pollin Board ist insofern anders als der Arduino Mega, als der Chip weniger Pins hat. Mit dem Arduino Mega kann man sich richtig austoben mit zusätzlichen Features, außerdem hat der auch noch richtig viel Speicher. Dafür hat das Pollin-Teil serienmäßig die Ethernet-Möglichkeit (muss aber erst programmiert werden, man würde da wohl existierende Module übernehmen, z.B. das von ethersex [www.ethersex.de]) und ist billig und für ein Basisgerät+X ausreichend. Wenn man vorhat, wirklich viel mit allen möglichen neuen Zusatzgeräten zu experimentieren, die alle eigene Pins brauchen, oder noch Lauflichter ranbauen will oder so, dann wäre wohl der Arduino Mega besser. Der Preisunterschied ist inzwischen so gering, dass man wohl nicht allzu lange darüber nachgrübeln sollte, ob man den nun nimmt oder nicht. Für Ethernet-Experimente mit einem normalen Mendel ist aber das Pollin-Teil bequemer, was die Hardware angeht, weil es einfach dabei ist und direkt getestet werden kann, dann weiß man bei Programmierproblemen zumindest, dass es nicht an der Hardware liegt.

Soweit ich weiß, ist die Anpassung für Arduino Mega schon in der neuesten offiziellen Firmware enthalten und wird dort wohl auch für eine ganze Weile verfügbar bleiben.

Quote

Das ist ja die Achse, die mit einer Schnecke betrieben wird. Das verstellt sich nicht, wenn der Motor stromlos ist

Ah, ok. Dann könnte man den eigentlich auch noch weglassen bzw. auf Grund legen. Oder besser belassen, weil der Motor ja insbesondere bei großen Flächen länger in einer Ebene bleibt ?

Quote

LCD und SD-Card und Ethernet und Bedientasten am Arduino Mega sind alle noch neuere Sachen als bleeding edge]

Fein, dann lohnt sich der Aufwand ja doch. Ausserdem will ich gewiss nicht mit Lauflichtern und dem neusten Zusatzschnickschnack experimentieren (der von uns angedachte reicht schon voll und ganz ) vielleicht abgesehen von sowas wie dem Wärmebett. Ausserdem gefällt mir am Arduino-Mega auch das SMD-Format nicht. Und ich hab hier auch noch nen unverbauten NetIo-Bausatz rumliegen

OK, dann werd ich mich mal dranbegeben und versuchen die Schematics vom NetIo und dem Gen2onaBoard irgendwie sinnvoll zusammenzustricken.

Die einzige Frage die bei mir im Moment noch offen ist, ist, ob man im Rahmen des recht plausibel klingenden Einwandes von Tobias nicht vielleicht doch den überzähligen ATmega32 da mit reinstrickt. Aber erst mal schauen, auf wieviel Pinne wir denn nun wirklich kommen.

Gruss, Case

Edited 2 time(s). Last edit at 08/30/2010 10:43AM by case.

Hi Case,

... es hindert dich ja niemand, eine Art 'Coprozessor-Erweiterung' vorzusehen - entweder als Bus oder speziellen Stecksockel.

Ich habe z.B. einige MySmartControl168-Riegel, Arduino-PRO-mini und andere Mini-MC-Module rumliegen, die auch fürs einfache Auf-/Einstecken in größere Schaltungen gedacht sind ...

---

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]

> überzähligen ATmega32 da mit reinstrickt

Würde ich nicht machen, solange es nicht nötig ist, weil es umständlich ist. Man muss sich dann ja ein Datenaustauschprotokoll überlegen, das Timing und die Pufferung berücksichten usw.
Aber wenn Du das gerne machen willst, warum nicht. In dem Fall wäre das Einfachste vermutlich, das in der Firmware existierende RS485-Protokoll mit den entsprechenden Pins zu verwenden (vielleicht kann man dann die RxEnable und TxEnable Pins weglassen, muss aber ggf. auch dafür wieder die Firmware anpassen (wie bei jeder Hardware-Änderung)).

Aber wenn Dir das Vermeiden herumliegender Controller so wichtig ist, warum nimmst Du dann nicht den mit dem Pollin-Board mitgelieferten ATmega32 als Controller? Das dürfte mit geeigneten Anpassungen in der Arduino IDE bzw. dem Bootloader auch gehen. Die aktuelle Firmware scheint nur ca. 20 kB zu brauchen, da ist auch für Erweiterungen wie ein LCD mit Menü noch Platz. Ich vermute, der Hauptgrund für die Verwendung des ATmega 644p war, dass der 2 serielle Schnittstellen hat, wobei die 2. für den RS485-Link zum Extruder-Board benötigt wird, aber wenn das Board eh wegfällt, reicht auch der ATmega32. Natürlich hat der 644p doppelt so viel Speicher, aber wenn der des 32 reicht, ist es ja kein Problem.

Quote

Bei der Gen2-Elektronik ist es nämlich so, dass zwischen jedem einzelnen Step (!) jedes einzelnen Steppers (!) die Temperatur des Extruders abgefragt wird - und das gleich 5 Mal, um Messfehler auszubügeln.

Das liegt nicht an der Elektronik, das liegt an der Firmware. Bei FiveD for Arduino ist das besser gemacht, es gibt einen eigenen Timer für die Temperaturregelung. Laut Triffid Hunter ist damit auch der 168er schnell genug für 1/16 Schritte, und er speichert auch bis zu 8 Zeilen GCode in einem Zwischenspeicher. Alles eine Frage der richtigen Programmierung ;-)

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Viktor
es hindert dich ja niemand, eine Art 'Coprozessor-Erweiterung' vorzusehen - entweder als Bus oder speziellen Stecksockel.

Prinzipiell schon, aber dann würd ich es glaubich in diesem Fall fast vorziehen zunächst zwei Varianten parallel zu entwickeln und dann hinterher zu schauen welche besser passt. Das fängt schon bei der Auswahl ob 644 oder 644p an, aber dazu gleich noch mehr.

Quote
Peer
Aber wenn Dir das Vermeiden herumliegender Controller so wichtig ist, warum nimmst Du dann nicht den mit dem Pollin-Board mitgelieferten ATmega32 als Controller?

*grins* , also ich kann die herumliegenden 32er schon durchaus noch für andere Sachen verbraten, ich meinte halt nur falls man denn unbedingt noch nen zweiten Prozessor braucht, dann hätte man hier eben einen mit mehr Speicher und Pins als der 168er hat und den gleich im Bausatz mit dabei. Als Hauptprozessor würde ich den aber nicht verwenden wollen, weil ich glaube, dass der übrige Speicherplatz schnell verbraucht ist. Ich hab das NetIo-Board schon in einer anderen Anwendung laufen und hab dabei festgestellt, dass sobald man mal das eine oder andere Zusatzfeature haben will (wie z.B. Telnet), was über den Umfang der Pollin-Firmware hinausgeht, der Platz vorne und hinten nicht reicht.

Quote
Traumflug
Das liegt nicht an der Elektronik, das liegt an der Firmware. ... Alles eine Frage der richtigen Programmierung ;-)

OK, das relativiert die Sache wieder etwas. Trotzdem habe ich bis hierher jetzt aber schon etwas den Eindruck, das manche Funktionen wie Extruder-Synchronisation einigermaßen zeitkritisch sind und wenn ich mir vorstelle, dass dann noch gleichzeitig über Ethernet Daten auf die SD-Karte geschaufelt werden sollen (wobei dies aber andererseits passiert bevor der Reprap losdruckt) dann würde ich den Co-Prozessor zumindest als Option erst mal noch im Hinterkopf behalten.

Übrigens hab ich mir in dem Zusammenhang mal angeschaut, welche Pins auf dem NetIo-Board von der zweiten seriellen Schnittstelle beim 644p betroffen sind und es sieht so aus, dass PD2, PD3 und PD4 innerhalb des Boards frei bzw. auf einen externen Anschluss geführt sind, d.h., man müsste also das NetIo problemlos auch damit anstatt mit dem 644er bestücken können.

Desweiteren hab ich jetzt nochmal zusammengefasst, wieviel Pins nun genau in einer Minimal-version benötigt würden, und das sieht so aus:

===========================================================
Benötigte Pinne
===========================================================

Analog:
-------

Temperatursensoren:     2


Digital:
-------

Pololu-Stepper:         9       (4 x STEP, 4 x DIR, 1 x ENL)

Heater:                 2       (OC1A(PD4), OC1B(PD5))

Lüfter:                 1

LCD:                    4

Tasten:                 2       (Minimum, gern auch mehr)

Ethernet / ISP:         5

RS232:                  2       (Txd0, Rxd0)

SD-Card:                4       (Din, Dout, CS, CLK)

EndStops:               3

[RS485:                 4       (Txd1, Rxd1, TxENL, RxENL)] 

-----------------------------------------------------------
 Summe:                34 [38]
===========================================================

Ich hab in eckigen Klammern mal den RS485-Anschluss optional mitberücksichtigt. Aber wenn man den weglässt käme man auf 34 Pins.

Von den insgesamt 32 Pins sind 7 für Ethernet, ISP und RS232 bereits auf dem Board belegt. 24 sind über externe Anschlüsse nach aussen geführt und auf einem sitzt so ein komischer Jumper, ich bin nicht ganz sicher, aber ich glaube der ist für Pollin-interne Zwecke, also wenn man die Pollin-Firmware updaten will, könnte also notfalls auch noch genutzt werden.

Falls ich also jetzt nix übersehen oder vergessen habe, sieht es bis hierhin gar nicht mal so schlecht aus, wenn es noch gelänge, 2 Pins einzusparen wären zumindest was die Anzahl der Pinne betrifft, die Voraussetzungen für eine Co-Prozessor-lose Version gegeben.

Als Kandidaten für die 2 Pins fiele mir zum einen der Lüfter ein. Ich weiss zwar nicht genau, wo der zum Einsatz kommen soll, aber vielleicht kann man den ja einfach auf Dauerbetrieb setzen. Oder hat der was mit dem Extruder zu tun und es ist zwingend erforderlich den an und abschalten zu können ?

Zum anderen war da noch der Hinweis von Wolfgang, das man ev. auch mit nur einem Pin alle Endstops abhandeln könnte.

Wenn das ginge hätte man sogar noch einen in Reserve oder man könnte halt wahlweise damit den Lüfter schalten.

Soweit der Überblick. Falls das so ginge würde ich als erstes damit anfangen, einen Entwurf für die Co-Prozessor-lose Version machen, weil das wohl die einfachere Variante wäre.

Gruss, Case

Edited 4 time(s). Last edit at 08/31/2010 09:44AM by case.

Man kann mehrere Tasten über einen Analogpin abfragen, wenn man ein kleines Widerstandsnetzwerk verwendet. Je nach Taste wird dann eine andere Spannung erzeugt.

Kann man nicht einige Pins von Ethernet und SD-Card und auch LCD parallel legen? Wenn die vom jeweiligen Chip Select bzw. Enable nicht angesteuert werden, können die anderen Pins sich ja beliebig verändern.

Die SD-Card hängt für gewöhnlich am SPI-Bus. Den sollte man ohnehin ansonsten freilassen, man braucht ihn ja zum Programmieren des Chips. Die Karte braucht also maximal einen Port für ihr Chip Select.
Die Ansteuerung von LCDs ist so eine Sache, bei direkter Ansteuerung brauchen die 11 oder 7 Ports - also viel zu viel. Ich hab mein Display über I²C angesteuert - das sind dann nur 2 Pins.
Wie bzw. wo Ethernet üblicherweise angeschlossen ist, weiß ich nicht.

Quote
Tobias
Wie bzw. wo Ethernet üblicherweise angeschlossen ist, weiß ich nicht.

Beim NetIo auch am SPI-Bus.

Quote
Peer
Man kann mehrere Tasten über einen Analogpin abfragen,

Alle 8 Anlogpins sind nach aussen geführt, hätte man also 6 zur Auswahl, ich kann allerdings nicht einschätzen, wie gut und sauber die dann ansprechen, von wegen entprellen und so, aber es ist auf jedenfall schon mal eine Option.

LCD zum Ethernet oder SD-Card parallel legen kann ich ebenfalls schlecht einschätzen, bzw. Ethernet ist auch nicht nach aussen geführt. Dann vielleicht schon eher die I2C-Variante, daran hatte ich auch schon gedacht, habs allerdings selbst noch nicht gemacht.

Alternativ fiel mir noch dazu ein, das LCD und die Tasten an einen ganz kleinen Atmel wie z.B. einen 2313 zu hängen und dann als ne Art serielles Terminal mit Txd1 und Rxd1 vom 644p anzuschliessen.

Damit hätten wir jetzt schon einige Optionen zur Auswahl, so dass man sich um die restlichen beiden Pins wohl keine Sorgen zu machen braucht.

Und bei mir sind jetzt auch erstmal keine weiteren Fragen mehr offen, ich melde mich wieder sobald ich einen ersten konkreten Entwurf hab.

Danke für Eure vielfältigen Vorschläge und Erläuterungen.

Gruss, Case

Edited 2 time(s). Last edit at 08/30/2010 08:46PM by case.

Quote

Trotzdem habe ich bis hierher jetzt aber schon etwas den Eindruck, das manche Funktionen wie Extruder-Synchronisation einigermaßen zeitkritisch sind

Es ist völlig richtig, dass der Extruder(-Motor) synchron zu den anderen Achsen laufen sollte. Die dafür erforderlichen Berechnungen sind allerdings erheblich einfacher, wenn alle Achsen vom gleichen Prozessor und im gleichen Arbeitsspeicher vollzogen werden. Ansonsten muss man nicht nur die notwendigen Schritte berechnen, sondern diese auch noch an das andere Board kommunizieren. Letzteres kostet wertvolle Mikrosekunden.

Quote

und wenn ich mir vorstelle, dass dann noch gleichzeitig über Ethernet Daten auf die SD-Karte geschaufelt werden sollen

Das geht über Timer mit verschiedenen Prioritäten. Der Timer für die Schrittmotoren hat eine hohe Priorität, der für die Kommunikation eine geringere. Ist der Prozessor mit den Motoren ausgelastet, kann die Kommunikation schon mal für einen Moment aussetzen. Einer LCD-Anzeige würde dann wohl eine noch niedrigere Priorität zukommen - die bekommt die Prozessorleistung, die die anderen übrig lassen.

Wenn diese ATmega-Dinger jetzt 64-bit (Integer) in der Hardware rechnen könnten ... *träum*

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Der Ventilator wird verschieden verwendet.

Zum einen kann man damit bei kleinen Flächen "Kühlschleifen" realisieren. Der Extruder fährt eine gewisse Zeit um die Fläche mit eingeschaltetem Ventilator.

Ich verwende ihn um am Schluss um das Heizbett schneller ab zu kühlen. Schalte ihn also nur am Schluss ein wenn die Maschine steht.

Dann hab ich ihn auch schon mal bei PLA verwendet um den Transportbereich des Extruders zu kühlen, damit sich die Transportzahnung nicht so schnell in das Filament frisst.


Außerdem sehe ich bei dir keine Pins um das Heizbett zu steuern ?

---

Mfg
Wolfgang

Aller Anfang war schwer - Wolfstrap

Reprap-fab.org

Erfahrungen kann man leider schlecht weiter geben, die muss man selber machen.

> keine Pins um das Heizbett zu steuern ?

Die sind in den:

Quote

Temperatursensoren: 2
Heater: 2

enthalten.

Ja dann ist gut...

---

Mfg
Wolfgang

Aller Anfang war schwer - Wolfstrap

Reprap-fab.org

Erfahrungen kann man leider schlecht weiter geben, die muss man selber machen.

Quote
Wolfgang
Zum einen kann man damit bei kleinen Flächen "Kühlschleifen" realisieren. Der Extruder fährt eine gewisse Zeit um die Fläche mit eingeschaltetem Ventilator.

Ja, sowas in der Art hab ich gemeint bzw. vermutet. Also behalten wir den Lüfteranschluss schon mal bei.

Momentan bin ich gerade mental etwas mit dem Anschluss der SD-Karte am rumeiern.

Wie Tobias schon angemerkt hat wird die nämlich auch am SPI-Bus angeschlossen wo aber auch schon der ENC mit dranhängt. Da ja auch Daten direkt vom Ethernet auf die Karte geschaufelt werden sollen, also quasi gleichzeitig betrieben werden (anders als beim ISP-Interface zum programmieren) wäre das wohl ein ziemliches hin- und her-Geschalte, ich frage mich obs da nicht Timing-probleme geben könnte bzw. weiss noch vom Avr-NetIo-Forum her das die ziemliche Schwierigkeiten hatten die Karte anzuschliessen, meist gabs dann Fehler oder Probleme beim Netzwerk.

Andererseits würde ich von etwas, das sich "Bus" nennt, erwarten, dass es sowas kann, vielleicht ist das auch eine Frage der sauberen Programmierung.

Und zumindest würde es dann passen mit den Pins.

Gruss, Case

Interessant wäre es vielleicht, wenn man die Heizausgänge an einen PWM-Ausgang legt. Dann kann man den Wärmeeintrag in Extruder/Druckbett bequem und sehr sanft über Pulsbreitenmodulation regeln.

Wenn Pins frei bleiben, würde ich weitere Temperaturmessstellen verwenden wollen, insbesondere am oberen Ende die Metalltemperatur überwachen wollen; einfach zur Überwachung, dass da nichts anfangen kann zu schmelzen, oder für Tests unterschiedlicher Düsen; oder auch zur Temperaturüberwachung eines geschlossenen Gehäuses um das Ganze. (Das ist aber keine essentielle Funktion, da das auch mit einer externen Vorrichtung machen könnte.) Wenn man noch mehr Sensoren bräuchte, könnte man auch mit einem Analogmultiplixer (74HC4067) die Eingänge multiplizieren.

ok, ist vorgemerkt.

Hallo zusammen,

da bin ich wieder.

sorry, dass es etwas lange gedauert hat, aber als Selbstständiger nenne ich nur ein äusserst geringes Maß an Freizeit mein eigen ...

Na, wieauchimmer, jedenfalls hat mich die Sache nicht mehr losgelassen und ich bin inzwischen ein bischen weiter gekommen.


Aktueller Ansatz ist also folgender:

- Pollin NetIo als Grundmodul
- dazu Pollin Addon-Card (bietet Reset-Taste, SD-Card-Slot und LCD-Anbindung via I2C)
- eine Platine, die ausser den üblichen Komponenten wie Polulus, Mosfets, Anschlüsse für Sensoren und Optos usw. die Pollin-Boards sozusagen integriert und derweil noch als Träger fungiert für ein LCD-Display und 5 Tasten.


(Disclaimer) : Ums gleich mal vorweg zu nehmen, das ganze ist ein einziges Chaos und Riesen-Gefrickel, vor der bevorstehenden Lötaktion wird mir jetzt schon schlecht, und ob das ganze Ding jemals wirklich laufen wird steht in den Sternen, also meine rechte Hand würd ich darauf jedenfalls nicht verwetten. Achja, und von Elektronik hab ich auch nicht wirklich Ahnung

OK, soviel zu den Formalitäten, ungeachtet dessen versuch ichs einfach mal und was ich noch vergass zu erwähnen: die Platine soll als einseitige Lochrasterplatine ausgeführt sein, weil ich blöderweise unterlassen hab, bei meiner letzten Bestellung ne Doppelseitige mitzuordern. Warum einfach, wenns auch schwierig geht. Aber zur Not kann man das Ganze ja als ne Art experimentellen Prototyp betrachten, somit mag das ok sein.

Was ich bislang habe:

- Nach Wochen und Monaten der Auszählerei von Anschlusspinnen eine Art Plan, wie die gewünschten Baugruppen mit den Atmel-Pins korrespondieren könnten.

- Ein Schema bzw. Schaltplan für die Hauptplatine

- Ein Layout für die Hauptplatine

Da ich nur die Demoversion von Eagle verwende, welche ja in der Größe beschränkt ist, hab ich versucht zu tricksen, indem ich das in zwei separaten Layouts für jeweils eine halbe Platine umgesetzt habe, die ich dann anschliessend mit Gimp zusammenmontiert habe (also sorry, wenn die nicht ganz so perfekt ist, mir gings dabei vor allem darum, für mich einen Plan zum löten zu erstellen). Offengestanden hätte ich dieses Problem sehr gerne umgangen, indem ich Geda verwendet hätte und ich habs auch zuerst damit probiert, aber irgendwann hab ich gefrustet aufgegeben, die Lernkurve war mir einfach zu hoch und ich wollte einfach endlich damit anfangen, was in die Tat umzusetzen. Aber prinzipiell halte ich Geda schon für die bessere Alternative (bis auf ein paar Kleinigkeiten).


Was die Ausführung der einzelnen Baugruppen angeht, so hab ich munter hier und da abgekupfert und mich dabei vor allem an Gen7, Ramps und Ultimaker orientiert, ich hoffe mir sind dabei keine gravierenden Fehler unterlaufen und das das Board nicht gleich bei der ersten Inbetriebnahme explodiert (aber ganz sicher bin ich mir da nicht).

Was ich auch noch vorab erwähnen sollte ist, dass damit das ganze funktioniert, die einzelnen Platinen untereinander mit diversen Überbückungskabeln verbunden werden, im Ganzen nicht weniger als 7 Stück an der Zahl. Leider, denn das macht das alles nicht gerade übersichtlicher und ich mache mir auch gewisse Sorgen bezüglich der Kabellängen. Ursprünglich hatte ich mal die Vision, ob man das nicht als eine Art Huckepackplatine im Stile der Arduino-Shields gestalten könnte, aber ich musste schnell einsehen, das das schlichtweg unmöglich ist, hauptsächlich deswegen, weil die Rastermaße der Pollin-Platinen dafür nicht ausgelegt sind bzw. in keinster Weise passen. OK, so ists nunmal, daher die ganzen Verbindungskabel. Es ist also gedacht als Sandwich im 160x100mm-Format, bei dem die Pollin-Platinen nebeneinanderliegend die untere Etage bilden und die Hauptplatine das Display, die Tasten und die ganzen Konnektoren beinhaltet.


So, hier ist schonmal der Schaltplan:



da ich mir nicht sicher bin, ob man darauf bei der gegebenen Auflösung was erkennen kann hier dasselbe nochmal als Eagle-Schema:

anirep1m_rechts.sch

Und hier das Layout:



ich hoffe man kann was darauf erkennen, ich musste das noch verkleinern ums hier hochladen zu können. Die Eagle-Files lass ich weg, weil sichs ja wie gesagt um eine Montage handelt.

Um mit dem Schaltplan etwas anfangen zu können ist es zwingend notwendig, die Schaltpläne der Pollin-Platinen mit hinzuzuziehen. Ich habs mir aus Zeitgründen erspart, die nochmal neu in Eagle zu erstellen und verweise stattdessen auf die Original-Doku bei Pollin:

Zum einen das NetIo-Board, Schaltplan steht auf S.7

[www.pollin.de]

sowie das Addon-Board, Schaltplan steht auf S.7

[www.pollin.de]

Ich hab in meinem Eagle-Schema zusätzlich notiert, an welche Atmel-Pinne die jeweiligen Baugruppen angeschlossen werden, hier nochmal in eine tabellarische Übersichtaus Atmel-Sicht:

PA0 Taste3
PA1 Taste2
PA2 Taste1
PA3 Polulu-Z/Step
PA4 Polulu-Z/Dir
PA5 Temp3
PA6 Temp2
PA7 Temp3

PC7 Polulu-Ext/Dir
PC6 Polulu-Ext/Step
PC5 Polulu-Y/Dir
PC4 Polulu-Y/Step
PC3 Polulu-X/Dir
PC2 Polulu-X/step
PC1 I2C-SDA
PC0 I2C-SCL

PD7 Fan
PD6 Zminmax
PD5 Heat2
PD4 Heat1
PD3 Yminmax
PD2 Xminmax
PD1 TX (RS232)
PD0 RX (RS232)

PB7 ISP-SCK
PB6 ISP-MISO
PB5 ISP-MOSI
PB4 ENC28J60-CS
PB3 SD-Card-CS
PB2 ENC28J16-INT
PB1 Taste5
PB0 Taste4

Prinzipiell sieht es also so aus, das alles haargenau aufgeht Was nicht zuletzt den ganzen Verbindungskabeln zu verdanken ist. Vielleicht sollte ich dazu auch noch die tabellarische Übersicht posten.

Also, im folgenden wird die Hauptplatine als "Anirep" bezeichnet (steht für AVR-NetIo-Reprap):

Verkabelung:
==========

- Anirep/Jp16 und Addon/Ext8 an NetIo/Ext (MinMax, Heater, Taste4, SD-CS, 5V, GND)

- Anirep/Jp17 an NetIo/Jp11 (Taste5)

- Addon/Isp (wird herausgeführt an externe Buchse zum brennen) (ISP-MISO, ISP-MOSI, ISP-SCK, Reset, 5V, GND)

- Addon/Isp1 an NetIo/Isp (SD-MISO, SD-MOSI, SD-SCK, Reset, 5V, GND)

- NetIo/Jp3 an Addon/Jp4 (I2C-SDA und I2C-SCL an Atmel-Pin PC1 und PC0)

- Anirep/Jp14 an Addon/Jp5 (LCD)

- NetIo/Jp3 und NetIo/Jp9 und NetIo/Jp7 an Anirep Jp18 (Temp1, Temp2, Fan, Taste1, Taste2, Taste3, Pollulu X, Y, Z, Ext)

Anmerkung: Auf dem ISP-Port wird nicht nur die SD-Karte als SPI-Bus durchgereicht, sondern darauft läuft natürlich auch noch der ISP-Anschluss zum flashen des Atmel und wird deshalb als "lose baumelndes" Kabel herausgeführt. (Ist nicht schön, ich weiss, aber ev. kann man das Kabel mit ein bischen Fummelei ein- und aus-stöpseln, falls man das mechanisch zwischen den Sandwich-Schichten hinbekommt, das hängt wohl letztlich vom Abstand der Sandwich-Ebenen zueinander ab, bei mir grad aktuell 24mm, aber kann man notfalls noch etwas vergrößern.) Ausserdem hängt am SPI-Bus auf der NetIO-Seite noch der ENC28J60 (Ethernet) mit dran, ich hoffe mal, das das so hinhaut, normalerweise sollte SD-Card oder ENC durch eine jeweils individuelle CS-Leitung (Chip-Select) auswählbar sein und das wäre ja auch der Sinn von einem Bus-System. Aber ich misstraue der Sache noch etwas solange ichs nicht live funktionieren sehe und möglicherweise hats auch Auswirkungen darauf, wie das softwareseitig implementiert wird (dh., ev. geht nicht beides gleichzeitig). Mal schauen.

Anmerkung2: Um die SD-Card auf dem Addon stabil ans laufen zu bringen ist es wahrscheinlich notwendig, den dortigen Spannungsteiler aus Widerständen zu umgehen und stattdessen noch einen Pegelwandler LVX125 auf dem Addon zu integrieren. Ist zwar unangenehm, aber nach allem was ich (theoretisch) weiss, wohl die sauberste und stabilste Lösung.

OK, soviel dazu in aller Kürze

Kommentare und Anmerkungen sind erwünscht, Änderungsvorschläge dagegen eher weniger das layouten war ein echter Alptraum, hab nicht die geringste Lust daran nochmal was zu ändern, falls allerdings jemand auf Anhieb gravierende Fehler entdeckt, die dazu führen würden das das Board explodiert, würde es mich natürlich schon interessieren.

Schade übrigens, das Peer hier nicht mehr online zu sein scheint

Achja, noch eins zum Schluss: Ich vermute mal das der Atmega644 zu klein ist um die ganze benötigte Software unterzubringen, darum hab ich schon mal einen Atmega1284p hier in Reserve liegen.

OK, mal schauen, was aus der Sache wird (und ob überhaupt etwas).

Gruss, Case

Edited 5 time(s). Last edit at 07/08/2011 07:48AM by case.

Wow, was ein Post.

Die Anziehungskraft von Eagle muss schon magisch sein wenn man solche Klimmzüge in Kauf nimmt.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Naja, es war wohl vor allem die Anziehungskraft der Möglichkeit, mit der eigentlichen Arbeit loslegen zu können. Eagle ist mir halt seit Jahren geläufig und ich kann damit sicher und zielgerichtet arbeiten.

Bei Geda hab ich eingesehen, das man (oder zumindest ich) nicht mal eben mit zwei oder drei Tagen Einarbeitung zum gleichen Punkt kommt. Ich finde Geda aber dennoch gut und habs mir mal für später vorgemerkt. Ich könnte mir z.B. gut vorstellen das zu verwenden, wenn die grobe Entwicklungsarbeit getan ist und man ein druck- bzw. ätzbares PCB-Layout ins Netz stellen möchte, bei meinem Layout gings mir ja zunächst mal nur darum, eine Art Verdrahtungsplan für die Lochrasterplatine als Orientierung zu haben.

Gruss, Case

Quote

Bei Geda hab ich eingesehen, das man (oder zumindest ich) nicht mal eben mit zwei oder drei Tagen Einarbeitung zum gleichen Punkt kommt.

Schlimmer als es aussieht. Die Bedienung ist nicht besser und nicht schlechter, nur sind die Tastaturkürzel ungewöhnlich. Obendrein zwischen beiden Programmen (Schaltplan/Layout) unterschiedlich. Einen Schaltplan in ein Layout zu übertragen ist plötzlich ganz einfach, wenn man "xgsch2pcb" kennt. Ist bei Ubuntu dabei.

Dafür hat das gEDA den Footprint unabhängig vom Bauteil. Man zeichnet also einen Widerstand und entscheidet erst später, welche Grösse der hat. Das habe ich schon oft gebraucht, denn so ein Erbsenzähler wie ich justiert auch noch ein 0,01 mm zu kleines Loch nach.

Was dem gEDA am meisten fehlt ist eine Art Objekt-Editor. Wenn eine Bahn genau 7,3 mil breit sein soll, muss man das Layout in einem Texteditor aufmachen, weil es dafür einfach keinen GUI-Befehl gibt. Gut wiederum ist, dass das überhaupt geht.

Hmm. Eigentlich ging's hier um das Pollin-Board, oder?

Wenn ich das richtig verstanden habe, dann kann man an den ISP einfach mehrere Geräte gleichzeitig hängen, oder? Also die SD-Karte, den Programmer und auch noch das Display.

Welchen Kartenleser nimmst Du denn? Mir hat man den hier empfohlen: [koti.kapsi.fi] , der braucht nur den ISP plus einen Pin.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Das xgsch2pcb ist bei mir auch in der Geda-Toolchain (unter Debian) enthalten und ich denke auch, dass die Bedienung ok ist, es lag wohl eher an mir, weil ich noch zu sehr auf das andere eingetunt war. Aber ich werd mich da noch einarbeiten.

Bezüglich des Objekt-Editors ist halt das gute, das es offene Quellen sind, ich schätze also, früher oder später wirds da auch einen grafischen Editor für geben, zumindest besteht die Möglichkeit.

Quote

Wenn ich das richtig verstanden habe, dann kann man an den ISP einfach mehrere Geräte gleichzeitig hängen, oder? Also die SD-Karte, den Programmer und auch noch das Display.

Genau, wobei das "ISP" für In-System-Programming(-Interface) steht und genaugenommen nur den Port zum programmieren bezeichnet, aber die Anschlüsse, an denen dieses am Atmel hängt, zusammen den SPI-Bus (SPI=Serial Peripheral Interface) bilden (vgl. Wikipedia SPI) , an welchen man mehrere Geräte dranhängen kann. Dabei dienen MISO, MOSI und SCK als gemeinsame Bus-Leitungen und jedes Gerät braucht dann nochmal eine separate Leitung (CS) anhand derer der Master auswählen kann mit welchem gerade kommuniziert wird. Wobei für die ISP-Programmierung als Sonderfall keine CS-Leitung benötigt wird, da die ja nicht gleichzeitig mit z.B. der SD-Karte zusammen betrieben wird.

Ausser der SD-Karte hängt beim NetIo noch der Ethernetchip mit am SPI-Bus, das LCD-Display allerdings nicht. Letzteres wird über I2C-Anbindung realisiert, auf dem Addon-Board befindet sich dafür ein eigener Chip PCF8574, der die I2C-Signale fürs LCD aufbereitet.

Quote

[Welchen Kartenleser nimmst Du denn? Mir hat man den hier empfohlen: koti.kapsi.fi , der braucht nur den ISP plus einen Pin.

Ja, das sind eben die drei SPI-Leitungen plus eine für CS.

In meinem Falle ist der Kartenleser regulärer Bestandteil des Addon-Boards, wobei es sich eigentlich nur um einen passenden Kartenslot handelt, plus 4 Widerstände als Spannungsteiler, die aus den 5V die von der SD-Karte benötigten 3.3V generieren.

Es wird aber überall von einer solchen Umsetzung aufgrund eines zu ungenauen 3V-Pegels dringend abgeraten, (siehe dazu z.B. auch diesen Link sowie diesen Link). Und auch in der Praxis hat sich beim Betrieb der Addon-Karte gezeigt, das de Spannungsteilervariante zu Problemen führte, in einigen wenigen Fällen gings wohl, aber dann in Abhängigkeit der jeweiligen Speicherkarte auch oft wieder nicht, oder es ging, aber das Ethernet funktionierte nicht. Somit ist hier der Einsatz eines bidirektionalen Pegelwandlers wohl die beste Lösung, den man dann halt noch auf das Addon mit draufpacken muss. Aber zumindest hat man hier den Slot für die Karte schon integriert.

Für das Gen7 spricht aber auch nix dagegen, das als eigene kleine Platine zum draufstecken zu machen, der von Dir verlinkte Kartenleser hat ja eine schöne kompakte Bauform. Wenn Du sowas bei Dir auf den ISP bzw. CONN6 draufsteckst müsstest Du da ev. noch eine Abzweigung zu einem separaten Pin für CS machen, den Du vielleicht auf dem MISC-Connector mit aufstecken kannst. Oder alternativ könntest Du den vielleicht auch komplett auf dem MISC draufstecken und den SPI softwaremässig realisieren, ich habe aber keine Erfahrung damit und kann nicht sagen ob und wie gut das funktioniert (finde es aber nicht uninteressant).

Gruss, Case

Edited 1 time(s). Last edit at 07/08/2011 01:18PM by case.

Quote

Für das Gen7 spricht aber auch nix dagegen, das als eigene kleine Platine zum draufstecken zu machen, der von Dir verlinkte Kartenleser hat ja eine schöne kompakte Bauform. Wenn Du sowas bei Dir auf den ISP bzw. CONN6 draufsteckst müsstest Du da ev. noch eine Abzweigung zu einem separaten Pin für CS machen, den Du vielleicht auf dem MISC-Connector mit aufstecken kannst.

So in der Art habe ich da schon einen Plan, doch der ist noch nicht fertig. Gut, dass ich da nicht falsch liege.

Quote

Oder alternativ könntest Du den vielleicht auch komplett auf dem MISC draufstecken und den SPI softwaremässig realisieren, ich habe aber keine Erfahrung damit und kann nicht sagen ob und wie gut das funktioniert (finde es aber nicht uninteressant).

Software-Lösungen sind immer doof, die kosten wertvolle Rechenzeit. Gestern habe ich es das erste Mal geschafft, auch die Teacup an die Grenzen zu bringen.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote

So in der Art habe ich da schon einen Plan, doch der ist noch nicht fertig. Gut, dass ich da nicht falsch liege.

Dann könnte Dich vielleicht ein Blick auf diesen Link interessieren.

Quote

Software-Lösungen sind immer doof, die kosten wertvolle Rechenzeit.

Ja, das ist schon richtig. Ich finde das als Alternative halt interessant, weil es mich etwas nervös macht, das Ethernet und die SD-Karte an der gleichen Leitung hängen zu haben, wollte man zB. eine Datei per Ethernet auf der SD speichern müsste da ja dauernd hin- und her geswitcht werden. Aber vielleicht ist das auch gar nicht so wild, weil man dafür ja schliesslich die CS-Leitung hat. Mir fehlen da einfach noch die praktischen Erfahrungen, aber das wird sich ja hoffentlich bald ändern

Gruss, Case