Selbstbausteuerung mit open source fw?

Ullrich · 25. Mai 2010

Ist ja schon ganz schön angewachsen, das Baby. Und wie ich das so sehe, werden 95% Hard- und Software des Controllers umfassen.

Unter diesen Umständen wäre es tatsächlich gut, ein eigenes Board dafür zu haben, um das Ganze strukturierter sammeln zu können. Schaun mer mal, was da so möglich ist.

Gruß

ullrich

Lorchi · 25. Mai 2010

Thomas!
Hatte das letzte Mal im Oktober vorbeigeschaut... mir ist grad der Mund offen stehen geblieben!
Mannomann...

Das einzige was mich verwirrt ist, welche Kabel wo dran kommen (muss irgendwas in die Handbox gestöpselt werden).

Gruß, Henning

ThomasWest · 25. Mai 2010

Hallo lorchi.
Da hast du mich falsch verstanden.
Das ist nicht die Platine die dann in der Steuerung drin ist. Mir ging es einfach nur mal darum die Einzelkomponenten (Prozessorboard, V-DIP2, Lantronix XPort usw.) auf ihr Zusammenspiel zu testen. Da aber leider das Prozessorboard kein Standardraster hat passt es nicht auf ein Breadboard. Deshalb habe ich halt dieses Platinchen geäzt und alles mal drauf gepackt. Man sieht ja auch schon, daß das Display einfach da hinten rum hängt und nur ein paar Taster dran sind.

Goedel · 25. Mai 2010

Hallo allseits,

als in der Regel passiv mitlesendes Astrotreff-Mitglied möchte ich an dieser Stelle Martin (MartinB) den Rücken stärken: auch ich liebäugle schon seit geraumer Zeit meinen Dobson zu motorisieren.

Zu diesem Thema habe ich neben Bastelkram auf der einen Seite und einer bestehenden recht teuren Lösung aus den USA (ServoCat) auf der anderen Seite die Webseite von Thomas gefunden. Diese Steuerung, insbesondere als Eigenentwicklung fand ich schon in einem relativ frühen Stadium faszinierend. Ich habe Thomas vor geraumer Zeit schon einmal per Mail kontaktiert, bedauerlicherweise habe ich damals nichts Genaueres von ihm über die Steuerung erfahren. An dieser Stelle jedoch von mir nochmals „Chapeau“! Eigentlich nur schade, dass seine Steuerung nicht auf den Markt finden wird…

Die Idee einer „Open Source“-Steuerung ist meiner Meinung nach fast überreif. Wenn man bedenkt, dass in der Modellflugszene mit autonomen Fluggeräten dieselbe Idee schon einen großen Erfolg verbuchen konnte, glaube ich fest an einen ebensolchen Effekt in der Astrogemeinde. Allein die Reaktionen, die dieser Thread innert kürzester Zeit hervorgerufen hat, sind ein überaus deutliches Signal, dass viele auf so etwas gewartet haben.

Ich für meinen Teil, werde das Projekt, wenn es dann konkret startet und - vorausgesetzt - die Steuerung eines Dobsons unterstützt, umsetzen (natürlich soweit es meine Lötkünste erlauben…)!

Äußerst interessiert die Entwicklung weiterverfolgend
wünsche ich best of luck für das Projekt!

Arno

selste · 25. Mai 2010

Hallo Jens,

<blockquote id="quote">Zitat:<hr height="1" noshade 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.
<hr height="1" noshade id="quote"></blockquote id="quote">

sorry, da bist Du völlig auf dem Holzweg ...
Fakt ist, daß kaum ein PC/Notebook noch mit serieller Schnittstelle ausgerüstet ist - und Adapterkarten zum Nachrüsten sind inzwischen auch eher Mangelware.
Und hier im Forum wirst genügend Beiträge von Leuten finden, die mit USB-/Seriell-Adaptern ihre liebe Mühe hatten und haben ... des Glump dut nämlich net zuverlässig!
Ich weiß nicht, ob Du Anwendungs- oder Systementwickler bist - aber ein sauberes Protokoll auf RS-232 zu implementieren ist NICHT trivial.

