Hallo Jochen,

Zitat

---

Für mich liegt der Unterschied deshalb in der Benutzerfreundlichkeit, in den zusätzlichen Möglichkeiten eines Computers nebenher und darin, dass PC-Software generell flexibler aktualisiert werden kann als Hardware-gebundene Updates für eine Zentralstation.

---

Ich verstehe dich, denke aber auch, dass bspw. das mit dem Bildschirm in Zukunft keine große Rolle mehr spielen wird. Man kann doch bei Bedarf einen großen Monitor zusätzlich anschließen. Zu den Updates würde ich sagen, dass das nur eine Frage eines System-Konzepts ist. Wenn die Steuerungssoftware auf einer Basis-Firmware, praktisch einem OS, läuft, sind Updates ebenso komfortabel und flexibel aktualisierbar.
Die Schwächen, die du momentan noch siehst, werden in Zukunft verschwinden, denke ich.

Zum Thema:
Möchte man heute mehr als nur Loks von Hand unabhängig fahren lassen, braucht es bei den einschlägigen Digitalsteuerungen "Verfolgungs-Software", so wie das Hubert auch beschreibt. Andernfalls ist bspw. bei DCC ein Aufwand aus zahlreichen Brems- (z.B. ABC-) Modulen und einer Steuereinheit nötig, die die Brems-Module dann nach einem logischen Konzept schaltet.
Wer das möchte, dem sei das unbenommen. Hat aber auch deutliche Schwächen.
Bei ABC ergibt sich eine Hardware-Abhängigkeit z.B. bei den Decodern.
Selbst bei UB Marco (obwohl vom eigentlichen Sinn eine Softwaresteuerung) ergibt sich eine Abhängigkeit gegenüber der Railcom-Fähigkeit - diese aber immer mehr schrumpfen wird, da Railcom Teil der DCC Norm.

Hallo Hubert,

Zitat

---

"Muss digitale Modellbahn notwendig auf den Computer zurückgreifen?"
Muss sie nicht. Es kommt immer darauf an, welche ansprüche man stellt.

---

Sehe ich auch so.

Zitat

---

Jetzt verstehe ich dich. Würdest du also auch sagen, dass eine Lok auch nicht wissen muss wann sie bspw. eine Funktion schalten "darf" und wann nicht?

---

Du meinst sowas wie "schalte die Führerstandbeleuchtung bei FS > 0 ab"? Streng genommen ja. Sind halt Komfortfunkionen, die da eingeführt wurden. Ich sehe da aber schon einen Unterschied zu der Geschichte HP0 / FS0: Die Lok macht bei beiden das gleiche. Wozu das Protokoll mit redundanten Befehlen aufblähen?

Zitat

---

Alles klar, das sehe ich eben anders. Aus meiner Sicht ist der Decoder praktisch der "verlängerte Arm" dessen, der am Handregler sitzt (bei Automatik, einer Software).

---

Genau das schrieb ich ja.

Zitat

---

Weil die Decoder mehr machen als nur einen Befehl direkt umzusetzen. Wenn er lediglich der Empfänger von Befehlen wäre, dann dürfte es im Decoder bspw. auch keine ABV geben und die Fahrstufen müssten direkt umgesetzt werden. Eine Verzögerung beim Beschleunigen müsste dann eben auch die Software oder der Lokführer übernehmen, denn nur die Software "weiß" (kann wissen) was für ein Zug/ eine Last gerade am Haken hängt und wie demzufolge gerade verzögert werden sollte.

---

Normalerweise funktioniert das auch so. Bei Softwarebetrieb schaltet man die ABV ab bzw. sehr weit runter. Die ABV ist eher was für den Handbetrieb, damit man sich eben nicht die Mühe machen muss, das selber langsam runterzudrehen.

Zitat

---

Außerdem steuert ein Decoder eine Lok doch mit deutlich mehr Fahrstufen, als diese von einem Steuernden/einer Steuerung vorgegeben werden können.

---

Wir haben hier eben immernoch Modelle, keine echte Eisenbahn. Ich möchte z.B. viele Fahrstufen haben, um feinfühlig rangieren zu können oder Loks möglichst gut aufeinander abstimmen zu können für Mehrfachtraktionen etc.

Zitat

---

Es gibt genug Dinge die ein Decoder doch vollkommen selbstständig "entscheidet", einfach nur aufgrund einer Übertragenen Information, ohne den "wirklichen Grund" für diese zu kennen. Eben wie ein HP0 Befehl. Den Grund der Steuerung dafür den Befehl zu schicken kennt/weiß der Decoder nicht, aber er reagiert entsprechend darauf und kann diesen auch von einem einfachen Fahrstufe 0 Befehl differenzieren.

---

Aber wozu sollte er das können müssen? Was unterscheidet HP0 von FS0 aus Decodersicht? Das Resultat bleibt das gleiche.

Viele Grüße
Carsten

Hallo Carsten,

Zitat

---

Du meinst sowas wie "schalte die Führerstandbeleuchtung bei FS > 0 ab"? Streng genommen ja. Sind halt Komfortfunkionen, die da eingeführt wurden. Ich sehe da aber schon einen Unterschied zu der Geschichte HP0 / FS0: Die Lok macht bei beiden das gleiche. Wozu das Protokoll mit redundanten Befehlen aufblähen?

---

Exakt so etwas meinte ich. Der Decoder kann Funktionen abhängig von Fahrstufen oder von anderen Funktionen schalten. Nach deiner Auffassung dürfte das alles aber eingentlich nicht sein, wenn ich dich richtig verstehe. Der Decoder müsste eingentlich viel "dümmer" sein und eine externe zentrale Software solle das alles bestimmen.
Naja, wenn der Decoder zwischen HP0 / HP1 und SH0 / SH1 und FS0 / FS>0 unterscheiden kann, kann er auch bspw. Funktionen davon abhängig (de)aktivieren. Wenn er z.B. Sh1 erkennt, also Rangierfahrt, können entsprechende Einstellungen bei ABV und beim Spitzenlicht vorgenommen werden.
Klar braucht es das alles nicht, wenn man davon ausgeht, dass eine externe Software all diese Dinge übernimmt. Man braucht dann auch kein fahrtrichtungsabhängiges Schalten von Funktionen oder abhängig von der Fahrstufe. Eine ABV braucht man dann auch nicht und ich weiß nicht was noch alles so eigentlich keine richtige Berechtigung hätte einen Decoder zu belästigen.
Es ist aber eben so, dass es jetzt, Stand heute, nicht der Fall ist, dass das von dir beschriebene Konzept auch decoderseitig umgesetzt wäre.
Mir wäre zumindest kein Decoder bekannt. Selbst die einfachsten haben zumindest eine der angesprochenen Funktionen. Und gefühlt - ich kann mich auch täuschen - wird es eher mehr bei den Funktionen und deren Logikverschaltungen.

Zitat

---

StephanLeist hat geschrieben: ↑
So 5. Apr 2020, 20:15
Alles klar, das sehe ich eben anders. Aus meiner Sicht ist der Decoder praktisch der "verlängerte Arm" dessen, der am Handregler sitzt (bei Automatik, einer Software).

Genau das schrieb ich ja.

---

Ja, nach deiner Ansicht ist der "Lokführer" vollständig außerhalb der Lok, ob Software oder Mensch. Bei mir ist der "Lokführer" die Kombination aus Mensch/Software und Lokdecoder.

Zitat

---

Normalerweise funktioniert das auch so. Bei Softwarebetrieb schaltet man die ABV ab bzw. sehr weit runter. Die ABV ist eher was für den Handbetrieb, damit man sich eben nicht die Mühe machen muss, das selber langsam runterzudrehen.

---

Das heißt dann, dass die ABV die ein Decoder sonst intern mit - ich weiß nicht genau - (10 Bit) 1023 oder gar (12 Bit) 4095 Fahrstufen macht, eine externe Software dann mit (6 Bit) 128 Fahrstufen machen muss. Ist das nicht ein Unterschied? Wenn nein, warum arbeiten Decoder dann mit dieser hohen Anzahl an internen Fahrstufen?

Zitat

---

Wir haben hier eben immernoch Modelle, keine echte Eisenbahn. Ich möchte z.B. viele Fahrstufen haben, um feinfühlig rangieren zu können oder Loks möglichst gut aufeinander abstimmen zu können für Mehrfachtraktionen etc.

---

Kann ich total nachvollziehen. Aber wie soll denn eine externe Softwaresteuerung eben genau die selbe Feinfühligkeit hinbekommen, wenn sie den Lokdecoder mit gerade mal weniger als 13% oder sogar weniger als 4% der sonst vorhandenen Fahrstufen ansteuert? (Und das wohlgemerkt "ohne" die interne ABV)

Zitat

---

Aber wozu sollte er das können müssen? Was unterscheidet HP0 von FS0 aus Decodersicht? Das Resultat bleibt das gleiche.

---

Es stimmt in sofern, als dass das Endergebnis das gleiche ist. Aber wie oben Beschrieben, können sich aus einem HP0 Befehl andere Abhängigkeiten für Funktionen oder grundsätzliche Funktionalitäten ergeben, als bei einfachem Stillstand.
Z.B.: Unter der Annahme, dass sich das Bremsverhalten ohne (sehr geringer) ABV und auch nur mit höchstens 13% der eigentlichen Fahrstufen als unvorteilhaft erweist, könnte im Fall eines HP0-Empfangs ein decoderinterner Bremsvorgang gestartet werden, was u.a. auch das Protokoll entlasten würde, anstatt bspw. nacheinander 100 Fahrstufenbefehle im Zeitverhalten der von der externen Software vorgegebenen ABV zu schicken.

Ich versehe sehr wohl deinen Ansatz, finde aber, dass sich dieser in letzter Konsequenz so nicht umsetzten lassen würde. Derzeit zumindest finden viele Dinge, von denen du sagst, diese müssten eigentlich von der Softwaresteuerung vorgegeben werden, im Decoder statt. (Beispiele, siehe oben)

