SRCP und Protokollversionen für Lokdekoder

[Andre Schenk]

Hallo SRCP-Entwickler,

seit einigen Tagen überlegen Torsten Vogt und ich, wie man folgendes
Problem am besten löst:

In der aktuellen SRCP-Spec sind für INIT GL sowohl für Märklin/Motorola als
auch für DCC nur jeweils 2 Protokollversionen definiert. Der srcpd versteht
aber M1 - M5 und N1 - N5. Damit mir das besser verständlich wird, habe ich
eine Übersicht erstellt:

http://bonus.dyndns.org/mediawiki/index.php/SRCPD-GenericLocoDevices

Ist die Spec unvollständig oder lassen sich die im echten Leben vorhandenen
Protokollversionen letztlich auf je 2 Versionen zurückführen?

Für DCC mag das gehen, aber was ist mit MM?

Wie kann man das einem User vermitteln, der keine Kenntnis der
DDL-Implementierung im srcpd hat?

--
Tschüß André

[Martin Schoenbeck]

Hallo Andre,

Andre Schenk schrieb:

> Ist die Spec unvollständig oder lassen sich die im echten Leben vorhandenen
> Protokollversionen letztlich auf je 2 Versionen zurückführen?
>
> Für DCC mag das gehen, aber was ist mit MM?

Motorola ist nicht mein Ding, aber für DCC wird man tatsächlich die
verschiedenen Versionen brauchen. Das läßt sich nicht zusammenfassen.

> Wie kann man das einem User vermitteln, der keine Kenntnis der
> DDL-Implementierung im srcpd hat?

Er muß ja nur wissen, wie er seine Lok konfiguriert hat bzw. was für einen
Dekoder die hat. Muß er bei anderen Zentralen auch, wobei die da teilweise
feste Voraussetzungen machen, z.B. die, daß Adressen bis 100 immer mit den
Protokollversionen 1 oder 2 betrieben werden.

Gruß Martin
--
Bitte nicht an der E-Mail-Adresse fummeln, die paßt so.

[Guido Scholz]

Andre Schenk schrieb:

> Hallo SRCP-Entwickler,

Hallo André,

> http://bonus.dyndns.org/mediawiki/index.php/SRCPD-GenericLocoDevices

hier noch eine Ergänzung zu deiner Tabelle: Die Li100 Zentrale von Lenz
unterstützt (seit Firmware Version 3.5) Adresse 0..9999, 128 Fahrstufen
und 1 + 28 Funktionen. Alles wird vom srcpd unterstützt.

Gruß
Guido

--
http://www.bayernline.de/~gscholz/
http://www.lug-burghausen.org/

[Torsten Vogt]

Hallo Andre,

On 14 Jan., 15:23, Andre Schenk <an...@melior.s.bawue.de> wrote:
> http://bonus.dyndns.org/mediawiki/index.php/SRCPD-GenericLocoDevices

ab M2 ist es eigentlich das Motorola 2 Protokoll. Das relevante
Merkmal ist
die Aufnahme der absoluten Fahrtrichtung in jeden Befehl.

Gruß

Torsten

[Torsten Vogt]

Hallo,

On 14 Jan., 17:11, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
wrote:

> > Ist die Spec unvollständig oder lassen sich die im echten Leben vorhandenen
> > Protokollversionen letztlich auf je 2 Versionen zurückführen?
> > Für DCC mag das gehen, aber was ist mit MM?
> Motorola ist nicht mein Ding, aber für DCC wird man tatsächlich die
> verschiedenen Versionen brauchen. Das läßt sich nicht zusammenfassen.

Danke! ;-)

Hier noch ein paar Infos aus meinen Diskussionen mit Andre:

Die derzeit niedergeschriebene SRCP-Spec scheint diesbzgl. derzeit
eher
an der Sicht der Anwender orientiert, aber nicht - wie es IMHO sein
sollte -
an der technischen Umsetzung. So ist es dem Anwender offenbar nur
schwer
begreiflich zu machen, dass z.B. die Dekoder-Adresse 60 (kurze DCC-
Adresse)
und die Dekoder-Adresse 60 (lange DCC-Adresse) eigentlich zwei
verschiedene
Adressen sind. D.h. ein auf lange Adressen eingestellter Dekoder funzt
nicht,
wenn er mit DCC-Paketen für die kurze Adressen gefüttert wird und
umgekehrt.

Mein Vorschlag wäre, die Protokollversionen (M1, .., M5) und (N1, ..,
N5) offiziell
in der SRCP-Spec zu verankern und zwar genauso, wie es ursprünglich
mal war:

N 1: NMRA-DCC, 7Bit-Adr, 28 FS
N 2: NMRA-DCC, 7Bit-Adr, 128 FS
N 3: NMRA-DCC, 14Bit-Adr, 28 FS
N 4: NMRA-DCC, 14Bit-Adr, 128 FS
N 5: NMRA-DCC, Basisprotokoll, 7Bit-Adr, 14 FS

M 1: MM, 80 Adressen, 14 FS, relative Fahrtrichtungsumschaltung
M 2: MM, 80 Adressen, 14 FS, absolute Fahrtrichtungsinfo in jedem
Befehl
M 3: MM, Spezialprotokoll für sog. Wikingerdekoder, 256 Adr, 28 FS
M 4: MM, 256 Adressen, 14 FS, absolute Fahrtrichtungsinfo in jedem
Befehl
M 5: MM, 256(?) Adressen, 28 FS, absolute Fahrtrichtungsinfo in jedem
Befehl

Damit es die Anwender leichter haben, hat Andre dem Programm J-Man
Dekoder-
Definitionsdateien spendiert. Diese werden künftig mit dem Programm
ausgeliefert.
D.h. ein Anwender von J-Man muss künftig nur noch den Dekoder wählen,
den er
verbaut hat und hoffentlich in der Liste findet. Weitere Dekoder-
Definitionen lassen
sich künftig leicht hinzufügen. Vielleicht könnten andere SRCP-Client-
Entwickler
diesen Gedanken auch aufnehmen.

Gruß

Torsten

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> Mein Vorschlag wäre, die Protokollversionen (M1, .., M5) und (N1, ..,
> N5) offiziell
> in der SRCP-Spec zu verankern und zwar genauso, wie es ursprünglich
> mal war:
>
> N 1: NMRA-DCC, 7Bit-Adr, 28 FS
> N 2: NMRA-DCC, 7Bit-Adr, 128 FS
> N 3: NMRA-DCC, 14Bit-Adr, 28 FS
> N 4: NMRA-DCC, 14Bit-Adr, 128 FS
> N 5: NMRA-DCC, Basisprotokoll, 7Bit-Adr, 14 FS
>
> M 1: MM, 80 Adressen, 14 FS, relative Fahrtrichtungsumschaltung
> M 2: MM, 80 Adressen, 14 FS, absolute Fahrtrichtungsinfo in jedem
> Befehl
> M 3: MM, Spezialprotokoll für sog. Wikingerdekoder, 256 Adr, 28 FS
> M 4: MM, 256 Adressen, 14 FS, absolute Fahrtrichtungsinfo in jedem
> Befehl
> M 5: MM, 256(?) Adressen, 28 FS, absolute Fahrtrichtungsinfo in jedem
> Befehl

Finde ich auch sinnvoll.

> Damit es die Anwender leichter haben, hat Andre dem Programm J-Man
> Dekoder-
> Definitionsdateien spendiert. Diese werden künftig mit dem Programm
> ausgeliefert.
> D.h. ein Anwender von J-Man muss künftig nur noch den Dekoder wählen,
> den er
> verbaut hat und hoffentlich in der Liste findet.

Das hilft ihm aber bei DCC-Dekodern nur bedingt. Die meisten aktuellen
Dekoder können alle fünf Protokollvarianten. Da hängt es davon ab, wie er
konfiguriert ist. Wobei 128/28 Fahrstufen nicht konfiguriert wird, sondern
einfach unterschiedliche Befehle sind.

[Andre Schenk]

Guido Scholz <guido....@bayernline.de> schrieb:

> hier noch eine Ergänzung zu deiner Tabelle: Die Li100 Zentrale von Lenz
> unterstützt (seit Firmware Version 3.5) Adresse 0..9999, 128 Fahrstufen
> und 1 + 28 Funktionen. Alles wird vom srcpd unterstützt.

Danke!

--
Tschüß André

[Andre Schenk]

Martin Schoenbeck <ms.usene...@schoenbeck.de> schrieb:

> Motorola ist nicht mein Ding, aber für DCC wird man tatsächlich die
> verschiedenen Versionen brauchen. Das läßt sich nicht zusammenfassen.

die Alternative (zumindest für DCC) wäre, daß die Spec bei N1 und N2 bleibt
und die Auftrennung in die 5 Versionen erst im srcpd intern erfolgt.

14 FS -> N5
28 FS -> N1 oder N3 (je nach Adresse)
128 FS -> N2 oder N4 (je nach Adresse)

Vorteil: Man müßte die Spec nicht ändern.

Nachteil: Man kann nicht mehr sagen, daß man z.B. eine Lok mit
langer Adresse 60 fahren will, weil Adresse 60 vom srcpd als kurze Adresse
interpretiert würde.

>> Wie kann man das einem User vermitteln, der keine Kenntnis der
>> DDL-Implementierung im srcpd hat?

> Er muß ja nur wissen, wie er seine Lok konfiguriert hat bzw. was für einen
> Dekoder die hat.

Könntest Du denn auf Anhieb sagen, weches Nx Du verwenden müßtest, wenn Du
meine Wikiseite nicht kennen würdest?

--
Tschüß André

[Andre Schenk]

Torsten Vogt <vogt_t...@gmx.de> schrieb:

> ab M2 ist es eigentlich das Motorola 2 Protokoll. Das relevante
> Merkmal ist die Aufnahme der absoluten Fahrtrichtung in jeden Befehl.

Habe ich geändert, danke!

--
Tschüß André

[Andre Schenk]

Andre Schenk <an...@melior.s.bawue.de> schrieb:

> 14 FS -> N5
> 28 FS -> N1 oder N3 (je nach Adresse)
> 128 FS -> N2 oder N4 (je nach Adresse)

> Vorteil: Man müßte die Spec nicht ändern.

> Nachteil: Man kann nicht mehr sagen, daß man z.B. eine Lok mit
> langer Adresse 60 fahren will, weil Adresse 60 vom srcpd als kurze Adresse
> interpretiert würde.

nochmal darüber nachgedacht und in den Sourcecode des DDW-Servers geschaut:

Den oben erwähnten Nachteil gibt es eigentlich nicht, wenn man N1 und N2 so
implementiert wie in der Spec beschrieben:

SRCP-N1 : kurze Adresse
SRCP-N2 : lange Adresse

Dann muß der srcpd intern nur die Fahrstufen anschauen.

SRCP-N1: 14 FS -> DDL-N5, 28 FS -> DDL-N1, 128 FS -> DDL-N2
SRCP-N2: 28 FS -> DDL-N3, 128 FS -> DDL-N5

Somit kann ich gar keinen Nachteil erkennen.

Für MM scheint es wohl nicht so einfach zu sein.

--
Tschüß André

[Harald Nikolisin]

Am 15.01.2012 09:37, schrieb Torsten Vogt:


> Hier noch ein paar Infos aus meinen Diskussionen mit Andre:
>
> Die derzeit niedergeschriebene SRCP-Spec scheint diesbzgl. derzeit
> eher
> an der Sicht der Anwender orientiert, aber nicht - wie es IMHO sein
> sollte -
> an der technischen Umsetzung. So ist es dem Anwender offenbar nur
> schwer
> begreiflich zu machen, dass z.B. die Dekoder-Adresse 60 (kurze DCC-
> Adresse)
> und die Dekoder-Adresse 60 (lange DCC-Adresse) eigentlich zwei
> verschiedene
> Adressen sind. D.h. ein auf lange Adressen eingestellter Dekoder funzt
> nicht,
> wenn er mit DCC-Paketen für die kurze Adressen gefüttert wird und
> umgekehrt.
>
> Mein Vorschlag wäre, die Protokollversionen (M1, .., M5) und (N1, ..,
> N5) offiziell
> in der SRCP-Spec zu verankern und zwar genauso, wie es ursprünglich
> mal war:

>

> M 1: MM, 80 Adressen, 14 FS, relative Fahrtrichtungsumschaltung
> M 2: MM, 80 Adressen, 14 FS, absolute Fahrtrichtungsinfo in jedem
> Befehl
> M 3: MM, Spezialprotokoll für sog. Wikingerdekoder, 256 Adr, 28 FS
> M 4: MM, 256 Adressen, 14 FS, absolute Fahrtrichtungsinfo in jedem
> Befehl
> M 5: MM, 256(?) Adressen, 28 FS, absolute Fahrtrichtungsinfo in jedem
> Befehl
>

Hallo,

Wahrscheinlich hast du prinzipiell recht, dass die SRCP Spec nicht dem
Enduser dienen sollte, wobei ich es sehr praktisch finde.
Mangels Anlage mache ich mit srcpd derzeit nur Tests (ad-hoc Aufbauten
steuere ich mit der MS2)
Bei den Tests starte ich den Server, steuere mit telnet und habe auf
einem 2. Monitor die SRCP Spec offen (die sehr verständlich ist).

Der Ansatz mit MM1-MM5 finde ich nicht optimal aus folgenden Gründen:
* die 4 Methoden in srcpd (comp_maerklin_2 - comp_maerklin_5) erzeugen
viel Code-Duplikationen
* der Code widerspricht sich m.E. an manchen Stellen selber - so ist
der Unterschied zwischen M2 und M4 ja nur die Anzahl der Adressen,
welche am Anfang abgeprüft wird - und genau hier steht als Kommentar "no
special error handling, it's job of the clients"

MM2/4/5 könnte man ganz einfach als "M2" zusammenfassen - der Server
übrprüft nur die FS und schaltet bei 28 (aka 27) die M5 Methoden...
...wäre da nicht der "Wikinger Decoder"
Das könnte man allerdings lösen, indem man bei den <optional further
parameters> von INIT GL einen Decoderspezialstring einführt.

Das wäre aus meiner Sicht besser, würde aber viel Aufwand erzeugen (SRCP
Spec ändern, srcpd ändern, J-Man und alle anderen Lok-Clients anpassen).
Ob es das wert ist, kann ich nicht sagen.
Bei deiner Lösung Torsten, könnte man ev. Code-Replikation verhindern,
indem man gemeinsame Methoden anbietet.

Gruß,
Harald

[Harald Nikolisin]

Am 14.01.2012 15:23, schrieb Andre Schenk:
Hallo Andre

>
> In der aktuellen SRCP-Spec sind für INIT GL sowohl für Märklin/Motorola als
> auch für DCC nur jeweils 2 Protokollversionen definiert. Der srcpd versteht
> aber M1 - M5 und N1 - N5. Damit mir das besser verständlich wird, habe ich
> eine Übersicht erstellt:
>
> http://bonus.dyndns.org/mediawiki/index.php/SRCPD-GenericLocoDevices
>

Ich hatte vor kurzem zum ersten Mal in srcpd ein ESU Lok mit srcpd und
DCC angesteuert (direkt mit telnet Kommandos - es war nur ein Test).

Ohne Hintergrundwissen erkannte ich die kurze Adresse und habe ich laut
der SRCP Spec bei INIT GL bei der Protocolversion 1 angegeben (kurze
Adresse las ich aus den CV Registern aus).

Ich hatte 22 Funktionen und 128 FS angegeben - die 22 Funktionen
funktionierten alle (1+8 Funktionen in deiner Tabelle?)
Bei den FS meckerte er die 128 zumindest nicht an - ob er sie alle
ausführen konnte kann ich aber nicht sagen - bis 28 hab ich es nicht
probiert.

Gruß,
Harald

[Martin Schoenbeck]

Hallo Andre,

Andre Schenk schrieb:

> nochmal darüber nachgedacht und in den Sourcecode des DDW-Servers geschaut:
>
> Den oben erwähnten Nachteil gibt es eigentlich nicht, wenn man N1 und N2 so
> implementiert wie in der Spec beschrieben:
>
> SRCP-N1 : kurze Adresse
> SRCP-N2 : lange Adresse
>
> Dann muß der srcpd intern nur die Fahrstufen anschauen.
>
> SRCP-N1: 14 FS -> DDL-N5, 28 FS -> DDL-N1, 128 FS -> DDL-N2
> SRCP-N2: 28 FS -> DDL-N3, 128 FS -> DDL-N5
>
> Somit kann ich gar keinen Nachteil erkennen.

Du hast völlig recht. Ich hatte nicht mehr im Kopf, daß beim INIT auch die
Zahl der Fahrstufen und Funktionen angegeben wird. Eine Implementation mit
N3 - N5 widerspricht also der Spezifikation.

[Andre Schenk]

Harald Nikolisin <harald.n...@mnet-online.de> schrieb:

> Ich hatte 22 Funktionen und 128 FS angegeben - die 22 Funktionen
> funktionierten alle (1+8 Funktionen in deiner Tabelle?)
> Bei den FS meckerte er die 128 zumindest nicht an - ob er sie alle
> ausführen konnte kann ich aber nicht sagen - bis 28 hab ich es nicht
> probiert.

Torsten hat inzwischen mehr Checks in den srcpd eingebaut, so daß N1 beim
INIT GL nur noch 28 FS erlaubt.

--
Tschüß André

[Torsten Vogt]

On 15 Jan., 13:38, Harald Nikolisin <harald.nikoli...@mnet-online.de>
wrote:

> Das wäre aus meiner Sicht besser, würde aber viel Aufwand erzeugen (SRCP
> Spec ändern, srcpd ändern, J-Man und alle anderen Lok-Clients anpassen).
> Ob es das wert ist, kann ich nicht sagen.

Nein, das ist es IMHO nicht. An dem ganzen Kram ändert sich sowieso
nichts mehr.

> Bei deiner Lösung Torsten, könnte man ev. Code-Replikation verhindern,
> indem man gemeinsame Methoden anbietet.

Wie es intern in einem speziellen SRCP-Server implementiert ist,
sollte
im Rahmen _dieser_ Diskussion keine Rolle spielen. Ich halte es auch
für unwahrscheinlich, dass hier nochmal jemand Hand anlegt. Der
vorhandene Code funktoniert und Änderungen an MM wird es künftig
nicht mehr geben.

Gruß

Torsten

[Torsten Vogt]

On 15 Jan., 12:23, Andre Schenk <an...@melior.s.bawue.de> wrote:
> Vorteil: Man müßte die Spec nicht ändern.