Zur Handbox - die 'Sparlösung' (nur Richtungstasten + Geschwindigkeit) würde ich inzwischen (schließe mich da der Meinung der 'Puristen' an) komplett an irgendwelchen Protokollen/Stacks vorbei direkt anschließen - im Prinzip Relais, die Strom auf die Stepper geben.
Gruß,

Steffen

selste · 25. Mai 2010

Hallo Martin,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
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.
<hr height="1" noshade id="quote"></blockquote id="quote">

wie viele Kilometer willst Du denn überbrücken?!
Hmm, mechanisch anfällig - ok, wenn der D-Sub mal festgeschraubt ist bekommt man ihn nicht mehr so einfach raus ... aber die Steckerkontakte sind alles andere als 'stabil'; VGA-Stecker waren bei uns mit an der Spitze der 'Verbrauchsmaterialien'.
Mir gefällt die Kombi USB+Ethernet sehr gut - es gibt fertige Bausteine, die an Hardware alles mitbringen, die Programmierung ist vielleicht kein Spaziergang aber Dank entsprechender Bibliotheken gut machbar - über Bluetooth-Adapter (am USB-Port) oder einen WLAN-Router (Ethernet) läßt sich an Distanzen so ziemlich alles überbrücken ... und wenn die Privatsternwarte auf der anderen Seite des Erdballs steht!
Gruß,

Steffen

JensStark · 25. Mai 2010

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: selste
 Hallo Jens,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
sorry, da bist Du völlig auf dem Holzweg ...
Fakt ist, daß kaum ein PC/Notebook noch mit serieller Schnittstelle ausgerüstet ist - und Adapterkarten zum Nachrüsten sind inzwischen auch eher Mangelware.
<hr height="1" noshade id="quote"></blockquote id="quote">
Wäre ja auch Unfug. Heutzutage setzen aber viele Systeme (auch der Arduino) Seriell->USB-Wandler ein. Auf dem PC läuft dann ein Treiber, welcher eine virtuelle serielle Schnittstelle anbietet. Das gibt es auch für Seriell auf Bluetooth und was nicht alles.

Mir wäre ja irgendwas mit sauberem IP-Stack auch lieber, aber wir wollen ja klein bleiben.
<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Und hier im Forum wirst genügend Beiträge von Leuten finden, die mit USB-/Seriell-Adaptern ihre liebe Mühe hatten und haben ... des Glump dut nämlich net zuverlässig!
[quote]
Nun, ich gehe schon davon aus, das Ganze mit "vertrauenswürdigen" Empfehlungen zu versehen. USB ist ja nun auch nicht unproblematisch - was nutzt einem automatische Geräteerkennung, wenn man keine Vendor-ID bekommt oder bezahlen will und was ist mit Leuten (die es durchaus gibt), die mit anderen Geräten als PCs oder Notebooks auf das Teil zugreifen wollen? (Zu Zeiten von Entwicklern, die teilweise nie etwas anderes als i386 gesehen haben, allerdings fast eine verzeihliche Annahme.)
[quote]
Ich weiß nicht, ob Du Anwendungs- oder Systementwickler bist - aber
ein sauberes Protokoll auf RS-232 zu implementieren ist NICHT trivial.
<hr height="1" noshade id="quote"></blockquote id="quote">
Oh, ich entwickle seit Jahren nur noch gelegentlich, eines meiner ersten Projekte war allerdings etwas zur Datenübernahme von WANG 2200 auf Norsk Data ND100. Zufällig seriell - mit den damaligen Systemen durchaus hundsgemein. Seitdem alles mögliche andere, von Kernelpfuschereien (macht Spaß) bis hin zu Anwendungssoftware (bringt länger Geld). Aber wie gesagt - als "Hello World" als installierbares Programm mit einer der Umgebungen von MS nicht mehr auf eine Floppy paßte, wurde mir das Ganze zu bunt. Das überlasse ich dann den jungen Leuten und schreibe höchstens mal was für den Eigenbedarf.

Ein sauberes, serielles Protokoll zu entwerfen und zu implementieren war zumindest früher grundlegendes Handwerkszeug. So viel kann da nicht wirklich schiefgehen - dafür ist es einfach zu dämlich. Und: Ich muß mich nicht großartig auf riesige Bibliotheken verlassen.

