Beiträge von martin.c

    Hallo zusammen,


    für die laterale Lagerung möchte ich eine Variante zur Diskussion stellen:


    Statt einer Rolle werden dabei zwei Rollen und eine kleine Wippe verbaut.

    Die Wippe (rot) hat ihren Drehpunkt (blau) genau am Schwerpunkt des Spiegels.


    Der Auflagepunkt und die Wippe bewegen sich beim Kollimieren mit dem Spiegel auf und ab, der Spiegel wird dadurch immer im Schwerpunkt gehalten.

    Lediglich die Gewichtsverteilung zwischen den beiden Rollen ändert sich.

    Der einzige (konstante) Störeinfluss auf den Spiegel wäre das geringe Eigengewicht der Wippe selbst.



    Ich habe so eine Lagerung noch nicht wirklich gebaut, Details wie z.B. die Befestigung der Wippe sind mir auch noch unklar.

    Aber vielleicht lohnt sich das näher zu betrachten.


    Grüße,

    Martin Cibulski

    Hallo zusammen,


    ich hatte M101 bereits vor einem Jahr fotografiert.


    Dies ist eine Neubearbeitung mit PixInsight vom Januar diesen Jahres,

    dabei habe ich mich an diesem LRGB Workflow M51 von Tommy Nawratil orientiert.


    Viele Grüße,

    Martin Cibulski



    Teleskop: Lacerta Newton 250mm F 4.7

    Montierung: Selbstbau Harmonic Drive mit RA-Encoder

    Kamera: Atik 460exm mit OAG

    Belichtung: ca. 11h LRGB 105x300s, Ha 23x600s | Temp: -10°C | Bin: L/Ha 1x1 RGB 2x2 |

    Bortle 5

    Bearbeitung: PixInsight

    Hallo Reinhold,


    Danke für Dein Lob :). Die Konstruktion ist schon recht massiv geworden, das Hauptgetriebe HD32 hat einen Außendurchmesser von 145mm und wiegt über 4 kg.

    Das Kreuzrollenlager kann tatsächlich knapp 4 Tonnen tragen, als zulässiges Kippmoment sind 580 Nm angegeben, entsprechend ist die Steifigkeit auch sehr hoch.

    Nenndrehmoment ist 137 Nm, damit könnte man Radmuttern am Auto festziehen.


    Die Daten findet man in der 'Projektierungsanleitung' auf der Herstellerseite:

    https://harmonicdrive.de/fileadmin/user_upload/PA_HFUS_2UH_SO_SH_D_1015779_12_2018_V02.pdf


    Auseinandergebaut habe ich das Getriebe noch nicht, das möchte ich auch lieber bleiben lassen. Die beobachteten Fehler kommen ja nicht plötzlich und lassen sich durch Guiding beheben. Durch den hochauflösenden Encoder kann die Steuerung den Fehler ausregeln, bevor die Guidingkamera eingreifen muss.


    An verschmutztes Fett glaube ich nicht, da die Getriebe fast neuwertig sind, sie wurden nur eine kurze Zeit in einem Labor eingesetzt.

    Ich vermute, der Fehler kommt von der Verzahnung; die Zahnform ist eben nicht beliebig genau so herstellbar, dass die Drehung beim Eingriff absolut gleichmäßig erfolgt.

    25" Abweichung entsprechen (nach meiner Rechnung) nur etwa 5 micron Abweichung an der Zahnflanke (bei 80mm Zahnraddurchmesser). Größere Getriebe haben da Vorteile, weil da auch der Zahnraddurchmesser mitwächst.


    Resonanzen meine ich in der Fehlerkurve auch nicht zu erkennen, die Kurve erstreckt sich ja über mehrere Minuten. Die kleinen Zacken sind die Einzelbelichtungen im Sekundenabstand, da wird das Seeing einen Einfuss gehabt haben. Die eigentliche Resonanzfrequenz dürfte eher bei mehreren Hertz liegen und dazu braucht es auch eine Anregung in dieser Frequenz.


    Aber eine Messung mit verschiedenen Belastungszuständen wäre mal interessant.

    Leider kann ich nicht exakt ausbalancieren, weil ich nicht auskuppeln kann, das Gegengewicht ist also abgeschätzt.


    Grüße, Martin

    Hallo zusammen,


    die Aussagen zu den Fehlern bei Harmonic Drive Getrieben kann ich bestätigen.

    Bei meiner Harmonic Drive Selbstbaumontierung habe ich Lager der Firma Harmonic Drive verwendet, diese wurden vor Jahren im Forum günstig angeboten. Die Untersetzung ist 160:1, angetrieben werden sie von Nanotec-Schrittmotoren mit 10:1 Planetengetrieben.

    Die Lager haben einen wiederkehrenden, aber nicht wirklich periodischen Fehler, der bei meinem RA-Lager auch einmal ca. 25 Bogensekunden erreicht.

    Hier eine Aufzeichnung des Verlaufs (blaue Kurve), dazu habe ich bei PHD2 die RA-Korrekturen ausgeschaltet. Der Anzeigebereich wird einmal komplett verlassen.



    Mit diesem Fehlerverlauf konnte ich beim Guider nicht mehr als 1.0-1.5 Sekunden belichten, bevor die Montierung schon zu weit wegläuft. Entsprechend war die Genauigkeit beim Guiden nicht optimal, auch wegen der Seeingeffekte beim kurzen Belichten.

    Später habe ich einen hochauflösenden Renishaw-Encoder für die RA-Achse ergänzt, nun kann ich beim Guiden auch 5 Sekunden belichten und damit das Seeing herausmitteln.


    Wie schon geschrieben wurde, ist der Bau von Harmonic Drive Montierungen insofern interessant, dass man bei den Präzisionsteilen (Lager und Antriebe) auf Serienfertigung zurückgreifen kann, der Rest der Montierung muss nicht extrem exakt (=teuer) gebaut werden. Da ich selbst keine Metallwerkstatt habe, bestehen die anderen Teile meiner Montierung momentan noch aus Holz.


    Ich habe mich vor ca. 5 Jahren nach den Listenpreisen der HD-Getriebe erkundigt. Das kleinere HFUS-25-2UH sollte damals etwa 1900 Euro netto kosten, das größere HFUS-32-2UH etwa 2200 Euro, in Einzelstücken, auch an Privatkunden. Noch größere Getriebe sind auch nicht extrem teurer. Das wurde mir so erklärt, dass der Fertigungsaufwand ja nicht durch die Baugröße entsteht, sondern durch die Präzision, und die ist auch bei den kleinen Typen erforderlich.

    Das macht die Getriebe besonders für größere Montierungen interessant, so sonst die Preise eher exponentiell steigen.


    Hier mal ein Bild meiner Montierung mit einem 10" Newton:




    Gruß,

    Martin Cibulski

    Hallo zusammen,


    vielen Dank für die hilfreichen Beiträge !

    (ich kam nicht eher zum antworten)

    Zwanzig Grad über den Meridian fahren zu können, scheint nach den ersten Rückmeldungen (Chris, Jörg) genug zu sein.

    Ich werde es dabei belassen.


    Zu der empfohlenen Knicksäule (Reinhold):

    Die Montierung steht meistens stationär auf einer Betonsäule in einer Rolldachhütte.

    Sowohl die Säule als auch die Hütte existieren bereits, eine Knicksäule kann es darum nicht mehr werden.

    Ich habe auch die Erfahrung gemacht, dass bei einem Betrieb weit vor oder hinter dem Meridian (Tubus jeweils unter der Achse) schnell die Seitenwand im Weg ist.

    Transportiert wird die Montierung auch manchmal (aber selten), etwa zum Astrourlaub auf der Emberger Alm; dann steht sie auf einem Holz-Säulenstativ.


    Zu der gekippten Achse (Konrad, Marcus):

    Da die Montierung auch mobil nutzbar sein soll, wollte ich den Schwerpunkt möglichst über der Säule haben,

    das ist der Grund für den nach Süden zeigenden Polblock.

    Würde er nach Norden zeigen, könnte ein Säulenstativ umkippen oder müsste speziell dafür gebaut werden.


    Zum Meridianflip (Frank):

    Da muss ich mich noch einarbeiten. Ich nutze die Software NINA, damit kann man das ja automatisieren.

    Nur wie ich meinen ASCOM-Treiber zu einem Meridianflip bewegen kann, weiß ich noch nicht.


    Freundliche Grüße,

    Martin Cibulski

    Hallo zusammen,


    ich konstruiere gerade eine Montierung für mich mit HarmonicDrive-Lagern, die ich vor einigen Jahren gebraucht gekauft habe.

    Einen funktionsfähigen Prototypen mit den tragenden Teilen aus Sperrholz habe ich bereits:




    Beim Entwurf der neuen (Metall-)Montierung frage ich mich, wie lang die Deklinationsachse sein sollte,

    also wie weit seitlich von der Rektaszensionsachse sollte das Teleskop gehalten werden ?


    Dadurch wird bestimmt, wie weit man über den Meridian fahren kann, bevor das Teleskop an die Säule anstößt.

    Zu breit sollte das ganze auch nicht werden, sonst wird es unnötig schwer, nimmt zu viel Platz ein und ist durch die längere Dekl.-Achse weniger steif.


    In dem CAD-Bild ist das Teleskop gerade 20 Grad, also 1:20 Stunden über den Meridian gefahren und stößt fast an der Säule an:



    Mich würde interessieren:


    Wie sind käufliche oder Selbstbau-Montierungen da normalerweise ausgelegt, wie weit kommt man damit über den Meridian ?

    Wie sind Eure Erfahrungen mit mehr oder weniger ausladender Bauweise, bei visueller/fotografischer Nutzung ?



    Freundliche Grüße

    Martin Cibulski

    Hallo allerseits,


    ein Astrokollege aus einem Nachbarland hat mich gefragt, wie in Deutschland üblicherweise Städte und Gemeinden mit Astrovereinen umgehen, die eine Sternwarte betreiben.
    Ihn interessieren besonders die finanziellen Verpflichtungen solch eines Vereines gegenüber der Gemeinde, wenn sich die Sternwarte in einem stadteigenen Gebäude befindet.


    Konkret möchte er wissen:
    >> Gibt es Sternwarten in Besitz von Stadt/Land/Gemeinden etc. die gegenüber einem gemeinnützigen Astronomieverein Ansprüche in Punkto Erhaltung und Abgaben stellen?
    Oder ist es eher die Regel, dass Astronomievereine von der öffentlichen Hand unterstützt werden ? <<


    Anlass sind laufende Vertragsverhandlungen seines Vereines mit der zuständigen Gemeinde.


    Es wäre schön, wenn hier ein paar Beispiele zusammenkämen, die für seine Verhandlung hilfreich sind.


    (ich hoffe, ich habe das richtige Unterforum gewählt, ansonsten bitte verschieben)


    Vielen Dank,
    Martin Cibulski

    [quoteaußerdem ist es gerade bei einem Erstschliff dankbarer mit einer großen Brennweite zu beginnen, das Cassergrain hätte diese dann ja mit ca. 2m.[/quote]


    Hallo Alex,


    beim Cassegrain ist die Gesamtbrennweite zwar groß, der zu schleifende Hauptspiegel hat aber eine deutlich kürzere Brennweite und ich dadurch schwieriger herzustellen.


    Gruß,
    Martin

    Hallo zusammen,


    was mir an den Angaben immer wieder auffällt:


    Es werden Herstellerangaben verglichen und diskutiert, aber niemals werden diese neutral kontrolliert !
    Es scheint kein eindeutiges Kriterium zu geben, was denn genau mit 'fotografisch geeignet' gemeint ist. Natürlich hängt das auch ab von der Tubuslänge, der verwendeten Brennweite, einem evtl. vorhandenen Windschutz usw.


    Aber als einziges messbares Kriterium bleibt für mich die Steifigkeit der Montierung übrig, also um wieviele Bogensekunden verbiegt sich die Montierung, wenn man ein bestimmtes Drehmoment anlegt. Wenn an diesen Wert weiß, kann man immer noch überlegen, wie sich das bei einem längeren/kürzeren Tubus, mit/ohne Kuppel usw. verhält. Aber man hat schon einmal EINEN vergleichbaren Wert in der Hand.


    Ich hätte da einen Vorschlag wie man die Steifigkeit einfach messen kann:


    1. Tubus am vorderen Ende mit einem Gewicht belasten, so dass ein bestimmtes Drehmoment entsteht (Tubuslänge * Gewicht = konstant)
    2. Montierung nach Süden auf einen Stern in mittlerer Höhe ausrichten
    3. Webcam einschalten und Videoaufzeichnung starten
    4. Nachführung stoppen und rasch
    5. Belastungsgewicht entfernen (evtl. über Elekromagnet oder Bandschlinge, bei der ein Ende losgelassen wird)


    Das Ergebnis ist eine abklingende Schwingung auf dem Video,
    die man hinsichtlich Amplitude und Abklingverhalten auswerten kann.


    Ist so etwas praktikabel, neutrale Daten zur Montierungssteifigkeit zu bekommen ?
    Vielleicht hat ja jemand bessee Vorschläge oder kann so etwas mal testen...


    Gruß,
    Martin Cibulski


    auf dieser Seite aufgefallen ist-


    Losmady G8 wird mit 13kg angegeben, die G11 mit 27- das liegt jeweils schon nahe den Angaben des Herstellers.


    Die Vixen Atlux dagegen steht mit 22kg drin- Vixen selbst gibt hier 34kg an. Damit läge sie fotografisch nutzbar bei den Daumen mal phi 2/3- bei den Losmandys dagegen ist das nicht der Fall.


    Und das eine LXD75 12kg fotografisch trägt bezweifle ich auch stark. [:)] <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">An astrophotography mount performance overview<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">Das steht ja als Kopfzeile darüber- und viele Angaben machen das unglaubwürdig.


    Gruß
    Stefan
    [/quote]

    Hallo zusammen,


    man kann bei einem Holzring das Gewicht optimieren, indem man ihn nicht überall gleich dick macht.


    Wenn eine Drahtspinne an vier Punten verspannt ist, ist das Biegemoment an den 4 Befestigungspunkten besonders hoch (Biegung nach innen) und an den 4 Stellen genau dazwischen auch (Biegung nach außen). Zwischen diesen 8 Punkten wird das Biegemoment null.


    Man kann also Gewicht sparen, wenn der Ring innen rund und außen achteckig (Spinne mit vier Befestigungspunkten) oder sechseckig (Spinne mit drei Befestigungspunkten) geformt ist. Dann ist dort die Stabilität am größten, wo auch die größten Biegekräfte auftreten.


    Gruß,
    Martin

    Hallo Martin,


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">Aber ich finde, wenn man einen Dobson schon unbedingt mit Goto aufrüsten will, gehören da Encoder für die Positionsbestimmung und Servomotoren mit Rutschkupplung als Antrieb dran.
    . . .
    Schon technisch ist ein Schrittmotorantrieb am Dobson eine ziemliche Katastrophe. Die nötge formschlüssige Kraftübertragung erfordert z.B. gebogene Zahnstangen oder ähnliche Lösungen. Mit Servomotoren wäre dagegen beispielsweise einfach der Austausch je eines Gleitlagers gegen einen Antriebsmotor mit Getriebe und Gummiwalze denkbar, die zwei Encoder müssen natürlich zusätzlich montiert werden.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Encoder und Rutschkupplungen machen sicherlich Sinn, weil man dann nicht über den halben Himmel fahren muss, wie Du richtig bemerkt hast. Ein einfacher Schwenk von Hand reicht aus und die Steuerung weiß wo das Teleskop hinzeigt und in welche richtung nachgeführt werden muss. Leider habe ich das nicht eingebaut.
    Servomotoren sind jedoch nicht zwingend notwendig, denn es gibt auch Montierungen mit Schrittmotoren und Rutschkupplungen.


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    Selbst ein perfekt laufendes Goto könnte bei mir nicht ganz die Aufsuchkarten ersetzen. Wenn ich einen schwachen PN oder eine grenzwertig helle Galaxiengruppe anpeile, brauche ich eine gute Aufsuchkarte, um die Positionen des Objekts zu den Feldsternen zu vergleichen.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Stimmt.


    <blockquote id="quote"><font size="1" face="Verdana, Arial, Helvetica" id="quote">Zitat:<hr height="1" noshade id="quote">
    Die Messier- und hellen NGC-"Standardkerzen" sollte man nach ein paar Jahren Dobson-Schubserei sowieso ohne Goto auswendig finden.<hr height="1" noshade id="quote"></blockquote id="quote"></font id="quote">


    Das ist leider ein Nachteil von Goto, dass man die Positionen der Objekte nicht lernt. Ich nutze Goto aus Bequemlichkeit und weiß darum nur ungefähr, wo die Standard-Objekte sind.
    Das Warten auf einen Schwenk 'über den halben Himmel' (2-3 Minuten?)stört mich eher wenig, da oft noch ein passendes Okular, evtl. mit Filter vorbereitet werden muss. Da hat man sowieso etwas zu tun.
    Und man kann die Tour auch etwas geschickter planen.


    Etwas laut ist es allerdings mit Schrittmotoren, besonders bei Dobson-Teleskopen, die mit ihrer Holzbauweise einen guten Resonanzkörper bilden.


    Gruß,
    Martin

    Hallo Mario,
    hallo Jan,


    eine Stückliste kann man aus den Eagle-Dateien erzeugen.
    Alle Bauteile auf den Platinen haben Namen und Werte bekommen.


    Für alles Andere (Kabel, Taster, Stecker ...) habe ich leider keine Stückliste parat.
    Wenn Ihr die Steuerung tatsächlich bauen wollt, kann ich die aktuellen Pläne gern zuschicken (oder hochladen, die Seite ist eh pflegebedürftig).
    Vielleicht macht ein Kontakt zu dem Verein in Holland Sinn, zuletzt hatte ich gelesen, dass dort ein verbessertes Layout mit einem 12/24V-Spannungswandler entworfen wurde. Auch ein Verkauf von Bausätzen ist dort im Gespräch.


    Gruß,
    Martin

    Hallo Peacemaker,


    ich habe solch eine Steuerung schon mal entwickelt.


    http://martin.cibulski.de/atm/…controller_4/index_de.htm


    Sie darf gern auch nachgebaut werden, in Holland gibt es mehrere davon in einem Astronomieclub:


    http://www.sterrenwachtalmere.nl


    Wichtig für die Funktion ist dass die Mechanik sauber läuft.
    Dann ist die Nachführung durch den Mikroschrittbetrieb sehr ruhig und genau. Ein Goto trifft sein Ziel auch bei höheren Vergrößerungen.


    Gruß,
    Martin

    Hallo,


    mit dem GCC übersetzte Programme können bei ARM-Prozessoren echte 64bit-double-Variablen verarbeiten. Bei Atmel ist double wie float nur 32 bit breit.
    Will man 64bit double verwenden, braucht man bei Atmel einen kommerziellen C-Compiler soweit mir bekannt ist.
    Und die sind sehr teuer.


    Gruß,
    Martin Cibulski

    Hallo Igor,


    der obere Teil erschein mir richtig zu sein,
    aber ab hier wird es falsch:


    <b>24 h = 86400 Bogensekunden entsprechen 360°</b>


    Ein Tag (eine volle Umdrehung) sind 360°*60*60 Bogensekunden,
    das sind 1296000 !
    In einer Zeitsekunde dreht sich die Erde 15 Bogensekunden weiter.


    Damit werden die Schrittauflösungen um den Faktor 15 grober
    als bei Dir angegeben.


    Gruß,
    Martin Cibulski
    http://martin.cibulski.de/atm/

    [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

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


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


    Hallo Steffen,


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


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


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


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


    Gruß,
    Martin

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


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


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


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


    Gruß,
    Martin

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


    Hallo Steffen,


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


    Gruß,
    Martin