[MariusS]

Hallo Alf,

Zitat

---

Zitat

---

Die Zentrale oder "Gleisprotokollumsetzter?" muss doch mit den verschiedenen Dekodern und Protokollen usw. umgehen nicht die Software. So hatte ich das Softwareprinzip bis jetzt verstanden.

---

Die Zentrale oder "Gleisprotokollumsetzter?" muss die nötigen Schnittstellen eingebaut haben, aber die Software spricht mit den Decodern.

---

Ich dachte die Software gibt einer Zentrale bestimmte Fahr- und andere Daten für diverse Adressen und die Zentral gibt diese an den Dekoder. Damit läge es dann an der Zentrale, ob sie die Daten an den Dekoder in Form des mfx oder DCC oder eines anderen Protokolls gesendet werden, oder etwa nicht?
Stellt man in der Software das Gleisprotokoll ein?

Zitat

---

Zitat

---

Ich finde es -wie du ja auch- unsinnig, funktionierende Dekoder aus Fahrzeugen zu schmeißen. Dafür brauch ich dann schon mehrere Gründe: z.B. ich möchte mehrere Funktionen einbauen, ich mache evtl. noch einen Motoraumbau und möchte dann einen besseren Dekoder, etc.
Den alten funktionsfähigen Dekoder schmeiße ich dann trotzdem nicht weg, den kann ich dann immernoch in Triebköpfen o.ä. nutzen.

---

Wenn ein Decoder in einer Lok nicht funktioniert, wird er auch im Triebkopf nicht funktionieren!

---

Was verstehst du unter funktionieren? Ich habe nichts davon geschrieben, dass ein alter oder älterer Dekoder nicht mehr funktioniert. Der Funktionsumfang ist evtl. etwas eingeschränkt (kann kein Railcom, hat weniger Schaltausgänge, hat schlechtere Motorregelung, ...o.ä.)
Ich weiß nicht wo du das herziehst ... ich bin doch nicht blöd und denke, dass ein nicht funktionsfähiger Dekoder in einem Triebkopf auf wundersame Weise wieder funktioniert!
Ich verstehe einfach nicht warum man mich hier schon wieder als Idioten hinstellen will.

Zitat

---

Zitat

---

Ich glaube so war das nicht gemeint, dass nur noch, also ausschließlich, Railcom für die Rückmeldung eingesetzt werden sollte. Gleisbesetztmelder braucht man doch trotzdem, schon alleine wegen rollendem Material, das keinen Dekoder besitzt, man aber sehen können will, wenn in einem Abschnitt noch ein Zug, oder ein paar Wagen ohne Lok stehen.
Für mein Verständniss und aus meiner Erfahrung ist eine Kombination aus beidem eigentlich ideal. Wie welche Information dann wann und wo genutzt wird, ist dann von der, an der Zentrale angeschlossenen, Peripherie abhängig. Die Informationen sind aufjeden Fall abrufbereit.

---

Also kann ich auf Railcom verzichten, wenn ich anderweitige Rückmelder (punkt- oder linienförmig), die einen eigenen, unabhängigen Bus bedienen, verwende! Damit entlaste ich auch noch die Kommunikation zwischen Zentrale und Decoder!

---

Schön, das siehst du halt so. Ich glaube nicht, dass alle anderen auch auf Railcom verzichten wollen! Ich glaube, dass die Idee die Kommunikation zwischen der Steuerung und den Decodern bidirektional zu ermöglichen eine gute und sinnvolle ist, die einem Anwender auch einige Vorteile bringen kann. Aber gut...

Zitat

---

Fazit 1: keiner benötigt C-Digital, wer es verwenden möchte - wir leben in einem "freien" Land - soll es verwenden. Der große Rest verwendet fast ausschließlich Motorola und seine Derivate oder DCC.

---

Alles klar. Ich weiß zwar nicht, wieso es jetzt schon wieder auf einmal um C-Digital gehen soll, aber es braucht ja eh niemand! - Ach ja und eine Moba braucht übrigens auch niemand!

Ich seh schon, ich kann nichts schreiben, ohne dass ich sofort auf C-Digital angesprochen/angegangen und in die Schranken gewiesen werde. Ja, ich bin in der homogenen Mobahnergemeinschfat der Fremdkörper, der entfernt werden muss!

Zitat

---

Fazit 2: keiner muß auf den Zug von C-Digital aufspringen auch wenn Du viele (positive?) Argumente hervorhebst. C-Digital ist und bleibt ein Nischenprodukt und hängt an der Laune eines einzigen Entwicklers ab - als definitiv nichts für mich.

---

Ja, es ist ein Nischenprodukt. Ja, es hat keinen Markt. Ja, es gibt nur einen Hersteller und ja, keiner muss/sollte irgendeine Idee von C-Digital nachmachen!
Ich habe hier nie von C-Digital sprechen wollen, wurde aber immer wieder mehr oder minder konkret darauf angesprochen. Wenn ich Dinge bemängelt habe, wurde mir recht schnell praktisch damit entgegnet, dass ich keine Kritik üben dürfte, weil es bei C-Digital auch nicht anders sei. (oder ähnliche Aussagen, dass ich falsch denken würde usw. weil C-Digital ein "falsches" Konzept sei ...)
Also musste ich zwangsläufig immer wieder dazu Stellung nehmen. Konkrete Fragen habe ich dann auch nur per PN beantwortet.
Was dieses Verhalten soll, ist mir ein Rätsel. Warum man immer wieder versucht mich als Deppen hinzustellen und mich zu denunzieren, weiß ich auch nicht?

