Ich darf vorstellen - TSC (yet another controller)

Status
Es sind keine weiteren Antworten möglich.

Birki

Aktives Mitglied
Hallo!

Vor einige Monaten habe ich meine Littlefoot endgültig dem Elektronikschrott übergeben und hab beschlossen, dass ich sogar für mein stationäres Teleskop nicht mehr von Laptop, Windows Components und anderem Schmarrn abhängig sein will - und hab mir eine Steuerung auf einem Raspberry Pi 3 mit Autoguider, LX200 und ST4 programmiert. Das Ergebnis - das noch nicht vollständig ausgetestet ist - habe ich einmal hier dokumentiert und vorgestellt: TSC-Wiki auf GitHub

Dort findet man auch den C++-Sourcecode etc. Kommentare und Anregungen sind mir sehr willkommen :D
lg
wolfi
Link zur Grafik: https://github.com/selste/TwoStepperControl/blob/master/Manual_Imagedata/tsc.jpg
 
hallo tommy!
naja, es hat ja auch seit unserem letzten treffen mit dem alois vor sich hingegärt ;)
lg
wolfi
 
Hallo Wolfi,

das sieht in der Tat sehr gut aus. Ich werde das einem Freund nahe legen.

Gruß Markus
 
Hallo Wolfi,

ich ziehen meinen Hut und verneige mich vor Ehrfurcht :respekt2:

Mein OnStep Umsetzungs-Projekt geht damit vorerst in die Kiste....und wird dann vollkommen beerdigt, wenn

- Support for german equatorial mounts
- Full ASCOM or INDI support for LX200 commands deployed form other software systems such as Stellarium.

irgendwann mal realisiert sind :smiley47:

Gruß und CS,
Dieter


 
Hallo Wolfi,
super Steuerung sieht schon richtig gut aus, auch die Dokumentation ist schon sehr gelungen.
Da ist erstmal alles an Bord was man so für eine Steuerung benötigt.

Gruß und CS

Anna
 
hallo!
danke für die blumen und ehrfurchtsbezeugungen - es ist ein projekt für die langen winterabende gewesen, aber es gibt noch viel zu probieren und zu debuggen; der autoguider hat sich das wochenende eigentlich recht gesittet verhalten, aber hochnebel und fön haben die tests eher rudimentär werden lassen.

@ ASCOM/INDI support: die software hat eigentlich schon einen INDI-server für die kamera laufen. nachdem der pi so konfiguriert ist, dass er in abwesenheit eines wlan-routers selber zum accesspoint wird, seh ich da wenig probleme mit der einbindung. das drama ist eher, dass einige planetariumsprogramme die serielle schnittstelle nur sehr schleissig eingebunden haben (z. B. stellarium). da habe ich hoffnung auf ascom und tcp/ip. nachdem ich cdc fan bin hab ich aber egoistischerweise einmal das cdc über die rs232 eingebunden.

@ deutsche montierung: das problem ist - ich hab keine. ich hab nur meine grosse gabel und eine ausgleichsmonti motorisiert. was soll die steuerung denn können? von selber east-of-pier erkennen? dann brauchts absolutencoder (teuer) oder endschalter (müssen angebaut werden) oder - am einfachsten - eine kompensierte gepufferte uhr (kostet 15 €) - dann weiss man nach dem sync, wo das ding gerade ist. soll die steuerung a.) herummeckern, wenns zeit zum umschlagen wird oder b.) selber umschlagen oder c.) ganz was anderes tun? verzeihts die dumme frage, ich hab da einfach keine erfahrung :)

lg
wolfi
 
Hallo Wolfi,

Glückwunsch. Ja,solche Herausforderungen sind immer was für dunkle, bewölte Winterabende. Sollen schon ganze Teleskope diseits der Wolkendecke entstanden sein. 8)

Aber bis zum Funktionsumfang der Onstep ist noch ein weiter weg.Alt-AZ-Unterstütung für Dobsons, äquatoriale Gabelmontierungen, Deutschemontierungen, Pointingmodell mit mehr als 3 Alignmentstars und Parametern, LAN, WLAN, Bluetooth, ASCOM-Treiber. Ja, da ist schon ordentlich Musik drinn. Und selbst ein Atmega 2560 kommt damit klar. Schön finde ich persönlich die kleine Variante auf Basis des Teensy 3.2. Die Steuerung wird dann gerade mal so groß wie eine Zigarettenschachtel.
So schnell werde ich die jetzt nicht über Bord werfen. Ein Raspberry-PI daneben tut auch keinem weh. Und wenn ich die kosten der Treiberstufen mit einem RASP128 vergleiche, dann fällt die Entscheidung klar aus.
Aber dennoch Hut ab. Hoffe Du hattest tierisch Spaß bei Deinem Projekt und wie man sieht, gehen Dir die Ideen nicht aus.

