Beiträge von Steno im Thema „Selbstbausteuerung mit open source fw?“

    Es freut mich, das mein Vorschlag hier auf Interesse trifft.


    >> Michael
    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">die Idee mit der Vernetzung der Geräte ist nicht schlecht...
    Ich sehe nur gewisse Probleme mit der Stromversorgung über den Bus
    bei 120W für die Steuerung, wie hier von einigen gewünscht.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Mein Vorstellung ist den Bus mit max. 30-50W zu belasten. Kleinere Geräte wie Filterräder oder Fokussierer benötigen kurzzeitig Ströme von max. 0,5-1A. Ich denke da sollten sich die EMV Probleme in Genzen halten und mit Entstörfiltern in der Versorgung zu beseitigen sein. Das man bei 120W Probleme mit Störungen bekommt ist mir auch bewußt, deswegen müßte man diesen Endpunkten eine eigene Stromversorgung spendieren. Diese sollten dann aber vom restlichen Bus, galvanisch getrennt sein.


    &gt;&gt; Steffen
    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Die Idee ist gut, finde ich, aber für das 'Standardzubehör' wie eben Filterräder & Co. (noch?!) zu progressiv (hätte beinahe radikal gesagt) - für die Komponenten, die wir selber beitragen (Handbox z.B.) aber echt eine Überlegung wert.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Am Anfang muß ja nicht gleich jedes Feature implementiert werden, man sollte sich nur für die Zukunft alle Möglichkeiten offen halten. Die Hardware wird ja auch immer komplexer. Der Fokussierer den ich z.B. zur Zeit plane hat so viele Rückmeldungen das es schon ein Unterschied ist, ob ich ein Kabel mit 10 oder 4 Adern zum Steuergerät führe. Es ist ja auch eine nicht zu unterschätzende EMV-Problematik. Wenn ich 2m lange Kabel zu den Schrittmotoren habe, auf welchen hohe Ströme schnell wechseln, sind Störungen im System schon vorprogrammiert. Bei einem Konzept mit Bus sind es vom Treiber-IC bis zum Motor 10cm Kabellänge incl. Leiterbahn, der Rest ist Gleichstrom und verursacht keine EMI.


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Der Einwand von Wolfgang mit ASCOM und INDI ist berechtigt; die Schnittstellen sind etabliert, es gibt haufenweise Treiber für unterschiedlichste Geräte.
    Im Prinzip - so verstehe ich zumindest das Konzept des Busses - müßte es möglich sein, z.B. einen ASCOM-Befehl (meinetwegen an das Filterrad) in eine Nachricht zu verpacken, die dann an geeigneter Stelle wieder ausgepackt wird.
    Aber das ist ein Haufen Aufwand für ein Kabel weniger - und die ganzen Kombinationen durchtesten ... au Backe!<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Genau das ist meine Vorstellung. Auf der PC Seite gibt es einen Treiber der die Befehle an die Steuerung sendet. Ob er nun ASCOM, INDI oder sonstwie heißt, ist erstmal egal. Die Umsetzung der Protokolle mußt Du ja sowieso für jede Steuerung machen, man benötigt allerdings eine gute Dokumentation.


    &gt;&gt; Wolfi
    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">... aber den CAN-bus kann man sicher in Pascal programmieren ... und dann mit ^foo oder foo^ pointer dereferenzieren und referenzieren ...<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    ...soll das eine Anspielung auf irgendwas sein? Ich verstehe gar nicht was ihr alle gegen Zeiger habt. Jede CPU kann damit bestens umgehen und die Verwendung selbiger ergibt meistens auch den effektiveren und schnelleren Code. Wenn man das Prinzip verstanden hat, ist es eigentlich ziemlich Genial :)

    Hallo Freunde der Nacht...


    mit großem Interresse lese ich hier von eurem Vorhaben einer Open Source Steuerung. Ich bin selbst gerade am planen bzw. schon über das Pflichtenheft hinaus und baue an einer Steuerung für meine in naher Zukunft zu realisierenden Projekte wie Fokussierer, Filterräder u.a. Da bei solchen Sachen jeder Hersteller (aus Konkurrenzgründen?) sein eigenes Süppchen kocht, dachte ich mir, man könnte ja mal einen offenen Standard schaffen um da ein wenig System rein zu bringen. Und je mehr dort mitmachen um so eher besteht natürlich die Chance das sich so etwas durchsetzt. Also werde ich hier mal meine Idee zu so einer Steuerung offen legen und hoffe natürlich auf regen Gedankenaustausch.


    Als wichtigstes Merkmal haben wir einen Datenbus, an den <b>alle</b> Geräte angeschlossen werden und darüber auch ihren Strom beziehen. Ich dachte da so an max. 1A pro Gerät, was für die meisten Sachen wie Fokussierer, Filterräder u.ä. reichen sollte. Solche Geräte kann man dann auch nacheinander zusammenstecken um den Kabelsalat zu reduzieren. Selbst kleine Teleskopsteuerungen welche mit ca. 2A auskommen, könnte man über den Bus versorgen. Für mich kommt da eigentlich nur ein Bus infrage, da er sich seit Jahrzenten unter härtesten Einsatzbedingungen bewährt hat und Standard ist, der CAN-BUS. Über ein noch näher zu beschreibendes Protokoll erfolgt der Datenaustausch zwischen allen Busteilnehmern. Dafür gibt es dann verschiedene Geräteklassen, wie z.B. Montierungsteuerung, Handpad, Fokussierer, Filterrad, Rotatoren, Kuppelsteuerung, Relais, Lüfter u.s.w. Am Befehlsumfang für die einzelnen Klassen könnte man sich an bekannten Protokollen wie LX200 und Robofocus orientieren. Die Verbindung zum PC erfolgt, wie schon von vielen vorgeschlagen, über ein Interface welches die Daten entgegen nimmt und in das interne Protokoll umwandelt. Von dort aus wird nur noch über das interne Protokoll kommuniziert. D.h. selbst ein simpler Taster benötigt einen Prozessor und auch die Fokussteuerung sitzt direkt am Fokussierer und benötigt eine eigene Intelligenz. Den großen Vorteil den ich darin sehe ist, wie auch schon von einigen anderen aufgegriffen, das ich klein anfangen und die Komponenten nach und nach erweitern kann. Außerdem ist man flexibel und kann alle Geräte nach belieben zusammenstecken. Es geht z.B. nur ein Kabel zum Fokussierer, von dort zum Filterrad und von dort zur Fangspiegelheizung und wenn ich möchte kann ich dort noch ein Handpad anschließen.



    Natürlich ist das nur ein Vorschlag meinerseits und ich bin an einem weiteren Gedankenaustausch sehr interessiert. Wie gesagt, je mehr mitmachen um so besser und ausgereifter wird das Protokoll, welches natürlich vollkommen offen wird, so das im Prinzip jeder seine eigene Steuerung implementieren kann. Um den Aufwand zu reduzieren könnte man z.B. auch eine abgespeckte Teleskopsteuerung realisieren, welche wie bisher den Fokusmotor bzw. Richtungstasten direkt ansteuert. Diese meldet sich am Bus einfach als 3 Geräte an. Auch wäre man von der verwendeten CPU-Hardware absolut unabhängig, solange das Protokoll eingehalten wird. Da das Meiste nicht sehr rechenaufwändig ist, sollten für einfache Sachen auch die 8bit AVR's reichen. Maximal für ein Handpad, welches auch Planetenpositionen und Goto berechnen soll, wäre ein stärkerer Prozessor nötig. Ich selbst benutze die 16bit dpPICs bzw. PIC24 von Microchip, welche mit 40MIPS echt schnell und auch preiswert sind und bereits eine CAN-Hardware besitzen. Allerdings sollte man sich auf 3,3V CAN-Controller einigen, damit es am Bus nicht zu unerwarteten Problemen wegen dem Buspegel zwischen 5V und 3,3V Controllern kommt. Die meisten Prozessorarchitekturen benutzen aber eh eine 3,3V Spannungsversorgung.