Wieso ist das ein Vorteil?

> Nachteil: Man kann nicht mehr sagen, daß man z.B. eine Lok mit
> langer Adresse 60 fahren will, weil Adresse 60 vom srcpd als kurze Adresse
> interpretiert würde.

Ich habe Dir ja bereits per PM geschrieben, dass ich das für
eine völlig unnötige Einschränkung halte. Die Adressen 1 .. 127
existieren in DCC schlicht und einfach zweimal und beide
Varianten sind korrekt.

> Könntest Du denn auf Anhieb sagen, weches Nx Du verwenden müßtest, wenn Du
> meine Wikiseite nicht kennen würdest?

Das muss er doch gar nicht. Er weiss, dass er den Dekoder xyz hat,
diesen
mit kurzen Adressen und 128 FS betreiben will. In den Dekoder-
Definitionsdateien
zu diesem Dekoder, die es dann halt pro Dekoder 5x geben muss, steht
das
richtige Nx (oder Mx) drin. Wenn Dir 5 Dekoderdateien pro Dekoder
nicht gefallen,
dann müssen wir das XML-Beschreibungsformat der Dekoder-Def. ändern,
so dass man mit einer Datei auskommt.

Gruß

Torsten

[Torsten Vogt]

Hallo,

ich stelle hier mal zusammen, was ich mir wünschen würde:

1. Das SRCP transportiert Protokoll (N,M, ....) und Protokollversion
(1, 2, ...)
vom Client zum Server.

D. h. falls es derzeit Einschränkungen im SRCP bzgl. der
Protokollversion
gibt, sollten wir die aufbrechen.

2. Es wird im SRCP definiert, was unter den Kombinationen Protokoll
_und_ Pr.Version
verstanden wird.

Also inhaltlich etwa das, was in Andre's Wiki steht.

3. Wie der Client pro Dekoder auf die richtige Kombination kommt, ist
Sache
des Client. Z.B. in dem er Wissen vom User abfrägt, in dem es
Dekoder-Def.-
Dateien gibt oder in dem der Client irgendein Voodoo aus den
Benutzereingaben
durchführt, um Protokoll + Version zu erraten. Auf jeden Fall
sendet der
Client via SRCP die korrekte Kombination zum Server beim INIT.

4. Der Server macht auf gar keinen Fall eine Auswertung bzgl.
Protokoll und
Version. Ausnahme: Protokoll 'P' ('protocol by server')

Gruß

Torsten

[Andre Schenk]

Torsten Vogt <vogt_t...@gmx.de> schrieb:

>> Vorteil: Man müßte die Spec nicht ändern.

> Wieso ist das ein Vorteil?

Vorhandene Implementierungen (Server wie Clients) müssen nicht geändert
werden, sofern sie sich an die Spec halten. :-)

>> Nachteil: Man kann nicht mehr sagen, daß man z.B. eine Lok mit
>> langer Adresse 60 fahren will, weil Adresse 60 vom srcpd als kurze Adresse
>> interpretiert würde.

> Ich habe Dir ja bereits per PM geschrieben, dass ich das für
> eine völlig unnötige Einschränkung halte. Die Adressen 1 .. 127
> existieren in DCC schlicht und einfach zweimal und beide
> Varianten sind korrekt.

Den Nachteil gibt es gar nicht, ist mir leider erst später klargeworden.

>> Könntest Du denn auf Anhieb sagen, weches Nx Du verwenden müßtest, wenn Du
>> meine Wikiseite nicht kennen würdest?

> Das muss er doch gar nicht. Er weiss, dass er den Dekoder xyz hat,
> diesen
> mit kurzen Adressen und 128 FS betreiben will. In den Dekoder-

> Definitionsdateien [...]

Jetzt bist Du gedanklich aber bei j-man. Andere SRCP-Clients haben
vielleicht keine solche Dekoderdateien.

--
Tschüß André

[Torsten Vogt]

On 15 Jan., 16:06, Andre Schenk <an...@melior.s.bawue.de> wrote:
> Vorhandene Implementierungen (Server wie Clients) müssen nicht geändert
> werden, sofern sie sich an die Spec halten. :-)

Das hängt also davon ab, was man höher bewertet .....

> Den Nachteil gibt es gar nicht, ist mir leider erst später klargeworden.

Du meinst, weil N1 und N2 genau dies regelt? Und bzgl. Fahrstufen soll
der Server aus den Angaben beim INIT entscheiden? IMHO ist das die
zweitbeste Lösung.

> Jetzt bist Du gedanklich aber bei j-man. Andere SRCP-Clients haben
> vielleicht keine solche Dekoderdateien.

Wie an anderer Stelle geschrieben, ist es mir eigentlich egal,
wieweit der Client(!) dies vor dem Anwender verbirgt, oder nicht.
Die Dekoder-Dateien wären _eine_ Möglichkeit.

Gruß

Torsten

[Andre Schenk]

Torsten Vogt <vogt_t...@gmx.de> schrieb:

>> Vorhandene Implementierungen (Server wie Clients) müssen nicht geändert
>> werden, sofern sie sich an die Spec halten. :-)

> Das hängt also davon ab, was man höher bewertet .....

Stimmt!

>> Den Nachteil gibt es gar nicht, ist mir leider erst später klargeworden.

> Du meinst, weil N1 und N2 genau dies regelt? Und bzgl. Fahrstufen soll
> der Server aus den Angaben beim INIT entscheiden?

Das ist meine Idealvorstellung.

Die Frage ist ja auch: Gewinnt der Anwender etwas, wenn er beim INIT GL
zwischen 5 Protokollversionen unterscheiden kann? Zumindest für DCC meine
ich, es bringt ihm nichts.

--
Tschüß André

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> Hallo,
>
> ich stelle hier mal zusammen, was ich mir wünschen würde:
>
> 1. Das SRCP transportiert Protokoll (N,M, ....) und Protokollversion
> (1, 2, ...)
> vom Client zum Server.
>
> D. h. falls es derzeit Einschränkungen im SRCP bzgl. der
> Protokollversion
> gibt, sollten wir die aufbrechen.

Aber nicht ohne Not. Bei DCC gibt's die Not nicht, also sollten wir das
auch nicht ändern. Der Client sollte sich darauf verlassen dürfen, daß wenn
er dem SRCP-Server mitteilt, diese Lok hab Adresse 74, N2, 128 Fahrstufen,
8 Funktionen, der SRCP-Server die Lok dann auch korrekt mit langen Adressen
ansteuert und _nicht_ darauf besteht, daß man ihm ein N4 meldet. Denn nur
so kann ist die Unabhängigkeit vom konkreten SRCP-Server gewährleistet.
Wenn da jeder nach eigenem Gusto die Protokollversionen implementiert, sind
die Clients eben nicht mehr vom Server unabhängig. Dann brauchen wir aber
auch kein SRCP.

> 2. Es wird im SRCP definiert, was unter den Kombinationen Protokoll
> _und_ Pr.Version
> verstanden wird.
>
> Also inhaltlich etwa das, was in Andre's Wiki steht.

Ist ja schon definiert. Zumindest für DCC eindeutig und ausreichend.

> 3. Wie der Client pro Dekoder auf die richtige Kombination kommt, ist
> Sache
> des Client. Z.B. in dem er Wissen vom User abfrägt, in dem es
> Dekoder-Def.-
> Dateien gibt oder in dem der Client irgendein Voodoo aus den
> Benutzereingaben
> durchführt, um Protokoll + Version zu erraten. Auf jeden Fall
> sendet der
> Client via SRCP die korrekte Kombination zum Server beim INIT.

Aber die sollte unabhängig vom Server sein. Wenn der Client den Benutzer
gefragt hat, der ihm gesagt hat, daß der Dekoder lange Adressen hat und mit
128 Fahrstufen arbeiten soll, dann soll das bitte in allen SRCP zur
richtigen Ansteuerung führen. Oder zu einer Fehlermeldung, wenn die
Kombination nicht möglich ist (z.B. Adresse 74 und N2 bei den meisten
Zentralen).

> 4. Der Server macht auf gar keinen Fall eine Auswertung bzgl.
> Protokoll und
> Version. Ausnahme: Protokoll 'P' ('protocol by server')

Was verstehst Du darunter? Natürlich muß er die Protokollangabe auswerten,
wie soll er sonst wissen, wie er zu steuern hat.

[Torsten Vogt]

On 15 Jan., 20:09, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
wrote:

> Aber nicht ohne Not. Bei DCC gibt's die Not nicht, also sollten wir das
> auch nicht ändern. Der Client sollte sich darauf verlassen dürfen, daß wenn
> er dem SRCP-Server mitteilt, diese Lok hab Adresse 74, N2, 128 Fahrstufen,
> 8 Funktionen, der SRCP-Server die Lok dann auch korrekt mit langen Adressen
> ansteuert und _nicht_ darauf besteht, daß man ihm ein N4 meldet. Denn nur
> so kann ist die Unabhängigkeit vom konkreten SRCP-Server gewährleistet.
> Wenn da jeder nach eigenem Gusto die Protokollversionen implementiert, sind
> die Clients eben nicht mehr vom Server unabhängig. Dann brauchen wir aber
> auch kein SRCP.

Ich verstehe die Argumentation nicht. Ich kann mich notfalls damit
anfreunden,
dass es "nur" zwei N's gibt, wobei dann der Server die Entscheidung
trifft,
ob DCC-Pakete für 28 Fahrstufen oder 128 FS erzeugt werden. Ich weiss
nicht, wo die Idee herkommt, dass "jeder nach eigenem Gusto" irgendwas
implememtieren soll oder kann. Ob jetzt zwei N's oder fünf N's im SRCP
definiert sind, erweitert die Freiheitsgrade für einen
Serverentwickler nicht.
Der einzige Unterschied ist, dass bei zwei N's der Server
Entscheidungen
bzgl. Art der zu generierenden DCC-Pakete trifft und dabei die FS-Info
beim INIT auswertet, implizite Logik also. Warum? Weil wir zu faul
sind,
zwei Sätze in die SRCP-Spec zu schreiben? Auch die Änderungen, die
dies bei der vorhandenen Software nach sich ziehen würde sind
marginal.

> > 2. Es wird im SRCP definiert, was unter den Kombinationen Protokoll
> > _und_ Pr.Version
> >     verstanden wird.
>
> >     Also inhaltlich etwa das, was in Andre's Wiki steht.
>
> Ist ja schon definiert. Zumindest für DCC eindeutig und ausreichend.

Offenbar nicht, sonst würden wir jetzt nicht diskutieren.

> Aber die sollte unabhängig vom Server sein. Wenn der Client den Benutzer
> gefragt hat, der ihm gesagt hat, daß der Dekoder lange Adressen hat und mit
> 128 Fahrstufen arbeiten soll, dann soll das bitte in allen SRCP zur
> richtigen Ansteuerung führen. Oder zu einer Fehlermeldung, wenn die
> Kombination nicht möglich ist (z.B. Adresse 74 und N2 bei den meisten
> Zentralen).

Aha. Du weisst, dass der ursprüngliche DDL-Server (erddcd) z.B. die
Adresse 74 dreimal ansteuern konnte? Ich persönlich fand dies
praktisch. So hatten meine beiden V60 die Adresse 60, einmal DCC-kurz,
einmal DCC-lang. Die Adresse 60 für MM war sogar noch frei .... ;-)
Der srcpd erlaubt dies nicht. Jede Adresse kann dort
nur einmal vorkommen. Jetzt lese ich hier, dass einige DCC-Zentralen
nicht mal in der Lage sind, Adressen unter 128 als lange Adressen
zu verwenden. Nun gut, aber was können wir für die Faulheit der
Programmierer? Konkret heisst das doch, dass der srcp-Server wissen
muss, was die Zentrale oder die Software-Zentrale kann. Beim srcpd
heisst das: Benutze ich DDL, dann geht eben Adresse 74 auch DCC-lang,
benutze ich einer der "meisten Zentralen", dann geht es eben nicht.
Das ist im Prinzip auch kein Problem, da jedes srcpd-Backend eigene
INIT-Callbacks hat, in denen das geregelt werden kann.
Soll sich nun jedes srcpd-Backend den Restriktionen der "meisten
Zentralen" unterwerfen?

Kommen wir zu den N's zurück: Möglicherweise ist zur Entwicklung
eines "meiste Zentralen"-Backends innerhalb des srcpd gar keine
Entscheidung bzgl. 28 und 128 Fahrstufen zu treffen, weil
das sowieso die Hardware der Zentrale übernimmt. Und
möglicherweise ist genau das der Grund, warum N3, N4 und N5 den
Übergang von SRCP 0.7 zu 0.8 nicht überlebt haben: Weil es
unnötig erschien. Für DDL ist es aber nur dann unnötig, wenn
man den Server ermächtigt, zu entscheiden. Warum ich das
für schlecht halte, steht weiter unten.

> > 4. Der Server macht auf gar keinen Fall eine Auswertung bzgl.
> > Protokoll und
> >     Version. Ausnahme: Protokoll 'P' ('protocol by server')
>
> Was verstehst Du darunter? Natürlich muß er die Protokollangabe auswerten,
> wie soll er sonst wissen, wie er zu steuern hat.

Mein Vorschlag besagt: Werte Protokoll und Protokollversion aus, das
reicht. SRCP verlangt aber, dass bei DCC auch die Anzahl der
Fahrstufen
beim INIT ausgewertet werden. Oder - wie Harald andeutete - bei
Mäklin
sollen sogar max. mögliche Adresse und Anzahl der FS zur Protokollwahl
herhalten. Nur zwischen den Versionen, bei denen das nicht geht, wird
mit dem Versions-Parameter geholfen. IMHO bedeutet "Ich kann nicht
zwischen ein _paar_ Versionen unterscheiden", dass ich _alle_
Versionen
spezifiziere. Und nicht mal rate und mal was gesagt bekomme.

Das ist der Grund, warum ich nach wie vor für die Aufnahme von
N1 ..., N5 in die SRCP-Spec. votiere und der MM-Kram bei
M1 ... M5 bestehen bleibt,.

Gruß

Torsten

[Guido Scholz]

Torsten Vogt schrieb:

> Hallo,

Hallo Torsten,

> ich stelle hier mal zusammen, was ich mir wünschen würde:

> 1. Das SRCP transportiert Protokoll (N,M, ....) und Protokollversion
> (1, 2, ...)
> vom Client zum Server.

wenn ich die Zusammenhänge richtig verstanden habe, dann macht die
Erweiterung bei MM auf 1..5 wohl Sinn; bei DCC sollte eher 1..2 reichen.
Für die Differenzierung aufgrund von unterschiedlichen Fahrstufen- oder
Funktionszahlen scheint es bei DCC keinen zwingenden Hardwaregrund zu
geben.

> D. h. falls es derzeit Einschränkungen im SRCP bzgl. der
> Protokollversion
> gibt, sollten wir die aufbrechen.

Apropos "Einschränkungen": Beim Einlesen ist mir gerade aufgefallen, das
SRCP es nicht erlaubt, unter DCC eine GL mit kurzer Adresse 60 und eine
weitere mit langer Adresse 60 auf dem gleichen Bus zu betreiben. Das war
mir so noch nicht klar. Ursache ist die Indentifizierung anhand der
Adresse (statt einer eigenen ID).

Im Falle der derzeitigen DDL-Implementierung ist es zusätzlich nicht
möglich, eine dritte GL mit Adresse 60 im MM-Format auf dem gleichen Bus
zu betreiben, obwohl die Hardwareimplementierung das hergeben würde.

Gibt es dafür Lösungsvorschläge? Gut, MM und DCC könnte man auf
getrennte Busse legen, aber das DCC-Adressproblem löst man damit nicht.

> 2. Es wird im SRCP definiert, was unter den Kombinationen Protokoll
> _und_ Pr.Version
> verstanden wird.
>
> Also inhaltlich etwa das, was in Andre's Wiki steht.

Macht Sinn, damit es verständlich wird.

> 3. Wie der Client pro Dekoder auf die richtige Kombination kommt, ist
> Sache
> des Client. Z.B. in dem er Wissen vom User abfrägt, in dem es
> Dekoder-Def.-
> Dateien gibt oder in dem der Client irgendein Voodoo aus den
> Benutzereingaben
> durchführt, um Protokoll + Version zu erraten. Auf jeden Fall
> sendet der
> Client via SRCP die korrekte Kombination zum Server beim INIT.

Würde ich auch so sehen.

> 4. Der Server macht auf gar keinen Fall eine Auswertung bzgl.
> Protokoll und
> Version. Ausnahme: Protokoll 'P' ('protocol by server')

Das verstehe ich jetzt nicht. Meiner Meinung nach sollten z.B. die
zulässigen Adressbereiche überprüft werden.

Übrigens bin ich auch auf die fehlerhafte Implementierung von N2 bis N5 im
srcpd gefunden. Die Protokollversion wird in "ddl.c" Zeilen 1403ff
anders interpretiert, als in ddl_nmra.c Zeile 1154ff. N2 kann man somit
derzeit nicht mit wirklich langen (großen) Adressen nutzen.

[Andre Schenk]

Torsten Vogt <vogt_t...@gmx.de> schrieb:

> Kommen wir zu den N's zurück: Möglicherweise ist zur Entwicklung
> eines "meiste Zentralen"-Backends innerhalb des srcpd gar keine
> Entscheidung bzgl. 28 und 128 Fahrstufen zu treffen, weil
> das sowieso die Hardware der Zentrale übernimmt. Und
> möglicherweise ist genau das der Grund, warum N3, N4 und N5 den
> Übergang von SRCP 0.7 zu 0.8 nicht überlebt haben: Weil es
> unnötig erschien.

Ist denn DDL nicht so etwas wie eine "Software-Zentrale"? Warum dürfen die
"Hardware-Zentralen" Entscheidungen bzgl. der FS treffen, DDL aber nicht?

> Das ist der Grund, warum ich nach wie vor für die Aufnahme von
> N1 ..., N5 in die SRCP-Spec. votiere

Ich würde es bestimmt verstehen, wenn Du mir ein Beispiel nennst, bei dem
N1 und N2 nicht ausreichen.

> und der MM-Kram bei M1 ... M5 bestehen bleibt,.

Na ja, auch hier wäre die Spec. anzupassen, da sie nur M1 und M2 vorsieht.

--
Tschüß André

[Andre Schenk]

Guido Scholz <guido....@bayernline.de> schrieb:

> Apropos "Einschränkungen": Beim Einlesen ist mir gerade aufgefallen, das
> SRCP es nicht erlaubt, unter DCC eine GL mit kurzer Adresse 60 und eine
> weitere mit langer Adresse 60 auf dem gleichen Bus zu betreiben. Das war
> mir so noch nicht klar. Ursache ist die Indentifizierung anhand der
> Adresse (statt einer eigenen ID).

Danke Guido, jetzt ist mir auch klar, warum DDW 3 Busse dafür vorsieht:
einer für MM, einer für DCC kurz und einer für DCC lang. Dort kann man also
eine Adresse dreimal vergeben.

Nun würde ich gleich nachschieben, beim srcpd einfach 3 DDL-Busse zu
definieren, wenn man dieses Feature unbedingt braucht, aber von Torsten
weiß ich, daß das im Moment nicht geht.

--
Tschüß André

[Torsten Vogt]

On 15 Jan., 22:45, Guido Scholz <guido.sch...@bayernline.de> wrote:
> wenn ich die Zusammenhänge richtig verstanden habe, dann macht die
> Erweiterung bei MM auf 1..5 wohl Sinn; bei DCC sollte eher 1..2 reichen.
> Für die Differenzierung aufgrund von unterschiedlichen Fahrstufen- oder
> Funktionszahlen scheint es bei DCC keinen zwingenden Hardwaregrund zu
> geben.

Ich habe bereits an anderer Stelle erläutert, warum es _IMHO_
auch bei DCC nicht reicht. Sieh es als dokumentarorische Hilfe,
wenn es fünf N's gibt (damit künftig dieses Diskussionen ausbleiben).
Dass es pragmatisch auch mit zwei N's geht, ist mir klar.
Wenn bei MM tatsächlich nur 2 Versionen im SRCP definiert sind,
sollte dies auf jeden Fall nachgebessert werden. Hier wäre die
Nachbesserung ja auf jeden Fall abwärtskompatibel, also
unproblematisch.

> Apropos "Einschränkungen": Beim Einlesen ist mir gerade aufgefallen, das
> SRCP es nicht erlaubt, unter DCC eine GL mit kurzer Adresse 60 und eine
> weitere mit langer Adresse 60 auf dem gleichen Bus zu betreiben. Das war
> mir so noch nicht klar. Ursache ist die Indentifizierung anhand der
> Adresse (statt einer eigenen ID).

Mann, Guido! Diese Diskussion hatten wir vor drei oder vier Jahren
schon mal. Damals war Dir das sehr wohl klar. ;-) Du hast mich
davon überzeugt, dass ich damit leben muss. Eine meiner V60 fährt
seitdem mit Adresse 61 ;-(.

> Im Falle der derzeitigen DDL-Implementierung ist es zusätzlich nicht
> möglich, eine dritte GL mit Adresse 60 im MM-Format auf dem gleichen Bus
> zu betreiben, obwohl die Hardwareimplementierung das hergeben würde.
>
> Gibt es dafür Lösungsvorschläge? Gut, MM und DCC könnte man auf
> getrennte Busse legen, aber das DCC-Adressproblem löst man damit nicht.

Kann man im Moment leider nicht. Mit dem "DCC-Problem" habe ich mich
abgefunden. Zumindest damit, dass es auf einer Anlage keine gleichen
DCC-Adressen geben kann. Nicht damit, dass es unter 128 keine "langen"
Adressen geben darf.

>
> > 2. Es wird im SRCP definiert, was unter den Kombinationen Protokoll
> > _und_ Pr.Version
> >     verstanden wird.
>
> >     Also inhaltlich etwa das, was in Andre's Wiki steht.
> Macht Sinn, damit es verständlich wird.

Oha!

> > 3. Wie der Client pro Dekoder auf die richtige Kombination kommt, ist
> > Sache
> >     des Client. Z.B. in dem er Wissen vom User abfrägt, in dem es
> > Dekoder-Def.-
> >     Dateien gibt oder in dem der Client irgendein Voodoo aus den
> > Benutzereingaben
> >     durchführt, um Protokoll + Version zu erraten. Auf jeden Fall
> > sendet der
> >     Client via SRCP die korrekte Kombination zum Server beim INIT.
>
> Würde ich auch so sehen.

Juchu!

>
> > 4. Der Server macht auf gar keinen Fall eine Auswertung bzgl.
> > Protokoll und
> >     Version. Ausnahme: Protokoll 'P' ('protocol by server')
>
> Das verstehe ich jetzt nicht. Meiner Meinung nach sollten z.B. die
> zulässigen Adressbereiche überprüft werden.

Meinetwegen um unzulässige Werte der Parameter zu erkennen, ja.
Aber nicht, um über N? oder M? zu entscheiden.

> Übrigens bin ich auch auf die fehlerhafte Implementierung von N2 bis N5 im
> srcpd gefunden. Die Protokollversion wird in "ddl.c" Zeilen 1403ff
> anders interpretiert, als in ddl_nmra.c Zeile 1154ff. N2 kann man somit
> derzeit nicht mit wirklich langen (großen) Adressen nutzen.

Ach? ;-) Und N3, N4 und N5 gibt es eigentlich nur in meinem Patch vom
letztn Samstag
(der Dir zu zur Verfügung steht. Trotzdem fahren drei meiner Loks mit
N3 schon
seit drei Jahren. Naja, da wir jetzt wieder im Code drin stecken
sollte
eine saubere Lösung - nachdem hier eine Entscheidung gefallen ist -
hinbekommen.

Gruß

Torsten

[Torsten Vogt]

On 16 Jan., 06:04, Andre Schenk <an...@melior.s.bawue.de> wrote:
> Ist denn DDL nicht so etwas wie eine "Software-Zentrale"? Warum dürfen die
> "Hardware-Zentralen" Entscheidungen bzgl. der FS treffen, DDL aber nicht?

Wenn es nach mir ginge, dürften es die HW-Zentralen auch nicht.

> Ich würde es bestimmt verstehen, wenn Du mir ein Beispiel nennst, bei dem
> N1 und N2 nicht ausreichen.

Das gibt es in diesem Fall leider nicht. Aber bei den M's (s.u.)
Ich bin aber ein Vertreter davon, dass man es überall gleich machen
sollte. Das erleichtert das Verstehen. Sonderlocken sind immer
für Fehler zuständig.

> > und der MM-Kram bei M1 ... M5 bestehen bleibt,.
> Na ja, auch hier wäre die Spec. anzupassen, da sie nur M1 und M2 vorsieht.

Ja, bitte. Hier geht es ja gar nicht anders.

Gruß

Torsten

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> On 15 Jan., 20:09, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
> wrote:
>> Aber nicht ohne Not. Bei DCC gibt's die Not nicht, also sollten wir das
>> auch nicht ändern. Der Client sollte sich darauf verlassen dürfen, daß wenn
>> er dem SRCP-Server mitteilt, diese Lok hab Adresse 74, N2, 128 Fahrstufen,
>> 8 Funktionen, der SRCP-Server die Lok dann auch korrekt mit langen Adressen
>> ansteuert und _nicht_ darauf besteht, daß man ihm ein N4 meldet. Denn nur
>> so kann ist die Unabhängigkeit vom konkreten SRCP-Server gewährleistet.
>> Wenn da jeder nach eigenem Gusto die Protokollversionen implementiert, sind
>> die Clients eben nicht mehr vom Server unabhängig. Dann brauchen wir aber
>> auch kein SRCP.
>
> Ich verstehe die Argumentation nicht.

Nun, wenn es SRCP-Server gibt, die die N1 und N2 nicht wie in der
Spezifikation beschrieben implementieren, dann _ist_ das doch eine
Implementation nach eigenem Gusto. Selbst dann, wenn es mehrere gibt, die
das wiederum gleich machen. Und sie sind dann zu einem, der es nach
Spezifikation implementiert, nicht kompatibel. Was sie aber sein sollten,
denn das ist ja die Idee hinter SRCP.

> Ich kann mich notfalls damit
> anfreunden,
> dass es "nur" zwei N's gibt, wobei dann der Server die Entscheidung
> trifft,
> ob DCC-Pakete für 28 Fahrstufen oder 128 FS erzeugt werden.

So steht's in der Spezifikation. Ich denke, wir haben das damals gründlich
überlegt, bevor wir zu diesem Ergebnis gekommen sind.

> Ich weiss
> nicht, wo die Idee herkommt, dass "jeder nach eigenem Gusto" irgendwas
> implememtieren soll oder kann.

Man kann es natürlich immer. Man hat aber eben auch.

> Ob jetzt zwei N's oder fünf N's im SRCP
> definiert sind, erweitert die Freiheitsgrade für einen
> Serverentwickler nicht.

Doch, im letzteren Fall hat er die Freiheit, einen Nx, der 28 Fahrstufen
vorsieht, bei einer Angabe von 128 Fahrstufen abzulehnen, die 128
Fahrstufen zu ignorieren oder jeweils umzurechnen. Damit sich das halbwegs
vorhersehbar verhält, müßte man also auch das wieder in die Spezifikation
schreiben. Wobei das Umrechnen durch die "maximum speed"-Angabe im SET GL
erledigt und ignorieren eigentlich keine Option ist. Bleibt also die
redundante Angabe, die wenn falsch abgelehnt wird. Finde ich wenig
überzeugend.

> Der einzige Unterschied ist, dass bei zwei N's der Server
> Entscheidungen
> bzgl. Art der zu generierenden DCC-Pakete trifft und dabei die FS-Info
> beim INIT auswertet, implizite Logik also.

Wieso "implizite Logik"? Wofür ist denn die Fahrstufenzahl im INIT drin,
wenn der Server sie nicht auswerten soll? Und wofür sonst soll er sie
auswerten, wenn nicht, um die Lok passend anzusteuern?

> Warum? Weil wir zu faul
> sind,
> zwei Sätze in die SRCP-Spec zu schreiben? Auch die Änderungen, die
> dies bei der vorhandenen Software nach sich ziehen würde sind
> marginal.

Glaubst Du wirklich, das hat was mit Faulheit zu tun? Man könnte jetzt die
damalige Diskussion nachlesen, aber ich bin mir sicher, daß das ganz bewußt
so und nicht anders spezifiert wurde. Wenn Faulheit, dann könnte man die
höchstens bei den Programmierern irgendwelcher SRCPDs vermuten, die nicht
extra zwei Werte heranziehen wollen (Nx und Fahrstufen) um zu einer
internen Variante zu kommen. Aber wie Du schon schriebst: die Änderungen
sind marginal, so daß ich das auch nicht glaube. Von daher wäre die
sinnvollste Lösung, diese Änderungen in den fehlerhaft programmierten
SRCPDs gerade umzusetzen und alles paßt wieder zusammen.

>>> 2. Es wird im SRCP definiert, was unter den Kombinationen Protokoll
>>> _und_ Pr.Version
>>>     verstanden wird.
>>
>>>     Also inhaltlich etwa das, was in Andre's Wiki steht.
>>
>> Ist ja schon definiert. Zumindest für DCC eindeutig und ausreichend.
>
> Offenbar nicht, sonst würden wir jetzt nicht diskutieren.

Offenbar wurde es vereinzelt falsch verstanden. Oder war vielleicht falsch
oder gar nicht mehr im Gedächtnis. Wenn man aber die SRCP-Spezifikation vor
sich hat, ist es klar und eindeutig.

>> Aber die sollte unabhängig vom Server sein. Wenn der Client den Benutzer
>> gefragt hat, der ihm gesagt hat, daß der Dekoder lange Adressen hat und mit
>> 128 Fahrstufen arbeiten soll, dann soll das bitte in allen SRCP zur
>> richtigen Ansteuerung führen. Oder zu einer Fehlermeldung, wenn die
>> Kombination nicht möglich ist (z.B. Adresse 74 und N2 bei den meisten
>> Zentralen).
>
> Aha. Du weisst, dass der ursprüngliche DDL-Server (erddcd) z.B. die
> Adresse 74 dreimal ansteuern konnte? Ich persönlich fand dies
> praktisch.

Sicher weiß ich das. Aber meine Lenz-Zentrale kann das beispielsweise
nicht. Und ein SRCPD, der diese Zentrale ansteuert, von dem würde ich mir
wünschen, daß er mir auf die Finger klopft, wenn ich ihm sage, er solle die
lange Adresse 74 ansteuern. Wenn der SRCPD es hingegen kann, dann soll er
es tun. Was er aber nicht tun soll, ist, die Lok mit der _langen_ Adresse
74 ansteuern. Was aber der SRCPD tut, für den die Liste von André paßt.

> So hatten meine beiden V60 die Adresse 60, einmal DCC-kurz,
> einmal DCC-lang. Die Adresse 60 für MM war sogar noch frei .... ;-)
> Der srcpd erlaubt dies nicht. Jede Adresse kann dort
> nur einmal vorkommen.

Wenn die Hardware beides kann, finde ich es persönlich doof, wenn die
Software das abschneidet. Aber das kann man unterschiedlich sehen und ist
letztlich eine Designentscheidung.

> Jetzt lese ich hier, dass einige DCC-Zentralen
> nicht mal in der Lage sind, Adressen unter 128 als lange Adressen
> zu verwenden. Nun gut, aber was können wir für die Faulheit der
> Programmierer?

Das hat mit Sicherheit nichts mit Faulheit zu tun. Sondern damit, daß der
Otto-Normal-Bediener einfach nicht versteht, daß es hier unterschiedliche
Längen gibt. Der sagt seiner Zentrale "programmier die Lok auf Adresse xy"
und dann macht die Zentrale das. Allenfalls kann man ihm noch klarmachen,
daß an bestimmten Zentralen nur Adressen bis 100 oder 127 gehen und dann
wird die Zentrale, die mehr kann, bei solchen Adressen kurze Adressen
vergeben, so daß die Loks auch an solchen Zentralen laufen, die lange
Adressen nicht können.

> Konkret heisst das doch, dass der srcp-Server wissen
> muss, was die Zentrale oder die Software-Zentrale kann.

Das empfiehlt sich aus meiner Sicht ohnehin ganz stark.

> Beim srcpd
> heisst das: Benutze ich DDL, dann geht eben Adresse 74 auch DCC-lang,
> benutze ich einer der "meisten Zentralen", dann geht es eben nicht.

Das wäre meine Lösung. Allenfalls noch einen Konfigurationsswitch, mit dem
man ihn kastrieren kann.

> Das ist im Prinzip auch kein Problem, da jedes srcpd-Backend eigene
> INIT-Callbacks hat, in denen das geregelt werden kann.
> Soll sich nun jedes srcpd-Backend den Restriktionen der "meisten
> Zentralen" unterwerfen?

Nöö.

> Kommen wir zu den N's zurück: Möglicherweise ist zur Entwicklung
> eines "meiste Zentralen"-Backends innerhalb des srcpd gar keine
> Entscheidung bzgl. 28 und 128 Fahrstufen zu treffen, weil
> das sowieso die Hardware der Zentrale übernimmt.

Das hängt wohl von der Zentrale ab. Bei Lenz kannst Du eine Lok jederzeit
von 28 auf 128 Fahrstufen umstellen. Auch im laufenden Betrieb. Also kann
das auch der SRCPD. Nur von 14 auf 28 mußt Du natürlich CVs ändern.

> Und
> möglicherweise ist genau das der Grund, warum N3, N4 und N5 den
> Übergang von SRCP 0.7 zu 0.8 nicht überlebt haben: Weil es
> unnötig erschien.

Nein, es _ist_ unnötig. Aber nicht, weil die Zentrale das weiß, sondern
weil es innerhalb der gleichen Adressierung (lang / kurz) nur zwei
unterschiedliche Geschwindigkeitsbefehle sind. Die man zur Not auch munter
mischen dürfte. *grusel*

> Für DDL ist es aber nur dann unnötig, wenn
> man den Server ermächtigt, zu entscheiden. Warum ich das
> für schlecht halte, steht weiter unten.

Wenn Du dem Server sagst, er soll 128 Fahrstufen fahren, was entscheidet er
denn da noch selbst? Nix. Gar nix.

>
>>> 4. Der Server macht auf gar keinen Fall eine Auswertung bzgl.
>>> Protokoll und
>>>     Version. Ausnahme: Protokoll 'P' ('protocol by server')
>>
>> Was verstehst Du darunter? Natürlich muß er die Protokollangabe auswerten,
>> wie soll er sonst wissen, wie er zu steuern hat.
>
> Mein Vorschlag besagt: Werte Protokoll und Protokollversion aus, das
> reicht. SRCP verlangt aber, dass bei DCC auch die Anzahl der
> Fahrstufen
> beim INIT ausgewertet werden.

Wowereit. Sonst kann man die Fahrstufenzahl auch weglassen.

> Oder - wie Harald andeutete - bei
> Mäklin
> sollen sogar max. mögliche Adresse und Anzahl der FS zur Protokollwahl
> herhalten. Nur zwischen den Versionen, bei denen das nicht geht, wird
> mit dem Versions-Parameter geholfen. IMHO bedeutet "Ich kann nicht
> zwischen ein _paar_ Versionen unterscheiden", dass ich _alle_
> Versionen
> spezifiziere. Und nicht mal rate und mal was gesagt bekomme.

Zu Märklin kann ich nichts sagen. Bei DCC muß jedenfalls nichts geraten
werden, das ist eindeutig. Und eindeutig sollte es auch bei Märklin sein.
Aber eben _nur_ eindeutig, nicht überspezifiziert, wie es bei DCC mit N3-N5
wäre.

> Das ist der Grund, warum ich nach wie vor für die Aufnahme von
> N1 ..., N5 in die SRCP-Spec. votiere und der MM-Kram bei
> M1 ... M5 bestehen bleibt,.

Ich halte es nicht für wünschenswert, da mutwillig Redundanzen einzubauen,
die den Anwender nur verwirren können.

[Guido Scholz]

Torsten Vogt schrieb:

> On 15 Jan., 20:09, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
> wrote:

> Ich verstehe die Argumentation nicht. Ich kann mich notfalls damit
> anfreunden,
> dass es "nur" zwei N's gibt, wobei dann der Server die Entscheidung
> trifft,
> ob DCC-Pakete für 28 Fahrstufen oder 128 FS erzeugt werden.

In den letzten Stunden habe ich mir am Beispiel der Li100 angesehen, wie
srcpd angeschlossene Zentralen ansteuert. Die Entscheidung zur Auswahl
des richtigen Befehls wird alleine aufgrund der vorhandenen Fahrstufen
gefällt, allerdings werden im konkreten Fall nicht nur zwei, sondern
gleich vier unterschieden (14, 27, 28, 126(128))!

Eine Erweiterung auf mehr als 2 Protikollversionen würde demnach eine
Koppelung von Fahrstufen mit Adressbereichen herstellen, die in der
(Hardware-)Praxis nicht vorhanden ist.