Interessant wird es, wenn Du auf Schicht 5 patzt, besonders, wenn die Kommunikation nicht nur aus Befehl/Antwort besteht, sondern man auch asynchron Statusmeldungen schicken will. Aber es ist beherrschbar.

Warum siehst Du ein sauberes Protokoll auf Seriell als schwieriger als beispielsweise auf sockets?
[quote]
Zur Handbox - die 'Sparlösung' (nur Richtungstasten + Geschwindigkeit) würde ich inzwischen (schließe mich da der Meinung der 'Puristen' an) komplett an irgendwelchen Protokollen/Stacks vorbei direkt anschließen - im Prinzip Relais, die Strom auf die Stepper geben.
<hr height="1" noshade id="quote"></blockquote id="quote">
Yep, und sei's als fallback...

Vielleicht gleich als Notbedienelemente/Testschalter gleich in die Stuerung integriert.

Gruß,
Jens

JensStark · 25. Mai 2010

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: selste

Mir gefällt die Kombi USB+Ethernet sehr gut - es gibt fertige Bausteine, die an Hardware alles mitbringen, die Programmierung ist vielleicht kein Spaziergang aber Dank entsprechender Bibliotheken gut machbar - über Bluetooth-Adapter (am USB-Port) oder einen WLAN-Router (Ethernet) läßt sich an Distanzen so ziemlich alles überbrücken ... und wenn die Privatsternwarte auf der anderen Seite des Erdballs steht!
<hr height="1" noshade id="quote"></blockquote id="quote">
Meine Meinung zu USB habe ich ja schon lautstark kundgetan

Die Frage ist hier ja - welche Komponenten sollen kommunizieren? Wenn die Komponente "Motorsteuerung" wirklich nur diese Aufgaben übernimmt (zwei Motoren in verschiedenen Geschwindigkeiten und Richtungen fahren und vielleicht noch Status/Positionsmeldungen abgeben), würde ich zumindest noch ein wenig mehr Logik auf der Teleskopseite des Netzwerkkabels haben wollen. Das ist ja die Komponente, die mit einer einfachen Handbox gefahren werden können soll oder diese sogar enthält.

Der Schritt darüber wäre dann der Betrieb durch eine Komponente, die die Handbox im einfachsten Falle emuliert, aber mehr kann.

Diese beiden Komponenten brauchen zwar ein definiertes Interface, aber das wird sicher keinen Webserver brauchen
Dafür aber eventuell einen Stecker, der ein wenig mehr aushält und eine ausreichende Anzahl an Verbindungen zur Verfügung stellt.

Sobald diese Box dann beispielsweise in der Lage ist, Koordinaten anzufahren und beispielsweise einen Systemstatus zurückzuliefern, würde allerdings in meinen Augen eine Netzwerkverbindung - oder eine andere Art "klassischer Byteströme" Sinn machen.

Gruß und CS,
Jens

ThomasWest · 26. Mai 2010

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Diese beiden Komponenten brauchen zwar ein definiertes Interface, aber das wird sicher keinen Webserver brauchen :)<hr height="1" noshade id="quote"></blockquote id="quote">
Der XPORT von Lantronix hat zwar auch einen Webserver, aber auch einen "Serial Tunnel". Der ist für den Anfang interessanter. Für den PC gibt es einen Treiber, der einen virtuellen COM Port erstellt. Damit kann dann zum Beispiel jedes LX200 kompatible Programm von irgendwo augf der Welt per Internet auf den hinter dem XPORT hängenden Prozessor zugreifen, so als wäre er per RS232-Kabel angeschlossen. Man kann die Verbindung auch verschlüsseln und somit die Sicherheit erhöhen.
Also bei mir klappt das Super. Man muss nur die entsprechenden Ports vom DSL-Router an den XPORT im lokalen Netzwerk weiterleiten.

Birki · 26. Mai 2010

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: ThomasWest
 [quote] Für den PC gibt es einen Treiber, der einen virtuellen COM Port erstellt.
<hr height="1" noshade id="quote"></blockquote id="quote">
hi!
darf ich mir als softwareheinzi was wünschen?

Bitte keine spezial-treiberlösungen, wie sie von elektronikern leider gerne und oft genutzt werden. das ist nicht notwendig und nicht zukunftssicher!

