Hallo liebes Forum,

angeregt durch den hier die letzten Tage aus dem Ruder gelaufenen Thread:
"Muss digitale Modellbahn notwendig auf den Computer zurückgreifen?"
habe ich dieses Thema hier aufgemacht. An einigen Stellen konnte man in dem genannten Thread lesen, dass es bei Softwaresteuerung, die ja bekanntlich auf einem Computer oder computerähnlichen Teil (Raspberry usw) läuft, eigentlich um die automatische Zugbeeinflussung geht. In eineigen Punkten eine durchaus interessantes Thema, wie ich finde ...

Der Langtitel für diesen Thread hier sollte somit wie folgt lauten:
Gibt es neben einer Steuerung nach dem Prinzip SW-Steuerung weitere Möglichkeiten eine digitale automaitsche ortsfeste Zugbeeinflussung umzusetzen?

Ja oder Nein:
Was wären/sind die konzeptionellen Unterschiede? (Vor- und Nachteile?)


Nein:
Warum macht eine andere Steuerung bspw. auch keinen Sinn?
bzw.
Wünschen die meisten Modellbahner ohne Softwaresteuerung, so eine Funktion eher nicht?


In diesem Zusammenhang wurde von Wolf in dem anderen Thread folgender Link geteilt:
http://www.zukunft-mobilitaet.net/90799/...chteile-streik/ so lise sich auch ein Vergleich der automatisierten Zugsteuerung in Realität und im Modell ziehen.


Ich möchte alle die sich für Fragen dieser Art interessieren dazu einladen, hier etwas beizusteuern. Ich möchte auch gleichzeitig darum Bitten, von persönlichen Feden und Streitigkeiten abzusehen. In diesem Sinne wünsche ich allen Beteiligten und Interessenten eine sachliche, informative und niveauvolle Diskussion.



Grüße vom Rand der Platte

Jonas


__________________________________________________
Begriffserklärungen:
automaitsche ortsfeste Zugbeeinflussung:
Ein Zug wird an einer definierten Stelle der Strecke automatisch in seinem Fahrverhalten beeinflusst. Z.B. verlangsamt er ggf. seine Geschwindigkeit in einem Abschnitt, für den ein Hp2 Signal gilt oder er bremst und bleibt stehen in einem Abschnitt für den ein Hp0 Signal gilt.

Prinzip SW-Steuerung:
Eine Steuerung, die nach dem Prinzip funktioniert, dass Sensoren in der Anlage einer Software mitteilen, wo, in welchem Streckenabschnitt, sich ein Zug befindet, um diesen dann gezielt - wie ein Mensch bei manuellem Betrieb - zu steuern.

Computer:
Damit muss in diesem Zusammenhang nicht zwingend ein herkömmlicher PC/Laptop gemeint sein, der Begriff schließt ebenso miniPC, Ein-Platinen-Computer und Computer-Zentralen ein.

Hallo Jonas,

Danke, dass Du Dich gleich mit Deiner Fragestellung um Definitionsklarheit sorgst.
__________________________

Zitat

---

________________________
Begriffserklärungen:

Computer:
Damit muss in diesem Zusammenhang nicht zwingend ein herkömmlicher PC/Laptop gemeint sein, der Begriff schließt ebenso miniPC, Ein-Platinen-Computer und Computer-Zentralen ein.
[/size]

---

d.h. eine CS2, CS3 oder ECoS sind ebenfalls Computer mit entsprechender Software im Sinne Deiner Frage? Der Viessmann Commander 1 gehört auch dazu?
Eine Z21 zusammen mit der Z21APP würde - falls die Kombination in einer zukünftigen Version Dein Problem überhaupt lösen könnte - nicht dazu gehören?

MfG

vik

Hallo Jonas,
es gibt, hängt von dem Digitalprotokoll ab, die ABC-Bremsbausteine (z.B. Lenz BM1, BM2, BM3) oder bei Märklin das Bremsen mit Gleichspannung, entweder von Märklin oder Bogobit. Wenn die Funktion im Decoder aktiviert ist dann bremst z.B. ein Zug vor einem Langsamfahrt zeigenden Signal ab.
Alles ohne PC.
Volker

Hallo zusammen,

Noch eine sehr genaue Nachfrage.
Ist die Langsamfahrt ebenfalls zwingende Voraussetzung?

Dann fällt ja ein Großteil an Möglichkeiten im Vorfeld raus.

MfG Oliver

Hallo Vik,

Zitat

---

d.h. eine CS2, CS3 oder ECoS sind ebenfalls Computer mit entsprechender Software im Sinne Deiner Frage? Der Viessmann Commander 1 gehört auch dazu?

---

Ja, ich denke schon. Das wichtige in dem Zusammenhang ist eigentlich, dass die Computer-Zentrale über Sensoren in der Anlage und einem virtuellen Gleisplan, die Loks als "automatischer Lokführer" steuert. So, oder so ähnlich kam das in dem anderen Thread raus ...?

Eine Z21 mit App könnte also m.E. schon auch dazu gehören, oder?


Grüße vom Rand der Platte

Jonas

Hallo Volker,

leider haben all die von dir aufgeführten Methoden das "Problem", dass sie im Grunde nicht digital funktionieren. Es sind technisch gesehen analoge Hilfslösungen, die mache Decoder intelligenterweise messen und auswerten können.
Alles was sich auch hier in diesem Miba Artikel findet, ist mir bekannt.
http://www.zimo.at/web2010/aboutus/miba_extra0510b.pdf




Hallo Oliver,

es geht um die grundsätzliche autom. ortsgebundene Zugbeeinflussung (digitalkonform). Das würde also auch Hp2 mit einbeziehen.
Aber auch so etwas wie Sh0/1 usw.



Grüße vom Rand der Platte


Jonas

Hallo Jonas,

Zitat

---

Zitat

---

