Selbstbausteuerung mit open source fw?

<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>
<br />Hallo Thomas,

deine Wunschliste deckt sich in etwa mit meiner...
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Das sollte die Mindestanforderung sein.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Hinsichtlich Hardware sehe ich das genau so.
Die Hardwarebasis sollte spaeter jedenfalls keine Limits fuer die Firmware darstellen.

Hinsichtlich Konfiguration:
Was haellt ihr von einer Art Konfigdatei (xyz.ini) auf SD-Karte,
wo alle wesentlichen Parameter im Klartext lesbar zugaenglich sind?

Gruesse
Michael

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

Ich wünsch mir schon lange eine Steuerung mit WLan-Router und Browseroberfläche zur Bedienung und Konfigurierung.
Sprich kleines Kastln an die Montierung angeschlossen und der Rest dann einfach mit jedem Handy, PDA, Netbook, Notebook oder PC mit WiFi-Unterstützung, um die Steuerung zu bedienen.
Bei der Umsetzung der Oberfläche könnte ich helfen.
Bin fit in xhtml, css, php und wenn nötig kann ich mich auch in andere skriptsprachen für diesen Zweck recht zügig einfummeln.

Hi Michael,
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
Hinsichtlich Konfiguration:
Was haellt ihr von einer Art Konfigdatei (xyz.ini) auf SD-Karte,
wo alle wesentlichen Parameter im Klartext lesbar zugaenglich sind?
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
wenn die für den Betrieb der Steuerung notwendig wäre ... net viel!

Wenn man der Steuerung sagen kann, daß sie die gerade verwendeten Parameter doch bitte als Properties-/Konfig-Datei wo ablegen soll, warum nicht?
Gruß,

Steffen

Hallo Steffen,

ich habe derzeitwohl ein Verständnisproblem mit den verschiedenen Layern und der Kommunikation untereinander.

Ich versuche mal zu beschreiben, was ich mir so vorstelle, ob dass dann auch das ist, was Du oben so beschrieben hast.

Layer1: Steppersteuerung mit Direktanschlußmöglichkeit einer Handbox und einer SPI (oder I2C) Schnittstelle zur Bus-Kommunikation.
Dieser Layer bewegt einfach nur die Motoren und macht die kontinuierliche Nachführung.
[Einschub: Bei der Handbox wünsche ich mir übrigens 3 Geschwindigkeiten: schnelles Verfahren, Positionieren im Okulargesichtsfeld, Nachführkorrektur)].

Layer2: Hier sitzt die Intelligenz (Steuerzentrale), also die Steuerung von PEC und Autoguiding, LX-200 Umsetzung in Ansteuerbefehle für die Motoren. Dazu Uhrzeit und Koordinaten (ggf. mit GPS) zur Positionsberechnung fürs Goto. Ebenso das Sicherheitssystem für Sonne.

Layer3: Sämtliche weiteren anschließbaren Geräte (Buskomponenten). Dazu gehören die am Teleskop hängenden Zubehörteile(Fokussierer, Rotationssystem, intelligente Handbox,...)
In diesen Layer gehören für mich auch die Empfangsschnittstellen vom PC. Dadurch kann man diverse Schnittstellen anbieten ohne sich streiten zu müssen.

Layer4: Externe Software auf Netbook o.ä. bzw. intelligente Handbox zur Konfiguration bzw. komfortablen Positionierund bzw. Batchabarbeitung. Beinhaltet auch Planetariumsprogramme o.ä.

Layer4 und Layer3 kommunizieren mit Layer2 über LX-200 Protokoll.
Layer2 steuert Layer1 mit eigenem Protokoll.

Genauso würde ich es auch entwickeln: zuerst Layer1.
Der kann dann schon mittels Michaels geposteten Adaptern SPI-Ethernet direkt über ein Netbook angesprochen werden. Dies macht eine komfortable Realisierung von Layer2 am PC möglich, die dann nur noch auf den uC heruntergebrochen werden muß. Dies kann auch schon parallel zur Entwicklung der HW von Layer2 erfolgen.