[Torsten Vogt]

On 15 Jan., 23:11, Guido Scholz <guido.sch...@bayernline.de> wrote:
> gefällt, allerdings werden im konkreten Fall nicht nur zwei, sondern
> gleich vier unterschieden (14, 27, 28, 126(128))!

Hmmm, das gibt es doch gem. den NMRA-DCC-RFCs gar nicht. D.h.
bzgl. Signalgenerierung müsste gelten: 27 == 28 und 126 == 128.
Wenn man das so macht, dann müsste srcpd _jede_ denkbare FS-Angabe
richtig(!) interpretieren. Also: 0 .. 14, 0 .. 28 und 0 .. 128, hmmm,
dann sind wir wieder bei den Dreien, die es immer geben muss ;-)
und eigentlich führt dann kein Weg an meinem Vorschlag vorbei oder
woher will ein SRCP-Server wissen, dass mit 14 FS das Basisprotokoll
gemeint ist und nicht irgendein Anwender nur die ersten 14 FS eines
28FS-Dekoders nutzen will - warum auch immer.

Gruß

Torsten

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> On 15 Jan., 23:11, Guido Scholz <guido.sch...@bayernline.de> wrote:
>> gefällt, allerdings werden im konkreten Fall nicht nur zwei, sondern
>> gleich vier unterschieden (14, 27, 28, 126(128))!
>
> Hmmm, das gibt es doch gem. den NMRA-DCC-RFCs gar nicht. D.h.
> bzgl. Signalgenerierung müsste gelten: 27 == 28 und 126 == 128.

Nee, 27 wird erzeugt, in dem ein 14-Stufen-Dekoder immer abwechselnd
Fahrstufe x und x+1 gesendet bekommt. Möglicherweise können das sogar nur
die Lenz-Dekoder. 126 ist die maximal Fahrstufe im 128-Fahrstufen-Modus,
weil 0 und Nothalt ja wegfällt.

> Wenn man das so macht, dann müsste srcpd _jede_ denkbare FS-Angabe
> richtig(!) interpretieren. Also: 0 .. 14, 0 .. 28 und 0 .. 128, hmmm,
> dann sind wir wieder bei den Dreien, die es immer geben muss ;-)
> und eigentlich führt dann kein Weg an meinem Vorschlag vorbei oder
> woher will ein SRCP-Server wissen, dass mit 14 FS das Basisprotokoll
> gemeint ist und nicht irgendein Anwender nur die ersten 14 FS eines
> 28FS-Dekoders nutzen will - warum auch immer.

Er weiß das, weil das so definiert ist. Features wie das Nutzen nur der
ersten 14 Fahrstufen eines Dekoders mit mehr Fahrstufen sind Sache des
Clients. Oder eines XRCP. Der SRCP soll nur die Ansprache der Hardware
vereinheitlichen.

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> On 15 Jan., 23:11, Guido Scholz <guido.sch...@bayernline.de> wrote:
>> gefällt, allerdings werden im konkreten Fall nicht nur zwei, sondern
>> gleich vier unterschieden (14, 27, 28, 126(128))!
>
> Hmmm, das gibt es doch gem. den NMRA-DCC-RFCs gar nicht. D.h.
> bzgl. Signalgenerierung müsste gelten: 27 == 28 und 126 == 128.

Nee, 27 wird erzeugt, in dem ein 14-Stufen-Dekoder immer abwechselnd

Fahrstufe x und x-1 gesendet bekommt. Möglicherweise können das sogar nur

die Lenz-Dekoder. 126 ist die maximal Fahrstufe im 128-Fahrstufen-Modus,
weil 0 und Nothalt ja wegfällt.

> Wenn man das so macht, dann müsste srcpd _jede_ denkbare FS-Angabe
> richtig(!) interpretieren. Also: 0 .. 14, 0 .. 28 und 0 .. 128, hmmm,
> dann sind wir wieder bei den Dreien, die es immer geben muss ;-)
> und eigentlich führt dann kein Weg an meinem Vorschlag vorbei oder
> woher will ein SRCP-Server wissen, dass mit 14 FS das Basisprotokoll
> gemeint ist und nicht irgendein Anwender nur die ersten 14 FS eines
> 28FS-Dekoders nutzen will - warum auch immer.

Er weiß das, weil das so definiert ist. Features wie das Nutzen nur der
ersten 14 Fahrstufen eines Dekoders mit mehr Fahrstufen sind Sache des
Clients. Oder eines XRCP. Der SRCP soll nur die Ansprache der Hardware
vereinheitlichen.

[Torsten Vogt]

On 16 Jan., 17:12, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
wrote:

> Nee, 27 wird erzeugt, in dem ein 14-Stufen-Dekoder immer abwechselnd
> Fahrstufe x und x+1 gesendet bekommt. Möglicherweise können das sogar nur
> die Lenz-Dekoder.

Echt? Ich wusste gar nicht, dass es das gibt. Ist das NMRA konform?
Wie dem auch sei, was wäre, wenn nach diesem Verfahren auch 28 FS
möglich wären? Da wär nix mehr mit eindeutiger Protokollerkennung
aus den FS ...

Gruß

Torsten

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> On 16 Jan., 17:12, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
> wrote:
>> Nee, 27 wird erzeugt, in dem ein 14-Stufen-Dekoder immer abwechselnd
>> Fahrstufe x und x+1 gesendet bekommt. Möglicherweise können das sogar nur
>> die Lenz-Dekoder.
>
> Echt? Ich wusste gar nicht, dass es das gibt. Ist das NMRA konform?

Da gab's noch kein NMRA-DCC. Ob das mit übernommen wurde, weiß ich nicht.
Legal ist es auf jeden Fall, die abwechselnd zu senden. Und legal ist
sicher auch, wenn der Dekoder dann mittelt.

> Wie dem auch sei, was wäre, wenn nach diesem Verfahren auch 28 FS
> möglich wären? Da wär nix mehr mit eindeutiger Protokollerkennung
> aus den FS ...

Das ist wohl so. Dann müßte man dafür ein Protokoll vorsehen, so wie es ja
auch bei der Länge der Adressen geschehen ist.

Gruß Martin

[Wolf K]

On 16/01/2012 12:19 PM, Martin Schoenbeck wrote:
> Da gab's noch kein NMRA-DCC.

Lenz uebergab der NMRA seine DCC Technik. Sind also NMRA Normen
eigentlich Lenz Normen.

Wolf K.

[Guido Scholz]

Andre Schenk schrieb:

> Danke Guido, jetzt ist mir auch klar, warum DDW 3 Busse dafür vorsieht:
> einer für MM, einer für DCC kurz und einer für DCC lang. Dort kann man also
> eine Adresse dreimal vergeben.

Kompliment an die "Konkurrenz", die haben wirklich weiter gedacht.

> Nun würde ich gleich nachschieben, beim srcpd einfach 3 DDL-Busse zu
> definieren, wenn man dieses Feature unbedingt braucht, aber von Torsten
> weiß ich, daß das im Moment nicht geht.

Ja, und bei bei OpenDCC/IB "einfach" zwei, bei li100 drei, ...

Es gibt viel zu tun.

[Martin Schoenbeck]

Hallo Wolf,

Wolf K schrieb:

Fehlt da ein Fragezeichen? Die Antwort ist jedenfalls "Nein".

[Guido Scholz]

Torsten Vogt schrieb:

Reichen denn 5 Versionen für MM überhaupt? Was ist denn mit "mfx"
(natürlich nicht alleine auf ddl bezogen)? Gibt es davon nur eine
Version (ist ja doch schon etwas älter)?

[Guido Scholz]

Torsten Vogt schrieb:

> Ich habe bereits an anderer Stelle erläutert, warum es _IMHO_
> auch bei DCC nicht reicht. Sieh es als dokumentarorische Hilfe,
> wenn es fünf N's gibt (damit künftig dieses Diskussionen ausbleiben).
> Dass es pragmatisch auch mit zwei N's geht, ist mir klar.
> Wenn bei MM tatsächlich nur 2 Versionen im SRCP definiert sind,
> sollte dies auf jeden Fall nachgebessert werden. Hier wäre die
> Nachbesserung ja auf jeden Fall abwärtskompatibel, also
> unproblematisch.

Oft werden Entscheidungen auf Basis einer nur dünnen Faktenlage gefällt.
Manchmal fehlt es auch an einer verständlichen Präsentation der
bekannten Fakten. Die übersicht von André ist z.B. eine gute Hilfe. Ich
bin mir augenblicklichh noch nicht ganz sicher, welcher Lösung ich
ustimmen soll. Vielleicht sammeln wir noch ein paar mehr Fakten und
stellen die irgendwo zusammen. Bei der Einführung der "eneric messages"
(GM) hat beispielsweise das "der moba"-Wiki gute Hilfe geleistet.

> Mann, Guido! Diese Diskussion hatten wir vor drei oder vier Jahren
> schon mal. Damals war Dir das sehr wohl klar. ;-) Du hast mich
> davon überzeugt, dass ich damit leben muss. Eine meiner V60 fährt
> seitdem mit Adresse 61 ;-(.

Offengestanden, ich kann mich nicht konkret an diese Art von Konsequenz
erinnern, aber ich werde auch nicht jünger ;-). irgendetwas mit
"inflationärer Busvermehrung" schwebt mir noch vor.

Aber offenbar hast du damals nicht überzeugend argumentiert ;-).

>> Gibt es dafür Lösungsvorschläge? Gut, MM und DCC könnte man auf
>> getrennte Busse legen, aber das DCC-Adressproblem löst man damit nicht.

> Kann man im Moment leider nicht. Mit dem "DCC-Problem" habe ich mich
> abgefunden. Zumindest damit, dass es auf einer Anlage keine gleichen
> DCC-Adressen geben kann. Nicht damit, dass es unter 128 keine "langen"
> Adressen geben darf.

Konsequenterweise sollte beides behoben werden; nicht zwingenderweise
arbeitsmäßig zeitgleich versteht sich.

>> > 2. Es wird im SRCP definiert, was unter den Kombinationen Protokoll
>> > _und_ Pr.Version
>> >     verstanden wird.
>>
>> >     Also inhaltlich etwa das, was in Andre's Wiki steht.
>> Macht Sinn, damit es verständlich wird.
>
> Oha!

Ich habe auch nichts gegen die Aufnahme einer Empfehlung etwa derart:

To avoid overlapping address ranges it is heavily recommended to
separate different digital protocols by implementing them on
different buses.

"hints" gibt es ja jetzt auch schon.

> Naja, da wir jetzt wieder im Code drin stecken sollte
> eine saubere Lösung - nachdem hier eine Entscheidung gefallen ist -
> hinbekommen.

Interessant wären auf jeden Fall noch ein paaar Fakten von anderen
Zentralen (IB, OpenDCC, Loconet,...), um das Bild noch etwas
vollständiger zu mahlen. Mit ECoS etc. kennt sich nicht zufällig jemand
aus? Die Kommunikationsprotokolle sind doch meist irgendwo veröffentlicht.

[Martin Schoenbeck]

Hallo Guido,

Guido Scholz schrieb:

> Offengestanden, ich kann mich nicht konkret an diese Art von Konsequenz
> erinnern, aber ich werde auch nicht jünger ;-). irgendetwas mit
> "inflationärer Busvermehrung" schwebt mir noch vor.
>
> Aber offenbar hast du damals nicht überzeugend argumentiert ;-).

Torsten hat damals erst nach der Festlegung an der Diskussion teilnehmen
können. Leider ist von den alten Threads nicht mehr viel zu finden, weil
google alle die wegoptimiert, die Sorgen haben, auch nach Jahren noch zu
ihren Aussagen zu stehen. ;-)

Aber wir haben damals schon recht ausführlich das für und wider der
verschiedenen Varianten durchgekaut.

> Ich habe auch nichts gegen die Aufnahme einer Empfehlung etwa derart:
>
> To avoid overlapping address ranges it is heavily recommended to
> separate different digital protocols by implementing them on
> different buses.

Zumindest war das der Diskussionsstand.

> "hints" gibt es ja jetzt auch schon.

Ja. Kann man reinschreiben. Oder als separates Dokument dazupacken.

>> Naja, da wir jetzt wieder im Code drin stecken sollte
>> eine saubere Lösung - nachdem hier eine Entscheidung gefallen ist -
>> hinbekommen.
>
> Interessant wären auf jeden Fall noch ein paaar Fakten von anderen
> Zentralen (IB, OpenDCC, Loconet,...), um das Bild noch etwas
> vollständiger zu mahlen. Mit ECoS etc. kennt sich nicht zufällig jemand
> aus? Die Kommunikationsprotokolle sind doch meist irgendwo veröffentlicht.

Allerdings meine ich, daß wir nicht ohne Not das Faß SRCP wieder aufmachen
sollten. Eine Lösung, die alle toll finden, werden wir wohl nicht finden
und die aktuelle Lösung läßt jedenfalls alle Freiheiten, die macht braucht,
um beliebige Protokolle miteinander auf einem SRCP verwalten zu können. Und
ohne, daß der Client um die Feinheiten wissen müßte.

[Harald Nikolisin]

Am 16.01.2012 23:00, schrieb Guido Scholz:
> Torsten Vogt schrieb:
>> On 16 Jan., 06:04, Andre Schenk <an...@melior.s.bawue.de> wrote:
>
>>>> und der MM-Kram bei M1 ... M5 bestehen bleibt,.
>>> Na ja, auch hier wäre die Spec. anzupassen, da sie nur M1 und M2 vorsieht.
>
>> Ja, bitte. Hier geht es ja gar nicht anders.
>
> Reichen denn 5 Versionen für MM überhaupt?

Ja, die reichen. Wenn es nicht den "Winkinger" Selbstbau-Decoder gäbe,
würde theoretisch auch 2 reichen.
Da es ihn aber gibt und die jetzige Unterscheidung logisch und
dokumentiert ist: Give me five :)

Was ist denn mit "mfx"
> (natürlich nicht alleine auf ddl bezogen)? Gibt es davon nur eine
> Version (ist ja doch schon etwas älter)?

Ah, das ist auch auf meinem Radar. Da es ja keine offizielle
Beschreibung davon gibt, kann das niemand so genau sagen. Bisher dürfte
es aber keine große Abweichungen geben.

Ein mögliches Erzeugen des Signals in DDL Manier (Re-Engineering Doku
Krauß/Müller..) dürfte schwer- bis unmöglich sein.

Der leichtere Ansatz ist das dokumentierte CAN Protokoll für Märklin
Hardware zu implementieren.

ok, das war jetzt schon leicht off-topic, Gruß
Harald

[Andre Schenk]

Guido Scholz <guido....@bayernline.de> schrieb:

>> Nun würde ich gleich nachschieben, beim srcpd einfach 3 DDL-Busse zu
>> definieren, wenn man dieses Feature unbedingt braucht, aber von Torsten
>> weiß ich, daß das im Moment nicht geht.

> Ja, und bei bei OpenDCC/IB "einfach" zwei, bei li100 drei, ...

2 Busse bei OpenDCC/IB, um zwischen kurzen und langen Adressen zu
unterscheiden? Wie soll denn das gehen?

Was ich noch anmerken wollte: Ich kann Torsten "Trauer" wegen der fehlenden
Möglichkeit, die Adresse 60 zweimal zu vergeben, weil er 2 V60 hat, gar
nicht so recht verstehen. Man doch im Client jeder Lok einen Namen geben.
Die DCC-Adresse kann von mir aus 0815 heißen.

--
Tschüß André

[Andre Schenk]

Harald Nikolisin <harald.n...@mnet-online.de> schrieb:

>> Was ist denn mit "mfx"

> Ah, das ist auch auf meinem Radar. Da es ja keine offizielle
> Beschreibung davon gibt, kann das niemand so genau sagen. Bisher dürfte
> es aber keine große Abweichungen geben.

> Ein mögliches Erzeugen des Signals in DDL Manier (Re-Engineering Doku
> Krauß/Müller..) dürfte schwer- bis unmöglich sein.

> Der leichtere Ansatz ist das dokumentierte CAN Protokoll für Märklin
> Hardware zu implementieren.

Wenn mfx über DDL nicht geht, müssen wir es doch nicht im SRCP erwähnen,
weil es dann über Protokoll "S" läuft oder sehe ich das falsch?

--
Tschüß André

[Torsten Vogt]

On 17 Jan., 08:01, Andre Schenk <an...@melior.s.bawue.de> wrote:
> Wenn mfx über DDL nicht geht, müssen wir es doch nicht im SRCP erwähnen,
> weil es dann über Protokoll "S" läuft oder sehe ich das falsch?

Ich dachte "P"? Ist "S" nicht Selectrix? Egal, ich hatte noch keine
Zeit die SRCP-Spec. nachzulesen.

Zurück zu mfx: Ich nehme an, dass "protocol by server" immer dann
Sinn macht, wenn die Lok sowieso über die Bedienelemente der
Zentrale angelegt werden muss/kann. D.h. die Zentrale weiss,
was zu tun ist. Nun gibt es aber auch Zentralen, die gar keine
Bedienoberfläche haben. Diese sind doch die, für die der srcpd
eigentlich gemacht ist. Hier muss die Software der (Multiprotokoll)-
Zentrale mitteilen, wie eine Lok anzusteuern ist. Das geht über INIT.
Da wir nicht ausschliessen können, dass mfx auch mal von einer
solchen Zentrale angeboten wird, sollte mfx irgendwie schon ins SRCP.

Anderes Thema: Wikingerdekoder! Ich behaupte mal, dass der, im
Gegensatz
zu sicher noch vielen vorhandenen 6090-Dekodern (M1), keine Relevanz
mehr hat. Oder hat den schon mal jemand "in Echt" gesehen? Der
Wikingerdekoder
tut weiterhin auch, wenn man ihn mit M2 anspricht. Ich könnte mir
also schon vorstellen, dass man den im DDL-Code über die Wupper gehen
lassen kann.

Und zu den V60: Ich verstehe auch so einige Dinge nicht, die andere
machen. Für was braucht man 28 Dekoderfunktionen? Jetzt bitte
nicht hier darüber diskutieren. Wer sie braucht, soll sie haben,
ist mir wurscht. Was solls, jeder lebt nach seinem Gusto und klar,
es gibt genügend freie Adressen. Nur warum soll man ein System
unnötig einschränken, wenn es wirklich nicht sein muss?

Gruß