Daher hier noch ein paar Anregungen:

Eine dedizierte serielle Schnittstelle brauchts nicht. Über einen virtual serial Port (com0com, es gibt davon aus eine signierte Variante (irgendwo im github Universum)) kann ein Windows-Client auch über die IP-Schnittstelle mit der Steuerung kommunizieren. Und damit auch über WLAN.

Solange der PI im Heimnetz ist, kann die Systemzeit auch über NTP synchronisiert werden. Hier steht wohl was dazu. Wir halten damit Server-Nodes synchron.
http://aufschnur.de/raspberry-pi-uhrzeit-automatik/

CDC kann evtl. auch indi. Zumindest auf dem Mac (oder auf Linux). Unter Windows verwende ich ASCOM. Bei der Entwicklung der LX200-Protokolls sollte man sich eher am LX200-Classic-Ascom-Treiber orientieren. Damit hat man einen guten Startpunkt, der zugleich auch verschiedene Client-Programme unterstützt.

Die Steuerungsanbindung über Stellarium gefällt mir persönlich garnicht. Wenngleich ich die Bedienung sehr ansprechend finde. TheSkyTechX ist mein neuer Stern am Softwarehimmel. Sehr durchdacht. Kann aber gegenwärtig nur ASCOM.

LG
Gerrit
 
Zuletzt von einem Moderator bearbeitet:
servus!

bitte keinen steuerungskrieg ;) - ich find die onstep grossartig, haeb mich aber letztenendes genau wegen der RAPS128 dagegen entschieden - die sind mit maximal 2.2 A leider zu schwach. wo ich dir beipflichte ist, dass die phidgets mit 100 € relativ teuer sind. da habe ich gewisse erwartungen in die ST micro dspin treiber, die immerhin 3A können. das wird die zukunft einfach weisen.

ansonsten ist es doch schön, wenn es mehrere möglichkeiten gibt - und WLAN, LAN und BT habe ich ja auch schon. dobson und 3 star alignemnt nocht nicht. letzteres gehört sicher dazu, ersteres weiss ich ehrlich gesagt nicht.

mein fokus liegt halt an der kameranbindung; das ist etwas, was meiner meinung nach sonst keine steuerung kann. für mich selber muss ich sagen, dass ich vor ein paar jahren mit dem fotografieren (auf bescheidenem niveau und zum spass) aufgehört habe aus frust über diverse probleme, die ich damals mit autoguiding und der littlefoot hatte.

lg
wolfi
 
Hallo Wolfi,

Einen Steuerungskrieg sehe ich nicht. Das will ich auch garnicht bezwecken. Bei den Kosten kann man das eine nutzen. Das andere weiterentwickeln.

2,2A pro Phase. DAs ist nicht zu schwach. Das wird völlig unterbewertet.

Jedes Opensource-Projekt tut uns gut. Denn was ist, wenn Steuerungen nicht weiter entwickelt werden oder vom Markt verschwinden. Dann steht der Sternfreund vor erheblichen Kosten. Deine Motivation möchte nicht beeinträchtigen. Du gehst einen Weg, den ich schon dem Openstep-Projekt empfohlen habe. Du baust das ganze auf Linux auf. Klasse Idee!
Ich wollte nur skizzieren, daß man noch einen weg gehen muß. Und ich denke, Du bist bereit das zu tun. Und das ist gut so.

DAs Thema Kameranbindung ist m.E. schon längst gelöst. Auch auf dem PI. Da schau Dir gerne noch mal EKOS an. Da tut sich eine Menge. Und wenn der PI das lasttechnisch parallel gestattet. Feine Sache.

Was mir an Deinem Ansatz sehr gut gefällt, ist die Option fertige Treiber einzusetzen. Es wäre doch bestimmt auch mnal interessant, Treiber von Nanotec einzubinden. Die kosten nicht viel mehr als Deine. Können aber BLDC-Motoren mit Encodern anschließen. Und über eine geschickte Architektur im Code für Aktuatoren und Sensorik (Encoder) ist doch sicherlich einiges möglich. Selbst in C++.