Aus deinem Ansatz heraus, kannst du zu Recht argumentieren, dass bspw. ein HP0-Befehl im Decoder nichts verloren habe. Völlig einverstanden. Nur spiegelt dein Ansatz die Realität nicht 100% wieder. Deshalb gibt es für mich aus aktueller und realistischer Sicht kein stichhaltiges Argument gegen derartige Information im Decoder.
Das Protokoll und letztlich auch der Decoder würden dadurch weniger belastet, weil es bspw. zur Reduzierung des Traffic beitragen würde.

Zitat

---

Aber wozu sollte er das können müssen?

---

Bsp: Eine Software gibt den Fahrdienstleiter - oder gerne auch eine Person vor dem Bildschirm macht das. Ich möchte den Lokführer geben. Auf meinem mobilen Steuergerät habe ich meine Lok und bin bereit. Der Fahrdienstleiter gibt mir freie Fahrt HP1. Ich sehe das grüne Signal und erhöhe die FSe. Dann fährt mein Zug immer weiter und ich komme an eine Stelle der Anlage, wo man in der einen Richtung ein Signal einsehen kann, für die Gegenrichtung jedoch nicht. Leider fahre ich genau auf dieses zu. Ich kann aber nicht sehen, ob mir der Fahrdienstleiter HP1 oder HP0 gegeben hat. Was mache ich jetzt an meinem Steuergerät?

Aktuell:
Ich gehe an den Bildschirm und schaue nach, wie der Fahrdienstleiter das Signal gestellt hat.

Möglich:
Der Lokdecoder bekommt den Hp0/Hp1 Befehl über das Protokoll und meldet mir diesen an mein mobiles Handsteuergerät. Im Zweifelsfall beginnte der Decoder bereits selbstständig zu Bremsen.

Zitat von StephanLeist im Beitrag Muss digitale Modellbahn notwendig auf den Computer zurückgreifen?

---

Naja, wenn der Decoder zwischen HP0 / HP1 und SH0 / SH1 und FS0 / FS>0 unterscheiden kann, kann er auch bspw. Funktionen davon abhängig (de)aktivieren. Wenn er z.B. Sh1 erkennt, also Rangierfahrt, können entsprechende Einstellungen bei ABV und beim Spitzenlicht vorgenommen werden.
(...)
Möglich:
Der Lokdecoder bekommt den Hp0/Hp1 Befehl über das Protokoll und meldet mir diesen an mein mobiles Handsteuergerät. Im Zweifelsfall beginnte der Decoder bereits selbstständig zu Bremsen.

---

Zitat von StephanLeist im Beitrag Muss digitale Modellbahn notwendig auf den Computer zurückgreifen?

---

Exakt so etwas meinte ich. Der Decoder kann Funktionen abhängig von Fahrstufen oder von anderen Funktionen schalten. Nach deiner Auffassung dürfte das alles aber eingentlich nicht sein, wenn ich dich richtig verstehe. Der Decoder müsste eingentlich viel "dümmer" sein und eine externe zentrale Software solle das alles bestimmen.

---

Zitat

---

Das heißt dann, dass die ABV die ein Decoder sonst intern mit - ich weiß nicht genau - (10 Bit) 1023 oder gar (12 Bit) 4095 Fahrstufen macht, eine externe Software dann mit (6 Bit) 128 Fahrstufen machen muss. Ist das nicht ein Unterschied? Wenn nein, warum arbeiten Decoder dann mit dieser hohen Anzahl an internen Fahrstufen?

---

Wo hast du diese Zahlen her? Die Decoder, die ich so kenne, arbeiten intern mit 128 Fahrstufen, höchstens mal mit 256.

Zitat

---

Z.B.: Unter der Annahme, dass sich das Bremsverhalten ohne (sehr geringer) ABV und auch nur mit höchstens 13% der eigentlichen Fahrstufen als unvorteilhaft erweist, könnte im Fall eines HP0-Empfangs ein decoderinterner Bremsvorgang gestartet werden, was u.a. auch das Protokoll entlasten würde, anstatt bspw. nacheinander 100 Fahrstufenbefehle im Zeitverhalten der von der externen Software vorgegebenen ABV zu schicken.

---

Theoretisch hast du Recht. Nur: Die Software kann den Bremsvorgang dann auch abhängig von der angehängten Last steuern. Der Decoder kann das nicht, denn er weiß das nicht.

Zitat

---

Bsp: Eine Software gibt den Fahrdienstleiter - oder gerne auch eine Person vor dem Bildschirm macht das. Ich möchte den Lokführer geben. Auf meinem mobilen Steuergerät habe ich meine Lok und bin bereit. Der Fahrdienstleiter gibt mir freie Fahrt HP1. Ich sehe das grüne Signal und erhöhe die FSe. Dann fährt mein Zug immer weiter und ich komme an eine Stelle der Anlage, wo man in der einen Richtung ein Signal einsehen kann, für die Gegenrichtung jedoch nicht. Leider fahre ich genau auf dieses zu. Ich kann aber nicht sehen, ob mir der Fahrdienstleiter HP1 oder HP0 gegeben hat. Was mache ich jetzt an meinem Steuergerät?

---

Das geht den Decoder dann immernoch nichts an. Diese Information gehört von der Software an den Handregler übertragen, nicht an den Decoder. Am Gleis ist und bleibt diese Information irrelevant. Warum sollte diese Information erst übers Gleis an den Decoder gehen und dann per Railcom (was ja noch nichtmal sooo weit verbreitet ist) wieder zur Zentrale und zum Handregler?

Zitat

---

Der Lokdecoder bekommt den Hp0/Hp1 Befehl über das Protokoll und meldet mir diesen an mein mobiles Handsteuergerät. Im Zweifelsfall beginnte der Decoder bereits selbstständig zu Bremsen.

---

Auch die Zwangsbremsung muss der Decoder nicht alleine machen. Die Software kann in diesem Fall einfach FS0 senden und gut ist.

Viele Grüße
Carsten

Hallo Werner,

Ja, natürlich hast du Recht. Nach meinem Kenntnisstand, gibt es (noch)keinen DCC Decoder der das kann. Weil es ja auch keinen DCC Befehl im Protokoll gibt, der diese Information bereitstellen würde.

Und genau das war ja der Punkt. Ich hatte behauptet, mit meiner provokannt überspitzten Frage, ob denn eine Softwaresteuerung nötig sei, um noch diverse Mängel des Digitalbetriebs zu eliminieren. Das "Erkennen" von bspw. Hp0 Hp1 Sh0 Sh1 ... geht digitalsystemgercht doch erst, wenn man eine Softwaresteuerung (das Prinzip einer Softwaresteuerung) verwendet. Doch selbst dann erkennt es aus oben genannten Gründen nicht wirklich der Decoder, sondern ALLES wird von der Software simuliert.

Ich gebe der Software virtuell eine Strecke mit Signalen vor, ordne entsprechende Sensorik zu und die Software (ob in PC oder versteck in einer Zentrale) "erledigt" den Rest. Carsten hat das ja gut erklärt. Die Lok (Decoder) weiß von nichts. Der fährt einfach auf den Gleisen herum (-> Fahren und schalten von Funktionen evtl. noch Sound).

Das ist in etwa so als würde ich Jemanden mit einem Funkhandregler in den Nebenraum schicken und ihm zuvor noch mitteilen, dass er immer anhalten soll, wenn bei ihm ein Lämpchen aufleuchtet. Das Lämpchen schließe ich bei mir auf der Anlage an einen Sensor im Gleis. Wo der genau ist weiß dieser Jemand eigentlich auch nicht. Er fährt also einfach einmal drauf los. Ich stehe im Raum bei der Anlage und aus meiner Sicht fährt eine Lok automatisch los. Irgendwann kommt sie an die Stelle, wo ich einen Sensor mit dem Lämpchen verknüpft habe und die Lok hält automatisch an. Tataaa, ein automatischer Halt. Der unsichbare Jemand im anderen Raum ist natürlich die Softwaresteuerung.

Wie wir jetzt hier so ziemlich alle festgestellt haben, ist das so. Erst mit dem Prinzip einer Softwaresteuerung gibt es im Fall von digital ein systemgerechten automatischen Halt.

So, und aufgrund dieser Erkenntnis habe ich gesagt, wenn man das anders wollte, also ohne auf so eine Softwaresteuerung für autom. Halt etc. angewiesen zu sein, müsste der Decoder in der Lage sein, diese Information erkennen zu können. Das war alles.

Darüber ist ein eigentlich unnötiger Streit vom Zaun gebrochen, weil Carsten eben erklärt hat, dass Informationenen dieser Art aber den Decoder nichts angehen würden. Wahrscheinlich um damit auszudrücken, dass das schon ganz richtig ist, wie das entwickelt wurde und dass das auch keinen "Mangel" darstellt. Denn es gehöre eben nicht auf diese "Ebene", meint er.

Und ich habe jetzt entgegenet, dass dann nach seiner Denkweise - die ja durchaus ein berechtigeter Ansatz ist - auch einige andere Informationen und Funktionen die in den Decodern sind, dort nicht hin gehören. Sie sind aber faktisch da.

Meine Schlussfolgerung daraus ist, dass man eben gerade nicht einfach behaupten kann, dass man bei der Entwicklung usw. nach dem von Carsten erklärten Prinzip entwickelt hat. Denn sont wären diese Funktionen (ABV usw.) heute nicht in den Decodern.

Man darf also doch ruhig sagen, ohne dabei von einer Meute denunziert und mit Polemik überrollt zu werden, dass es nicht von Grund auf zu dem konzeptionellen Gedanken gehört hat, den Decoder strikt als dummen Befehlsempfäger zu sehen und die Funktionalität in einer externen Software zu verpacken. Das wäre eben aus meiner Sicht das Pferd von hinten aufgezäumt.
Das alles hat sich so entwickelt und heute nutzt man Softwaresteuerung, um die letzten funktionalen Lücken zu schließen. Die Entwicklung von Railcom tut da ihr übriges, sodass auch ohne "wirklichen" PC diese Lücken geschlossen werden können (meckh zur Freude).
Auch wenn sich das so Stück für Stück zusammengefügt hat, möchte ich nicht so verstanden werden, dass das alles 'Flickwerk' sei. Und dass sich durch die Verwendung neuerer und andere Technik fehlende oder mangelhafte Dinge verbessert oder eingefügt wurden, sollte auch klar sein.