Zitat

---

PS: dieser Tröt ist eigentlich für mfx und DCC, aber nicht für C-Digital oder sonstige Protokolle wie SX usw.

---

Wo ging es in meinen Aussagen, - auf die du hier Bezug nahmst - denn um C-Digital? Ich hatte von Railcom gesprochen, also von DCC und dann von Softwaresteuerungen.
Hier ist es also wieder so: Erst labert man mich blöd an, dass ich hier andauernd von C-Digital schwafle, "Werbung?" betreiben will und angeblich (zweifelhaft) positive Eigenschaften herausstellen möchte, obwhol es garnicht um C-Digital ging. Dann beschwert man sich im selben Atemzug, dass hier immer wieder C-Digital ein Thema ist. Das muss man nicht verstehen!
Wer macht es denn andauernd zum Thema? - Außer um gewisse Sichtweisen zu verdeutlichen, war und ist es von meiner Seite hier nie Thema gewesen!

Der Fremdkörper verabschiedet sich hiermit und wünscht allen normalen Diskussionspartnern weiter viel Freude!

Marius

[vikr]

Hallo Stephan,

Zitat

---

Bist Du sicher, dass bei der Ecos ein Cutout nach einem MFX-Befehl vorhanden ist?

---

Ich bin mir sicher, dass die ECoS wie andere Multi-Zentralen korrekte DCC-Pakete mit genügend langer Preamble sendet, wenn mind. ein DCC Fahrzeug angemeldet ist, egal welche anderen Protokolle außerdem gefahren werden. Und das ist die einzige Voraussetzung für die Möglichkeit RailCom-Cuts zu schneiden. Ja, und ich habs auch gemessen.
[quote=stephan_bauer]
Und warum sollte der Decoder im MFX-Modus Railcom-Daten senden?
[/quote]
Na damit man die RailCom-Rückmeldungen dieses Decoders auch im M4-Modus nutzen kann.

MfG

vik

[Erich Müller]

Zitat

---

Na damit man die RailCom-Rückmeldungen dieses Decoders auch im M4-Modus nutzen kann.

---

Hallo vik,

Railcom ist im mfx-Modus aber nicht definiert.
Railcom geht nur mit DCC.

So wie du gern 모델 기차 hier ins Forum schreiben kannst, aber das ist eben in deutscher Sprache nicht definiert und wird von den Lesern dieses Forum darum nicht verstanden. Auch wenn es auf koreanisch "Modellbahn" bedeutet.

[vikr]

Hallo Erich,[quote="Erich Müller" post_id=1824746 time=1524406585 user_id=26147]

Zitat

---

Na damit man die RailCom-Rückmeldungen dieses Decoders auch im M4-Modus nutzen kann.

---

Railcom ist im mfx-Modus aber nicht definiert.
Railcom geht nur mit DCC.
[/quote]
Ich vermute Du hast in diesen Thread zumindest nicht jeden Beitrag ganz durch gelesen...
Natürlich läßt sich ein RailCom-Cut nur dort einschneiden wo auch ein DCC-Protokoll läuft.
Die Betonung liegt aber auf auch.
Wenn also an einer Multizentrale wie MS2, ECoS oder CS2 die Protokolle mfx und DCC laufen, dann kann man mfx-Loks und DCC-Loks gleichzeitig fahren. Natürlich werden die mfx und die DCC-Pakete immer abwechselnd gesendet und in den RailCom-Cut der DCC-Pakete kann jeder RailCom-Nachrichten reinschreiben.
Hat man in einer Lok mit mfx-Decoder zusätzlich einen DCC-Funktionsdecoder eingebaut kann dieser seine DCC-Adresse als Railcom-Nachricht in die RailCom-Cuts der vorhandenen DCC-Pakete einfügen. Die ECoS selber oder/und ein Modellbahnprogramm wie RocRail oder Windigipet können dann diese Adresse einander zuordnen.

Ich vermute mal - auf Grund Deiner Einlassung - dass Du dies selber noch nie ausprobiert hast.

Ich kann Dir aber versichern, dass es funktioniert. Meine Frage war also warum sollte ein ESU LoPi M4, der dies problemlos kann wenn er im DCC-Modus arbeitet, es nicht können wenn er im M4 Modus arbeitet (die bei ihm hinterlegte DCC-Adresse als RailCom-Nachricht in die auf dem Gleis vorhandenen RailCom-Cuts schreiben).

Tatsächlich kann es der LoPi M4 im M4-Modus nicht, es scheint mir aber keinen technischen Grund dafür zu geben, denn der Adressat der RailCom-Nachricht ist ja nicht der mfx-Decoder, sondern die Multi-Zentrale die mfx und DCC spricht, bzw. meistens ein Detector der die Cuts analysiert.

Oder um in Deinem Vergleich zu bleiben - koreanisch (RailCom) verstehen muß der Detector - und ein LoPi M4 kann nachweislich auf koreanisch (RailCom) rufen wenn er auf DCC hört warum verliert er die Fähigkeit koreanisch (RailCom) zu rufen plötzlich wenn er auf M4 hört?

MfG

vik

[Erich Müller]

Hallo Vikr,

kennst du irgendeinen Decoder, der Railcom-Meldungen abgibt, wenn er nicht im DCC-Format angesprochen wird?

Ich nicht.

Aus gutem Grund: wenn der LoPi-M4 mit mfx angesprochen wird, ist intern DCC abgeschaltet. Du kannst einen DCC-Decoder auf der im LoPi-M4 in CV1 gespeicherten Adresse ansprechen, und der LoPi-M4 wird sich einen feuchten Kehricht drum kümmern. Wenn M4, dann NOT(DCC). Railcom aber gehört NUR zu DCC.