Ich bin gerne für einen weiteren Informationsaustausch offen. Auch via PN.
Sollte ich Dir zu nahe getreten sein, Wolfi. Keine Bange. Das war nicht meine Intention.
LG
Gerrit

 
Zuletzt von einem Moderator bearbeitet:
hallo!

bist mir überhaupt nicht zu nahe getreten, keine sorge :D

- wegen der 2.2A: ich hatte einmal eine steuerung mit 2.5A pro endstufe - die hat mein teleskop mit ach und krach angetrieben, mit massiver kühlung, und mit einer goto-gteschwindigkeit von 60x (statt jetzt 120x) sidereal. das gute stück ist halt ein bisserl schwerer ;)

- wg. EKOS: die anbindung der kamera erfolgt intern ja schon über INDI; EKOS ist da eher ein schritt zur verkomplizierung, so wie ich das im moment sehe.

- treiber: nanotec schätze ich sehr, die endstufen kosten aber nocheinmal das doppelte. die dspin-endstufen sind für ~ 30 € zu haben, das find ich interssanter.

und informationsaustauch - gern, jederzeit :)

lg
wolfi
 
Hallo Wolfi,

da kenne ich die Motoren und den Antrieb Deiner Monti nicht. Evtl. erzählst mal was darüber.

EKOS ist für mich eher schon eine Workbench, mit der man einiges an Aufnahmen automatisieren kann. Es wird Dir helfen. Wieso dann üerhaupt INDI, wenn man das Flagschiff nicht fahren will. Nur wegen CDC braucht man das nicht.

LG
Gerrit
 
Zuletzt von einem Moderator bearbeitet:
hi!
ich brauch INDI nicht fürs CdC, ich brauchs fürs einlesen der guidingkamera. die idee ist ja, dass die steuerung einen eigenen autoguider hat - was sie meiner meinung nach von anderen steuerungen unterscheidet. man kann auch extern über st4 guiden, wobei ich das im feld noch nicht probiert habe - aber man sollte nicht müssen :)

und meine motoren wollen bis zu 2.6 A (sind grössere nanotecs), das montierungsgewicht liegt be ~350 kg++. in dem wiki ist am anfang eh ein bild von dem trumm...

lg
wolfi

 
hallo!
hab gestern ein bisserl mit ASCOM gespielt - was soll das 32 bit only driver gschiterl bei den LX200 treibern heissen? skytechx und hallo northern sky erklären kurzerhand, dass sie als 64 bit programme den treiber nicht nutzen können, und auf der ASCOm page verweist man darauf, dass das ein treiber- und kein ASCOM problem sei. bei skytechx kann ich die 32 bit version installieren, aber gibts da sonst noch alternativen?

lg
wolfi
 
jaja, du hast meine motivation gut erkannt :D
lg
wolfi
 
hallo!
so, nach einigem gekämpfe - geht der Advanced LX200 treiber von charles auch. also zumindest mit skytechx und cartes du ciel, stellarium und hallo northern sky hab ich noch nicht ausprobiert.
lg
wolfi
 
hi!
um genauer zu sein - hier eine liste der planetrariumsprogramme, die mit Advanced LX200 ASCOM zumindest für trackings, syncing und slewing funktionieren: https://github.com/selste/TwoStepperControl/wiki/TSC

kurz und gut: CdC 4.0, SkyTechX 1.05 und C2A gehen mit ASCOM, wobei ich mich mit der software-handbox noch beschäftigen muss. Hallo Northern Sky kommt mit dem Advanced LX200 treiber nicht wirklich klar.

Stellarium wird - solange sich keiner mit der Telskopschnittstelle ernsthaft beschäftigt - immer ein Problem sein. Die direkte Verbindung via serialle Schnittstelle erlaubt kein Sync, und das Slew ist keines im Sinne des LX200 Protokolls. Stellarium schickt nämlich nur Koordinaten, nicht aber den Befehl, den Slew auszuführen. StellariumScope - die ASCOM anbindung von Stellarium - fliegt mir leider um die Ohren ...

lg
wolfi
 
hi!