d.h. eine CS2, CS3 oder ECoS sind ebenfalls Computer mit entsprechender Software im Sinne Deiner Frage? Der Viessmann Commander 1 gehört auch dazu?

---

Ja, ich denke schon. Das wichtige in dem Zusammenhang ist eigentlich, dass die Computer-Zentrale über Sensoren in der Anlage und einem virtuellen Gleisplan, die Loks als "automatischer Lokführer" steuert. So, oder so ähnlich kam das in dem anderen Thread raus ...?

---

Ja, alle diese Zentralen können ohne PC-Unterstützung - bestimmte Aktionen von Weichen und Loks initieren, in Abhängigkeit vom Zustand der Sensoren. Eigentlich gehören auch 6021 mit Memory 6043 und TwinCenter und Intellibox noch dazu, allerdings mit - aus heutiger Sicht - recht umständlich zu bedienenden Benutzeroberflächen.

Zitat

---

Eine Z21 mit App könnte also m.E. schon auch dazu gehören, oder?

---

Leider gab es diese Möglichkeit - Aktionen in Abhängigkeit vom Zustand der Rückmelder auszuführen - zumindest mit den Versionen bis zum 25. März 2020 noch nicht.
Hat schon jemand diesbezügliche Erfahrungen mit der aktuellen Version der Z21App?

MfG

vik

Hallo Vik,

Danke für deine Erklärung. Also heißt das, dass all diese "Computer"-Zentralen, wenn man sie so nennen darf, auch alle mit dem Prinzip einer PC-Softwaresteuerung eine autom. ortsgebundene Zugbeeinflussung vornehmen, oder?

Konkret, wenn ich atuom. digit. Signalhalt möchte:
An der Stelle am GLeis, wo bspw. ein einfaches Blocksignal steht, ist in der Nähe ein Sensor (Schaltgleis, Reed-Kontakt, GBM, ...) eingebaut.
Für die Zentrale ist es dann einfach nur eine "Wenn-Dann-Funktion": Wenn das Signal auf rot geschalten ist, und der Sensor eben an diesem Streckenabschnitt auslöst, dann bremst die Zentrale das auslösende Triebfahrzeug ab. (Sendet FS0 oder so ...?)
Richtig?

So, oder so in etwa, ergibt sich dann ein autmatscher Signalhalt. Und das Ganze funktioniert komplett digital. Am Gleis ist halt ein oder evtl. werden zwei Sensoren nötig.

Stimmt das so, oder habe ich etwas vergesen?

Auf die selbe Weise ist dann natürlich prinzipiell auch jede andere Streckeninformation, wie Hp2 oder so, schaltbar.


Grüße vom Rand der Platte

Jonas

Uhlenbrock LISSY/MARCo

https://www.uhlenbrock.de/de_DE/produkte...4B051AF-001.htm


Klaus

Hallo Klaus,

das Uhlembrock System mit den Marco Railcom-Modulen kenne ich. Es funktioniert praktisch auch wie eine herkömmliche Softwaresteuerung in etwa so, wie ich das in meinem vorherigen Post geschildert habe. Oder sollte ich mich da getäuscht haben?

In der Zentrale ist praktisch ein mini Computer. Es reiht sich also im Prinzip doch zur Ecos, CS2/3, Commander usw. ein ...?



Grüße vom Rand der Platte,

Jonas

Hallo Jonas,

Zitat

---

das Uhlembrock System mit den Marco Railcom-Modulen kenne ich.

---

was meinst Du mit "kenne ich"?

"das habe ich selbst schon mal eingesetzt" oder
"davon habe ich auch schon mal gehört"

davon abhängig müßte die Antwort ganz unterschiedlich ausführlich ausfallen...

MfG

vik

Zitat

---

das Uhlembrock System mit den Marco Railcom-Modulen kenne ich. Es funktioniert praktisch auch wie eine herkömmliche Softwaresteuerung in etwa so, wie ich das in meinem vorherigen Post geschildert habe. Oder sollte ich mich da getäuscht haben?

In der Zentrale ist praktisch ein mini Computer. Es reiht sich also im Prinzip doch zur Ecos, CS2/3, Commander usw. ein ...?

---

Von meiner wissen sendet die Modulen nur Kommandos bis der zentrale um die Geschwindigkeit zu ändern oder weichen setzen.

Es ist autonomes System, wer nutzen der Loconet zu kommunizieren mit einander (und der zentrale).

https://www.uhlenbrock.de/de_DE/produkte...1720D18-001.htm
"Der MARCo-Empfänger enthält zwei RailCom®-Detektoren zur Überwachung von jeweils einem Gleisabschnitt und eine Intelligenz, die selbständig Schaltvorgänge ausführen kann. Die Verbindung zur Digitalzentrale erfolgt über das LocoNet. Sollen einfache Schaltfunktionen fahrtrichtungsunabhängig ausgeführt werden, so kann ein Modul zwei Gleisabschnitte überwachen. Dabei werden lediglich die Adresse der vorbeifahrenden Lok übermittelt und einfache Schaltaufgaben ausgeführt. An Stellen, an denen eine fahrtrichtungsabhängige Automatikfunktion ausgeführt werden soll, werden die beiden Gleisabschnitte eines Detektors hintereinander ins Gleis eingebaut. So wird zusätzlich zur Adresse die Fahrtrichtung erkannt und die Automatik kann den Zug zielgenau im zweiten Abschnitt anhalten."


Für mich ist es doch ganz egal. Vollen ich Automatik haben ist der einfachsten Methode ein Computer zu nutzen.
Alles andere methoden bedeutet unglaublich viel zeit mit Relais, Verdrahtung, usw.


Klaus

Hallo Vik,

ich habe dieses System vor Jahren auf einer Messe (bin nicht mehr sicher, auf welcher) am Stand von Uhlenbrock vorgeführt bekommen. --> also live gesehen etc.