Ob ein anderer Decoder Railcom sendet, ist doch völlig unerheblich: der Decoder funktioniert in einem einzigen Protokoll zur Zeit, und wenn das nicht DCC ist, gibt es kein Railcom.

Es gibt noch ein paar Decoder, die auf mehrere Protokolle gleichzeitig hören, was auch gern mal für Probleme sorgt; mfx-Decoder tun dies aber meines Wissens alle nicht.

[vikr]

Hallo Erich,[quote="Erich Müller" post_id=1824957 time=1524431699 user_id=26147]
Es gibt noch ein paar Decoder, die auf mehrere Protokolle gleichzeitig hören
[/quote]
Alle Decoder müssen das Gleisformat decodieren, d.h. die einzelnen positiven und negativen Anteile des Gleissignals ausmessen und dann so früh wie möglich in Pakete eines bekannten Typs einteilen. Ein Protokoll Abschalten bedeutet lediglich erkannte Pakete eines bestimmten Typs, sobald sie als solcher Typ erkannt sind, nicht detaillierter zu analysieren und vor allem keine Steuerinformationen für das Fahrzeug daraus abzuleiten.
Festzustellen, dass da ein DCC-Paket ist, gehört also zur Aufgabe jedes zeitgemäßen Decoders. Damit ist implizit auch die Identifizierung eines ggf. vorhandenen Cuts verbunden. Und ein Decoder, der wie der LoPi 4.0 M4, RailCom-Nachrichten nachweislich versenden kann, sollte das natürlich auch im M4 Modus können. Es spricht ja nichts dagegen RailCom im Decoder auch unter M4 abschaltbar zu machen, genau wie unter DCC.
Von Decodern, wie z.B. die mLDs oder mSDs von Märklin, die das RailCom-Nachrichten versenden nicht mal im DCC-Modus beherrschen (was ich für ein Manko für Trix-, LGB-, I- und minitrix-Fahrer halte), erwarte ich das natürlich überhaupt nicht...

MfG

vik

[StephanLeist]

Hallo Vikr,

Verstehe ich dich richtig, dass du die Railcom-Sendung auch im M4-Modus forderst, weil es kein Problem für einen Multiprotokoll-Dekoder und Zentrale sein sollte? Oder ist es Tatsache, dass das so von irgendeinem Dekoder gemacht wird und es bereits funktioniert?

Im Übrigen hört sich das sehr nach dem an, was Marius hier einmal als Forderung für einen Rückmelde-BUS formuliert hat, dass eine Rückmeldung (Rücksendung) unabhängig von der Hinsendung geschehen können sollte.
Ganz konsequent wäre es dann doch, wenn man sich ebenso wie das hinwärtige Protokoll (DCC, mfx, MM, SX) auch das rückwärtige (RC, mfx, o.a) durch eine Einstellung wählen liese.
Stephan B. hatte ja schon erklärt, dass RC das DCC nicht betrifft, also es nicht "verbiegt", es also in jedem Fall standardkonform ist. Folglich funktioniert RC unabhängig vom hinwärtigen Protokoll, oder? Alleine ein Zentralenseitiger Cut-Out sorgt dafür, dass RC möglich ist, was für eine Multiprotokollzentrale, die RC-fähig ist, ja kein Problem darstellen sollte.

Freundliche Grüße,
Stephan L.

[Martin Lutz]

Zitat

---

Hallo Vikr,

Verstehe ich dich richtig, dass du die Railcom-Sendung auch im M4-Modus forderst, weil es kein Problem für einen Multiprotokoll-Dekoder und Zentrale sein sollte? Oder ist es Tatsache, dass das so von irgendeinem Dekoder gemacht wird und es bereits funktioniert?

Im Übrigen hört sich das sehr nach dem an, was Marius hier einmal als Forderung für einen Rückmelde-BUS formuliert hat, dass eine Rückmeldung (Rücksendung) unabhängig von der Hinsendung geschehen können sollte.
Ganz konsequent wäre es dann doch, wenn man sich ebenso wie das hinwärtige Protokoll (DCC, mfx, MM, SX) auch das rückwärtige (RC, mfx, o.a) durch eine Einstellung wählen liese.
Stephan B. hatte ja schon erklärt, dass RC das DCC nicht betrifft, also es nicht "verbiegt", es also in jedem Fall standardkonform ist. Folglich funktioniert RC unabhängig vom hinwärtigen Protokoll, oder? Alleine ein Zentralenseitiger Cut-Out sorgt dafür, dass RC möglich ist, was für eine Multiprotokollzentrale, die RC-fähig ist, ja kein Problem darstellen sollte.

Freundliche Grüße,
Stephan L.

---

Das ist ja genau der Krux der Geschichte.

Wenn man ein intelligentes Rückmeldesystem nutzen kann, so sollte das für den ganzen Fuhrpark funktioneren. Nicht zuletzt historisch bedingt, habe ich alle Foromate auf der Anlage. MM1, MM2, mfx und DCC.
- Wenn, dann müsste ich ja alles umbauen und auf ein System bringen.
- Doch genau das ist ja nicht nötig, da es ja ein simples System gibt, das s88 das auf einfache Kontakte reagiert und daher unabhängig ist vom Digitalformat.

[StephanLeist]

Morgen Martin,

[quote="Martin Lutz" post_id=1824994 time=1524461787 user_id=124]
Das ist ja genau der Krux der Geschichte.