kleines update: Advanced LX200 ASCOM treiber geht vollständig mit CdC, C2A - bei SkyTechX gehen Sync und Slew, die handbox macht schwierigkeiten, die sie bei CdC und C2A nicht macht.

Stellarium kann jetzt zumindest slewing, syncing wird ja nicht unterstützt. ausserdem gehen auf linux stellarium, CdC und KStars - details wie immer hier https://github.com/selste/TwoStepperControl/wiki/TSC
lg
wolfi
 
Zitat von Birki:
hallo!
@ deutsche montierung: das problem ist - ich hab keine. ich hab nur meine grosse gabel und eine ausgleichsmonti motorisiert. was soll die steuerung denn können? von selber east-of-pier erkennen? dann brauchts absolutencoder (teuer) oder endschalter (müssen angebaut werden) oder - am einfachsten - eine kompensierte gepufferte uhr (kostet 15 €) - dann weiss man nach dem sync, wo das ding gerade ist. soll die steuerung a.) herummeckern, wenns zeit zum umschlagen wird oder b.) selber umschlagen oder c.) ganz was anderes tun? verzeihts die dumme frage, ich hab da einfach keine erfahrung :)

lg
wolfi
Hallo Wolfi,

meine Anerkennung für Dein Projekt !

Grundsätzlich würde ich Aktionen unterlassen, die den Benutzer überraschen. Plötzliches selber umschlagen wäre schon mal nicht gut.
Man stelle sich vor, man beobachtet arglos und bekommt das Okular ins Auge gerammt.
Geeignet wäre ein Hinweis zur gegebener Zeit, welchen man explizit bestätigen oder auch ablehnen kann. Man könnte im Falle der Nichtbeachtung auch vorsehen, dass die Nachführung nach einer gewissen (evtl. voreinstellbaren) Zeit stoppt und das Umschlagen dann explizit oder nach nochmaliger (evtl. akkustischer) Vorwarnung ausgelöst wird.
Eine Abbruchtaste während des Umschlagen und GOTO ist in jedem Fall eine gute Idee.

Für meine Steuerungen hatte ich überhaupt kein automatisches Umschlagen während der Nachführung vorgesehen. Lediglich für das GOTO konnte man voreinstellen, ob ein Umschlagen automatisch oder bestätigt geschehen würde, falls das Umschlagen die kürzere Strecke zum Zielobjekt bedeuten würde.

Sofern keine [zensiert]ensichere Encoderlösung vorhanden ist, sollte der Benutzer ohnehin ein Auge auf die Situation haben. Am ungefährlichsten wäre noch, wenn der Teleskoptubus im schnellen Schwenk an ein Stativbein anstösst. Denn das Drehmoment der Motoren ist normalerweise niedrig genug, dass sie sofort stehenbleiben anstatt den Teleskoptubus zu knicken. Eher schon werden hervorstehende Motoren oder Kabel eingezwickt und beschädigt. Aufwändiger wird es, wenn die deutsche Montierung vollständig unbeaufsichtigt und zuverlässig aus der Ferne kontrollierbar sein soll.

Was den maximalen Wicklungsstrom betrifft gilt natürlich: Viel kann viel helfen. Andererseits ist auch mit wenig Wicklungsstrom einiges möglich, wenn alle Komponenten optimiert und für das benötigte Drehmoment aufeinander abgestimmt sind. Für kleine Montierungen genügen 1,5A durchaus für eine Schwenkgeschwindigkeit von 4 Grad pro Sekunde.

LG
Sigi
 
Zuletzt von einem Moderator bearbeitet:
hallo sigi!

die anerkennung des profis freut mich natürlich besonders. ich denke - wenn man umschlagen direkt auf der steuerung realisiert, dann sicher nur beim GoTo und nach vorwarnung. ich denke, dass ist bei charles' ascom treiber auch so realsiiert. ich selber kanns leider nicht ausprobieren - habe einige montierungen, aber keine motorisierte deutsche :D

einen notstop habe ich natürlich; bei meinem letzten treffen mit richard gierlinger sind wir zum schluss gekommen, dass der grossmontierungsbau in österreich als vermächtsnis vom ing. pressberger wohl populärer ist als anderswo, daher haben wir eine neigung zu dickeren brummern - und auch mein teleskop möchte ich nicht schnell oder unkontrolliert bewegen, da ist dann einiges kaputt ...