Mein Fazit:
Ob digitale Modellbahn auf (den Computer) das Prinzip Softwaresteuerung zurückgreifen muss, ist von den funktionellen Wünschen des Anwenders abhängig. (--> individuelle Entscheidung)
Tatsache ist, dass sich die Möglichkeiten einer Digitalsteuerung (bei den Protokollen mit technol. Ursprung Märklin, Lenz) erst vollends durch die Verwendung des Softwaresteuerungsprinzips ergeben.

Was heißt das konkret? Ab wann ist man dann bspw. auf so eine Steuerung nach dem Prinzip Softwaresteuerung angewiesen?

• sobald man ein virtuelles BSW möchte
• sobald man eine automatische ortsabhängige Zugbeeinflussung (Hp0, Hp2, Sh1, ...) systemkonform digital möchte
• sobald man einen virtuellen Fahrdienstleiter möchte
• sobald man komplexe Automation möchte (das dürfte aber eh klar sein)

Hallo Carsten,

Zitat

---

Theoretisch: Ja. Allerdings sind die implementierten Sachen mehr für die manuelle Steuerung als Komfortfunktionen vorgesehen, nicht unbedingt für Automatikbetrieb.

---

Ok, das verstehe ich nicht ganz. Wenn es für den manuellen Betrieb ist, dann steuere ich doch sowieso - eben manuell. D.h. Ich schalte die Funktionen, von mir aus fahrtrichtungs- oder fahrstufen- abhängig, oder dreh den Regler langsamer oder schneller auf, je nach Last. Ich meine, das sind eher Automatikfunktionen, denn sie erledigen Aufgaben automatisch, ich geben nur das Ergebnis vor. Bspw. Ziel-FS = FS0 und der Decoder bremst FS für FS mit einer ABV herunter. Das ist Automatik.
Sie passt halt nicht in das von dir beschriebene Konzept, in dem eine Externe Software alles machen soll. Da muss man sich eben entscheiden, wer jetzt die Automation übernimmt. Decoder oder Software. Evtl. Muss man das auch aufteilen: Software für Automatik, Fahrdienstleiteraufgaben betreffend, Decoder für Automatik, Lokführeraufgaben betreffend. So verstehe ich das.

Zitat

---

Wo hast du diese Zahlen her? Die Decoder, die ich so kenne, arbeiten intern mit 128 Fahrstufen, höchstens mal mit 256.

---

Die 128 von denen du sprichst sind ja bereits externe Fahrstufen, denn auf die kannst du extern zugreifen und diese auch FS für FS einstellen (Tabelle: Zuordnung der internen zu den externen FSen). Intern steuert der Decoder die Lok aber mit deutlich mehr. Das hat u.a. mit der Motorregelung aber auch mit der ABV zu tun. Und daher kommen die Zahlen. Sonst ergäben sich Sprünge beim Wechsel von FS zu FS.

Zitat

---

Theoretisch hast du Recht. Nur: Die Software kann den Bremsvorgang dann auch abhängig von der angehängten Last steuern. Der Decoder kann das nicht, denn er weiß das nicht.

---

Ja, stimmt, da hast du Recht. Wenn schon, dann müsste auch in diesem Fall dem Decoder mitgeteilt werden können was für eine Last er am Haken hat. Die ABV müsste also Stufenweise eingestellt übertragen werden. Da reichen bestimmt 8 oder höchstens 16 Stufen also 3 oder 4 Bit.

Zitat

---

Das geht den Decoder dann immernoch nichts an. Diese Information gehört von der Software an den Handregler übertragen, nicht an den Decoder. Am Gleis ist und bleibt diese Information irrelevant. Warum sollte diese Information erst übers Gleis an den Decoder gehen und dann per Railcom (was ja noch nichtmal sooo weit verbreitet ist) wieder zur Zentrale und zum Handregler?

---

Stimmt, das wäre auch eine Möglichkeit. Nach deinem Konzept auch total nachvollziebar, weil du ja den Lokführer ausschließlich hinter dem Handregler siehst. Also muss dieser auch die Info nur auf seinen Regler bekommen. Korrekt.

Zitat

---

Auch die Zwangsbremsung muss der Decoder nicht alleine machen. Die Software kann in diesem Fall einfach FS0 senden und gut ist.

---

Stimmt auch. Die Funktion geht eben dann auch nur mit einer Steuerungssoftware.

Ich verstehe dich schon, du sagst jegliche Automation gehört nicht in den Decoder, selbst die ABV eigentlich nicht. Automation ist und bleibt bei dir die Domäne einer externen, zentralen Steuerungssoftware, die wo auch immer drauf läuft. Und das absolut.

Aber dieses Konzept ist doch total Ansichtssache, oder? Und auch nicht so von den Herstellern entwickelt worden. Wenn schon dann hat es sich so ergeben (ergeben müssen).

Hallo Meute ,

Bis jetzt habe ich ja nur mit interesse - teilweise kopfschüttelnd - hier mitgelesen ...

Ich möchte mich selbst zitieren, da das hier ebenso hin passt, was ich hier Stoppen am Signal? ABC vs. Software (z.B. Rocrail) mitte Februar schon geschrieben hatte:

Zitat

---

Ich finde an der Idee/Konzept mit den Rückmeldern und der somit unabdingbaren Software dahinter nichts verwerfliches. Ich denke ich kann Hermann auch verstehen, wenn er bemängelt, dass für das automatische Halten Rückmelder und damit erzwungenermaßen in irgendeiner Form auch eine Softwaresteuerung Bedingung ist. Offensichtlich geht oder ginge das ja auch anders. Was natürlich nicht heißt, dass man sich vor Software fürchten muss .
Aber gut das Konzept digitale Modellbahnsteuerung sieht heute und in Zukunft eben einen Rechner mit Software + die entsprechenden Sensoren auf der Anlage vor. Ist halt so ...
So lange die Steuerung nicht gezwungener Maßen auch größtenteils vor dem Bildschirm stattfindet, kann ich - und ich denke kannst auch du Hermann - hier glücklich werden.

---

Zitat

---

Sofern man annimmt, dass die meisten Mobahner sich wünschten, eine Lok könne automatisch (digitalkonform) vor einem Signal halten bzw. auf Streckensignale (Hp2, Sh1/2 ...) reagieren, so wird diese fehlende Funktion (dieser Mangel) durch das Prinzip Softwaresteuerung beseitigt.
Wenn dem nicht so ist, dann handelt sich es dabei eben lediglich um eine "nette" Funktion, die ein paar wenigen Freude bereitet, was doch auch ok wäre.

---

Dass dem nicht so wäre hielte ich für ein Gerücht. Ich kann mir sonst nicht erklären, warum es X Lösungsversuche verschiedener Hersteller gab und gibt, genau das Thema der automatischen ortsgebundenen Zugbeeinflussung in den Griff zu bekommen. Da muss schon ein deutliches Interesse für da sein, sonst entwickle ich doch diese Dinge nicht.
Ich sehe auch, wenn ich den Markt so überblicke, dass keine der angebotenen Lösungen diese Funktion uneingeschränkt liefert, ausgenommen Sensorik mit Softwaresteuerung. (Komplett andere Digitalsysteme wie dieses C-Digital nehme ich mal aus, weil ich mich da selbst nicht so auskenne)

Ich würde also schon sagen, dass alleine die Softwaresteuerung in der Lage ist die volle Steuerungsfunktionalität auch digital zu ermöglichen.

Zitat

---

... fehlende Funktion (dieser Mangel) durch das Prinzip Softwaresteuerung beseitigt.

---

Stimmt aus meiner Sicht voll.
Und damit muss digitale Modellbahn auch notwendigerweise auf den Computer (miniPC/PC-Zentrale und dergeleichen) zurückgreifen, sofern gewisse Funktionen verlangt sind, die sonst mangelhaft oder schlichtweg nicht existent wären.

Ganz einfach ... und für diese "Erkenntnis" diskutiert man hier seitenlang herum?

Das was du StephanLeist mit Carsten hier diskutierst, ist eigentlich ein anderes (eher hypothetisches) Thema:
"(Hätte es gegeben oder) gibt es keine "bessere"/andere Lösung, bei der man eine Softwaresteuerung nicht zwingend für die systemgerechte automaitsche Zugbeeinflussung * benötigt?"
*was für ein Ausdrck!!!

Die Idee Automationen welche die Lok/Lokführer betreffen im Decoder zu erledigen und solche die das Delegieren/Leiten von Zügen usw. in einer Softwaresteuerung, finde ich gar nicht so übel. Ich denke das hat was, v.a. weil sich dadurch auch gleich noch ein paar andere Vorteile ergäben. Das wäre praktisch die strickte Aufteilung von Fahrdienstleitung und Zugführern. Es wäre auf jeden Fall eine Alternative, die mE. durchaus ihre Berechtigung hätte.
Nur wie müsste das technisch umgesetzt werden? Hmm???


Schöne Grüße vom Rand der Platte

Jonas

Hallo Carsten und Stephan,

Zitat

---

Die 128 von denen du sprichst sind ja bereits externe Fahrstufen, denn auf die kannst du extern zugreifen und diese auch FS für FS einstellen (Tabelle: Zuordnung der internen zu den externen FSen). Intern steuert der Decoder die Lok aber mit deutlich mehr. Das hat u.a. mit der Motorregelung aber auch mit der ABV zu tun. Und daher kommen die Zahlen. Sonst ergäben sich Sprünge beim Wechsel von FS zu FS.

---

Exakt. Genau diese Sprünge kann man feststellen, wenn man - so in meinem Fall - mit Rocrail fährt und im Decoder einmal die ABV auf den Minimalwert stellt. Ich habe davon bereits an anderer Stelle berichtet.
Das ist nämlich genau eines der kleinen Probleme bei Softwaresteuerung, dass diese eben NICHT den Decoder so direkt steuern kann, wie sie das vielleicht können sollten. Man muss also - wie so oft - einen Kompromiss zwischen exakter Steuerung und geschmeidigem Fahren finden.
Ich gebe zu, so groß ist der Verlust an Exaktheit beim automatischen Halten nicht (+- 1 bis 3 cm mehr gegenüber Minimal-ABV bei mir), wenn man die ABV auf einen annemlichen Wert stellt.
Will man eine Präzisinon von +-1cm beim Halten, dann sieht man halt sprünge, bzw. ein abruptes Abbremsen, wenn der Zug vom Brems- in den Stopp-Bereich kommt. Also ich sehe das zumindest. (gibt auch Filme auf Youtube, wo man das bei Softwaresteuerung sehen kann)