Dann habe ich auf der UB Homepage darüber gelesen, ein wenig in der BDA gestöbert und zu guter letzt hier im Froum darüber gelesen.

Selber, also ich an meiner Anlage, habe es noch nicht eingesetzt oder irgendwelche Erfahrungen damit gemacht.


Hallo Klaus,

danke für deine Erklärung. Ich habe die Informationen zu diesem System auf der Uhlebrock Homepage schon einmal gelesen.
Das System nutzt vom Prinzip her die gleiche Methode wie "jede" andere Softwareautomatik. Unterschied, man sieht den "Computer" nicht wirklich und es ist im Vergleich etwas teurer.
Darum gebe ich dir Recht, wenn ich eine Automatik wünsche, dann liegt der Griff zu einer Softwaresteuerung (Computer) näher - für mich jedenfalls. Allerdings brauche ich diese Lösung bereits dann, wenn ich lediglich wünsche, dass eine Lok automatisch vor einem roten Signal hält (digital-konform versteht sich), ohne großartig weitere Automatikfunktionen zu wollen.

Aus diesem Grund finde ich die Fragestellung dieses Threads eben interessant. Auch wenn ich mittlerweile glaube, dass es keine andere Lösung gibt. Man muss das immer mit der Methode "Softwaresteuerung" erledigen, auch wenn man hier und da den Computer als solchen vielleicht nicht sieht.


Grüße vom Rand der Platte,

Jonas

Hallo Jonas,

Zitat

---

Allerdings brauche ich diese Lösung bereits dann, wenn ich lediglich wünsche, dass eine Lok automatisch vor einem roten Signal hält (digital-konform versteht sich), ohne großartig weitere Automatikfunktionen zu wollen.

---

Nein, wenn Du willst:
"dass eine Lok automatisch vor einem roten Signal hält (digital-konform versteht sich)"
dann benötigst Du keinen Computer als Zentralsteuerung. Selbst mit mehreren Loks wirst Du das mit den richtigen Decodern und den passenden Bremsgeneratoren - auch ohne Computer - so hinbekommen, dass alle Loks einigermaßen passend halten.
Wenn dieselben Loks aber mal mehr oder weniger viele Wagen ziehen, wird es schon schwieriger. Auf jeden Fall benötigst Du recht viel Platz für lange Brems- und Halteabschnitte mit der notwendigen Reserve. Wenn die Wagen beleuchtet sein sollen, gibt es neue Schwierigkeiten, die zusätztlich gelöst werden müssen.
Es ist die Technik der Neunziger. Sie funktioniert, ist aber nicht so präzise und bei weitem nicht so flexibel. Z.B. sind Rangierfahrten damit i.d. R. nicht zu realisieren. Insbesondere bei beschränkten Platzverhältnissen wird es schwierig.
Die meisten Modellbahner die sich heute so etwas wie digitalen (Block-)Betrieb mit punktgenauem Halten wünschen, genügt das nicht mehr, wenn sie woanders sehen, dass es besser und - zumindest augenscheinlich
- auch weniger Arbeitsaufwand geht.

Die Zentrale von Uhlenbrock ist zwar in der Lage logische Verknüpfungen zwischen Rückmeldungen und Aktionen abzuarbeiten, die klassische Benutzeroberfläche dazu ist aber schwierig zu bedienen. Praktisch benötigt man dazu einen PC mit einem Programm. Zusätzlich kann man die IB durch dezentrale Komponenten, wie die Marcos unterstützen, die sich bei Bedarf zentrlal über das LocoNet programmieren lassen. Das System ist mächtiger, als die 6021 mit Zubehör einschl. 6043 und Interface 6050, gegen die sie als Konkurenz konzipiert wurde, aber genau so wie die braucht man einen PC, um sie auszunutzen. Das war damals einerseits der Grund für den Erfolg von Widigipet, Railware und TC, andererseits für die Entwicklung von CS1/ECoS (und Viessman Commander) mit eigener grafischer Benutzerobefläche, um eine Modellbahnanlage auch ohne PC beherschen zu können.
Meines Erachtens können die Lösungen ohne PC nicht wirklich mithalten ... und das gilt genauso für die Nachfolger CS2 und CS3.

MfG

vik

Hallo Vik,

Zitat

---

Selbst mit mehreren Loks wirst Du das mit den richtigen Decodern und den passenden Bremsgeneratoren - auch ohne Computer - so hinbekommen, dass alle Loks einigermaßen passend halten.

---

Also so wie ich das verstanden habe und so wie das hier auch schon mehrfach diskutiert wurde, erfüllen diese Lösungen eben folgendes nicht: "(digital-konform versteht sich)".
Das sind ja vom Prinzip alles "analoge" Lösungen. Ob das nun ABC oder das Bremsen mit Gleichspannung ist. Bei den Bremsgeneratoren, die einzelne Bits im Protokoll manipulieren geschieht das zwar digital-konform, jedoch leider nicht wirklich systemkonform, da diese Methode - nach meinem Verständnis - grundlegende Digitalfunktionen einschränkt/blockiert. (Beispiel: Das Einfahren einer zweiten Lok in einen Abschnitt während eine andere bereits im rot steht. Rangierfahrten funktionieren also nicht - Unabhängiges Steuern von 2 oder mehreren Loks in einem Abschnitt wird hier blockiert.)

Auch Probleme mit unterschiedlichen Zuglängen, beleuchteten Wagen und viel Platz für "unnötig" lange Brems- und Halteabschnitten sind ein Unding. Der Funktionsumfang eines Systems sollte doch grundsätzlich nicht von einer Zuglänge oder so abhängig sein.

Zitat

---

Z.B. sind Rangierfahrten damit i.d. R. nicht zu realisieren.

---

Ja, eben weil es keine digital-konformen Lösungen sind.