zum maximalen wicklungsstrom: wie du richtig sagst, viel hilft viel. in meinem fall stören die 1/16 mikroschritte der phidgets dank grosser schneckenräder nicht, für andere mögens zu wenig sein. mittelfristig will ich ehrlich gesagt eher weg von den dingern, weil sie auch nicht unbedingt billig sind mit 90$ ... ich denke da an eine tcp/ip basierte master/slave lösung, wo die usb vernbindung zu den phidgets von einer tcp - verbindung auf einen arduino o. ä. ersetzt wird. ich will auf jeden fall einmal was mit dem standard drv8825 oder dem dspin probieren, das kostet fast nix und ist gut unterstützt.

lg
wolfi
 
Hallo Wolfi,

beneidenswert, was heutzutage mit fertigen Modulen möglich ist. Die genannten Motortreiber sind hochinteressant und bestimmt die Mühe wert mit unterstützt zu werden. Wobei ich angesichts des Fokus auf grössere Montierungen die Materialkosten eher sekundär und vorrangig die unproblematische Gesamtintegration sehen würde. Aber nätürlich kann ein Modul auch mal nicht mehr erhältlich sein, so dass das Vorsehen von Alternativen richtig und wichtig ist und wenn man vorausschauend in der Firmware dafür eine variable Treiberschicht vorsehen kann, umso besser.

Selbstredend kein Vergleich zu meinen damaligen bescheidenen Steuerungen, wo aus möglichst wenig Bauteilen mit einem 8-Bit-Mikrocontroller noch eine halbwegs annehmbare Leistung herauszukitzeln war und alles auf eine relativ kleine Leiterplatte passen musste. Die Ansteuerung der Motortreiber war direkt und low-level.
Heutzutage gibt es diese "intelligenten" Motortreiber und mit der Rechenpower und Speicherausstattung von 32-Bit-Mikrocontrollern geht viel mehr, wenngleich natürlich die Anforderungen an das Leiterplattenlayout nicht weniger geworden sind.

LG
Sigi
 
Hallo Sigi, Hallo Wolfi,

na der Wolfi hat halt erstmal geschaut, daß es läuft. Vom Software-Design hier kann man ja jetzt weiter voran gehen. Mir fällt z.B. auf, daß man für die Phidgets je zwei Treiber-Anbindungen entwickelt hat. Software-Entwickler sind aber i.d.R. faul wie Hulle (zumindest ich). Durch ein geschicktes Software-Design mit "Interface"-Klassen kann man aber:

1. Entwicklungsaufwand sparen, weil man pro Treiber nur eine Klasse entwickeln muß
2. Viel wichtiger noch: Den Rest der Steuerungslogik von der konkreten Treiber-Ansteuerung trennen und damit:
3. Den Code zugänglicher machen für weitere Treiberbausteine (Non-Phidgets).

Dazu bedarfs nicht mal vieler Änderungen. Und mit etwas Komfort kann man diese Treiberstufen dynamisch zur Laufzeit in die Hauptsoftware linken.

Ich zeichne später mal auf, was ich meine.

LG
Gerrit
 
Zuletzt von einem Moderator bearbeitet:
grüss euch!

erste einmal - debuggt und wiki upgedatet - https://github.com/selste/TwoStepperControl/wiki/TSC

jetzt gibts wunderhübsche screenshots im appendix von sky safari 5 plus, stellarium (würg), CdC, SkyTechX und soweiter ...

@sigi: ich erinnere mich auch noch an früher - allerdings bin ich kein elektroniker, und hab daher mit microcontrollern nie soviel gemacht. aber ich hatt einmal wahnsinnig teure schrittmotor-steuermodule, die per vt-terminal mit ASCII zeichen angesprochen wurden - das war wirklich schlimm. was aber mit dem ganzen neuen zeug ein bisserl verlorengeht ist die trickreiche programmiererei :)

@Gerrit: uiui, da hat er einen finger auf eine wunde gelegt :) - das will ich schon seit monaten bereinigen (man verzeihe dem physiker). eigentlich wär das ein klassischer vererbungskandidat, weil der RA motor nur eine funktion mehr hat (nämlich stur nachzuführen). aber du weisst ja, wenns einmal geht, dann mag man da gar nicht soviel herumfummeln :) ... ich denke, dass ich das eh abstrakter angehen sollte, dann gibts eine motorklasse, die hat ein rektaszensionskind - und die reden dann nur mit parametern mit den treiberinterfaces, so wie du vorgeschlagen hast.