Layer3 folgt wenn Layer2 fertig ist.

Hab ich das so richtig begiffen?

Gruß
Volker

Hallo nochmal,

also das mit der SD-Karte sehe ich so wie Steffen.
Kataloge darauf oder Backup der Konfigurationsparameter gerne,
aber der Betrieb sollte ohne möglich sein.
Ich trau den Teilen bei Kälte nicht.

Grüße
Volker

Hallo Volker,

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
[...]
Layer1: Steppersteuerung mit Direktanschlußmöglichkeit einer Handbox und einer SPI (oder I2C) Schnittstelle zur Bus-Kommunikation.
Dieser Layer bewegt einfach nur die Motoren und macht die kontinuierliche Nachführung.
[Einschub: Bei der Handbox wünsche ich mir übrigens 3 Geschwindigkeiten: schnelles Verfahren, Positionieren im Okulargesichtsfeld, Nachführkorrektur)].

Layer2: Hier sitzt die Intelligenz (Steuerzentrale), also die Steuerung von PEC und Autoguiding, LX-200 Umsetzung in Ansteuerbefehle für die Motoren. Dazu Uhrzeit und Koordinaten (ggf. mit GPS) zur Positionsberechnung fürs Goto. Ebenso das Sicherheitssystem für Sonne.
[...]
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

eigentlich sehe ich das genauso, ist eine gute Zusammenfassung, vielen Dank!
Ich bin mir nicht sicher, wie die Alt-Az Fraktion da geschickt untergebracht werden kann ... Layer 1 reicht net, muß mindestens Layer 2 sein, oder - und wie schaut es dann mit einer Handbox aus?!?

Zur Kommunikation zwischen 4,3 und 2 - wenn wir so Sachen wie Aufspielen neuer Firmware über z.B. http anbieten wollen, dann reicht LX-200 net; Layer 3 muß sicherlich dieses Protokoll samt Schnittstelle nach außen (Layer 4) anbieten, aber intern ... vielleicht einfach auch SPI?!
Gruß,

Steffen

Hallo an Alle,

Mal eine Frage zur Goto. wie bringt man denn die verschiedenen Montierungstypen unter einen Hut? Also Dobson, Gabel, Deutsche Montierungen usw. haben doch alle an bestimmten Himmelspositionen Probleme. Dobsons im Zenit, Deutsche Montierungen beim Umlegen im Sueden. Wie 'versteht' das eine Steuerung? Oder sind dann in der Steuerung alle moeglichen Montierungsgeometrien einprogrammiert und der Benutzer muss dann die auf seine 'Hardware' zutreffende beim Booten auswaehlen? Das ist dann doch eine Menge 'Ballast'. Wenn ich 'nur' meine Deutsche Montierung betreiben will, was mache ich mit den ganzen Firmwareupdates fuer die Dobsonsteuerung? Selbst innerhalb einer 'Klasse' von Montierungen hat man noch konstruktionsbedingte Unterschiede. Z.B. wie 'weit' eine Deutsche Montierung erlaubt ein Objekt nach Meridiandurchgang zu verfolgen. Ich habe mal gehoert, dass selbst eine &gt;10K EUR Monti wie die Paramount da einfach stehen bleibt. (Kann das eigentlich jemand bestaetigen?)

Clear Skies,
Gert

Hallo Steffen,

ja, mit dem LX-200 hab ich auch so meine Probleme.
Ich denke, dass auch diverse andere Buskomponenten Ergänzungen benötigen würden.

Deshalb würde ich vorschlagen, dass LX-200 natürlich zur Kommunikation von Layer4 nach Layer3 angeboten wird. Zur internen Kommunikation (Layer3 nach Layer2 und Layer2 nach Layer1) würde ich ein komplett eigenes Protokoll definieren. D.h. Layer3 wandelt externe Protokolle ins interne Protokoll.
Und wie gesagt, dank der SPI Adapter lasen sich so schnell direkte Test- und Programmiertools auf dem PC definieren.

