Hallo Marius,

Zitat

---

Wie meinst du das mit Digital als besseres Analog mit Hardwarecodierung?

---

Damit meine ich, wenn Bremsbausteine - oder wie man das immer nennen mag, jedenfalls Elemente, die eine Lok zum Bremsen und Anhalten bringen - an festen Punkten in die Anlage verbaut werden. Das ist vom Prinzip her nichts anderes als was wir früher (tm) auch analog gemacht haben, mit Halteabschnitten und Stromlosschaltungen - die ganz Gewitzten sogar schon mit temperaturabhängigen Widerständen, die ein langsames Abbremsen halbwegs ermöglichten.
Das im Gegensatz zur zentral überwachten und gesteuerten Anlage, wo bei exakt derselben Konfiguration (Fahrgeschwindigkeit, freie Gleise, Signalstellung) der eine Zug zum halten kommt (Personenzug) und der andere durchfährt (Güterzug) oder der Eilzug mal hält und mal nicht, je nach Fahrplan. Das kann mit vertretbarem Aufwand nur durch Softwaresteuerung geleistet werden.
Interaktion zwischen Anlagenbauteilen und Rollmaterial ist dazu aber nicht in der Lage - allein schon, weil dazu zu viele Informationen auch in der Lok transportiert werden müssten, die der Lokführer in 1:1 zwar in seiner Tasche mitbringen kann, nicht aber der Decoder in 1:87 oder gar 1:160. (Und dass es selbst in 1:1 nicht immer klappt, davon wissen z.B. einige Passagiere ein Lied zu singen, die in Wolfsburg den ICE nehmen oder daraus aussteigen wollten.)

Zitat

---

Sehe ich ganz genauso, - mit Selbstabsicherung des eigenen Blocks.

---

Die "Selbstabsicherung" wird aber nicht durch den Zug vorgenommen, sondern durch an der Strecke montierte Elemente. Auch da ist der Lokführer nur Befehlsempfänger.

Zitat

---

Allerdings möchte ich nicht in ALLEN Punkten ein Modell der großen Bahn .

---

Jeder wie er mag. Aber, vorsichtig ausgedrückt, ist es heutzutage nicht einfach zu vermitteln, dass man ein existierendes und funktionierendes System, das noch dazu halbwegs realistisch die große Bahn abbildet, strikt ablehnt und die Entwicklung und Einführung eines neuen Systems einfordert, das gerade "unrealistisch" ist.

Und auf die Gefahr hin, zu wiederholen, was schon andere gesagt haben: ich habe den Eindruck, du verurteilst hier Systeme, die du nur sehr unzureichend kennst, auf der Basis von Informationen, die du da und dort gefunden hast und von denen du mangels Kenntnissen und Erfahrung nicht sagen kannst, inwieweit sie zutreffen, ob allgemein oder nur in bestimmten Fällen oder vielleicht auch nur Frucht einer Fehleinschätzung sind - und was davon dem System zuzurechnen ist und was den Herstellern, die sich möglicherweise nicht an gewisse Regeln gehalten haben oder auch sich im Jahre 2001 noch nicht an erst 2006 erstellte Regeln halten konnten (willkürlich erdachte Zahlen; ich hatte jetzt keine Zeit und Lust, die richtigen Zahlen herauszusuchen, und es kommt eh aufs Gleiche heraus). Dazu kommt die Vermengung von DCC und mfx und MM einerseits, die vor allem dazu gedacht sind, Aufträge von der Zentrale zur Lok bzw. dem Zubehördecoder zu bringen, und diversen Meldebus-Systemen, die umgekehrt dazu dienen, Informationen von der Anlage zur Zentrale bzw. auch zum verbundenen Rechner zu bringen.
Hier stellt sich auch immer die Frage, wozu man es braucht.
Wer nur durch den Ort zum BÄcker und zum Arzt fährt, braucht keinen Maserati oder Bentley, da tut es ein Ligier-Gefährt mit Moped-Kennzeichen. Wer seine Modulanlage öfter mal zu Ausstellungen fahren will, braucht einen Kombi oder Lieferwagen und keinen Mx5.
Mein Programm funktioniert sehr gut mit binären Rückmeldern - also solchen, die nur "frei" oder "belegt" melden. Mehr Info bringt nicht mehr Nutzen, sondern nur höhere Kosten, warum also sollte ich mehr wollen?
Railcom geht nur mit DCC. Ich habe Loks mit Decodern, mit denen ich sehr zufrieden bin, die aber kein DCC verstehen. Andere verstehen DCC, sind aber nicht railcomfähig.Der Austausch allein dieser Lokdecoder würde mich tausende Euro kosten und mir keinen Mehrwert bringen.

Um auf die Überschrift zurückzukommen (die Ausgangsfrage war ja im dritten Antwortbeitrag bereits umfassend geklärt): die DCC-Sphäre hat, nachdem sie zunächst mal mfx und die darin implizierte Rückmeldung aus dem Lokdecoder an die Zentrale belächelt hatte, Railcom auf den Weg gebracht, dann gibt es auch Railcom+ und BiDiB. All dies zielt, wenn ich es richtig einschätze, auf gewisse Funktionalitäten im Automatikbetrieb ab.
Märklin hat mfx+ entwickelt, das weitergehende Interaktion zwischen CS2/3 und Lok ermöglicht, aber mit einer anderen Zielsetzung (die von vielen "ernsthaften" Modellbahnern belächelt oder auch abschätzig abgetan wird - aber Kunden dafür scheint es ja zu geben...): bei der manuellen Steuerung der Lok auf Elemente des "richtigen" Bahnwesens eingehen zu können, derzeit vor allem eben den Verbrauch bestimmter Betriebsmittel (Brennstoff, Sand, Wasser bei Dampfloks).
DCC wird, von Haus aus, über eine Reihe von Kontrollschaltern eingestellt, die man CV nennt. Mfx funktioniert grundsätzlich mit einer Bedienoberfläche, die als Interface zwischen den Kontrollschaltern und dem Anwender liegt - für DCC erledigen das, wenn man will, Programme wie JMRI oder auch die Decoderprogrammier-Programme der verschiedenen Hersteller. Da ich es schon nervig finde, einem Fahrradtacho den richtigen Raddurchmesser einzugeben, kannst du dir vorstellen, wo meine Präferenz liegt. Und doch "kann" ich beides.
Mehrere Hersteller haben inzwischen - mit mehr oder weniger Erfolg - Routinen in ihre Decoder eingebaut, die dazu dienen (sollen), den Decoder genau auf den Motor abzustimmen. Protokollunabhängig.

Für mich gibts da keinen "Sieger". Aber auch zum derzeitigen Zeitpunkt keinen Bedarf für große Neuerungen.