lg
wolfi
 
Zuletzt von einem Moderator bearbeitet:
Hallo Wolfi,
:huhu:
die anderen Wunden die ich gestern gesehen habe, lasse ich noch etwas bluten :)
:cool:
Gestern habe ich Deinen Code mal probehalber reverse engineered in der UML und mir sind da auch ein paar Leichen entgegen gepurzelt. Macht nix.

Evtl. kann ma diesen Thread hier verwenden, um über algorithmische Lösungen nach zu denken. Was Du davon übernimmst, ist ja Dir überlassen.
Ich persönlich hatte auch schon vor, so etwas zu basteln. Und mir bleibt nicht die Zeit und das Tagesgeschäft treibt einen nach Feierabend nicht noch an den PC zum Programmieren.

Obwohl man bei Deinem Projekt schon Bock darauf hat, mit zu machen.

Weitere "Klugtuereien" gebe ich jetzt erstmal nicht mit. Wenns Dir genehm ist mit den Lösungsvorschlägen, bringe ich mich gerne mal da ein.

Grüße,
Gerrit
 
hallo!

jaja - ich sag nur signalling von der lx200 klasse für tcp/ip vs. internem seriellen port :D

aber im ernst - ich freu mich über input, würde aber vorschlagen, dass ich dir entweder eine version für ubuntu xerus zur verfügung stelle - oder ein 16GB raspian image inkl. aller os-installationen. das kannst du dann einfach auf eine sd karte kopieren und in einen pi 3 model b stecken. die phidgets brauchst dafür nicht, die kinetischen parameter sind dann halt blödsinn.

lg
wolfi
 
Zitat von Birki:
was aber mit dem ganzen neuen zeug ein bisserl verlorengeht ist die trickreiche programmiererei :)
Hallo Wolfi,

naja, ich schreibe auch lieber leicht verständlichen und portablen Code, aber zu oft war halt Maschinensprache (hauptsächlich für Interruptcode) unvermeidlich. Bei dem ARMv8 1,2 GHz Quad Core Prozessor des Raspberry PI 3 erübrigt sich jedes Ansinnen in dieser Richtung ohnehin. Das, was für mich momentan noch interessant ist, ist rund 2 Größenordnungen kleiner, etwa ein ARM Cortex-M4 (ARMv7-M instruction set) oder ein Renesas RX (CISC, niedriger Stromverbrauch, kleinstmögliches Chipgehäuse).

LG
Sigi

 
Zuletzt von einem Moderator bearbeitet:
... am ende des tages sind die schmutzigen tricks nie vermeidbar ;)
lg
wolfi
 
Zitat von Birki:
... am ende des tages sind die schmutzigen tricks nie vermeidbar ;)
lg
wolfi

Und die rächen sich dann Monate später auf übelste Art und Weise.

Es gibt nichts, was man in C und C++ nicht auch elegant machen kann.
Selbst die Einbettung von Assembler-Code. Da, wo es wirklich drauf ankommt.

Oftmals kranken viele nicht industrielle Lösungen an schlechten Designs. Und das ist nicht nur eine Philosophiefrage. Auf der anderen Seite kann man nicht erwarten, daß jemand der kaum Software-Engineering-Erfahrung hat, gleich eine gute Architektur aus dem Ärmel purzelt. Es ist immer ein guter Weg eine existierende, funktionale Lösung dann im Laufe der Zeit in ein solides (also auch testbares) Produkt umzuwandeln.

Grüße,
Gerrit
 
Zuletzt von einem Moderator bearbeitet:
hi!
hast schon recht, ich meinte auch nicht "schmutzige" lösungen, sondern die schönen alten tricks, die in der numerik aus zeiten, wo der speicher noch handgestrickt war, gang und gäbe waren.

was die motoren angeht - ich habe heute erste schöne erfolge mit der AccelStepper library am Arduino mit einem Polulu DRV 8825 gehabt, da kann man sicherlich auch den RAPS128 damit ansteuern. die sind halt alle relativ schwach im vergleich zum A4989, aber damit ist dann der weg zu anderen endstufen geebnet, und dann muss man die motorklassen halt verallgemeinern.
lg
wolfi
 
Status
Es sind keine weiteren Antworten möglich.
Oben