Hallo User,
plage mich weiter mit dem Thema Railcom obwohl ich dieses Thema erst einmal beiseite schieben wollte.
Hardware DCC Fahrsignale von der FCC über drei Booster (D&H), alle Rückmelder von Fichtelbahn GBM16TS.
Alle Loks von der Moba genommen und um nach Testung und erneutem Einfahren der Loks diese wieder aufzugleisen. Habe dabei trotz aller eingetretenen Stabilität hinsichtlich der Railcom-Infos folgendes beobachtet: Lok fährt per Fahrstrasse vom Startpunkt zum Zielpunkt über mehrere Faz und keiner Kehrschleife, alles Korrekt, erst bei der zweiten Fahrt passiert am Ziel folgendes: bei Ankunft Richtungswechsel im FAZ, obwohl bei Ankunft am Ziel Fahrtrichtung korrekt angezeigt wird, und erst mit Halt die Fahrtrichtung wechselt.
Bei allem was ich inzwischen zum Thema Railcom gelernt habe, so finde ich hier keinen Erklärungsansatz. Kann mir hier im Forum jemand auf die "Spur" helfen?
Vorab Dank vom Niederrhein, Achim
Hallo Achim, ist bei mir auch so! Habe Railcom abgeschaltet und nun bleibt die Fahrtrichtung so wie es soll! Kann am Booster liegen oder am Lokdecoder. Grüße Ingo
Hallo Achim,
Entweder ist für den Zielanschnitt die Richtungsanzeige bei Fahrzeugerkennung via Railcom verkehrt herum konfiguriert oder grundsätzlich für die Lok halt. Muss du experimentell ggf im Vergleich mit weiteren Fahrzeugen ermitteln
Grüße
Markus
Hallo Ingo,
Hallo Markus,
ja Ingo war auch mein kürzlicher Gedanke, jedoch wollte und will ich noch nicht einsehen das Railcom bei mir nicht funktionieren will. Gebe noch nicht auf, am Ende kann es auf das Abschalten hinauslaufen.
Das beschriebene Zielfaz kann seit Jahren nur in einer Richtung ausgefahren werden, denn dahinter lauert schon der nächste Erzzug. Die derzeitigen decoder der Firmen D&H, ESU und Zimo sind vor dem erneuten Aufgleisen der leergefahrenen Moba mit neuer Firmware aktualisiert worden.
Auch habe ich bei drei wieder in Betrieb genommenen Lok folgendes beobachtet: beim hochfahren von Windigipet werden drei Loks zwar auf den Faz gemeldet jedoch wird das Feld nicht mit der entsprechenden Lok ausgefüllt. Erst nach dembetätigen einer Funktion der entsprechenden Lok wird diese dann korrekt mittels Railcomsignal angezeigt !?
Auch die Signalauswertung unter dem Punkt Überwachung in Windigipet gibt keine Hinweise, hier liegt beinah alles im grünen Bereich, eine Zone zeigt nur mildes Grün.
Ich weiss das hier kein speziefisches Problem vorliegt, dachte das die User möglicherweise ähnliche Erfahrungen mit Railcom haben u. am Ende dann Railcom einzustampfen. Selbst das , Ingo wäre am Ende auch eine Lösung.
Guten Abend, achim
Hallo Achim
Zitat von: achim schuetzendorf in 24. April 2025, 20:40:56beim hochfahren von Windigipet werden drei Loks zwar auf den Faz gemeldet jedoch wird das Feld nicht mit der entsprechenden Lok ausgefüllt.
welche Decoder haben diese Loks eingebaut?
MfG
vik
Hallo Vik,
kann ich jetzt nicht mehr nachvollziehen ausser das die grössten Ärgenisse bereiten bei mir die aktuellen MS Zimos trotz aktuellster Firmware.
grüsse, Achim
Zitat von: achim schuetzendorf in 24. April 2025, 20:40:56Ich weiss das hier kein speziefisches Problem vorliegt, dachte das die User möglicherweise ähnliche Erfahrungen mit Railcom haben u. am Ende dann Railcom einzustampfen. Selbst das , Ingo wäre am Ende auch eine Lösung.
Guten Abend, achim
Ich kann mich damit gut identifizieren.
Railcom ist für mich nur noch für POM geeignet.
Für den Rest ist es ausgeschaltet.
Ich verwende nur Zimo-Decoder, daher dachte ich zunächst an ein isoliertes Problem.
Aber es ist viel umfassender, als ich dachte.
Auch Esu- und Imperium-Decoder weisen ähnliche Probleme auf.
Bei Spurweite 0 und größer ist die Störungswahrscheinlichkeit deutlich höher.
Dies liegt an der Signalübertragung und dem Datenempfang eines lokalen Railcom-Empfängers.
Das ist im Datenprotokoll von Windigipet sehr gut zu sehen.
Die Stromerkennung eines Standorts ist ausgeschaltet, es gibt jedoch eine Railcom-Meldung an diesem Standort. Ist es Teil der Strecke, stoppt alles.
DCC arbeitet im Hochfrequenzbereich von durchschnittlich 6,8 kHz.
Auf einem Digiscoop mit einem DCC-Datenanalysator kann ein vollständiger DCC-Befehlssatz von einem parallel liegenden Messingstab in 7 cm Entfernung von einem an ein DCC-System angeschlossenen Schienenstück (40 cm) gelesen werden.
Da es sich hier um HF handelt, ist dies technisch nicht mehr zu lösen.
Feldstärkemessungen zeigen, dass die Übertragung bis zu 40 cm von der Quelle entfernt messbar ist.
Vermutlich ist dies der Grund, warum RFID-Techniken in Großbritannien wieder aus der Versenkung geholt werden.
Dabei liegt der Tag zwischen den Schienen und die Leseeinheit befindet sich in der fahrenden Lok neben dem DCC-Decoder.
Der fahrende RFID-Sender kommuniziert entweder über Bluetooth oder WLAN mit der Schnittstelle.
Problem gelöst. Railcom ist ebenfalls noch verfügbar, jedoch nur für POM.
Kind regards
Rupert
Hallo Foristen,
Bin mit meinen zuvorgenannten Problemen etwas weiter nachdem ich die Hardware komplett auf Readybooster und GBM, also mit reinen Fichtelbahn Bausteinen, umgerüstet habe. Die "alte" Selektrix Hardware ist zunächst beiseite geräumt und ich habe bessere und sinnvollere Ergebnisse erhalten.
Nun habe ich aber ein Phänomen das ich nicht genau zuordnen kann: Im Lokcontroll gibt es links neben dem Windigipet-Quadrat ein i im Kreis das bei Railcomverbindung aktiv ist.
Jetzt ist es so das bei Mobastart alle ! Loks ohne aktivem Symbol starten, erst mit dem programmieren z.B. mit CV29, ist das Symbol wieder aktiv, auch während der ganzen Mobasitzung.
Die Frage die sich mir stellt, was zeigt das Symbol an und woraum wird hier von seiten der Elektronik, bzw. des Windigipet Programmes reagiert. ?.
Dumme Frage? keine Ahnung...................
Grüsse vom Niederrhein, Achim
Hallo Achim,
das "i"-Symbol enthält Informationen zum Fahrzeug, wenn es aktiv ist. Das muß nichts mit Railcom zu tun haben. Bewege die Maus auf das "i" und im Tooltip werden die Infos angezeigt.
Hallo Sven,
Okay, komme nur deswegen auf Railcom, wenn aktives "i", wird diverses wie Spannung, Geschwindigkeit etc angezeigt und ich hatte dies Infos Railcom zugeordnet.
Aber warum ist das "i" nicht schon beim Start der Moba aktiv? Also sobald das Gesamtsystem Windigipet und die kompletten Hardware hochgefahren ist?
Grüsse,Achim
Hallo Achim,
Weil die Decoder diese Infos per Railcom nur von Zeit zu Zeit übertragen und solange die nichts gesendet haben, gibt es da noch keine Infos.
Grüße
Markus
Hallo Markus,
danke für die Erläuterung. Habe anhand Deiner Erklärung in einem anderen Forumsbeitrag ein Macro und per Stellwerkfunktion alle Loks beim Start von Windigipet einmal alke Spitzenlichter aus- und einschalten lassen. Problem gelöst.
Danke und ein schönes Wochende, Achim
Hallo Markus,
Zitat von: Markus Herzog in 04. Juni 2025, 22:09:52Weil die Decoder diese Infos per Railcom nur von Zeit zu Zeit übertragen und solange die nichts gesendet haben, gibt es da noch keine Infos.
ist das Detektieren der Aufgleisrichtung (vorausgesetzt das Fahrzeug mit dem Railcom Decoder ist korrekt nach Norm verdrahtet) nicht eine Funktion des lokalen Detektors (unter Berücksichtigung der aktuellen DCC-Polarisierung im Rückmeldeabschnitt)? Wenn Kanal 1 permanent eingeschaltet ist, erhält der Detektor sehr engmaschig die Adresse und stellt die Information auch laufend zur Verfügung. Spannend ist das allerdings, wenn sich der Railcom-Detektor in einen Kehrschleifenabschnitt befindet und dort die Polarisierung umgeschaltet werden muss. Falls das Programm die Kehrschleifenumschaltung nicht zeitnah mitbekommt, werden die Daten dort falsch interpretiert und kollidieren mit den im Programm gespeicherten Informationen.
Wie können (auch im Automatikbetrieb) die Daten synchronisiert werden, bzw. wie sollte man vorgehen um die unterschiedliche Informationslage aufzulösen (ohne explizit manuell einzugreifen)?
MfG
vik
Hallo vikr,
in der Userfrage auf die sich mein Zitat bezog, ging es nicht um die Aufgleisrichtung, sondern um Dinge die QoS-Meldung und weitere Meldungen, die der Dekoder von Zeit zu Zeit absondert. Also Kanal 2 Daten.
Mit Glück gelingt es wie Achim schon schrieb über Licht aus/an den Dekoder dazu zu bringen die Infos nochmal zu senden. Ich habe aber auch schon Dekoder gesehen, die solange keine Wertänderung eintrat zig Minuten brauchten ehe sie sich (wenn überhaupt) nochmal geäußert haben.
Zu der Thematik Kehrschleife und Aufgleisrichtung: WDP hat hier keinerlei Verfahren implementiert für "Oh da ist eine Kehrschleife" umgeschaltet und interpretiere die gemeldete Aufgleisrichtung umgekehrt. Zumal wie schon von dir korrekt bemerkt man jetzt auch noch wissen müsste bei jeder Richtungsmeldung "War schon umgeschaltet oder nicht". Hier wäre mein Erwartungshaltung an die Hardware-Hersteller, dass man dem Kunden ein Kehrschleifenmodul anbietet mit Railcom-Detektor, der egal wie rum die Kehrschleife "steht" das korrekt an den PC oder andere Mithörer meldet. Meiner Meinung nach ist das in Hardware zu lösen, denn selbst wenn das ein PC kann... Sollen das dann lokale Railcom-Displays oder Handregler auch alle auflösen können?
Und ehe die Frage kommt: Keine Ahnung ob es so eine Hardware schon gibt, damit habe ich mich noch nie befasst.
Beim schnellen Googeln habe ich Hinweise gefunden nach dem Motto: "Schalte einen Einzel-Railcom-Detektor zwischen Kehrschleifenausgang und Gleis", klingt auch noch einer Idee, ohne das jetzt komplett durchdacht zu haben...
Grüße
Markus
Hallo Rupert,
Zitat von: Rupert van Swol in 02. Mai 2025, 08:34:48Railcom ist für mich nur noch für POM geeignet.
Für den Rest ist es ausgeschaltet.
Ich verwende nur Zimo-Decoder, daher dachte ich zunächst an ein isoliertes Problem.
Aber es ist viel umfassender, als ich dachte.
Auch Esu- und Imperium-Decoder weisen ähnliche Probleme auf.
...
Problem gelöst. Railcom ist ebenfalls noch verfügbar, jedoch nur für POM.
Kind regards
Rupert
vor gerade mal zwei Jahren warst Du sehr enthusiastisch vom Gegenteil überzeugt...
Zitat von: Rupert van Swol in 25. Mai 2023, 09:45:15Ich habe mich 2022 von der Lenz Spur 0 und dem System verabschiedet, da ich nach 40 Jahren bereit für etwas anderes war.
Ich bin dann bei Lokstore digital gelandet, von denen ich alles habe.
Spur-0-Lokomotiven aus Großbritannien sind defacto mit Zimo ausgestattet.
Warum Zimo und nicht Lenz
ZIMO Decoder aller Typen (sowie Digitalzentralen und Gleis-Rückmelder als Empfangsgeräte) waren schon seit den 1990er Jahren (lange vor RailCom) mit einer proprietären Form der ,,bi-directional communication" ausgestattet - der ,,ZIMO Zugnummernerkennung". Dies war damals ein wesentlicher Unterschied zu Produkten des Mitbewerbs.
In Anlagen mit den bis 2010 gebauten MX9 Gleisabschnitts-Modulen wird weiterhin die ZIMO Zugnummernerkennung verwendet, da MX9-Module NICHT mit ,,RailCom" arbeiten (die nachfolgenden ,,StEin"-Module hingegen schon).
Seit dem Jahr 2005 (kurz nach der Einführung durch die Fa. Lenz) sind alle ZIMO Decoder ausgestattet
für das in der Zwischenzeit genormte Rückmeldeprotokoll ,,RailCom" (RCN-217 bei RailCommunity -
VHDM - und S-9.3.2 bei NMRA).
RailCom ersetzt auch die oben erwähnte ZIMO Zugnummernkennung.
Die grundsätzliche Funktionsweise von RailCom beruht darauf, dass der ansonsten kontinuierliche Energie- und Datenstrom, also das DCC - Schienensignal, welches von der Digitalzentrale auf die Schiene gelegt wird, von kurzen potenzial-freien Lücken (die "RailCom-Cutouts", max. 500 microsec) unterbrochen wird; in diesen Lücken können die Decoder weitgehend ungestört Rückmelde-Informationen (als ,,RailCom-Nachrichten", insgesamt - beide Channels
zusammen - bis zu 48 bit lang) aussenden, welche von ,,lokalen Detektoren" (einzelnen isolierten Gleisabschnitten zugeordnet) oder vom globalen Detektor in der Digitalzentrale selbst empfangen und ausgewertet werden.
n ZIMO Decodern (mittlerweile auch in den meisten Fremdprodukten) sind die RailCom-Funktionen
standardmäßig eingeschaltet; wenn dies nicht der Fall sein sollte, werden sie aktiviert durch:
CV #29, Bit 3 = 1 UND CV #28 = 3 (oder = 67, wenn Großbahn-Decoder),
falls die Geschwindigkeits-Rückmeldung (Tacho) nicht funktionieren sollte: CV #158, Bit 2 = 1 oder ausnahmsweise (falls MX31ZL als Zentrale): = 0
In den ersten Jahren nach Einführung von RailCom wurde dessen Potenzial nur für zwei Möglichkeiten
intensiv genutzt: zur Adress-Meldung für isolierte Gleisabschnitte (das, was zuvor die ZIMO Zugnummernerkennung geleistet hat), sowie zum CV-Programmieren und -Lesen im Operational Mode (auch
,,Programming-on-the-Main" oder ,,PoM" genannt). Dies hat sich - etwa seit dem Jahr 2015 - geändert:
Kurz zusammengefasst können die RailCom-Aufgaben so gegliedert werden:
Durch sämtliche RailCom-Antworten (zunächst unabhängig vom Inhalt der Nachricht selbst) wird
der Empfang der jeweils vorangehenden DCC-Befehle bestätigt, was die Betriebssicherheit und
die Bandbreite der gesamten DCC-Steuerung erhöht. Letzteres ist der Fall, weil quittierte DCCBefehle nicht wiederholt werden müssen.
,,RailCom Channel 2" (der jeweils zweite - mit 36 Bit größere Teil - jeder RailComGesamtnachricht): Darüber werden, jeweils als Antwort auf einen DCC-Befehl an die eigene Decoder-Adresse, aktuelle Daten aus dem Fahrzeug zum globalen Detektor der Digitalzentrale gemeldet; dazu gehören beispielsweise (je nach Auslegung) die "echte" (gemessene) Geschwindigkeit,
Routing- und Positions-Codes, simulierte "Treibstoffvorräte", aktuelle Werte der CVs auf Anfrage
(CV-Programmieren und -Lesen im Operational Mode, PoM)
,,RailCom Channel 1" (der jeweils erste - kleinere Teil mit 12 Bit): Darüber wird (mit Ausnahmen,
z. B. in Anmeldeverfahren) ausschließlich die eigene Decoder-Adresse gemeldet, und zwar als
Antwort auf sämtliche DCC-Befehle (also vor allem auf diejenigen, die NICHT das eigene Fahrzeug
adressieren, daher bis zu 100 Mal/sec). Da somit alle Decoder gleichzeitig Channel 1-Daten aussenden, sind diese nur auf isolierten Gleisabschnitten durch lokale Detektoren lesbar, wenn sich
dort gerade nur ein einziges Fahrzeug mit RailCom-aktiviertem Decoder befindet.
Im globalen Detektor des Basisgerätes überlagern sich hingegen die gleichzeitigen Channel 1-Daten der verschiedenen Decoder und sind daher nicht lesbar, was aber sowieso keinen Sinn hätte, da die Adressen nur lokal
(auf den einzelnen isolierten Gleisabschnitten) von Interesse sind.
Die obige ,,Kurzbeschreibung" der RailCom-Technik bezieht sich nur auf die ,,normalen" Vorgänge; es gibt in der
Praxis (auch in den Normen selbst) zahlreiche Abweichungen und Ausnahmen in den Channel-Zuteilungen, u.a.
Weiterentwicklung der RailCom-Nutzung:
Da laufend neue RailCom-Anwendungen geschaffen und in Decodern und Digitalgeräten implementiert werden, wobei ZIMO häufig eine Vorreiter-Rolle einnimmt, können Betriebsanleitungen diesbezüglich nicht immer aktuell gehalten werden.
Daher gibt es hier nur eine kurze Auflistung von Anwendungen und ins Auge gefassten Anwendungen,
die entweder schon realisiert wurden (je nachdem, wann dieser Text gelesen wird), gerade in Arbeit
sind, oder vielleicht in näherer Zukunft realisiert werden (in ZIMO Decodern und Systemen):
Klassische Anwendungen
Diese werden von vielen modernen Digitalzentralen verwendet (Geschwindigkeitsanzeige noch selten).
- Adress-Meldung (zur Anzeige auf Ziffernanzeigen oder Computer-Stellwerk),
- CV-Programmieren und -Lesen, Geschwindigkeits-Meldung (zur Tacho-Anzeige am Bediengerät),.
Erweitere Meldungen aus den Fahrzeugen
Diese werden derzeit hauptsächlich von ZIMO Digitalzentralen und Bediengeräten ausgewertet.
Stand SW-Version 4.210:
- Richtungszustands-Meldung (zur Anzeige Vor-/Rückwärts sowie Ost-West-Richtung am Bediengerät
und automatische Steuerungseingriffe); gemäß RailCommunity-Norm: ID7, Sub-ID 27,
- ZIMO Aufgleissuche; gemäß RailCommunity-Norm: ID1, ID2, ID14 (nach Aufforderung auf Adresse 0),
- Quality-of-Service-Meldung, gemäß RailCommunity-Norm: ID7, Sub-ID 7,
- Gleisspannung am Ort des Decoders; gemäß RailCommunity-Norm: ID7, Sub-ID 46.
Geplant:
HLU&ABC-Meldungen (zur Anzeige am Bediengerät und automatische Steuerungseingriffe), Zielentfernung und Zielgeschwindigkeit (zur Anzeige auf ,,Echt"-Führerständen), zurückgelegte Wegstrecken,
Steigungen, Gefälle, Kurven (Decoder mit Sensoren), Höhendifferenzen, Drehwinkel, Streckenprofile,
aktuelle Position, Decoder-bezogene Daten (Motorstrom, Temperatur, ...).
Geplante betriebliche Anwendungen
Diese sind bis auf weiteres nur innerhalb von ZIMO Systemen verfügbar.
Übermittlung größerer Datenmengen aus den Fahrzeugen und Zügen, beispielsweise GUI (GraphicalUser-Interface) aus dem Fahrzeug zu den Bediengeräten), Streckenprofil oder Vorbild-Gewichte und -
Masse der Wagen eines Zuges, Textnachrichten aus dem Zug zur Anzeige am Bediengerät.
die Railcom-Kommunikation schien für Dich komplett beherrschbar zu sein...
Jede Technik hat ihre Grenzen, aber wenn man die kennt, kann man sie sehr gut nutzen.
MfG
vik
Hallo Markus,
Zitat von: Markus Herzog in 11. Juni 2025, 13:19:11Zu der Thematik Kehrschleife und Aufgleisrichtung: WDP hat hier keinerlei Verfahren implementiert für "Oh da ist eine Kehrschleife" umgeschaltet und interpretiere die gemeldete Aufgleisrichtung umgekehrt. Zumal wie schon von dir korrekt bemerkt man jetzt auch noch wissen müsste bei jeder Richtungsmeldung "War schon umgeschaltet oder nicht". Hier wäre mein Erwartungshaltung an die Hardware-Hersteller, dass man dem Kunden ein Kehrschleifenmodul anbietet mit Railcom-Detektor, der egal wie rum die Kehrschleife "steht" das korrekt an den PC oder andere Mithörer meldet. Meiner Meinung nach ist das in Hardware zu lösen, denn selbst wenn das ein PC kann...
OK, das wurde die dezidierte Hardware (RailCom-Detektor) natürlich nochmals teurer machen. Im PC wäre es dagegen eine Softwarelösung.
Zitat von: Markus Herzog in 11. Juni 2025, 13:19:11Sollen das dann lokale Railcom-Displays oder Handregler auch alle auflösen können?
Es handelt sich in erster Linie um ein organistorisches Problem, man muss eine Grundstellung für jeden Eingebauten Dezektorabschnitt vereinbaren und natürlich, im Moment der Kehrschleifenumschaltung, das Steuerungssystem über die Umkehrung der Bedeutung für die betroffenen Abschnitte und RailCom-Detektoren informieren. Falls sich dort schon Fahrzeuge befanden muss die Logik für die Interpretation der Railcom-Nachrichten aller dieser Fahrzeuge angepasst werden.
Falls das nicht, oder nicht rechtzeitig passiert, wird das Steuerprogramm falsch informiert und trifft u.U. falsche Entscheidungen, z.B. in welche Richtung der Fahrzeugmotor vom Decoder gedreht werden muss, damit das Fahrzeug das Gleis in der gewünschten Verkehrsrichtung verlässt.
WDP beherrscht das auch ohne die Nutzung von Railcom, d.h. man kann - insbesondere im Automatikbetrieb - auch einfach auf Railcom verzichten.
Eine inkorrekte Interpretation der eigentlich richtigen (Railcom)-Messdaten, einfach nur der Hardware anzulasten, obwohl man bei der Messung gar nicht alle Rahmenbedingungen erfasst, darf man aber vielleicht doch kritisieren. Wobei ich keineswegs behaupte, dass es einfach sei, das alles beim Programmieren umfassend zu berücksichtigen.
MfG
vik
Hallo vikr,
wie so oft im Leben: man kann es so oder so sehen. Und wir bügeln schon ständig Unzulänglichkeiten der Hardware aus und man immer mal wieder entscheiden wie weit man dabei geht. Das möchte ich jetzt aus Zeitgründen aber auch nicht weiter diskutieren, denn die WDP-Programmarbeit ruft.
Grüße
Markus
Hallo Markus,
Zitat von: Markus Herzog in 13. Juni 2025, 01:20:42wie so oft im Leben: man kann es so oder so sehen.
ja, das ist häufig Geschmackssache...
Zitat von: Markus Herzog in 13. Juni 2025, 01:20:42wir bügeln schon ständig Unzulänglichkeiten der Hardware aus und man immer mal wieder entscheiden wie weit man dabei geht.
aber physikalische Gesetzmäßigkeiten in Raum und Zeit als Unzulänglichkeiten der aktuell eingesetzten Hardware einzuordnen, führt letzlich nicht wirklich zur Lösung solcher Probleme. Das hat - nicht zuletzt - die Geschichte Gallileis gezeigt. ;-)
MfG
vik
Hallo Markus,
Zitat von: Markus Herzog in 13. Juni 2025, 01:20:42wie so oft im Leben: man kann es so oder so sehen.
ja, das ist häufig Geschmackssache...
Zitat von: Markus Herzog in 13. Juni 2025, 01:20:42wir bügeln schon ständig Unzulänglichkeiten der Hardware aus und man immer mal wieder entscheiden wie weit man dabei geht.
aber physikalische Gesetzmäßigkeiten in Raum und Zeit als Unzulänglichkeiten der aktuell eingesetzten Hardware einzuordnen, führt nicht wirklich zur Auflösung solcher Probleme. Das hat - nicht zuletzt - die Geschichte Gallileis gezeigt. ;-)
MfG
vik
Hallo Vik,
So wie ich das sehe, wird die Railcom-Funktionalität zunehmend zu einer markenabhängigen Angelegenheit.
Wenn Sie nur Zimo-Decoder haben, werden Sie mit einem vollständigen Zimo-System kaum Probleme haben.
Wenn Sie zu einem ,,freien System" wie BidiB oder LoDi wechseln, kann es bei einer hohen Melderdichte zu Nebenwirkungen in diesem System kommen, die sich negativ auf die Zugüberwachung auswirken.
Als Nutzer bin ich damit nicht allein, und ich beschränke mich hier auf die Niederlande.
Aber wir werden sehen, wie sich die RFID-Technik über Wifi und einen MQTT-Broker in Windigipet 2025 bewährt. :)
Viel Spaß mit Railcom, wie ich bereits geschrieben habe: POM Only :)
https://www.youtube.com/shorts/DD0P9evUxHU?feature=share
https://www.youtube.com/shorts/yWMozA1jOe8?feature=share
https://www.youtube.com/shorts/FVqqeegwd1g?feature=share
Rupert
Hallo Rupert,
Zitat von: Rupert van Swol in 13. Juni 2025, 17:39:57So wie ich das sehe, wird die Railcom-Funktionalität zunehmend zu einer markenabhängigen Angelegenheit.
ja, das ist wohl so und auf einen gemeinsamen Nenner oder/und Abwärtskompatibikität wird wenig Wert gelegt.
Angefangen hat aber schon 2007 mit Zimos erstem Ausscheiden aus der Railcom-Arbeitsgruppe...
Wie Du aber schon schreibst, kann man mit einer Lösung von nur einem Hersteller, wie z.B. mit der ECoS und den unverhältnismäßig teuren ECoS-Detektoren, aber zeigen, dass Railcom prinzipiell konsistent funktioniert. Läßt man mit diesem System dann aber komplexere Automatikabläufe per WDP steuern, gibt es dann aber plötzlich unerklärliche Phänomene.
Natürlich kann man die dann einfach beseitigen in dem man Railcom abschaltet...
Daraus zu folgern, dass Railcom Schuld war, scheint mir aber doch etwas zu kurz gegriffen.
MfG
vik
Daraus zu folgern, dass Railcom Schuld war, scheint mir aber doch etwas zu kurz gegriffen.
Hallo Vikr,
Und das stimmt.
Railcom bietet viele Vorteile, wie in meinem Fall mit dem fantastischen WDP-Steuerungsprogramm, das die Zugerkennung ermöglicht, wenn ein Zug falsch abbiegt und auf das falsche Gleis fährt, und das sofort von WDP gestoppt wird.
Warum viele Hersteller Railcom so eng abschirmen und dies trotz des NMRA-Standards normieren?.
Die positiven Aspekte von Railcom haben sich also bewährt.
Mit freundlichen Grüßen,
Jan Stienstra
Hallo Zusammen,
im FAZ gibt es für die automatische Erkennung der Fahrtrichtung noch eine
Option "Erkannte Fahrtrichtung invertieren". Ist das Gleisbild, wie bei meiner Demo-Anlage, als Kreis dargestellt, gibt es immer FAZ, wo diese Option aktiviert werden muss, sonnst wird die Lök bei Ankunft im FAZ gewendet. Siehe Bilder im Anhang. Wer sich nicht sicher ist, einfach Lok mit Railcom auf dem FAZ mit Rilcom-Erkennung aufgleisen, im FAZ schauen ob die Richtung stimmt, wenn ja, ist alles in Ordnug, wenn nicht , dann den Haken bei "Erkannte Fahrtrichtung invertieren" setzen!
Mi freundlichen Grüßen
Dirk
Hallo Dirk,
Zitat von: Dirk Streuber in 16. Juni 2025, 16:35:06Ist das Gleisbild, wie bei meiner Demo-Anlage, als Kreis dargestellt, gibt es immer FAZ, wo diese Option aktiviert werden muss, sonnst wird die Lök bei Ankunft im FAZ gewendet. Siehe Bilder im Anhang.
bei solch einem Gleisbild darf das eigentlich niemals passieren, wenn die lokalen RailCom-Detektoren (und natürlich die Lokdecoder) korrekt verdrahtet und korrekt konfiguriert sind. Am vorderen Anlagenrand gibt es die Verkehrsrichtung von West nach Ost, d.h. auf der Anlage gegen den Uhrzeigersinn. Die zum Anlagenrand hin liegende Schiene jedes Gleises ist dann DCC1, die zur Anlagenmitte liegende Schiene aller Gleise ist DCC2.
Alle isolierten Detektor-Abschnitte müssen dann in der jeweils äußeren Schiene der Gleise liegen.
wenn eine Lok mit dem Schornstein Richtung Ost, am vorderen Anlagenrand aufgegleist wird und immer nur vorwärts (dem Schornstein hinterher) fährt, sollte die Fahrtrichtung auf keinem FAZ geändert angezeigt werden.
Falls natürlich der Modellbahner die Lok vom Gleis abhebt und sie um 180° gedreht wieder aufsetzt, ändert sich die Aufgleisrichtung und gleichzeitig die Verkehrsrichtung. Die Drehrichtung des Motors und damit auch Fahrtrichtung der Lok (dem Schornstein hinterher) bleiben gleich und im FAZ muss natürlich die Verkehrsrichtung aktualisiert und die Entgegengesetzte angezeigt werden.
Vergleichbares muss auch passieren wenn - aus betrieblichen Gründen - z.B. zur Vermeidung eines Kurzschlusses - in einer Kehrschleife, in einem Abschnitt oder ganzem Anlagenteil, DCC1 und DCC2 vertauscht werden müssen. Das Steuerprogramm muss von dieser Umschaltung sofort erfahren und ggf. alle abhängen Informationen anpassen, i.d. R. invertieren.
Herr Jürgen Gräbner hatte das hier vor vielen Jahren bereits dezidiert ausgearbeitet.
MfG
vik
Hallo RailComer,
die "Lenzsche Regel für RailCom lautet: "Rot ist Rechts und Richtig". Bedeutet daß das DCC-Signal so aufgelegt werden muß, daß der Lokdecoder mit dem Roten Draht auf der Rechten Schiene immer nach vorne fährt.
Demzufolge muß erst mal vom Hersteller der Decoder auch so installiert sein und auch der Motoranschluß so gewählt werden, daß dieser so dreht, daß die Lok vorwärts fährt.
Hallo Vik,
Zitat von: vikr in 16. Juni 2025, 17:15:39Falls natürlich der Modellbahner die Lok vom Gleis abhebt und sie um 180° gedreht wieder aufsetzt, ändert sich die Aufgleisrichtung und gleichzeitig die Verkehrsrichtung. Die Drehrichtung des Motors und damit auch Fahrtrichtung der Lok (dem Schornstein hinterher) bleiben gleich und im FAZ muss natürlich die Verkehrsrichtung aktualisiert und die Entgegengesetzte angezeigt werden.
Dies macht WDP korrekt. Ist das FAZ nicht richtig definiert, ändert sich nach dem Anhalten die Richtungsanzeige im FAZ, die Lok behält aber auf dem Gleis die Fahrtrichtung! Ist die automatische Wende aktiviert, wird bei der nächsten Fahrstraße die Lok gewendet, da die Fahrtrichtung im FAZ nicht passt. Kleine Ursache große Störung .... Das hat auch nichts mit der Verdrahtung zu tun, in CV 29 lässt sich ja beim Decoder die Richtung korrigieren. Bei einer Kehrschleife ist es ratsam beim FAZ die Erkennung nicht zu aktivieren. Dann sollte es da auch keine Probleme geben.
Mit freundlichen Grüßen
Dirk
Hallo Dirk,
Zitat von: Dirk Streuber in 16. Juni 2025, 21:55:49Zitat von: vikr in 16. Juni 2025, 17:15:39Falls natürlich der Modellbahner die Lok vom Gleis abhebt und sie um 180° gedreht wieder aufsetzt, ändert sich die Aufgleisrichtung und gleichzeitig die Verkehrsrichtung. Die Drehrichtung des Motors und damit auch Fahrtrichtung der Lok (dem Schornstein hinterher) bleiben gleich und im FAZ muss natürlich die Verkehrsrichtung aktualisiert und die Entgegengesetzte angezeigt werden.
Dies macht WDP korrekt.
geh mal biite sofort sofort nach dem Wiederaufgleisen mit der Maus auf das (entsprechend konfigurierte) FAZ und sieh Dir das Bild der Lok an. Stimmt das immer gleich sofort mit der Richtung des Modells überein, wenn Du die Lok von Hand umgedreht hast?
Zitat von: Dirk Streuber in 16. Juni 2025, 21:55:49Ist das FAZ nicht richtig definiert, ändert sich nach dem Anhalten die Richtungsanzeige im FAZ, die Lok behält aber auf dem Gleis die Fahrtrichtung!
ja, wenn das FAZ nicht korrekt konfiguriert ist, kann auch das passieren.
Zitat von: Dirk Streuber in 16. Juni 2025, 21:55:49Ist die automatische Wende aktiviert, wird bei der nächsten Fahrstraße die Lok gewendet, da die Fahrtrichtung im FAZ nicht passt. Kleine Ursache große Störung ....
was meinst Du mit "
wird bei der nächsten Fahrstrasse
die Lok gewendet"? Die Lok kann doch nur mit einer Drehscheibe, Kehrschleife, Gleisdreieck oder händisch vom Modellbahner
gewendet werden. Wenn das Programm die örtliche Represäntation des Modells in der Datenbank wendet, (damit es z.B. für eine geplante Fahrstrasse passt), stimmt es in der Datenbank nicht mehr mit den topologischen Verhältnissen auf der Anlage und dem darauf stehenden Modell überein. Railcom-Detektoren bilden aber exakt diese Topologie zu jedem beliebigen Zeitpunkt ab, wenn man sie befragt und ein Decoder auf dem Abschnitt ist.
Ein Programm kann die Fahrtrichtung der Lok ändern, aber die Lok nicht einfach an Ort und Stelle wenden, dazu bedarf es der Drehscheibe oder eines Eingriff des Modellbahners. Zitat von: Dirk Streuber in 16. Juni 2025, 21:55:49Bei einer Kehrschleife ist es ratsam beim FAZ die Erkennung nicht zu aktivieren. Dann sollte es da auch keine Probleme geben.
Kehrschleifen sind in dem von Dir gezeigtem Demo-Gleisplan nicht vorhanden und können deshalb nicht Ursache des von Dir beschriebenen inkonsistenten Anzeigeverhaltens im FAZ sein.
MfG
vik
Hallo zusammen,
Zitatgeh mal biite sofort sofort nach dem Wiederaufgleisen mit der Maus auf das (entsprechend konfigurierte) FAZ und sieh Dir das Bild der Lok an. Stimmt das immer gleich sofort mit der Richtung des Modells überein, wenn Du die Lok von Hand umgedreht hast?
Ja das ist so. Jedoch immer abhänig ob die Adresse sofort gesendet bzw. erkannt wird.
ZitatRailcom-Detektoren bilden aber exakt diese Topologie zu jedem beliebigen Zeitpunkt ab, wenn man sie befragt und ein Decoder auf dem Abschnitt ist.
In einer perfekten Welt mag das so sein aber es kann schon mal vorkommen das ein Detektor die Fahrtrichtung falsch auswertet und das dann an WDP auch falsch weitergibt, dann kommt es genau zu dem was Dirk beschrieben hat und WDP dreht die Fahrtrichtung weil "bei Bedarf wenden" aktiv ist. Ich habe auch schon regelrecht ständig wechselnde Fahrtrichtungen gesehen weil z.B. ein Dekoder "spinnt" oder der Kontakt einfach schlecht war.
Immer im Hinterkopf behalten WDP reagiert nur auf Daten die von der Zentrale kommen. Wenn die Zentrale bzw. der Detektor meint die Fahrtrichtung hat sich geändert wird WDP entsprechend reagieren.
Hallo Stefan,
Zitat von: Flitt (Stefan) in 17. Juni 2025, 07:35:31Zitatgeh mal biite sofort sofort nach dem Wiederaufgleisen mit der Maus auf das (entsprechend konfigurierte) FAZ und sieh Dir das Bild der Lok an. Stimmt das immer gleich sofort mit der Richtung des Modells überein, wenn Du die Lok von Hand umgedreht hast?
Ja das ist so. Jedoch immer abhänig ob die Adresse sofort gesendet bzw. erkannt wird.
um diese Frage geht es, liefern die Railcom-Detektoren - gleichzeitig mit der korrekten Adresse - auch die korrekte Aufgleisrichtung? Und erkennen(berechnen!) Modellbahnsteuerprogramme dann aus dieser Lieferung im Kontext der Position des jeweiligen Detektors (ggf. einschließlich der aktuellen DCC-Polarisierung im Gleis) die korrekte Aufgleisrichtung und können daher auch jederzeit die korrekte Verkehrsrichtung anzeigen.
Zitat von: Flitt (Stefan) in 17. Juni 2025, 07:35:31ZitatRailcom-Detektoren bilden aber exakt diese Topologie zu jedem beliebigen Zeitpunkt ab, wenn man sie befragt und ein Decoder auf dem Abschnitt ist.
In einer perfekten Welt mag das so sein aber es kann schon mal vorkommen das ein Detektor die Fahrtrichtung falsch auswertet und das dann an WDP auch falsch weitergibt, dann kommt es genau zu dem was Dirk beschrieben hat und WDP dreht die Fahrtrichtung weil "bei Bedarf wenden" aktiv ist. Ich habe auch schon regelrecht ständig wechselnde Fahrtrichtungen gesehen weil z.B. ein Dekoder "spinnt" oder der Kontakt einfach schlecht war.
regelrecht ständige wechselnde Fahrtrichtung kann ein RailCom-Detektor nicht melden, er kann nur die Aufgleisrichtung melden, alles andere kann nur das Modellbahn-Steuerprogramm bzw. die GUI aus der aktuellen Datenlage neuberechnen. Natürlich kann es auch defekte Detektoren geben, die muss man wie andere defekte Hardware, z.B. eine nicht zuverlässig arbeitende Weiche austauschen. Bedauerlicherweise gibt es auch RailCom-Detektoren, die können einfach die Aufgleisrichtung nicht detektieren und Programme die, wenn gar keine Aufgleisrichtung codiert wurde, dies einfach als vorwärts interpretieren. Auch von diesen Kombinationen kann man natürlich keine zuverlässigen Informationen erwarten und sollte man unbedingt vermeiden.
Zitat von: Flitt (Stefan) in 17. Juni 2025, 07:35:31Immer im Hinterkopf behalten WDP reagiert nur auf Daten die von der Zentrale kommen. Wenn die Zentrale bzw. der Detektor meint die Fahrtrichtung hat sich geändert wird WDP entsprechend reagieren.
Wichtig scheint mir, dass WDP zuverlässig sicher stellen kann, dass alle herangezogen Daten innerhalb eines kleinen Zeitraums (Sekunden) erhoben wurden, am besten naturlich innerhalb der letzten Sekunden, erhoben wurden. Einzige Ausnahme sind Daten, die über den gesamten Betrieb absolut stabil bleiben, dazu gehören - außer im Bereich von Kehrschleifen - alle Daten die die Lage und Polarisation von RailCom-Detektor-Gleisabschnitten betreffen. Nur auf solche Daten darf z.B. beim Start des Programms, einmalig eingelesen, im weiteren Betrieb - einschließlich automatischer Abläufe - ohne weitere Plausibilitätsprüfung - zurückgegriffen werden.
MfG
vik
Hallo Vik,
Zitatum diese Frage geht es, liefern die Railcom-Detektoren - gleichzeitig mit der korrekten Adresse - auch die korrekte Aufgleisrichtung?
Alle Detektoren die ich bis jetzt in den Fingern hatte arbeiten so.
Ob die Aufgleirichtung richtig gemeldet wird das liegt doch sehr an der Hardware, Detektor Firmware Stand, Gleissauberheit und noch vielen anderen Dingen. Es gibt durchaus Decoder die genau andersrum melden als andere.
Zitatregelrecht ständige wechselnde Fahrtrichtung kann ein RailCom-Detektor nicht melden, er kann nur die Aufgleisrichtung melden, alles andere kann nur das Modellbahn-Steuerprogramm bzw. die GUI aus der aktuellen Datenlage neuberechnen.
Man möge mir verzeihen das ich Fahrtrichtung und Aufgleisrichtung verwechselt habe. 8)
ZitatUnd erkennen(berechnen!) Modellbahnsteuerprogramme dann aus dieser Lieferung im Kontext der Position des jeweiligen Detektors (ggf. einschließlich der aktuellen DCC-Polarisierung im Gleis) die korrekte Aufgleisrichtung und können daher auch jederzeit die korrekte Verkehrsrichtung anzeigen.
WDP reagiert immer nur auf die Daten die von der Zentrale bzw. Detektoren gemeldet werden. Wie soll WDP auch berechnen was da nun richtig ist? Das geht schlicht und einfach nicht. Es könnte ja die Lok ans Ende von Hand gefahren worden sein und schon stimmen Aufgleisrichtung und Fahrrichtung nicht mehr überein damit der Zug vorwärts fährt.
ZitatWichtig scheint mir, dass WDP zuverlässig sicher stellen kann, dass alle herangezogen Daten innerhalb eines kleinen Zeitraums (Sekunden) erhoben wurden, am besten naturlich innerhalb der letzten Sekunden, erhoben wurden.
Wie schon vorher erwähnt regaiert WDP nur auf die Daten die von aussen kommen. Wenn der Decoder oder der Detektor Mist melden und im Stillstand die Aufgleisrichtung ändert dann wird WDP auch daruf reagieren und wenn "Wenden bei Bedarf" aktiv ist die Fahrtrichtung ändern.
Ausserdem meldet nicht jeder Dekoder gleich. Es gibt welche die sporatisch alle Minute mal sagen "Hallo ich bins" oder halt welche die das im Abstand von Sekunden machen.
Hallo Dirk,
Zitat von: Dirk Streuber in 16. Juni 2025, 16:35:06im FAZ gibt es für die automatische Erkennung der Fahrtrichtung noch eine Option "Erkannte Fahrtrichtung invertieren". Ist das Gleisbild, wie bei meiner Demo-Anlage, als Kreis dargestellt, gibt es immer FAZ, wo diese Option aktiviert werden muss, sonnst wird die Lok bei Ankunft im FAZ gewendet.
ich würde das gerne mal nachstellen, an welchen Stellen diese Option akriviert werden muss. Könntest Du bitte - ergänzend zu den Screenshots -
noch gelegentlich Dein WDP-Projekt dieser Demoanlage einstellen?
MfG
vik
Hallo Fristen und Themeninteressierte,
heute mein Zwischenbericht zum technischen Umbau vom SX-System hin zum Bidib-System in Verbindung mit Railcom. Alle Steuerelektronik ist ersetzt durch Bauelemente der Readyserie der Fa. Fichtelbahn, incl. der Kehrschleifen.
Der Signalqualitäts-Monitor zeigte anfangs alles in roter Farbe, inzwischen fast alles grün,
bzw. beige (o.ä.). Alles im "grünen" Bereich.
Trotzdem bleibt in einigen Bereichen Fragezeichen. Richtungswechsel im Faz, BR-Bezeichnung verschwindet im Fa obwohl in der Überwachung der Haken zum beibehalten der BR Bezeichnung abgewählt ist und das Feld rot, also besetzt und ausgeleuchtet ist.
Trotzdem war der Wechsel okay, habe dafür andere Qualitäten bekommen. Mal sehen wohin sich Railcom als Zusatznutzen entwickelt.
Grüsse vom Niederrhein, Achim
Hallo Achim,
Zitat von: achim schuetzendorf in 08. Juli 2025, 13:05:48Trotzdem bleibt in einigen Bereichen Fragezeichen. Richtungswechsel im Faz, BR-Bezeichnung verschwindet im Fa obwohl in der Überwachung der Haken zum beibehalten der BR Bezeichnung abgewählt ist und das Feld rot, also besetzt und ausgeleuchtet ist.
Danke für Deinen Zwischenbericht.
Es wäre schön, wenn Du die bestehenden Probleme fokussiert so konkret beschreiben könntest, dass man es mit eigenen Gleisen, eigener Verdrahtung und ggf. eigenen RailCom/BiDIB-Detektoren- und Komponenten nachstellen könnte...
MfG
vik
Hallo vik,
frage mich konkrekt nach der fehlenden Info.
Gleismaterial, Decoder und Decoderfirmware, Kabelquerschnitte ?
Was willst Du wissen? Die Steuerungselemente sind in meiner Signatur zu lesen.
Grüsse vom Niederrhein, Achim
Hallo Achim,
Zitat von: achim schuetzendorf in 10. Juli 2025, 15:42:52frage mich konkrekt nach der fehlenden Info.
na ja, Du schriebst:
Zitat von: achim schuetzendorf in 08. Juli 2025, 13:05:48bleibt in einigen Bereichen Fragezeichen. Richtungswechsel im Faz, BR-Bezeichnung verschwindet im Fa obwohl in der Überwachung der Haken zum beibehalten der BR Bezeichnung abgewählt ist und das Feld rot, also besetzt und ausgeleuchtet ist.
dazu gehört ein Gleisplan mit Deiner Zentrale, den Detektoren und ein WDP-Projekt, bei dem offensichtlich nicht alles so klappt, wie Du das erwartest.
Insbesondere die Situation, bei der der Fahrtrichtungswechsel im WDP-Ziel-FAZ (bei Verwendung von RailCom-Detektor-Gleisabschnitten) nicht klappt, würde ich gerne mal nachstellen. Natürlich ohne Deine gesamte Anlage nachzubauen. Das Anschauen Deines Projektes in einer Büroversion wird eher nicht zielführend sein.
Du könntest also eine fokussierte, übersichtliche Testanlage einschließlich passendem WDP-Projekt vorschlagen, in der das von Dir beobachtete Verhalten ebenfalls auftritt und die andere Forumsmitglieder, ggf. mit ihrer eigenen Zentrale und Hardware nachstellen könnten, um zu versuchen der Sache auf den Grund zu gehen.
Umgekehrt könnte ich natürlich ein kleines Layout vorschlagen, das Du mit Deiner Hardware nachbaust, um mit WDP den genannten Fehler nachzustellen.
MfG
vik
Hallo vik
wenn ich eine Testanlage vorschlage in der der ,,Fehler" auftritt dann wüsste ich ja die Ursache. ? .
Habe ein verständnisproblem mit dem Begriff -fokussiert-.
Was verstehst Du darunter?
Wenn ich eine Versuchsanlage bauen soll bei der das o.g. Problem auftritt habe ich doch schon die Lösung... da ich das Problem ja schon rekonstruieren kann.
Grüsse, Achim
Hallo Achim,
Zitat von: achim schuetzendorf in 10. Juli 2025, 17:28:21wenn ich eine Testanlage vorschlage in der der ,,Fehler" auftritt dann wüsste ich ja die Ursache. ?
schön wärs.
Aber, wenn ich Dich richtig verstanden habe, tritt doch auf Deiner Anlage (gelegentlich?) irgendein Problem auf, wenn Du einen Fahrtrichtungswechsel in einem Ziel-FAZ durchführen willst, bzw. Du musst - wie Dirk berichtet - ggf. schon vor Erreichen des Ziel-FAZ - besondere Einstellungen getroffen haben, damit es wie gewünscht funktioniert.
MfG
vik
Hallo Achim,
Zitat von: achim schuetzendorf in 23. April 2025, 21:48:17Habe dabei trotz aller eingetretenen Stabilität hinsichtlich der Railcom-Infos folgendes beobachtet: Lok fährt per Fahrstrasse vom Startpunkt zum Zielpunkt über mehrere Faz und keiner Kehrschleife, alles Korrekt, erst bei der zweiten Fahrt passiert am Ziel folgendes: bei Ankunft Richtungswechsel im FAZ, obwohl bei Ankunft am Ziel Fahrtrichtung korrekt angezeigt wird, und erst mit Halt die Fahrtrichtung wechselt.
Bei allem was ich inzwischen zum Thema Railcom gelernt habe, so finde ich hier keinen Erklärungsansatz.
so wie ich das verstanden habe, war diese Beobachtung doch der Anlass für die Eröffnung dieses Threads?
MfG
vik
Hallo vik,
Zwischen dem zitierten Anfangsbeitrag und heute liegen einige Wochen in denen ich die damalige Steuerung durch eine ,,reine" Bidib Anlage ersetzt habe. Seit dieser Zeit haben sich die Ungereimtheiten deutlich minimiert.
Dies wollte ich mit dem Zwischenbericht kundtun.
Grüsse, Achim
Hallo Achim,
Zitat von: achim schuetzendorf in 10. Juli 2025, 21:53:28Zwischen dem zitierten Anfangsbeitrag und heute liegen einige Wochen in denen ich die damalige Steuerung durch eine ,,reine" Bidib Anlage ersetzt habe. Seit dieser Zeit haben sich die Ungereimtheiten deutlich minimiert.
OK, vorgestern schriebst Du noch:
Zitat von: achim schuetzendorf in 08. Juli 2025, 13:05:48... Trotzdem bleibt in einigen Bereichen Fragezeichen. Richtungswechsel im Faz, BR-Bezeichnung verschwindet im Fa obwohl in der Überwachung der Haken zum beibehalten der BR Bezeichnung abgewählt ist und das Feld rot, also besetzt und ausgeleuchtet ist.
aber wenn das Dich nicht mehr so doll stört, ist ja alles OK.
MfG
vik
Hallo allerseits,
Zitat von: Flitt (Stefan) in 17. Juni 2025, 16:42:19Alle Detektoren die ich bis jetzt in den Fingern hatte arbeiten so.
Ob die Aufgleirichtung richtig gemeldet wird das liegt doch sehr an der Hardware, Detektor Firmware Stand, Gleissauberheit und noch vielen anderen Dingen. Es gibt durchaus Decoder die genau andersrum melden als andere.
hier würden mich konkrete, sorgfältig dokummentierte Beispiele interessieren.
Zitat von: Flitt (Stefan) in 17. Juni 2025, 16:42:19Man möge mir verzeihen das ich Fahrtrichtung und Aufgleisrichtung verwechselt habe. 8)
diese Verwechslung ist leider eiene der häufigsten Ursachen für Mißverständnisse im Kontext der Interpretation von Railcom-Nachrichten.
Zitat von: Flitt (Stefan) in 17. Juni 2025, 16:42:19WDP reagiert immer nur auf die Daten die von der Zentrale bzw. Detektoren gemeldet werden. Wie soll WDP auch berechnen was da nun richtig ist? Das geht schlicht und einfach nicht. Es könnte ja die Lok ans Ende von Hand gefahren worden sein und schon stimmen Aufgleisrichtung und Fahrrichtung nicht mehr überein damit der Zug vorwärts fährt.
Das ist genau das Problem: WDP entscheidet z.B. bei "Wenden nach Bedarf" "nach Aktenlage" und dabei können sich - genau, wie Du beschreibst - eigentlich schon zwangsläufig Fehler einschleichen. Und das liegt praktisch nie an der Hardware.
Zitat von: Flitt (Stefan) in 17. Juni 2025, 16:42:19Wie schon vorher erwähnt regaiert WDP nur auf die Daten die von aussen kommen. Wenn der Decoder oder der Detektor Mist melden und im Stillstand die Aufgleisrichtung ändert dann wird WDP auch daruf reagieren und wenn "Wenden bei Bedarf" aktiv ist die Fahrtrichtung ändern.
Ausserdem meldet nicht jeder Dekoder gleich. Es gibt welche die sporatisch alle Minute mal sagen "Hallo ich bins" oder halt welche die das im Abstand von Sekunden machen.
Hier wären ganz konkrete Beispiele mit allen Komponenten sinnvoll, bei denen ein solches Verhalten reproduzierbar beobachten kann.
Meistens geht das nur mit dezidierten Logdaten.
Eine Alternatative wäre vielleicht ein gut dokumentiertes Beispiel einer Kombination, bestehend aus Lok-Decoder(n), RailCom-Detektor(en), der passenden Zentrale und einem entsprechenden Modellbahn-Steuerprogramm.
Ich werde mal versuchen, ein plausibles Beispiel zum Nachbauen - konkret für WDP-2025 - hier im Forum einzustellen.
MfG
vik
Hallo zusammen,
das gleiche Problem (wie Überschrift) habe ich bei unserer neu aufgebauten Club-Anlage auch. Hier fahren wir 2 Leiter Gleichstrom, DCC, Railcom +, komplett mit Modulen von Fichtelbahn (BiDiB mit beiseitig getrennten Rückmeldern) und Win Digipet 2021. Folgendes habe ich ausprobiert:
Lok auf FAZ gestellt, Aufgleisrichtung beachtet, Anzeige richtig im Lokcontrol wie auch auf dem Gleisbild, Fahrtrichtungsumkehr im Lok-Editor nicht angehakt. Fahtrichtungspfeile auf allen FAZ geprüft.
Irgendwann fährt die Lok im Automatikbetrieb nicht mehr, weil auf dem FAZ im Gleisbild die Fahrtrichtung nicht mehr stimmt.Jedoch im Lokcontrol richtig angezeigt wird!
Ändert man Softwaremäßig die Fahrtrichtung im Win Digipet, wird sofort die entsprechende Fahrstraße gestellt und es läuft weiter. An den Fahrtagen ist das schon nervig, zumal mein Eindruck ist, dass bei länger Betriebszeit die Fehler sich häufen.
Es ist mir klar, dass bei dem Fehler alle Komponenten in Frage kommen :( . Wenn noch etwas auspobiert werden soll stehe ich gerne zur Verfügung.
Was mir noch aufgefallen ist, dass die Anzeige (Betriebsnummer) nur geht, wenn die Lok auf dem Halteabschnitt anhält! Wenn sie davor auf dem Bremsabschnitt anhält, ist keine Anzeige im intelligenten Fahrzeuganzeiger zu sehen. Hängt das mit Railcom zusammen? In meiner privaten Anlage (kein Railcom) ist das nicht so.
Viele Moba Grüße
Wolfgang
Hallo Wolfgang,
Du mußt bei einem iFAZ allen zusätzlichen RM sagen, das sie ihre Meldung an das iFAZ weiterleiten sollen.
Hallo,
Zitat von: Sven Spiegelhauer in 09. Januar 2026, 11:40:14Hallo Wolfgang,
Du mußt bei einem iFAZ allen zusätzlichen RM sagen, das sie ihre Meldung an das iFAZ weiterleiten sollen.
und das muss passieren inklusive der korrekten Aufgleisrichtungsinformation aus der
aktuellen Railcomnachricht, die der Detektor gerade mitliefert!
MfG
vik
Hallo,
Zitat von: Sven Spiegelhauer in 09. Januar 2026, 11:40:14Hallo Wolfgang,
Du mußt bei einem iFAZ allen zusätzlichen RM sagen, das sie ihre Meldung an das iFAZ weiterleiten sollen.
und zwar inklusive der korrekten Aufgleisrichtungsinformation aus der
aktuellen Railcomnachricht, die der Detektor gerade mitliefert!
MfG
vik
Hallo Sven und vik,
danke für eure schnelle Antwort. Kann die Fahrtrichtung unter "Eigenschaften Fahrzeuganzeiger, Erkennung /Ansicht, auf Statisch einstellen (Nord, Süd etc.). Wie ist es bei einem FAZ in beiden Richtungen? Gilt hier die gründsätzliche W/O Richtung?
Außerdem, wie bzw. wo kann ich die Weitergabe der Info der RM auf das FAZ einstellen?
Viele Moba Grüße
Wolfgang
Hallo Wolfgang,
für ein FAZ mit zwei Richtung und Railcom probiert man mit Aufgleisen eines railcomfähigen Fahrzeuges aus, ob die dann angezeigte Richtung stimmt und wenn wählt man den Haken zum invertieren selbiger in diesem FAZ.
Grüße
Markus
Hallo Markus,
Zitat von: Markus Herzog in 13. Januar 2026, 22:20:22für ein FAZ mit zwei Richtung und Railcom probiert man mit Aufgleisen eines railcomfähigen Fahrzeuges aus, ob die dann angezeigte Richtung stimmt und wenn wählt man den Haken zum invertieren selbiger in diesem FAZ.
das ist allerdings auch die korrekte Beschreibung eines wichtigen Teilproblems. WDP erwartet hier grundsätzlich (zwingend) eine Entscheidung des Anwenders, obwohl ein lokaler RailCom-Detektor (Gleise und Loks - mit Railcom-Decoder - korrekt verdrahtet und nach Konvention konfiguriert) jederzeit alle notwendigen Daten liefern kann, d.h. eine vollständige automatische Platzierung, wäre möglich, wenn WDP alle aktuell verfügbaren Informationen berücksichtigen und auch interpretieren würde. Das gilt natürlich nur für Anlagen ohne Mittelleiter! Bei Anlagen mit Mittelleiter "vernichtet" die Symmetrie von Fahrzeug und Gleis alle Information zur Aufgleisrichtung.
Am überzeugensten kann man das beim Einsatz einer ECoS mit einem passenden RailCom-Detektor (z. B. 50098) und (auch der aktuellen) WDP-Version zeigen. Mit früheren WDP-Versionen (z. B. WDP 2012) war, wie z.B. auch von Herrn Gräbener beschrieben, eine automatisierte Platzierung - bei Einhaltung bestimmter Rahmenbedingungen - möglich.
MfG
vik
Hallo vikr,
Win-Digipet setzt die Loks richtig rum ins FAZ aufgrund bekannter Fahrt- und Aufgöeisrichtung bei 2L-Railcom. Genau dafür gibt es eine passende Einstellung im FAZ bei Railcom-Dekodern. Die statische Option ist nur relevant für den 3L-Fall oder wenn der Detektor die Richtung nicht an WDP meldet (einige Protokolle haben durchaus den Richtungsparameter als optional beschrieben).
Da es aber genügend Meldungen von Usern gibt, dass sie nicht nach Konvention verdrahteten Loks oder Detektoren haben (und sich selber auch nicht in der Lage sehen das korrigieren) gibt es auf Userwunsch auch die Möglichkeit die Meldung Lok- oder Detektorspezifisch zu interpretieren.
Lediglich die Information, ob eine 10cm lange Lok auf einem 100cm langen Melderabschnitt am Anfang oder Ende steht kann man beim besten Willen nicht aus den Melderdaten ablesen.
Grüße
Markus
Hallo Markus,
Zitat von: Markus Herzog in 14. Januar 2026, 07:16:15Win-Digipet setzt die Loks richtig rum ins FAZ aufgrund bekannter Fahrt- und Aufgöeisrichtung bei 2L-Railcom. Genau dafür gibt es eine passende Einstellung im FAZ bei Railcom-Dekodern....
Du meinst bei Abschnitten mit RailCom-Detektoren?
ZitatDie statische Option ist nur relevant für den 3L-Fall oder wenn der Detektor die Richtung nicht an WDP meldet (einige Protokolle haben durchaus den Richtungsparameter als optional beschrieben).
Da es aber genügend Meldungen von Usern gibt, dass sie nicht nach Konvention verdrahteten Loks oder Detektoren haben (und sich selber auch nicht in der Lage sehen das korrigieren) gibt es auf Userwunsch auch die Möglichkeit die Meldung Lok- oder Detektorspezifisch zu interpretieren.
wenn diese Option von Usern dann mal sinngemäß mal eben falsch genutzt wird gibt es ebenfalls Inkonsistenzen.
Prinzipiell kann WDP das alles sicher, aber es macht das nicht immer richtig, am häufigsten wahrscheinlich nicht im dazu passenden Zeitfenster.
Ich werde versuchen eine solcher Situationen - für eine Kombination aus einer ECoS mit ECoS-Detektor und WDP - als hoffentlich nachvollziehbares Beispiel anzufügen.
Ein gerades Gleis (ohne Mittelleiter) aus vier (z.B. Trix-C-Gleis und hier beidseitig) isolierten Abschnitten wird parallel zur vorderen Tischkannte aufgebaut. Am Bauch des davor sitzenden Modellbahnes ist Süd, links West rechts Ost. Loks sollen so aufgegleist werden, das der Schornstein (normalerweise) bzw. der Führerstand mit der Bezeichnung 1 oder V nach Osten zeigt. Sind die DCC-Loks mit ihren Railcom fähigen Decodern und auch die Detektoren korrekt nach Norm verdrahtet, fahren die Loks auf diesem Gleis in der Fahrtrichtung "vorwärts" von West nach Ost.
Auf dem Gleisbild der ECoS (oder einer entprechend präparierten CS1 reloadet) sieht das dnn wie folgt aus:
ECoS-Detektor RC(ECo4FA4RPen-00l)S01.png
Der im Bockbild der ECoS dargestellte Pfeil zeigt die Aufgleisrichtung (
nicht die Fahrtrichtung!!!) an, das heisst er ändert sich auch nicht, wenn man von Ost nach West zurück fährt.
Wird die Lok von Hand auf dem Gleis um 180 Grad gedreht, so dass der Schonstein nach West zeigt, zeigt der Pfeil im Gleisbild ebenfalls nach West, solange die Lok mit dieser Ausrichtung auf den Gleisen stht.
Man kann jetzt z.B. auch eine Pendelstrecke unter der ECoS einrichten und die Lok von West nach Ost und zurück pendeln lassen.
Richtet man in WDP ein passendes Gleisbild mit einer geraden Strecke mit vier RM-Abschnitten und vier FAZ ein und konfiguriert die Erkennung im System, in den Rückmeldemodulen, in den FAZs und in den Fahrzeugen korrekt, kann man die Bewegung auch unter WDP verfolgen, das heißt WDP verarbeitet die Nachricht aus der ECoS und zeigt sie auch korrekt an. Geht man in WDP mit dem Mauszeiger über das FAZ, wird auch das Lokbild seitenrichtig eingeblendet.
ECoS-Detektor RC(WDP4FA4RPen-00l)S01.png
Solange man mit der ECoS manuell per ECoS-Fahrregler steuert und WDP nur anzeigen läßt, funktioniert die Darstellung. Probemleme treten erst auf, wenn die ECoS (zusätzlich) über ein entsprechend konfiguriertes WDP gesteuert wird oder per hinterlegter Automatik die ECoS selber steuern soll und in die ECoS eingreift. Möglicherweise handelt sich dabei auch um Laufzeitprobleme unter Windows, abe sie treten reproduzierbar auf.
Als erstes bitte die ECoS mit den Detektoren einrichten und mal ohne WDP Probefahren.
Dann bitte WDP (für manuellen Fahrbetrieb konfiguriert) dazuschalten und per ECoS-Fahrregler und alternativ per grafischen Fahrregler in WDP die Fahrtrichtung umschalten und dabei ggf. auch auf vertikale rote Balken im FAZ achten!
Nach einer Weile funktioniert es meistens, aber - zumindest eine zeitlang - ist das Verhalten nicht wirklich verlässlich.
MfG
vik
Hallo vikr,
Zitat von: vikr in 14. Januar 2026, 19:40:07Hallo Markus,
Zitat von: Markus Herzog in 14. Januar 2026, 07:16:15Win-Digipet setzt die Loks richtig rum ins FAZ aufgrund bekannter Fahrt- und Aufgöeisrichtung bei 2L-Railcom. Genau dafür gibt es eine passende Einstellung im FAZ bei Railcom-Dekodern....
Du meinst bei Abschnitten mit RailCom-Detektoren?
Jawohl.
Zitat von: vikr in 14. Januar 2026, 19:40:07ZitatDie statische Option ist nur relevant für den 3L-Fall oder wenn der Detektor die Richtung nicht an WDP meldet (einige Protokolle haben durchaus den Richtungsparameter als optional beschrieben).
Da es aber genügend Meldungen von Usern gibt, dass sie nicht nach Konvention verdrahteten Loks oder Detektoren haben (und sich selber auch nicht in der Lage sehen das korrigieren) gibt es auf Userwunsch auch die Möglichkeit die Meldung Lok- oder Detektorspezifisch zu interpretieren.
wenn diese Option von Usern dann mal sinngemäß mal eben falsch genutzt wird gibt es ebenfalls Inkonsistenzen.
Natürlich wenn es der User falsch einstellt gibt es Inkonsitenzen, da aber wie gesagt als wir das noch nicht mit dem invertieren konnten, viele User sich das gewünscht haben (insb. N-Bahn-Fahrer die nach ihren Darstellungen bei vielen Loks keine Möglichkeit hatten umzuverdrahten -> daher die Einstellmöglichkeit für einzelne Loks in der FZ-DB, als auch User (von denen wir zahlreiche habnen) die ihre Anlagen durch Firmen/Dritte haben bauen lassen und sich nicht eine nachträgliche Umverkablung zugetraut haben).
Zu deinem Testaufbau:
Habe mir jetzt tatsächlich die Zeit genommen das zu testen.
2L-Spur-N-Gleis analog zu deinem Aufbau mit nacheinander drei Fleischmann-Loks, einmal mit D&H 05C, einmal Zimo MX-Dekoder und einmal ESU Lopi 4 micro. Alle vorab auf aktuelle Firmware gebracht.
Setup einmal ECoS mit ECOS-Detector mit aktuellster Firmware und einmal LodiRektor mit Lodi-GBM8 als alternatives System.
Test exakt so wie von dir beschrieben durchgeführt.
Ich konnte keine Fehlanzeige der Richtung in den FAZ feststellen/beobachten. Das einzige was ich mal gesehen habe im ECoS-AUtomatik-Betrieb, dass zwei bis dreimal eine Railcom-Meldung eines Detektors erst 2-3 Sekunden nachdem sie schon auf der ECoS zu sehen erst in WDP ankam. Zeitstempel-Abgleich von Wireshark direkt auf der Windows-Schnittstelle sind erfolgt und zumindest zwischen Wireshark und Eingang WDP waren nur Laufzeiten kleiner 10 msec festzustellen (genauer war mit den Mitteln nicht aufzulösen).
Eingesetzte PC- und Netzwerkhardware: Intel(R) Core(TM) i7-9700K, 32GB, 6 Jahre alt. Netgear GS208 und Unifi Layer-3-Switch USW48
Nebenbei bemerkt habe ich das jetzt dir zum Gefallen und für mein Gewissen zwar nochmal gemacht, aber du darst auch schon davon ausgehen, dass wir solche Tests auch nicht jetzt das erste Mal gemacht haben und damit muss ich das Thema für mich jetzt auch wieder beenden.
Grüße
Markus
Hallo Markus,
Zitat von: Markus Herzog in 14. Januar 2026, 23:09:39Zu deinem Testaufbau:
Habe mir jetzt tatsächlich die Zeit genommen das zu testen.
2L-Spur-N-Gleis analog zu deinem Aufbau mit nacheinander drei Fleischmann-Loks, einmal mit D&H 05C, einmal Zimo MX-Dekoder und einmal ESU Lopi 4 micro. Alle vorab auf aktuelle Firmware gebracht.
Setup einmal ECoS mit ECOS-Detector mit aktuellster Firmware...
Test exakt so wie von dir beschrieben durchgeführt.
Ich konnte keine Fehlanzeige der Richtung in den FAZ feststellen/beobachten. Das einzige was ich mal gesehen habe im ECoS-AUtomatik-Betrieb, dass zwei bis dreimal eine Railcom-Meldung eines Detektors erst 2-3 Sekunden nachdem sie schon auf der ECoS zu sehen erst in WDP ankam. Zeitstempel-Abgleich von Wireshark direkt auf der Windows-Schnittstelle sind erfolgt und zumindest zwischen Wireshark und Eingang WDP waren nur Laufzeiten kleiner 10 msec festzustellen (genauer war mit den Mitteln nicht aufzulösen).
Eingesetzte PC- und Netzwerkhardware: Intel(R) Core(TM) i7-9700K, 32GB, 6 Jahre alt. Netgear GS208 und Unifi Layer-3-Switch USW48
vielen Dank für Deine große Mühe beim exakten Nachvollziehen meines Testaufbaus. Könntest Du vielleicht das WDP-Projekt für Deinen aktuell durchgeführten Test mit der ECoS hier einstellen. Ich würde das bei mir dann exakt genauso für meine ECoS und meinen ECoS-Detektor so konfigurieren und naturlich meine Fahrzeuge hinterlegen. Vielleicht finde ich ja den einen entscheidenden Konfigurationsfehler in meinem Testaufbau.
Zitat von: Markus Herzog in 14. Januar 2026, 23:09:39und einmal LodiRektor mit Lodi-GBM8 als alternatives System.
das würde ich zum Vergleich bei mir dann später ebenfalls mal versuchen nachszutellen.
Zitat von: Markus Herzog in 14. Januar 2026, 23:09:39Nebenbei bemerkt habe ich das jetzt dir zum Gefallen und für mein Gewissen zwar nochmal gemacht, aber du darst auch schon davon ausgehen, dass wir solche Tests auch nicht jetzt das erste Mal gemacht haben und damit muss ich das Thema für mich jetzt auch wieder beenden.
Dir ein schlechtes Gewissen zu machen, war keinesfalls meine Absicht! Nochmal ganz vielen lieben Dank, ich werde bei mir nochmaljede Verkabelung, jede Isolierung und jedes Häkchen in der Konfiguration sorgfältig überprüfen.
MfG
vik
Hallo vikr,
siehe Anhang.
Allerdings habe ich das jetzt ein bisschen bearbeiten müssen, denn das war bei mir eingebettet in ein großes Testprojekt wo schon die Fahrzeuge drin waren. Habe das jetzt raus extrahiert und hoffentlich dabei keinen Fehler gemacht.
Grüße
Markus
Hallo Markus,
Zitat von: Markus Herzog in 15. Januar 2026, 19:47:29siehe Anhang.
Allerdings habe ich das jetzt ein bisschen bearbeiten müssen, denn das war bei mir eingebettet in ein großes Testprojekt wo schon die Fahrzeuge drin waren. Habe das jetzt raus extrahiert und hoffentlich dabei keinen Fehler gemacht.
Danke!
Du hast in Deinem Projekt einen ESU 50094 eingesetzt. Ich verfüge nur über ESU 50098. Sie müssen etwas anders konfiguriert werden und sind daher nicht einfach eins zu eins austauschbar. Prinzipiell kann man mit beiden aber dieselben Railcom-Nachrichten detektieren und es könnten natürlich ggf. auch dieselben Fehlinterpretationen auftreten.
Ich werde Dein Projekt zunächst mal für den Einsatz mit dem ESU 50098 anpassen und austesten...
MfG
vik