Selbstbausteuerung mit open source fw?

  • Hallo Steffen,


    der ist ARM-Mäßig am unteren Ende, bringt aber einiges mit :)


    "The Stellaris® LM3S8962 microcontroller is based on the ARM® Cortex™-M3 controller core operating at 50 MHz, with 256 kB single-cycle flash, 64 kB single-cycle SRAM, 10/100 Ethernet MAC/PHY, a CAN controller, a 24-bit Systick Timer, 4x 32-bit or 8x 16-bit general-purpose timers, a watchdog timer, a SSI / SPI controller, an I2C interface, 2 UARTs, an analog comparator, a 10-bit analog-to-digital converter (ADC) with 4 input channels (+/- 1LSb of accuracy), a motion-control Pulse Width Modulation (PWM) module with 6 output channels, two Quadrature Encoder Inputs, a battery-backed hibernation module with RTC and 256 bytes of non-volatile state-saving memory, a low drop-out voltage regulator, brown-out reset, power-on reset controller, and up to 42 GPIOs. The LM3S8962 also features hardware-assisted support for synchronized industrial networks utilizing the IEEE 1588 Precision Time Protocol (PTP)."


    Aber es gibt sicherlich auch Boards mit mehr Fump, beispielsweise BeagleBoard - aber das wird teuer.


    Atmel hingegen: http://www.watterott.com/de/Atmel-AVRXPLAIN :)


    Wie üblich aber - wir sind zu früh!


    CAN hingegen klingt gut. Bussystem, das heißt: man kann wunderbar alles modularisieren und die Komponenten können miteinander reden, wobei ich nicht weiß, wie sich das vom Implementationsaufwand verhält. Seriell ist blödsinnig einfach, aber immer nur Punkt-zu-Punkt. BUS-System wäre schon sehr gut - und ein Großteil der Arbeit wird wohl darin bestehen, ein flexibles high-level-Protokoll zu spezifizieren. :)


    Aber - welche Module soll es überhaupt geben und wie sollen sie miteinander reden? Welche Module sind optional und welche müssen da sein? Was davon ist der Boß - oder ist der ein eigenes Modul?


    Mal in's Unreine geschrieben:


    - User Interface Modul (mindestens oder genau eines?)
    - Minimal: Dumme Box mit Richtung und Geschwindigkeit
    - Schnittstelle zu PC mit definitertem Protokoll (via USB?)
    - Schlaue Box mit GOTO. Real Time Clock und GPS
    - Beliebige benutzerdefiniterte Lösungen (z.B. Bluetooth, LAN)
    - Autiguiding-Eingang


    - Motorensteuerung, parametrisierbar, mit und ohne Winkelsensoren.
    Braucht Speicher für Konfiguratiosnparameter, PEC, ...


    - Filterrad (optional)


    Ich versuche nur immer noch, mir das irgendwie vorzustellen.


    Gruß,
    Jens

  • Hallo Jens,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    "The Stellaris® LM3S8962 microcontroller is based on the ARM® Cortex™-M3 controller core operating at 50 MHz, with 256 kB single-cycle flash, 64 kB single-cycle SRAM, 10/100 Ethernet MAC/PHY, a CAN controller, a 24-bit Systick Timer, 4x 32-bit or 8x 16-bit general-purpose timers, a watchdog timer, a SSI / SPI controller, an I2C interface, 2 UARTs, an analog comparator, a 10-bit analog-to-digital converter (ADC) with 4 input channels (+/- 1LSb of accuracy), a motion-control Pulse Width Modulation (PWM) module with 6 output channels, two Quadrature Encoder Inputs, a battery-backed hibernation module with RTC and 256 bytes of non-volatile state-saving memory, a low drop-out voltage regulator, brown-out reset, power-on reset controller, and up to 42 GPIOs. The LM3S8962 also features hardware-assisted support for synchronized industrial networks utilizing the IEEE 1588 Precision Time Protocol (PTP)."


    Aber - welche Module soll es überhaupt geben und wie sollen sie miteinander reden? Welche Module sind optional und welche müssen da sein? Was davon ist der Boß - oder ist der ein eigenes Modul?


    Mal in's Unreine geschrieben:


    - User Interface Modul (mindestens oder genau eines?)
    - Minimal: Dumme Box mit Richtung und Geschwindigkeit
    - Schnittstelle zu PC mit definitertem Protokoll (via USB?)
    - Schlaue Box mit GOTO. Real Time Clock und GPS
    - Beliebige benutzerdefiniterte Lösungen (z.B. Bluetooth, LAN)
    - Autiguiding-Eingang


    - Motorensteuerung, parametrisierbar, mit und ohne Winkelsensoren.
    Braucht Speicher für Konfiguratiosnparameter, PEC, ...


    - Filterrad (optional)
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    das ist wirklich nicht mehr Stand der Dinge - zumindest Richtung Rechenleistung; aber die Schnittstellen sind schon beeindruckend!


    Ich lese aus dem derzeitigen Stand der Diskussion heraus, daß die Steuerung erst mal möglichst einfach sein soll; 2 Motoren - auch gerne mit ordentlich Dampf - ansteuern, net viel mehr.
    Schnittstelle für den Anschluß eines Rechners - kann eigentlich nur USB sein; über einen Adapter damit auch Bluetooth - der dann via Software den Rest macht; Hardware-Zubehör wie GPS-Receiver, Filterrad u.ä. sowie Software-Zubehör wie GoTo mit Sternkatalogen etc. über den PC.
    Kann man mit leben ... aber so richtig dolle find ich das net ;)


    Filterrad, Timer-gesteuerter) Auslöser für eine DSLR, GPS, Auto-Guider u.ä. könnte man vielleicht als Modul (vielleicht als separate Box) machen, die an den Controller via Bus angeschlossen wird ...
    Gruß,


    Steffen

  • Servus!
    Wo bleiben die Fortschritte? [:)] Ihr verzettelt euch in Controllertypen und das eigentliche Projekt tritt immer mehr in den Hintergrund, hab' ich zumindest so das Gefühl. [:D] Könnte einer von Euch Experten mal ein vorläufiges Hardware-Konzept einstellen (*) (ein konkretes mit Bildern bitte!)? Eins gab es ja schon auf Seite..... jetzt hab ich's! Seite 8 [:D]
    Gruß
    Gerhard
    Derzeit klingt es eher nach Open Source und vielleicht Selbstbausteuerung! [:D]
    (*) und bitte nicht mit vierlagigen Prints für sowas anfangen!

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">... mal ein vorläufiges Hardware-Konzept einstellen (*) (ein konkretes mit Bildern bitte!)? ...<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Hallo,


    hier ist meine Steuerung (mit Bildern):
    http://martin.cibulski.de/atm/…controller_4/index_de.htm


    Damit steuere ich mein Dobson-Teleskop im AltAz-Betrieb. Die Steuerung ist nicht modular aufgebaut, daher würde ich heute manches anders machen:


    Prozessor: Cortex M3, z.B. LPC1768 von NXP
    Der neue ARM-CPU-Kern CortexM3 ist der Nachfolger des ARM7TDMI, der z.B. noch im SAM7 von Atmel enthalten ist.
    LPC1768 verfügt über alle zuvor genannten Schnittstellen (RS232, I2C, CAN, USB). Leider habe ich noch kein Steckmodul mit diesem Chip auf dem Markt gefunden, also muss man SMD im 0.5mm Raster löten ;(


    Massenspeicher:
    Micro SD Karte, billig, massenhaft Speicher und PC-kompatibel.
    Open Source-Software für FAT-Dateisysteme gibt es.


    Betriebsystem:
    FreeRTOS oder ähnliche, für Open Source nutzbar.


    USB-Anbindung:
    Auch hier ist Open Source Software vorhanden, z.B. von Bertrik Sikken, ob für den neuen LPC1768, weiß ich allerdings nicht.



    Handbox: Über RS232 angeschlossen, evtl. galvanisch getrennt.
    Dann in der Handbox einen Atmel AVR Prozessor.
    Oder Tasten und Display über I2C anschließen, aber wie galvanisch trennen ?


    Motortreiber: Allegro 3972 (bis 1.5 Ampere), für mehr Ströme gibt es den 3985, der externe Transistoren ansteuern kann.
    Die Motortreiber könnten auf eigenen Platinen sein, die gestapelt montiert werden. Durch die Modulbauweise sind auch mehr als zwei Motoren möglich, der Hauptprozessor könnte die seriellen Daten parallel für 4-6 Motortreiber erzeugen, da er schneller ist als der von mir verwendete Atmel-Prozessor.
    Es könnten Platinen mit 3985 und externen FETs für große Motoren und Platinen mit 3972 für kleine Motoren (Filterrrad, Derotator, Fukussierer) kombiniert werden.


    Platinengröße: 100x80mm wie bei meiner Steuerung, dann reicht die Freeware-Lizenz von Eagle aus.
    Ein Bopla-Gehäuse 100x120mm (habe ich verwendet) reicht auch für 3 gestapelte Platinen aus.


    Platinenfertigung:
    Könnte z.B. bei Olimex erfolgen. Dort sind auch teilbestückte Platinen möglich, wo die CPU schon drauf ist. Kein Problem, wenn die CPU auch auf anderen Platinen von Olimex verwendet wird, wie es z.B. beim LPC1768 der Fall ist.


    Gruß,
    Martin Cibulski

  • Hallo Martin,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    hier ist meine Steuerung (mit Bildern):
    http://martin.cibulski.de/atm/…controller_4/index_de.htm


    Damit steuere ich mein Dobson-Teleskop im AltAz-Betrieb. Die Steuerung ist nicht modular aufgebaut, daher würde ich heute manches anders machen:


    Prozessor: Cortex M3, z.B. LPC1768 von NXP
    Der neue ARM-CPU-Kern CortexM3 ist der Nachfolger des ARM7TDMI, der z.B. noch im SAM7 von Atmel enthalten ist.
    LPC1768 verfügt über alle zuvor genannten Schnittstellen (RS232, I2C, CAN, USB). Leider habe ich noch kein Steckmodul mit diesem Chip auf dem Markt gefunden, also muss man SMD im 0.5mm Raster löten ;(
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    schöne Steuerung - und die Vorschläge hören sich auch interessant an :)
    'Hack a day' hat was zum LPC1768:
    http://hackaday.com/2009/11/21…-lpc1768-microcontroller/
    Ist fast unglaublich, was auf so eine kleine Platine paßt ...
    Gruß,


    Steffen

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">'Hack a day' hat was zum LPC1768:
    http://hackaday.com/2009/11/21…-lpc1768-microcontroller/
    Ist fast unglaublich, was auf so eine kleine Platine paßt ...
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Hallo Steffen,


    diese Platine habe ich auch gefunden, ich glaube, sie lässt sich nur über ein Web-Frontend auf der Herstellerseite programmieren.
    Besser fände ich eine Plattform wie YAGARTO, wo man Editor, Compiler und Debugger zur Verfügung hat. Ein Debugger-Anschluss (JTAG) ist auf dem mbed-Modul leider nicht vorhanden.


    Gruß,
    Martin

  • Hallo Martin,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    Hallo Steffen,


    diese Platine habe ich auch gefunden, ich glaube, sie lässt sich nur über ein Web-Frontend auf der Herstellerseite programmieren.
    Besser fände ich eine Plattform wie YAGARTO, wo man Editor, Compiler und Debugger zur Verfügung hat. Ein Debugger-Anschluss (JTAG) ist auf dem mbed-Modul leider nicht vorhanden.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    das ist wohl der große Nachteil.
    YAGARTO in Kombination z.B. mit den Ethernut-Boards ... ?!?
    Gruß,


    Steffen

  • Hallo Martin!
    Prima, was Du machst! Habe Dich vor Jahren schon bewundert! Ganz toll, wieder mal von Dir zu hören!
    Viele Grüße
    Gerhard

  • Hallo,
    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">zunächst mal müßte man natürlich ein Display finden, welches bezahlbar und für winterliche Temperaturen geeignet ist<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Man könnte ja beheizen, falls nötig...
    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Schnittstelle für den Anschluß eines Rechners - kann eigentlich nur USB sein; über einen Adapter damit auch Bluetooth - der dann via Software den Rest macht; Hardware-Zubehör wie GPS-Receiver, Filterrad u.ä. sowie Software-Zubehör wie GoTo mit Sternkatalogen etc. über den PC.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    bedenke, dass die meisten CPUs nur USB-Clients sind -&gt; also nix mit Bluetooth-Stick dran und fertig...
    USB braucht FW-seitig zudem einen ziemlich aufwändigen Stack, wenn man nicht über FTDI-Chips geht.
    Warum keinen Objektkatalog auf SD am Controller? Ist nicht sehr kompliziert und entsprechende Datenquellen gibt es auch.
    LX200 hat es ja auch im Protokoll.


    (==&gt;)Gerhard:
    Geduld bitte! Es hat doch gerade erst angefangen...


    (==&gt;)Martin:
    Super - dein Projekt; wäre toll, wenn du mit machen würdest!
    Die Allegro Treiber scheinen ja 'ne Alternative zu den Trinamics zu sein, werde mir die Teile mal anschauen...
    Die LPC-Controller von NXP waren vor Jahren mal ziemlich buggy... kann man die mittlerweile benutzen? ;)


    Scheint ja doch Richtung ARM zu gehen...


    Grüße
    Michael

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: a_treff</i>
    Warum keinen Objektkatalog auf SD am Controller? Ist nicht sehr kompliziert und entsprechende Datenquellen gibt es auch.
    LX200 hat es ja auch im Protokoll.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Klingt wieder reichlich monolithisch. :)


    Klar, SD kann ich selbst mit einem Shield für den Arduino beackern.
    Sogar auf relativ hohem Level, da muß man nicht unbedingt sektorweise arbeiten.


    Die Minimalversion würde doch zwei Motoren treiben und über eine Handbox bedienen. Die ist sicherlich einfacher gedacht als das hier:


    http://jyetech.com/Products/LcdScope/06203P_3.jpg


    (Habe den Vorgänger, gut bedienbar!)


    Nur sind monolithische Ansätze schlecht in Gruppe zu entwickeln, schwer an Änderungen anzupassen und typischerweise unflexibel. Was man dadurch spart, daß man einen großen Block produziert, bezahlt man durch deutlich höhere Komplexität. Nicht umsonst besteht Software üblicherweise aus Schichten - man schaue sich nur mal Netzwerksoftware an.


    Schauen wir mal von oben:


    Oberste Schicht ist die, die der Benutzer sieht. Der will im Extremfall eine automatisierte Beobachtungsnacht mit Fotografie.
    Das System würde vielleicht nur eine Warteschlange voller Befehle abfahren:


    Da reden wir über "Gehe zu M31, fahre Fotoprogramm X ab", "Bleibe an augenblicklicher Position, fahre Fotoprogramm Y ab" und so weiter.


    Darunter dann der Objektkatalog (mit Verwaltung, mit Bahndaten falls erforderlich, mit Mimik zur Wartung usw.
    Also: "Gib mir die Position von M31 und Daten zur subjektiven Bewegung." (Ich könnte ja auch die ISS oder den Mond beobachten. Und hier kann man auch schauen, ob man die Sonne treffen würde.)


    Darunter dann eine Schicht, die ein Objekt mit bekannter Position anfahren und verfolgen kann - hier würde vielleicht auch ein Autoguider angreifen. Hier muß man unabhängig von der Art der Montierung eine Möglichkeit zur Verfügung stellen, zu positionieren und nachzuführen. Diese Schicht weiß auch etwas über PEC.


    Darunter kommt dann wirklich die Motorsteuerung mit Anschluß für Handbox. :)


    5 Schichten, nur Software, stark vereinfacht (die Fotoarie ist beispielsweise nicht 'drin). Es wird immer Punkte geben, wo man diese saubere Trennung verletzen muß: "Tut mir leid, lieber Anwender, aber mit DIESER Montierung kannst Du die ISS nicht verfolgen!", trotzdem aber glaube ich, daß es anders schwierig wird.


    Gruß,
    Jens

  • Hallo Michael,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    bedenke, dass die meisten CPUs nur USB-Clients sind -&gt; also nix mit Bluetooth-Stick dran und fertig...
    USB braucht FW-seitig zudem einen ziemlich aufwändigen Stack, wenn man nicht über FTDI-Chips geht.
    Warum keinen Objektkatalog auf SD am Controller? Ist nicht sehr kompliziert und entsprechende Datenquellen gibt es auch.
    LX200 hat es ja auch im Protokoll.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    um den USB-Anschluß werden wir einfach nicht herumkommen, denke ich - irgendwie muß der Controller sich ja mit dem Rechner unterhalten (ok, es gibt noch Firewire, aber das ist in Summe sicherlich nicht einfacher zu realisieren).


    Muß aber zu meiner Schande gestehen, daß ich die Alt-Az Fraktion gar nicht mit auf der Rechnung hatte (obwohl ich auch gelegentlich mal mit einem Dob beobachte) ... das kann man natürlich auch mit Software auf einem externen Rechner erschlagen, wenn der Controller partout mit ohne Gimmicks aufgebaut sein soll; aber elegant ist des net.


    Gehört dann auch in die Anforderungen mit rein, oder - und was müßte der Controller dann alles zusätzlich können?!


    Steffen

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: selste</i>


    um den USB-Anschluß werden wir einfach nicht herumkommen, denke ich - irgendwie muß der Controller sich ja mit dem Rechner unterhalten (ok, es gibt noch Firewire, aber das ist in Summe sicherlich nicht einfacher zu realisieren).


    Muß aber zu meiner Schande gestehen, daß ich die Alt-Az Fraktion gar nicht mit auf der Rechnung hatte (obwohl ich auch gelegentlich mal mit einem Dob beobachte) ... das kann man natürlich auch mit Software auf einem externen Rechner erschlagen, wenn der Controller partout mit ohne Gimmicks aufgebaut sein soll; aber elegant ist des net.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    USB ist reine Faulheit der PC-Fraktion, die das Leben auf der Modulseite wieder komplizierter macht :)


    Man könnte ja auch seriell arbeiten, dann einen USB-&gt;Seriell-Wandler einsetzen. Oder andenken, die Geräte über Ethernet zu vernetzen.


    Ich bin ja durchaus von USB angetan, wenn es um billige Massenspeicher oder HIDs geht, aber damit Geräte steuern?
    Für diejenigen, die statt einem PC auf die Schnittstelle mit irgendwas an Selbstbaubix zugreifen wollen, heißt das, einen USB-Master zu bauen. Für eine Handbox nicht wirklich toll...


    Gruß und CS,
    Jens


    ("Wenn man nur einen Hammer hat, sieht alles aus wie ein Nagel" :) )

  • Hallo,


    zu USB - schaut mal z.B. hier auf die Schaltung:
    http://www.astrohome.info/StepperFocuser.htm


    USB(Client) läuft über den FTDI Chip.
    Dieser wandelt (intern) auf RS232.
    Die zwei RS232-Leitungen zur CPU kann man dann über
    Optokoppler galvanisch trennen und auch die 5V für den FTDI
    über einen kl. geregelten DC/DC-Wandler führen.
    RS232 könnte man parallel zum FTDI auch über Pegelwandler nach außen führen.
    So hat man USB und RS232 nach außen galvanisch getrennt für die Steuerung.


    Grüße
    Michael

  • Hallo


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    Man könnte ja auch seriell arbeiten, dann einen USB-&gt;Seriell-Wandler einsetzen. Oder andenken, die Geräte über Ethernet zu vernetzen.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Also ich denke Ethernet ist SW seitig genauso aufwändig wie USB, da auch wieder ein Stack benötigt wird.


    Nachdem was ich so in jüngster Vergangenheit gelesen hatte, sollte als PC Schnittstelle beides möglich sein. Seriell und eine aktuelle Schnittstelle (USB oder Ethernet). Man könnte auch zunächst seriell realisieren und die andere hardwareseitig vorsehen.


    Für den Anfang könnte man ja tatsächliche so ein Wandler benutzen.
    Auf Dauer sollte es schon eine richtige USB oder Ethernet Schnittstelle geben, da ein Wandler immer ein Gerät darstellt, das wieder untergebracht werden muß, das vergessen werden kann oder das schlicht die Grätsche machen kann.


    Den Steuerungsbus würde ich so einfach wie möglich halten, da die Module (wie einfache Handbox) gleich viel komplizierter werden. Die Controller der Module müssen ja auch den Bus bedienen. Große Datenmengen laufen hier ja vermutlich nicht und Fehlertoleranz ist in meinen Augen auch eher gering priorisiert. Von daher sollte man den Overhead so gering wie möglich halten.


    Andere Frage: Wie würde denn die USB/Ethernet PC seitig eingebunden? Als virtueller COM Port, oder?


    Grüße
    Volker

  • Hallo Volker,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    [...]
    Nachdem was ich so in jüngster Vergangenheit gelesen hatte, sollte als PC Schnittstelle beides möglich sein. Seriell und eine aktuelle Schnittstelle (USB oder Ethernet). Man könnte auch zunächst seriell realisieren und die andere hardwareseitig vorsehen.
    [...]
    Andere Frage: Wie würde denn die USB/Ethernet PC seitig eingebunden? Als virtueller COM Port, oder?
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    serielle Schnittstelle ist seitens der Hardware vielleicht einfacher - obwohl ich da so meine Zweifel hab - Software-seitig aber ein ziemlicher Horror weil es kein verbindliches Protokoll gibt, im Gegensatz zu USB und Firewire; und von so Goodies wie automatischer Erkennung des Gerätes am Host beim Einstecken haben wir da noch gar nicht gesprochen ...


    Wie der Controller am PC erscheint hängt vom verwendeten OS und dem - ggf. notwendigen - Treiber ab, unter Windows könnte das schon ein COM Port sein, wenn der Controller via USB angeschlossen ist.
    Gruß,


    Steffen

  • Hallo,
    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Also ich denke Ethernet ist SW seitig genauso aufwändig wie USB, da auch wieder ein Stack benötigt wird.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    nicht, wenn man für USB Chips wie die von FTDI für USB (6 EUR) oder XPort von LANtronics (ab 33 EUR) für Ethernet nutzt.
    Schaut euch die Sachen doch mal an.
    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Software-seitig aber ein ziemlicher Horror weil es kein verbindliches Protokoll gibt,<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Wollten wir nicht LX200 machen?
    Das könnte man ja noch zusätzlich mit eigenen Sachen erweitern...


    Wer, außer Martin und Thomas, hat schon was mit Schrittmotoren, deren Ansteuerung und entsprechenden Chips gemacht?


    Grüße
    Michael

  • Hallo,


    hier gibt es auch Infos zu den Ethernet-Teilen von LANtronix:
    http://www.heise.de/ct/projekt…f-LAN-Adapter-284121.html


    Ethernet wäre schon nützlich, da man mit einem externen Wlan-Router
    (Fritzbox etc. f. weniger als 30 EUR) dran, auch eine Funkverbindung vom Notebook zu der Steuerung hätte.


    Man könnte natürlich auch die WiPort von LANtronix vorsehen, das allerdings teurer kommen würde, als die externe Router-Box.


    Funkverbindung über RS232 für eine kabellose Handsteuerbox könnte über XBee-Module von Maxstream laufen,
    wenn auch mit je 30 EUR pro Modul nicht ganz billig.


    Grüße
    Michael

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: selste</i>
    serielle Schnittstelle ist seitens der Hardware vielleicht einfacher - obwohl ich da so meine Zweifel hab - Software-seitig aber ein ziemlicher Horror weil es kein verbindliches Protokoll gibt, im Gegensatz zu USB und Firewire; und von so Goodies wie automatischer Erkennung des Gerätes am Host beim Einstecken haben wir da noch gar nicht gesprochen ...
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Ich mag mich hier als DV-Dino outen, aber sowas braucht kein Mensch :)
    Wenn ich auf serieller ebene arbeite, muß ich auf beiden Seiten die Schnittstellenparameter passend auswählen, alles andere kann man trivial in Software lösen. Das kann sogar eine einfache Handbox, auch wenn man da vielleicht ein NOCH einfacheres Interface möchte. (Notbetrieb?)


    Die Nachteile bei RS-232 (sind wir noch bei C?) sind Geschwindigkeit und die Beschränkung auf zwei Geräte. Dazu noch kein out-of-band-signalling, außer, man schreibt sich da was, aber das wäre Streß. Vorteile: Man kann von seriell aus auf ziemlich alles wandeln, preiswert auf USB und Bluetooth, etwas teurer auf Ethernet mit irgendeinem TCP-Port. Dazu gibt es kaum eine erprobtere, kompatiblere und besser beherrschte Schnittstelle. Die kann ein moderner Microcontroller notfalls auf ein paar Beinchen in Software abfahren.


    Gruß,
    Jens

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: Gamma Ray</i>
    <br />
    Die haben ja wirklich prima Dinge! [:p] Das Board ist schon gekauft! ;)
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Die haben sogar tolle Sachen :)


    Mit http://www.watterott.com/de/Atmel-AVR-Butterfly
    kann man beispielsweise einen programmierbaren Auslöser für die EOS bauen :)


    Gruß,
    Jens
    (Der mit Motoren und Servos nur mit einem Arduino-Shield gespielt hat, das aber sehr einfach fand.)

  • Moin,


    zum Thema Handbox hier noch eine Anregung aus dem Bereich Fokussteuerung: http://www.cosmic-tools.de/Pro…berFoc/body_cyberfoc.html
    (sorry, aber der Typ hat bis auf ein Mal einfach nie geantwortet - ich glaub der verkauft nicht mehr)
    Sowas hatte ich selber mal angefangen zu entwickeln - aber aus Zeitmangel aufgegeben. Bin aber auf jeden Fall Verfechter eines Dreh-Klick-Rades statt Knöpfen (für diese Anwendung)!


    Habe gerade über eine Montierungs-Regelung statt -Steuerung mit Encodern nachgedacht. Sowas würde bei Bedarf als ein alternatives HW-Modul Sinn machen, oder?


    Grüße, Henning

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">(==&gt;)Martin:
    Super - dein Projekt; wäre toll, wenn du mit machen würdest!
    Die Allegro Treiber scheinen ja 'ne Alternative zu den Trinamics zu sein, werde mir die Teile mal anschauen...
    Die LPC-Controller von NXP waren vor Jahren mal ziemlich buggy... kann man die mittlerweile benutzen? ;)
    Grüße
    Michael
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Hallo Michael,
    Ich kann leider nicht mitmachen, aus Zeitmangel und weil ich gerade eine Steuerung entwickle, die allerdings verkauft werden soll. Wie das vereinbar ist, müsste ich noch klären...


    Die Allegro-Bausteine sind die am weitesten parametrierbaren, die ich kenne, man kann so ziemlich alle Schaltvorgänge (on-, off-, blank-time usw.) beeinflussen. Trinamic hat dafür zusätzlich die Schrittfehlererkennung ('Stall Guard'?), aber ich denke, dass man Schrittfehler auch so hören würde, weil dann meistens der Motor komplett hängen bleibt und das ist dann deutlich hörbar. Stall Guard macht sicher Sinn, wenn man den Motor nicht selbst überwachen kann.


    Ich programmiere zur Zeit den LPC2148, nutze davon beide I2C, beide RS232 und SSP für eine SD-Karte, das funktioniert alles. USB habe ich noch nicht, aber der USB-Stack von Bertrik Sikken (LPCUSB) ist für diese Prozessorreihe geschrieben.
    Die neue LPC17xx-Reihe soll die selben (bewährten) Peripheriebaugruppen enthalten wie die LPC2xxx. Der eigentliche CPU-Kern ist von ARM zugekauft und sollte auch funktionieren.


    Gruß,
    Martin

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">YAGARTO in Kombination z.B. mit den Ethernut-Boards ... ?!?
    Gruß,


    Steffen
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Hallo Steffen,


    interessante Boards, mir würde Ethernut 3 gefallen, wenn ein aktuellerer Prozessor drauf wäre. Ein Linux-Betriebssystem wie bei Ethernut 4 würde ich persönlich nicht brauchen. Ich frage mich allerdings, ob man sich von einem solchen Boardsystem abhängig machen sollte, oder besser eigene Hardware entwickeln. Dann müsste man nur darauf achten, dass es die Bauteile in ein paar Jahren noch zu kaufen gibt.


    Ich finde daher ein CPU-Headerboard, welches in die Steuerungsplatine eingesetzt wird, besser.
    Man erspart sich dadurch die komplette Inbetriebnahme einer unbekannten CPU und muss trotzdem nicht viel Fertighardware zukaufen. Solch ein Headerboard kann man auch später nachbauen, falls es nicht mehr lieferbar ist.


    Außerdem muss nicht jeder Softwareentwickler gleich die SMD-CPU löten können, wenn er das Headerboard zukaufen kann.


    Wenn es für die Wunsch-CPU kein Headerboard zu kaufen gibt, würde ich mit einem kompletten Development Board (z.B. LPC-1766STK von Olimex) beginnen. Da kann man zunächst die CPU mit all ihren Schnittstellen kennen lernen.
    Danach würde ich möglichst schnell ein eigenes CPU-Headerboard entwickeln, welches in die Steuerung eingesetzt werden kann.


    Gruß,
    Martin

  • Hallo Leute,
    nachdem ich die Diskussion hier schon länger verfolge, möchte ich mich mal aktiv einmischen. Wer sich jetzt wundert "was will der Typ mit seinen Dobsons mit einer Selbstbausteuerung anfangen?": Ich denke seit einiger Zeit darüber nach, in Zukunft auch mal in die Fotografie einzusteigen, zunächst mit kleiner Öffnung. Auf halbe Sachen habe ich aber keine Lust, dafür umso mehr auf Selbstbau.
    Meine eigenen Fähigkeiten beschränken sich auf vor 20 Jahren marktgängige Lösungen, programmiert wurde noch weitgehend in Assembler. Ich kann euch also bei der Entwicklung nicht wirklich eine Hilfe sein.


    Trotzdem hier mal meine Gedanken als potentieller Nachbauer:


    Ein Schalenmodell zu definieren, ist natürlich unabdingbar. Ebenso eine umzusetzende Minimal-Ausbaulösung als ersten Schritt festzulegen.


    Das Projekt sollte unbedingt auf verschiedene Hardware adaptierbar sein, auch wenn zu Beginn vermutlich eine parallaktische Monti mit Schrittmotoren, ohne Encoder, mit einfacher Handbox, Autoguider-Eingang und Motorfokussierer-Anschluß als Standard-Hardware definiert wird. Natürlich sollte auch eine Altaz-Monti mit Bildfeld-Derotator ansteuerbar sein, damit haben wir insgesamt 4 Motoren.


    Ein gut umgesetztes Schalenmodell würde es erlauben, später auch DC-Motoren mit Encodern oder sogar ein Direct Drive System anzusteuern.


    PC-Interface in USB ist vor allem hardwaremäßig suboptimal. Hauptprobleme: Zu kurze max. Leitungslängen, mechanisch viel zu anfällige Steckverbinder. Dann lieber erst mal RS232 und später evtl. gleich LAN (WLAN?). USB sehe ich nur als Alternative für kleine mobile Systeme, weil man ein Netbook ohne Adapter anstöpseln kann.


    Auch der Hardware-Aufbau darf ruhig modular sein.
    Ganz wichtig finde ich, beim Standard-Basissystem ohne exotische Hardware auszukommen.
    Falls es absolut nicht ohne SMD &lt; 1/20" Pinabstand und 4lagige Platinen geht, ok.
    Zweilagige 1/2 Europlatinen wären aber wünschenswert, zumindest für eine einfache Basishardware.


    Wenn genügend Leute mitarbeiten und die Schnittstellen-Definitionen zwischen den Schalen vernünftig gepflegt werden, spricht gar nix dagegen, dass von Beginn an verschiedene Entwickler mehrere Alternativen erarbeiten. Nachbauer könnten dann, vielleicht zunächst mit Hilfe der Entwickler, aus den vorhandenen Komponenten das für sie passende Menü zusammenstellen.
    Die oberen 2-3 Schalen nach Jens' Beschreibung könnten sicher auch problemlos auf einem PC laufen.


    Beteiligte Entwickler sollten sich möglichst auf eine Schale beschränken. Ein großer Vorteil dieser Strukturierung: Jeder Entwickler beackert eine überschaubare Teilmenge des Gesamtprojekts und kann sich innerhalb seines Aufgabengebiets ziemlich frei entfalten.


    Wie wollt Ihr denn nun weiter vorgehen?
    Dieser Thread ist jetzt schon eigentlich viel zu lang und unübersichtlich. Ihr braucht dringend eine andere Basis, um die Grundlagen zu erarbeiten Es wäre gut, wenn sich jemand fände, der die nächsten Schritte und die Kommunikation strukturiert. Minimal wäre wohl ein extra Forum und eine Plattform zum Onlinestellen von Dateien erforderlich.


    Ich bin gespannt, wie sich die Sache weiter entwickelt.


    Gruß,
    Martin

  • Also ich will mich mal wieder in die Geschichte rein hängen.
    Zum Thema USB gibt es fertige Lösungen, die auch Speichersticks usw unterstützen. mit dem FTDI kommt man dann nicht mehr weit. Ich habe bei mir im Prototyp das vinculum V-DIP2 Modul drin.
    Was Ethernet angeht, setze ich voll auf den Lantronix XPORT Pro. Der ist kaum größer als eine Netzwerkbuchse, hat aber einen kompletten prozessor mit Flash usw drin. Da läuft ein Webserver drauf. Zur kommunikation mit dem XMEGA den ich verwende gibt es eine Serielle schnittstelle. Lest euch einfach mal die Doku durch.
    Zum Testen hatte ich das ganze mal auf eine kleine Leiterplatte gebaut. Das schaut dann so aus. Zu einer fertigen Steuerung fehlt da nur die Motorstufe und das Netzteil

    Der Xport sitzt unter dem Prozessormodul und das Vinculum-Modul daneben. Für die eile muss man auch nicht SMD löten können.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!