[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
die DCC-Sphäre hat, nachdem sie zunächst mal mfx und die darin implizierte Rückmeldung aus dem Lokdecoder an die Zentrale belächelt hatte, Railcom auf den Weg gebracht
[/quote]
Railcom wurde 2000 vorgestellt, MFX 2004.

[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147] dann gibt es auch Railcom+ und BiDiB.
All dies zielt, wenn ich es richtig einschätze, auf gewisse Funktionalitäten im Automatikbetrieb ab.
[/quote]
Railcom+ ist Erweiterung von Railcom um die Mfx-Anmeldung.

Grüße
Stephan

Zitat

---

[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
die DCC-Sphäre hat, nachdem sie zunächst mal mfx und die darin implizierte Rückmeldung aus dem Lokdecoder an die Zentrale belächelt hatte, Railcom auf den Weg gebracht

---

Railcom wurde 2000 vorgestellt, MFX 2004.

[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147] dann gibt es auch Railcom+ und BiDiB.
All dies zielt, wenn ich es richtig einschätze, auf gewisse Funktionalitäten im Automatikbetrieb ab.
[/quote]
Railcom+ ist Erweiterung von Railcom um die Mfx-Anmeldung.

Grüße
Stephan
[/quote]

Hier steht, dass Railcom 2007 in die NMRA-Spezifikationen eingetragen wurde. Vorher mag es existiert haben, aber war standardfremd und u.U. sogar standardwidrig. (Und kein Hahn hat danach gekräht.)
Erst mit der Offenlegung und Integration ins DCC-Regelwerk wurde es "auf den Weg gebracht".

Hallo,

@Erich:
[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]

Zitat

---

Wie meinst du das mit Digital als besseres Analog mit Hardwarecodierung?

---

Damit meine ich, wenn Bremsbausteine - oder wie man das immer nennen mag, jedenfalls Elemente, die eine Lok zum Bremsen und Anhalten bringen - an festen Punkten in die Anlage verbaut werden.
[/quote]
Ah, alles klar. Das kenne ich natürlich nicht, da ich ja mit C-Digital fahre. Mir war das mit den Bremsbausteinen von den anderen Digitalsystemen schon bekannt, war auch mit ein Grund, wesshalb ich damals bei C-Digital gelandet bin.


[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
Das ist vom Prinzip her nichts anderes als was wir früher (tm) auch analog gemacht haben, mit Halteabschnitten und Stromlosschaltungen - die ganz Gewitzten sogar schon mit temperaturabhängigen Widerständen, die ein langsames Abbremsen halbwegs ermöglichten.
[/quote]
Kann sein, dass ich hier wieder zu wenig von DCC oder mfx weiß, aber ich finde doch, dass es da noch einen Unterschied gibt. Digital bleibt eine Lok im Halt in vollem Funktionsumfang ansprechbar und kann grundsätzlich in Gegenrichtung das Halt durchfahren und rückwärts herausfahren. Analog war das doch nicht möglich, - höchstens teilweise und dann mit deutlichem Schaltungsaufwand, oder?



[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
Das im Gegensatz zur zentral überwachten und gesteuerten Anlage, wo bei exakt derselben Konfiguration (Fahrgeschwindigkeit, freie Gleise, Signalstellung) der eine Zug zum halten kommt (Personenzug) und der andere durchfährt (Güterzug) oder der Eilzug mal hält und mal nicht, je nach Fahrplan. Das kann mit vertretbarem Aufwand nur durch Softwaresteuerung geleistet werden.[/quote]
Gut hier kann ich auch nur wieder mit meiner Sicht von "außen" etwas sagen. Mir ist nicht ganz klar, wo bei DCC genau der Unterschied zwischen einer zentral überwachten und gesteuerten Anlage zu einer mit sochen Brems- und Rückmeldemodulen sein soll? Ist da nicht dann in beiden Fällen exakt das gleiche möglich?
Ist vielleicht wieder eine blöde Frage ... ? - Ich kenne das eben so nicht, weil das in meinem System z.B. auch keinen Unterschied macht. Da kann ich das was du verlangst auch ganz simpel (2 Einstellungen) ohne PC.


[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
Interaktion zwischen Anlagenbauteilen und Rollmaterial ist dazu aber nicht in der Lage - allein schon, weil dazu zu viele Informationen auch in der Lok transportiert werden müssten, die der Lokführer in 1:1 zwar in seiner Tasche mitbringen kann, nicht aber der Decoder in 1:87 oder gar 1:160.
[/quote]
Wieso denn? Eine Lok kann doch ihre Adresse in einem Abschnitt zurück melden und eben auf diese Adresse wird dann in irgendeiner Weise reagiert. Wenn man möchte, dass diese Lokadresse in diesem Abschnitt halten soll, dann stellt man das ein und es wird auch dann nur diese halten - alle anderen Adressen reagieren darauf nicht. Dazu muss in der Lok garnichts zusätzliches gemacht werde, oder? Der Dekoder macht halt was er sonst auch macht und meldet seine Adresse zurück. Ich verstehe hier einfach nicht was du meinst....?


[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]

Zitat

---

Sehe ich ganz genauso, - mit Selbstabsicherung des eigenen Blocks.

---

Die "Selbstabsicherung" wird aber nicht durch den Zug vorgenommen, sondern durch an der Strecke montierte Elemente. Auch da ist der Lokführer nur Befehlsempfänger.
[/quote]
Naja, das stimmt schon und das habe ich auch so gemeint. Aber für die Absicherung ist doch auch ein Zug o.ä. nötig. Der Zug löst einen Besetzmelder oder durch Magnet einen Reedkontakt aus und damit kann wird dann der eigene Abschnitt abgesichert. -> z.B. Halt im vorigen Abschnitt für alle Züge.



[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]

Zitat

---

Allerdings möchte ich nicht in ALLEN Punkten ein Modell der großen Bahn .

---

Jeder wie er mag. Aber, vorsichtig ausgedrückt, ist es heutzutage nicht einfach zu vermitteln, dass man ein existierendes und funktionierendes System, das noch dazu halbwegs realistisch die große Bahn abbildet, strikt ablehnt und die Entwicklung und Einführung eines neuen Systems einfordert, das gerade "unrealistisch" ist.
[/quote]
Hier weiß ich jetzt auch wieder nicht ganz was du mit unrealistisch meinst? Meinst du das C-Digitalsystem und was genau sticht dir da ins Auge?
Ich hatte mit meiner Aussage eigentlich nur einen kleinen Scherz gemacht, weil ich damit sagen wollte, dass ich z.B. nicht die ganzen Probleme, die die Bahn in Echt hat, auch im Modell haben möchte.


[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
Und auf die Gefahr hin, zu wiederholen, was schon andere gesagt haben: ich habe den Eindruck, du verurteilst hier Systeme, die du nur sehr unzureichend kennst, auf der Basis von Informationen, die du da und dort gefunden hast und von denen du mangels Kenntnissen und Erfahrung nicht sagen kannst, inwieweit sie zutreffen, ob allgemein oder nur in bestimmten Fällen oder vielleicht auch nur Frucht einer Fehleinschätzung sind - und was davon dem System zuzurechnen ist und was den Herstellern, die sich möglicherweise nicht an gewisse Regeln gehalten haben oder auch sich im Jahre 2001 noch nicht an erst 2006 erstellte Regeln halten konnten (willkürlich erdachte Zahlen; ich hatte jetzt keine Zeit und Lust, die richtigen Zahlen herauszusuchen, und es kommt eh aufs Gleiche heraus).
[/quote]
Das stimmt wohl so. Ich hätte nicht gedacht, dass ich da so vieles falsch verstanden habe und mich so verrannt habe. Aber gut, so ist es anscheinend nunmal...


[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
Dazu kommt die Vermengung von DCC und mfx und MM einerseits, die vor allem dazu gedacht sind, Aufträge von der Zentrale zur Lok bzw. dem Zubehördecoder zu bringen, und diversen Meldebus-Systemen, die umgekehrt dazu dienen, Informationen von der Anlage zur Zentrale bzw. auch zum verbundenen Rechner zu bringen.[/quote]
Wie das zustande kommt ist leicht erklärt:
Ich hatte einige Probleme in der Art der physikalischen Übertragung dieser Systeme gesehen. Diese ist da zwar nicht identisch, aber sehr ähnlich (sonst wäre Multiprotokoll auch garnicht möglich). Alle arbeiten mit einer aus Rechteckimpulsen bestehenden Wechselspannung zwischen +-12 bis 22 Volt, wenn ich mich hier nicht auch getäuscht habe?
Die Melde-Systeme müssen also in jedem System mit dieser, am Gleis ligender, Signalform klar kommen. - Vorausgesetzt es wird auch über das Gleis zurück gesendet.
So war meine Denklogik....



[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
Mein Programm funktioniert sehr gut mit binären Rückmeldern - also solchen, die nur "frei" oder "belegt" melden. Mehr Info bringt nicht mehr Nutzen, sondern nur höhere Kosten, warum also sollte ich mehr wollen?
[/quote]
Also mir fällt da gleich ein Grund ein (es gibt bestimmt noch weitere?).
Wenn ich nur auf besetzt ja/nein prüfe, weiß ich, respektive die PC-Software, nie wirklich welcher Zug oder Lok sich wo befindet. Wenn man eine Lok auf deiner Anlage, aus welchem Grund auch immer, einmal vom Gleis nimmt, und mal eben durch eine andere ersetzt weiß es deine Software doch nicht, oder?


[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
DCC wird, von Haus aus, über eine Reihe von Kontrollschaltern eingestellt, die man CV nennt. Mfx funktioniert grundsätzlich mit einer Bedienoberfläche, die als Interface zwischen den Kontrollschaltern und dem Anwender liegt - für DCC erledigen das, wenn man will, Programme wie JMRI oder auch die Decoderprogrammier-Programme der verschiedenen Hersteller.[/quote]
Den Unterschied, den du hier beschreibst sehe ich nicht? Sowohl bei mfx als auch bei DCC Dekodern gibt es doch Konfigurationsvariablen (CVs), die man entweder direkt oder über eine höhere Softwareebene konfiguriert. :


[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
Da ich es schon nervig finde, einem Fahrradtacho den richtigen Raddurchmesser einzugeben, kannst du dir vorstellen, wo meine Präferenz liegt. Und doch "kann" ich beides.
Mehrere Hersteller haben inzwischen - mit mehr oder weniger Erfolg - Routinen in ihre Decoder eingebaut, die dazu dienen (sollen), den Decoder genau auf den Motor abzustimmen. Protokollunabhängig.
[/quote]
Ja, das stimmt, das sehe ich genauso. Das schätze ich sehr an meinen C-Digitaldekodern, dass sich diese sehr anwenderfreundlich konfigurieren lassen, v.a. auch die Motorregelung. (der Dekoder kommt insgesammt auch mit nur 62 Einstellungsparametern aus). Das sah früher noch anders aus...

[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
Für mich gibts da keinen "Sieger". Aber auch zum derzeitigen Zeitpunkt keinen Bedarf für große Neuerungen.[/quote]
Das habe ich mittlerweile auch verstanden.


Grüße,
Marius

Guten Abend Heinz,

Zitat

---

Zitat

---

Mein Thema war einzig und alleine die Problematiken, die, so von mir angenommen, durch die Übertragungstechnik der Digitalsysteme kommen und die Frage, warum man immer noch daran festhält.

---

Dazu hast du dich aber sehr weit aus dem Fenster gelehnt. und hast dann wohl ein bisschen viel Probleme angenommen, die theoretisch ev. gar vorhanden sind, praktisch aber keine Auswirkungen zeigen und negiert werden können.

---

JA, das habe ich mittlerweile auch schon feststellen müssen

Zitat

---

Weshalb man an den bekannten Systemen festhält?
Ganz einfach: Weil es keinen Markt gibt für neue revolutionäre Systeme.
Die Digitalsysteme sind historisch gewachsen und waren zum Zeitpunkt der Hochblühte der Modellbahn vermutlich nicht mehr gerade revolutionär, aber zu der Zeit sicher noch Zeitgemäss.
Selbst neue Systeme wie z.B. ALAIN kommen nicht an den bekannten Digitalsystemen vorbei. Im Gegenteil, die bringt neben einem anderen Hardwareaufbau diesbezüglich auch nichts neues.
Die Probleme eines neuen Systems sind:
Es muss kompatibel sein zu bestehenden Systemen, sonst kommt es nie über den Randgruppenstatus oder Individualistenstatus hinaus (Siehe C-Digital, dem durchaus eine gute Idee zugrunde liegt) Dazu darf es bei gleichbleibender Funktionalität nicht teurer sein und Wow-Funktionalitäten die mit den bestehenden Systemen nicht abgedeckt werden sind auch sehr schwierig auszumachen.

---

Alles klar. Ich bin auch der Meinung, dass bei einer Neuerung die Kompatibilität gewahrt sein muss. Was immer sein darf, ist z.B. dass nicht immer alle neuen Funktionen mit alter Hardware nutzbar sind. Es darf aber keine funktionalen Probleme geben.
Bei dem C-Digital kann ich z.B. einen Uraltdekoder von 1998 immer noch voll und ohne jegliche Probleme mit der neuen Hardware (integrierte Rückmeldung) nutzen und umgekehrt kann ich die letzten Dekoder auch mit der Hardware von vor 20Jahren nutzen (die Rückmeldefunktoin ist hier dann halt ohne Funktion).

Martin (Entwickler C-Digital) hat mir mal gesagt, dass er sich es auch garnicht leisten könnte, bei einer Neuerung irgendwelche Inkompatibilitäten aufkommen zu lassen, weil er ja dadurch nur noch weniger Kunden hätte. Das könne ein "großes" Unternehmen deutlich leichter. Da lässt man dann hier und da was sterben...

Grüße,
Marius

Hallo Marius

Zitat

---

Digital bleibt eine Lok im Halt in vollem Funktionsumfang ansprechbar und kann grundsätzlich in Gegenrichtung das Halt durchfahren und rückwärts herausfahren. Analog war das doch nicht möglich, - höchstens teilweise und dann mit deutlichem Schaltungsaufwand, oder?

---

Der Knackpunkt ist, dass das Bremsen mit Dioden am Gleis ein klarer Bruch mit dem Gedanken ist, der hinter einem Digitalsystem steht. Bei Digital soll eigentlich einzig und allein die Zentrale über dei Befehle die Decoder steuern. Es ist nicht vorgesehen, dass irgendwelche Einrichtungen am Gleis die Loks beeinflussen.

Zitat

---

Mir ist nicht ganz klar, wo bei DCC genau der Unterschied zwischen einer zentral überwachten und gesteuerten Anlage zu einer mit sochen Brems- und Rückmeldemodulen sein soll? Ist da nicht dann in beiden Fällen exakt das gleiche möglich?

---

Genau hier liegt das oben beschriebene Problem. Da für die Zentrale die Beeinflussung der Lok außen vor bleibt, bekommt auch die Steuerung nichts mit. In jedem Fall ist ABC eine "dumme" Technik. Jeder Decoder, der in einen Abschnitt mit akivem ABC fährt hält an, sofer er ABC kennt und es angeschaltet ist. Zumindest wenn man Glück hat, übermäßig zuverlässig ist die Technik nicht.

Mit einer PC-Steuerung kannst du dagegen sehr viel mehr. Die Decoder müssen nix Spezielles können und da es über die DCC-Befehle läuft, ist es ebenso zuverlässig wie das Drehen am Handregler. Wie die Züge reagieren sollen kannst du beliebig einstellen.

Viele Grüße
Carsten

Guten Abend Carsten,

Zitat von 1001-digital im Beitrag Mfx und DCC

---

Zitat

---

Das mag sein, aber ich sehe die Vorteile leider nicht? Kannst du mir welche nennen?

---

Ich bin kein Techniker, aber soweit ich weiß lässt sich das Gleissignal mit der Wechselspannung einfacher erzeugen. Es braucht praktisch nur eine H-Brücke. Das ist vergleichsweise Low-Tech. Du hast das Signal dann auch gleich auf beiden Gleis-Seiten anliegen. Ich vermute außerdem, dass noch ein Gedanke eine Rolle gespielt hat. Lenz hat bis heute eine Funktion drin, dass die Wechselspannung mit einer Gleichspannung überlagert werden kann. So kann eine analoge Lok mitfahren. Speziell bei neueren Loks sollte man sowas natürlich keinesfalls machen, aber damals dürfte das ein Verkaufsargument gewesen sein. Aber wie gesagt, das ist nur eine Vermutung.

---

Ok, hier reicht mein technischer Sachverstand nicht aus, um das zu beurteilen. Das mit der Überlagerung einer Gleichspannung, um analoge und digitale Loks gleichermaßen zu steuern, geht natürlich nur mit der gleichanteilfreien Rechteckwechselspannung, wie bei DCC. Wie du aber auch schreibst gibt es dafür wohl seit über 20 Jahren schon keinen Markt mehr. Fleischmann hat das mit FMZ doch auch so gemacht? Und wann wurde das eingestellt? Das war doch noch vor der Jahrtausendwende, oder?

Zitat von 1001-digital im Beitrag Mfx und DCC

---

Zitat

---

Aber gut, wenn es sich hier um Fehlkonstruktionen handelt, frage ich mich, warum ein Hersteller dann damit durchkommt?

---

Weil keiner im realen Einsatz die Auswirkungen spürt oder weil Railcom noch nicht übermäßig breit eingesetzt wird oder ...

Die Hersteller kommen mit allem möglichen Blödsinn durch, beispielsweise die Unart von Lenz, die Bits in den CVs nicht mit 0 - 7 zu zählen, sondern mit 1 - 8. Und das ist nur ein einziges von vielen Beispielen.

---

Ok. Also ich glaube ich würde mir das als Kunde nicht gefallen lassen, v.a. nicht wenn ich mir ansehe, was bei manchen Herstellern für ein Betrag pro Dekoder abgedrückt werden muss. Mit steigendem Preis sinkt hier meine Tolleranzschwelle

Zitat von 1001-digital im Beitrag Mfx und DCC

---

Zitat

---

Nehmen wir einen Anbieter wie Vodafone (+ ehemalig Kabeldeutschland). Die geben dir über eine Leitung, nämlich deinen Kabelanschluss, Fernsehen + Internet welches bidirektional ist und Telefon, auch bidirektional. Und das alles über eine Leitung, coaxial. Glaub mir, es ist keine Seltenheit, das bidirektionale Kommunikationssysteme über nur eine Leitung + Schirm (GND) aufgebaut werden.

---

Ja, aber da gibts wie gesagt doch sehr andere Grundvoraussetzungen. Ich will mich jetzt nicht an dem dritten Leiter festbeißen, das war eigentlich eher ein flapsiger Einwurf.

---

Alles klar. Wie genau das technisch geht, weiß ich ja auch nicht, ich sehe nur, dass es geht - und so groß scheint der Aufwand dafür nicht zu sein, wenn ich mir das bei C-Digital so anschaue.

Zitat von 1001-digital im Beitrag Mfx und DCC

---

Zitat

---

Ja. Das Stimmt. Eigentlich ist jeder Taschenrechner ein kleiner Computer. Genauso wie jeder Dekoder usw.. Eigentlich jede el. Baugruppe, wo ein Microcontroller drauf ist, oder?
Bei der Steuerung über einen PC entfällt die Hardware doch nicht, oder? Woher weiß das PC-Programm sonst, wo sich wann ein Zug befindet. Mindestens Gleisbesetzmelder braucht man doch.?
Warum sollte es da einen Unterschied bei der Komplexität geben?

---

In der "normalen" Form hast du nur "dumme" Komponenten, die von einer zentralen Stelle aus gesteuert werden. Willst du intelligente Bauteile miteinander vernetzen, steigt der Aufwand, denn jedes Modul muss die anderen kennen.

---

Wieso? Wie ist das gemeint? Reicht es nicht, wenn die Zentrale oder der PC einfach alle kennt? Da müssen die sich doch nicht auch noch alle untereinander kennen?

Zitat von 1001-digital im Beitrag Mfx und DCC

---

Wie soll es sonst wissen, welche Daten wohin gesendet werden müssen?

---

Zitat von 1001-digital im Beitrag Mfx und DCC

---

Du musst außerdem jedem Modul sagen, wo es sich befindet etc. pp. und dann Beziehungen zwischen den Modulen herstellen.

---

Zitat von 1001-digital im Beitrag Mfx und DCC

---

Dann willst du ja noch den Bus entlasten, also Nachrichten möglichst effizient zwischen den Geräten austauschen.

---

Zitat von 1001-digital im Beitrag Mfx und DCC

---

Man könnte auch zusammengefasst sagen: Hardware, die mehr kann, muss komplexer sein. Ich sehe schlicht und einfach nicht, was dieser Aufwand bringen soll.

---

Zitat von 1001-digital im Beitrag Mfx und DCC

---

Bei der Steuerung über den PC hast du die gesamte "Intelligenz" gebündelt an einer Stelle. Die Rückmelder, Decoder etc. können dadurch einfacher und somit billiger gebaut werden.

---

Zitat von 1001-digital im Beitrag Mfx und DCC

---

Und wenn mal ein Gerät kaputt geht, ersetzt du es, stellst die gleiche Adresse ein und es sollte alles wieder laufen.

---

Hallo,

Zitat

---

Der Knackpunkt ist, dass das Bremsen mit Dioden am Gleis ein klarer Bruch mit dem Gedanken ist, der hinter einem Digitalsystem steht. Bei Digital soll eigentlich einzig und allein die Zentrale über dei Befehle die Decoder steuern. Es ist nicht vorgesehen, dass irgendwelche Einrichtungen am Gleis die Loks beeinflussen.

---

Sehen das alle so? Widerspricht das Bremsen über Dioden (ABC) oder anderen Bremsmodulen einem digitalen Konzept? Entsteht hier ein Bruch mit dem Grundgedanken eines Digitalsystems?



Wie ist das

Zitat

---

Bei Digital soll eigentlich einzig und allein die Zentrale über dei Befehle die Decoder steuern.

---

konkret gemeint? - Heißt das, dass alle Befehle ausschließlich im Protokoll vorhanden sein sollten?


Einrichtungen am Gleis wie Rückmelde- oder Gleisbesetztmodule sind ok, Bremsmodule aber nicht?

Zitat

---

Zitat

---

Mir ist nicht ganz klar, wo bei DCC genau der Unterschied zwischen einer zentral überwachten und gesteuerten Anlage zu einer mit sochen Brems- und Rückmeldemodulen sein soll? Ist da nicht dann in beiden Fällen exakt das gleiche möglich?

---

Genau hier liegt das oben beschriebene Problem. Da für die Zentrale die Beeinflussung der Lok außen vor bleibt, bekommt auch die Steuerung nichts mit. In jedem Fall ist ABC eine "dumme" Technik. Jeder Decoder, der in einen Abschnitt mit akivem ABC fährt hält an, sofer er ABC kennt und es angeschaltet ist. Zumindest wenn man Glück hat, übermäßig zuverlässig ist die Technik nicht.

---

Ok. Aber ist ABC wirklich nicht sonderlich zuverlässig? Sehen das die ABC Fahrer genauso und warum?

Zitat

---

Mit einer PC-Steuerung kannst du dagegen sehr viel mehr. Die Decoder müssen nix Spezielles können und da es über die DCC-Befehle läuft, ist es ebenso zuverlässig wie das Drehen am Handregler. Wie die Züge reagieren sollen kannst du beliebig einstellen.

---

Heißt das dann, dass bei DCC einiges nur mit PC überhaupt möglich wird? Sehen das andere DCC-Fahrer auch so?

Grüße,
Marius

Zitat

---

.
Heißt das dann, dass bei DCC einiges nur mit PC überhaupt möglich wird? Sehen das andere DCC-Fahrer auch so?

Grüße,
Marius

---

NEIN! mit der Computersteuerung gewinnt die digitale Modellbahn generell an Funktionalität, ganz egal welches digitale Format dahintersteckt!

Morgen an die Runde,

Also ich nutze ABC gerne und erfolgreich. Ich kann nicht verstehen, warum man das madig machen will.
Ich sehe es auch nicht ein, dass man nur dann ein richtiges Digitalsystem haben soll, wenn ein PC integriert ist.

Warum sollte eine digitale Anlage mit ABC weniger digital sein, als eine mit PC?

Zitat

---

Der Knackpunkt ist, dass das Bremsen mit Dioden am Gleis ein klarer Bruch mit dem Gedanken ist, der hinter einem Digitalsystem steht.

---

Was soll das denn für ein Gedanke sein?

Zitat

---

Sehen das alle so? Widerspricht das Bremsen über Dioden (ABC) oder anderen Bremsmodulen einem digitalen Konzept? Entsteht hier ein Bruch mit dem Grundgedanken eines Digitalsystems?

---

Nein. Wie gesagt, was sollte dieser Grundgedanke sein?

Zitat

---

Zitat

---

Mit einer PC-Steuerung kannst du dagegen sehr viel mehr. Die Decoder müssen nix Spezielles können und da es über die DCC-Befehle läuft, ist es ebenso zuverlässig wie das Drehen am Handregler. Wie die Züge reagieren sollen kannst du beliebig einstellen.

---

Heißt das dann, dass bei DCC einiges nur mit PC überhaupt möglich wird? Sehen das andere DCC-Fahrer auch so?

---

Das sehe ich nicht so. Das stimmt evtl. ab einer bestimmten Anlagengröße. Aber zwingend würde ich das nicht behaupten.

Freundliche Grüße,
Stephan

Morgen,

Zitat

---

Sehen das alle so? Widerspricht das Bremsen über Dioden (ABC) oder anderen Bremsmodulen einem digitalen Konzept? Entsteht hier ein Bruch mit dem Grundgedanken eines Digitalsystems?

---

Beim digitalen Konzept ist es die Frage, was man darunter versteht.

Ich selbst nutze auch ABC und für mich führt im DCC-Segment nichts daran vorbei, wenn man keinen PC zur Anlagensteuerung verwendet. Nur ABC ermöglicht die volle digitale Funktionspalette auch im Halteabschnitt. Freie Fahrt in Gegenrichtung und rückwärts herausfahren, alle Funktionen sind im Abschnitt ansteuerbar, auch PoM geht ohne Probleme.

Einen PC würde ich nur als Bereicherung sehen, nicht aber als zwingend notwendig für ein Digitalsystem.

Hallo,

Na, da geht es ja schon wieder rund. Ich hoffe ich bin mit meinen Fragen nicht wieder übers Ziel hinausgeschossen!? Ich habe ja nur Fragen auf Carstens Aussagen hin gestellt.


[quote="Martin Lutz" post_id=1819492 time=1523079680 user_id=124]

Zitat

---

.
Heißt das dann, dass bei DCC einiges nur mit PC überhaupt möglich wird? Sehen das andere DCC-Fahrer auch so?

Grüße,
Marius

---

NEIN! mit der Computersteuerung gewinnt die digitale Modellbahn generell an Funktionalität, ganz egal welches digitale Format dahintersteckt!
[/quote]Das verstehe ich jetzt garnicht. Du sagst nein und fügst im selben Atemzug hinzu, dass die digitale Modellbahn durch Computersteuerung an Funktionalität gewinnt. Ergo gibt es diese Funktionalität doch nur mit Computersteuerung, oder wie?
Und ganz nebenbei, was genau ist eigentlich mit Computersteuerung gemeint? -> Nur Lösungen mit Programmen wie TrainContorller, Rocrail, Softlok und wie sie alle heißen, oder auch Lösungen mit Ecos, CS2/3 usw. usf.?

Zitat

---

Nein. Wie gesagt, was sollte dieser Grundgedanke sein?

---

Das weiß ich leider auch nicht so richtig. Darum habe ich ja auch Carsten gefragt, was er damit meint. Oder was eben auch gerne andere da meinen?

Zitat

---

Ich sehe es auch nicht ein, dass man nur dann ein richtiges Digitalsystem haben soll, wenn ein PC integriert ist.

---

Also ich denke so; ein Digitalsystem ist ein System, wo die Fahr- und andere Befehle auf digitalem Weg übertragen werden. Ob man es zusätzlich dann mit einem PC erweitert, ist jedem selbst überlassen.
Digital bleibt das System so oder so.

Zitat

---

Einen PC würde ich nur als Bereicherung sehen, nicht aber als zwingend notwendig für ein Digitalsystem.

---

Sehe ich auch so.

Zitat

---

Ich selbst nutze auch ABC und für mich führt im DCC-Segment nichts daran vorbei, wenn man keinen PC zur Anlagensteuerung verwendet. Nur ABC ermöglicht die volle digitale Funktionspalette auch im Halteabschnitt. Freie Fahrt in Gegenrichtung und rückwärts herausfahren, alle Funktionen sind im Abschnitt ansteuerbar, auch PoM geht ohne Probleme.

---

Das hieße aber doch schon wieder, dass man entweder ABC oder eine PC-Steuerung braucht, damit das alles geht.? So hast du das zumindest geschrieben.

Grüße,
Marius

Zitat

---

Also ich nutze ABC gerne und erfolgreich. Ich kann nicht verstehen, warum man das madig machen will.

---

Es bleibt dir doch unbenommen das zu nutzen. Dennoch hat das System mehrere Schwächen, die ich auch schon öfter live erlebt habe. ABC funktioniert, indem das Gleissignal asymmetrisch gemacht wird, also die Spannung verändert wird. Neben dem unschönen Effekt, dass die Fahrzeuge beim Einfahren in einen ABC-Block ruckartig langsamer werden können(falls der Decoder zu wenig Regelreserve hat) gibt es das Problem, dass so eine Asymmetrie auch anders entstehen kann. Bei Fahrzeugen mit Glühlampen, deren Pluspol an einer Gleisseite hängt, kommt es z.B. bereits dazu und selbst manche Zentralen (z.B. Intellibox) haben ein asymmetrisches Gleissignal. Im Ergebnis kommt es vor, dass manche Fahrzeuge schlicht und einfach nicht bremsen, andere halten zwar, fahren dann aber immer wieder kurz an und kriechen so nach einer Weile aus dem ABC-Block heraus.

Die Unterstützung von ABC in den Decodern muss außerdem noch gegeben sein. Leider ist die viel zu oft nur rudimentär, vielen Decodern fehlt z.B. die Möglichkeit, einen konstanten Bremsweg unabhängig von CV 3 / 4 einzustellen.

Zitat

---

Ich sehe es auch nicht ein, dass man nur dann ein richtiges Digitalsystem haben soll, wenn ein PC integriert ist.
Warum sollte eine digitale Anlage mit ABC weniger digital sein, als eine mit PC?

---

Wo steht denn das geschrieben? Hat das irgendjemand behauptet?

Zitat

---

Nein. Wie gesagt, was sollte dieser Grundgedanke sein?

---

Wie wärs mit weiterlesen? Das hatte ich direkt danach ausgeführt.

Viele Grüße
Carsten

Hallo Marius,

Zitat von Gast im Beitrag Mfx und DCC

---

Hallo,

@Erich:
[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]

Zitat von Gast im Beitrag Mfx und DCC

---

Wie meinst du das mit Digital als besseres Analog mit Hardwarecodierung?

---

Damit meine ich, wenn Bremsbausteine - oder wie man das immer nennen mag, jedenfalls Elemente, die eine Lok zum Bremsen und Anhalten bringen - an festen Punkten in die Anlage verbaut werden.

---

Zitat

---

[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
Das ist vom Prinzip her nichts anderes als was wir früher (tm) auch analog gemacht haben, mit Halteabschnitten und Stromlosschaltungen - die ganz Gewitzten sogar schon mit temperaturabhängigen Widerständen, die ein langsames Abbremsen halbwegs ermöglichten.

---

Kann sein, dass ich hier wieder zu wenig von DCC oder mfx weiß, aber ich finde doch, dass es da noch einen Unterschied gibt. Digital bleibt eine Lok im Halt in vollem Funktionsumfang ansprechbar und kann grundsätzlich in Gegenrichtung das Halt durchfahren und rückwärts herausfahren. Analog war das doch nicht möglich, - höchstens teilweise und dann mit deutlichem Schaltungsaufwand, oder?
[/quote]
Hier muss man wohl zwischen den Systemen unterscheiden. Im DC-Bereich - und damit meine ich nicht Zweileiter, sondern Gleichstrom, wie der Begriff sagt! - war es schon immer möglich, einen Haltbereich mit einer Diode zu überbrücken, um "rückwärts wieder herauszufahren" (etwa bei einer Schutzzone vor einem Prellbock) oder das Signal nur in der richtigen Richtung zugbeeinflussend wirksam zu machen. Mit Wechselstrom dagegen - nun ja, sehr schwierig.
Und andere Funktionen als "fahren und bei der Fahrt Licht zeigen" hatten die Loks ja damals nicht.

Zitat

---

[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
Das im Gegensatz zur zentral überwachten und gesteuerten Anlage, wo bei exakt derselben Konfiguration (Fahrgeschwindigkeit, freie Gleise, Signalstellung) der eine Zug zum halten kommt (Personenzug) und der andere durchfährt (Güterzug) oder der Eilzug mal hält und mal nicht, je nach Fahrplan. Das kann mit vertretbarem Aufwand nur durch Softwaresteuerung geleistet werden.

---

Gut hier kann ich auch nur wieder mit meiner Sicht von "außen" etwas sagen. Mir ist nicht ganz klar, wo bei DCC genau der Unterschied zwischen einer zentral überwachten und gesteuerten Anlage zu einer mit sochen Brems- und Rückmeldemodulen sein soll? Ist da nicht dann in beiden Fällen exakt das gleiche möglich?
Ist vielleicht wieder eine blöde Frage ... ? - Ich kenne das eben so nicht, weil das in meinem System z.B. auch keinen Unterschied macht. Da kann ich das was du verlangst auch ganz simpel (2 Einstellungen) ohne PC.
[/quote]

Dazu hat Carsten schon was geschrieben:

Zitat

---

Bei Digital soll eigentlich einzig und allein die Zentrale über dei Befehle die Decoder steuern. Es ist nicht vorgesehen, dass irgendwelche Einrichtungen am Gleis die Loks beeinflussen.

---

Um mal wieder einen meiner allseits beliebten Vergleiche heranzuziehen:
Ein Bremsmodul, oder jede andere Einrichtung, die in der Anlage verbaut ist und dem herannahenden Zug eine Aktion abverlangt, ist wie ein Reflex. Der funktioniert ohne Mitwirkung des Gehirns - und immer gleich.
Die Steuerung über die Zentrale (und den Menschen, der sie bedient, oder den Computer, der sie unterstützt...) dagegen bezieht das Gehirn mit ein. Die Intelligenz. Und damit kann die Reaktion intelligent geschehen.

Analog gedacht ist: wenn irgendeine Lok an der Stelle x ist, dann muss sie dies oder das tun. Digital gedacht ist: wenn die Zentrale der Lok etwas aufträgt, dann tut sie das, egal wo sie sich gerade befindet. Analog gedacht ist: ich steuere die Anlage, und die Anlage steuert das Triebfahrzeug. Digital gedacht ist: ich (und nicht die Anlage!) steuere das Triebfahrzeug.

Zitat

---

[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
Interaktion zwischen Anlagenbauteilen und Rollmaterial ist dazu aber nicht in der Lage - allein schon, weil dazu zu viele Informationen auch in der Lok transportiert werden müssten, die der Lokführer in 1:1 zwar in seiner Tasche mitbringen kann, nicht aber der Decoder in 1:87 oder gar 1:160.

---

Wieso denn? Eine Lok kann doch ihre Adresse in einem Abschnitt zurück melden und eben auf diese Adresse wird dann in irgendeiner Weise reagiert. Wenn man möchte, dass diese Lokadresse in diesem Abschnitt halten soll, dann stellt man das ein und es wird auch dann nur diese halten - alle anderen Adressen reagieren darauf nicht. Dazu muss in der Lok garnichts zusätzliches gemacht werde, oder? Der Dekoder macht halt was er sonst auch macht und meldet seine Adresse zurück. Ich verstehe hier einfach nicht was du meinst....?
[/quote]

Und genau das ist analoges Denken. Das konnte man übrigens vor 30 Jahren auch schon, mit Strichcodeleser etc., und dann klickten die relais je nach gelesener Zugnummer...

Zitat

---

[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]

Zitat von Gast im Beitrag Mfx und DCC

---

Sehe ich ganz genauso, - mit Selbstabsicherung des eigenen Blocks.

---

Die "Selbstabsicherung" wird aber nicht durch den Zug vorgenommen, sondern durch an der Strecke montierte Elemente. Auch da ist der Lokführer nur Befehlsempfänger.

---

Naja, das stimmt schon und das habe ich auch so gemeint. Aber für die Absicherung ist doch auch ein Zug o.ä. nötig. Der Zug löst einen Besetzmelder oder durch Magnet einen Reedkontakt aus und damit kann wird dann der eigene Abschnitt abgesichert. -> z.B. Halt im vorigen Abschnitt für alle Züge.
[/quote]

Stimmt - aber ohne Zutun des Zuges oder seines Lokführers. Und - auch das ist analog gedacht. Wie das gesamte Haupt- und Vorsignal-System. Digitales Denken kannst du beim Vorbild etwa in der LZB-Führung erkennen (ECTS2 kenne ich nicht oder nicht genug, um dazu was sagen zu können), wo eben nicht mehr geographisch und statisch festgelegte Punkte und Zonen die Sicherheitsbereiche des Zuges festlegen, sondern der Zug quasi eine Sicherungszone hinter sich her schleppt und der folgende Zug durch dynamische Geschwindigkeitsgrenzen auf Abstand gehalten wird. Ungefähr so wie wir das machen, wenn zwei Loks auf einem Kreis hintereinander herfahren und wir die Geschwindigkeit nachstellen, damit nicht die eine auf die andere auffährt.

Zitat

---

[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]

Zitat von Gast im Beitrag Mfx und DCC

---

Allerdings möchte ich nicht in ALLEN Punkten ein Modell der großen Bahn .

---

Jeder wie er mag. Aber, vorsichtig ausgedrückt, ist es heutzutage nicht einfach zu vermitteln, dass man ein existierendes und funktionierendes System, das noch dazu halbwegs realistisch die große Bahn abbildet, strikt ablehnt und die Entwicklung und Einführung eines neuen Systems einfordert, das gerade "unrealistisch" ist.

---

Hier weiß ich jetzt auch wieder nicht ganz was du mit unrealistisch meinst? Meinst du das C-Digitalsystem und was genau sticht dir da ins Auge?
Ich hatte mit meiner Aussage eigentlich nur einen kleinen Scherz gemacht, weil ich damit sagen wollte, dass ich z.B. nicht die ganzen Probleme, die die Bahn in Echt hat, auch im Modell haben möchte.
[/quote]

Dann habe ich deinen Satz falsch interpretiert; ich hatte dich so verstanden, dass du ein Steuerungsmodell favorisierst, das in bestimmten Punkten nicht den Grundsätzen der "großen" Bahn entspricht. Zum Beispiel, indem Lokführer (=Decoder) und ortsfeste Einrichtungen bestimmte Aktionen untereinander "aushandeln".

Zitat

---

[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
Und auf die Gefahr hin, zu wiederholen, was schon andere gesagt haben: ich habe den Eindruck, du verurteilst hier Systeme, die du nur sehr unzureichend kennst, auf der Basis von Informationen, die du da und dort gefunden hast und von denen du mangels Kenntnissen und Erfahrung nicht sagen kannst, inwieweit sie zutreffen, ob allgemein oder nur in bestimmten Fällen oder vielleicht auch nur Frucht einer Fehleinschätzung sind - und was davon dem System zuzurechnen ist und was den Herstellern, die sich möglicherweise nicht an gewisse Regeln gehalten haben oder auch sich im Jahre 2001 noch nicht an erst 2006 erstellte Regeln halten konnten (willkürlich erdachte Zahlen; ich hatte jetzt keine Zeit und Lust, die richtigen Zahlen herauszusuchen, und es kommt eh aufs Gleiche heraus).

---

Das stimmt wohl so. Ich hätte nicht gedacht, dass ich da so vieles falsch verstanden habe und mich so verrannt habe. Aber gut, so ist es anscheinend nunmal...
[/quote]
Auch bei den letzten Beiträgen hatte ich den Eindruck, du schreibst manchmal schneller als dein Schatten. Willst du bei mir als Sekretär anfangen?
Nee, ohne Scherz, man kann sich mal verrennen. Das passiert sogar den besten - schau mich an. Aber es ist eigentlich besser, erst noch mal zu lesen, bevor man nachfragt, oder auch zu Dingen, die im Internet irgendwo stehen, noch andere Seiten zu suchen, ob die das gleiche sagen (und nicht voneinander abschreiben - das gibts nämlich auch, und manchmal sogar wortgleich!), und ob andere was ganz anderes sagen.
Und nachfragen, ob man das richtig verstanden hat, wie man es verstanden hat, kann gerade bei hitziger Diskussion mal Schärfe rausnehmen...

Zitat

---

Wie das zustande kommt ist leicht erklärt:
Ich hatte einige Probleme in der Art der physikalischen Übertragung dieser Systeme gesehen. Diese ist da zwar nicht identisch, aber sehr ähnlich (sonst wäre Multiprotokoll auch garnicht möglich). Alle arbeiten mit einer aus Rechteckimpulsen bestehenden Wechselspannung zwischen +-12 bis 22 Volt, wenn ich mich hier nicht auch getäuscht habe?
Die Melde-Systeme müssen also in jedem System mit dieser, am Gleis ligender, Signalform klar kommen. - Vorausgesetzt es wird auch über das Gleis zurück gesendet.
So war meine Denklogik....

---

Nur nützen die Rückmeldesysteme ja eben nicht das Gleis - von mfx-Anmeldung und (sehr lokal begrenzt funktionierender) Railcom-Meldung abgesehen.

Zitat

---

Also mir fällt da gleich ein Grund ein (es gibt bestimmt noch weitere?).
Wenn ich nur auf besetzt ja/nein prüfe, weiß ich, respektive die PC-Software, nie wirklich welcher Zug oder Lok sich wo befindet. Wenn man eine Lok auf deiner Anlage, aus welchem Grund auch immer, einmal vom Gleis nimmt, und mal eben durch eine andere ersetzt weiß es deine Software doch nicht, oder?


Den Unterschied, den du hier beschreibst sehe ich nicht? Sowohl bei mfx als auch bei DCC Dekodern gibt es doch Konfigurationsvariablen (CVs), die man entweder direkt oder über eine höhere Softwareebene konfiguriert. :

---

Zum System von mfx gehört eben von Anfang an dazu, CV (bei mfx heißen die eigentlich anders, aber das habe ich vergessen) nicht direkt zu konfigurieren, sondern über eine Bildschirmeingabe, die auch nicht "CV xxx" anzeigt, sondern beispielsweise "Höchstgeschwindigkeit" oder "Bremsverzögerung". Da kann ich dann auch eine Reihe von Häkchen setzen oder abwählen, statt eine CV mit vielen Einzeleinstellungen richtig errechnen zu müssen. CV-Rechner gibts für DCC, nicht für mfx - weil mfx grundsätzlich das Interface mitbringt.
Und einige DCC-Jünger erklären einem auch gern mal ungefragt, wie schön und wichtig es doch sei, CV direkt einstellen zu können und das auch zu tun... Nun ja, jedem Tierchen sein Pläsierchen.
[/quote]

Zitat

---

Heißt das dann, dass bei DCC einiges nur mit PC überhaupt möglich wird? Sehen das andere DCC-Fahrer auch so?

---

Das hat nichts mit DCC oder mfx oder welchem Protokoll auch immer zu tun. Eine PC-Steuerung kann viel mehr Dinge auf einmal machen als ein Mensch, der eine Zentrale betätigt. Ganz egal, ob das jetzt (wie beim Kollegen Bärtle, wenn ich mich recht erinnere, bei dem das aber nie richtig funktionierte, weil damit der Bus überfordert war) eine Batterie aus CS2 und angesteckten MS2 ist, oder eine Reihe von Handreglern oder auch Pultreglern a la 6021+c80f. Der Mensch hat zwei Augen, zwei Ohren, zwei Hände, der PC kann selbst über einen seriellen Bus wie USB wesentlich schneller Informationen erhalten und Befehle abgeben und dazwischen auch noch in Windeseile die Informationen auswerten, um die richtigen Befehle zu erteilen.
Und das gilt sogar für Steuerungen, deren Ausgabe zur Anlage analog funktioniert. (Was aber wegen des materiellen Aufwands für die analoge Steuerung keine Zukunft hat; digital ist es schlicht einfacher und billiger.)
Moderne High-End-Zentralen können in dieser Hinsicht einiges bieten, aber bisher noch nicht mit einem PC und dem entsprechenden Programm mithalten - dies vor allem, weil keine Zugverfolgung vorgesehen ist. (Man könnte sagen, die Zentralen denken analog. )
Umgekehrt gibt es Aufgaben, die kein Computer und keine Zentrale und keine Automatik so gut ausführen kann wie ein Mensch am Regler - obwohl die Margen immer geringer werden. Zum Beispiel punktgenaues Rangieren, stoßfreies Ankuppeln und solche Dinge.

Zitat

---

Einrichtungen am Gleis wie Rückmelde- oder Gleisbesetztmodule sind ok, Bremsmodule aber nicht?

---

Diese Module sind die "Augen und Ohren" der Zentrale, sie können zwar mittelbar eine Reaktion der Zentrale auslösen, aber sie beeinflussen nicht direkt das Verhalten des Zuges und geben ihm keine Befehle.

Hallo Carsten,

Zitat

---

Zitat

---

Also ich nutze ABC gerne und erfolgreich. Ich kann nicht verstehen, warum man das madig machen will.

---

Es bleibt dir doch unbenommen das zu nutzen. Dennoch hat das System mehrere Schwächen, die ich auch schon öfter live erlebt habe. ABC funktioniert, indem das Gleissignal asymmetrisch gemacht wird, also die Spannung verändert wird. Neben dem unschönen Effekt, dass die Fahrzeuge beim Einfahren in einen ABC-Block ruckartig langsamer werden können(falls der Decoder zu wenig Regelreserve hat) gibt es das Problem, dass so eine Asymmetrie auch anders entstehen kann. Bei Fahrzeugen mit Glühlampen, deren Pluspol an einer Gleisseite hängt, kommt es z.B. bereits dazu und selbst manche Zentralen (z.B. Intellibox) haben ein asymmetrisches Gleissignal. Im Ergebnis kommt es vor, dass manche Fahrzeuge schlicht und einfach nicht bremsen, andere halten zwar, fahren dann aber immer wieder kurz an und kriechen so nach einer Weile aus dem ABC-Block heraus.

Die Unterstützung von ABC in den Decodern muss außerdem noch gegeben sein. Leider ist die viel zu oft nur rudimentär, vielen Decodern fehlt z.B. die Möglichkeit, einen konstanten Bremsweg unabhängig von CV 3 / 4 einzustellen.

---

Ok. Du hast recht, dass es hier und da Probleme geben kann. So ist das aber überall.
ABC hat bestimmt auch ein paar Schwächen, aber auch viele Stärken wie Klaus auch geschrieben hat. Mir ist für DCC keine gleichwertige Alternative bekannt, dir?

Zitat

---

Zitat

---

Ich sehe es auch nicht ein, dass man nur dann ein richtiges Digitalsystem haben soll, wenn ein PC integriert ist.
Warum sollte eine digitale Anlage mit ABC weniger digital sein, als eine mit PC?

---

Wo steht denn das geschrieben? Hat das irgendjemand behauptet?

---

Für mich haben sich deine Aussagen so angehört, als ob du sagen willst, dass ABC dem Prinzip eines Digitalsystems widerspricht. Folglich wird, wenn ich deine Aussage richtig deute, aus einem Digitalsystem, durch die Verwendung von ABC, ein System mit keiner "echte" bzw. vollwertigen digitalen Lösung.
Wie soll man deine Aussage sonst verstehen?

Zitat

---

Zitat

---

Nein. Wie gesagt, was sollte dieser Grundgedanke sein?

---

Wie wärs mit weiterlesen? Das hatte ich direkt danach ausgeführt.

---

Dann erkläre doch bitte noch einmal genau, wie du das gemeint hast. Marius hat das offensichtilich auch nicht ganz verstanden, was du damit sagen willst.

Hallo Stephan

Zitat

---

Ok. Du hast recht, dass es hier und da Probleme geben kann. So ist das aber überall.
ABC hat bestimmt auch ein paar Schwächen, aber auch viele Stärken wie Klaus auch geschrieben hat. Mir ist für DCC keine gleichwertige Alternative bekannt, dir?

---

Ich persönlich habe die Schwächen leider zu oft als zu gravierend erlebt, als dass ich die Benutzung guten Gewissens empfehlen kann. Speziell bei der Fehlersuche sind weniger technikaffine Nutzer dann schnell überfordert. Ich persönlich empfehle bei Verwendung von ABC immer einen stromlosen Abschnitt nach dem Halteabschnitt einzuplanen, damit die Fahrzeuge auch sicher halten. Ist natürlich eine Platzfrage...

Wie gesagt, wer es nutzen will, soll das gern tun. Ich verstehe durchaus, warum manche das gern verwenden, immerhin ist es eine ziemlich simple und vor allem billige Methode. Um es "richtig" zu machen muss man den Aufwand, auch den finanziellen, schon deutlich erhöhen. Man sollte aber schon drauf aufmerksam machen, dass es ein bisschen mit Vorsicht zu genießen ist.

Zitat

---

Für mich haben sich deine Aussagen so angehört, als ob du sagen willst, dass ABC dem Prinzip eines Digitalsystems widerspricht. Folglich wird, wenn ich deine Aussage richtig deute, aus einem Digitalsystem, durch die Verwendung von ABC, ein System mit keiner "echte" bzw. vollwertigen digitalen Lösung.
Wie soll man deine Aussage sonst verstehen?

---

Es liegt mir fern irgendjemandem die "Digitalität" abzusprechen, nur weil er ABC einsetzt. Aber wie ich oben schon schrieb, sollen bei Digital die Loks allein von der Zentrale gesteuert werden, das Gleis dient nur als Medium zur Befehlsübermittlung und als Stromversorgung. Damit sollte die Anzeige auf dem Handregler auch immer den aktuellen Betriebszustand des Fahrzeugs widerspiegeln. ABC bricht mit diesem System, indem es die analoge Art des Steuerns in die Digitalwelt herüberholt. Eine Lok im ABC-Abschnitt ignoriert die Fahrbefehle der Zentrale, bestenfalls rückwärts kann man noch fahren.

Viele Grüße
Carsten

Hallo an die Runde,

Ich hoffe es hat niemand etwas dagegen, wenn ich mich hier ein bisschen einmische und antoworte, auch wenn ich nicht direkt gefragt war...

Zunächst noch einmal hierzu:

Zitat

---

Der Knackpunkt ist, dass das Bremsen mit Dioden am Gleis ein klarer Bruch mit dem Gedanken ist, der hinter einem Digitalsystem steht. Bei Digital soll eigentlich einzig und allein die Zentrale über dei Befehle die Decoder steuern. Es ist nicht vorgesehen, dass irgendwelche Einrichtungen am Gleis die Loks beeinflussen.

---

Ich denke, was Carsten hier sagen will ist, dass bei einem Digitalsystem eigentlich alle Befehle, die einen Dekoder steuern, digital erfolgen sollten. Alle Befehle sollten ausnahmslos über das jeweilige Protokoll von einer Zentrale o.ä. zum Dekoder gelangen. Also keine Beeinflussung eines Dekoders durch ein lokales, irgendwie geartetes Signal, wie z.B. Gleichspannung, asymmetriesche Spannung (ABC), etc..
Aus dieser Forderung folgt, dass das Halten, bspw. vor einem Signal, mittels ABC-Bremsstrecken (DCC) oder Bremsstrecken durch Gleichspannung (Märklin) nicht wirklich in die digitale Welt "passen". Man kann sie natürlich bedenkenlos verwenden, mache ich selber auch, nur widerspricht das eigentlich dem Grundgedanken von Digital. Es erinnert eher an eine analoge Halteautomatik.
Daraus folg im Fall von DCC (keine Ahnung wie das bei mfx ist) nunmal, dass man, sofern man eine "totale" Digitalsteuerung mit Automatismen wie Halt uvm. möchte, man immer einen PC mit entsprechender Software + irgendeine Art Rückmelder braucht. Das DCC-System alleine gibt das nicht her.

Zitat

---

ABC hat bestimmt auch ein paar Schwächen, aber auch viele Stärken wie Klaus auch geschrieben hat. Mir ist für DCC keine gleichwertige Alternative bekannt, dir?

---

Die einzige "Alternative", wenn man das in dem Fall überhaupt so bezeichnen kann, ist also eine PC-Steuerungssoftware mit Rückmeldern auf der Anlage.

Zitat

---

Das hieße aber doch schon wieder, dass man entweder ABC oder eine PC-Steuerung braucht, damit das alles geht.? So hast du das zumindest geschrieben.

---

Ganz genau, korrekt!

Zitat

---

Heißt das dann, dass bei DCC einiges nur mit PC überhaupt möglich wird?

---

JA, natürlich ist das so. Erst die PC-Steuerung kann Dinge ermöglichen, die sonst bei DCC nicht möglich sind. Um nur ein Beispiel zu nennen: Automatisches Halten, ohne dass dafür irgendwelche Bremsmodule o.ä. nötig wäre, die ja (wie oben schon besprochen) einem grundlegenden digitalen System widersprechen und eine Reaktion auf so ein Signal kann nicht lokspezifisch erfolgen.
Außerdem ergenben sich durch eine Software viel viel komplexere Betriebsmodi, was einige hier auch schon geschrieben haben.

Zitat

---

Und ganz nebenbei, was genau ist eigentlich mit Computersteuerung gemeint? -> Nur Lösungen mit Programmen wie TrainContorller, Rocrail, Softlok und wie sie alle heißen, oder auch Lösungen mit Ecos, CS2/3 usw. usf.?

---

Diese großen "Allround" Zentralen können vieles, aber nicht alles. Mit einem PC kann bis heute keine dieser Zentralen mithalten. Eine Computersteuerung mit den von dir genannten Softwares, sind deutlich leistungsfähiger und können Sachen, die eine CS2 oder Ecos nicht kann.

Zitat

---

Also ich denke so; ein Digitalsystem ist ein System, wo die Fahr- und andere Befehle auf digitalem Weg übertragen werden. Ob man es zusätzlich dann mit einem PC erweitert, ist jedem selbst überlassen.

---

Ja, da bist du durch dein C-Digital zu sehr "vorbelastet" . Ich stimmer dir voll zu. Das ist es, was Carsten ja im Prinzip auch gesagt hat.
Nur ist das:

Zitat

---

ein Digitalsystem ist ein System, wo die Fahr- und andere Befehle auf digitalem Weg übertragen werden

---

Im Fall von ABC-Bremsmodulen, oder anderen Bremsmodulen, eben gerade nicht der Fall. Das Halt kommt da nicht von der Zentrale, sondern wird durch ein Signal, welches analog von einem Modul erzeugt wird und nur für diesen Abschnitt gilt im Dekoder ausgelöst, sofern dieser eine Erkennung hierfür implementiert hat.
Hier liegen dann auch einige Problemquellen von ABC.
Siehe:

Zitat

---

Dennoch hat das System mehrere Schwächen, die ich auch schon öfter live erlebt habe. ABC funktioniert, indem das Gleissignal asymmetrisch gemacht wird, also die Spannung verändert wird. Neben dem unschönen Effekt, dass die Fahrzeuge beim Einfahren in einen ABC-Block ruckartig langsamer werden können(falls der Decoder zu wenig Regelreserve hat) gibt es das Problem, dass so eine Asymmetrie auch anders entstehen kann. Bei Fahrzeugen mit Glühlampen, deren Pluspol an einer Gleisseite hängt, kommt es z.B. bereits dazu und selbst manche Zentralen (z.B. Intellibox) haben ein asymmetrisches Gleissignal. Im Ergebnis kommt es vor, dass manche Fahrzeuge schlicht und einfach nicht bremsen, andere halten zwar, fahren dann aber immer wieder kurz an und kriechen so nach einer Weile aus dem ABC-Block heraus.

Die Unterstützung von ABC in den Decodern muss außerdem noch gegeben sein. Leider ist die viel zu oft nur rudimentär, vielen Decodern fehlt z.B. die Möglichkeit, einen konstanten Bremsweg unabhängig von CV 3 / 4 einzustellen.

---

Zitat

---

Zitat

---

Zitat

---

Mit einer PC-Steuerung kannst du dagegen sehr viel mehr. Die Decoder müssen nix Spezielles können und da es über die DCC-Befehle läuft, ist es ebenso zuverlässig wie das Drehen am Handregler. Wie die Züge reagieren sollen kannst du beliebig einstellen.

---

Heißt das dann, dass bei DCC einiges nur mit PC überhaupt möglich wird? Sehen das andere DCC-Fahrer auch so?

---

Das sehe ich nicht so. Das stimmt evtl. ab einer bestimmten Anlagengröße. Aber zwingend würde ich das nicht behaupten.

---

Warum sollte das nicht so sein? Dann sage mir doch, wie du oben genanntes (zum autom. Halt) ohne PC umsetzt?


[quote="Erich Müller" post_id=1819642 time=1523108932 user_id=26147]
Wie wird denn bei C-Digital einer Lok signalisiert, dass sie an einem bestimmten Punkt halten soll? Doch sicher nicht durch Erkennung des roten Signallichts?
[/quote]Ich habe mich mit diesem System etwas befasst und mich mit dem Entwickler hier ausgetauscht...
Bei C-Digital gibt es im Datenprotokoll 2Bit (also 4 Zustände = Werte); die sagen dem Decoder entweder 1= "Halt in Urzeigersinn", 2="Halt gegen Urzeigersinn", 3="freie Fahrt" und 0="Langsamfahrt" (für die Zuordnung keine Garantie ). Da dies bereits im Protokoll enthalten ist, wird sonst zunächst nichts weiteres benötigt.
Wollte man früher, altes C-Digital, irgendwelche Abhängigkeiten Schalten, musste man das über einfache Relais-Baugruppen erledigen mit Schalteingängen für Reedkontakte, Taster, Schalter oder Gleisbesetzt-Auslöser usw.. Das System ermöglichte dadurch eine beliebig komplexe Blockstellen-Logik ohne großen Aufwand.
Heute ist die Rückmeldung hinzugekommen, die so wie Railcom und mfx auch über das Gleis geht. Es werden also keine Rückmelde-Kontakte (z.B. Reedkontakte oder Strichcode-Leser) gebraucht. Allerdings wird die komplette Strecke in Abschnitte für die Rückmeldung aufgeteilt. Ein Rückmelder pro Abschnitt.
Nur so ergibt sich eine vollständige Zugverfolgung, die hier wirklich eindeutig geschieht, da u.a. auch die Adresse zurückgemeldet wird.
Soviel zu C-Digital... Marius wird das sicher bestätigen können denke ich.


Daraus folgt auch, dass Marius hier bei DCC einige Verständnisprobleme hat, weil er das so ja nicht kennt...
[quote="Erich Müller" post_id=1819642 time=1523108932 user_id=26147]
Um mal wieder einen meiner allseits beliebten Vergleiche heranzuziehen:
Ein Bremsmodul, oder jede andere Einrichtung, die in der Anlage verbaut ist und dem herannahenden Zug eine Aktion abverlangt, ist wie ein Reflex. Der funktioniert ohne Mitwirkung des Gehirns - und immer gleich.
Die Steuerung über die Zentrale (und den Menschen, der sie bedient, oder den Computer, der sie unterstützt...) dagegen bezieht das Gehirn mit ein. Die Intelligenz. Und damit kann die Reaktion intelligent geschehen.

Analog gedacht ist: wenn irgendeine Lok an der Stelle x ist, dann muss sie dies oder das tun. Digital gedacht ist: wenn die Zentrale der Lok etwas aufträgt, dann tut sie das, egal wo sie sich gerade befindet. Analog gedacht ist: ich steuere die Anlage, und die Anlage steuert das Triebfahrzeug. Digital gedacht ist: ich (und nicht die Anlage!) steuere das Triebfahrzeug.
[/quote]denn bei ihm gibt es keine Bremsmodule oder ähnliches. Die Steuerung erfolgt praktisch immer über die Zentrale. Welche Übertragungskette sich im Detail ergibt hängt davon ab, wie genau er steuert. z.B. PC->Zentrale->Gleis oder Tablett->Zentrale->Gleis oder Handregler->Zentrale->Gleis oder Zentrale->Gleis (wobei in der Zentrale etwa irgendein/e Automatismus/Logik eingestellt wurde).

[quote="Erich Müller" post_id=1819642 time=1523108932 user_id=26147]
[quote="Erich Müller" post_id=1819642 time=1523108932 user_id=26147]
Interaktion zwischen Anlagenbauteilen und Rollmaterial ist dazu aber nicht in der Lage - allein schon, weil dazu zu viele Informationen auch in der Lok transportiert werden müssten, die der Lokführer in 1:1 zwar in seiner Tasche mitbringen kann, nicht aber der Decoder in 1:87 oder gar 1:160. [/quote]

Zitat

---

Wieso denn? Eine Lok kann doch ihre Adresse in einem Abschnitt zurück melden und eben auf diese Adresse wird dann in irgendeiner Weise reagiert. Wenn man möchte, dass diese Lokadresse in diesem Abschnitt halten soll, dann stellt man das ein und es wird auch dann nur diese halten - alle anderen Adressen reagieren darauf nicht. Dazu muss in der Lok garnichts zusätzliches gemacht werde, oder? Der Dekoder macht halt was er sonst auch macht und meldet seine Adresse zurück. Ich verstehe hier einfach nicht was du meinst....?

---

Und genau das ist analoges Denken. Das konnte man übrigens vor 30 Jahren auch schon, mit Strichcodeleser etc., und dann klickten die relais je nach gelesener Zugnummer...
[/quote]Bei Marius, C-Digital, wird eine Adresse zurückgemeldet und die Zentrale oder PC oder was auch immer er zum Steuern nimmt, reagiert gezielt auf diese Lok mit entsprechenden Digitalbefehlen über das Protokoll. Das ist also gerade nicht analoges Denken. Ihr redet hier wohl aneinander vorbei, weil keiner das System des anderen richtig kennt


Dann noch etwas zum Mehraufwand im Dekoder. Im Fall von Marius System, muss der Dekoder natürlich selbstständig auf einen Halte-, Langsamfahrbefehl reagieren können. Also muss hier im Dekoder mehr "Intelligenz" sein (fahrstufenunabhängige Anhalteweglänge usw.). Aber das ist grundsätzlich zunächst einmal genauso wie beim großen Vorbild, weil der Dekoder ja im Prinzip der Lokführer ist und dieser in den meisten Fällen auch aktiv die Lok steuert (beschleunigt, bremst, auf ein Signal reagiert, ...). LZB setzt man bei der Bahn ja auch erst ab einer gewisse Geschwindigkeit ein, wenn ich mich nicht täusche.
Diesen Mehraufwand hat man hier also tatsächlich. Auf der anderen Seite spart man bei der Auslastung des Bus-Systems, egal ob für die Hin- oder Rückrichtung. Evtl gibt es noch andere Vorteile, da müsste ich noch einmal darüber Nachdenken.


Wenn ich mich irgendwo getäuscht haben sollte, berichtigt mich gerne und flammbiert mich nicht gleich.
Ich denke, dass hier nur so kontrovers diskutiert wird, weil man größten Teils aneinander vorbei redet. Ich hoffe ich habe für etwas Klarheit sorgen können.



edit: Habe eben erst Carstens letzten Post gelesen. Meine oben angenommene Vermutung scheint sich also bestätigt zu haben.

Zitat

---

Aber wie ich oben schon schrieb, sollen bei Digital die Loks allein von der Zentrale gesteuert werden, das Gleis dient nur als Medium zur Befehlsübermittlung und als Stromversorgung. Damit sollte die Anzeige auf dem Handregler auch immer den aktuellen Betriebszustand des Fahrzeugs widerspiegeln. ABC bricht mit diesem System, indem es die analoge Art des Steuerns in die Digitalwelt herüberholt. Eine Lok im ABC-Abschnitt ignoriert die Fahrbefehle der Zentrale, bestenfalls rückwärts kann man noch fahren.

---

Zitat

---

Hallo,

Na, da geht es ja schon wieder rund. Ich hoffe ich bin mit meinen Fragen nicht wieder übers Ziel hinausgeschossen!? Ich habe ja nur Fragen auf Carstens Aussagen hin gestellt.


[quote="Martin Lutz" post_id=1819492 time=1523079680 user_id=124]

Zitat

---

.
Heißt das dann, dass bei DCC einiges nur mit PC überhaupt möglich wird? Sehen das andere DCC-Fahrer auch so?

Grüße,
Marius

---

NEIN! mit der Computersteuerung gewinnt die digitale Modellbahn generell an Funktionalität, ganz egal welches digitale Format dahintersteckt!

---

Das verstehe ich jetzt garnicht. Du sagst nein und fügst im selben Atemzug hinzu, dass die digitale Modellbahn durch Computersteuerung an Funktionalität gewinnt. Ergo gibt es diese Funktionalität doch nur mit Computersteuerung, oder wie?
[/quote]Wenn du schreibst, dass bei DCC einiges nur mit PC möglich wird, dann sage ich Nein deshalb, weil es nicht nur für DCC so ist, sondern für ALLE Digitalsysteme.

Und ein Digitales Modellbahnsytem wird sicher nicht digitaler, wenn man mit Hilfe von einer PC Steuerung noch zusätzliche Funktionalitäten hinzufügt.

Digital ist Digital!

Wenn man eine Multiprotokoll-Zentrale hat und eine Computersteuerung ist es schon fast egal, ob das System eine Lok mit MM, mfx, DCC oder
Selectrix ansteuert.

Zitat

---

Hallo an die Runde,

Ich hoffe es hat niemand etwas dagegen, wenn ich mich hier ein bisschen einmische und antoworte, auch wenn ich nicht direkt gefragt war...

---

Hallo Klaus,

ich hab jedenfalls nichts dagegen - im Gegenteil. Du bringst Klarheit in die Sache, für mich zumindest.
Einiges zitiere ich hier nicht, weil es entweder sagt, was ich auch auszudrücken versucht habe, oder mich gar nicht betrifft.

Zitat

---

[quote="Erich Müller" post_id=1819642 time=1523108932 user_id=26147]
Wie wird denn bei C-Digital einer Lok signalisiert, dass sie an einem bestimmten Punkt halten soll? Doch sicher nicht durch Erkennung des roten Signallichts?

---

Ich habe mich mit diesem System etwas befasst und mich mit dem Entwickler hier ausgetauscht...
Bei C-Digital gibt es im Datenprotokoll 2Bit (also 4 Zustände = Werte); die sagen dem Decoder entweder 1= "Halt in Urzeigersinn", 2="Halt gegen Urzeigersinn", 3="freie Fahrt" und 0="Langsamfahrt" (für die Zuordnung keine Garantie ). Da dies bereits im Protokoll enthalten ist, wird sonst zunächst nichts weiteres benötigt.
Wollte man früher, altes C-Digital, irgendwelche Abhängigkeiten Schalten, musste man das über einfache Relais-Baugruppen erledigen mit Schalteingängen für Reedkontakte, Taster, Schalter oder Gleisbesetzt-Auslöser usw.. Das System ermöglichte dadurch eine beliebig komplexe Blockstellen-Logik ohne großen Aufwand.
Heute ist die Rückmeldung hinzugekommen, die so wie Railcom und mfx auch über das Gleis geht. Es werden also keine Rückmelde-Kontakte (z.B. Reedkontakte oder Strichcode-Leser) gebraucht. Allerdings wird die komplette Strecke in Abschnitte für die Rückmeldung aufgeteilt. Ein Rückmelder pro Abschnitt.
Nur so ergibt sich eine vollständige Zugverfolgung, die hier wirklich eindeutig geschieht, da u.a. auch die Adresse zurückgemeldet wird.
Soviel zu C-Digital... Marius wird das sicher bestätigen können denke ich.
[/quote]

C-Digital setzt also um, was mfx zwar potentiell könnte, aber de facto nicht macht, und DCC mit Railcom auch könnte, aber meines Wissens auch von keiner Zentrale unterstützt wird - und wenn man einen PC dran hat, braucht man die identifizierende Rückmeldung nicht...

Zitat

---

Daraus folgt auch, dass Marius hier bei DCC einige Verständnisprobleme hat, weil er das so ja nicht kennt...
[quote="Erich Müller" post_id=1819642 time=1523108932 user_id=26147]
Um mal wieder einen meiner allseits beliebten Vergleiche heranzuziehen:
Ein Bremsmodul, oder jede andere Einrichtung, die in der Anlage verbaut ist und dem herannahenden Zug eine Aktion abverlangt, ist wie ein Reflex. Der funktioniert ohne Mitwirkung des Gehirns - und immer gleich.
Die Steuerung über die Zentrale (und den Menschen, der sie bedient, oder den Computer, der sie unterstützt...) dagegen bezieht das Gehirn mit ein. Die Intelligenz. Und damit kann die Reaktion intelligent geschehen.

Analog gedacht ist: wenn irgendeine Lok an der Stelle x ist, dann muss sie dies oder das tun. Digital gedacht ist: wenn die Zentrale der Lok etwas aufträgt, dann tut sie das, egal wo sie sich gerade befindet. Analog gedacht ist: ich steuere die Anlage, und die Anlage steuert das Triebfahrzeug. Digital gedacht ist: ich (und nicht die Anlage!) steuere das Triebfahrzeug.

---

denn bei ihm gibt es keine Bremsmodule oder ähnliches. Die Steuerung erfolgt praktisch immer über die Zentrale. Welche Übertragungskette sich im Detail ergibt hängt davon ab, wie genau er steuert. z.B. PC->Zentrale->Gleis oder Tablett->Zentrale->Gleis oder Handregler->Zentrale->Gleis oder Zentrale->Gleis (wobei in der Zentrale etwa irgendein/e Automatismus/Logik eingestellt wurde).[/quote]

Und genau das - dass die Steuerung vor dem roten Signal über die Zentrale erfolgt und nicht über eine direkte Interaktion zwischen einem örtlichen Modul und der Lok - hatte Marius nicht gesagt. Aus seinen Ausführungen hatte ich genau das Gegenteil verstanden und darauf reagiert.

Zitat

---

[quote="Erich Müller" post_id=1819642 time=1523108932 user_id=26147]
[quote="Erich Müller" post_id=1819320 time=1523028886 user_id=26147]
Interaktion zwischen Anlagenbauteilen und Rollmaterial ist dazu aber nicht in der Lage - allein schon, weil dazu zu viele Informationen auch in der Lok transportiert werden müssten, die der Lokführer in 1:1 zwar in seiner Tasche mitbringen kann, nicht aber der Decoder in 1:87 oder gar 1:160.

---

Zitat

---

Wieso denn? Eine Lok kann doch ihre Adresse in einem Abschnitt zurück melden und eben auf diese Adresse wird dann in irgendeiner Weise reagiert. Wenn man möchte, dass diese Lokadresse in diesem Abschnitt halten soll, dann stellt man das ein und es wird auch dann nur diese halten - alle anderen Adressen reagieren darauf nicht. Dazu muss in der Lok garnichts zusätzliches gemacht werde, oder? Der Dekoder macht halt was er sonst auch macht und meldet seine Adresse zurück. Ich verstehe hier einfach nicht was du meinst....?

---

Und genau das ist analoges Denken. Das konnte man übrigens vor 30 Jahren auch schon, mit Strichcodeleser etc., und dann klickten die relais je nach gelesener Zugnummer...
[/quote]
Bei Marius, C-Digital, wird eine Adresse zurückgemeldet und die Zentrale oder PC oder was auch immer er zum Steuern nimmt, reagiert gezielt auf diese Lok mit entsprechenden Digitalbefehlen über das Protokoll. Das ist also gerade nicht analoges Denken. Ihr redet hier wohl aneinander vorbei, weil keiner das System des anderen richtig kennt
[/quote]

Ja, wie ich schon sagte. Nun frage ich mich, wie genau eigentlich Marius selbst sein System und dessen Funktionsweise kennt?

Zitat

---

Dann noch etwas zum Mehraufwand im Dekoder. Im Fall von Marius System, muss der Dekoder natürlich selbstständig auf einen Halte-, Langsamfahrbefehl reagieren können. Also muss hier im Dekoder mehr "Intelligenz" sein (fahrstufenunabhängige Anhalteweglänge usw.). Aber das ist grundsätzlich zunächst einmal genauso wie beim großen Vorbild, weil der Dekoder ja im Prinzip der Lokführer ist und dieser in den meisten Fällen auch aktiv die Lok steuert (beschleunigt, bremst, auf ein Signal reagiert, ...). LZB setzt man bei der Bahn ja auch erst ab einer gewisse Geschwindigkeit ein, wenn ich mich nicht täusche.
Diesen Mehraufwand hat man hier also tatsächlich. Auf der anderen Seite spart man bei der Auslastung des Bus-Systems, egal ob für die Hin- oder Rückrichtung. Evtl gibt es noch andere Vorteile, da müsste ich noch einmal darüber Nachdenken.

---

Ich finde also bei C-Digital im Decoder wieder, was ich in meinem System bei Rocrail angebe: die Langsamfahrgeschwindigkeit. Ist die einstellbar?
Verglichen mit Rocrail (zumindest ohne BBT-Funktion) liegt die Belastung der Übertragungswege ungefähr auf gleichem Niveau: da verwendet Rocrail die decodereigenen Beschleunigungs- und Verzögerungskurven, eben um mit wenig Rechenleistung und wenig Zentralenbelastung auszukommen. Da ich aber beim Rückmeldebus auf nicht mehr als eine reine wahr-falsch-Meldung (also 1 Bit pro Melder) angewiesen bin, dürfte sich selbst mit BBT (rund fünf bis zehn Fahrbefehle pro Anhalten) die Belastung in Grenzen halten.
Der Vorteil, diese "Intelligenz" nicht dem Decoder einzubauen, sondern in oder jenseits der Zentrale zu implantieren, ist in meinen Augen: die Routine muss nur einmal programmiert werden und kann dann auf viele Decoder angewandt werden, und das ganz unabhängig von deren Hersteller und sonstigen Fähigkeiten; die Rechenleistung wird von einem groß dimensionierten Rechner verlangt, der weder räumlich noch an Arbeits- oder Datenspeicher Platznot kennt und auch seine Wärme bestens abführen kann. In Lokomotiven, je kleiner sie sind, um so mehr, ist sowohl Platz als auch Wärme ein echtes Problem.

Zitat

---

Wenn ich mich irgendwo getäuscht haben sollte, berichtigt mich gerne und flammbiert mich nicht gleich.
Ich denke, dass hier nur so kontrovers diskutiert wird, weil man größten Teils aneinander vorbei redet. Ich hoffe ich habe für etwas Klarheit sorgen können.



edit: Habe eben erst Carstens letzten Post gelesen. Meine oben angenommene Vermutung scheint sich also bestätigt zu haben.

Zitat

---

Aber wie ich oben schon schrieb, sollen bei Digital die Loks allein von der Zentrale gesteuert werden, das Gleis dient nur als Medium zur Befehlsübermittlung und als Stromversorgung. Damit sollte die Anzeige auf dem Handregler auch immer den aktuellen Betriebszustand des Fahrzeugs widerspiegeln. ABC bricht mit diesem System, indem es die analoge Art des Steuerns in die Digitalwelt herüberholt. Eine Lok im ABC-Abschnitt ignoriert die Fahrbefehle der Zentrale, bestenfalls rückwärts kann man noch fahren.

---

---

Das von Carsten Geschriebene gilt übrigens m.M.n. in gleicher Weise auch für die u.a. bei tams angewandte Methode des "Bremsboosters" - wenn ich richtig sehe, ein Booster, der quasi nur dazu dient, auf Brems- bzw. Haltestrecken zu speisen, und zwar mittels Relaisumschaltung zwischen diesem und dem normalen Fahrbooster. Der Bremsbooster gibt, bei Übermittlung aller sonstigen Befehle, immer Fahrstufe 0 aus.
Bremsbooster sind die Antwort auf die Frage "geht das denn überhaupt ohne ABC"... Der Vorteil ist, dass das mit allen Decodern und in allen Protokollen funktionieren kann, sogar in MM1 oder MM2 mit nicht ABC- und nicht gleichstrombremsfähigen Decodern. Der grundsätzliche Verstoß gegen das von Carsten beschriebene Grundprinzip bleibt aber auch hier.

Hallo Erich

Zitat

---

Der Bremsbooster gibt, bei Übermittlung aller sonstigen Befehle, immer Fahrstufe 0 aus.
Bremsbooster sind die Antwort auf die Frage "geht das denn überhaupt ohne ABC"... Der Vorteil ist, dass das mit allen Decodern und in allen Protokollen funktionieren kann, sogar in MM1 oder MM2 mit nicht ABC- und nicht gleichstrombremsfähigen Decodern. Der grundsätzliche Verstoß gegen das von Carsten beschriebene Grundprinzip bleibt aber auch hier.

---

Hinzu kommt, dass eine Trennstelle zwischen Bremsbooster / Bremsgenerator und normalem Fahrbetrieb nicht überbrückt werden darf, sonst Kurzschluss. Immerhin dieses Manko hat ABC nicht.

Viele Grüße
Carsten

Guten Abend,

@Erich:

[quote="Erich Müller" post_id=1819766 time=1523129463 user_id=26147]
ich hab jedenfalls nichts dagegen - im Gegenteil. Du bringst Klarheit in die Sache, für mich zumindest.
[/quote]
Super, das war meine Intention.



[quote="Erich Müller" post_id=1819766 time=1523129463 user_id=26147]
C-Digital setzt also um, was mfx zwar potentiell könnte, aber de facto nicht macht, und DCC mit Railcom auch könnte, aber meines Wissens auch von keiner Zentrale unterstützt wird - und wenn man einen PC dran hat, braucht man die identifizierende Rückmeldung nicht...
[/quote]
Da bin ich mir nicht so sicher. So wie das nach meinem Kenntnisstand bei C-Digital ist, kann das bei DCC oder mfx nicht sein, weil es in diesen Protokollen doch keine Halteinformation gibt.
C-Digital setzt von Beginn an eine komplett "digitale Denkweise" (wie du es genannt hast) um.
Also wenn das bei DCC genauso ginge wie bei C-Digital, dann sollte man das unbedingt implementieren. Allerdings glaube ich es erst, wenn ich es einmal gesehen habe, dass das funktioniert.
Stimmt, mit PC braucht man nicht unbedingt eine identifizierte Rückmeldung. Es erleichtert aber andere Dinge und ich finde zunächst einmal generell, dass es hier und da auch Vorteile bringt, gerade wenn auch noch mehrere Leute interagieren oder man bestimmte Zugverbände mit einem Dekoder ausstattet.

[quote="Erich Müller" post_id=1819766 time=1523129463 user_id=26147]
Und genau das - dass die Steuerung vor dem roten Signal über die Zentrale erfolgt und nicht über eine direkte Interaktion zwischen einem örtlichen Modul und der Lok - hatte Marius nicht gesagt. Aus seinen Ausführungen hatte ich genau das Gegenteil verstanden und darauf reagiert.
[/quote]Wahrscheinlich, weil er ja für die Rückmeldung pro Abschnitt ein Modul am Gleis hängen hat. Es geht über ein und die selbe Leitung die Information auf die Schiene, so wie auch von der Schiene zurück. Klar hat er das aus seiner Sicht garnicht richtig unterschieden und aufgedröselt, weil er es ja praktisch garnicht anderes kennt.
Alleine der Hinweis, dass sich bei C-Digital schon immer eine Halteinformation im Protokoll befindent, hätte dir hier wahrscheinlich schon die Augen geöffnet.
Mir ging es auch so, wenn man etwas nur anders kennt, ist es schwer umzudenken.

[quote="Erich Müller" post_id=1819766 time=1523129463 user_id=26147]
Nun frage ich mich, wie genau eigentlich Marius selbst sein System und dessen Funktionsweise kennt?
[/quote]Ich denke schon, dass er einiges darüber weis. Vermutlich deutlich mehr als ich, da er ja auch Anwendererfahrungen gemacht hat. Wie gesagt, ist es wahrscheinlich so, dass für ihn manche Dinge so klar sind, die du/ihr hier erst definieren müsst, weil diese am sonstigen Markt nicht üblich sind, und er das dann garnicht oder nur schwer nachvollziehen kann. :
Das wäre meine Einschätzung.


[quote="Erich Müller" post_id=1819766 time=1523129463 user_id=26147]
Ich finde also bei C-Digital im Decoder wieder, was ich in meinem System bei Rocrail angebe: die Langsamfahrgeschwindigkeit. Ist die einstellbar?
[/quote](Ich habe keine Rocrail Erfahrung) Ja, so weit ich weiß ja auch fahrrichtungsabhängig in Prozent der ebenfalls einstellbaren Vmax.
Aber Marius weiß das sicher genau.

[quote="Erich Müller" post_id=1819766 time=1523129463 user_id=26147]
da verwendet Rocrail die decodereigenen Beschleunigungs- und Verzögerungskurven, eben um mit wenig Rechenleistung und wenig Zentralenbelastung auszukommen. Da ich aber beim Rückmeldebus auf nicht mehr als eine reine wahr-falsch-Meldung (also 1 Bit pro Melder) angewiesen bin, dürfte sich selbst mit BBT (rund fünf bis zehn Fahrbefehle pro Anhalten) die Belastung in Grenzen halten.
[/quote]Wie das jetzt genau bei C-Digital ist, weiß ich leider nicht. So exzessiv habe ich mich damit jetzt auch nicht beschäftigt, ich fand es eben nur sehr interessant und halte es für eine recht kluge Lösung.
@Marius: Wie wird das automatische Halten bei dir im Dekoder konfiguriert?


[quote="Erich Müller" post_id=1819766 time=1523129463 user_id=26147]
Der Vorteil, diese "Intelligenz" nicht dem Decoder einzubauen, sondern in oder jenseits der Zentrale zu implantieren, ist in meinen Augen: die Routine muss nur einmal programmiert werden und kann dann auf viele Decoder angewandt werden, und das ganz unabhängig von deren Hersteller und sonstigen Fähigkeiten; die Rechenleistung wird von einem groß dimensionierten Rechner verlangt, der weder räumlich noch an Arbeits- oder Datenspeicher Platznot kennt und auch seine Wärme bestens abführen kann.
[/quote]
Ich weiß nicht ob ich dich hier richtig verstehe, aber das Halten ist ja gerade auch von der Lok selbst abhängig (Motor + Getriebe) und wenn man seine Lok nicht mit einer Software rel. aufwändig einmessen will oder kann, dann ist man doch gerade darauf angewiesen, dass man für jede Lok individuell eine Bremskurve/Bremsprofil erstellen kann. Ich muss also in jedem Fall für jede Lok individuell einstellen, respektive programmieren können, wie sie im Fall der Fälle halten soll.
Thermische Probleme aufgrund einer erhöhten Rechenleistung eines Dekoders höre ich persönlich zum ersten mal.
@Marius: Hast du derartiges schon einmal bei deinen Dekodern festgestellt?


[quote="Erich Müller" post_id=1819766 time=1523129463 user_id=26147]
Das von Carsten Geschriebene gilt übrigens m.M.n. in gleicher Weise auch für die u.a. bei tams angewandte Methode des "Bremsboosters" - wenn ich richtig sehe, ein Booster, der quasi nur dazu dient, auf Brems- bzw. Haltestrecken zu speisen, und zwar mittels Relaisumschaltung zwischen diesem und dem normalen Fahrbooster. Der Bremsbooster gibt, bei Übermittlung aller sonstigen Befehle, immer Fahrstufe 0 aus.
Bremsbooster sind die Antwort auf die Frage "geht das denn überhaupt ohne ABC"... Der Vorteil ist, dass das mit allen Decodern und in allen Protokollen funktionieren kann, sogar in MM1 oder MM2 mit nicht ABC- und nicht gleichstrombremsfähigen Decodern. Der grundsätzliche Verstoß gegen das von Carsten beschriebene Grundprinzip bleibt aber auch hier.
[/quote]Diese Lösungen halte ich aus den selben Gründen wie Carsten für keine wirkliche Alternative und eher mit Vorsicht zu genießen. Denn hier unterscheidet sich das DCC-Gleissignal außerhalb des Blocks zu dem innerhalb, weil hier ja alle Fahrstufenbits 0 gesetzt sind. Da wäre mir die Gefahr eines Kurzschlusses viel zu groß und es schränkt enorm die Möglichkeiten ein.

Stellen wir uns vor eine Lok mit Zug hält in so einem Boosterabschnitt. Jetzt soll der Zug hinten durch weiter Wagons ergänzt werden und vorne soll eine zweite Lok für Doppeltraktionbetrieb angehängt werden. Hier kann man jetzt nicht einfach rangieren und hinten die Wagons anhängen, auch das ankuppeln vor der bestehenden Lok ist nicht einfach möglich, da sich jedesmal zerstörerische Kurzschlüsse ergäben bzw. die Lok sobald sie im Abschnitt wäre nicht mehr fahren würde (FS0). Man müsste dann immer erst die Lok im Halt auf FS0 stellen und den Abschnitt auf Fahrt schalten, damit man gefahrlos rangieren kann. Das ist für mich keine wirkliche Alternative zu ABC, zumal auch hier gegen das Prinzip eines Digitalsystems widersprochen wird.

@Martin:
[quote="Martin Lutz" post_id=1819710 time=1523121506 user_id=124]
Wenn du schreibst, dass bei DCC einiges nur mit PC möglich wird, dann sage ich Nein deshalb, weil es nicht nur für DCC so ist, sondern für ALLE Digitalsysteme.

Und ein Digitales Modellbahnsytem wird sicher nicht digitaler, wenn man mit Hilfe von einer PC Steuerung noch zusätzliche Funktionalitäten hinzufügt.

Digital ist Digital!

Wenn man eine Multiprotokoll-Zentrale hat und eine Computersteuerung ist es schon fast egal, ob das System eine Lok mit MM, mfx, DCC oder
Selectrix ansteuert.
[/quote]Ich glaube auch hier liegt nur wieder ein Missverständnis zu Grunde.
Aus der Sicht von Marius mit seinem C-Digital gibt es keinen funktionellen Unterscheid, ob er nun vom PC, Tablett oder Handregler aus steuert. Desshalb wohl die Verwirrung...
Eine höhere Funktionalität ergibt sich also für alle Digitalsysteme, - halt -, für alle gängigen Digitalsysteme (mfx, DCC, MM). Für C-Digital gilt das eben anscheinend nicht. Da ist es der Vorliebe des Nutzers überlassen wie, oder mit was er/sie am liebsten steuert. Es könnte z.B. auch ein Tablett in Kombination mit einem selbstgebauten BSW sein.
Das einzige was sein kann ist, dass sich der Bedienkomfort von der einen zur anderen Methode unterscheidet.

Das Digital entweder Digital ist oder nicht, da stimme ich dir zu. Hier gibt es keine Abstufung und es wird auch nicht "digitaler" flaster: , wenn man mit PC-Software fährt, - egal welches Protokoll.

Guten Abend,

Man man man, habt ihr hier viel geschrieben. Mal schauen, ob ich da hinterher komme...

Danke Klaus, für dein Engagement, zwischen den zwei Welten zu vermitteln
In der Tat ist es so, dass ich mich bei meiner Denkweise zu sehr von meinem Kenntnisstand von C-Digital beeinflussen lasse. Das ist auch nichts neues für mich, manche "Probleme", sofern ich das so bezeichnen darf, kenne ich nicht und kann ich nicht nachvollziehen, weil es diese in meiner Welt einfach garnicht gibt.


@Erich:
Viele deiner Fragen an mich hat ja Klaus freundlicherweise schon beantwortet, ich gehe desshalb nicht noch einmal explizit auf alles ein. Ich werde allerdings hier und da einmal etwas ergänzen, wenn ich es für nötig halte....

Bei C-Digital steht die Halte-, Fahrt- und Langsamfahrtinformation im Protokoll und kann zusätzlich auch als Draht aus der Zentrale direkt verwendet werden. Es gibt UZ=Halt Uhrzeigersinn, GUZ=Halt Gegenuhrzeigersinn, STR=Fahrt und "nicht STR"=Langsamfahrt.
Die Langsamfahrterkennung (Parameter 14?) kann im Dekoder ein oder ausgeschaltet werden, nur für Vorwärts, nur für Rückwärts oder immer aktiviert werden und es kann die Langsamfahrgeschwindigkeit in Prozent, ausgehend von der eingestellten Höchstgeschwindigkeit, eingestellt werden.

Das Reagieren auf die Signale UZ und GUZ kann auch eingestellt werden. Ein/aus und ob nur mit passender Adresse darauf reagiert wird oder, wie bei den ganz alten Dekodern, immer darauf reagiert wird unabhängig der gesendeten Adresse.
Wenn man noch mit den etwa 20Jahre alten Dekodern fahren will, muss man diese Einstellung nehmen, da die Dekoder weder rückmelden, noch adressspezifisch auf die Haltesignale reagieren können.
Die Kompatibilität wird also niergends verletzt, allerdings wird die Funktionalität deutlich eingeschränkt.

Zitat

---

Ein Bremsmodul, oder jede andere Einrichtung, die in der Anlage verbaut ist und dem herannahenden Zug eine Aktion abverlangt, ist wie ein Reflex. Der funktioniert ohne Mitwirkung des Gehirns - und immer gleich

---

Kann er doch auch, sofern ich das für diesen Abschnitt, für jene Lok so in der Zentrale eingestellt habe. Das darf dann ruhig automatisch geschehen. Da braucht es dann kein Zutun mehr und es geschieht, gemäß dem was eingstellt wurde, immer gleich. Allerdings nicht, ohne dass die Zentrale das auch weiß, denn dort habe ich es ja eingestellt.
Ich kann auch einstellen, dass ein Abschnitt unabhängig der Lokadresse immer nur entweder Halt oder Fahrt am Gleis (im Protokoll) hat. Ein Überfahren oder Brücken der Trennstelle dieses Rückmelde-Abschnitts zum nächsten macht hier nichts, auch wenn sich das Datensignal von einem Abschnitt zum Anderen unterscheiden könnte.

Zitat

---

ich hatte dich so verstanden, dass du ein Steuerungsmodell favorisierst, das in bestimmten Punkten nicht den Grundsätzen der "großen" Bahn entspricht. Zum Beispiel, indem Lokführer (=Decoder) und ortsfeste Einrichtungen bestimmte Aktionen untereinander "aushandeln".

---

Wie gesagt, kann man auch das machen, sofern man möchte, in dem man es über die Zentrale einstellt. Die Einstellungen kennt die Zentrale so natürlich immer.

Zitat

---

Nee, ohne Scherz, man kann sich mal verrennen. Das passiert sogar den besten - schau mich an. Aber es ist eigentlich besser, erst noch mal zu lesen, bevor man nachfragt, oder auch zu Dingen, die im Internet irgendwo stehen, noch andere Seiten zu suchen, ob die das gleiche sagen (und nicht voneinander abschreiben - das gibts nämlich auch, und manchmal sogar wortgleich!), und ob andere was ganz anderes sagen.
Und nachfragen, ob man das richtig verstanden hat, wie man es verstanden hat, kann gerade bei hitziger Diskussion mal Schärfe rausnehmen...

---

Ich werde es in Zukunft beherzigen.

Zitat

---

Nur nützen die Rückmeldesysteme ja eben nicht das Gleis - von mfx-Anmeldung und (sehr lokal begrenzt funktionierender) Railcom-Meldung abgesehen.

---

Das sind dann abe Systeme die keine identifizierte Rückmeldung können. Die melden dann halt, das im Abschnitt xy ein Verbraucher ist oder so, oder?

Zitat

---

Ja, wie ich schon sagte. Nun frage ich mich, wie genau eigentlich Marius selbst sein System und dessen Funktionsweise kennt?

---

Also ich meine schon, dass ich mich bei meinem C-Digital auskenne. Zumindest bin ich bis jetzt ganz gut zurecht gekommen, trotz der spärlichen Dokumentation, weil Martin damit nicht hinterher kommt.
Ich wollte hier aber eigentlich nicht über C-digital sprechen, anscheinend führt kein Weg daran vorbei. Also wenn du Fragen hast, frag ruhig. Im schlimmsten Fall weiß ich es halt nicht. ops:


@Martin:
[quote="Martin Lutz" post_id=1819710 time=1523121506 user_id=124]
Wenn du schreibst, dass bei DCC einiges nur mit PC möglich wird, dann sage ich Nein deshalb, weil es nicht nur für DCC so ist, sondern für ALLE Digitalsysteme.

Und ein Digitales Modellbahnsytem wird sicher nicht digitaler, wenn man mit Hilfe von einer PC Steuerung noch zusätzliche Funktionalitäten hinzufügt.

Digital ist Digital!

Wenn man eine Multiprotokoll-Zentrale hat und eine Computersteuerung ist es schon fast egal, ob das System eine Lok mit MM, mfx, DCC oder
Selectrix ansteuert.
[/quote]Ok. Das wusste ich so nicht, dass sich die Fähigkeiten mit einer PC-Steuerung erweitern. Ich dachte nur, dass die vorhandenen Fähigkeiten komplexer werden können, also komplexer verknüpft z.B. - aber nicht, dass sich erst so gewisse Funktionen ermöglichen.
Das kenne ich tatsächlich anders.


@Klaus:

Zitat

---

Wie wird das automatische Halten bei dir im Dekoder konfiguriert?

---

Man kann verschiedene Anhalteweglängen wählen, ein adaptives Verhalten einstellen und, sofern es nötig sein sollte, einzelne Bremsweglängen zu Fahrstufen, die evtl. bei der Bremsweglänge zu stark ausscheren, anpassen.
Das Beschleunigungs- und Bremsverhalten, was ja keine fahrstufenunabhängige konstante Bremsweglänge liefert, wird gesondert eingestellt und hat auf obiges beim Bremsen keinen Einfluss.

Zitat

---

Hast du derartiges schon einmal bei deinen Dekodern festgestellt?

---

Ein Temperaturproblem kenne ich nur von den Motorendstufen, wenn man zu viel Saft zieht. Dann kann es sein, dass die Endstufe Kurzfristig abschaltet. Kaputt gegangen ist mir noch keine. Das der Dekoder gekühlt werden müsste, weil die Rechenleistung so hoch ist, wär mir neu. Ich kann Martin ja mal dazu fragen.

Gute Nacht,
Marius

Morgen an die Runde,

Ich habe mir die letzten beiden Seiten hier nocheinmal durchgelesen und bin jetzt etwas verwirrt und ersteunt. Bei einigen eurer Aussagen musste ich stutzen...

Ich hoffe das was ich jetzt schreibe, führt nicht wieder zu Streit und ich versuche so viel wie möglich an Zitaten fest zu machen.
Leider muss ich hier und da auch auf mein System Bezug nehmen...

Ich hoffe mich im Folgenden an dies...
[quote="Erich Müller" post_id=1819642 time=1523108932 user_id=26147]
Aber es ist eigentlich besser, erst noch mal zu lesen, bevor man nachfragt, oder auch zu Dingen, die im Internet irgendwo stehen, noch andere Seiten zu suchen, ob die das gleiche sagen (und nicht voneinander abschreiben - das gibts nämlich auch, und manchmal sogar wortgleich!), und ob andere was ganz anderes sagen.
Und nachfragen, ob man das richtig verstanden hat, wie man es verstanden hat, kann gerade bei hitziger Diskussion mal Schärfe rausnehmen...
[/quote]
gehalten zu haben.

Zitat von Heinzi im Beitrag Mfx und DCC

---

Weshalb man an den bekannten Systemen festhält?
Ganz einfach: Weil es keinen Markt gibt für neue revolutionäre Systeme.

---

Zitat von Heinzi im Beitrag Mfx und DCC

---

Also ich hege keine Heilserwartungen an ALAN. Ich sehe ALAN genauso wie du als Nichenprodukt.
Das C-Digitalsystem ist da wirklich innovativer, aber leider komplett inkompatibel zu bestehenden Digitalsystemen. Daher noch weniger Verbreitungschancen.

---

Zitat

---

Der Knackpunkt ist, dass das Bremsen mit Dioden am Gleis ein klarer Bruch mit dem Gedanken ist, der hinter einem Digitalsystem steht. Bei Digital soll eigentlich einzig und allein die Zentrale über dei Befehle die Decoder steuern. Es ist nicht vorgesehen, dass irgendwelche Einrichtungen am Gleis die Loks beeinflussen.
...
Genau hier liegt das oben beschriebene Problem. Da für die Zentrale die Beeinflussung der Lok außen vor bleibt, bekommt auch die Steuerung nichts mit. In jedem Fall ist ABC eine "dumme" Technik. Jeder Decoder, der in einen Abschnitt mit akivem ABC fährt hält an, sofer er ABC kennt und es angeschaltet ist. Zumindest wenn man Glück hat, übermäßig zuverlässig ist die Technik nicht.

---

Zitat

---

Es bleibt dir doch unbenommen das zu nutzen. Dennoch hat das System mehrere Schwächen, die ich auch schon öfter live erlebt habe. ABC funktioniert, indem das Gleissignal asymmetrisch gemacht wird, also die Spannung verändert wird. Neben dem unschönen Effekt, dass die Fahrzeuge beim Einfahren in einen ABC-Block ruckartig langsamer werden können(falls der Decoder zu wenig Regelreserve hat) gibt es das Problem, dass so eine Asymmetrie auch anders entstehen kann. Bei Fahrzeugen mit Glühlampen, deren Pluspol an einer Gleisseite hängt, kommt es z.B. bereits dazu und selbst manche Zentralen (z.B. Intellibox) haben ein asymmetrisches Gleissignal. Im Ergebnis kommt es vor, dass manche Fahrzeuge schlicht und einfach nicht bremsen, andere halten zwar, fahren dann aber immer wieder kurz an und kriechen so nach einer Weile aus dem ABC-Block heraus.

Die Unterstützung von ABC in den Decodern muss außerdem noch gegeben sein. Leider ist die viel zu oft nur rudimentär, vielen Decodern fehlt z.B. die Möglichkeit, einen konstanten Bremsweg unabhängig von CV 3 / 4 einzustellen.

---

Zitat

---

... sollen bei Digital die Loks allein von der Zentrale gesteuert werden, das Gleis dient nur als Medium zur Befehlsübermittlung und als Stromversorgung. Damit sollte die Anzeige auf dem Handregler auch immer den aktuellen Betriebszustand des Fahrzeugs widerspiegeln. ABC bricht mit diesem System, indem es die analoge Art des Steuerns in die Digitalwelt herüberholt. Eine Lok im ABC-Abschnitt ignoriert die Fahrbefehle der Zentrale, bestenfalls rückwärts kann man noch fahren.

---

Zitat

---

Ich persönlich habe die Schwächen leider zu oft als zu gravierend erlebt, als dass ich die Benutzung guten Gewissens empfehlen kann. Speziell bei der Fehlersuche sind weniger technikaffine Nutzer dann schnell überfordert. Ich persönlich empfehle bei Verwendung von ABC immer einen stromlosen Abschnitt nach dem Halteabschnitt einzuplanen, damit die Fahrzeuge auch sicher halten. Ist natürlich eine Platzfrage...
Wie gesagt, wer es nutzen will, soll das gern tun. Ich verstehe durchaus, warum manche das gern verwenden, immerhin ist es eine ziemlich simple und vor allem billige Methode. Um es "richtig" zu machen muss man den Aufwand, auch den finanziellen, schon deutlich erhöhen. Man sollte aber schon drauf aufmerksam machen, dass es ein bisschen mit Vorsicht zu genießen ist.

---

[quote="Erich Müller" post_id=1819642 time=1523108932 user_id=26147]
Analog gedacht ist: wenn irgendeine Lok an der Stelle x ist, dann muss sie dies oder das tun. Digital gedacht ist: wenn die Zentrale der Lok etwas aufträgt, dann tut sie das, egal wo sie sich gerade befindet.
[/quote]

Zitat

---

Nur ist das:

"ein Digitalsystem ist ein System, wo die Fahr- und andere Befehle auf digitalem Weg übertragen werden"

Im Fall von ABC-Bremsmodulen, oder anderen Bremsmodulen, eben gerade nicht der Fall. Das Halt kommt da nicht von der Zentrale, sondern wird durch ein Signal, welches analog von einem Modul erzeugt wird und nur für diesen Abschnitt gilt im Dekoder ausgelöst, sofern dieser eine Erkennung hierfür implementiert hat.
Hier liegen dann auch einige Problemquellen von ABC.

---

Zitat

---

dass bei einem Digitalsystem eigentlich alle Befehle, die einen Dekoder steuern, digital erfolgen sollten. Alle Befehle sollten ausnahmslos über das jeweilige Protokoll von einer Zentrale o.ä. zum Dekoder gelangen. Also keine Beeinflussung eines Dekoders durch ein lokales, irgendwie geartetes Signal, wie z.B. Gleichspannung, asymmetriesche Spannung (ABC), etc..
Aus dieser Forderung folgt, dass das Halten, bspw. vor einem Signal, mittels ABC-Bremsstrecken (DCC) oder Bremsstrecken durch Gleichspannung (Märklin) nicht wirklich in die digitale Welt "passen". Man kann sie natürlich bedenkenlos verwenden, mache ich selber auch, nur widerspricht das eigentlich dem Grundgedanken von Digital. Es erinnert eher an eine analoge Halteautomatik.
Daraus folg im Fall von DCC (keine Ahnung wie das bei mfx ist) nunmal, dass man, sofern man eine "totale" Digitalsteuerung mit Automatismen wie Halt uvm. möchte, man immer einen PC mit entsprechender Software + irgendeine Art Rückmelder braucht. Das DCC-System alleine gibt das nicht her.

---

Es liegt doch im Konzept ein Fehler vor, wenn die Systeme, egal welche, auf analoge Technik angewiesen sind, um entsprechende Halte-Funktionalität zu liefern.
Dann kommt noch hinzu, dass diese analoge Technik, im Fall von ABC, nicht besonders Betriebssicher zu sein scheint.
Des Weiteren bringt der Einsatz der Analogtechnik hier und da immer noch funktionelle Einschränkungen mit sich.
Außerdem muss der Dekoder diese analoge Technik "verstehen", was nicht grundsätzlich gegeben ist.
Das habt ihr hier doch geschrieben, oder verstehe ich das alles falsch?

Zitat

---

Mit einer PC-Steuerung kannst du dagegen sehr viel mehr. Die Decoder müssen nix Spezielles können und da es über die DCC-Befehle läuft, ist es ebenso zuverlässig wie das Drehen am Handregler. Wie die Züge reagieren sollen kannst du beliebig einstellen.

---

[quote="Martin Lutz" post_id=1819492 time=1523079680 user_id=124]
mit der Computersteuerung gewinnt die digitale Modellbahn generell an Funktionalität, ganz egal welches digitale Format dahintersteckt!
[/quote]

Zitat

---

Einen PC würde ich nur als Bereicherung sehen, nicht aber als zwingend notwendig für ein Digitalsystem.

---

[quote="Erich Müller" post_id=1819642 time=1523108932 user_id=26147]
Moderne High-End-Zentralen können in dieser Hinsicht einiges bieten, aber bisher noch nicht mit einem PC und dem entsprechenden Programm mithalten - dies vor allem, weil keine Zugverfolgung vorgesehen ist. (Man könnte sagen, die Zentralen denken analog. )
[/quote]
[quote="Erich Müller" post_id=1819642 time=1523108932 user_id=26147]
MariusS hat geschrieben: ↑
Sa 7. Apr 2018, 01:36
Heißt das dann, dass bei DCC einiges nur mit PC überhaupt möglich wird? Sehen das andere DCC-Fahrer auch so?

Das hat nichts mit DCC oder mfx oder welchem Protokoll auch immer zu tun.
[/quote]
[quote="Martin Lutz" post_id=1819710 time=1523121506 user_id=124]
Wenn du schreibst, dass bei DCC einiges nur mit PC möglich wird, dann sage ich Nein deshalb, weil es nicht nur für DCC so ist, sondern für ALLE Digitalsysteme.
Und ein Digitales Modellbahnsytem wird sicher nicht digitaler, wenn man mit Hilfe von einer PC Steuerung noch zusätzliche Funktionalitäten hinzufügt.
Wenn man eine Multiprotokoll-Zentrale hat und eine Computersteuerung ist es schon fast egal, ob das System eine Lok mit MM, mfx, DCC oder
Selectrix ansteuert.
[/quote]
Abhilfe schafft dann erst die PC-Steuerung + Rückmelder, egal ob DCC, Märklin oder SX Systeme. Diese sollte aber nicht zwingend für ein Digitalsystem von Nöten sein, sondern mehr als "Bereicherung" dienen, damit komplexere Zusammenhänge geschaltet werden können. Außerdem scheint sie auch nicht wenig zu kosten.
Die Grundfunktionalität eines Digitalsystems und dazu gehört auf jeden Fall auch das automatische Halten, das muss man glaube ich nicht diskutieren, sollte sich dadurch nicht erst überhaupt ergeben.
Es muss also ein deutlich größerer Aufwand getrieben werden, damit die Systeme eine vollständig digitale Steuerung darstellen. Eine Zugverfolgung geht ohne PC überhaupt nicht.

Unterm Strich bleibt also:
- In den Systemen ist die digitale Funltionalität konzeptionell nicht vollständig enthalten. Also ein Manko...
- Alle Lösungen ohne PC verletzten den digitalen Grundgedanken und sind dazu nicht einmal besonders Betriebssicher und weisen immer funktionale Einschränkungen auf. Also auch ein Manko...

=====================================

[quote="Erich Müller" post_id=1819642 time=1523108932 user_id=26147]
Die Steuerung über die Zentrale (und den Menschen, der sie bedient, oder den Computer, der sie unterstützt...) dagegen bezieht das Gehirn mit ein. Die Intelligenz. Und damit kann die Reaktion intelligent geschehen.
[/quote]Das ist bei DCC, SX, Märklin also nicht automatisch gegeben, sondern muss durch höheren Aufwand (PC Software, Rückmelder) erst geschaffen werden.

====================================

[quote="Erich Müller" post_id=1819766 time=1523129463 user_id=26147]
Das von Carsten Geschriebene gilt übrigens m.M.n. in gleicher Weise auch für die u.a. bei tams angewandte Methode des "Bremsboosters" - wenn ich richtig sehe, ein Booster, der quasi nur dazu dient, auf Brems- bzw. Haltestrecken zu speisen, und zwar mittels Relaisumschaltung zwischen diesem und dem normalen Fahrbooster. Der Bremsbooster gibt, bei Übermittlung aller sonstigen Befehle, immer Fahrstufe 0 aus.
Bremsbooster sind die Antwort auf die Frage "geht das denn überhaupt ohne ABC"... Der Vorteil ist, dass das mit allen Decodern und in allen Protokollen funktionieren kann, sogar in MM1 oder MM2 mit nicht ABC- und nicht gleichstrombremsfähigen Decodern. Der grundsätzliche Verstoß gegen das von Carsten beschriebene Grundprinzip bleibt aber auch hier.
[/quote]

Zitat

---

Hinzu kommt, dass eine Trennstelle zwischen Bremsbooster / Bremsgenerator und normalem Fahrbetrieb nicht überbrückt werden darf, sonst Kurzschluss. Immerhin dieses Manko hat ABC nicht.

---

Zitat

---

Diese Lösungen halte ich aus den selben Gründen wie Carsten für keine wirkliche Alternative und eher mit Vorsicht zu genießen. Denn hier unterscheidet sich das DCC-Gleissignal außerhalb des Blocks zu dem innerhalb, weil hier ja alle Fahrstufenbits 0 gesetzt sind. Da wäre mir die Gefahr eines Kurzschlusses viel zu groß und es schränkt enorm die Möglichkeiten ein.

Stellen wir uns vor eine Lok mit Zug hält in so einem Boosterabschnitt. Jetzt soll der Zug hinten durch weiter Wagons ergänzt werden und vorne soll eine zweite Lok für Doppeltraktionbetrieb angehängt werden. Hier kann man jetzt nicht einfach rangieren und hinten die Wagons anhängen, auch das ankuppeln vor der bestehenden Lok ist nicht einfach möglich, da sich jedesmal zerstörerische Kurzschlüsse ergäben bzw. die Lok sobald sie im Abschnitt wäre nicht mehr fahren würde (FS0). Man müsste dann immer erst die Lok im Halt auf FS0 stellen und den Abschnitt auf Fahrt schalten, damit man gefahrlos rangieren kann. Das ist für mich keine wirkliche Alternative zu ABC, zumal auch hier gegen das Prinzip eines Digitalsystems widersprochen wird.

---

Zitat von Gast im Beitrag Mfx und DCC

---

Ich hatte einige Probleme in der Art der physikalischen Übertragung dieser Systeme gesehen. Diese ist da zwar nicht identisch, aber sehr ähnlich (sonst wäre Multiprotokoll auch garnicht möglich). Alle arbeiten mit einer aus Rechteckimpulsen bestehenden Wechselspannung zwischen +-12 bis 22 Volt, wenn ich mich hier nicht auch getäuscht habe?
Die Melde-Systeme müssen also in jedem System mit dieser, am Gleis ligender, Signalform klar kommen. - Vorausgesetzt es wird auch über das Gleis zurück gesendet.
So war meine Denklogik....

---

Zitat

---

Aus der Sicht von Marius mit seinem C-Digital gibt es keinen funktionellen Unterscheid, ob er nun vom PC, Tablett oder Handregler aus steuert. Desshalb wohl die Verwirrung...
Eine höhere Funktionalität ergibt sich also für alle Digitalsysteme, - halt -, für alle gängigen Digitalsysteme (mfx, DCC, MM). Für C-Digital gilt das eben anscheinend nicht. Da ist es der Vorliebe des Nutzers überlassen wie, oder mit was er/sie am liebsten steuert. Es könnte z.B. auch ein Tablett in Kombination mit einem selbstgebauten BSW sein.
Das einzige was sein kann ist, dass sich der Bedienkomfort von der einen zur anderen Methode unterscheidet.

---

Ja, so ist das bei mir. Für mich wäre das auch wichtig, dass nicht das "Werkzeug" (Handregler, Tablett, PC, ...) mit welchem man steuert darüber entscheidet, welche Funktionen eine "Maschine" (Anlage mit Digitalsystem) hat. Der Bedienkomfort darf sich gerne unterscheiden, mehr aber nicht.
Und unter Bedienkomfort versteht jeder etwas anderes, weil jeder so seine eigenen Vorlieben bei der Bedienung hat. Hier hat er dann eine gewisse Auswahl....

====================================================

Zitat von Heinzi im Beitrag Mfx und DCC

---

Dazu hast du dich aber sehr weit aus dem Fenster gelehnt. und hast dann wohl ein bisschen viel Probleme angenommen, die theoretisch ev. gar vorhanden sind, praktisch aber keine Auswirkungen zeigen und negiert werden können.

---

Moin Marius,


so langsam hast Du es ja erkannt. Ich fasse mal aus meiner Sicht und auch für meine Anlage knallhart zusammen.

Ohne PC-Steuerungssoftware mit stinknormaler S 88 Rückmeldung kann meine Anlage unmöglich laufen bzw. man müßte sich so verbiegen und tausende Sachen zusammenstricken, daß man mit z.B einer ECos oder CS evtl. einen Bruchteil von dem erreichen kann was mit einer Steuerungssoftware möglich ist. Die Kisten (ECos und CS) sind im Vergelich zur Steuerungssoftware einfach nur saudumme Kisten. Mehr nicht.

Mit einer Steuerungssoftware und total geringem Aufwand an Eigeninitiative sowie auch ohne große Kosten für die Rückmelderei hat man alles was man braucht.

Warum und für wen sollte da was neues gestrickt werden, wenn perfektes vorhanden ist.

Wer eine Anlage hat wo alle Gleise einsehbar sind der wird auch nicht unbdeingt eine PC-steuerung brauchen. Mir geht es aber hier um komplexe Anlagen wo in der Regel mehr als die Hälfte der Streckenführung nicht einzusehen ist und ein großer SBH voller Komplettzüge dazugehört. Wie soll das ohne Steuerungssoftware gehen. Das geht auch nicht mit x Neuerungen von denen Du träumst.

Hab jetzt extra etwas hart geschrieben, aber es ist so. Es gibt keinen Markt für solche Wünsche, weil es abgedeckt ist. Man muß halt nur wollen und eine Steuerungssoftware einbinden oder leiden und sich irgendwie mit zig Krücken behelfen. Kann sein, daß man(n) auch damit glücklich werden kann. Das ist ja das gute an unserem Hobby. Der eine so der andere so.

Gruß Markus

Zitat

---

=> Es gibt also keinen Markt für neue Systeme, warum aber nicht für eine konzeptionelle Neuerung bestehender Systeme? Hätte man so etwas nicht doch lieber machen sollen und hat den günstigen Moment bei der Einführung von Railcom oder mfx verpennt?
So in etwa meine frühere Annahme, die zu einem Aufschreib führte.

---

Weil das Abschneiden alter Zöpfe zwangsläufig zu Inkompatibilitäten führt. Mich stört am meisten das Heckmeck um die langen und kurzen Adressen bei DCC. Prinzipiell würden die langen Adressen ausreichen, denn auch die können Adressen ab 1 abbilden. Man wird das aber nicht los, weil per Default alle Decoder mit kurzer Adresse 3 ausgeliefert werden. Ändert man das auf lange Adresse 3, haben Kunden mit Bestandssystemen das Nachsehen, weil die die lange Adresse 3 nicht aufrufen können. So eine eigentlich simple Änderung zieht also einen Rattenschwanz an Konsequenzen nach sich, den Aufwand scheut man schlicht und einfach.

Zitat

---

Das heißt für mich, dass die Kompatibilität der verschiedenen Digitalsysteme untereinander durch die Art der Rückmeldung (Railcom oder mfx) inkompatibel werden, oder?

---

Jain. Prinzipiell spräche nichts dagegen beides gleichzeitig zu nutzen. Ich weiß allerdings nicht, ob es entsprechende Hardware gibt, die beides kann.

Zitat

---

Damit ergibt sich hier ein Manko für die Rückmeldesysteme Railcom und mfx, da sie bisherige Erungenschaften (Multiprotokoll, freie wahl bei Zentrale und Dekoder) zerstören.

---

Ich bin bin ehrlich gesagt kein Freund von Multiprotokoll. Das Vermischen zweier unterschiedlicher Systeme fügt immer potentielle Problemstellen hinzu. Obs nun blinkende Lampen sind, oder losrasende Loks, weil sie in den Analogmodus fallen - Dann lieber nur ein System verwenden.

Zitat

---

Es liegt doch im Konzept ein Fehler vor, wenn die Systeme, egal welche, auf analoge Technik angewiesen sind, um entsprechende Halte-Funktionalität zu liefern.
Dann kommt noch hinzu, dass diese analoge Technik, im Fall von ABC, nicht besonders Betriebssicher zu sein scheint.
Des Weiteren bringt der Einsatz der Analogtechnik hier und da immer noch funktionelle Einschränkungen mit sich.
Außerdem muss der Dekoder diese analoge Technik "verstehen", was nicht grundsätzlich gegeben ist.
Das habt ihr hier doch geschrieben, oder verstehe ich das alles falsch?

---

Warum soll das ein Fehler sein? Wie funktioniert das denn bei C-Digital? Dort muss doch auch eine Meldung zur Zentrale, damit die einen Befehl zur Lok schicken kann, oder? Wenn dort sonst auch einfach nur an einem Gleis eine Halt-Info ausgegeben wird, obwohl für die Lok im Regler eigentlich eine Fahrstufe eingestellt ist, haben wir dort sonst den gleichen Bruch. Ich hab aber von C-Digital keinerlei Ahnung, viel mehr als den Namen kenn ich nicht. Daher wär ich über eine grobe Zusammenfassung dankbar, wie das dort gehandhabt wird.

Zitat

---

Abhilfe schafft dann erst die PC-Steuerung + Rückmelder, egal ob DCC, Märklin oder SX Systeme. Diese sollte aber nicht zwingend für ein Digitalsystem von Nöten sein, sondern mehr als "Bereicherung" dienen, damit komplexere Zusammenhänge geschaltet werden können. Außerdem scheint sie auch nicht wenig zu kosten.
Die Grundfunktionalität eines Digitalsystems und dazu gehört auf jeden Fall auch das automatische Halten, das muss man glaube ich nicht diskutieren, sollte sich dadurch nicht erst überhaupt ergeben.
Es muss also ein deutlich größerer Aufwand getrieben werden, damit die Systeme eine vollständig digitale Steuerung darstellen. Eine Zugverfolgung geht ohne PC überhaupt nicht.

---

Es geht schon ohne PC, du kannst sowas auch mit kleinerer Hardware bzw. Microcontrollern machen. Ich benutze z.B. einen Raspberry Pi, weiter gibt es Zentralen mit integrierter Steuerungssoftware. Ein PC ist aber leistungsmäßig und von der Flexibilität her der beste Weg.

Ich persönlich sehe den automatischen Halt nicht als Grundfunktionalität. Digital heißt, dass in jeder Lok ein Lokführer sitzt, über den Decoder bin ich das. Damit liegt auch das Halten in meiner Verantwortung. Jeglicher Automatismus sitzt "on top" auf dem Digitalsystem, nutzt also nur dessen Funktionen um ins Geschehen einzugreifen. Anders gesagt ist die Automatik ein weiterer Mitspieler, der mir Aufgaben abnimmt.

Zitat

---

Hier lag ich mit der Problematik, die die Art der physikalischen Übertragung der Digitalsysteme mitsichbringt wohl doch nicht so falsch, oder? Denn diese ist doch die Ursache, wesshalb die Systeme erst mit zuhilfenahme eines PCs + Rückmeldemodulen zu Systemen werden, die die volle Funktionalität eines Digitalsystems liefern, ohne dass es in irgend einer Form zu einem Bruch mit dem "digitalen Grundgedanken" kommt.

---

Ich weiß nicht, was das eine mit dem anderen zu tun hat. Es wäre jetzt nicht das Problem es anders zu machen. Man könnte z.B. eine Hardware entwickeln, die sich als Handregler am System anmeldet und auf der anderen Seite Railcom-Meldungen von einem Gleisabschnitt entgegennimmt. Als Handregler kann das Ding eine Lok übernehmen, wenn sie in den Abschnitt einfährt, und der Zentrale sagen, dass sie an diese Adresse jetzt bitteschön Fahrstufe 0 senden soll. Das würde mit jedem Railcom-fähigen Decoder funktionieren, keine unüberfahrbaren Trennstellen produzieren und auch keinen Bruch mit dem Digitalgedanken bedeuten.

Zitat

---

Dann liegt also doch ein kozeptioneller Fehler (gravierende Schwäche) vor?

---

Wie ich dir oben schon schrieb: Konzeptionelle Fehler hängen sehr davon ab, was das Ziel des Konzepts sein sollte. Ein Geländewagen hat doch keinen konzeptionellen Fehler, nur weil du damit kein Formel 1-Rennen gewinnen kannst.

Zitat

---

Außerdem lese ich, dass es im Fall von DCC keine echte Alternative für ABC gibt und, dass die Ursache des Problems eben auf das Protokoll und va. die Methode der Übertragung zurückzuführen ist.

---

Wie ich oben schon schrieb ist das nicht der Fall. Es wäre durchaus möglich Lösungen zu bauen, aber es gibt wohl keinen Markt dafür.

Zitat

---

Ich hatte doch schon einmal geschrieben, dass diese Übertragung ein potentielles Kurzschlussproblem in sich trägt, welches dann hier und da zu Tage tritt (treten kann).
Da liege ich doch dann auch nicht falsch, oder?

---

Wenn du damit das Überfahren von Trennstellen meinst, bei denen unterschiedliche Gleissignale anliegen, dann ja. Es tritt aber eben nur bei falscher Handhabung der Technik auf. Bei C-Digital kannst du das auch haben, wenn du auf einer Seite die Kabel verkehrt anschließt. Oder um bei den beliebten Autovergleichen zu bleiben: Benzin ist leicht entzündlich, bei falscher Handhabung (oder Defekt) brennt dir die ganze Karre schnell ab. Sind das deswegen konzeptionelle Fehler?

Viele Grüße
Carsten