Ich stimme dir zu, das UB System mit den Marco Railcom-Detektoren ist schon mächtig. Man braucht halt zwingend Railcom und eigentlich auch einen PC mit Programm, wie du ja auch geschrieben hast - während des Anlagenbetriebs aber nicht. Am Ende ist das vom Prinzip her jedoch auch eine Softwaresteuerung, wenn man davon ausgeht, dass Softwaresteuerung heißt, dass Rückmelder in der Anlage den Zustand an eine Steuerungs-Software-Logik liefert und diese dann ALLE Loks steuernd beeinflusst. Bei dem UB System mit Marco ist halt kein herkömmlicher PC als solches erkennbar, das Prinzip bleibt jedoch das gleiche. Ebenso wie bei den "Computer-Zentralen" Ecos, CS2/3, Viesmann Commander, Z21 + App ...

Zitat

---

Meines Erachtens können die Lösungen ohne PC nicht wirklich mithalten ... und das gilt genauso für die Nachfolger CS2 und CS3.

---

Das ist nur eine Frage der Zeit, denke ich. Aber es ist wohl so, dass hier auch die Anlagengröße und Komplexität relevant sein dürfte.

Also sieht es meines Erachtens doch danach aus, also müsste man

Zitat

---

[...] das immer mit der Methode "Softwaresteuerung" erledigen, auch wenn man hier und da den Computer als solchen vielleicht nicht sieht [...], wenn ich lediglich wünsche, dass eine Lok automatisch vor einem roten Signal hält.

---

Es bleibt im Prinzip ja auch unbenommen, dass in jedem Fall Hardware in der Anlage nötig wird.
Bei Softwaresteuerung:

• zwingend Rückmelder: Besetztmelder, Stromfühler, Lichtschranken, Reedkontakte, Railcom-Detektoren ...
• Schaltdecoder für Signale und Magnetartikel

• Bremsmodule: ABC, Gleichstrombremsen, ...
• Schaltdecoder für Signale und Magnetartikel
• evtl. Rückmelder: Besetztmelder, Stromfühler, Lichtschranken, Reedkontakte, Railcom-Detekoren ...

Zitat

---

[...]

Es bleibt im Prinzip ja auch unbenommen, dass in jedem Fall Hardware in der Anlage nötig wird.
Bei Softwaresteuerung:

• zwingend Rückmelder: Besetztmelder, Stromfühler, Lichtschranken, Reedkontakte, Railcom-Detektoren ...
• Schaltdecoder für Signale und Magnetartikel

Ohne Softwaresteuerung:

• Bremsmodule: ABC, Gleichstrombremsen, ...
• Schaltdecoder für Signale und Magnetartikel
• evtl. Rückmelder: Besetztmelder, Stromfühler, Lichtschranken, Reedkontakte, Railcom-Detekoren ...

Sooo groß ist der Unterschied bei der benötigten Hardware jetzt auch nicht. V.a. wenn man bei "ohne Software" die nicht zwingend notwendigen Rückmelder weglässt.

---

Die - jeweils "geeigneten" - Lok-Decoder solltest Du noch in beide Listen mit aufnehmen.

MfG

vik

Hallo Vik,

Das stimmt. Aber wenn man die Kompatibilität verschiedener Decoder mit aufnimmt wird es wieder deutlich differenzierter - bei ABC und Railcom vor allem.
Da ist eine Softwaresteuerung die keine besonderen Anforderungen an Decoder oder Anlage hat natürlich am komfortabelsten, was das angeht. Dann müsste man auch noch aufnehmen, bei welcher Lösung Gleisabschnitte notwendig sind und wie viele ...

Am Ende ist man doch generell am "besten" bedient, wenn man bei der Steuerung eine gewisse "Artenreinheit" sicherstellt. Ich weiß schon, dass das manche anders sehen ...

Grüße vom Rand der Platte

Jonas

Hallo Jonas,

Zitat

---

Am Ende ist man doch generell am "besten" bedient, wenn man bei der Steuerung eine gewisse "Artenreinheit" sicherstellt.

---

das entspricht der 80-20-Regel. Konzentriert man sich auf einen Hersteller kann man mit 20% des Knowhows über digitale Modellbahn 80% der möglichen Funktionalität nutzen....

MfG

vik

Hallo Jonas,

es wurde ja schon einiges geschrieben, aber ich möchte das ganze mal ein wenig aufteilen.

Es gibt aus meiner Sicht ganz grob vier Varianten:

1. Eine "Signalsteuerung" schaltet den Gleisabschnitt vor dem Signal stromlos -> die Lok hält an (die Technik stammt zwar aus der Analogsteuerungs-Zeit, hat aber zwei Zustände, ist also abzählbar und man kann es daher bei einem seit weit gedehnten "Digital"-Begriff auch als "digital" bezeichnen )

2. Der Lok wird von einer "Signalsteuerung" irgendwie mitgeteilt, dass sie von sich aus anhalten soll und die im Dekoder aktuell eingestellte (per DCC/mfx ferngesteuerte) Geschwindigkeit ignorieren soll. Dazu muss die "brems jetzt!"-Information irgendwie der Lok mitgeteilt werden. Das kann z.B. dadurch passieren, wie beim ABC-Bremssystem, dass eine Asymmetrie in der Versorgungsspannung im Gleisabschnitt vor dem Signal erzeugt wird und der Dekoder diese Information auch erkennen kann und dann reagiert und anhält. Da alle anderen Funktionen der Lok weiterhin digital steuerbar bleiben, könnte man auch dieses als "digital" im Sinne von "kompatibel zur digitalen Steuerung" bezeichnen.