Torsten

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> Und zu den V60: Ich verstehe auch so einige Dinge nicht, die andere
> machen. Für was braucht man 28 Dekoderfunktionen? Jetzt bitte
> nicht hier darüber diskutieren. Wer sie braucht, soll sie haben,
> ist mir wurscht. Was solls, jeder lebt nach seinem Gusto und klar,
> es gibt genügend freie Adressen. Nur warum soll man ein System
> unnötig einschränken, wenn es wirklich nicht sein muss?

Es ist ja nicht eingeschränkt. Ob Du nun beim Ansteuern der Loks N1 60 und
N2 60 ansteuerst oder Bus 1 60 und Bus 2 60 ist erstmal völlig egal. Eine
Einschränkung wird es erst dadurch, daß irgendein Teil der Software es
nicht unterstützt. Was aber in beiden Varianten denkbar ist. Die
Einschränkung liegt also nicht in der Spezifikation und sollte daher auch
nicht dort behoben werden.

[Torsten Vogt]

Hallo Martin,

On 17 Jan., 11:40, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
wrote:

> Es ist ja nicht eingeschränkt. Ob Du nun beim Ansteuern der Loks N1 60 und
> N2 60 ansteuerst oder Bus 1 60 und Bus 2 60 ist erstmal völlig egal. Eine
> Einschränkung wird es erst dadurch, daß irgendein Teil der Software es
> nicht unterstützt.

Richtig, der srcpd unterstützt es nur mit unterschiedlichen
Bussen und das DDL-Backend kann derzeit nicht gleichzeitig auf
mehreren Bussen konfiguriert werden. Weiterhin ist _das_ nicht
das Thema der eigentlichen Diskussion und ausserdem hab ich mich
bereits damit abgefunden, dass es zumindest derzeit nicht geht.
Und wie Andre richtig bemerkt hat: Es ist ein absolutes Luxus-
Problem.

> Was aber in beiden Varianten denkbar ist. Die
> Einschränkung liegt also nicht in der Spezifikation und sollte daher auch
> nicht dort behoben werden.

Das war nie verlangt. Gewünscht habe ich mir nur, dass ein
Client die Art und Weise, wie ein Dekoder anzusteuern ist,
eindeutig über SRCP (mit separaten Parametern) an den Server
übermitteln kann, ohne dass der Server zusätzliche Parameter
(wie z.B. Anzahl der FS) für diese Entscheidung heranziehen
darf/muss.

Gruß

Torsten

[Andre Schenk]

Torsten Vogt <vogt_t...@gmx.de> schrieb:

> Ich dachte "P"? Ist "S" nicht Selectrix? Egal, ich hatte noch keine
> Zeit die SRCP-Spec. nachzulesen.

oh ja, sorry, da hatte ich wohl "S"erverprotokoll im Hinterkopf.

> Zurück zu mfx: Ich nehme an, dass "protocol by server" immer dann
> Sinn macht, wenn die Lok sowieso über die Bedienelemente der
> Zentrale angelegt werden muss/kann. D.h. die Zentrale weiss,
> was zu tun ist.

Nicht alle Zentralen haben Bedienelemente, OpenDCC z.B. oder Lenz, soweit
ich weiß.

Für mich ist der Unterschied zwischen DDL (also "M" und "N") und den
anderen Protokollen der, daß bei ersteren der srcpd das Digitalsignal
selbst erzeugt. Insofern würde ich mfx da nicht dazuzählen, wenn ein
CAN-Interface dazwischengeschaltet werden muß.

> Anderes Thema: Wikingerdekoder! Ich behaupte mal, dass der, im
> Gegensatz
> zu sicher noch vielen vorhandenen 6090-Dekodern (M1), keine Relevanz
> mehr hat. Oder hat den schon mal jemand "in Echt" gesehen? Der
> Wikingerdekoder
> tut weiterhin auch, wenn man ihn mit M2 anspricht. Ich könnte mir
> also schon vorstellen, dass man den im DDL-Code über die Wupper gehen
> lassen kann.

Wenn der Wikinger-Dekoder wirklich noch unterstützt werden soll, wie wäre
es dann, für ihn ein "M3" zu spezifizieren und die anderen
Märklin-Protokolle in "M1" und "M2" zusammenzufassen? Ginge das?

--
Tschüß André

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> Das war nie verlangt. Gewünscht habe ich mir nur, dass ein
> Client die Art und Weise, wie ein Dekoder anzusteuern ist,
> eindeutig über SRCP (mit separaten Parametern) an den Server
> übermitteln kann, ohne dass der Server zusätzliche Parameter
> (wie z.B. Anzahl der FS) für diese Entscheidung heranziehen
> darf/muss.

Ich sehe da immer noch keinen Nutzen. Wohl aber beim Nachdenken Nachteile
für den Benutzer. Daß N1 kurze Adresse kodiert und N2 lange kann man sich
noch recht leicht merken. So kann man für alle Dekoder aus dem Kopf die
Parameter für den INIT eintragen, wenn man weiß was der Dekoder kann. Mit
N1 bis N5 müßte ich zumindest regelmäßig nachsehen, welches denn nun lange
Adressen mit 28 Fahrstufen oder kurze mit 128 Fahrstufen sind. Und daß nur,
damit der Serverprogrammierer sich ein paar Befehle spart.

[Torsten Vogt]

On 17 Jan., 22:04, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
wrote:

> Ich sehe da immer noch keinen Nutzen.

dann geb ich an dieser Stelle auf.

> Wohl aber beim Nachdenken Nachteile für den Benutzer.

??????? Wer will denn den Nutzer damit belasten? Oder heisst Dein
Client telnet? Ich will eine saubere Lösung zwischen Client und
Server.

> Daß N1 kurze Adresse kodiert und N2 lange kann man sich
> noch recht leicht merken.

Ach ja? Ich habe mir aus Urzeiten des erddcd gemerkt, dass
N1 kurze und N3 lange Adressen hat (haben soll) ;-)

BTW: Will mir irgendeiner erzählen, dass ein Modellbahner
(== Anwender) nicht weiss, welche Dekoder er verbaut hat
und wie die konfiguriert sind? Bei DCC ist immer noch die
CV-Konfiguration weit verbreitet. Also muss doch bei
jedem Dekoder mal entschieden werden, wie der konfiguriert
wird. Wenn wir das Basisprotokoll mal ausser acht lassen,
sind das nun mal 4 Möglichkeiten bei DCC. Diese 4 Möglichkeiten
sind doch geläufig.

> So kann man für alle Dekoder aus dem Kopf die
> Parameter für den INIT eintragen,

Also doch telnet.

> wenn man weiß was der Dekoder kann. Mit
> N1 bis N5 müßte ich zumindest regelmäßig nachsehen, welches denn nun lange
> Adressen mit 28 Fahrstufen oder kurze mit 128 Fahrstufen sind. Und daß nur,
> damit der Serverprogrammierer sich ein paar Befehle spart.

Nein dass ist nicht mein Anliegen. Mein Anliegen ist, dass künftig
eindeutige Klarheit herrscht.

Nur mal angenommen, dass DCC-Protokoll wird um eine weitere
Variante offiziell erweitert, die irgendwelche Vorteile bietet,
sich aber aus den INIT-Parametern nicht von einer anderen
unterscheiden lässt. Dann wäre eine Erweiterung um eine Protokoll-
version für Dich akzeptabel. Meine Argumentation geht in die
Richtung, dass man besser eine saubere Spezifikation von _allen_
Protokollversionen macht, als einige durch implizite Logik
auseinanderzuhalten und andere andere eben nicht. IMHO ist das
die _sauberste_ Lösung.

Hmmm, jetzt hab ich doch nicht aufgegeben ;-)

Wenn die Mehrheit hier eher für Hacks ;-) ist, dann beuge ich
mich.

Aber das ist meine Meinung zu dieser Sache.

Gruß

Torsten

[Torsten Vogt]

On 17 Jan., 21:26, Andre Schenk <an...@melior.s.bawue.de> wrote:
> Wenn der Wikinger-Dekoder wirklich noch unterstützt werden soll, wie wäre
> es dann, für ihn ein "M3" zu spezifizieren und die anderen
> Märklin-Protokolle in "M1" und "M2" zusammenzufassen? Ginge das?

Ach, Andre ;-) Was soll ich hierauf antworten?

Rein von der Logik her ginge das, ja. Hat ja Harald N. ausgeführt.

Gut finde ich es aus den vielfach hier aufgeführten Gründen nicht.

Ich schlage nun vor, keine weiteren Argumente anzuführen, ich denke
es ist alles gesagt. IMHO liegen zwei Vorschläge vor, über die man
nun entscheiden kann. Ich fasse zusammen:

1. Über die beiden Argumente protocol (P) und protocolversion (V)
des INIT-Befehls wird eindeutig festgelegt, welches Protokoll der
Server für eine bestimmte Adresse und Bus zu benutzen hat.
_Alle_ zulässigen Kombinationen von P und V werden im SRCP
definiert.
Gggflls. wird SRCP erweitert, wenn weitere Protokolle an Bedeutung
gewinnen.

2. Zusätzlich zu den beiden Argumente protocol (P) und protocolversion
(V)
des INIT-Befehls, muss ein SRCP-Server die anderen übergebenen
Parameter
auswerten. Die Kombination aus allen Parametern ergibt das
Protokoll,
die der Server für eine bestimmte Adresse und Bus zu benutzen hat.
Im SRCP wird nur dann eine Kombinationen von P und V definiert,
wenn
man aus den anderen Parametern keine eindeutige Protokollzuordnung
ermitteln kann.

Ich bin für 1.

Gruß

Torsten

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> On 17 Jan., 22:04, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
> wrote:
>> Ich sehe da immer noch keinen Nutzen.
>
> dann geb ich an dieser Stelle auf.
>
>> Wohl aber beim Nachdenken Nachteile für den Benutzer.
>
> ??????? Wer will denn den Nutzer damit belasten? Oder heisst Dein
> Client telnet? Ich will eine saubere Lösung zwischen Client und
> Server.

Wenn man einen Client hat, der die Initialisierung selbst erledigt und dem
Benutzer ein hübsches Menü dafür gibt, umso besser. Die Nachteile
materialisieren sich natürlich nur, wenn man den nicht hat. Vorteile gibt's
aber nirgends, also schlimmstenfalls ein Patt. Was dann dafür spricht,
nichts zu ändern.

>> Daß N1 kurze Adresse kodiert und N2 lange kann man sich
>> noch recht leicht merken.
>
> Ach ja? Ich habe mir aus Urzeiten des erddcd gemerkt, dass
> N1 kurze und N3 lange Adressen hat (haben soll) ;-)

Und N2? Intuitiv ist daran jedenfalls nichts. Ist aber letztlich wirklich
nicht entscheidend.

> BTW: Will mir irgendeiner erzählen, dass ein Modellbahner
> (== Anwender) nicht weiss, welche Dekoder er verbaut hat
> und wie die konfiguriert sind?

Natürlich muß er das wissen. Wer solls ihm denn sonst sagen? Wie kommst Du
darauf, ich nähme an, er wisse das nicht?

> Bei DCC ist immer noch die
> CV-Konfiguration weit verbreitet. Also muss doch bei
> jedem Dekoder mal entschieden werden, wie der konfiguriert
> wird. Wenn wir das Basisprotokoll mal ausser acht lassen,
> sind das nun mal 4 Möglichkeiten bei DCC. Diese 4 Möglichkeiten
> sind doch geläufig.

Natürlich. Aber die Zuordnung dieser vier Möglichkeiten zu den alten Nx ist
ja nun keineswegs irgendwie intuitiv.

>> So kann man für alle Dekoder aus dem Kopf die
>> Parameter für den INIT eintragen,
>
> Also doch telnet.

Du willst trollen?

>> wenn man weiß was der Dekoder kann. Mit
>> N1 bis N5 müßte ich zumindest regelmäßig nachsehen, welches denn nun lange
>> Adressen mit 28 Fahrstufen oder kurze mit 128 Fahrstufen sind. Und daß nur,
>> damit der Serverprogrammierer sich ein paar Befehle spart.
>
> Nein dass ist nicht mein Anliegen. Mein Anliegen ist, dass künftig
> eindeutige Klarheit herrscht.

Meine auch. Deshalb bin ich dagegen, noch einmal, diesmal völlig unnötig,
am SRCP rumzuändern. Das _ist_ aktuell nämlich eindeutig.

> Nur mal angenommen, dass DCC-Protokoll wird um eine weitere
> Variante offiziell erweitert, die irgendwelche Vorteile bietet,
> sich aber aus den INIT-Parametern nicht von einer anderen
> unterscheiden lässt.

Dann wird man eine neue Variante der INIT-Parameter dafür definieren
müssen. In jeder denkbaren Lösung. Wo siehst Du das Problem.

> Dann wäre eine Erweiterung um eine Protokoll-
> version für Dich akzeptabel.

Sicherlich. Was sollte dagegensprechen?

> Meine Argumentation geht in die
> Richtung, dass man besser eine saubere Spezifikation von _allen_
> Protokollversionen macht,

Ich habe das schon verstanden, daß Du Deine Variante für sauberer hältst.
Ich halte die aktuell festgelegte Variante für sauberer. Vor allem aber
halte ich die Unterschiede für dermaßen banal, daß es einfach albern ist,
dafür eine neue SRCP-Version in den Stiel zu stoßen. Man kann Argument für
beide Varianten finden und bei der Festlegung von 0.8 haben wir uns nun
einmal für die aktuelle Variante entschieden. Wenn Du jedesmal, wenn
jemanden die Entscheidung nicht paßt - obwohl es genaugenommen völlig
wurscht ist - neu entscheiden willst, dann zerstörst Du den Ansatz von
SRCP. Jedenfalls dann, wenn es jeweils gelingt, aus welch zufälligen
Gründen auch immer, für die jeweils andere Variante eine Mehrheit zu
finden.

Die Entscheidung ist gefallen und auch wenn Du damals daran nicht beteiligt
warst, solltest Du sie respektieren.

> als einige durch implizite Logik
> auseinanderzuhalten und andere andere eben nicht. IMHO ist das
> die _sauberste_ Lösung.

Selbst wenn rechtfertigt sie keine Änderung des aktuellen Standards. Das
ist, entschuldige wenn ich das jetzt so deutlich sage, Kinderei. Die
Änderungen, um die aktuelle Variante in einem SRCP zu berücksichtigen, sind
ja schneller erledigt, als hier ein Posting dazu zu schreiben.

> Hmmm, jetzt hab ich doch nicht aufgegeben ;-)
>
> Wenn die Mehrheit hier eher für Hacks ;-) ist, dann beuge ich
> mich.

Und was ein Hack ist und was eine saubere Definition, das weiß außer Dir
natürlich niemand. Schon klar.

> Aber das ist meine Meinung zu dieser Sache.

Die Dir auch unbenommen zusteht. Die aber bei Festlegung von 0.8 nicht
mehrheitsfähig war. Und die jetzt durchzusetzen, selbst wenn sich eine
Mehrheit findet, wirklich ausgemachter Blödsinn wäre.

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> Ich bin für 1.

Und ich bin dafür, nicht aus Jux und Dollerei an SRCP Änderungen
durchzuführen. Also für 3

3) Änderungen an den für INIT im SRCP definierten Parametern werden nur
dann durchgeführt, wenn dies erforderlich ist, weil anders Funktionen
existierender oder wegen Änderungen eines Standards zu erwartender Dekoder
nicht genutzt werden können.

[Torsten Vogt]

On 18 Jan., 09:55, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
wrote:

> Und ich bin dafür, nicht aus Jux und Dollerei an SRCP Änderungen
> durchzuführen. Also für 3

??????

> 3) Änderungen an den für INIT im SRCP definierten Parametern werden nur
> dann durchgeführt, wenn dies erforderlich ist, weil anders Funktionen
> existierender oder wegen Änderungen eines Standards zu erwartender Dekoder
> nicht genutzt werden können.

Das passt sowohl zu 1. wie zu 2.

Das was Du heute willst ist 2., denn das entspricht aktuell quasi
keiner Änderung im SRCP.

Im übrigen halte ich meinen Vorschlag für gar nicht so dramatisch,
was die Auswirkungen auf bestehende Implementierungen angeht.
Man braucht ja nur an N2 für lange Adressen festzuhalten und
N3 und N4 definieren dann die Protokollwahl bzgl. Fahrstufen.
Dann wäre zwar einige Software defakto inkompatibel zu SRCP,
praktische Auswirkungen hätte es aber keine.
Die Märklin-Abteilung des SRCP sollte ja auf jeden Fall angepackt
werden. Hier käme ggflls. zu M1 und M2 noch weitere M's hinzu.
Wenn Software das nicht unterstützt, ist das auch kein Beinbruch,
da mit M1 und M2 eigentlich alle Dekoder funktionieren, nur werden
ein paar Features eben nicht angesprochen. D.h. es läge nicht mal
eine Inkompatibilität zum SRCP vor. Es fehlen nur optionale
Teile.

Gruß

Torsten

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> 1. Über die beiden Argumente protocol (P) und protocolversion (V)
> des INIT-Befehls wird eindeutig festgelegt, welches Protokoll der
> Server für eine bestimmte Adresse und Bus zu benutzen hat.

In dem Fall mußt Du bei NMRA-DCC übrigens natürlich so, wie Du die
Ansprache der Geschwindigkeit als unterschiedliche Protokollvariante
definieren willst, auch die Ansprache der Funktionen als unterschiedliche
Protokollvariante definieren. Da bist Du aktuell (wenn ich keine vergessen
habe) dann bereits bei 15 Protokollvarianten allein für NMRA-DCC.

Und das, obwohl ein SRCP-Server die mit der aktuellen Spezifikation auch
bereits problemlos behandeln kann.

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> Im übrigen halte ich meinen Vorschlag für gar nicht so dramatisch,
> was die Auswirkungen auf bestehende Implementierungen angeht.

Nein, natürlich nicht. Genauso, wie auch die aktuelle Definition völlig
banal in bestehenden Implementierungen berücksichtigt werden kann. Die
Unterschiede zwischen beiden Varianten liegen ja nicht in der Schwierigkeit
der Implementation. Und übrigens auch nicht, wie von Dir suggeriert, darin,
daß die Mitdiskutanten bei 0.8 alle keine Ahnung davon habe, wie saubere
Schnittstellen aussehen.

Und genau deshalb, weil die Unterschiede am Ende belanglos sind, darf man
deshalb nicht am SRCP herumbasteln. Insbesondere, weil es schon wieder ein
inkompatible Änderung wäre.

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> Im übrigen halte ich meinen Vorschlag für gar nicht so dramatisch,
> was die Auswirkungen auf bestehende Implementierungen angeht.