Um ganz ehrlich zu sein bzgl. der Handbox, ich halte einen direkten Anschluß an die Stepperstufe nicht für erforderlich. Wenn der SPI Bus nicht mehr funktioniert, dann ist eh alles zu spät. Dann funktioniert kein Autoguiding und kein PEC mehr. Als bessere Lösung halte ich eine einfache Handbox über SPI, die entweder direkt auch Layer1 ansteuert oder für Alt-Az mit Layer2 kommuniziert.

(==&gt;)Gert: Also ich sehe zwei brauchbare Möglichkeiten:
Jeder Montierungstyp bekommt eine eigene Firmware oder alles in einem Firmwarestand. Ich denke, dass sollten wir vielleicht noch etwas näher rankommen lassen, dann wissen wir auch besser, wie voll der uC wird.

Grüße
Volker

Hallo Leute,

ich denke hier ist es an der Zeit, mal die bereits gesammelten Fakten und Ideen strukturiert aus den Diskussionen zu lösen und ein wenig konkreter zu werden. Ich habe dazu mal ein Wiki eingerichtet, mit dessen Hilfe wir vielleicht eher den Überblick behalten als wenn wir hier gelegentlich 18+ Seiten Thread immer und immer wieder durchsuchen nach 'da hat doch der ... mal ne gute Idee gehabt...'.

Unter dieser URL findet Ihr die Hauptseite des Wikis: http://www.smolinski.name/OSSt…ndex.php?title=Hauptseite
Habt keine Hemmungen, das Ding ist ein Wiki - das heißt jeder darf und SOLL drin rumeditieren, so dass Inhalt und Struktur(!) immer besser werden.

DS, Holger

PS: meine GP war schon fast ein Jahr nicht mehr unter klarem Himmel...

Hallo,

ich hab mir nochmal Gedanken gemacht wg. Handbox.

Also ich würde vorschlagen, dass die Handbox im Normalbetrieb mit Layer2 kommuniziert.
Dazu ein kleiner Umschalter für den "Notfallbetrieb" in dem die Handsteuerbox direkt die Motorkommandos für Layer1 sendet(also das was normalerweise Layer2 liefert).
Zusätzlich ein Schalter, mit dem man Layer2 ausschalten kann oder vielleicht noch besser eine Möglichkeit Layer2 vom Bus abzuklemmen. Alt-Az betriebene Teleskope muß man dann halt im Notbetrieb in zwei Achsen nachführen.

Anschluß der Box über SPI.

Grüße
Volker

Soooo...

da mein Vorschlag, ein extra Board einzurichten, keine Anhänger gefunden hat und ich zudem zeitmässig nicht in der Lage bin, die Anforderungen zu erfüllen, bin ich erstmal raus aus dem Geschäft.

Im übrigen sehe ich mit etwas Sorge, daß sich 95% der Diskussion um Software und Schnittstellen dreht, aber fast keiner konkret sagt, wie die Ansteuerung der Motortreiber sein soll. Ich hoffe aber, daß sich das noch bessert [;)]

Gruß

ullrich

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Im übrigen sehe ich mit etwas Sorge, daß sich 95% der Diskussion um Software und Schnittstellen dreht, aber fast keiner konkret sagt, wie die Ansteuerung der Motortreiber sein soll. <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Sehe ich genauso. Deshalb hab ich mich erst mal raus gehalten. Man sollte erst mal eine Hardware haben und sehen, daß die läuft. Ich bin da auch shcon mal drauf rein gefallen, und hatte dann einen prototypen, der zwar lief, aber leider nur mehr schlecht als recht. Das ist dann frustrierend, wenn man eine Treiberstufe nochmal umkonstruieren muss, nur weil man eine Kleinigkeit nicht beachtet hat.
Oft höre ich so Sätze wie 'na das mache ich dann in der Firmware'. Ich denke es ist ein großer Irrtum, den ich leider immer wieder bei Programmierern antreffe, zu glauben, man könne alles was man in der Hardware versäumt haben dann softwaremäßig realisieren. Deshalb denke ich auch, daß als erster Schritt die Hardware fertig sein sollte. Dann kann man da nen Prozesssor drauf setzen und sich an die Kommunikation machen.