lg
wolfi

JensStark · 26. Mai 2010

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: Birki

Bitte keine spezial-treiberlösungen, wie sie von elektronikern leider gerne und oft genutzt werden. das ist nicht notwendig und nicht zukunftssicher!
<hr height="1" noshade id="quote"></blockquote id="quote">
Da bleibt dann außer Seriell und Netzwerk nicht wirklich viel. (USB HID?)

Gruß,
Jens

Birki · 26. Mai 2010

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: JensStark
 <blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: Birki
Bitte keine spezial-treiberlösungen, wie sie von elektronikern leider gerne und oft genutzt werden. das ist nicht notwendig und nicht zukunftssicher!
<hr height="1" noshade id="quote"></blockquote id="quote">
Da bleibt dann außer Seriell und Netzwerk nicht wirklich viel. (USB HID?)
<hr height="1" noshade id="quote"></blockquote id="quote">
hi jens!

es ist aber so, dass man sich nichts spart, wenn man sich auf eine speziallösung in der software verlässt. vom codemonkey standpunkt (mit linux - präferenz) sieht das so aus:
- ideal ist TCP/IP: das ist auf allen plattformen problemlos integrierbar und erlaubt es auch, die steuerung remote zu fahren.
- next best thing wäre USB, wobei auch die lösung USB rechnerseitig - USB/RS232 konverter - RS232 hardwareseitig ok ist. viele rechner haben überhaupt keine RS 232 mehr, die konverter funktionieren aber und man hat so nette sachen wie repeater etc.
- RS232 ... ist, wie steffen schopn geschrieben hat, schon mühsam: auf UNIX gehts mitm POSIX.1 standard, unter windows hab ichs in furchtbarer erinnerung ...

lg
wolfi

ren · 26. Mai 2010

Hallo zusammen

Nachdem ich Thread die letzten Tage mit Spannung mitverfolgt habe, kommen wir in den Bereich wo ich glaube vielleicht auch noch etwas beisteuern zu koennen [8D]

Von meiner Seite her waere die Implmentation eines IP Stacks sicherlich die sinnvollste Loesung ueberhaupt, da es einfach die hoechste Flexibilitaet bietet. Mittels TCP waere es auch sicherlich einfacher (als mit einem seriellen Protokoll) eine Error Detection 'einzubauen' was beim Remote Betrieb sicherlich nur von Vorteil waere. Des Weiteren laessen sich ueber IP schoene Wrapper basteln, so dass die Implementation von weiteren Funktionen u.U. vereinfacht wuerde...

Gruss:
Marc

JensStark · 26. Mai 2010

Wenn wir abstimmen würden - IP hat eindeutig Vorteile.

Plattformunabhängig, läuft über alles mögliche an Medien, kann alles mögliche simultan, ist netzwerkfähig :)...
Dazu noch gibt es offene IP-Stacks, teilweise sogar schon auf Ethernet-Chips fertig und man hat etablierte Standards. Sofort läßt sich das mit allem verbinden, was IP spricht - und das sind mehr Systeme als bei USB.

Die Frage ist nur - welche Funktionalität braucht die Steuerung auf der Montierungsseite des Netzwerkkabels?
Mit Sicherheit eine Handbox(-ansclußmöglichkeit), aber wo trennt man die Komponenten? Über das Internet direkt Motoren anzusprechen, halte ich aus diversen Gründen für Unfug. Einmal eingestellt sollte die Montierung schon nachgeführt werden, dabei die mechanisch nicht mögliche Positionen und die Sonne vermeiden(!), vielleicht sogar auf lokale Autoguiding-Signale reagieren können. Filterrrad und Kamerasteuerung können andere autarke Einheiten übernehmen.

Das heißt aber: Die Montierung muß wissen, wo sie steht (GPS-Anschluß vorsehen?), sie muß Datum und Uhrzeit kennen, muß in der Lage sein, ihre eigene Ausrichtung (Az/El.) irgendwie nachzuvollziehen und in der Lage sein, verschiedene Standardobjekte autark nachzuführen, auch wenn sie sie nicht beim Namen kennen muß.