Allen Enthusiasten zum Trotz möcht ich nur sagen, dass auch die Softwaresteuerung nicht frei von Kompromissen ist. Aber was ist das schon im Leben

Zitat

---

Das wäre praktisch die strickte Aufteilung von Fahrdienstleitung und Zugführern. Es wäre auf jeden Fall eine Alternative, die mE. durchaus ihre Berechtigung hätte.

---

Ja, das wäre vielleicht gar nicht so schlecht. Mir fallen da auch gleich einige Vorteile ein, die sich dadurch ergeben würden.

Zitat

---

Nur wie müsste das technisch umgesetzt werden? Hmm???

---

Das ist die eigentlich viel, viel wichtigere Frage. Dazu muss ich mir auch erst einmal Gedanken machen.

Zitat

---

Ok, das verstehe ich nicht ganz. Wenn es für den manuellen Betrieb ist, dann steuere ich doch sowieso - eben manuell. D.h. Ich schalte die Funktionen, von mir aus fahrtrichtungs- oder fahrstufen- abhängig, oder dreh den Regler langsamer oder schneller auf, je nach Last. Ich meine, das sind eher Automatikfunktionen, denn sie erledigen Aufgaben automatisch, ich geben nur das Ergebnis vor. Bspw. Ziel-FS = FS0 und der Decoder bremst FS für FS mit einer ABV herunter. Das ist Automatik.

---

Wie gesagt, das sind halt Komfortfunktionen. Ich würde das schon ein bisschen differenzierter betrachten. Ich z.B. würde nicht wie bei analog selber langsam am Regler drehen wollen. Bei der ABV ists aber auch wieder ein wenig eingebauter Realismus. Schließlich gibt der TF auch nur eine Fahrstufe vor und der Zug beschleunigt dann langsam auf diesen Soll-Wert.

Zitat

---

Die 128 von denen du sprichst sind ja bereits externe Fahrstufen, denn auf die kannst du extern zugreifen und diese auch FS für FS einstellen (Tabelle: Zuordnung der internen zu den externen FSen). Intern steuert der Decoder die Lok aber mit deutlich mehr. Das hat u.a. mit der Motorregelung aber auch mit der ABV zu tun. Und daher kommen die Zahlen. Sonst ergäben sich Sprünge beim Wechsel von FS zu FS.

---

Nochmal: Woher hast du diese Zahlen? Ich wüsste nicht, welcher Decoder so viele bietet. D&H verwendet intern 127 (vermutlich 128, wenn an FS0 dazu zählt). Zimo hat 255. Externe Fahrstufen gibts maximal 128, das ist schon klar.

Zitat

---

Ja, stimmt, da hast du Recht. Wenn schon, dann müsste auch in diesem Fall dem Decoder mitgeteilt werden können was für eine Last er am Haken hat. Die ABV müsste also Stufenweise eingestellt übertragen werden. Da reichen bestimmt 8 oder höchstens 16 Stufen also 3 oder 4 Bit.

---

Dann müsstest du aber auch entsprechend viele Brems- und Beschleunigungskurven haben. Wie auch immer, ich denke, hier bewegen wir uns dann schon deutlich an der Grenze dessen, was für die Modellbahn noch sinnvoll umsetzbar ist.

Zitat

---

Stimmt, das wäre auch eine Möglichkeit. Nach deinem Konzept auch total nachvollziebar, weil du ja den Lokführer ausschließlich hinter dem Handregler siehst. Also muss dieser auch die Info nur auf seinen Regler bekommen. Korrekt.

---

Genau so ist es. Was kümmert es die Lok, warum sie halten soll?

Zitat

---

Stimmt auch. Die Funktion geht eben dann auch nur mit einer Steuerungssoftware.

---

Wenn du einen virtuellen Fahrdienstleiter willst, dann kommst du um eine Software doch sowieso nicht herum. Und so drehen wir uns ein wenig im Kreis...

Zitat

---

Ich verstehe dich schon, du sagst jegliche Automation gehört nicht in den Decoder, selbst die ABV eigentlich nicht. Automation ist und bleibt bei dir die Domäne einer externen, zentralen Steuerungssoftware, die wo auch immer drauf läuft. Und das absolut.

---

Nein, das würde ich so nicht sagen. Man kann durchaus eine verteilte Steuerung bauen, der Aufwand dafür ist nur Wahnsinn im Vergleich zu ein paar Belegtmeldern, die man für die verteilte Steuerung ja eigentlich auch noch braucht.

Zitat

---

Aber dieses Konzept ist doch total Ansichtssache, oder? Und auch nicht so von den Herstellern entwickelt worden. Wenn schon dann hat es sich so ergeben (ergeben müssen).

---

Vielleicht. Nach meinem Empfinden sind diese Krücken wie ABC etc. aber letztlich nur entstanden, weil ein Teil der Kundschaft sich nicht vom analogen Denken lösen konnte oder wollte und diese lokalen Bremsdinger nur deshalb wollte, weil mans eben schon immer so gemacht hat. Wer sich mal ein wenig mit der ganzen Geschichte Software beschäftigt, müsste eigentlich schnell feststellen, dass die viel mehr kann, zuverlässiger funktioniert und um Welten flexibler ist. Allein schon die Möglichkeit eines Stellpults auf nem Tablet ist eine unfassbar geniale Sache. Wer mal den Drahtverhau eines Stellpults einer auch nur mäßig großen Anlage verkabeln durfte, wird verstehen, was ich meine. Oder sowas gar ändern, weil man an der Anlage was an- oder umgebaut hat...

Viele Grüße
Carsten

Hallo Carsten und Stephan,

ich mal wieder ...
Viellecht kann ich hier ein wenig Klarheit herstellen.

Zitat

---

Nochmal: Woher hast du diese Zahlen? Ich wüsste nicht, welcher Decoder so viele bietet. D&H verwendet intern 127 (vermutlich 128, wenn an FS0 dazu zählt). Zimo hat 255. Externe Fahrstufen gibts maximal 128, das ist schon klar.

---

Ich denke dass Stephan hier etwas verwechselt. Die meisten mir bekannten Decoder arbeiten intern mit 256 (0 bis 255) Fahrstufen. Die Werte der 10 oder 12 Bit Auflösung beziehen sich nicht direkt auf die internen FS eines Decoders, sondern auf die Auflösung der Regelungen und damit letztendlich für die Geschwindigkeit. Soweit ich weiß hatte der Lopi 4 bereits 10 Bit, also eine Auflösung der Regelung von 1024, der mld3 von Märklin hat eine Auflösung von 12 Bit also 4096. (alle Angaben ohne Gewähr)

@Stephan:
Die intern verwendeten Fahrsstufen, meist 256 an der Zahl, können sich wiederrum auf eine Geschwindigkeitsauflösung durch die Regelung von bspw. 10 oder mehr Bit beziehen. Das ist aber etwas anderes als die reine interne FS. Da hat Carsten schon Recht.

Zitat von StephanLeist im Beitrag Muss digitale Modellbahn notwendig auf den Computer zurückgreifen?

---

Aber wie soll denn eine externe Softwaresteuerung eben genau die selbe Feinfühligkeit hinbekommen, wenn sie den Lokdecoder mit gerade mal weniger als 13% oder sogar weniger als 4% der sonst vorhandenen Fahrstufen ansteuert? (Und das wohlgemerkt "ohne" die interne ABV)

---

Zitat

---

Ich z.B. würde nicht wie bei analog selber langsam am Regler drehen wollen. Bei der ABV ists aber auch wieder ein wenig eingebauter Realismus. Schließlich gibt der TF auch nur eine Fahrstufe vor und der Zug beschleunigt dann langsam auf diesen Soll-Wert.

---

Da könnte man aber auch sagen, am Regler gäbe ich als TF eine FS vor und die Software beschleunigt dann langsam auf diesen Soll-Wert. Das wäre nach dem von dir beschriebenen Konzept, Carsten, der korrekte Weg. Egal, ob das nun technisch sinnvoll wäre.
Der von Stephan angesprochene Punkt bleibt hier meines Erachtens schon. Nach deinen Vorgaben hätte die ABV im Decoder nichts verloren. Komfort-Funktion hin oder her.
Und da ergibt sich in der Tat das Problem, dass eine externe ABV nicht mit einer Auflösung von 1024 oder 4096 Werten arbeiten kann, sondern mit lediglich 128. Nach deiner Auffasung der Modellbahnsteuerung müsste eine Software demnach mit den 10 oder 12 Bit Geschwindigkeitswerten eine Lok steuern.

Zitat

---

Dann müsstest du aber auch entsprechend viele Brems- und Beschleunigungskurven haben. Wie auch immer, ich denke, hier bewegen wir uns dann schon deutlich an der Grenze dessen, was für die Modellbahn noch sinnvoll umsetzbar ist.

---

Nein, das müsste man nicht. Es genügt eine einzige Funktionsgleichung, der nur ein, zwei Funktionsparameter übergeben werden. Wenn so ein Parameter einen Wertebereich bspw. von 1 bis 200 hat, ergeben sich schon 200 Bremskurven. Die C-Digitaldecoder machen das im Übrigen so.

Zitat

---

Nach meinem Empfinden sind diese Krücken wie ABC etc. aber letztlich nur entstanden, weil ein Teil der Kundschaft sich nicht vom analogen Denken lösen konnte oder wollte und diese lokalen Bremsdinger nur deshalb wollte, weil mans eben schon immer so gemacht hat.

---