3. Die Geschwindigkeitsinformation des "Lokführers" (z.B. vom MoBa Handregler) wird bei SIgnalhalt überschrieben und ersetzt durch die Geschwindkeitsinformation der "Signalsteuerung", bevor diese Information bei der Lok ankommt. Die "Signalsteuerung" übernimmt dann quasi temporär einen "Automatikbetrieb" und reduziert dann die Geschwindigkeit der Lok, bis auf 0. Für die Lok besteht kein Unterschied und die Lok kann auch nicht erkennen ob der Lokführer/Handregler die Geschwindkeit auf 0 gesetzt hat, oder die "Signalsteuerung".

Damit die "Signalsteuerung z.B. per DCC oder mfx aber die Geschwindigkeit der richtigen Lok(adresse) vermindert, muss die "Signalsteuerung" wissen, welche Lok(adresse) sich im Gleisabschnitt vor dem roten Signal befindet. Das könnte z.B. über einen Railcom Gleisbesetztmelder im Gleisabschnitt vor dem Signal erfolgen.

4. Es gibt keinen (menschlichen) Lokführer (z.B. mit MoBa Handregler) mehr, die Loks werden komplett über eine Automatik gesteuert. Da die Automatik alle Zustände (Signale, Weichen, Lokpositionen,..) kennt, kann sie die Loks auch entsprechend den Vorgaben steuern.


Variante (3) finde ich am reizvollsten und flexibelsten (z.B. könnte für jede Lok ihr indviduelles Bremsverhalten in der "Signalsteuerung" hinterlegt werden was bei 1. und 2. so nicht geht), es wäre quasi eine Manuell-Automatik-Hybridsteuerung. Wesentlicher Nachteil aus meiner Sicht: Ich kenne keine real-existierenden Lösungen. Ich könnte mir aber vorstellen, dass es vielleicht mit Rocrail ginge, weil damit mit Ausnahme von Kaffeekochen doch alles geht.

Ach ja, und den Begriff "Signalsteuerung" habe ich bewusst als black-box offen gelassen. Ob da jetzt nur ein paar einzelne Dioden,Transistoren, einzelne Logischaltkreise oder vielleicht ganz viele Transistoren und ganz viele Logikschaltkreise (aka Mikroprozessor/Microcontroller oder z.B. nen Raspberry mit Rocrail) im Gehäuse stecken, halte ich dabei erstmal für nicht so relevant. Den Begriff "Software-Steuerung" der Überschrift halte ich daher, trotz Deiner Erklärung, auch für etwas unglücklich gewählt. Auch kann die "Signalsteuerung" zentral (einmal pro Anlage, pro "Zentrale") sein, oder dezentral (jeweils pro Signal/Bereich/Gleisabschnitt etc.).


Grüße.

Hallo Martin,

vielen Dank für deine ausführliche, detaillierte Aufschlüsselung. Ich stimme dir so ziemlich bei allem zu.

Hätte aber ein paar Anmerkungen, vielleicht weil mein Verständnis hier einfach etwas anders ist. Ich versuche das mal zu erklären ...

Die Variante 1 als digital zu bezeichnen, scheint mir etwas weit hergeholt. Im Prinzip wird hier, wenn auch nur abschnittsweise, die Anlagensteuerung abgeschalten. Das entspricht für mich keiner Digitalfunktion, weil damit alle Digitalfunktionen futsch sind.

Zur Variante 2:

Zitat

---

könnte man auch dieses als "digital" im Sinne von "kompatibel zur digitalen Steuerung" bezeichnen.

---

Ich finde nicht, dass das wirklich (voll) kompatibel zur digitalen Steuerung ist. Das wird meines Erachtens deutlich, wenn man sich die hier und da auftretenden Probleme ansieht, wie sie bspw. bei ABC vorkommen können. Das ABC Signal muss erkannt werden können, manchmal detektiert ein Decoder nicht richtig, es gibt Probleme beim Überbrücken durch beleuchtete Wagen, Langsamfahrt geht zwar, dann aber keine Pendelzugstrecke mit Zwischenhalt mehr, man kann das Halten nicht adressspezifisch anpassen, ...
Die Gleisspannung wird eben analog abgeschwächt ==> analoge Informationsübertragung.

Variante 3:
Die finde ich persönlich auch am interessantesten, weil sie ganz leicht ein Wechsel zwischen Automatik und Manuell zulässt. Nachteilig finde ich, dass die "Signalsteuerung" hier für alle Loks entsprechende Eingaben/Vorgaben braucht, was, wo zu machen ist. Nur so gelingen dann auch beliebige zugspezifische Langsamfahrten und Bremswege.
Hier bekommt man aber das Problem, dass die Information für eine Lok in einem Bremsabschnitt unterschiedlich zu der außerhalb ist. Also muss immer der Komplette Zug in einem Abschnitt sein und es kann nicht nachträglich eine andere Lok in den Abschnitt einfahren. Die einzige Lösung aus diesem Dilemma ist, die Information des Handreglers gar nicht erst auf das Gleis durchzulassen. Dei Zentrale muss also dann in so einem Fall wissen, wann eine bestimmte Lok einen Abschnitt befährt und blockiert dann bereits in der Zentrale die Fahrinformation des Handreglers. Die Zentrale ist dann im Prinzip ein "Computer" mit Softwaresteuerung, die nur in ausgewählten Abschnitten "aktiv" ist.

Stimmt, hier müsste man bspw. Railcom-Rückmeldung in einem Halteabschnitt voraussetzen. Das entspricht am ehesten dem Uhlenbrock System mit MARCO Modulen.


Die 4. Variante ist die klassische PC-Softwaresteuerung bei Vollautomation. Die Software kennt/weiß alles und kann entsprechend alles steuern.

Zitat

---

Wesentlicher Nachteil aus meiner Sicht: Ich kenne keine real-existierenden Lösungen.

---

Wie erwähnt, finde ich, dass das dem System von Uhlenbrock+MARCO-Railcom-Modulen sehr nahe kommt. Ist halt im Prinzip eine Softwaresteuerung nur ohne richtigen PC.

