Anzeige:
THEMA: Esu SwitchPilot Railcom Rückmeldung ohne Ecos?
THEMA: Esu SwitchPilot Railcom Rückmeldung ohne Ecos?
wassi - 23.09.22 11:52
Hallo,
die ESU Switchpilot können ja bei Doppelspulantrieben die Position des Ankers bei Doppelspulantrieben mit Endabschaltung erkennen und via Railcom rückmelden.
Wie kann man diese Railcom-Rückmeldung ohne Einsatz einer Ecos (bzw. eines Ecos-Boosters/Detecors) in ein Steuerprogramm (insbesondere RocRail) bekommen?
Bei den meisten Meldern/Global Detectoren wird meist nur die Unterstützung für Lokdecoder-Medlungen erwähnt.
Hat jemand soetwas schon einmal erfolgreich umgesetzt (Nutzung der Railcom-Rückmeldung der Esu Switchpilkoten) ?
VG wassi
die ESU Switchpilot können ja bei Doppelspulantrieben die Position des Ankers bei Doppelspulantrieben mit Endabschaltung erkennen und via Railcom rückmelden.
Wie kann man diese Railcom-Rückmeldung ohne Einsatz einer Ecos (bzw. eines Ecos-Boosters/Detecors) in ein Steuerprogramm (insbesondere RocRail) bekommen?
Bei den meisten Meldern/Global Detectoren wird meist nur die Unterstützung für Lokdecoder-Medlungen erwähnt.
Hat jemand soetwas schon einmal erfolgreich umgesetzt (Nutzung der Railcom-Rückmeldung der Esu Switchpilkoten) ?
VG wassi
Hi,
lange hat es gedauert
da derzeit wohl noch keine anderen Zentralen es unterstützen, habe ich nun mal eine ecos zum ausprobieren.
esu ecos 50200 + switchpilot3 + MTX Weichenantrieb (Doppelspule mit Endabschaltung) entsprechend zusammengeschaltet.
in Rocrail einen kleinen Testplan (siehe Anhang) im virtuellen Automatikbetrieb. Weiche swR ist die angeschlossene.
In der Virtuellen Simulation werden die Zubehördekoder real angesprochen und auch die Rückmeldung verarbeitet.
Nur die Fahrzeuge und Belegtmelder werden simuliert
Im Beispiel steht die Weiche swR nicht richtig (könnte z.bsp. nicht richtig geschaltet haben, hier war sie nur gerade zu demo abgezogen vom Dekoder). Daher ist sie rot unterlegt und L4 wartet darauf, das seine Fahrstrasse endlich richtig liegt.
Korrigiere ich von Hand die Weichelage am Antrieb (wenn ich ihn wieder angesteckt habe), wird die L4-Fahrstrasse freigegen und L4 fährt endlich los.
Scheint eine Lösung für das Problem bei der Vereins N-Bahn zu sein, in den Bereichen wo wir die Doppelspulantriebe nur schwer gegen zuverlässigere (z.bsp. MTB MP5 ) tauschen können.
vg wassi
PS: als Alternative ginge natürlich auch der Weich88-N von digital-bahn, dann jedoch nicht via Railcom sondern S88N
https://www.digital-bahn.de/bau_s88n/weich88-n_2v7.htm
Die von wassi zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login
lange hat es gedauert
da derzeit wohl noch keine anderen Zentralen es unterstützen, habe ich nun mal eine ecos zum ausprobieren.
esu ecos 50200 + switchpilot3 + MTX Weichenantrieb (Doppelspule mit Endabschaltung) entsprechend zusammengeschaltet.
in Rocrail einen kleinen Testplan (siehe Anhang) im virtuellen Automatikbetrieb. Weiche swR ist die angeschlossene.
In der Virtuellen Simulation werden die Zubehördekoder real angesprochen und auch die Rückmeldung verarbeitet.
Nur die Fahrzeuge und Belegtmelder werden simuliert
Im Beispiel steht die Weiche swR nicht richtig (könnte z.bsp. nicht richtig geschaltet haben, hier war sie nur gerade zu demo abgezogen vom Dekoder). Daher ist sie rot unterlegt und L4 wartet darauf, das seine Fahrstrasse endlich richtig liegt.
Korrigiere ich von Hand die Weichelage am Antrieb (wenn ich ihn wieder angesteckt habe), wird die L4-Fahrstrasse freigegen und L4 fährt endlich los.
Scheint eine Lösung für das Problem bei der Vereins N-Bahn zu sein, in den Bereichen wo wir die Doppelspulantriebe nur schwer gegen zuverlässigere (z.bsp. MTB MP5 ) tauschen können.
vg wassi
PS: als Alternative ginge natürlich auch der Weich88-N von digital-bahn, dann jedoch nicht via Railcom sondern S88N
https://www.digital-bahn.de/bau_s88n/weich88-n_2v7.htm
Die von wassi zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login
Moin,
da bisher hier noch keine Antwort kam, haben ich mit Hilfe eines Moba-Kollegen mal ein wenig weiter gesucht.
Versuch 1: Ansteuern eines SWP3 (51830) mit einer ECOS 50200 (DCC mit Railcom für den SWP3 ausgewählt, Feedback-Anschlüsse mit angeschlossen gemaß Handbuch S.13 Abb.9 )
-> Rückmeldung geht, auch wenn direkt am Doppelspulrnweichenantrieb mechanisch geschaltet wird (sollte ja auch.png)
)
Versuch 2: Ansteuern eines SWP3 mit einer anderen Railcom fähigen Zentrale (GBMboost+GBM16T)
-> Schalten geht, jedoch keine Rückmeldung, auffällig ist das auf dem GBM16T keinerlei Railcom-Meldungen detektiert werden
Versuch 3: DCC-Signalgenerierung durch die ECOS (siehe oben), Einspeisung dieses DCC Signals in einer GBM16TS via DCC-In, Auswertung via BIDIB GBMboost+GBM16TS
-> GBM16TS detektiert Railcom Meldungen und diese werden auch via GBMboost zum PC ausgeleitet
Da aus diesen Versuchen offensichtlich die ECOS den SWP3 anders ansprechen muss, damit dieser via Railcom antwortet, wurde nun das DCC-Signal beider Zentralen mit einem DCC-Analyze-Tool beobachtet. Dabei viel ein Paket auf, für das wir keinen Standard finden konnte
R0F 81 F0 E4 20 00 B5
R0F Preamble 15
81 F0 Zubehördecoderschaltbefehl 11bit Addr
Jedoch dieses zusätzliche E4 20 00 kann ich keiner gefunden Norm zuordnen.
B5 XOR Checksumme über das gesamte Paket (stimmt)
Die Railcom-Antwort des SWP3 wird als Reaktion POM-lesen der CV4,32 erkannt
Wo finde ich etwas zu diese Erweiterung ?
da bisher hier noch keine Antwort kam, haben ich mit Hilfe eines Moba-Kollegen mal ein wenig weiter gesucht.
Versuch 1: Ansteuern eines SWP3 (51830) mit einer ECOS 50200 (DCC mit Railcom für den SWP3 ausgewählt, Feedback-Anschlüsse mit angeschlossen gemaß Handbuch S.13 Abb.9 )
-> Rückmeldung geht, auch wenn direkt am Doppelspulrnweichenantrieb mechanisch geschaltet wird (sollte ja auch
)Versuch 2: Ansteuern eines SWP3 mit einer anderen Railcom fähigen Zentrale (GBMboost+GBM16T)
-> Schalten geht, jedoch keine Rückmeldung, auffällig ist das auf dem GBM16T keinerlei Railcom-Meldungen detektiert werden
Versuch 3: DCC-Signalgenerierung durch die ECOS (siehe oben), Einspeisung dieses DCC Signals in einer GBM16TS via DCC-In, Auswertung via BIDIB GBMboost+GBM16TS
-> GBM16TS detektiert Railcom Meldungen und diese werden auch via GBMboost zum PC ausgeleitet
Da aus diesen Versuchen offensichtlich die ECOS den SWP3 anders ansprechen muss, damit dieser via Railcom antwortet, wurde nun das DCC-Signal beider Zentralen mit einem DCC-Analyze-Tool beobachtet. Dabei viel ein Paket auf, für das wir keinen Standard finden konnte
R0F 81 F0 E4 20 00 B5
R0F Preamble 15
81 F0 Zubehördecoderschaltbefehl 11bit Addr
Jedoch dieses zusätzliche E4 20 00 kann ich keiner gefunden Norm zuordnen.
B5 XOR Checksumme über das gesamte Paket (stimmt)
Die Railcom-Antwort des SWP3 wird als Reaktion POM-lesen der CV4,32 erkannt
Wo finde ich etwas zu diese Erweiterung ?
Beitrag editiert am 21. 11. 2023 09:27.
Hallo Wassi,
E4 20 00 ist doch das Long-Format für CV-Byte-Verify:
1110 01vv vvvvvvvv dddddddd,
v = 00 00100000 = CV# 32
d = 0 (bei POM-lesen wird das Datenbyte nicht beachtet)
Aber in einem Paket hintereinander gestapelt?
Grüße, Peter W.
E4 20 00 ist doch das Long-Format für CV-Byte-Verify:
1110 01vv vvvvvvvv dddddddd,
v = 00 00100000 = CV# 32
d = 0 (bei POM-lesen wird das Datenbyte nicht beachtet)
Aber in einem Paket hintereinander gestapelt?
Grüße, Peter W.
Nur registrierte und eingeloggte User können Antworten schreiben.
Einloggen ->
Noch nicht registriert? Hier können Sie Ihren kostenlosen Account anlegen: Neuer N-Liste Account
Zum Seitenanfang
© by 1zu160.net;