Das sehe ich anders. Die Alternative dazu wäre gewesen (und ist sie ja auch noch heute) sich einen PC an die Anlage anzuschließen. Das das heute (und seit etwa 2010) mit embedded PCs, Raspberry und modernen "PC"-Zentralen usw. kein Thema mehr ist ok, aber was war denn davor? Vielleicht war das für die Kundschaft nicht so toll, wenn sie beim Umstieg/Einstieg in Digital mit dem Wunsch einen Zug autom. vor einem Signal halten zu lassen, nur gehört hätten: "Ja, da müssen sie die komplette Steuerung ihrer Anlagen mit einem PC machen und dafür die Anlage mit Rückmeldemodulen ausstatten." Da kann ich mir vorstellen, dass das bei vielen nicht so toll ankam. Tut es ja heute oft auch noch nicht.

Zitat

---

Allein schon die Möglichkeit eines Stellpults auf nem Tablet ist eine unfassbar geniale Sache. Wer mal den Drahtverhau eines Stellpults einer auch nur mäßig großen Anlage verkabeln durfte, wird verstehen, was ich meine. Oder sowas gar ändern, weil man an der Anlage was an- oder umgebaut hat...

---

Absolut, ja! Und dann kommt noch irgendwo ein Kabelbruch in einer Leitung hinzu, den man dann suchen darf.
Irgendwann ist es dann besser alles rauszuschmeißen und neu zu machen, als noch Fehler zu suchen.
Die Funktion mit dem virtuellen Stellpult und der Softwaresteuerung zur Fahrdienstleitung wäre bei Stephans Konzept jedoch auch nicht anders. (Aufteilung: Zw. Fahrdienstleitung und Lokführern)

Hallo,

@Hermann:

Zitat

---

Ich denke dass Stephan hier etwas verwechselt. Die meisten mir bekannten Decoder arbeiten intern mit 256 (0 bis 255) Fahrstufen. Die Werte der 10 oder 12 Bit Auflösung beziehen sich nicht direkt auf die internen FS eines Decoders, sondern auf die Auflösung der Regelungen und damit letztendlich für die Geschwindigkeit. Soweit ich weiß hatte der Lopi 4 bereits 10 Bit, also eine Auflösung der Regelung von 1024, der mld3 von Märklin hat eine Auflösung von 12 Bit also 4096.

---

Ich war vielleicht mit den Begriffen nicht achtsam genug.

Zitat

---

Intern steuert der Decoder die Lok aber mit deutlich mehr. Das hat u.a. mit der Motorregelung aber auch mit der ABV zu tun. Und daher kommen die Zahlen. Sonst ergäben sich Sprünge beim Wechsel von FS zu FS.

---

Ich dachte, ich hätte das hier schon deutlich gemacht, was ich meine.

Zitat

---

Diese Zahlen stimmen also so in diesem Zusammenhang nicht. Die Software steuert den Decoder mit 50% der sonst vorhandenen FS an.

---

Ja, da habe ich mich dann geirrt.

Zitat

---

Außerdem zeigt es auch,... dass eine ABV außerhalb des Decoders schon gar keinen Sinn macht, [...]

---

Ja, das sehe ich auch so. Aus meiner Sicht macht eigentlich auch eine Streckeninformation eben im Decoder Sinn, weil sie ja eben die Lok und die Strecke betreffen und nicht die Fahrdienstleitung. Die gibt den Signalzustand praktisch vor, aber warum sollte sie die Inforamtion auch selbst wieder verarbeiten?
Genauso wie bei der ABV: Der TF (menschlich oder automatisch) gibt die Soll-Fahrstufe vor, verarbeiten muss sie aber der Decoder und nicht auch der TF, indem er den Regler langsam aufdreht (oder die Software indem sie die FS langsam erhöht).

So wie mir das Carsten erklärt hat, ist stand heute, im Prinzip die Softwaresteuerung sowhol Fahrdienstleitund als auch Lokführer, wenn man bspw. einen automatischen Halt möchte. Richtig, Carsten?

Zitat

---

Da könnte man aber auch sagen, am Regler gäbe ich als TF eine FS vor und die Software beschleunigt dann langsam auf diesen Soll-Wert.

---

Exakt, das hätte ich auch gesagt. Wenn eine Halteinformation, wie das Carsten mir geschrieben hat, von der Software an den Handregler (zum Lokführer) gechickt werden sollte, so muss auch umgekehrt gelten, dass der Lokführer eine Soll-Fahrstufe vorgibt und die Software dann die ABV (entsprechend Zuglast) zu simulieren hat und nicht der Decoder. Egal ob ich nun manuell per Handregler steuere oder ein Automat.
Die "Komfortfunktion" aus sicht des Bedieners bliebe also. Es wird aber trotzdem nicht so gemacht.

Zitat

---

Dann müsstest du aber auch entsprechend viele Brems- und Beschleunigungskurven haben. Wie auch immer, ich denke, hier bewegen wir uns dann schon deutlich an der Grenze dessen, was für die Modellbahn noch sinnvoll umsetzbar ist.

---

Nein, wieso? Sieh was Hermann geschrieben hat. Es braucht doch nur eine Bremsfunktion, die parametrierbar ist.

Zitat

---

Wenn du einen virtuellen Fahrdienstleiter willst, dann kommst du um eine Software doch sowieso nicht herum. Und so drehen wir uns ein wenig im Kreis...

---

Stimmt schon, ich wollte das nur noch einmal festhalten, dass diese Funktion eben nur bei einer Softwaresteuerung geht.
In dem von mir beschriebenen Konzept wäre es egal, ob man mit oder ohne Software, mit oder ohne virtuellem Fahrdienstleiter fährt.
Anders gesagt, ob die Fahrdienstleitung ein Mensch vor einem GBS ist oder ein Mensch vor einem virtuellen GBS oder eine automatisierte Fahrdienstleitung, wären egal. Rotes Signal bliebe rotes Signal mit allen Konsequenzen ...

Zitat

---

Man kann durchaus eine verteilte Steuerung bauen, der Aufwand dafür ist nur Wahnsinn im Vergleich zu ein paar Belegtmeldern, die man für die verteilte Steuerung ja eigentlich auch noch braucht.

---

Da bin ich noch nicht ganz mitgekommen, warum da der Aufwand so viel größer wäre ...

Zitat

---

ach meinem Empfinden sind diese Krücken wie ABC etc. aber letztlich nur entstanden, weil ein Teil der Kundschaft sich nicht vom analogen Denken lösen konnte oder wollte und diese lokalen Bremsdinger nur deshalb wollte, weil mans eben schon immer so gemacht hat.

---

Das würde ich wiederum differenzierter betrachten, als das einfach nur damit zu erklären, dass man sich nicht von analogen Denken lösen konnte. Für mein Verständnis ist es bspw. deutlich einleuchtender wenn man einen Befehl einem Signal das an der Strecke steht lokal zuordnen kann, als dafür erst eine virtuelle Welt in einem Rechner (Zentrale) erschaffen zu müssen. Das ist vom Gedanken her deutlich einläuchtender, finde ich. Nicht wegen analogem Denken, sondern weil das so direkt von der echten Bahn ableitbar ist.

Hallo zusammen,

ich hatte den Thread eröffnet, und 60 Beiträge später ziehe ich das Fazit:

• - die einzige tatsächlich neue Information in 60 Beiträgen ist, daß das Uhlenbrock-System die Funktionen, die bei den meisten Kollegen, die sie wünschen, durch einen PC übernommen wird, auch bietet.
• - Dazu kommt ein ziemlich nerviger Hahnenkampf; die Hähne wissen, wer gemeint ist, und müssen nicht extra genannt werden. Der praktische und sittliche Nährwert dieser Debatte ist null. Lediglich dem Verhaltensforscher bietet sich hier reiches Studienmaterial.

Hallo,

Zitat von CDC-User im Beitrag Muss digitale Modellbahn notwendig auf den Computer zurückgreifen?

---

Zitat von Klaus_K im Beitrag Muss digitale Modellbahn notwendig auf den Computer zurückgreifen?

---

Ich sehe das ganze Gerede um Digitalsteuerungen und deren ach so tolle Entwicklung deutlich nüchterner

---

Inwiefern genau?

---

Zitat

---

"(Hätte es gegeben oder) gibt es keine "bessere"/andere Lösung, bei der man eine Softwaresteuerung nicht zwingend für die systemgerechte automaitsche Zugbeeinflussung * benötigt?"
*was für ein Ausdrck!!!

---

Du hast noch "ortsgebunden" vergessen.

Zitat

---

Ja, natürlich hast du Recht. Nach meinem Kenntnisstand, gibt es (noch)keinen DCC Decoder der das kann. Weil es ja auch keinen DCC Befehl im Protokoll gibt, der diese Information bereitstellen würde.

---

Ach Stephan, das funktioniert doch bei DCC und allen ähnlichen Derivaten nicht. Das hatte Carsten doch schon einmal ziemlich am Anfang hier erklärt. Das geht rein technisch nicht. Das einzige was ginge wäre ein 1 Bit Bremsbefehl oder so etwas. Dafür bräuchte man aber zwingend Railcom und dieser Bremsbefehl wäre kein Broadcast-Befehl, sondern ausschließlich adressspezifisch.
Den einzige Vorteil, den ich dadurch erkennen kann, ist, dass man das Bremsen feiner und mit weniger Traffic auf dem Gleis stattfinden lassen könnte. *

Edit:
*Im Fall von DCC (und ähnlichen Systemen) selbstverständlich nur. Bei einem komplett anderen Digitalsystem, wo das mit dem Broadcast-Befehl möglich ist, sieht das natürlich wieder ganz anders aus. Da können sich auch andere Vorteile ergeben. So etwas geht in die Richtung was ich mir mit Railcom + ABC-Bremsen + miniPC zusammengebastelt habe. Das einzige mir bekannte System, welches das konsequent umsetzt ist das C-Digitalsystem.

Hallo Wolf,

Zitat

---

Die letzten Beiträge gehen dann schon von der eigentlichen Frage weg in die Richtung - die philosophisch interessant sein mag - wo in der Ablaufkette der Lokführer imitiert wird.

---

Das ist aber nun einmal eine für das Konzept eines Systems sehr entscheidende Frage, weil wie du ja erkannt hast, es keinen menschlichen Lokführer in einer Lok geben kann. (Im Modell bei kleineren Maßstäben)

