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