[DDL-ML] Re: [DDL-ML] Digitale Modellbahnsteuerung mit Java No.2 - Rückfragen

["Andy" <Andy_P@gmx.de>]

Hallo Torsten,

----- Original Message -----
From: "Torsten Vogt" <vogt@vogt-it.com>

> Lieber Andy, die Handreglerdiskussionen wurden schon zu genuege -
> auch jetzt wieder in Rüdesheim - geführt. Und ganz ehrlich: Der
> FRED ist nicht für alle das optimale Handgerät. Ich selbst könnte
> mit einem Fred im Prinzip nichts anfangen, weil er _meinen_
> Anforderungen nicht gerecht wird. Der von Holger Püschel vorgestellte
> simucopa kommt da schon eher meinen Vorstellungen entgegen.

Ich finde FRED auch nicht ideal, er ist zu spezialisiert für den Modulbahner
denke ich. Die Möglichkeiten der Lenz/Digitrax/*-Handregler ist da
anzustreben, als einfaches (preiswertes) Selbstbauprojekt. Es geht mir auch
nicht um die Mechanik/Funktionalität eines FRED, sondern um die
"Architektur" (ach wie lieben wir dieses Wort...). Soll doch jeder
ranstöpseln können was er will, wenn's denn eine tragfähige skalierbare
Infrastruktur ist. Derzeit sind mir hier nur Konstruktionen bekannt
geworden, die die begrenzten Schnittstellen des PC trickreich ausnutzen,
aber nicht wirklich zuverlässig und erweiterungsfähig sind. Ich stell mir
selbst für eine große Heimanlage durchaus ein halbes Dutzend
FRED-oder-was-auch-immer vor, damit man einfach einen Knopf pro Lok hat und
nicht ständig am rumkonfigurieren/schalten/auswählen ist. Ich sehe den
Selbstbau dabei nicht primär als Sparmöglichkeit an, sondern die Möglichkeit
eben alles selber zu beherrschen. Dabei möchte ich mich aber nicht von
vornherein auf fehlenden Bedienungskomfort festlegen. Die paar Prozent vom
Gesamtanlagenpreis für kommerzielle Regler/Zentralen stehen sonst in keinem
Verhältnis zur Einbuße beim Handling.

> Du beziehst Dich auf das Bild aus Rüdesheim? War ja nur ein Spass, keine
> Machbarkeitsstudie. Dass Mehrfachtraktion grundsätzlich geht, kann man
> schon seit Jahren mit dem Programm J-Man ausprobieren.
Nicht falsch verstehen, klar geht Doppeltraktion (oder Tripeltraktion?). Es
schien mir als Außenstehenden eben nur bezeichnend für die gewälzten
Probleme (der Eindruck mag täuschen). Ich wollte nur vor unserer geliebten
Oase, dem Elfenbeinturm warnen. Da sind wir dabei DAS System schlechthin zu
designen, Server, Middleware, Protokolle vom Feinsten, nur der Benutzer wird
vergessen. Der fragt wie er denn das alles ansteuern soll. Für jeweils zwei
Loks ein PC bei einem Modulbahnertreffen für die Gameport-Handregler? Hm.

> Versteh ich nicht, es funktioniert doch sofort bei den meisten.
Nun, es gibt wohl keine Zahlen wer DDL einsetzt und problemlos die
Installation gemeistert hat (und daher hier nie "auffällig" wurde), sondern
man sieht nur die Problemfälle.
Mein Eindruck ist: erhebliche Abhängigkeiten von Distributionen/Kernels,
"geheimnisvolle" Switches für die eine oder andere DCC-Generatorroutine...
Immer gerne genommen: fehlende Pakete die nachzuinstallieren sind (klar:
Anfängerproblem bzw. RTFM). Solche Abhängigkeiten ließen sich innerhalb
einer Distribution sicherlich lösen. Ich selber habe nur dtcl-tiny und
erddcd zum Laufen gehabt (problemlos :-), aber J-Man etc nicht (irgend ein
Problem mit der Java-RT, bin nicht weiter eingestiegen da ich sowohl J-Man
als auch dtcl-tiny eh nur als Behelf ansehe). Für mich selber sind mir
Distributionen egal: im Zweifel hole ich mir eh Sourcen von sonstwo und
kompiliere selber.

Mit Interesse habe ich immer wieder die Diskussionen über nanosleep() und
ähnliche Abgründe gelesen. Ohne bisher auch nur einen Blick in den Code
geworfen zu haben (Der Rechner rostet in der Ecke vor sich hin, vermutlich
läuft gerade die CMOS-Backup-Batterie aus), frage ich mich ob die
Timingprobleme nicht einfach damit zusammenhängen, daß da von Linux
Realtime-Fähigkeiten gefordert werden die es nur schwer (und
kernelspezifisch) leisten kann. Daher mein Vorschlag zu einem Device
Treiber. Dieser könnte per write() die vorberechneten DCC-Sequenzen bekommen
und ansonsten Idle-Bytes auf die Schiene schicken. Dazu braucht man nicht
einmal einen 16550A, eine hinreichend schlanke Interruptroutine löst's
schon. Wenn geringe Latenzen gewünscht sind muß der Cache eh abgeschaltet
werden.

Andreas