[quote]Im übrigen sehe ich mit etwas Sorge, daß sich 95% der Diskussion um Software und Schnittstellen dreht, aber fast keiner konkret sagt, wie die Ansteuerung der Motortreiber sein soll. Ich hoffe aber, daß sich das noch bessert [;)]
[/quote

Hallo Ullrich,

zur Ansteuerung von Schrittmotoren im Mikroschrittbetrieb gibt es spezielle Treiberbausteine. Hier wurden Bausteine von Trinamic oder Allegro vorgeschlagen. Diese können von einem Mikrocontroller
angesteuert werden.

Bei den von mir verwendeten Allegro 3973 Mikroschritt-Treibern muss man die Motorströme per seriellem Datenwort (18 bit lang) vorgeben, und das tausende Male pro Sekunde, damit sich der Motor dreht.

Die Trinamic-Treiber haben eine SPI-Schnittstelle, wo man auch Rampen, Solldrehzahlen und Zielpositioen (?) vorgeben kann. Die Drehbewegung machen sie dann alleine.
Dafür sind sie nicht so fein parametrierbar wie die Allegro-Treiber, wo man sämtliche Schaltzeiten für die Transistoren einzeln einstellen kann, ebenfalls in einem 18bit-Datenwort, in bis zu 32 Stufen.

Eine wichtige Frage ist, ob man die Motortreiber jeweils von eigenen 'Slave'-Prozessoren ansteuert oder ein Prozessor alles alleine machen soll.

In meiner Dobson-Steuerung werden zwei Motortreiber von der Haupt-CPU (Atmel mega128) angesteuert. Die Steuerung ist nicht erweiterbar.
Bei einem modularen erweiterbaren Design mit Hauptplatine und weiteren (2, 3, 4, ...) Treiberplatinen wäre dieser Prozessor damit überfordert. Ein schnellerer Prozessor könnte das evtl. schaffen.

Bei je einem Slave-Prozessor (mega8 oder mega16) pro Treiberplatine
würde etwas Intelligenz an diese ausgelagert, der Hauptprozessor würde nur Drehzahlsollwerte übertragen und Positionen abfragen.
Die Ansteuerung der Motortreiber selbst übernehmen die Slaves,
dann auch mit höherer Frequenz, da sie nichts anderer mehr zu tun haben.

Ein Ansatz mit Slave-Prozessoren würde auch die Verwendung anderer
Antriebsarten wie Gleichstrommotoren mit Encoder oder BLDC-Motoren erlauben. Man könnte dann je Motortyp eine intelligente Treiberplatine entwickeln, die die Kommandos der Haupt-CPU ausführt.

Für die Kommunikation zwischen Hauptprozessor und Slaves bieten sich als Schnittstellen I2C, SPI oder CAN an.

I2C kann max. 400kHz und beliebig viele Busteilnehmer verwalten, benötigt zwei Leitungen.

SPI kann mehrere MHz, die Busteilnehmer müssen über eigene Leitungen angewählt werden, da muss man sich vorher auf eine Anzahl festlegen. SPI benötigt vier Leitungen plus Anwahlleitungen. Interessant ist, dass man die kleineren Atmel-Prozessoren auch über die SPI-Schnittstelle programmieren kann, wodurch Software-Updates über die Haupt-CPU möglich werden.

Mit CAN habe ich noch keine Erfahrung, aber es liegt in der Geschwindigkeit zwischen I2C und SPI, kann auch beliebig viele Busteilnehmer verwalten.

Gruß,
Martin Cibulski

Servus!
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"> Deshalb denke ich auch, daß als erster Schritt die Hardware fertig sein sollte.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">Das meinte ich auch schon vor etwa16 Seiten...
Gruss
Gerhard

Also ich verwende bei meinem neuen Prototypen als Hauptprozessor einen ATXMega128 als Hauptptozessor. Dieser steuert per SPI jeweis einen TMC457 für RA und DE (oder ALT und AZ) an. Über einen Expansionsstecker auf der Platine lassen sich 3 weitere Stufen ansteuern. Der TMC457 macht genau das was martin.c mit den Slaveprozessoren (mega8 oder Mega16) machen will. Den Vorteil des TMC457 sehe ich allerdings darin, daß er erstend das GAnze Hardwaremäßig macht und zudem genau auf die Trinamic Treiberstufen abgestimmt ist. Im Falle eines Slave-Prozessors müsste man für den dann auch wieder eine Firmware schreiben.
Von einer Direkten ansteuerung einer Schrittmotorstufe vom Hauptprozessor aus halte ich überhaupt nichts. Bei hohen Geschwindigkeiten kommt der dann irgendwann an seine Grenzen. Wenn er dann auch noch encoder auswerten muss wirds noch mal etwas enger.

Hallo

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
Das meinte ich auch schon vor etwa16 Seiten...
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Dito!

Aber vielleicht präzisiere ich mein oberes Post noch um Mißverständnisse zu vermeiden.
Mit Layer verstehe ich nicht nur die Software, sondern inkl.
der zugehörigen Hardware.

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
Von einer Direkten ansteuerung einer Schrittmotorstufe vom Hauptprozessor aus halte ich überhaupt nichts.
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Also da schließe ich mich an. Ich denke die Motoransteuerung (Layer1) ist ein eigener Hardwareteil mit eigenem Prozessor. Die Intelligenz auf Layer2 läuft auf einem separaten Prozessor.

Somit kann man modular an beiden Modulen arbeiten bzw. man kann ggf. eines der Module umbauen, falls notwendig ohne dass das andere Modul davon betroffen wäre.
Man kann ja beides immer noch in das gleiche Kasterl packen. [:)]