Grüße vom Rand der Platte

Jonas

Hallo,

Zitat

---

Wesentlicher Nachteil aus meiner Sicht: Ich kenne keine real-existierenden Lösungen.

---

Wie ist das denn gemeint?

Hallo Jonas,

Zitat

---

Hallo Martin,

vielen Dank für deine ausführliche, detaillierte Aufschlüsselung. Ich stimme dir so ziemlich bei allem zu.

Hätte aber ein paar Anmerkungen, vielleicht weil mein Verständnis hier einfach etwas anders ist. Ich versuche das mal zu erklären ...

Die Variante 1 als digital zu bezeichnen, scheint mir etwas weit hergeholt. Im Prinzip wird hier, wenn auch nur abschnittsweise, die Anlagensteuerung abgeschalten. Das entspricht für mich keiner Digitalfunktion, weil damit alle Digitalfunktionen futsch sind.

---

Du hast ja recht. Ich hatte ja auch geschrieben, dass ich das von sehr weit hergeholt habe. Denn "digital" bedeutet ja "abzählbar". Und mit "strom an" und "strom aus" hat man etwas abzählbares (genau zwei Zustände).

Zitat

---

Zitat

---

könnte man auch dieses als "digital" im Sinne von "kompatibel zur digitalen Steuerung" bezeichnen.

---

Ich finde nicht, dass das wirklich (voll) kompatibel zur digitalen Steuerung ist. Das wird meines Erachtens deutlich, wenn man sich die hier und da auftretenden Probleme ansieht, wie sie bspw. bei ABC vorkommen können. Das ABC Signal muss erkannt werden können, manchmal detektiert ein Decoder nicht richtig, es gibt Probleme beim Überbrücken durch beleuchtete Wagen, Langsamfahrt geht zwar, dann aber keine Pendelzugstrecke mit Zwischenhalt mehr, man kann das Halten nicht adressspezifisch anpassen, ...
Die Gleisspannung wird eben analog abgeschwächt ==> analoge Informationsübertragung.

---

Nun ja. Genau betrachtet ist die am Gleis anliegende Spannung und das am Gleis anliegende Signal bei der Modellbahn immer analog. Aus diesem Analogsignal wird das Digitalsignal für die Loksteuerung erst im Lokdecoder umgewandelt/quantifiziert.

Diesem Analog-Signal am Gleis überlagert ist das Brems-Analogsignal z.B. der ABC-Bremssteuerung aus dem dann ebenfalls der Dekoder, der das ABC-Analogsignal dekodieren kann, ein Digitalsignal mit zwei Zuständen (bremsen, nicht bremsen) quantifiziert und dieses Digitaldatum dann weiter verarbeitet (und bremst).

Wie zuverlässung und empfehlenswert das ABC-Bremsprinzip ist, ist ein anderes Thema, ich hatte es nur als Beispiel genannt.

Zitat

---

Variante 3:
Die finde ich persönlich auch am interessantesten, weil sie ganz leicht ein Wechsel zwischen Automatik und Manuell zulässt. Nachteilig finde ich, dass die "Signalsteuerung" hier für alle Loks entsprechende Eingaben/Vorgaben braucht, was, wo zu machen ist. Nur so gelingen dann auch beliebige zugspezifische Langsamfahrten und Bremswege.
Hier bekommt man aber das Problem, dass die Information für eine Lok in einem Bremsabschnitt unterschiedlich zu der außerhalb ist. Also muss immer der Komplette Zug in einem Abschnitt sein und es kann nicht nachträglich eine andere Lok in den Abschnitt einfahren. Die einzige Lösung aus diesem Dilemma ist, die Information des Handreglers gar nicht erst auf das Gleis durchzulassen. Dei Zentrale muss also dann in so einem Fall wissen, wann eine bestimmte Lok einen Abschnitt befährt und blockiert dann bereits in der Zentrale die Fahrinformation des Handreglers. Die Zentrale ist dann im Prinzip ein "Computer" mit Softwaresteuerung, die nur in ausgewählten Abschnitten "aktiv" ist.

Stimmt, hier müsste man bspw. Railcom-Rückmeldung in einem Halteabschnitt voraussetzen. Das entspricht am ehesten dem Uhlenbrock System mit MARCO Modulen.

---

Ich habe mich jetzt mal ein wenig zu Marco schlau gemacht. Das kannte ich noch gar nicht. Ja, so in die Richtung dachte ich das. Das scheint ein railcom-Empfänger / GBM zu sein der über railcom weiss, welche lok(adresse) im Gleisabschnitt vor dem Signal ist, und der dann einfache, hinterlegte Befehle an die Lok mittels Loconet an die Zentrale sendet, die dann diese Befehle wieder an das Gleis sendet.

Nur: Wie ist es mit wiedersprüchlichen "Befehlen" an die Lok? Wenn der Marco-GBM "Halt" sendet und einen Sekundenbruchteil danach der Handregler die Geschwindigkeit auf "Maximal" erhöht?

Zitat

---

Wie erwähnt, finde ich, dass das dem System von Uhlenbrock+MARCO-Railcom-Modulen sehr nahe kommt. Ist halt im Prinzip eine Softwaresteuerung nur ohne richtigen PC.

---

Ja, so scheint es. Mir scheint dieses System durch/trotz den Verzicht auf einen PC (und dessen Möglichkeit einer komfortablen und benutzerfreundlichen Software) aber nicht weniger komplex zu konfigurieren und zu pflegen zu sein. Dafür aber ist es anscheinend weniger flexibel.