Warum der Aufwand? Das schöne Teleskop mit der neuen Kamera neben der Berghütte verliert irgendwann den Kontakt zum Kontrollrechner, weil das Konto der GSM-Karte erschöpft ist. Dann soll sie weder versuchen, ungefiltert Bilder der Sonne aufzunehmen, noch mit grober Gewalt versuchen, 720° nachzufahren, weil sie nicht weiß, daß das nicht geht und etwas kaputt macht.

Alles, was das nicht kann, würde ich nicht für sinnvoll vernetzbar halten. Im Augenblick komme ich also auf drei Komponenten:

1) Motoransteuerung (jeweils in beide Richtungen, mit mehreren Geschwindigkeiten) mit angebauter Handbox.

2) Box, die mit eigener Intelligenz Katastrophen verhindert und ansonsten autark nachführt. Optional kann sie natürlich mehr, aber eigentlich sehe ich das GOTO in einem Notebook oder irgendwas PDA-artigem.

3) PDA/Notebook/wasauchimmer

Netzwerk ist ideal für Verbindung von 2 und 3. Verbindung zwischen 1 und 2 ist sicher eher "simpel elektrisch".

Gruß,
Jens

Birki · 26. Mai 2010

hi jens!

ich will da ein missverständnis vermeiden - ich will keine fernsteuerbare steuereung (unbedingt). ich halte es nur für das protokoll für die verbindung rechner/steuerung. das kann auch (und sollte hauptsächlich) über 0.5 m mit patchkabel gehen.
lg
wolfi

selste · 26. Mai 2010

Hallo Jens,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
Meine Meinung zu USB habe ich ja schon lautstark kundgetan

Die Frage ist hier ja - welche Komponenten sollen kommunizieren? Wenn die Komponente "Motorsteuerung" wirklich nur diese Aufgaben übernimmt (zwei Motoren in verschiedenen Geschwindigkeiten und Richtungen fahren und vielleicht noch Status/Positionsmeldungen abgeben), würde ich zumindest noch ein wenig mehr Logik auf der Teleskopseite des Netzwerkkabels haben wollen. Das ist ja die Komponente, die mit einer einfachen Handbox gefahren werden können soll oder diese sogar enthält.
[...]
<hr height="1" noshade id="quote"></blockquote id="quote">