Wie schon erwähnt würde mir schon allein Layer1 reichen, den könnte man dann über ein Netbook ansteuern.

Grüße
Volker

Hiho zusammen,
Irgendwie fürchte ich, wenn wir das ganze zu sehr modularisieren, kriegen wir nachher einen ganzen Haufen unabhängiger Prozessoren zusammen uns müsssen die alle miteinander reden lassen.
Lasst mich mal versuchen für den Layer 1 - die Steppersteuerung - ein Anforderungsprofil zu erstellen:
Ziel ist ein Steppersteuerungsmodul, das auch unabhängig von anderen Steuerungskomponenten als einfach Nachführung eingesetzt werden könnte.
- Bis zu 3 (4?) bipolare Schritt-Motoren sollen angesteuert werden
-- davon 1 (ein 2. für den Rotator?) dauerhaft mit jeweils eigener Schrittfrequenz, die konstant beibehalten wird, wenn keine weiteren Steuerungsimpulse auftreten.
-- Frei programmierbare Schrittfrequenzen der Motoren (Parametersatz 1)
-- Frei programmierbare Drehrichtung für die konstante (Parametersatz 2)
-- Frei programmierbare Phasensequenz zur Anpassung an verschiedene Motoren (Parametersatz 3)
- Möglichkeit die Schrittfrequenz der 4 Motoren durch Signal von außen zu ändern.
-- durch einfaches Schaltsignal um einen von 2 vorgegebenen Werten (langsam/schnell - Parametersatz 4) zu erhöhen/erniedrigen
-- auf von außen vorgegebene Wert zu setzen.
- lokaler, bei Spannungverlust nicht flüchtiger Speicher für Parametersätze
- Mikroschritt fähig
- Unabhängige Stromversorgung (&lt;=24 DC) für Motorstrom
- maximal schaltbarer Motorstrom variabel durch Austausch der Motortreiberbausteine
- kurzschlussfest auf Motorseite
Das Ganze habe ich nochmal dokumentiert auf:
http://www.smolinski.name/OSSt….php?title=Motorsteuerung
Bitte ergänzt die dortige Beschreibung, wenn Euch noch was fehlt oder passt die einzelnen Punkte an, wenn sie nicht konkret/genau genug sind...
DS, Holger