Nein, natürlich nicht. Genauso, wie auch die aktuelle Definition völlig
banal in bestehenden Implementierungen berücksichtigt werden kann. Die
Unterschiede zwischen beiden Varianten liegen ja nicht in der Schwierigkeit
der Implementation. Und übrigens auch nicht, wie von Dir suggeriert, darin,
daß die Mitdiskutanten bei 0.8 alle keine Ahnung davon habe, wie saubere
Schnittstellen aussehen.

Und genau deshalb, weil die Unterschiede am Ende belanglos sind, darf man

deshalb nicht am SRCP herumbasteln. Insbesondere, weil es schon wieder eine
inkompatible Änderung wäre.

[Torsten Vogt]

Hallo Martin,

On 18 Jan., 09:51, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
wrote:
[....]
> Du willst trollen?
[...]

> halte ich die Unterschiede für dermaßen banal, daß es einfach albern ist,
> dafür eine neue SRCP-Version in den Stiel zu stoßen. Man kann Argument für
> beide Varianten finden und bei der Festlegung von 0.8 haben wir uns nun
> einmal für die aktuelle Variante entschieden. Wenn Du jedesmal, wenn
> jemanden die Entscheidung nicht paßt - obwohl es genaugenommen völlig
> wurscht ist - neu entscheiden willst, dann zerstörst Du den Ansatz von
> SRCP. Jedenfalls dann, wenn es jeweils gelingt, aus welch zufälligen
> Gründen auch immer, für die jeweils andere Variante eine Mehrheit zu
> finden.

[...]

> Selbst wenn rechtfertigt sie keine Änderung des aktuellen Standards. Das
> ist, entschuldige wenn ich das jetzt so deutlich sage, Kinderei.

[...]

> Und was ein Hack ist und was eine saubere Definition, das weiß außer Dir
> natürlich niemand. Schon klar.

[...]

> Und die jetzt durchzusetzen, selbst wenn sich eine
> Mehrheit findet, wirklich ausgemachter Blödsinn wäre.

Für mich ist hier EOD. Sorry, dass ich mich mal wieder einbringen
wollte. Vielleicht denkst Du mal darüber nach, dass ich

a.) jede Entscheidung der Abstimmung akzeptieren werde
b.) die vorgeschlagene Änderung nur eine kleine Modifikation
ist.

Ich wusste im übrigen nicht, dass SRCP 0.8.4 "in Beton gegossen"
ist. Hat mir niemand gesagt, aber jetzt weiss ich es ja.

Wie gesagt: EOD.

Gruß

Torsten

[Torsten Vogt]

On 18 Jan., 10:18, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
wrote:

> In dem Fall mußt Du bei NMRA-DCC übrigens natürlich so, wie Du die
> Ansprache der Geschwindigkeit als unterschiedliche Protokollvariante
> definieren willst, auch die Ansprache der Funktionen als unterschiedliche
> Protokollvariante definieren. Da bist Du aktuell (wenn ich keine vergessen
> habe) dann bereits bei 15 Protokollvarianten allein für NMRA-DCC.

Das stimmt so nicht. Funktionspakete werden einfach angehängt. Das ist
bei allen N's gleich. Zumindest war es so, als ich zum letzten Mal
die NMRA-DCC-Spec. gelesen habe.

Gruß

Torsten

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> Für mich ist hier EOD. Sorry, dass ich mich mal wieder einbringen
> wollte. Vielleicht denkst Du mal darüber nach, dass ich
>
> a.) jede Entscheidung der Abstimmung akzeptieren werde

Dann gäbe es diese Diskussion nicht. Denn die Abstimmung darüber wurde vor
Jahren getroffen und seitdem hat sich nichts an den Rahmenbedingungen
geändert. Sorry, aber das ist so. Es gibt keinen Grund für eine neue
Abstimmung.

> b.) die vorgeschlagene Änderung nur eine kleine Modifikation
> ist.

Es ist insbesondere eine inkompatible Änderung. Und banal und überflüssig.

> Ich wusste im übrigen nicht, dass SRCP 0.8.4 "in Beton gegossen"
> ist. Hat mir niemand gesagt, aber jetzt weiss ich es ja.

In Bezug auf überflüssige Änderungen sollte _jede_ Schnittstellendefinition
in Beton gegossen sein. Aber das weißt Du auch.

Entschuldige, wenn ich in meinem letzten Posting ein wenig sehr deutlich
geworden bin. Aber die Diskussion ist wirklich überflüssig wie ein Kropf
und es nervt, wenn man an solchen Diskussionen nur deshalb teilnehmen muß,
damit nicht am Ende eine Abstimmung stattfindet, bei der nur noch die
teilnehmen, die noch nicht entnervt aufgegeben haben.

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> Das stimmt so nicht. Funktionspakete werden einfach angehängt. Das ist
> bei allen N's gleich. Zumindest war es so, als ich zum letzten Mal
> die NMRA-DCC-Spec. gelesen habe.

Einem Dekoder, der nur das basic packet format versteht, kannst Du nicht
einfach Funktionsbefehle anhängen. Und auch ansonsten sind Funktionsbefehle
eben eine Sorte Befehle, Geschwindigkeitsbefehle eine andere. Die
Protokolle unterscheiden sich da sowieso nicht, wenn man vom basic packet
format absieht und genaugenommen ist auch die Adresslänge kein
unterschiedliches Protokoll. Bloß ist das auf dem Weg einfacher für den
Benutzer oder den Clientprogrammierer, als wenn man ihm die Bitkodierung
aufnötigt.

[Torsten Vogt]

Hallo Martin,

ich mache hier nicht mehr weiter. Ich denke,
dass wir die jeweiligen Argumente des anderen
sehr wohl verstehen. Also lass gut sein.

Wenn sich hier keine Mehrheit für meinen Vorschlag
findet, werde ich den DDL-Teil des srcpd in den
nächsten Tagen vollständig zum aktuellen SRCP
kompatibel machen. Das ist er nämlich nicht und
deshalb auch der Stein des Anstosses. Mit Andre werde
ich daran gehen, dass der j-man es auch richtig macht,
falls er das nicht jetzt schon tut. Es ist kein grosser
Aufwand. U. U. bleibt dann der Wikingerdekoder auf der
Strecke, was mir persönlich ziemlich egal ist.

Insgesamt finde ich das Ergebnis der Diskussion im
übrigen nicht unbefriedigend, da zumindest für mich
einige Fragen beantwortet sind, die mir letzte Woche
noch unklar waren.

Gruß

Torsten

[Guido Scholz]

Harald Nikolisin schrieb:

> Am 16.01.2012 23:00, schrieb Guido Scholz:

>> Reichen denn 5 Versionen für MM überhaupt?
> Ja, die reichen. Wenn es nicht den "Winkinger" Selbstbau-Decoder gäbe,
> würde theoretisch auch 2 reichen.

Wieso reichen 5 wenn...

> Was ist denn mit "mfx"
>> (natürlich nicht alleine auf ddl bezogen)? Gibt es davon nur eine
>> Version (ist ja doch schon etwas älter)?

> Ah, das ist auch auf meinem Radar. Da es ja keine offizielle
> Beschreibung davon gibt, kann das niemand so genau sagen. Bisher dürfte
> es aber keine große Abweichungen geben.

... das eindeutig von den beiden (drei/fünf) Motorola-Formaten abweicht?
Siehe eben hier:

http://www.skrauss.de/modellbahn/mdigital.html

Dort wird auch das neuere M4-Format erwähnt, was dann ein weiteres wäre,
wenn es denn nicht nur aus lizenzrechtlichen Gründen einen anderen Namen
hat. Leider habe ich auf der Seite des Erfinders (ESU) nichts gescheites
zu "M4" bzw. zu den Unterschieden zu mfx gefunden. Die FAQ zu dem Thema
ist ein schlechter Witz:

http://www.esu.eu/support/faq/digitalsysteme/m4-datenformat/

[Guido Scholz]

Andre Schenk schrieb:

> Wenn mfx über DDL nicht geht, müssen wir es doch nicht im SRCP erwähnen,
> weil es dann über Protokoll "S" läuft oder sehe ich das falsch?

Das GL/GA Protokoll hat mit DDL zunächst nichts zu tun, sondern ist
wegen der Verstädigung der Zentrale mit den angeschlossenen Decodern
notwendig. Ein halbwegs brauchbarer Überblicksartikel scheint mir diese
Liste zu sein:

http://www.digital-bahn.de/info_kompo/zentrale_multi.htm

Dort werden immerhin 4 DCC-Protokolle, aber nur drei Märklin-Protokolle
unterschieden.

Bei Selektrix hat sich ja wohl auch einiges getan, siehe hier:

<http://www.muet-digirail.de/digirail_modellbahn/index.php?option=com_content&view=article&id=82%3Aselectrix-2>

oder

http://www.rautenhaus.de/themen/rmx-system.html

Das sollte mindestens für eine weitere Selectrix-Protokollvariante
reichen.

[Harald Nikolisin]

Hm, ich glaube da kommt einiges Durcheinander

Beim Märklin Motorola Protokoll reden wir von dem Signalmuster den die
alten Motorola IC's erzeugen.
Dort besteht ein Kommando/Datenwort aus 9 "Trits" (trinärer statt
binärer Zustand), welche wiederum aus 2 Datenimpulse bestehen.

Die Interpretation der 9 Trits wurde in den 80iger festgelegt: Märklin
Motorola Protokoll I
Mit der Einführung der Funktionen F1-F4 wurde die Interpretation der
letzten 4 Trits abwärtskompatibel geändert, so dass Märklin Motorola
Protokoll II entstand.

Also gibt es nur 2 - leider gelten beide Versionen eigentlich nur für 14
Fahrstufen. Mit Einführung der 27 FS bei Märklin Decodern wurde nicht
das Protokoll geändert, sondern die Art der Wiederholung der
Datenwörter, so dass durch ein "verändertes Wiederholungsmuster" die
Zwischenstufen eingeführt wurden.

Der Wikinger-Decoder wiederum änderte Trit Nr. 5 zur Übermittlung der 28
FS, so dass dieser Decoder ein "inoffizielles" Motorola Protokoll 3
darstellt.

Daran ändert sich aber - wie schon Torsten erwähnte - ziemlich sicher
nichts mehr.


ESU entwickelte dann im Auftrag von Märklin das mfx Protokoll, welches
nichts mit MM zu tun hat.
Es darf auch von ESU benutzt werden - allerdings unter einem anderen
Namen: M4

Schön wäre es sicherlich, dieses Protokoll auch wie MM und DCC in DDL
einzuführen. Nur wäre da noch viel Re-Engineering Arbeit zu leisten - es
sieht nicht so aus als ob Märklin die Spezifikation freigibt und ESU
darf es meines Wissens nicht.
Ob es Varianten dieses Protokolls gibt weiß der Geier (und Märklin und ESU)

Die Alternative ist mfx via CANBus anzusteuern. Dazu braucht man aber
einen GFP (Gleisformatprozessor) der das Signal letztendlich erzeugt.
Dieser ist entweder in einer Zentrale (Märklin CS1/CS2, ESU ECos) oder
man nimmt den extra Baustein (kleine graue Kiste) die mit der MS2
vertrieben wird.
Bei dem CANBus Protokoll gibt es 3 Varianten (eine für CS1/MS1/Ecos,
eine zusätzliche Ecos Variante und eine für CS2/graue Kiste der MS2).
Die letzte Variante ist offiziell dokumentiert:

http://medienpdb.maerklin.de/produkte/pdfs/CS2_can-protokoll_1-0.pdf


..Jetzt hab ich schon wieder einen Roman geschrieben.Kurz

* 2 MM Formate (+1 Extrawurst für Wikinger)
* MFX/M4 via DDL ? Formate, sowieso äusserst unwahrscheinlich
* MFX/M4 via CANBus+GFP, 3 Formate (nur das letzte gut zu implementieren)

gruß,
Harald

[Torsten Vogt]

On 18 Jan., 22:26, Guido Scholz <guido.sch...@bayernline.de> wrote:
[... MM Protokoll ...]
> Wieso reichen 5 wenn...
[... mfx ...]

> ... das eindeutig von den beiden (drei/fünf) Motorola-Formaten abweicht?

Naja, mfx weicht soweit von MM ab, dass man das wohl als völlig
eigenständiges Protokoll sehen muss und nicht als Protokollversion
von MM.

MM steht für Märklin Motorola, mfx hat damit nichts zu tun.

> Dort wird auch das neuere M4-Format erwähnt

Sowie Harald es schreibt ist mfx == M4. Und dieses M4 hat dann
offensichtlich nichts mit dem SRCP-M4, also einer 4. Protokollversion
von MM, zu tun.

Wenn man mfx in SRCP aufnehmen will, muss man wohl einen neuen
Protokollbuchstaben spendieren. Was wäre denn noch frei? 'X'?

Gruß

Torsten

[Torsten Vogt]

On 19 Jan., 00:19, Harald Nikolisin <harald.nikoli...@mnet-online.de>
wrote:

> Schön wäre es sicherlich, dieses Protokoll auch wie MM und DCC in DDL
> einzuführen.

Ein erster Schritt wäre ja schon getan, wenn mfx in SRCP
eingeführt wird. Ein srcpd-DDL-Modul für mfx erscheint mir aus
heutiger
Sicht nicht machbar. Aber ein srcpd-Modul für eine der neuen
Märklin oder ESU-Zentralen sollte doch möglich sein.

> * MFX/M4 via CANBus+GFP, 3 Formate (nur das letzte gut zu implementieren)

Ich dachte man kann neue Märklin-Zentralen per Netzwerkprotokoll
ansprechen. War das nicht mal angekündigt?

Gruß

Torsten

[Harald Nikolisin]

Am 19.01.2012 08:41, schrieb Torsten Vogt:

>> * MFX/M4 via CANBus+GFP, 3 Formate (nur das letzte gut zu implementieren)
>
> Ich dachte man kann neue Märklin-Zentralen per Netzwerkprotokoll
> ansprechen. War das nicht mal angekündigt?
>

Hallo Torsten,

Auf der CS2 kann man wohl ein CAN-UDP Gateway starten. SRCPD könnte dann
die CAN Messages via UDP Pakete senden und empfangen.

Gruß,
Harald

[Lothar Roth]

Hallo,

...und die Dokumentation gibt es bei Märklin zum Download
<http://medienpdb.maerklin.de/produkte/pdfs/CS2_can-protokoll_1-0.pdf>

> Gruß,
> Harald

Gruß,
Lothar

[Guido Scholz]

Torsten Vogt schrieb:

> Sicht nicht machbar. Aber ein srcpd-Modul für eine der neuen
> Märklin oder ESU-Zentralen sollte doch möglich sein.

>> * MFX/M4 via CANBus+GFP, 3 Formate (nur das letzte gut zu implementieren)

> Ich dachte man kann neue Märklin-Zentralen per Netzwerkprotokoll
> ansprechen. War das nicht mal angekündigt?

Wobei das wohl zwei verschiedene Module wären, denn die Ecos wird über
ein für den Menschen gut lesbares Text-Protokoll angesprochen...

http://www.espacerails.com/modelisme/html/maj_ecos/ECoS_PC_protocole.pdf

... während die aktuelle Märklin Central Station gemäß der
Märklindokumentation, auf die Harald einen Link zitierte, einen CAN-Bus
zu UDP Adapter eingebaut hat. Man muß also das CAN-Bus-Protokoll über
Ethernet verschicken, was wegen der größeren Entfernung von der
menschlichen Sprache etwas schwieriger zu implementieren sein dürfte.

Wenn ich mich recht erinnere hatte sich über die srcpd-Mailingliste mal
jemand gemeldet, der die ECos-unterstützung fast fertig hate, wegen der
merkwürdig strikt formulierten Lizenzbedingungen aber verwirrt war und
sich daher nicht an eine Veröffentlichung traute.

[Guido Scholz]

Torsten Vogt schrieb:

> Naja, mfx weicht soweit von MM ab, dass man das wohl als völlig
> eigenständiges Protokoll sehen muss und nicht als Protokollversion
> von MM.

> MM steht für Märklin Motorola, mfx hat damit nichts zu tun.

>> Dort wird auch das neuere M4-Format erwähnt

> Sowie Harald es schreibt ist mfx == M4. Und dieses M4 hat dann
> offensichtlich nichts mit dem SRCP-M4, also einer 4. Protokollversion
> von MM, zu tun.

> Wenn man mfx in SRCP aufnehmen will, muss man wohl einen neuen
> Protokollbuchstaben spendieren. Was wäre denn noch frei? 'X'?

Also steht das "M" beim GL/GA-Protokoll nicht für _M_ärklin, sondern
für _M_otorola? Das geht aus der SRCP-Definition nicht wirklich hervor.

Die schon erwähnten CAN-Bus-Protokolle wären dann C 1..3 oder fällt das
dann unter mfx, weil die Lokdecoder eingentlich CAN-Bus-Teilnehmer sind?

Ich frage absichtlich etwas verwirrend, da eines in der SRCP-Spezifikation
klar fehlt: Die Definition, was dieses Protokoll ist, und wie es abgegrenzt
wird. Diese Definition sollte klären, ob ein Mehr an Fahrstufen ein
neues Protokoll bzw. eine neue Version notwendig macht und auch, ob mehr
Funktionen den gleichen Effekt haben.

Vergessen sollte man auch nicht das Protokoll bei den GAs. Da kommt man
ja bislang ohne Version aus. Beim flüchtigen Lesen habe ich den Eindruck
gewonnen, dass es für mfx keine Schaltdecoder gibt; also wäre ein "X"
dort (noch) nicht zu erfinden.

[Harald Nikolisin]

Am 19.01.2012 21:13, schrieb Guido Scholz:
> Torsten Vogt schrieb:
>
>> Naja, mfx weicht soweit von MM ab, dass man das wohl als völlig
>> eigenständiges Protokoll sehen muss und nicht als Protokollversion
>> von MM.
>
>> MM steht für Märklin Motorola, mfx hat damit nichts zu tun.
>
>>> Dort wird auch das neuere M4-Format erwähnt
>
>> Sowie Harald es schreibt ist mfx == M4. Und dieses M4 hat dann
>> offensichtlich nichts mit dem SRCP-M4, also einer 4. Protokollversion
>> von MM, zu tun.
>
>> Wenn man mfx in SRCP aufnehmen will, muss man wohl einen neuen
>> Protokollbuchstaben spendieren. Was wäre denn noch frei? 'X'?
>
> Also steht das "M" beim GL/GA-Protokoll nicht für _M_ärklin, sondern
> für _M_otorola? Das geht aus der SRCP-Definition nicht wirklich hervor.