Wenn man ein intelligentes Rückmeldesystem nutzen kann, so sollte das für den ganzen Fuhrpark funktioneren. Nicht zuletzt historisch bedingt, habe ich alle Foromate auf der Anlage. MM1, MM2, mfx und DCC.
- Wenn, dann müsste ich ja alles umbauen und auf ein System bringen.
- Doch genau das ist ja nicht nötig, da es ja ein simples System gibt, das s88 das auf einfache Kontakte reagiert und daher unabhängig ist vom Digitalformat.
[/quote]Moment, moment, ich verstehe, was du sagen willst, aber...
Über den S88 alleine, kannst du doch keine konkreten Dekoderinformationen bekommen. Also keine Adresse und andere Werte, auch keine einprogrammierte Daten.
Der S88 ist echt robust und bewährt und für eine PC-Steuerung anscheinend ausreichend (ich steuere selbst noch nicht mit Computer), es ist aber kein Rückmelde-BUS, der als Pendant zur Dekoder-Hinsendung genutzt werden kann. Der S88 ist ein Bus zur Kommunikation zwischen Zentrale und anderen Hardwarekomponenten, wie Besetztmeldern. Ein RC-Melder könnte z.B. mit der Zentrale über den S88 kommunizieren und die vom Dekoder empfangenen Daten weiterleiten. Im Fall eines Besetztmelders leitet der S88 ja auch "nur" weiter zur Zentrale. Er ist also hier mit RC oder der mfx Rückmeldung des Dekoders nicht vergleichbar, da er den Inforamtionsweg von Zentrale und Dekoder ja nicht bidirektional ermöglicht, in einer anderen "Ebene" arbeitet und was ganz anderes darstellt.
Durch DCC mit RC ergibt sich doch eine bidirektionale Kommunikation zwischen Zentrale und Dekoder.

Für alte oder "unfähige" Dekoder gäbe es doch kleine RC-Module zum Nachrüsten.
Ich sehe es natürlich sonst genauso wie du, dass ein intelligentes Rückmeldesystem für alle Dekoder gehen sollte.
Den einzigen Nachteil den ich hier jetzt sehe ist, dass es im Fall von RC alte Dekoder und Hardware gibt, die damit nicht umgehen können. Hier sollte man dann einen Tausch vornehmen.
Blöd ist natürlich auch, dass es Dekoder gibt, die den RC-Umfang nicht voll unterstützen.
Ich hoffe ich werde für diese "Kritik" am RC-System jetzt nicht gelyncht, wie Marius, der genau das ja auch an RC bemängelte.

Freundliche Grüße,
Stephan L.

[vikr]

Hallo Stephan,

Zitat

---

Verstehe ich dich richtig, dass du die Railcom-Sendung auch im M4-Modus forderst, weil es kein Problem für einen Multiprotokoll-Dekoder und Zentrale sein sollte? Oder ist es Tatsache, dass das so von irgendeinem Dekoder gemacht wird und es bereits funktioniert?

---

"Fordern" ist sicher nicht das richtige Wort. Ich habe nachgefragt ob es einen Decoder gibt, der das leistet, was mir eigentlich ganz naheliegend erschien.
[quote=StephanLeist]
Stephan B. hatte ja schon erklärt, dass RC das DCC nicht betrifft, also es nicht "verbiegt", es also in jedem Fall standardkonform ist. Folglich funktioniert RC unabhängig vom hinwärtigen Protokoll, oder? Alleine ein Zentralenseitiger Cut-Out sorgt dafür, dass RC möglich ist, was für eine Multiprotokollzentrale, die RC-fähig ist, ja kein Problem darstellen sollte.
[/quote]
"Gleisprotokollseitiger Cut-Out" wäre ganz korrekt, der Cut könnte auch von einem geeigneten Booster in die von der Zentrale generierten DCC-Preambeln geschnitten werden.

MfG

vik

[Martin Lutz]

Zitat

---

Morgen Martin,

[quote="Martin Lutz" post_id=1824994 time=1524461787 user_id=124]
Das ist ja genau der Krux der Geschichte.

Wenn man ein intelligentes Rückmeldesystem nutzen kann, so sollte das für den ganzen Fuhrpark funktioneren. Nicht zuletzt historisch bedingt, habe ich alle Foromate auf der Anlage. MM1, MM2, mfx und DCC.
- Wenn, dann müsste ich ja alles umbauen und auf ein System bringen.
- Doch genau das ist ja nicht nötig, da es ja ein simples System gibt, das s88 das auf einfache Kontakte reagiert und daher unabhängig ist vom Digitalformat.

---

Moment, moment, ich verstehe, was du sagen willst, aber...
Über den S88 alleine, kannst du doch keine konkreten Dekoderinformationen bekommen. Also keine Adresse und andere Werte, auch keine einprogrammierte Daten.
[/quote]Ja, das ist mir auch klar. Nur: braucht man das wirklich?

Klar wäre es schön, wenn wenn die Lok konkret mitteilen könnte, wo sie sich gerade befindet. Aber wie gesagt, das s88 System funktioniert recht gut. WIchtig ist halt, die Software kennt auch die Startbedingungen. Also wo steht welcher Zug. Danach folgt sie dem Zug gemäss gestellter Fahrstrassen. Danach steht der Zug da wo hin sollte. Vorausgesetzt der PC stürzt dazwischen nicht ab oder die Weichen werden nicht korrekt geschaltet. ABer dafür gibt es Sicherheitskontakte, die den Zug stoppen, wenn der Sicherheitskontakt nicht in einer gewissen Zeit ausgelöst wurde.