Zitat

---

Dagegen wäre es meiner Ansicht nach interessant, für die Betrachtung automatisierter Anlagen nicht die herkömmliche lokführergesteuerte Bahn als Parallele heranzuziehen, sondern die automatisierte. Da wird - o Wunder - das, was der Kamerad Lokführer in seiner Lok tut, nicht an einer Stelle von einem automatischen System übernommen, sondern das gesamte Steuersystem inklusive Fahrdienstleitung und Fahrtsteuerung auf der Lok ist eine funktionelle Einheit. Die Parallelen zu Softwaresteuerungen sind sicher nicht zufällig. http://www.zukunft-mobilitaet.net/90799/...chteile-streik/

---

Klar kann man sich ausschließlich auf so einen Vergleich der vollautomatisierten Steuerungen in Realität und Modell beziehen. Das schließt dann jedoch den manuellen Betrieb grundsätzlich aus. Wenn man das möchte ok, aber dann reden wir über ganz andere Dinge. Dann betrachte ich eine Anlage komplett als die Hardware einer Maschine, die es mittels Software zu automatisieren gilt. Manuellen Betrieb parallel oder teils, teils, kann es dann nicht mehr geben (denn wo säße dann im
manuellen Fall der Lokführer? Auf einem Stuhl neben dem Fahrdienstleiter? ).
Freilich, dann zieh ich die Software und das ganze Konzept gleich ganz anders auf.
Letzten Endes gebe ich dann nur noch einen Soll-Fahrplan vor mit bestimmten Wunsch-Zugumläufen und alles weitere macht die Software. Voilà --> Voll-Automation. Meines ist das dann allerdings nicht mehr.
Hier wäre die Software dann keine Unterstützung im Sinne von Ergänzung zur Modellbahnsteuerung, sie wäre vielmehr der Zweck eines höheren im Modell eigentlich nicht vorhandenen Ziels. Oder wer von euch hat seine Modellbahn zum Zweck des Güter und Personentransports gebaut und muss Liefer- und Fahrzeiten einhalten?

Das einzige Szenario für Vollautomatik, ist das des reinen Zuschauerbetriebs. Ich persönlich halte das für eine recht eindimensionale Geschichte. Der Zweck liegt hier einzig und alleine Darin für einen Betrachter abwechlungsreichen Betrieb zu simulieren.
Wem das gefällt der soll das machen, aber worüber sollte man jetzt hier deiner Meinung nach diskutieren?


Ach ja, und was vielleicht aus deinem Link interessant sein dürfte (besonders für Stephan und Carsten):

Zitat

---

Bei Überfahren der ersten Balise erhält der Zug einen Bremsbefehl. Der Bordrechner kalkuliert die Bremskurve, um an einem vordefinierten Punkt zum Halten zu kommen. Um die Genauigkeit zu verbessern, wird diese Bremskurve bei Einfahrt in den Bahnhof mit weiteren Balisen in enger werdenden Abständen aktualisiert.

---

Das ist es was Stephan doch vorschlägt, mit den verbreiteten Digitalsystemen aber nicht möglich ist. Ich denke es ist klar, dass das Pendant zum Bordrechner der Lokdecoder nahe kommt und der Bremsbefehl einem Hp0-Befehl o.ä. gleich kommt.

Mir ist nicht klar wie du da zu dieser Ansicht kommen kannst:

Zitat

---

Da wird - o Wunder - das, was der Kamerad Lokführer in seiner Lok tut, nicht an einer Stelle von einem automatischen System übernommen, sondern das gesamte Steuersystem inklusive Fahrdienstleitung und Fahrtsteuerung auf der Lok ist eine funktionelle Einheit.

---

Die Geschwindigkeitsreduktion (Fahrstufen) wird über die Bremskurve im Bordcomputer (Decoder) berechnet und von dort auch die Lok gesteuert. Es ist eben gerade nicht so, dass eine Zentrale Softwaresteuerung extern die Bremskurve bestimmt und dann anhand dieser Bremsbefehle verschiedener Stärke (Verringerung der Fahrstufen) an das Fahrzeug übermittelt werden.
Die Aufgaben des Bordcomputers und des Fahrdienstleiters sind getrennt, auch wenn sie, wenn man das so sehen mag, eine funktionelle Einheit bilden. Aber klar müssen die Zusammenspielen, macht ja anders auch keinen Sinn.

Hallo,

Ja, Klaus. Natürlich funktioniert das so, wie Stephan das auch vorgeschlagen hat in der Realität.
Hier:

Zitat

---

Hierfür erhält das Zugsicherungssystem Informationen über die Belegung der kommenden Streckenblöcke durch einen vorausfahrenden Zug, wandelt diese in eine Geschwindigkeitsbegrenzung für den Streckenblock um, in dem sich der Zug gerade befindet, und sendet die neue Geschwindigkeitsbegrenzung an die Strecke. Der Zug nimmt diese Informationen über ortsfeste Einrichtungen wie Gleisstromkreise oder Balisen auf.

---

Es wird also iregndwo, im Zugsicherungssystem eine Geschwindigkeitsbegrenzung (wie Hp2) für einen Streckenblock ermittelt und diese wird dann lokal an einen Abschnitt der Strecke (ortsfest) übertragen, von wo aus sie von einem Zug aufgenommen und im internen Bordcomputer (Decoder) entsprechend verwertet wird.
Ich kann mich schwach erinnern, müsste das noch einmal nachlesen, aber ich meine von Martin_G, dem Entwickler des C-Digitalsystem, in einem seiner Beiträge/Erklärungen zu seinem System, genau das gelesen zu haben, was hier über ATP&ATO steht und was im Prinzip auch Stephan beschreibt/wünscht.

Zitat

---

Die Züge ermittelnden Standort ihres Zugschlusses selber und senden ihn quasi-kontinuierlich an den folgenden Zug. Dieser berechnet unter Berücksichtigung seines Bremsweges den Punkt, ab dem die Geschwindigkeit herabgesetzt werden muss.

---

Auch diese Train-to-Train (Lokdecoder zu Lokdecoder) Kommunikation im Modell, habe ich schon von irgend jemadem hier im Forum gelesen ... ? Kann sich zufällig jemand hier daran erinnern?
Aber das dürfte mit den Bestehenden Systemen (noch) nicht möglich sein und ich glaube kaum, dass das jemals kommen wird?

Zitat

---

Die Parallelen zu Softwaresteuerungen sind sicher nicht zufällig.

---

Ich schließe mich hier Klaus an. Wo du diese Parallelen siehst ist mir schleierhaft. Ich finde eher, dass man genau die Unterschiede sehen kann. Und zwar sogar in der Weise, dass das Konzept was Stephan hier beschreibt/wünscht/fordert, das ist, was auf der Seite deines Links im Prinzip erklärt wird. Das steht konzeptionell in deutlichem Widerspruch zu der externen Zentralensoftwaresteuerung, die (von extern) auch Triebfahrzeugführer ist. Triebfahrzeugführerfunktion übernimmt ein Bordcomputer.
Du kannst also sehen, dass es evtl. sehr wohl Sinn macht, über die Lokalisierung des Zugführers bei einem Konzept zu sprechen, auch wenn das hier zu dem anfänglichen Thema wohl nichts (kaum etwas) beiträgt.

Hallo,

da die Diskussion schon seit mehreren Beiträgen nur noch am Rande mit dem eigentlichen Thema hier zu tun hat, habe ich hier:viewtopic.php?f=5&t=179260 ein neues Thema eröffnet.

Wenn noch Interesse besteht, könnte man dort gerne gezielt diese Fragen diskutieren ...


Grüße vom Rand der Platte

Jonas

Hallo,

es gibt ein französisches Sprichwort, das sagt: jeder macht Mittag, wenn die Sonne in seine Tür scheint.

Ich sehe einen deutlichen Unterschied, ob ein Mann in der Lok sitzt, der aufgrund der Informationen, die ihm aus verschiedenen Quellen zur Verfügung stehen, der Lok eine Geschwindigkeit einstellt, oder ob ein Zentralrechner dem Zug mitteilt, welche Geschwindigkeit er fahren soll. Wenn das für euch dasselbe ist, dann reden wir auf nicht kompatiblen Grundlagen - mit anderen Worten, ein fruchtbarer Austausch ist nicht möglich.

Außerdem blendet ihr, soweit ich euch verstehe, in eurem Versuch, mir Falschdenken nachzuweisen, konsequent aus, daß auf der verlinkten Seite das System aus drei Subsystemen besteht, die nur zusammen funktionieren können. ATP, ATS, ATO. Nur das ATO ist an Bord des Zuges - in Anbetracht der Größe des Zuges verglichen mit der nötigen Elektronik auch kein Problem - und die anderen Systeme sind außerhalb. Nur auf das ATO bezieht sich Klaus' Zitat:

Zitat

---

Zitat

---

Bei Überfahren der ersten Balise erhält der Zug einen Bremsbefehl. Der Bordrechner kalkuliert die Bremskurve, um an einem vordefinierten Punkt zum Halten zu kommen. Um die Genauigkeit zu verbessern, wird diese Bremskurve bei Einfahrt in den Bahnhof mit weiteren Balisen in enger werdenden Abständen aktualisiert.

---

Das ist es was Stephan doch vorschlägt, mit den verbreiteten Digitalsystemen aber nicht möglich ist. Ich denke es ist klar, dass das Pendant zum Bordrechner der Lokdecoder nahe kommt und der Bremsbefehl einem Hp0-Befehl o.ä. gleich kommt.

---

Soweit ich orientiert bin, ist das ziemlich genau, was passiert, wenn in einem handelsüblichen Programm nicht die Einmessung der Züge verwendet wird, sondern die Zwei- oder Dreipunktbremsung, verbunden mit dem "konstanten Bremsweg", den einige Decoderhersteller anbieten. Ich nutze das nicht und kenne es deshalb nicht näher.

Zitat

---