Wenn man jetzt mal nicht an das "halbintelligente" Marco-System denkt, sondern, auf Basis von Railcom-Rückmeldern, an eine zentrale, intelligentere Steuerung denkt, dann könnte man ja einmal alle Lokparameter (z.B. Bremscharakteristik/Parabel, Bremsweg bei verschiedenen Geschwindigkeiten, Lastverhalten, etc. ) einmal der zentralen "Signalssteuerung" bekannt machen und dann kann diese beim Eingriff der Zugbeeinflussung den Zug bei allen Haltestrecken rechtzeitig anhalten. Also so ähnlich wie man das auch bei einer komplette Automatiksteuerung macht. Nur dass die Zugbeeinflussung der Automatiksteuerung erst dann eingreift, wenn der Lokführer (vom Handregler aus) nicht von selber rechtzeitig bremst/hält.

Grüße.

Hallo Martin,

Zitat

---

Nur: Wie ist es mit wiedersprüchlichen "Befehlen" an die Lok? Wenn der Marco-GBM "Halt" sendet und einen Sekundenbruchteil danach der Handregler die Geschwindigkeit auf "Maximal" erhöht?

---

Naja, wie gesagt, muss die Zentrale IB2 die Befehle des Handreglers blockieren. Dann werden den Befehlen der Marco-GBM die höhere Priorität eingeräumt. Eine andere Möglichkeit wäre zu sagen, wenn eine Lok über einen Handregler aktiv gesteuert wird, wird diese eben manuell gesteuert und die Automatik sollte dann unwirksam sein.
Wie auch immer, denke ich, dass sich dieser Befehlskonflikt durch Priorisierung lösen lässt. Denn eines ist doch klar, es darf nicht dazu kommen, dass widersprüchliche Befehle aufs Gleis gelangen.

Zitat

---

Nun ja. Genau betrachtet ist die am Gleis anliegende Spannung und das am Gleis anliegende Signal bei der Modellbahn immer analog. Aus diesem Analogsignal wird das Digitalsignal für die Loksteuerung erst im Lokdecoder umgewandelt/quantifiziert.

Diesem Analog-Signal am Gleis überlagert ist das Brems-Analogsignal z.B. der ABC-Bremssteuerung aus dem dann ebenfalls der Dekoder, der das ABC-Analogsignal dekodieren kann, ein Digitalsignal mit zwei Zuständen (bremsen, nicht bremsen) quantifiziert und dieses Digitaldatum dann weiter verarbeitet (und bremst).

---

Das ist zwar alles schlüssig, wenn man es so betrachtet, jedoch betrachte ich das anders.
Im Digitalfall kommen die Befehle von der Zentrale, bei ABC kommt der Bremsbefehl jedoch von einem lokalen Modul. Es wird also nicht ein Lokdecoder, wie im Digitalsystem üblich über seine Adresse angesprochen und diesem Informationen mitgeteilt, sondern diese Fallen aus Sicht des Systems praktisch vom Himmel. Weder die Zentrale noch ein Handsteuergerät "weiß" von der ABC-Information. Ich finde, dass hier ein Bruch in der Systematik vorliegt --> darum auch die möglichen Probleme bei ABC.

Zitat

---

[...] dann könnte man ja einmal alle Lokparameter (z.B. Bremscharakteristik/Parabel, Bremsweg bei verschiedenen Geschwindigkeiten, Lastverhalten, etc. ) einmal der zentralen "Signalssteuerung" bekannt machen [...]

---

Das wäre mir zu viel Aufwand für alle Loks: Bremscharakteristik für zig Geschwindigkeiten und deren Lastverhalten... Das müsste schon der Decoder irgendwie handeln. Eine direkte Fahrstufensteuerung für das Anhalten scheint mir per se nicht besonders klug zu sein. Über wie viele Fahrstufen sollte das denn dann laufen? 200, 300 oder 1000?

Grüße vom Rand der Platte

Jonas

Hallo Jonas,

Zitat

---

Hallo Martin,

Zitat

---

Nur: Wie ist es mit wiedersprüchlichen "Befehlen" an die Lok? Wenn der Marco-GBM "Halt" sendet und einen Sekundenbruchteil danach der Handregler die Geschwindigkeit auf "Maximal" erhöht?

---

Naja, wie gesagt, muss die Zentrale IB2 die Befehle des Handreglers blockieren. Dann werden den Befehlen der Marco-GBM die höhere Priorität eingeräumt. Eine andere Möglichkeit wäre zu sagen, wenn eine Lok über einen Handregler aktiv gesteuert wird, wird diese eben manuell gesteuert und die Automatik sollte dann unwirksam sein.
Wie auch immer, denke ich, dass sich dieser Befehlskonflikt durch Priorisierung lösen lässt. Denn eines ist doch klar, es darf nicht dazu kommen, dass widersprüchliche Befehle aufs Gleis gelangen.

---

Zustimmung. Es sollte nicht zu widersprüchlichen Befehlen an die Lok kommen. Ich hatte oben aber keine rhetorische Frage gestellt, sondern eine echte Wissensfrage, wie genau das technisch bei dem Marco-GBM "Halt" Befehlen/Nachrichten abläuft, da ich das System nicht kenne.

Zitat

---

Zitat

---

Nun ja. Genau betrachtet ist die am Gleis anliegende Spannung und das am Gleis anliegende Signal bei der Modellbahn immer analog. Aus diesem Analogsignal wird das Digitalsignal für die Loksteuerung erst im Lokdecoder umgewandelt/quantifiziert.

Diesem Analog-Signal am Gleis überlagert ist das Brems-Analogsignal z.B. der ABC-Bremssteuerung aus dem dann ebenfalls der Dekoder, der das ABC-Analogsignal dekodieren kann, ein Digitalsignal mit zwei Zuständen (bremsen, nicht bremsen) quantifiziert und dieses Digitaldatum dann weiter verarbeitet (und bremst).

---