Diese Zugsverfolgung funktioniert in der Praxis sehr gut. Auch ohne intelligente Rückmeldung, die systemabhängig ist.

Mein Wunsch wäre schon, dass es nur noch ein digitales System gäbe.

[Gleichstromer]

Für die reine Rückmeldung der Positionsbestimmung reichen ja schon einfache Railcom-fähige Funktionsdecoder aus, die zusätzlich zum vorhandenen Decoder in die Loks eingebaut werden. In der PC-Steuerung müssen dann einer Lok lediglich zwei Adressen zugewiesen werden, eine für das Fahren, die andere für die Rückmeldung.

Das dürfte immer noch günstiger sein, als sämtliche (Sound-)Decoder durch neue zu ersetzen.

[supermoee]

Zitat

---

Das dürfte immer noch günstiger sein, als sämtliche (Sound-)Decoder durch neue zu ersetzen.

---

Hallo,

wenn die Lok Platz für den Zusatzdekoder hat.........

Bei Köfs, Br 80-89 und weiteren Kleinloks wahrscheinlich nicht, besonders wenn noch ein Sounddekoder mit Lautsprecher und Pufferkondensator eingebaut sind.

Gruss

Stephan

[Martin Lutz]

Zitat

---

Für die reine Rückmeldung der Positionsbestimmung reichen ja schon einfache Railcom-fähige Funktionsdecoder aus, die zusätzlich zum vorhandenen Decoder in die Loks eingebaut werden. In der PC-Steuerung müssen dann einer Lok lediglich zwei Adressen zugewiesen werden, eine für das Fahren, die andere für die Rückmeldung.

Das dürfte immer noch günstiger sein, als sämtliche (Sound-)Decoder durch neue zu ersetzen.

---

Kann schon sein aber wozu etwas ändern wenn es für einen so funktioniert wie man es sich wünscht?

[Martin Lutz]

Zitat

---

Zitat

---

Das dürfte immer noch günstiger sein, als sämtliche (Sound-)Decoder durch neue zu ersetzen.

---

Hallo,

wenn die Lok Platz für den Zusatzdekoder hat.........

Bei Köfs, Br 80-89 und weiteren Kleinloks wahrscheinlich nicht, besonders wenn noch ein Sounddekoder mit Lautsprecher und Pufferkondensator eingebaut sind.

Gruss

Stephan

---

Na ja. Ich kenne jemanden, der sogar schon Z-Loks mit Sound ausstattet. Und bei Loks bei denen wirklich kein Platz mehr ist, tauscht man halt wirklich den Decoder aus, wenn man schon die intelligente Rückmeldung will.

[StephanLeist]

Hallo,

Zitat

---

Für die reine Rückmeldung der Positionsbestimmung reichen ja schon einfache Railcom-fähige Funktionsdecoder aus, die zusätzlich zum vorhandenen Decoder in die Loks eingebaut werden. In der PC-Steuerung müssen dann einer Lok lediglich zwei Adressen zugewiesen werden, eine für das Fahren, die andere für die Rückmeldung.

Das dürfte immer noch günstiger sein, als sämtliche (Sound-)Decoder durch neue zu ersetzen.

---

Das stimmt wohl und wäre auch eine Möglichkeit. Wenn es unabhängig vom Gleisprotokoll gehen soll muss halt trotzdem ein Cut her. Entweder durch Booster oder Zentrale wie Vikr auch meinte.
Ich habe das Glück nur Dekoder verbaut zu haben, die sowieso alle RC-fähig sind.


[quote="Martin Lutz" post_id=1825014 time=1524466552 user_id=124]
Ja, das ist mir auch klar. Nur: braucht man das wirklich?