Hallo Thomas,

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
Also ich verwende bei meinem neuen Prototypen als Hauptprozessor einen ATXMega128 als Hauptptozessor. Dieser steuert per SPI jeweis einen TMC457 für RA und DE (oder ALT und AZ) an. Über einen Expansionsstecker auf der Platine lassen sich 3 weitere Stufen ansteuern.
[...]
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

ich war bisher davon ausgegangen, daß man um einen - wenn auch sehr einfachen - Prozessor für die Ansteuerung der Stepper nicht herumkommt; wenn es aber so hochintegrierte Bausteine gibt ... erleichtert die Arbeit ungemein!

(==&gt;)Holger:
Meiner Meinung nach macht ein Wiki im 'luftleeren' Raum net viel Sinn - ich würd mir - als Programmierer - wünschen, daß eine Lösung zum Einsatz kommt, die Bug Tracker/Issue Management, Milestones und Wiki (vielleicht auch noch Diskussionsforen) vereinigt (beispielsweise Redmine, Trac oder Jira + Extensions).
Momentan würde ich - wie Michael es ja schon angefangen hat, in einem separaten Thread mit der Zusammenfassung der Anforderungen beginnen.
Gruß,

Steffen

Hi Steffen,
ja, Du hast recht - ein Wiki hatte ich halt zur Hand und hielt es für besser geeignet als einen 18-seitigen Thread, um Anforderungen zu dokumentieren. Ich habe auch keinerlei Erfahrungen mit dem Aufsetzen von Open-Source-HW/SW-Projekten. Wenn irgendjemand hier sich in der Lage sieht, das 'richtig' zu machen - ich bin dabei. Wenn nicht, müssne wir halt mit dem vorlieb nehmen, was wir mit unseren Fähigkeiten machen können - ich würde mich freuen, wenn wenigstens jeder hier mal sagen würde welche Aufgabe er sich in dem Projekt zutraut - dafür hat ja Micha den 'wer macht mit'-Thread schon geöffnet - bislang leider mit nur geringer Resonanz.
Sieht für mich eher so aus, als ob jeder dafür ist - keiner was machen will und am Ende alle motzen, dass es keiner macht...
DS, Holger

Hallo Holger,
richtig oder falsch gibt es da eher nicht ... ich fände es halt schade, wenn da jetzt viel Aufwand investiert wird, und die Arbeit - womöglich? - anschließend mehr oder weniger umsonst war.
Michael hat ja den zweiten Thread schon ins Leben gerufen ... vielleicht sollte man ihn mal fragen, was er bevorzugt?
Gruß,

Steffen

Hallo Gert,
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
Mal eine Frage zur Goto. wie bringt man denn die verschiedenen Montierungstypen unter einen Hut? Also Dobson, Gabel, Deutsche Montierungen usw. haben doch alle an bestimmten Himmelspositionen Probleme.
[...]
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
hab noh keine Steuerung programmiert - aber ich würde mal ganz naiv annehmen, daß der Rechner ein Modell pro unterstütztem Montierungstyp hat; wäre eher ungeschickt, wenn jedes Mal eine neue Firmware aufgespielt werden müßte, wenn die Steuerung an eine andere Montierung angestöpselt würde?!

Steffen

Hallo,

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">hab noh keine Steuerung programmiert<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
ich auch nicht, sondern nur eine aus logischen IC´s und Schrittmotorentreibern zusammengelötet.
<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">- aber ich würde mal ganz naiv annehmen, daß der Rechner ein Modell pro unterstütztem Montierungstyp hat; wäre eher ungeschickt, wenn jedes Mal eine neue Firmware aufgespielt werden müßte, wenn die Steuerung an eine andere Montierung angestöpselt würde?! ;-)<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
Hoffentlich ist die Steuerung auch individuell perametrierbar (durchaus unterschiedlich in Rec und Dec) sonst sind Selbsbaumontierungen u.u. nicht damit steuerbar!

Gruß

Hallo,

<blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: martin.c</i>
...
zur Ansteuerung von Schrittmotoren im Mikroschrittbetrieb gibt es spezielle Treiberbausteine. Hier wurden Bausteine von Trinamic oder Allegro vorgeschlagen. Diese können von einem Mikrocontroller
angesteuert werden.

Bei den von mir verwendeten Allegro 3973 Mikroschritt-Treibern muss man die Motorströme per seriellem Datenwort (18 bit lang) vorgeben, und das tausende Male pro Sekunde, damit sich der Motor dreht.

Die Trinamic-Treiber haben eine SPI-Schnittstelle, wo man auch Rampen, Solldrehzahlen und Zielpositioen (?) vorgeben kann. Die Drehbewegung machen sie dann alleine.
...
<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">

Ist es auch moeglich mit der selben Steuerung Servo-Motoren anzusteuern? Roland Christen, der die Montierungen bei Astrophysik baut, hat mal geschrieben (den Link habe ich leider nicht mehr zur Hand), dass Servos bessere Dynamikeigenschaften haben. In den High-End Montierungen von Astroophysik sind auch nur Servo-Antriebe verbaut. In der bisherigen Diskussion wird ja sehr aufwendig geplant. Da sollte auch Unterstuetzung fuer Servomotoren als Antrieb vorgesehen sein.

Clear Skies,
Gert

Mit einem modularen Design könnte man prinzipiell auch Servomotoren ansteuern. Die werden sich meiner Meinung eh irgendwann durchsetzen. Allerdings wird es dann teurer, insbesondere die Encoder kosten wenn man genau sein will eine Unmenge.
Dazu müsste dann der Motorcontroller und die Treiberstufe ein extra Modul sein. Ich ziehe das gerade bei mir durch. Man muss dann nur sicherstellen, daß das Protokoll vom Hauptcontroller zum Schrittmotorcontroller so ausgelegt ist, daß wirklich nur eine Positionsangabe bzw. Geschwindigeit und Richtung übertragen wird.

Was den Betrieb von Alt/AZ bzw. deutschen Montierungen angeht, so sehe ich da eigentlich kein Problem. Auch muss man nicht irgendwelche Modelle integrieren. Die Steuerung muss eh über Koordinatenrechnungen verfügen, umd die Koordinaten aus den Katalogen in wahre Himmelskoordinaten umzurechnen. Zudem mus auch immer ein Misalignment der Polachse mit korrigiert werden wenn das Teleskop nicht ordnungsgemäß gescheinert ist. Da sind zwangsweise Umrechnungen vom Äquatorialsystem ins Alt/AZ System und zurück nötig. Es fallen also beide Koordinatentypen an. Ich nutze sie zum Beispiel zur Steuerung der Kuppel obwohl wir eine deutsche Montierung haben. Wenn man einen Dobsen steuern will, dann schickt man einfach die wahren ALT/AZ Koorinaten des Objektes an den Motorcontroller und bei parallaktischer Montierung halt die wahren Äquatorialkoordinaten. Man muss halt nur in den Grenzbereichen (Meridan oder Zenit) aufpassen.

Servus,
und entschuldigt mal, aber <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Mit einem modularen Design könnte man prinzipiell auch Servomotoren ansteuern.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote"> die Idee mit den Servomotoren kommt mir nicht gut vor. Wenn die so exakt wären, würde die Firma mit den Direct-Drive Montierungen wohl keine Stepper mehr verwenden? http://www.astrosysteme.at/de/montierung.html Die Montierungen kosten ein Schweinegeld mit den Steppern.
Gruss
Gerhard
Guckt mal den Vergleich hier: http://www.bzt-cnc.de/wp/pdf/V…ch_Schritt-Servomotor.pdf
Stepper sind auch im Roboterforum ( http://www.roboternetz.de/ ) noch immer recht weit vorne. Sowohl hier als auch eben im Microcontrollernetz ( http://www.mikrocontroller.net/forum/ ) mikrocontroller-elektronik ) gibt es immer tolle Schaltungstipps! Ich glaube, dass Einiges davon für 'ne autonome Steuerung brauchbar wäre.