Selbstbausteuerung mit open source fw?

  • Hallo,


    mit Interesse verfolge ich dieses Thema, da ich schon seit einiger Zeit überlege, wie die vor einiger Zeit selbstgestrickte Steuerung auf Basis der L 297/298 Treiber verbessert/ersetzt werden kann. Dabei ist die Handbox mit der Steuerung von der Treiberplatine, die in der Montierung untergebracht ist, getrennt. Zwar hat sie eine ST 4 Schnittstelle aber kann nur 1/2 Schritt und die Montierung tuckert wie ein Binnenschiff...
    Daher mal meine Gedanken dazu:
    <ul><li> 1/16 Schritt Minimun </li><li> 30 V finde ich vollkommen ausreichend </li><li> Goto ist schön aber nicht unbedingt nötig </li><li> Autoguiderschnittstelle: hier bin ich für LX 200 und ST 4. Mit der einfachen ST 4 Schnittstelle habe ich gute (zuverlässige) Erfahrungen gemacht. Sie beinhaltet kein umständliches Protokoll mit Rückmeldung, da hier nur die Richtungstasten bei Aktivierung nach Minus gezogen werden. Zudem haben einige Guidercams bereits eine ST 4 Schnittstelle integriert</li><li> 2 Platinenlösung in Steuerungs- und Treiberplatine umgeht eventuelle Probleme </li><li>Alle Kabel/Verbindungen sollten auch für den Ausseneinsatz geeignet sein und könnten auch von den Nutzern selbst hergestellt werden </li><li>Bei der Wahl der Gehäuse sollten Standartgrößen berücksichtigt werden, Alugehäuse als Handbox ist in der Kälte eh nix </li></ul>
    Das wärs auch schon. Ach ja, SMD Bauteile zu löten, das ist m.E. schon machbar und heutzutage unumgänglich. Dabei habe ich vielleicht ein wenig handwerkliches Geschick aber elektronisch nur sehr eingeschränkte Kenntnisse.


    Gruß

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


    ..........


    Aber zurück zum Pflichtenheft:


    1. Mikroschritt: 1/64 (können die Tri-Chips) so könnte man kl. Getriebe von 1/4 an der Monti verwenden<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Das sollte Mindestvoraussetzung sein - kannste schon mal aufschreiben ;)



    <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 />2. max. Geschwindigkeit: je mehr, desto besser; wenn die Stromversorgung mitspielt sollten 8 U/sec der Motoren drin sein<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Das sollte erst einmal leicht in den Hintergrund treten, denn das kommt auf alle Fälle auch auf die benutzten Motoren und die Untersetzung an. Ich denke das 240x Goto (nur um mal eine Hausnummer zu nennen) ausreichen sollten. Lieber Präzision in der Nachführung....


    <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 />3. interner Wandler: Vorschlag: 12V -&gt; 30V mit 120W - 150W ev. auch modular ausgelegt, da nicht alle so viel brauchen
    .
    .
    .<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Da bin ich schon geteilter Meinung. Es gibt sehr gut geeignete Netzteile die bis 24V eine ausreichende Stromstärke liefern -&gt; siehe hier So Eines habe ich derzeit selbst an meiner Steuerung und es macht einen sehr guten Eindruck (Metallgehäuse), obwohl es aus Fernost stammt.


    Vielleicht sollte man wirklich einen neuen Thread anfangen wo keiner antwortet sondern wo die Eckdaten (was soll die Steuerung mitbringen / können und das hardwareseitig weitergehend das Ganze zusammenfasst)


    Sehr interessant, aber nicht einfach das Ganze........bin gespannt

  • Hallo Thomas,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Es gibt sehr gut geeignete Netzteile die bis 24V eine ausreichende Stromstärke liefern<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Für den mobilen Einsatz wäre ein interner Wandler besser, denke ich.
    Sonst könnte man natürlich auch was externes nehmen,
    dann muss eine Crowbar-Schaltung innen rein, welche bei Überspannung
    die Treiber schützt und definiert die Sicherung durchbrennen lässt.
    Ist aber keine große Sache, ein paar Bauteile.
    So was sollte aber auch bei der internen Variante rein...


    Grüße
    Michael

  • Hallo zusammen,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    Kommerzielles Ausnutzen des Projektes sollte so gut es geht verhindert werden.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Warum? Es ist doch Open Source. Soll jeder, der damit glücklich werden will, es auch werden.


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    Die Handbox kann ja genauso die LX-200 Movement Befehle absetzen
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Find ich viel zu umständlich. Handbox = 4 Knöpfe. Am einfachsten vier Schalter und gut...Eignet sich am besten zum Nachbau auch für die einfachste Ansteuerung.


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    Das Problem ist, dass hier im Gegensatz zu reinen Digitalschaltungen richtig heftige Ströme fließen, bei denen es ganz schnell zu irgendwelchen unerwünschten Quereffekten kommt durchs Layout
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Deswegen ja ein modularer Aufbau. Kein Monolith. Bei kleinerem Equipment <i>kleinere</i> Bauteile, bei einer Großen halt die <i>fetten Brummer</i>


    Gruß aus der Pfalz

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Den Inhalt der Adresse der Motorstellung meinst Du? ;) Geht nach wie vor auch heute noch mit dem * (Dereferenzierungsoperator! ) Wenn Du die Adresse brauchst, gibt es doch den Adressoperator & dafür. Du meine Güte!<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Auch wenn das nur als Scherz gemeint war ist es dennoch interessant daß es immer noch Leute gibt, die Glauben man bräuchte Zeiger bei der softwareentwicklung. ;) Klar wenn man aus der antiken C Welt kommt.


    Es gibt durchaus Alternativen zu C die ich persönlich für besser erachte. Deshalb entwickle ich in Pascal. Die Sprache ist einfach besser strukturiert und läßt weniger Fehler zu. Bei C ist immer der Entwickler gefordert sein Programm vor Fehlern zu schützen.

    Es gibt ja sogar noch Leute die meinen, daß C die einzige Sprache sei um einen Microcontroller effektiv zu programmieren, weil sie dafür ausgelegt seien. Das ist natürlich ein totales Ammenmärchen. Letztendlich kommt es nur auf den vom Compiler erzeugten Code an. C hat aber im Microcontrollerbereich den Vorteil, daß halt die Compiler kostenlos sind.

    In diesem Sinne:
    http://www.henning-thielemann.de/CHater.html

  • Hallo Jörn,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    Find ich viel zu umständlich. Handbox = 4 Knöpfe. Am einfachsten vier Schalter und gut...Eignet sich am besten zum Nachbau auch für die einfachste Ansteuerung.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Ach, und der Tastendruck wird dann per Telepathie an die Motoren weitergegeben?
    Du verlagerst das Problem doch nur von der Handsteuerbox in die Steuerung bzw. den großen uController dort.
    Ein bißchen mehr Intelligenz in der Handsteuerbox vereinfacht das Interface Konzept um z.B. später eine zusätzliche Handsteuerbox mit grafischem Display zu implementieren.


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    Deswegen ja ein modularer Aufbau. Kein Monolith. Bei kleinerem Equipment kleinere Bauteile, bei einer Großen halt die fetten Brummer
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Nur die Probleme der einzelnen Module bleiben und Du erweiterst zudem die Komplexität der Software.[;)]

    Ich will damit doch nur ausdrücken, was andere auch schon gesagt haben, dass das ganze vermutlich wesentlich komplexer wird als es momentan aussieht. Und man das nicht unterschätzen darf.


    Nicht umsonst gilt der Spruch: 80% der Entwicklung ist in 20% der Zeit zu machen. Die restlichen 20% brauchen 80% der Zeit.


    Viele Grüße
    Volker

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Was genau meinst du?
    Bei den Controller-Herstellern für die Schrittmotoren gibt er bezüglich Layout etc. genaue Vorgaben.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Ja eben, aber selbst die Referenzdesigns (Demoboards) sind meist für recht geringe Ströme ausgelegt. Auch hier ergibt sich schon das Problem, daß selbst dort 4-Lagen-Leiterplatten (bei Trinamic) eingesetzt werden. Die sind deutlich teurer und lassen sich auch nicht mehr zu Hause ätzen. Wenn man dann noch bis an die Leistungsgrenze des Treibers gehen will, wird es sportlich. Ich wüsste nicht wie man da sein Layout mit Eagle zum Beispiel vorher auf eventuelle Leitugsbedingte Induktivitäten oder Widerstände prüfen will. Das dürfte in Trial and Error ausarten, schätze ich mal.

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: ThomasWest</i>
    ...
    Es gibt durchaus Alternativen zu C die ich persönlich für besser erachte. Deshalb entwickle ich in Pascal.
    ...
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    ok [:D]


    lg
    wolfi

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: ThomasWest</i>
    ...
    Es gibt durchaus Alternativen zu C die ich persönlich für besser erachte. Deshalb entwickle ich in Pascal.
    ...
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Hehe das is ja lustig. Da wünsche ich nur viel Spass bei zum Beispiel der Compilersuche für ARM und Konsorten ;)
    Ne jetzt im Ernst: Für Mikrokontrollerprogrammierung gibts eigentlich keine Alternative zu C (da wird meistens nicht mal c++ verwendet). Die ganzen verfügbaren Entwiklungsumgebungen bauen eigentlich auf C (zumindest für AVR und ARM)


    Weil hier schon des öfteren der Vorschlag gemacht wurde einen AVR zu benutzten: davon würde ich abraten, da eine Steuerung wie auch schon bemerkt wurde relativ viele komplexe Berechnungen machen muss und ich denke da geht so einen AVR schon mal recht schnell die Puste aus.


    Außerdem würde für den ARM sprechen, da es da Derivate gibt die schon relativ viele Schnittstellen mitintegriert haben (SPI, I2C, USB, ...)


    Von was ich auch abraten würde: Platinen selber ätzen. Warum: Nun das ist relativ einfach. Ein zweilagige Platine selber ätzen ist für einen Anfänger nicht möglich und mit einer Singellayer Platine kommt man bei den Modernen Gehäusen von MK of nicht aus. Man bekommt da die Leitungen einfach nicht entwirrt.


    Da ich in einen großen Halbleiterkonzern Arbeite und mich täglich mit hardwarenaher Programmierung und ARM's rumschlagen kann, kann ich euch davon ein Lied singen [:)] - Naja so arg is es auch wieder nicht [;)], aber da man Printplatten relativ günstig sich machen lassen kann (auch vierlagige zum Beispiel) würde ich da von einer Bastellösung absehen zumal die Printplatte sonst unerträglich groß werden würde und die SMD-Formfaktoren gar nicht so einfach zu ätzen sind - das kann dann schon des öfteren mal in die Hose gehen...


    Viele Grüße,
    Günther

  • 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.

  • hi!
    hm ... das machen aber ASCOM und INDI eigentlich auch. und INDI zumindest geht ned so schlecht ...


    ... aber den CAN-bus kann man sicher in Pascal programmieren [;)] ... und dann mit ^foo oder foo^ pointer dereferenzieren und referenzieren ...



    (just kiddin)


    lg
    wolfi

  • Hallo Steffen,


    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.


    Grundsätzlich finde ich es klasse, dass anscheinen doch einige Leute hier Sachen selber bauen.


    Der Tenor in diesem Thread geht in Richtung "starke", schnelle und
    genaue Steuerung ohne viel Schnickschnack als ersten Schritt.


    Wenn das dann läuft könnte man Erweiterungen nach legen.


    Es spricht natürlich nichts dagegen einen MCU mit CAN zu verwenden...


    Grüße
    Michael

  • Hallo,
    ja, so ganz unrund ist die Idee net - obwohl: Ducati hat so um 2005 die Elektronik ihrer Maschinen umgestellt auf dieses System ... und so viele Rückrufe hatten die bis dahin in ihrer gesamten Firmengeschichte net gehabt; ist reihenweise abgeraucht ;)


    (==&gt;)Michael:
    Die Stromversorgung des Busses kann ja die Steuerung mit übernehmen, das sollte eigentlich kein Problem darstellen, oder?!
    Für die Stepper würde ich eine getrennte Stromversorgung vorsehen - Entstörung und so ...


    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!


    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.
    Gruß,


    Steffen

  • Hallo Thomas,
    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Ja eben, aber selbst die Referenzdesigns (Demoboards) sind meist für recht geringe Ströme ausgelegt. Auch hier ergibt sich schon das Problem, daß selbst dort 4-Lagen-Leiterplatten (bei Trinamic) eingesetzt werden. Die sind deutlich teurer und lassen sich auch nicht mehr zu Hause ätzen. Wenn man dann noch bis an die Leistungsgrenze des Treibers gehen will, wird es sportlich. Ich wüsste nicht wie man da sein Layout mit Eagle zum Beispiel vorher auf eventuelle Leitugsbedingte Induktivitäten oder Widerstände prüfen will. Das dürfte in Trial and Error ausarten, schätze ich mal.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Gegen 4-Lagen-Leiterplatten habe ich nichts.
    Du kennst doch aus deinem Projekt die Preise der Chips - meinst du,
    dass es da auf 30 EUR mehr für die 4-Lagen-Leiterplatte gegenüber der 2-Lagen-LP ankommt?


    Den Widerstand von LP kann man mit z.B. 70um Basismaterial und Verzinnen senken...
    Induktivitäten hat man immer; etwa 1 nH/mm Leitungslänge, weshalb die Strompfade ja auch kurz sein sollten.
    Dann muss man noch auf die Potentialzusammenführung achten...


    Eigentlich alles keine Schwarze Magie.


    Der große Vorteil von "open" Projekten ist ja gerade, dass man nicht im stillen Kämmerlein entwickelt, sondern das Layout bzw. den Code veröffentlicht und Experten da korrigierend eingreifen können.


    Generell habe ich ja nichts gegen mahnende Worte, nur sollte man auch konstruktive Lösungsvorschläge bringen...


    Grüße
    Michael

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


    &gt;&gt; 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 :)

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Jede CPU kann damit bestens umgehen und die Verwendung selbiger ergibt meistens auch den effektiveren und schnelleren Code.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Klar kann jede CPU damit umgehen, aber für das Gehirn eines Menschen gibt es bessere Darstellungsformen. Man muss nicht wirklich wissen, wo eine Variable liegt um auf sie zuzugreifen. Man handelt sich aber durch Zeiger oft Fehlerquellen ein, wenn man nicht aufpasst wohin man zeigt. Die meisten Windows Sicherheitslecks sind auf unsaubere Zeigerroutinen zurückzuführen. Wenn man da nicht aufpasst, dann kann man schnell in Bereiche schreiben, wo eigentlich keine Daten sondern Code liegt und somit kann man Fremdcode einschleusen.
    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Wenn man das Prinzip verstanden hat, ist es eigentlich ziemlich Genial :-)<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    Aber genau da liegt das Problem. Man muss es erst mal verstehen und halt höllisch aufpassen.


    Letztendlich ist es eine Frage des Compilers. Der erzeugt den ja Code der auf der CPU ausgeführt wird und bestimmt damit die Effizienz des Codes unabhängig von der verwendeten Hochsprache. Auch Pascal verwendet übrigens im generierten Code Zeiger! Die eigentliche Hochsprache, mit der man es aber als Entwickler zu tun hat, kommt gänzlich ohne aus (aus Kompatibilitätsgründen sind die aber auch mit drin). Dafür ist Pascal wesentlich weniger fehleranfällig. Viele Fallstricke von C läßt Pascal per se nicht zu. So ist es zum Beispiel überhaupt nicht möglich, auf Elemente außerhalb eines Array zu schreiben. Auch die Stringverarbeitugsfunktionen von Pascal sind um Klassen besser.

    Ob ein Code hingegen schnell und effizient ist hängt nicht von der Verwendung von Zeigern ab. Das ist eine Mär, die gern von C Entwicklern verbreitet wird, C rzeuge pauschal den schnelleren Code. Moderne Pascal Compiler sind was den generierten Code angeht ebenbürtig.


    Hier mal ein Vergleich der Sprachen und der Mythen um C
    http://www.bernd-leitenberger.de/pascal-und-c.shtml
    Es reicht für das grobe Verständnis die Abschnitte "Zusammenfassung" und "Warum ist C so erfolgreich" zu lesen.
    Wer es genauer wissen will der sollte kann auch alles lesen.


    Letztendlich kommt es doch auf eines an: Jeder Entwickler ist mit irgendeiner Sprache groß geworden und diese beherrscht er. Eine andere Sprache zu lernen ist meist schwierig und man ist immer geneigt in der neuen Sprache genauso zu programmieren wie in der alten die man in- und auswändig kennt. Letztlich ist es eine Frage der Entwicklereffizienz. Was man kennt, geht schneller.
    Ich selbst entwickle sowohl in Pascal, Java als auch in C (obwoh ich es nicht mag ;-), aber weil ich es muss). Pascal ist mein Favorit, weil es sehr strukturiert, sehr leicht zu lesen und auch nach Jahren immer noch verständlich ist. Ich kenne genug C Programmierer, die nach Jahren Ihren eigenen Code nur noch mit Mühen verstehen können, weil sie geneigt waren alles so "effizient" wie möglich zu programmieren.


    Mal ganz abgesehen davon, was spricht dagegen in beiden Systemen zu entwickeln. Wenn die Hardware einmal steht, dann kann man verschiedne Firmware-Systeme drauf setzen. Das klappt beim PC doch auch. Da gibt es auch Windows und UNIX auf einer Hardwareplattform.

  • Hallo,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    Mal ganz abgesehen davon, was spricht dagegen in beiden Systemen zu entwickeln. Wenn die Hardware einmal steht, dann kann man verschiedne Firmware-Systeme drauf setzen. Das klappt beim PC doch auch. Da gibt es auch Windows und UNIX auf einer Hardwareplattform.
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Na eigentlich erstmal nichts, außer dass man wohl die Resourcen besser einsetzen sollte, als das gleiche doppelt zu implementieren.


    Im Prinzip hast Du aber recht, die Wahl der Hochsprache ist kein Kriterium mehr, wie schnell der ausführbare Code dann ist.


    Der vermutlich größte Vorteil von C liegt an der besseren Verfügbarkeit von Tools und Bibliotheken.


    Das Buskonzept klingt interessant, aber wir sollten erstmal auf die Grundkomponenten achten. Was bringt die Filterradsteuerung mit Rückmeldung, wenn die Motorsteuerung nicht rund läuft.
    Ich könnte mir aber gut einen Parallelbetrieb vorstellen. Zuerst die Motorsteuerung mit direkt anschließbarer (einfacher) Handbox, dazu schon das Businterface. Damit könnten wir uns zunächst auf das wesentliche konzentrieren und dann später den Rest erweitern. Stromversorgung sollte es ja eh eine eigene für die Motoren geben.


    Wir dürfen aber zwei wesentliche Grundelemente nicht aus den Augen verlieren: Die Steuerung sollte Selbstbau-geeignet sein und preislich sollte sie auch in einem vernünftigen Rahmen sein. Bei mal eben 30 Euro mehr nur für die Platine sollte man schon erstmal noch überlegen, ob sich eine andere Lösung nicht günstiger realisieren lässt.


    Viele Grüße
    Volker

  • Hi Leute,


    über das wichtigste von allem wurde hier noch gar nicht gesprochen: wie gedenkt ihr die Versionsverwaltung durchzuziehen. Sobald auch nur zwei Leute an dem Projekt arbeiten braucht man ein Versionierungstool (SVN, Git, ...) zwingend. Sonnst kommt nur Chaos dabei raus.
    Vielleicht könnte man dass über Sourceforge machen? Wobei es bei diesem Projekt ja nicht nur Software zu versionieren gilt sondern auch die Schaltpläne und Konstruktionszeichnungen.


    Gruß,
    Günther

  • Hallo,
    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">über das wichtigste von allem wurde hier noch gar nicht gesprochen<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    doch - siehe Seite 5. SVN und CVS wurde vorgeschlagen...
    Steffen wollte kein CVS.


    Webspace und sogar ein eigenes Forum wurde mir per PM angeboten.
    Finde es aber besser, zumindest erst mal, auf Astrotreff zu bleiben,
    damit möglichst viele von dem Projekt erfahren.


    Es wurde auch schon ein Zeitplan angedacht:
    Etwa 4 Wochen für Ideenfindung und Pflichtenheft.


    Grüße
    Michael

  • Hi Michael,


    hmm hab ich überlesen. Ja da kann ich Steffen nur beipflichten: bitte kein CVS. Ich persönlich würde SVN nehmen...


    Gruß,
    Günther

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: tmctiger</i>
    <br />
    hmm hab ich überlesen. Ja da kann ich Steffen nur beipflichten: bitte kein CVS. Ich persönlich würde SVN nehmen...
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    damit kann man ja auch prints und layouts update halten ... machen wir zumindest mit unseren manuskripten auch so...
    lg
    wolfi

  • Hallo Zusammen,


    ich wäre auch durchaus an aktiver Mitarbeit interessiert. Jedoch sollte vorher diskutiert und festgelegt werden, wie die Lizenz aussieht. Sprich: was ist unter Open Source zu verstehen?
    M.E. sollte Open Source z.B. jedem erlauben, das Projekt kommerziell zu nutzen und es nach eigenem Gutdünken zu verändern, sofern bei kommerzieller Nutzung die Änderungen ebenfalls Open Source sind.


    Viele Grüße
    Chris

  • Hallo,
    gehört sicherlich mit ins Pflichtenheft, die verwendete Lizenz.
    Welche Ausprägung ist aber ein technisches Detail ...


    Zum Thema 'Versionierung' - persönlich würde mir ein verteiltes System (git, mercurial, bazaar) gut gefallen - aber das ist auch Technik.
    Ins Pflichtenheft würde ich reinschreiben, daß ein Versionierungswerkzeug zum Einsatz kommt, und das Hosting des Codes (und vermutlich der gesamten Web-Präsenz?) bei einem entsprechenden Provider (sourceforge, github, etc.) erfolgen soll.
    Gruß,


    Steffen


    Steffen

  • <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: Birki</i>
    <br /><blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote"><i>Original erstellt von: tmctiger</i>
    <br />
    hmm hab ich überlesen. Ja da kann ich Steffen nur beipflichten: bitte kein CVS. Ich persönlich würde SVN nehmen...
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">
    damit kann man ja auch prints und layouts update halten ... machen wir zumindest mit unseren manuskripten auch so...
    lg
    wolfi
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    ja eben deshalb hab ich auch svn vorgeschlagen da es nicht so straight auf software ausgelegt ist und alles mögliche verwalten kann.

  • <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>
    <br />Hallo,
    gehört sicherlich mit ins Pflichtenheft, die verwendete Lizenz.
    Welche Ausprägung ist aber ein technisches Detail ...
    <hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Hi Steffen,


    die Ausformulierung der Open Source Lizenz ist ein <u>rechtliches</u> Detail - ein sehr wichtiges sogar.
    Diese sollte so früh wie möglich verbindlich formuliert werden - sowohl für die Software, als auch für die Hardware. Nur so kann man spätere Streitereien um Urheberschaften und Nutzungsrechte etc. halbwegs begrenzen.


    Ich würde kein Gehirnschmalz auf ein Projekt verwenden, bei dem die rechtlichen Randbedingungen nicht klar sind.


    Viele Grüße
    Chris

Jetzt mitmachen!

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