Ich weiß es auch nicht - heutzutage muß man es aber als "M"otorola
interpretieren, da es bei Märklin mehrere Formate gibt (mittlerweile
übrigens auch fast durchgängig DCC)

> Die schon erwähnten CAN-Bus-Protokolle wären dann C 1..3 oder fällt das
> dann unter mfx, weil die Lokdecoder eingentlich CAN-Bus-Teilnehmer sind?
>
> Ich frage absichtlich etwas verwirrend, da eines in der SRCP-Spezifikation
> klar fehlt: Die Definition, was dieses Protokoll ist, und wie es abgegrenzt
> wird. Diese Definition sollte klären, ob ein Mehr an Fahrstufen ein
> neues Protokoll bzw. eine neue Version notwendig macht und auch, ob mehr
> Funktionen den gleichen Effekt haben.

Das neue Protokoll wäre genau definiert "CAN Bus Protokolle für ehemals
Märklin Systems - heute Märklin Digital"
Nur CANBus ist zu wenig, denn Märklin ist nicht die einzigste Firma, die
diese Art der Kommunikation einsetzt.

Ausserdem ist dieses "CANBus für Märklin..." eine Art High-Level
Protokoll - der User der Schnittstelle (bspw. srcpd) weiß ja nicht, ob
der Gleisformatprozessor/die Zentrale am Ende das Low-Level Signal für
MM,DCC oder mfx/m4 erzeugt.

>
> Vergessen sollte man auch nicht das Protokoll bei den GAs. Da kommt man
> ja bislang ohne Version aus. Beim flüchtigen Lesen habe ich den Eindruck
> gewonnen, dass es für mfx keine Schaltdecoder gibt; also wäre ein "X"
> dort (noch) nicht zu erfinden.

Nein, es gibt keine Schaltdecoder welche mit mfx/m4 betrieben werden.

Gruß,
Harald

[Guido Scholz]

Andre Schenk schrieb:

> Für mich ist der Unterschied zwischen DDL (also "M" und "N") und den
> anderen Protokollen der, daß bei ersteren der srcpd das Digitalsignal
> selbst erzeugt. Insofern würde ich mfx da nicht dazuzählen, wenn ein
> CAN-Interface dazwischengeschaltet werden muß.

Wenn du dir mal die Programmierdokumentation für die ECos durch liest,
wirst du folgendes finden:

| set(id, protocol[val])
|
| Setzen des Protokolls. val kann folgende Werte annehmen:
| MM14, MM27, MM28, DCC14, DCC28, DCC128, SX32, MMFKT

D.h. die Zentrale bietet Funktionen an, bei denen man genau wissen muss,
welches Protokoll der anzusprechende Decoder versteht. Das Protokoll
wird hier übrigens schön sichtbar (nur) anhand der Fahrstufen unterschieden
(wie auch bei der Li100), aber nicht inklusive der Anzahl der Funktionen.

Die Handbuch-Version aus der das zitiert ist, hat Version 0.1 und ist
von 2007. Mittlerweile hat ESU mfx als M4 im Programm und ich fantasiere
mal, dass die aktuelle Programmierbeschreibung auch eine Option für "M4"
Decoder vorsieht. Das wäre jetzt noch nachzuweisen, aber ein klarer
Hinweis für die Notwendigkeit von mfx/M4 im SRCP.

Ich hätte übrigens auch gerne mal einen konkreten Fall gesehen, bei dem
das "P" zur Anwendung kommt. Die IB kann z.B. FMZ, SX, MM1, MM2, DCC??,
wird aber beim srcpd per P50X nur im DCC-Modus angesprochen. Warum? Die
OpenDCC kann nichts anderes, aber die IB?

[Torsten Vogt]

On 19 Jan., 21:13, Guido Scholz <guido.sch...@bayernline.de> wrote:
> Also steht das "M" beim GL/GA-Protokoll nicht für _M_ärklin, sondern
> für _M_otorola?

Als das 'M' im SRCP definiert wurde gab es nur 'Märklin Digital' auf
Motorola-Basis. Damals stand das 'M' eigentlich schon für Märklin.
Häufig spricht man ja auch von MM (Märklin Motorola), um
Missverständnisse zu vermeiden.

> Die schon erwähnten CAN-Bus-Protokolle wären dann C 1..3 oder fällt das
> dann unter mfx, weil die Lokdecoder eingentlich CAN-Bus-Teilnehmer sind?

Hmmmm, der CAN-Bus ist doch "nur" die Schnittstelle zwischen srcpd und
"Central Station 2" und nicht das "Gleisformat" (um mal im Märklin-
Jargon
zu schreiben). Bisher gibt es sowas im SRCP nicht, also Hinweise
auf die Protokollsprache zwischen Zentrale und srcp-Server. Über den
CAN-Bus bzw. CANviaUDP kann man übrigens auch MM-Befehle via CS2 aufs
Gleis schicken ....

> Ich frage absichtlich etwas verwirrend, da eines in der SRCP-Spezifikation
> klar fehlt: Die Definition, was dieses Protokoll ist, und wie es abgegrenzt
> wird.

Wohl eher "was _ein_ Protokoll ist und ..."

> Diese Definition sollte klären, ob ein Mehr an Fahrstufen ein
> neues Protokoll bzw. eine neue Version notwendig macht und auch, ob mehr
> Funktionen den gleichen Effekt haben.

ACK.

> Vergessen sollte man auch nicht das Protokoll bei den GAs. Da kommt man
> ja bislang ohne Version aus. Beim flüchtigen Lesen habe ich den Eindruck
> gewonnen, dass es für mfx keine Schaltdecoder gibt; also wäre ein "X"
> dort (noch) nicht zu erfinden.

Ja lustig, gell? Das "moderne" mfx-System schaltet die GA's mit dem
uralten
MM1-Protokoll. Bzw. im "Gleisformat" mfx gibt es gar keine
Möglichkeit,
GA's anzusprechen.

Gruß

Torsten

[Torsten Vogt]

On 19 Jan., 22:37, Guido Scholz <guido.sch...@bayernline.de> wrote:
> Das Protokoll
> wird hier übrigens schön sichtbar (nur) anhand der Fahrstufen unterschieden
> (wie auch bei der Li100), aber nicht inklusive der Anzahl der Funktionen.

Wie bereits beschrieben sind Martins Argumente, auch bzgl. Anzahl
der Funktionen Protokollversionen einführen zu müssen - wenn man
meinen Vorschlägen folgt - sehr akademisch. In den mir bekannten
Gleisformat-Protokollen (MM und DCC) ändert sich nix grundlegendes
am Signalgenerator, wenn mehr oder weniger Funktionen angesprochen
werden.

> Ich hätte übrigens auch gerne mal einen konkreten Fall gesehen, bei dem
> das "P" zur Anwendung kommt. Die IB kann z.B. FMZ, SX, MM1, MM2, DCC??,
> wird aber beim srcpd per P50X nur im DCC-Modus angesprochen. Warum? Die
> OpenDCC kann nichts anderes, aber die IB?

Irgendwer hat mal einen Client implementiert, der nur 'P' konnte. Ist
aber schon lange her, keine rechte Erinnerung mehr dran.

Gruß

Torsten

[Rainer Müller]

"Torsten Vogt" <vogt_t...@gmx.de> schrieb im Newsbeitrag
news:4e25af10-1eb4-48c5...@cf6g2000vbb.googlegroups.com...
> ... Ein srcpd-DDL-Modul für mfx erscheint mir aus
> heutiger Sicht nicht machbar. ...

Das müsste schon machbar sein. Ich erzeuge auf einem PC mit Standard-UART
mittels eigenem Windows Kernel-Mode-Treiber das Gleissignal auch für mfx.
(Signalerzeugung hängt sich in Timer-Interrupt und greift direkt auf UART
und Timer zu). Und was unter Windows (ohne SRCP) geht müsste auch irendwie
unter Linux gehen.

Allerdings stellt sich die Frage ob das sinvoll ist, weil
- Anpassung des Treibers an die Betriebssystemversionen
- immer weniger PCs mit Standard-UART (insbes. Laptops)
- für mfx ist ein RDS-Detektor zur Rückmeldung erforderlich

Gruß
Rainer

[Torsten Vogt]

On 20 Jan., 10:48, "Rainer Müller" <r...@gmx.net> wrote:
> Das müsste schon machbar sein. Ich erzeuge auf einem PC mit Standard-UART
> mittels eigenem Windows Kernel-Mode-Treiber das Gleissignal auch für mfx.

Aha. Also ist mfx sehr wohl dokumentiert oder reengeniert.
Gibt es dazu was im Internet?

> (Signalerzeugung hängt sich in Timer-Interrupt und greift direkt auf UART
> und Timer zu). Und was unter Windows (ohne SRCP) geht müsste auch irendwie
> unter Linux gehen.

> Allerdings stellt sich die Frage ob das sinvoll ist, weil
> - Anpassung des Treibers an die Betriebssystemversionen

Jow, ekelig.

> - immer weniger PCs mit Standard-UART (insbes. Laptops)

Naja, die vorhandene Basis an PCs ist enorm. Selbst mein
zwei Jahre alter Büro-PC hat noch einen COM-Port. Muss mal
schauen, was wir derzeit so einkaufen, aber ich glaube,
auch die Neuen haben immer noch einen.
Bei Pollin gibt es Schnittstellenkarten (2x ser, 1x par)
für unter 20,--.

> - für mfx ist ein RDS-Detektor zur Rückmeldung erforderlich

Ok. Das macht es natürlich schwierig.

Gruß

Torsten

[Rainer Müller]

"Torsten Vogt" schrieb im Newsbeitrag
news:444f0989-ac8e-462d...@d8g2000vbb.googlegroups.com...

> Aha. Also ist mfx sehr wohl dokumentiert oder reengeniert.

fürs Fahren und Programmieren von Lokdecodern reichts, evtl. fehlen noch ein
paar Spezialitäten

> Gibt es dazu was im Internet?

unsere Ergebnisse hat Stefan unter
http://www.skrauss.de/modellbahn/mdigital.html schön gefasst.

> Selbst mein zwei Jahre alter Büro-PC hat noch einen COM-Port.

bei großen Computern habe ich NOCH kein Problem, aber bei Laptops. Da sind
auch die Seriell-Schachtkarten vorzugsweise über USB angeschlossen.

>> - für mfx ist ein RDS-Detektor zur Rückmeldung erforderlich
> Ok. Das macht es natürlich schwierig.

Oder man macht das wie TAMS, dort als M3 bezeichnet. Kerstens Zentrale kann
keine Daten empfangen, sondern nur einfache Acknowledges. Vermutlich nutzt
er dazu den schon eingebauten DCC-ACK-Detector und verlässt sich darauf,
dass zur RDS-Rückmeldung die Stromaufnahme des Decoders steigt.
Damit kann man dann zwar die Anmeldung durchführen, aber keine
Programmierwerte auslesen.

Gruß
Rainer

[Torsten Vogt]

Hallo,

hier mal eine kurze Notiz, für alle, die noch mitlesen
und sich an dieser Stelle eventuell fragen, ob man derzeit
mfx-Dekoder mit DDL/DDW überhaupt benutzen kann oder nicht:
Ja, es geht! Das hängt damit zusammen, dass jeder bisher
ausgelieferte Märklin-Dekoder immer noch zusätzlich das
alte MM-Protokoll kann. Wem also 28 FS, 255 Adressen und
5 Funktionen reichen, kann alle mfx-Dekoder auch mit
DDL/DDW benutzen.

Wenn man weiterhin sieht, dass neuere Märklin-Dekoder auch
das DCC-Format unterstützen, würde ich die These aufstellen,
dass Märklin-Dekoder auch künftig irgendein Format untertützen
werden, das DDL/DDW aufs Gleis bringen kann.

Gruß

Torsten

[Andre Schenk]

Guido Scholz <guido....@bayernline.de> schrieb:

> Ich hätte übrigens auch gerne mal einen konkreten Fall gesehen, bei dem
> das "P" zur Anwendung kommt. Die IB kann z.B. FMZ, SX, MM1, MM2, DCC??,
> wird aber beim srcpd per P50X nur im DCC-Modus angesprochen. Warum? Die
> OpenDCC kann nichts anderes, aber die IB?

da bin ich nicht so sicher. Der srcpd verschickt die Lokbefehle mit "XLok".
Da ist keine Information enthalten, ob es sich um eine MM-, DCC- oder
Selectrix-Dekoder-bestückte Lok handelt. Ich nehme an, man muß vorher an
der IB eine Art Anmeldung der Lok machen und da das Protokoll festlegen.
Soweit finde ich das korrekt.

--
Tschüß André

[Guido Scholz]

Guido Scholz schrieb:

> Die Handbuch-Version aus der das zitiert ist, hat Version 0.1 und ist
> von 2007. Mittlerweile hat ESU mfx als M4 im Programm und ich fantasiere
> mal, dass die aktuelle Programmierbeschreibung auch eine Option für "M4"
> Decoder vorsieht. Das wäre jetzt noch nachzuweisen, aber ein klarer
> Hinweis für die Notwendigkeit von mfx/M4 im SRCP.

Das war nix. Auch in den aktuelleren Protokollbeschreibungen taucht
mfx/M4 nicht als eigenes Decoderprotokoll auf. Weder in der Version 0.2
von 2011,

<http://wiki.rocrail.net/lib/exe/fetch.php?id=ecos-en&cache=cache&media=ecos:ecos_pc_interface2.pdf>

noch in der Version 0.3 von 2011:

<http://wiki.rocrail.net/lib/exe/fetch.php?id=ecos-en&cache=cache&media=ecos:ecos_pc_interface3.pdf>

Die Ansteuerung der Loks bezüglich Geschwindigkeit und Funktionen
geschieht über eine numerische ID (16 Bit). Dennoch ist für diese Loks
eines der konventionellen Decoder-Protokolle zu konfigurieren. Man
könnte vielleicht von einem "Meta-Protokoll" sprechen. Damit gehört es
definitiv nicht in die SRCP M-Reihe.

Lesenswert sind ja wirklich die Lizenzbedingungen; man beachte auch den
Passus zum Verteilen der Protokolldokumentation.

[Andre Schenk]

Guido Scholz <guido....@bayernline.de> schrieb:

> Lesenswert sind ja wirklich die Lizenzbedingungen; man beachte auch den
> Passus zum Verteilen der Protokolldokumentation.

Da müßte man wohl ESU fragen, ob ein Modul für den srcpd als Einbau in
einen Client oder in einen Server verstanden wird. Das darf aber derjenige
machen, der das Modul bauen möchte. :-)

--
Tschüß André

[Jens Schmidt]

Andre Schenk schrieb:

> SRCP-N1: 14 FS -> DDL-N5, 28 FS -> DDL-N1, 128 FS -> DDL-N2
> SRCP-N2: 28 FS -> DDL-N3, 128 FS -> DDL-N5

Nur mal so als Zwischenfrage:

Und wo bleibt die Kombination 14 FS, lange Adresse? Ich kenne
keine Decoder (sofern sie überhaupt lange Adressen kennen), die
das nicht können. Zentralen auch nicht.
--
Viele Grüße,
Jens Schmidt

[Jens Schmidt]

Martin Schoenbeck schrieb:

> Sicher weiß ich das. Aber meine Lenz-Zentrale kann das beispielsweise
> nicht. Und ein SRCPD, der diese Zentrale ansteuert, von dem würde ich mir
> wünschen, daß er mir auf die Finger klopft, wenn ich ihm sage, er solle
> die lange Adresse 74 ansteuern. Wenn der SRCPD es hingegen kann, dann soll
> er es tun. Was er aber nicht tun soll, ist, die Lok mit der _langen_
> Adresse 74 ansteuern. Was aber der SRCPD tut, für den die Liste von André
> paßt.

Du wolltest beim unterstrichenen Wort _kurzen_ schreiben, oder?

>> Jetzt lese ich hier, dass einige DCC-Zentralen
>> nicht mal in der Lage sind, Adressen unter 128 als lange Adressen
>> zu verwenden. Nun gut, aber was können wir für die Faulheit der
>> Programmierer?

Der gesamte Bereich von 100 bis 127 ist je nach Zentrale unmöglich, immer
mit kurzen Adressen, immer mit langen Adressen oder frei konfigurierbar.

> Das hat mit Sicherheit nichts mit Faulheit zu tun. Sondern damit, daß der
> Otto-Normal-Bediener einfach nicht versteht, daß es hier unterschiedliche
> Längen gibt. Der sagt seiner Zentrale "programmier die Lok auf Adresse xy"
> und dann macht die Zentrale das. Allenfalls kann man ihm noch klarmachen,
> daß an bestimmten Zentralen nur Adressen bis 100 oder 127 gehen und dann
> wird die Zentrale, die mehr kann, bei solchen Adressen kurze Adressen
> vergeben, so daß die Loks auch an solchen Zentralen laufen, die lange
> Adressen nicht können.

Ersetze 100 durch 99. WIMRE ist Lenz der einzige, der das richtig[TM]
vermurkst hat. Bei ihm sind 100..9999 dann lang. Alle(?) anderen legen die
Grenze für das von Dir korrekt beschriebene Verhalten zwischen 127 und 128.

> Nein, es _ist_ unnötig. Aber nicht, weil die Zentrale das weiß, sondern
> weil es innerhalb der gleichen Adressierung (lang / kurz) nur zwei
> unterschiedliche Geschwindigkeitsbefehle sind. Die man zur Not auch munter
> mischen dürfte. *grusel*