ich orientiere mich immer noch an dem Bildsche (Seite ...

Der Controller für die Stepper besitzt danach einen - beliebig ungenormten - Anschluß für die Handbox (wie gesagt, Basis Relais), und einen weiteren Stecker für einen 'Bus' (z.B. CAN, I2C).
Für den anderweitigen Zugriff auf den Controller kommt ein Modul zum Einsatz (egal ob weitere Platine im Controller oder eigenes Gehäuse), über das dann USB+Ethernet zur Verfügung gestellt werden ... und z.B. auch noch Anschlüsse für motorisierte Fokussierer, Auto-Guider, Filterräder (beheizte Taukappen?!?), weitere 'Bus'-konforme Geräte.

Und weshalb sollte man mit Socket-Programmierung anfangen - wenn es die CPU des Moduls hergibt macht doch gleich was Anständiges ... Webservices - saubere API, universelles Protokoll mit SOAP/HTTP
Gruß,

Steffen

selste · 26. Mai 2010

Hallo,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
[Wenn wir abstimmen würden - IP hat eindeutig Vorteile.
[...]
<hr height="1" noshade id="quote"></blockquote id="quote">

genau, IP hat so viele Vorteile ... daß als erstes Mal UDP/TCP drübergestülpt wurden, damit man (im letzteren Fall) überhaupt sagen kann, ob ein Datenpaket beim Empfänger angekommen ist.

Und darüber kommen dann Protokolle, mit denen man wirklich etwas anfangen kann ... ftp, http, um zwei verbreitete zu nennen, die standardisierte Methoden/Funktionen bereitstellen (z.B. PUT, POST).
Gruß,

Steffen

ThomasWest · 26. Mai 2010

Bevor man sich über UDP/TCP unterhält sollte man vielleicht mal klären, welche Programme sowas überhaupt unterstützen. Ich denke Guide, Starrynight, TheSky usw. sollten das nicht können. Da müsste man dann auf jeden Fall wieder einen ASCOM Treiber schreiben.

ren · 26. Mai 2010

Na villeicht muesste man erst mal spezifizieren, was mit der Verbindung alles so angestellt werden koennte / sollte, danach kann man sich ueber Protokolle Gedanken machen.

TCP hat halt einfach den Vorteil, dass man aufgrund der Error Correction sicherstellen kann, dass das Packet auch in einem brauchbaren Zustand auf der anderen Seite angekommen ist... Je nachdem was man damit anstellen kann, ist es u.U. auch sinnvoll die bestehenden Protokolle einfach zu verwenden und ueber TCP zu tunneln...?

Des weiteren waere ein Protokoll welches ueber ein vernuenftige Zustandskontroll wuenschenswert, vor allem fuer den Remote Betrieb- hier bietet sich aus dem Sicherheitsaspekt eine offene Implementation von SSH an... letzendlich kann man auch ein serielles Protkoll schoen ueber eine TCP Session schicken... ein Device ist ein Device ist ein Device, wuerde der geneigte UNIXaner sagen [:)]

Birki · 26. Mai 2010

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: ThomasWest
 Bevor man sich über UDP/TCP unterhält sollte man vielleicht mal klären, welche Programme sowas überhaupt unterstützen. Ich denke Guide, Starrynight, TheSky usw. sollten das nicht können. Da müsste man dann auf jeden Fall wieder einen ASCOM Treiber schreiben.
<hr height="1" noshade id="quote"></blockquote id="quote">
hi!
... oder einen INDI treiber. nur - wennst LX200 direkt treiben willst über die existierenden ASCOM/INDI server, dann muss man eh RS 232 nehmen, oder?
lg
wolfi

selste · 26. Mai 2010

Hallo Wolfi,

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">
hi!
... oder einen INDI treiber. nur - wennst LX200 direkt treiben willst über die existierenden ASCOM/INDI server, dann muss man eh RS 232 nehmen, oder?
<hr height="1" noshade id="quote"></blockquote id="quote">

INDI wär - halbwegs - Plattform-unabhängig; ASCOM ist Windooze-only, können da aber die meisten Programme. Geht über den (virtuellen) seriellen Port.

Noch kurz eine Anmerkung zu IP & Co. - das ist einfach nur ein Container - eine Verpackung/Schachtel - für Bits und Bytes ... sinnvolle Informationen daraus zu (re-)konstruieren erfordert ein Protokoll, daß darüber liegt ... so gesehen kann kein (Astronomie-)Programm - z.B. - TCP/UDP
Gruß,

Steffen

JensStark · 26. Mai 2010

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: selste
Und weshalb sollte man mit Socket-Programmierung anfangen - wenn es die CPU des Moduls hergibt macht doch gleich was Anständiges ... Webservices - saubere API, universelles Protokoll mit SOAP/HTTP
<hr height="1" noshade id="quote"></blockquote id="quote">
Bist Du Webdesigner? Egal, welche Datenmengen man schiebt, Hauptsache, das Ganze ist in feinstem XML geschrieben.
Bitte dann aber auch mit Schnittstellen an SAP und DATEV

Webinterface mag Sinn machen - aber nicht jeder will sich unendlich viel Encapsulation geben. Fatware läßt grüßen...

Nichts gegen "lesbare" Protokolle! Um Himmels Willen - ich habe hier in der Firma Geräte, die Statusmeldungen in 4K großen Binärdateien reporten. Die Zahlen dann je nach Laune in BCD oder binär.
(Ach so, je nach Gerätegeneration auch noch in verschiedenen Varianten.) Ähnlich lesbar wie SMB-Pakete von Microsoft

LX200 scheint mir da schon etwas lesbarer. Aber es ist zumindest ein Standard - da erfindet man nicht notwendigerwese das Rad neu.

Und auch TELNET (oder SSH) ist ein erprobter Standard - und für LX200 schreibt sich schneller ein Parser als für einen neu zu definierenden SOAP-basierenden Standard. (DEN Kram sprechen die gleichen Geräte übrigens auch. Vor lauter Bibliotheken haben die Entwickler kaum noch Platz für Funktionen, die dem Benutzer wirklich etwas bringen...)

Ich gebe allerdings AUCH zu, daß ich ein Fable für Kommandozeilen habe.

Gruß,
Jens

Birki · 26. Mai 2010

hi steffen, alter recke!
>INDI wär - halbwegs - Plattform-unabhängig; ASCOM ist Windooze-only, >können da aber die meisten Programme. Geht über den (virtuellen) >seriellen Port.

>Noch kurz eine Anmerkung zu IP & Co. - das ist einfach nur ein >Container - eine Verpackung/Schachtel - für Bits und Bytes ... >sinnvolle Informationen daraus zu (re-)konstruieren erfordert ein >Protokoll, daß darüber liegt ... so gesehen kann kein >(Astronomie-)Programm - z.B. - TCP/UDP
>Gruß,

hier prallen WELTEN aufeinander. der controller will nur bits/bytes - der socket liefert das. wieso so kompliziert?
lg
wolfi

JensStark · 26. Mai 2010

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: selste
genau, IP hat so viele Vorteile ... daß als erstes Mal UDP/TCP drübergestülpt wurden, damit man (im letzteren Fall) überhaupt sagen kann, ob ein Datenpaket beim Empfänger angekommen ist.

Und darüber kommen dann Protokolle, mit denen man wirklich etwas anfangen kann ... ftp, http, um zwei verbreitete zu nennen, die standardisierte Methoden/Funktionen bereitstellen (z.B. PUT, POST).
<hr height="1" noshade id="quote"></blockquote id="quote">
Brauchst Du mir nicht wirklich zu erklären - habe mal eine Zeitlang in dem Bereich unterrichtet und bin nicht bei Datenkommunikation mit Kermit hängengeblieben.

Aber irgendwie bewegen wir uns hier auf einem Nebenschauplatz.

Das Bild auf Seite 8 habe ich eben noch einmal studiert.

Der Kasten links in der Mitte ist eine große, eierlegende Wollmilchsau. Fehlt noch die Ansteuerung für die Kuppel und Bildfelddrehung.

Im Augenblick erinnert mich das Ganze ein wenig an die berühmte Graphik mit der Schaukel, hier mal in einer mir zuvor aucn noch nicht bekannten Version:

http://code.reduxo.de/media/20…aukel-baum-seil-gross.png

Aalso.

Das Teil muß ja nicht viel können. Jeden Montierungstyp mit jeder Motorisierung. Angesprochen wird es seriell, über USB, Ethernet, Bluetooth, Firewire, seriell und wohl auch noch WLAN (dann aber nicht ohne 802.1X!) und SNA. Angesteuert werden muß alles bis einschließlich der Sucherheizung.
Wesentliche Funktionen (alles bis auf die Sucherheizung) müssen aber auch durch einfache Handbox bedienbar bleiben. Es darf nix kosten und muß mit wenig know-how zu fertigen sein.

Geht alles, wird dann aber wahrscheinlich 2065 in den ersten Test gehen.

Also. Wo liegt die 90%-Lösung? Was ist unbedingt notwendig, was ist nice-to-have?

Und - reichen wir mit einem einzigen Thread hier aus? Ich finde nicht, daß das Ganze noch wirklich übersichtlich ist.

Gruß,
Jens

JensStark · 26. Mai 2010

<blockquote id="quote">Zitat:<hr height="1" noshade id="quote">Original erstellt von: Birki
hier prallen WELTEN aufeinander. der controller will nur bits/bytes - der socket liefert das. wieso so kompliziert?
<hr height="1" noshade id="quote"></blockquote id="quote">

Yep. Trotzdem ist so ein wenig Sicherheit mit TCP keine schlechte Sache.
Kommt halt auch darauf an, was preiswerte Ethernet-Hardware so kann, und das ist inzwischen nicht ohne.
Eine Ethernetlösung für den Arduino arbeitet beispielsweise mit dem W5100 von Wiznet. Kostet wohl um die 5€, kann aber überraschend viel.

Schau mal:
http://www.i-vis.co.jp/pdf/wiz…tasheet_v1%5B1%5D.0.1.pdf

Damit kann man sicher schon mit dem Arduino Mega und dem Servo-Shield eine primitive, netzwerkfähige Motorsteuerung bauen.

Gruß,
Jens

Selbstbausteuerung mit open source fw?

Jetzt mitmachen!

Teilen

37 Benutzer haben hier geschrieben