Das ist zwar alles schlüssig, wenn man es so betrachtet, jedoch betrachte ich das anders.
Im Digitalfall kommen die Befehle von der Zentrale, bei ABC kommt der Bremsbefehl jedoch von einem lokalen Modul. Es wird also nicht ein Lokdecoder, wie im Digitalsystem üblich über seine Adresse angesprochen und diesem Informationen mitgeteilt, sondern diese Fallen aus Sicht des Systems praktisch vom Himmel. Weder die Zentrale noch ein Handsteuergerät "weiß" von der ABC-Information. Ich finde, dass hier ein Bruch in der Systematik vorliegt --> darum auch die möglichen Probleme bei ABC.

---

Das was Du als "Bruch in der Systematik" bezeichnest, nenne ich "out-of-band Signalisierung" und stimme Dir dahingehend zu.

Der Bremsbefehl erfolgt bei Variante (2) "out-of-band" (ausserhalb der normalen Steuerung von Lokführer/Zentrale/Handregler). Das ist ja gerade der Unterschied der Variante (2) gegenüber der Variante (3). Das ist also im Prinzip genauso wie die PZB (Punktförmige Zugbeeinflussung) bei der echten Bahn, bei der die Fahrzeugeinrichtung von sich aus eine Zwangsbremsung auslöst wenn der Lokführer bei einem Hp0 nicht aufpasst. Statt einem Indusi-Magneten zur Informationsübermittlung wird bei der Modellbahn halt die Information dafür der vorhandenen Gleisspannung bzw. dem vorhandenem Gleissignal überlagert.

Möglicherweise gefällt Dir das Zimo-HLU-Verfahren hier besser: Dabei werden in der Bremsstrecke (vom "Gleisabschnittsmodul") in das DCC-Signal (in die DCC-Präambel) Datenbits hinzugefügt (Bits auf 0 gesetzt) in dem im Gleisabschnitt die Spannung für jedes Bit ganz kurz unterbrochen wird (keine Spannung -> Bit auf "0") um dem Lokdekoder u.a. einen Bremsbefehl zu geben. Das wäre also quasi das "digitalste" der oben genannten Verfahren.

Dass das bei der Modellbahn genutze PZB-Verfahren leider nicht per NEM/DCC-Standard festgelegt wurde und daher verschiedene Hersteller ihre eigenen Verfahren entwickelt haben (z.B. DC Bremsmodus, Märklin Bremsstrecke, Selectrix Diodenbremsstrecke, ABC-Bremsmodus, Zimo HLU Bremsstrecke, ...) und die unterschiedlich zuverlässig sind, ist zwar unschön, ändert aber nichts am Prinzip.

Zitat

---

Zitat

---

[...] dann könnte man ja einmal alle Lokparameter (z.B. Bremscharakteristik/Parabel, Bremsweg bei verschiedenen Geschwindigkeiten, Lastverhalten, etc. ) einmal der zentralen "Signalssteuerung" bekannt machen [...]

---

Das wäre mir zu viel Aufwand für alle Loks: Bremscharakteristik für zig Geschwindigkeiten und deren Lastverhalten... Das müsste schon der Decoder irgendwie handeln. Eine direkte Fahrstufensteuerung für das Anhalten scheint mir per se nicht besonders klug zu sein. Über wie viele Fahrstufen sollte das denn dann laufen? 200, 300 oder 1000?

---

Naja, einen ähnlichen Aufwand, vielleicht nicht so detailliert, machen ja viele Modellbahner bei der Vollautomatik-Variante.

Man kann dieses allerdings auch auf den Lokdekoder verlagern:

Bei aktuellen ESU-Dekodern kann man übrigens über CV 254 einen von der Geschwindigkeit unabhängigen konstanten Bremsweg einstellen, für den Fall, dass ein "Bremsbefehl" über Bremsstrecken erkannt wird. Und über das gesetzte Bit 7 in CV 27 interpretiert der Dekoder dann auch "Fahrstufe 0" als "Bremsbefehl" (so dass das eingestelle Bremsverhalten verwendet wird).

Damit könnte man also alle Loks so "eichen", dass sie bei einem Bremsbefehl immer nach der gleichen Strecke zum halten kommen und könnte den Anfang der Bremsstrecken und die Position der Signale entsprechend anpassen ohne das individuelle Lokverhalten bei der "Signalsteuerung" oder der Zentrale individuell festhalten zu müssen.

Ob andere/ältere Dekoder ebenso auf eine konstante Bremsstrecke eingestellt werden können, weiß ich aber nicht.

Grüße.

Hallo Martin,

Zitat

---

nenne ich "out-of-band Signalisierung"

---

Nicht nur du. Ja, absolut korrekt.

Stimmt man könnte das ABC mit der PZD vergleichen.

Zitat

---

Möglicherweise gefällt Dir das Zimo-HLU-Verfahren hier besser:

---

Ja, das finde ich besser. Leider ist das nicht in die DCC Protokoll Normierung aufgenommen worden. Aber laut Zimo sind hierfür auch mehrere Abschnitte und relativ teure Hardware notwendig. Aber das Verfahren finde ich gut, auch dass mehrere Langsamfahrt Befehle existieren.
Meines Wissens nach gab es das HLU von Zimo bereits vor der Normierung des DCCs Anfang der 90er. Man hätte es also mit aufnehmen können.

Zitat

---

Bei aktuellen ESU-Dekodern kann man übrigens über CV 254 einen von der Geschwindigkeit unabhängigen konstanten Bremsweg einstellen, für den Fall, dass ein "Bremsbefehl" über Bremsstrecken erkannt wird. Und über das gesetzte Bit 7 in CV 27 interpretiert der Dekoder dann auch "Fahrstufe 0" als "Bremsbefehl" (so dass das eingestelle Bremsverhalten verwendet wird).

---

Das ist mir bekannt. Dann braucht man keine Direktsteuerung zum Halten und Beschleunigen.
Die Einstellung konstanter Bremsweg liefern auch andere Decoderhersteller. Zimo z.B.

Grüße vom Rand der Platte

Jonas