Klar kann man sich ausschließlich auf so einen Vergleich der vollautomatisierten Steuerungen in Realität und Modell beziehen. Das schließt dann jedoch den manuellen Betrieb grundsätzlich aus. Wenn man das möchte ok, aber dann reden wir über ganz andere Dinge. Dann betrachte ich eine Anlage komplett als die Hardware einer Maschine, die es mittels Software zu automatisieren gilt. Manuellen Betrieb parallel oder teils, teils, kann es dann nicht mehr geben (denn wo säße dann im
manuellen Fall der Lokführer? Auf einem Stuhl neben dem Fahrdienstleiter? ).
Freilich, dann zieh ich die Software und das ganze Konzept gleich ganz anders auf.
Letzten Endes gebe ich dann nur noch einen Soll-Fahrplan vor mit bestimmten Wunsch-Zugumläufen und alles weitere macht die Software. Voilà --> Voll-Automation. Meines ist das dann allerdings nicht mehr.
Hier wäre die Software dann keine Unterstützung im Sinne von Ergänzung zur Modellbahnsteuerung, sie wäre vielmehr der Zweck eines höheren im Modell eigentlich nicht vorhandenen Ziels. Oder wer von euch hat seine Modellbahn zum Zweck des Güter und Personentransports gebaut und muss Liefer- und Fahrzeiten einhalten?

---

Richtig, das ist Vollautomatik. Eine Art der Vollautomatik. Man kann es auch ohne Fahrplan machen, das wird augenzwinkernd manchmal "Aquarium-Modus" genannt. Du wirst staunen, wie viele Kollegen das betreiben; die findest du dann in den Foren der jeweiligen Software. Hart wird es, in meinen Augen, wenn sie versuchen, im reinen Zufallsmodus die Dinge so zu strukturieren, daß der Zufall wieder zu einem geordneten Ergebnis führt. Da wären Fahrpläne so viel einfacher!
Es gibt aber keinen Grund, das abschätzig zu belächeln. Warum soll man nicht seine Freude daran haben können, einfach ein funktionierendes System zu beobachten? Was tun Trainspotter anderes? Niemand zwingt dich, das als höchstes der Ziele anzusehen. Jedem das Seine. Ich belächle ja auch nicht die Timesaver-Fans, obwohl ich dieser Art Modellbahn nicht viel abgewinnen kann. Im Gegenteil, ich freue mich über die Vielfalt der Konzepte, die sich die einen und die anderen erschaffen.

Aber:

Zitat

---

Manuellen Betrieb parallel oder teils, teils, kann es dann nicht mehr geben (denn wo säße dann im
manuellen Fall der Lokführer? Auf einem Stuhl neben dem Fahrdienstleiter? ).

---

Spätestens an dieser Stelle höre ich auf, deinen Vortrag ernstzunehmen. Denn das ist nun mal - von den bereits erwähnten Aufsitzbahnen abgesehen - das Prinzip der Modellbahn, daß der Mensch, der steuert, nicht in der Lok sitzt. Oder hast du in deiner Lok gesessen, als du als Bub mit der analogen Bahn gespielt hast? Ich nicht, ich paßte da schon mit fünf Jahren nicht mehr hinein.

Weißt du, Klaus, wir sind hier auf einer Diskussionsebene, die nicht technisch dominiert ist. Da gibt es nicht die einfache Entscheidung zwischen "stimmt" und "stimmt nicht". Wobei die Techniker manchmal auch aus dieser einfachen Denke herauskommen müssen, oder anerkennen, daß ihre Axiome falsch sind. Die Stromrichtung als Beispiel, die entgegengesetzt der Bewegung der Elektronen geht...
Wir reden hier auf einer Ebene, wo man abwägen muß. Zu verstehen versuchen, was der andere denkt, und auch wie er denkt, um zu seinen Ergebnissen zu kommen. Damit kann man dann seine Sicht auf die Dinge erweitern und sie besser verstehen. Es gibt aber nicht "die" richtige und viele "falsche" Sichten. Falsch, wenn nicht mit den Fakten übereinstimmend, ja. Aber immer noch bleibt, wie die Fakten zu bewerten und zu gewichten sind, und darüber kann man sehr lange und - wenn man will - fruchtbar diskutieren.
Ich kenne deine Beiträge zum Thema "intelligente Decoder", wenn ich das mal so betiteln darf, deine foliantenlangen Diskussionen mit Martin und CDC-User. Du bleibst aber immer auf deinem Argumentationsschema und gehst nicht darauf ein, was andere anders sehen können - oder machst es lächerlich. So kommt keine Diskussion weiter. Das ist steril, das ist "deaf people's dialogue". Da sagen sich dann andere: "Ach, Klaus wieder. Laß ihn reden, wir machen woanders weiter." Wie es hier bereits geschehen ist.
Ich find's schade. Schade, weil es einiges zu sagen gegeben hätte. Schade, weil auch du einiges dazu beitragen kannst.
Aber genau weil die Wahrheit viele Facetten hat, ist deine Sicht nicht die einzig richtige, ebensowenig wie meine, Stephans oder Carstens. Sondern wir alle haben eine Sicht auf die Dinge, und je nach Sonnenstand und Perspektive kommen wir dabei zu verschiedenen Meinungen.
Ein Kind sagte: "wenn die Ampel rot ist, dürfen die Fußgänger die Straße überqueren."
Stimmt das? Wir lernen schließlich: ist die Ampel rot, so bleibe stehn; ist die Ampel grün, so darfst du gehn.
Und doch hat das Kind Recht.
Aber dazu müssen wir die Sache durch die Augen dieses Kindes betrachten.
Und dieses Kind, ein echtes Dorfkind, kennt Ampeln nur, wo es mit den Eltern im Auto fährt. Da hat es völlig richtig beobachtet: wenn die Ampel rot ist, hält das Auto an, und die Fußgänger dürfen über die Straße gehen. Daß die Fußgänger in diesem Moment ein grünes Licht sehen, weiß das Kind nicht und kann es auch nicht sehen.

Wenn wir aber nun nicht durch die Augen des Kindes sehen, sondern hingehen und im Brustton der Überzeugung diesem Kind erklären, daß es sich irrt, was geschieht dann? Wird das Kind sagen, "ja, ich habe mich getäuscht, danke für den Erkenntnisgewinn?" Nein, es wird uns für dumm halten. Und damit hat es - noch einmal - Recht. Aber auch das können wir nicht erkennen, solange wir nicht bereit sind, die Perspektive des Kindes einzunehmen.

Hallo Wolf,

Zitat

---

es gibt ein französisches Sprichwort, das sagt: jeder macht Mittag, wenn die Sonne in seine Tür scheint.

---

der Gesprächsfaden ist verloren gegangen und das liegt m.E. auch zu einem sehr großen Teil an der unglücklichen und etwas geschraubt wirkenden Fragestellung:
"Muss digitale Modellbahn notwendig auf den Computer zurückgreifen?"

Wär es nicht wirklich an der Zeit, dass Du den von Dir begonnenen Thread schließt und Dich konstruktiv an einem neuen Versuch beteiligst?

MfG

vik

Hallo Ihr Spezialisten:
Was haltet Ihr davon:

https://www.modellbahn-steuerung.de/

Gruß Opa Helmut

Hallo Wolf,

weißt du, Wolf, du sitzt auf einem ganz schön hohen Ross. Schulmeistersts und erklärst, wie ich nicht in der Lage wäre Dinge einmal aus einem anderen Blickwinkel zu betrachten. Ja, wirfst mir sogar indirekt vor, ich würde gewisse Möglichkeiten des Modellbahnbetreibens abwertend belächeln.

Dann stellst du mich als derart naive Person dar, dass es schon fast frech und anmaßend ist. Ich weiß nicht sicher, was du damit eigentlich bezweckst. Die Aussagen und Belehrungen, die du mir vorgetragen hast, solltest du dir einmal selbst vorhalten.
Versuch doch erst einmal eine andere, dir offensichtlich fremde, Denkweise und Sicht auf einen Sachverhalt zu verstehen, bevor du darüber urteilst und richtest.

Zitat

---

Da wird - o Wunder - das, was der Kamerad Lokführer in seiner Lok tut, nicht an einer Stelle von einem automatischen System übernommen, [...]

---

Erkläre mir doch einmal, wieso du bspw. an dieser Stelle mit einem "- o Wunder -" in den Diskurs trittst? Ein Ausdruck wie diesen verstehe ich an dieser Stelle ironisch, als wolltest du damit sagen: "Ja wie könnte es auch anders sein!?"
Oder willst du mir weismachhen, du hieltest hier tatsächlich etwas für ein Wunder?

Du fällst äußerst leichtfertig eine Aussage über etwas, ohne dir über eine andere Sicht auf den Sachverhalt gedanken zu machen. Ebenso leichtfertig hast du ja über mich geurteilt. Ich rate dir daher schulmeistere dich vielleicht ein stückweit auch einmal selbst.

Mir wäre nicht bekannt, dass es je möglich gewesen wäre, dass ein Mensch als Lokführer in einer Modelllok sitzt. Eine Diskussion über darart unrealistische Dinge hielte ich für vollkommenen Unsinn. Was ist mit dir?

Wenn du schon Probleme damit hast, meine Aussagen richtig zu verstehen, dann frage doch einfach nach, dann versuche ich darauf einzugehen. Womöglich bin ich bei einigen Sichtweisen ja auch einem Irrtum aufgesessen - ist durchaus schon vorgekommen - und dann hätten wir ggf. beide etwas davon.

Auch wenn du mich nicht wirklich gefragt hast, möchte ich noch etwas zu der letztn Thematik und meiner Sicht darauf erklären.

Für mich hat jede digitale Lok einen Bordcomputer, der Befehele einer externen Steuereinheit entgegen nimmt. Damit meine ich den Decoder.

Jetzt gibt es bei dem Modellbahnbetrieb aus meiner Sicht prinzipiell 2 Möglichkeiten + eine 3. als Mischform:
A) Der Decoder erhällt seine Befehle von einem Menschen. (Direkt, also unmittelbar über ein Steuergerät z.B. einem Handregler.)
B) Der Decoder erhällt seine Befehle von einer Maschine. (z.B. einem PC o.ä.)
Mischform) Aufteilung der Befehlsgewalt unter mehreren Befehlsgebern. (Bsp. Fahrdienstleiter & Mensch an Handregler, etc.)