Klar wäre es schön, wenn wenn die Lok konkret mitteilen könnte, wo sie sich gerade befindet. Aber wie gesagt, das s88 System funktioniert recht gut. WIchtig ist halt, die Software kennt auch die Startbedingungen. Also wo steht welcher Zug. Danach folgt sie dem Zug gemäss gestellter Fahrstrassen. Danach steht der Zug da wo hin sollte. Vorausgesetzt der PC stürzt dazwischen nicht ab oder die Weichen werden nicht korrekt geschaltet. ABer dafür gibt es Sicherheitskontakte, die den Zug stoppen, wenn der Sicherheitskontakt nicht in einer gewissen Zeit ausgelöst wurde.
[/quote]Die Frage, ob man das braucht, war ja schon ein paar Seiten zuvor sehr umstritten (wg. Marius' C-Digital). Ich persönlich finde es schon sinnvoll, notwenig ist immer so eine Sache, weil das ja implizieren würde, dass es ohne nicht richtig geht. Es geht aber auch ohne, auch nur mit punktueller Besetztmeldung und der Software.
Die Software ist aber nur so "schlau", so genau auch das Abbild der tatsächlichen Anlage und der Vorgänge darauf in ihr ist. Da ist es dann schon "nötig", dass sie auch weiß, welche Adresse sich wo befindet und ggf. noch was diese gerade macht.
Ohne das, bleibt die Softwaresteuerung doch nur eine recht aufwändige Simulation einer Anlage, die nicht zwingend mit der Realität übereinstimmen muss. Ganz egal wie viel "Intelligenz" ein paar Vorredner der Software alleine bereits andichten wollten, so hat sie die nur, wenn eben auch genügend Infos der "realen Welt" in ihr vorliegen.
Ich denke es stimmt schon, was hier schon einmal geschrieben wurde; ob man nun mit Software auf einem PC oder sonst einem Computer fährt, oder mit irgend einem anderen Steuerungsteil (Handregeler, Tablett, ...), so ist man zunächst immer auf die "Intelligenz" des Systems angewiesen und nicht primär auf die, die in dem "Steuerungsteil (Handregler/Software)" enthalten ist. Die Intelligenz in dem Steuerungsteil ist dann erst der 2. Schritt.
Das finde ich wäre die logische und konsequente Herangehensweise.

Eine große Schwachstelle einer Softwaresteuerung sehe ich, wenn die Software selbst einen nicht unerheblichen Teil der Informationen aus der echten Welt in sich selbst erzeugt (simuliert) und damit zu einem Teil in sich geschlossen aggiert. Bei einer Steuerungseinheit sollte sowas dringend vermieden werden.
Im forliegenden Fall lässt sich das nur bewerkstelligen, wenn die Steuerungseinheit min. weiß welche Adresse sich wo befindet, denke ich.

[quote="Martin Lutz" post_id=1825014 time=1524466552 user_id=124]
Diese Zugsverfolgung funktioniert in der Praxis sehr gut. Auch ohne intelligente Rückmeldung, die systemabhängig ist.
[/quote]Ja, verstehe ich auch, dass eine Systemabhängigkeit blöd wäre. Aber was meinst du genau mit Systemabhängig? Protokollabhängig? - Das wäre sie ja nach Vikrs Idee nicht.
Eine gewisse Systemabhängigkeit hast du trotzdem immer, weil ja zumindest ein S88 Rückmeldesystem Aufgebaut und integrierbar sein muss (ist auch fast überall möglich). Da hat man immer eine gewisse Systemabhängigkeit nur eben nicht zum Gleisprotokoll, was im obigen Fall aber auch nicht gegeben wäre.

[quote="Martin Lutz" post_id=1825014 time=1524466552 user_id=124]
Mein Wunsch wäre schon, dass es nur noch ein digitales System gäbe.
[/quote]Das wird wohl ein Wunschgedanke bleiben. Zumal es ja von einigen geradezu gefordert wird, eine möglichst breite Palette an Auswahlmöglichkeiten der Systeme zu haben (siehe Kritikpunkt an C-Digital). Der ambitionierte SX fahrer schwört darauf und wird es weiter fahren wollen ebenso wie die nicht zu unterschätzende Märklinfraktion mit MM oder mfx. Ebenso wird wohl kaum ein DCC Fahrer zu MM oder mfx wechseln. Wobei man eine Kombination aus mehreren Protokollen/Systemen schon haufiger vorfindet.

Zitat

---

"Fordern" ist sicher nicht das richtige Wort. Ich habe nachgefragt ob es einen Decoder gibt, der das leistet, was mir eigentlich ganz naheliegend erschien.

---

Alles klar. Nach allem was hier bis jetzt zu RC zusammengetragen wurde, erscheint es für mich auch naheliegend und es sollte kein Problem darstellen. Mir ist aber nicht bekannt, dass das auch bereits möglich ist und Dekoder das tatsächlich machen (können).

Freundliche Grüße,
Stephan L.

[Heinzi]

Hallo zusammen

Obwohl als mfx Fahrer ich nichts mit railcom am Hut habe trotzdem nochmals meine Wortmeldung.

Automatisch Steuerung mit Zugverfolgung erfordert ja eine Mehr oder weniger lückenlose Überwachung / Rückmeldung. Eine Anwendung für die Rückmeldung Railcom sähe ich da, wo bahnen manuell gesteuert werden, somit nicht durchgängig Rückgemeldet werden aber der Schattenbahnhof überwacht werden soll.

Und dann noch eine frage: Wie zügig meldet denn Railcom eine Lok zuverlässig rück. Ist der Zug dann nicht längst schon woanders ?

[Martin Lutz]

Zitat

---

Die Frage, ob man das braucht, war ja schon ein paar Seiten zuvor sehr umstritten (wg. Marius' C-Digital).

---

Wieso umstritten? Streitet jemand deswegen?

Zitat

---

Ich persönlich finde es schon sinnvoll,

---

Ja, genau. Für dich persönlich. Das ist ja auch gut so.

Zitat

---

notwenig ist immer so eine Sache, weil das ja implizieren würde, dass es ohne nicht richtig geht. Es geht aber auch ohne, auch nur mit punktueller Besetztmeldung und der Software.

---

Genau. Das wollte ich ja auch sagen. Daher schrieb ich, dass ICH das nicht brauche. Letztlich kann ich ja nur für mich reden/schreiben.

Zitat

---

Die Software ist aber nur so "schlau", so genau auch das Abbild der tatsächlichen Anlage und der Vorgänge darauf in ihr ist. Da ist es dann schon "nötig", dass sie auch weiß, welche Adresse sich wo befindet und ggf. noch was diese gerade macht.

---

Genau! Das ist der Punkt. Selbst bei jeder Intelligenz eine Rückmeldung. DIe Topologie der Anlage muss irgendwie sowieso mitgeteilt werden. Was nützt der Steuersoftware sonst die Info: Ahh, die Lk sowieso befindet sich gerade am Rèckmeldesensor sowieso. Aber wo ist er denn? Im Bahnhof Hintertupfingen oder am Bahnhof Blausee oder gar im Tunnel Dunkelfeld?

[Martin Lutz]

Zitat

---

Hallo zusammen

Obwohl als mfx Fahrer ich nichts mit railcom am Hut habe trotzdem nochmals meine Wortmeldung.

Automatisch Steuerung mit Zugverfolgung erfordert ja eine Mehr oder weniger lückenlose Überwachung / Rückmeldung. Eine Anwendung für die Rückmeldung Railcom sähe ich da, wo bahnen manuell gesteuert werden, somit nicht durchgängig Rückgemeldet werden aber der Schattenbahnhof überwacht werden soll.

---

Genau, da sehe auch ich den grössten Vorteil. Wenn ich mal einen Zug aus der Automatik rausnehmen möchte und von Hand fahren, dann wäre so ein intelligentes Rückmelden ganz nützlich, wenn dann der Zug am PC wieder melden kann. "Hurra lieber PC, jetzt bin ich am wieder am Gleis 1 in Zindelstein. du kannst mich jetzt wieder in deine Automatik einbinden."

Zitat

---

Und dann noch eine frage: Wie zügig meldet denn Railcom eine Lok zuverlässig rück. Ist der Zug dann nicht längst schon woanders ?

---

Da sprichst du etwas an, was wahrscheinlich das wichtigste Element der ganzen Geschichte ist. Es muss mehr oder weniger in Echtzeit geschehen. Schon wenige Sekunden Verzögerungen beim Rückmelden und das System ist für die "Tonne"

[vikr]

Zitat von Martin Lutz" post_id=1824994 time=1524461787 user_id=124]
Das ist ja genau der Krux der Geschichte.

Wenn man ein intelligentes Rückmeldesystem nutzen kann, so sollte das für den ganzen Fuhrpark funktioneren. Nicht zuletzt historisch bedingt, habe ich alle Formate auf der Anlage. MM1, MM2, mfx und DCC.
[/quote]
Ja, das ist die Ausgangssituation, in der sich die meisten Märklinfahrer befinden.
[quote="Martin Lutz

---

- Wenn, dann müsste ich ja alles umbauen und auf ein System bringen.

---

die Railcom-Rückmeldung ist weitgehend abwärtskompatibel zum klassischen DCC-System mit Stromfühlern, auch wenn die Meldung über s88 ging.
Das heißt bei den alten Fahrzeugen wird eine einfache Besetztmeldung abgesetzt bei Fahrzeugen mit RailCom-Decoder erfolgt eine qualifizierte Besetztmeldung (mit welcher Adresse besetzt).
Zu den Märklin-typischen Kontaktgleisen bzw. Masse-Belegtmeldern zwischen Masse und einer isolierten Schiene besteht keine Abwärtskompatibilität.

Zitat von Martin Lutz

---

- Doch genau das ist ja nicht nötig, da es ja ein simples System gibt, das s88 das auf einfache Kontakte reagiert und daher unabhängig ist vom Digitalformat.

---

Einfache Kontakte benötigen immer einen Kontext, den der Modellbahner mit seinen Sinnen erfasst und interpretiert. Welches Fahrzeug passiert zum Zeitpunkt T welchen Punkt X und in welcher Richtung. Dies muss vom Modellbahner manuell festgelegt werden, danach kann die Software die nächsten Fahrtmöglichkeiten eingrenzen und bei der nächsten unspezifischen Kontaktmeldung mit recht großer Wahrscheinlichkeit die Bewegung richtig anzeigen.

RailCom kann im Wesentlichen den Kontext setzen, den ansonsten der Modellbahner beim Start festlegen muss. Außerdem können die Plausibilitätskontrollen die der manuell fahrende Modellbahner beiläufig durchführt automatisch durch Auswertung (Wer, wo, wierum, wie schnell) der qualifizierten Rückmeldung mit absolviert werden.

Theoretisch wäre es möglich qualifizierte Rückmeldungen von einem geeigneten Detektor dann über S88 weiterzuleiten. Ein Versuch ist z.B. das TD88 von Littfinsky. Dabei werden zusammenhängende Bitfolgen in auf einanderfolgenden S88-Zyklen übertragen. Leider wird das kaum - insbesondere nicht von Märklin selbst - unterstützt und funktioniert auch auf Grund der Störaneinstahlungsfälligkeit von S88 nicht sehr zuverlässig.

Seit dem Erscheinen vom mfx mit der CS1, spätestens seit dem Erscheinen der CS2 - also 2007 warten Märklinbahner zumindest auf qualifizierte ortsbezogene Rückmeldung (Adresse und Ortsangabe) über mfx. Eine lokale Adressabfrage über mfx wurde in den letzten 11 Jahren nicht mal angekündigt. Es fehlt auch die Anzeigemöglichkeit eines bestimmten Fahrzeuges in den eingebauten Gleisbildstellwerken der CS2 oder CS3, was die ECoS allerdings über RailCom seit vielen Jahren kann.

MfG

vik

[Ulf325]

Zitat

---

Automatisch Steuerung mit Zugverfolgung erfordert ja eine Mehr oder weniger lückenlose Überwachung / Rückmeldung. Eine Anwendung für die Rückmeldung Railcom sähe ich da, wo bahnen manuell gesteuert werden, somit nicht durchgängig Rückgemeldet werden aber der Schattenbahnhof überwacht werden soll.

---

Genau das ist der Grund warum ich Railcom benutze. Ich kann beliebig Züge verfahren wie ich will und habe immer die korrekte Rückmeldung welcher Zug gerade wo steht. Inzwischen funktioniert das sogar so gut, daß ich (mit Rocrail) direkt danach die Automatik starten kann und alles funktioniert wieder.

Zitat

---

Und dann noch eine frage: Wie zügig meldet denn Railcom eine Lok zuverlässig rück. Ist der Zug dann nicht längst schon woanders ?

---

Meine (Blücher-) Melder brauchen ca 1 Sekunde um die Loknummer zu erkennen. Die Bausteine sind aber mit einem Stromfühler kombiniert, der quasi sofort (also so schnell wie jeder andere GBM auch) meldet. Ich bekomme also zwei Signale: Erst das "Enter" Signal vom GBM, dann das "Ident" Signal mit der Loknummer vom Railcom.

[3047]

Zitat von Gast im Beitrag Mfx und DCC

---

[quote="egon II" post_id=1815569 time=1522310874 user_id=29917]
Kann man das nicht ganz einfach zusammenfassen?
Man kann sich für ein proprietäres Protokoll (mfx...) oder für ein internationales (DCC) entscheiden.
Pickelbahner bevorzugen das eine 2L Fahrer das andere.

---

Nein, kann man nicht, weil es nicht stimmt!

Ich fahre Mittelleiter (Pickelbahn habe ich nicht im Handel gefunden, werde ich aber mal Ausschau nach halten) und bevorzuge DCC zum Fahren und mfx zum Programmieren, habe eine Märklin CS2 und mehrere MS2.
[/quote]

Kann doch Jeder machen wie er will. Für mich gesehen wäre das manuelle Anlegen einer Lok in der CS2 schlimmer als zum Zahnarzt gehen - undenkbar ohne MFX für mich.

Es läuft mit MFX genau so ab wie ich es mir wünsche. Lok aufs Gleis stellen, zurück lehnen, warten bis sie eingelesen ist, die Lok erscheint sofort in der Lokliste an erster Stelle, und losfahren. Manuell anlegen wäre für mich Schwerstarbeit. Ich meine, in der CS2 sei die neue Lok auch gleich am Fahrregler gewesen, das vermisse ich in der CS3 tatsächlich. Ich trauere dem Bedienfeld der CS2 nach, das der CS3 mag auf den ersten Blick futuristisch erscheinen, ich meine es war ein Rückschritt, ohne Maus gar nicht zu bedienen, und ständig muss man die Fenster verkleinern oder vergrößern, um von der Bedienung der loks zur Bedienung der Magnetartikel zu wechseln, weil Teile der Fenster verdeckt wurden, usw.

Trotzdem plädiere ich für die CS3, weil sie ganz einfach die schnellste Zentrale ist die ich kenne, kein Vergleich zur lahmen CS2. Klar, die Software wird dicker und fetter, kennt man von WINDOOF, und irgendwann lahmt die Hardware so stark dass es keinen Spass mehr macht.

Ansonsten hält auch DCC in der Märklin Welt Einzug. z.B. beim Programmieren der Magnetartikel usw., wird heute schon im Märklin Magazin angeraten DCC zu verwenden.

Wenn Railcom Plus nicht so viele Macken hätte, und ein einheitlicher Standard wäre, könnte ich mir vorstellen dass Märklin diesen einmal unterstützt, aber so lange MFX das eh schon besser leistet, warum sollte man hier Geld vergeuden.

[Gleichstromer]

Zitat

---

Für mich gesehen wäre das manuelle Anlegen einer Lok in der CS2 schlimmer als zum Zahnarzt gehen - undenkbar ohne MFX für mich.

---

Daher, und da ich auch am liebsten mit MFX die Loks programmiere, fände ich es sehr praktisch, wenn man das Protokoll einer in der CS2 angelegten Lok wechseln könnte, also Lok mit mfx anlegen und ggf. einrichten, wenn alles stimmt, das Protokoll zu DCC ändeen und Lokkarte schreiben, Decoder fix auf DCC umstellen.

[vikr]

Hallo Heinzi,

Zitat

---

Obwohl als mfx Fahrer ich nichts mit railcom am Hut habe trotzdem nochmals meine Wortmeldung.

Und dann noch eine frage: Wie zügig meldet denn Railcom eine Lok zuverlässig rück. Ist der Zug dann nicht längst schon woanders ?

---

Du hast - wenn man Deinem Footer folgt - gute Voraussetzungen das auszuprobieren. Du benötigst als Besitzer einet CS1reloaded lediglich einen ECoSDetector Railcom und einen Booster, der in der Lage ist den Cut zu erzeugen, z.B. den Tams B3 in der Version mit RailCom.

Dann kannst Du Dir die RailCom Meldungen, die Loknamen im Gleisbild der CS1 ansehen. Wenn Du noch ein Modellbahnsteuerprogramm an der CS1 reloaded hast kannst Du auch dort verarbeiten und sehen wie lange es dauert.

MfG

vik

[vikr]

Hallo Heinzi,

Zitat

---

Obwohl als mfx Fahrer ich nichts mit railcom am Hut habe trotzdem nochmals meine Wortmeldung.

Und dann noch eine frage: Wie zügig meldet denn Railcom eine Lok zuverlässig rück. Ist der Zug dann nicht längst schon woanders ?

---

Du hast - wenn man Deinem Footer folgt - gute Voraussetzungen das auszuprobieren. Du benötigst als Besitzer einer CS1reloaded lediglich einen ECoSDetector Railcom und einen Booster, der in der Lage ist den Cut zu erzeugen, z.B. den Tams B3 in der Version mit RailCom.

Dann kannst Du Dir die RailCom Meldungen, die Loknamen im Gleisbild der CS1 ansehen. Wenn Du noch ein Modellbahnsteuerprogramm an der CS1 reloaded hast kannst Du sie auch dort verarbeiten und sehen wie lange es dauert.

MfG

vik