Eigentlich ja. Wie immer gibt es jedoch auch fehlerhafte Implementierungen.
Es gibt da Decoder, die ihren Nothalt immer als 28 FS-Variante haben wollen,
auch wenn sie ansonsten mit 128 FS betrieben werden. Oder war das andersrum,
dass sie also 28 FS-Nothalt nicht verstehen, wenn sie vorher mit 128 FS
gefahren sind? Egal, auf jeden Fall :-(((.

[Martin Schoenbeck]

Hallo Jens,

Jens Schmidt schrieb:

Für irgendwas muß ja noch DDL-N4 gut sein. *duck*

Aber im Ernst: kennst Du jemand, der _das_ benutzt? Will man das?

[Martin Schoenbeck]

Hallo Jens,

Jens Schmidt schrieb:

> Martin Schoenbeck schrieb:
>
>> Sicher weiß ich das. Aber meine Lenz-Zentrale kann das beispielsweise
>> nicht. Und ein SRCPD, der diese Zentrale ansteuert, von dem würde ich mir
>> wünschen, daß er mir auf die Finger klopft, wenn ich ihm sage, er solle
>> die lange Adresse 74 ansteuern. Wenn der SRCPD es hingegen kann, dann soll
>> er es tun. Was er aber nicht tun soll, ist, die Lok mit der _langen_
>> Adresse 74 ansteuern. Was aber der SRCPD tut, für den die Liste von André
>> paßt.
>
> Du wolltest beim unterstrichenen Wort _kurzen_ schreiben, oder?

Ist schon ein paar Tage her, aber das ist die einzige Variante, die Sinn
ergibt.

>> Das hat mit Sicherheit nichts mit Faulheit zu tun. Sondern damit, daß der
>> Otto-Normal-Bediener einfach nicht versteht, daß es hier unterschiedliche
>> Längen gibt. Der sagt seiner Zentrale "programmier die Lok auf Adresse xy"
>> und dann macht die Zentrale das. Allenfalls kann man ihm noch klarmachen,
>> daß an bestimmten Zentralen nur Adressen bis 100 oder 127 gehen und dann
>> wird die Zentrale, die mehr kann, bei solchen Adressen kurze Adressen
>> vergeben, so daß die Loks auch an solchen Zentralen laufen, die lange
>> Adressen nicht können.
>
> Ersetze 100 durch 99.

Interpretiere 'bis' bei Bedarf einfach nicht als 'bis einschließlich'. ;-)

> WIMRE ist Lenz der einzige, der das richtig[TM]
> vermurkst hat. Bei ihm sind 100..9999 dann lang. Alle(?) anderen legen die
> Grenze für das von Dir korrekt beschriebene Verhalten zwischen 127 und 128.

Das dürfte daran liegen, daß Lenz vorher schon Handregler hatte, die damals
nur zwei Ziffern für die Loknummer anzeigten und deshalb nur bis 99
konnten. Wenn man die Zahlen irgendwie in ein Baureihenschema o.ä. packen
will, kann man mit 100 - 127 ohnehin nichts anfangen und 99 Loks sind mehr
als genug. Man kennt ja solche Überlegungen. Dafür dann eine Stelle auf
einem ohnehin knappen Display opfern? Da war es dann nur logisch, daß man
die neuen Adressen ab der ersten bis dahin nicht belegten verwendet hat.

>> Nein, es _ist_ unnötig. Aber nicht, weil die Zentrale das weiß, sondern
>> weil es innerhalb der gleichen Adressierung (lang / kurz) nur zwei
>> unterschiedliche Geschwindigkeitsbefehle sind. Die man zur Not auch munter
>> mischen dürfte. *grusel*
>
> Eigentlich ja. Wie immer gibt es jedoch auch fehlerhafte Implementierungen.
> Es gibt da Decoder, die ihren Nothalt immer als 28 FS-Variante haben wollen,
> auch wenn sie ansonsten mit 128 FS betrieben werden. Oder war das andersrum,
> dass sie also 28 FS-Nothalt nicht verstehen, wenn sie vorher mit 128 FS
> gefahren sind? Egal, auf jeden Fall :-(((.

Murks gibt's immer.

[Jens Schmidt]

Andre Schenk schrieb:

> http://bonus.dyndns.org/mediawiki/index.php/SRCPD-GenericLocoDevices

Ich habe mir das mal angesehen. Ein kleiner Fehler bei DCC: die 0 ist auch
eine gültige lange Adresse laut NMRA-Spec. Und nein, ich kenne bisher keine
Zentrale, die das auch verwenden kann.

[Torsten Vogt]

On 23 Jan., 10:12, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
wrote:

> Für irgendwas muß ja noch DDL-N4 gut sein. *duck*

Wenn, dann bitte richtig ablästern: Du meinst DDL-N5 ;-)

N5 war zu Urzeiten mal NB und das stand für NMRA-DCC Basisprotokoll.
Also kurze Adressen und 14 FS, keine Funktionen
Mir hat es damals dazu gedient, erste Pakete für DCC zu generieren,
die jeder Dekoder verstehen muss. Wie Du selbst schreibst, hat das
wohl keine Relevanz in der Anwendung.

Gruß

Torsten

[Martin Schoenbeck]

Hallo Torsten,

Torsten Vogt schrieb:

> On 23 Jan., 10:12, Martin Schoenbeck <ms.usenet.nos...@schoenbeck.de>
> wrote:
>> Für irgendwas muß ja noch DDL-N4 gut sein. *duck*
>
> Wenn, dann bitte richtig ablästern: Du meinst DDL-N5 ;-)

Nee, ich meinte N4, weil das in der Umsetztabelle von André, die Jens
zitierte, fehlt. N5 hat er doppelt, das müssen wir abziehen. ;-)

> N5 war zu Urzeiten mal NB und das stand für NMRA-DCC Basisprotokoll.
> Also kurze Adressen und 14 FS, keine Funktionen

eine Funktion (Licht)

> Mir hat es damals dazu gedient, erste Pakete für DCC zu generieren,
> die jeder Dekoder verstehen muss. Wie Du selbst schreibst, hat das
> wohl keine Relevanz in der Anwendung.

In der Form sicherlich noch. Zumindest ich habe durchaus noch Dekoder, die
nur das verstehen (plus die 27 Fahrstufen mit den wechselnden Befehlen).
Aber daß jemand 14 Fahrstufen bei einem Dekoder einsetzt, der garantiert
auch 28 kann (sonst hätte er kaum lange Adressen), das scheint mir doch
hinreichend unwahrscheinlich.

[Andre Schenk]

Jens Schmidt <Jens.Sc...@gmx.de> schrieb:

> Ich habe mir das mal angesehen. Ein kleiner Fehler bei DCC: die 0 ist auch
> eine gültige lange Adresse laut NMRA-Spec. Und nein, ich kenne bisher keine
> Zentrale, die das auch verwenden kann.

Ist das nicht auch wie bei den kurzen Adressen die Broadcast-Adresse?

--
Tschüß André

[Andre Schenk]

Jens Schmidt <Jens.Sc...@gmx.de> schrieb:

>> SRCP-N1: 14 FS -> DDL-N5, 28 FS -> DDL-N1, 128 FS -> DDL-N2
>> SRCP-N2: 28 FS -> DDL-N3, 128 FS -> DDL-N5
>

> Und wo bleibt die Kombination 14 FS, lange Adresse? Ich kenne
> keine Decoder (sofern sie überhaupt lange Adressen kennen), die
> das nicht können. Zentralen auch nicht.

Der Spec folgend müßte das auch SRCP-N2 sein. Ob der DDL-Code im srcpd das
kann, weiß ich aber nicht.

--
Tschüß André

[Jens Schmidt]

Andre Schenk schrieb:

Nein, Broadcast gibt es nur als kurze 0. Siehe RP 9.2.1, Abschnitt A.

[Andre Schenk]

Jens Schmidt <Jens.Sc...@gmx.de> schrieb:

>>> Ich habe mir das mal angesehen. Ein kleiner Fehler bei DCC: die 0 ist
>>> auch eine gültige lange Adresse laut NMRA-Spec. Und nein, ich kenne
>>> bisher keine Zentrale, die das auch verwenden kann.

>> Ist das nicht auch wie bei den kurzen Adressen die Broadcast-Adresse?

> Nein, Broadcast gibt es nur als kurze 0. Siehe RP 9.2.1, Abschnitt A.

Das ist ja kraß, dann gibt es Adresse 0 zweimal (einmal kurz = Broadcast
und einmal lang = normale Adresse).

Nun soll meine Wikiseite ja den Istzustand im srcpd beschreiben. Ich habs
eben probiert: INIT 2 GL 0 N 2 128 28 mag er nicht.

Ist denn die Adresse 0 lang ein "must to have"?

--
Tschüß André

[Torsten Vogt]

On 23 Jan., 19:50, Andre Schenk <an...@melior.s.bawue.de> wrote:
> Das ist ja kraß, dann gibt es Adresse 0 zweimal

jede Adresse unterhalb von 128 gibt es zweimal.

> (einmal kurz = Broadcast und einmal lang = normale Adresse).

das ist halt so definiert.

> Ist denn die Adresse 0 lang ein "must to have"?

Vermutlich sind mehr als 10.000 Adressen selbst fürs
MiWuLa Luxus ;-)

Torsten

[Jens Schmidt]

Andre Schenk schrieb:

> Nun soll meine Wikiseite ja den Istzustand im srcpd beschreiben. Ich habs
> eben probiert: INIT 2 GL 0 N 2 128 28 mag er nicht.

Ich vermute mal, das ist über die Änderung einer Abfrage im srcpd zu
korrigieren. Die Pakete sind ja genauso aufgebaut wie die übrigen.

> Ist denn die Adresse 0 lang ein "must to have"?

Nein. Ich kenne keine kommerzielle Zentrale, die das kann. Nicht einmal
lange Adressen unter 100/128 können die meisten. Ich kenne da nur WIMRE
NCE als Ausnahme. Das selbe Problem auch mit 10000 bis 10239.

Das ist eher was für Leute mit "Open Source ist besser". Und es ist
eine triviale Änderung. Nur ordentlich dokumentiert muss es eben werden.
Aber Leute, die srcpd verwenden, sind wahrscheinlich sowieso nicht gerade
die selben wie die, die die Doku erst lesen, wenn nichts geht.

[Jens Schmidt]

Torsten Vogt schrieb:

> Vermutlich sind mehr als 10.000 Adressen selbst fürs
> MiWuLa Luxus ;-)

Ich kann ja demnächst mal direkt Fragen. Ich bin demnächst
vor Ort.

Wer wirklich damit Probleme bekommt, ist in nächster Zeit
die H0-Fraktion im FREMO. Da die Adressen nicht für jedes
Treffen neu vergeben werden, wird es langsam knapp. Leider
können auch H0-USA wegen Testfahrten und H0m/H0e wegen
Dreischienengleis keine Doppelbelegungen machen.

[Torsten Vogt]

On 23 Jan., 23:27, Jens Schmidt <Jens.Schmidt...@gmx.de> wrote:
> Wer wirklich damit Probleme bekommt, ist in nächster Zeit
> die H0-Fraktion im FREMO. Da die Adressen nicht für jedes
> Treffen neu vergeben werden, wird es langsam knapp.

Naja, der Anspruch auf lebenslange feste Dekoder-Adressen
erscheinen mir auch als eine Art Luxusproblem.

Man könnte das im Vorfeld eines jeden Fremo-Treffens
organisatorisch lösen. Klar, ist Aufwand, aber eine
weitere Dekoder-Adresse hilft da auch nicht wirklich
weiter.

Gruß

Torsten

[Lothar Roth]

Hallo,

Am 23.01.2012 19:59, schrieb Torsten Vogt:
> On 23 Jan., 19:50, Andre Schenk<an...@melior.s.bawue.de> wrote:
>> Das ist ja kraß, dann gibt es Adresse 0 zweimal
>
> jede Adresse unterhalb von 128 gibt es zweimal.

Derzeit läuft die interne Zentrale des SRCPD ja (noch?) mit einem Bus
für alle Protokolle.
Was liefert denn eine Anfrage
GET <bus> GL <addr>
in als Antwort zurück, wenn es zu <addr> eine Lok mit kurzer, langer und
womöglich auch mit MM-Adresse gibt?

Dito bei
GET <bus> GA <addr> <port>
wenn es MM-, DCC-, Selectrix-Zubehördekoder gibt (und die Zentrale mit
den gleichen Adress/Port-Kombinationen auf mehreren Protokollen umgehen
kann).

Da müßten dann wohl entweder die Protokolle/Protokollvarianten auf
mehrere Busse verteilt werden (IMHO nicht ganz so toll) oder die
Spezifikation erweitert werden.
Ich bevorzuge weiterhin eine "logische" Zentrale (ein Bus) für alle Loks
einer "physischen" Zentrale zu verwenden.

<spekulation>
Ich vermute mal, daß die meisten am Markt in größerene Stückzahlen
vorhandenen Multiprotokollzentralen jede Adresse nur einmal zulassen
(aber mit beliebigem/sinnvollen Protokoll) und man durch diese
"Einschränkung" wohl nicht zu viele Möglichkeiten verbaut(und auch die
Supportanfragen reduziert).
</spekulation>

Die TamsMC z.B. läßt jede Lokadresse nur einmal zu, dann aber jedes
unterstütze/sinnvolle Protokoll zur Auswahl. Bei den Zubehördecodern ist
das Protokoll (MM/DCC) "nur" in 4er-Blöcken zuweisbar.

Gegenbeispiel:
In der Märklin CS2 kann man Loks sowohl mit Motorola als auch DCC
anlegen, das kann manchmal aber sehr seltsame Auswirkungen auf das
Verhalten der Loks/Decoder haben. Bei einem Kollegen habe ich folgendes
erlebt: MM2 Lok fuhr problemlos, die Front-/Rücklichtlicht-LEDs
pulisierten jedoch immer wie bei einseitig an Masse angeschlossenen
Glühbirnchen mit MM1 am Gleis. Ich hatte den Decoder/Verkabelung in
Verdacht, aber alles OK.
Erst als er eine DCC-Lok mit gleicher Adresse, die inzwischen verkauft
und deshalb monatelang nicht mehr aufgerufen war aus der Lokdatenbank
gelöscht hat war der Spuk vorbei.


Gruß,
Lothar

[Martin Schoenbeck]

Hallo Lothar,

Lothar Roth schrieb:

> Derzeit läuft die interne Zentrale des SRCPD ja (noch?) mit einem Bus
> für alle Protokolle.
> Was liefert denn eine Anfrage
> GET <bus> GL <addr>
> in als Antwort zurück, wenn es zu <addr> eine Lok mit kurzer, langer und
> womöglich auch mit MM-Adresse gibt?

Auf einem Bus kann es nicht mehrere Loks mit gleicher Adresse geben. Ich
würde erwarten, daß die erste gewinnt und danach Fehler kommen oder die
jeweils letzte Anmeldung überschreibt die vorherige.

> Dito bei
> GET <bus> GA <addr> <port>
> wenn es MM-, DCC-, Selectrix-Zubehördekoder gibt (und die Zentrale mit
> den gleichen Adress/Port-Kombinationen auf mehreren Protokollen umgehen
> kann).

Eben: dto.

> Da müßten dann wohl entweder die Protokolle/Protokollvarianten auf
> mehrere Busse verteilt werden

Genau so ist das gedacht.

> (IMHO nicht ganz so toll)

Nur, wenn man unter dem Bus irgendwas physikalisches verstehen will.

> oder die
> Spezifikation erweitert werden.

In welcher Form? Wenn Du die gewünschte Lok nicht allein über ihre Adresse
auswählen kannst, müßtest Du das Protokoll mit angeben. Genau _das_ soll ja
mit den Bussen vermieden werden. Der Client soll nicht wissen müssen, wie
die Lok anzusteuern ist.

> Ich bevorzuge weiterhin eine "logische" Zentrale (ein Bus) für alle Loks
> einer "physischen" Zentrale zu verwenden.

Das geht ja bei vielen Zentralen auch. Nämlich bei all denen, die ohnehin
nur eine Lok unter einer Nummer erlauben. Aber man kauft sich eben damit
den Nachteil ein, daß man Loks mit gleicher Nummer nicht verwalten kann.
Hinter dem Bus im SRCP steht deshalb bewußt nicht die Idee, eine Zentrale
mit genau einem Bus anzusteuern. Ein Bus trennt Adressräume. Er _kann_ auch
zusätzlich physikalische Gegebenheiten abbilden, aber auch dann trennt er
immer Adressräume.

[Guido Scholz]

Lothar Roth schrieb:

> Hallo,

Hallo Lothar,

> Derzeit läuft die interne Zentrale des SRCPD ja (noch?) mit einem Bus
> für alle Protokolle.

das ist jetzt etwas merkwürdig ausgedrückt, denn von einer "internen"
Zentrale kann man eigentlich nur im Falle des DDL-Moduls sprechen. Die
anderen Module haben im Prinzip nur eine Übermittlerrolle, die aber
nicht immer ganz interpretationsfrei ist, wie z.B. bei der IB.

> Was liefert denn eine Anfrage
> GET <bus> GL <addr>
> in als Antwort zurück, wenn es zu <addr> eine Lok mit kurzer, langer und
> womöglich auch mit MM-Adresse gibt?

Das kommt darsuf an, mit welchem Protokoll du die Adresse initialisiert
hast (INIT <bus> GL <addr> <prot etc.>). Eine Ansprache ohne
Initialisierung gibt in der Regel eine Fehlermeldung (ich hoffe, es gibt
hierbei keine Ausnahme). Was natürlich nur logisch ist.

> Dito bei
> GET <bus> GA <addr> <port>
> wenn es MM-, DCC-, Selectrix-Zubehördekoder gibt (und die Zentrale mit
> den gleichen Adress/Port-Kombinationen auf mehreren Protokollen umgehen
> kann).

Hier gibt es "INIT <bus> GL <addr> <protcol>", siehe auch hier:

http://srcpd.sourceforge.net/srcp/srcp-084.html

> Da müßten dann wohl entweder die Protokolle/Protokollvarianten auf
> mehrere Busse verteilt werden (IMHO nicht ganz so toll)

So ist es, wie weiter oben (historisch gesehen) schon erwähnt.

> oder die
> Spezifikation erweitert werden.

Wobei das dann einen ordentlichen Versionssprung nach sich ziehen
müsste. Eine Adressierung per "IDs" ist schon mal diskutiert worden.

> Ich bevorzuge weiterhin eine "logische" Zentrale (ein Bus) für alle Loks
> einer "physischen" Zentrale zu verwenden.

Tja, dann kommst du mit dem aktuellen SRCP nur beschränkt zurecht.

><spekulation>
> Ich vermute mal, daß die meisten am Markt in größerene Stückzahlen
> vorhandenen Multiprotokollzentralen jede Adresse nur einmal zulassen
> (aber mit beliebigem/sinnvollen Protokoll) und man durch diese
> "Einschränkung" wohl nicht zu viele Möglichkeiten verbaut(und auch die
> Supportanfragen reduziert).
></spekulation>

Da bin ich mir nicht sicher; ich vermute eher, die Mehrheit befindet
sich auf der anderen Seite.

[Torsten Vogt]

Hi,

Am 24.01.2012 16:39, schrieb Martin Schoenbeck:
[...]

> Der Client soll nicht wissen müssen, wie die Lok anzusteuern ist.

Genau! Er lebt stattdessen mit einer guten Portion Halbwissen. ;-)

*duck und weg*

Gruß

Torsten

--- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---