Zitat

---

Falschdenken nachzuweisen

---

Das brauche ich dir nicht nachweisen, was hätte ich davon? Ich habe lediglich erklärt, dass ich zu einem genau anderen Schluss aus dem Link komme, als du ihn gezogen hast. Dann habe ich, damit man meine Aussage verstehen kann, versucht darzulegen, was mich zu dieser Sicht auf die Sache bewogen hat - und mehr nicht.

Es wird erklärt, dass ein externer Bremsbefehl lokal an den Bordcomputer eines Zuges übermittelt wird und dieser dann eine Bremskurve berechnet, nach welcher er (der Bordcomputer) dann den Zug bremst. Zur Kontrolle wird dieser Vorgang während des Bremsens mehrere Male wiederholt, um eine möglichst hohe Genauigkeit zu gewährleisten.
So habe ich den Text verstanden. Wie verstehst du ihn?

Zitat

---

Soweit ich orientiert bin, ist das ziemlich genau, was passiert, wenn in einem handelsüblichen Programm nicht die Einmessung der Züge verwendet wird, sondern die Zwei- oder Dreipunktbremsung, verbunden mit dem "konstanten Bremsweg", den einige Decoderhersteller anbieten. Ich nutze das nicht und kenne es deshalb nicht näher.

---

Würdest du, wenn du schon behauptest, dass das ziemlich genau diese Zwei- oder Dreipunktbremsung sei, mir diese bitte genauer erklären (auch per PN). Ich meine dein Kenntnisstand wird schon ausreichen, du kannst ja immerhin abschätzen, dass das "ziemlich genau" das gleiche sei.

Zitat

---

Du wirst staunen, wie viele Kollegen das betreiben; die findest du dann in den Foren der jeweiligen Software.

---

Ja, das ist richtig. Es macht auch Sinn. Den Zweck, den die Softwaresteuerung hier dann erfüllt, ist der der Simulation eines möglichst abwechlslungsreichen Bahnbetriebs. Er eignet sich auch gut für reine Schauanlagen. Aber gut das hatte ich ja alles schon geschrieben ... (ohne Unterton und ohne das abschätzig zu belächeln)

Zitat

---

Manuellen Betrieb parallel oder teils, teils, kann es dann nicht mehr geben (denn wo säße dann im
manuellen Fall der Lokführer? Auf einem Stuhl neben dem Fahrdienstleiter? ).

---

Mit dieser rethorischen Frage habe ich mich nur darüber amysiert, weil ich mir vorgestellt habe, wie eine Automationssoftware (evtl. mit ein paar wenigen Fahrdienstleitern zur Kontrolle) den Betrieb steuert und die Lokführer für das manuelle Steuern nicht automatisierter Loks "daneben sitzen" (mit der Software eins werden), was es so nicht gibt. (in Echt)

Im Modell ist bei voller Softwareautomation, das haben wir hier über Seiten geklärt, der Fahrdienstleiter und der Lokführer eins. Damit eine manuelle Fahrt bei einem Teils Teils Betrieb keinen Unsinn anrichten kann und es zu keinem Zuständigkeitskonflikt kommt, wird im Modell der Fahrbefehl trotzdem über die Software laufen (laufen müssen) - auch wenn dieser von einem Lokführer (in Person ein Modellbahnspieler) von Hand, also manuell gesteuert wird.
Auch das sehe ich als deutlichen Unterschied zwischen einem Automationssystem in Echt und im Modell.
In Echt, so verstehe ich das, steuert der Lokführer einer manuellen Lok, diese direkt auf dem Führerstand (im Modell natürlich nicht) und muss sich lediglich, wie sonst auch, an die Vorgaben der Fahrdienstleitung halten (ob nun Automat oder Mensch). Im Modell steuert der "Lokführer" einer manuellen Lok diese eben genau nicht direkt. Er "vereint" sich praktisch mit der Software und von dort gehen die Steuerbefehle über die Schiene zum Decoder (Bordcomputer).
Ich sehe hier einen deutlichen Unterschied.
Wie siehst du das?

Zitat

---

wir sind hier auf einer Diskussionsebene, die nicht technisch dominiert ist. Da gibt es nicht die einfache Entscheidung zwischen "stimmt" und "stimmt nicht".

---

Nein, hier geht es rein um konzeptionelle Fragen. Diese gilt es zu beantworten, wenn man Systeme vergleichen will. Mit Schwarz-Weis-Denken à la "stimmt", "stimmt nicht" hat das nichts zu tun. Man muss ja nicht den Anspruch haben Systeme und Konzepte zu vergleichen und den Fakten ins Auge zu sehen, dann verwehre ich mich aber gegen Aussagen wie: "Dieses System sei wie jenes System und jenes System sei wie ...". Das entbehrt dann jeglicher Grundlage.

Zitat

---

Ich kenne deine Beiträge zum Thema "intelligente Decoder", wenn ich das mal so betiteln darf, deine foliantenlangen Diskussionen mit Martin und CDC-User.

---

Was für ein Thema? Was für Beiträge? Was hätte das hier verloren? Bitte nimm doch dort Bezug, wo du mit Aussagen probleme hast und unterlasse doch diese "querschießer". Was soll das - und v.a. wem etwas - bringen?


P.S.: Und die Sonne dreht sich genauso um die Erde wie die Erde um die Sonne...



Edit: Das musste ich jetzt noch abschicken, sonst hätte ich mir die Mühe ja vollkommen umsonst gemacht.

Hallo Wolf und alle anderen,

Eigentlich wollte ich Dein Statement als Schlusswort stehen lassen, weil mich der Zitier-Marathon der "3 von der Tankstelle" auch mehr als genervt hat.
Auch Deine Kinder-Allegorie mit der Verkehrs-Ampel bringt das Problem auf den Punkt.
Aber eine Aussage kann ich nicht so ganz unwidersprochen lassen:
Die Sache mit dem Lokführer!
Sicherlich ist es physikalisch ein Ding der Unmöglichkeit, ein Lok kleiner Als Maßstab 1:12 selbst vom Führerstand aus zu steuern, aber ich glaube schon, dass bei vielen Modellbahnern dieser Wunsch besteht. Wenn ich mir die Zugriffszahlen der "Führerstands-Mitfahrten" auf YT sowohl in 1:1 als auch virtuell in 1:87 so ansehe, dann muss da gesteigertes Interesse bestehen, Wenn Roco Kamera-Loks entwickelt und Märklin einen virtuellen Führerstand in ihrer Spielewelt-Mfx-plus-Umgebung integriert, dann muss auch dafür Interesse bestehen (Perfekt wäre übrigens die Symbiose: Das Video-Bild der Roco-Kamera-Lok in den MFx-Führerstand eingeblendet ergibt echtes Lokführer-Feeling ).
Aber sooo weit von der Wirklichkeit sind wir doch nicht, wie Du jetzt meinst, für Streckenloks vielleicht noch, aber Rangierloks lassen sich über Rangierfunk fernsteuern und genau das machen wir doch auch auf unseren Anlagen, wir steuern eine Lok mit einer Art Fernbedienung…

Zu Guter letzt wollte ich auch noch einmal über den Software- und Computer-Einsatz philosophieren, in dem ich einen Schritt zurücktrete und den Computer nicht nur als Teil der Anlagensteuerung sehe.
Warum brauchen wir den Computer?
Das hat dieser Thread schon beantwortet: Es geht um Automatische Abläufe, die die Software-Steuerung nicht einzig aber doch am einfachsten, relativ preiswert und für die meisten Anwendungen passend bereitstellen kann.

Aber warum brauchen wir überhaupt automatische Zugsteuerung???
Weil wir mehr Betrieb auf unseren Anlagen sehen wollen, als wir selbst managen können.
Wir benötigen Kollegen Computer als Spielkamerad, als ständig verfügbaren Mitspieler, an den wir als (meistens) "Einzelspieler" Funktionen abtreten können bis hin zur Vollautomatik, bei der wir gar keinen Finger mehr krumm machen müssen und wie im MiWuLA Modellbahn nur noch "konsumieren"…
Insofern ist Klaus Vergleich:

Zitat

---

Manuellen Betrieb parallel oder teils, teils, kann es dann nicht mehr geben (denn wo säße dann im
manuellen Fall der Lokführer? Auf einem Stuhl neben dem Fahrdienstleiter [respektive Kollege Computer]? ).

---

…gar nicht so falsch!

Es ist also auch eine Mentalitätsfrage, wer von uns jetzt SW benötigt und wer nicht…
Es gibt Genügsame und es gibt unmässige Modellbahner, nicht nur was den Platz angeht, sondern v. allem was das Layout der Anlage und den angedachten Betrieb angeht, Wer dem Anlagen-Bau-Credo "Weniger ist Mehr" frönt, wird wahrscheinlich auch häufiger ohne Software auskommen …

Habt schöne Ostern und schlagt Euch nicht mehr die Köppe ein, auch nicht verbal!

uLi

Zitat

---

Was haltet Ihr davon:

https://www.modellbahn-steuerung.de/

Gruß Opa Helmut

---

Hallo Helmut,

danke für den Link. Das finde ich interessant und ich hätte auch einwenig dazu zu sagen, möchte dies aber hier nicht mehr tun.
Ich bitte um dein Verständnis. Evtl. machst du ein neues Thema auf, in dem es konkret um dieses Konzept geht.

Hallo Wolf,

Zitat von Railwolf im Beitrag Muss digitale Modellbahn notwendig auf den Computer zurückgreifen?

---

Da frage ich mich beispielsweise, wie sinnvoll und notwendig es ist, Heizungsventile mit einem "Offenes-Fenster-Sensor" zu versehen, der dafür sorgt, daß der Heizkörper abgeschaltet wird, wenn ein starker Temperaturabfall festgestellt wird. Natürlich ist es ein Leichtes, so etwas in eine elektronische Thermostatsteuerung einzubauen, denn alles, was man dafür braucht, ist ja hardwareseitig vorhanden. Aber ist es ernsthaft nötig und wünschenswert, daß wir die Fenster aufreißen, ohne uns über die Heizung Gedanken zu machen?

---