Anzeige:
THEMA: Rückmeldemodule, Weche taugen für ESU Zentrale über Loconet
THEMA: Rückmeldemodule, Weche taugen für ESU Zentrale über Loconet
roadrunnertrix - 16.02.19 13:58
Hallo zusammen,
da ich gerade dabei bin meine aktuelle Steuerung von ESU Zentrale (ESU Detector und SwitchPilot) auf PC Steuerung umzustellen, überlege ich auch auf andere Hersteller bei den Rückmeldemodulen zurück zu greifen.
Warum das ganze ?
Die ESU Rückmelde Detectoren sind sehr gut aber auch sehr teuer, der ESU Detector 50094 ist im schnitt für 169€ zu bekommen und beeinhaltet 16 Rückmelder.
Das wird auf dauer ganz schön teuer .........
Da ich jetzt einen weiteren bräuchte, die überlegung eventuell andere Hersteller zu Integrieren um kosten zu senken.
Das anschließen sollte dabei funktionieren wie bei dem ESU Detector, ein Rückmelder anschluß pro getrennten Gleis abschnitt und fertig ist das Mondgesicht.png)
-------------------------------------------------------------------
Quelle: ESU
Stromfühler
Der ECoSDetector kann 16 Gleisabschnitte überwachen Die Eingänge lassen sich per Steckbrücke einzeln umschalten zwischen Schalteingang (Masseeingang) oder Stromfühler. Der ECoSDetector ist also universell auf allen Gleissystemen verwendbar und somit die erste Wahl für alle 2-Leiterfahrer. Da die Eingänge, in denen jeweils maximal 3A Strom fließen dürfen, in zwei Gruppen separat voneinander mit Strom versorgt werden können, kann jeder ECoSDetector bis zu zwei Booster-Stromkreise abdecken. Optokoppler sorgen für eine zuverlässige Erkennung.
Zugnummernerkennung
Neben den konventionellen Gleisbesetztmeldern ist der ECoSDetector darüber hinaus in der Lage, vier der 16 Gleisabschnitte besonders zu überwachen: Mit Hilfe der RailCom®-Technik ("local detector") kann auf diesen Abschnitten nicht nur herausgefunden werden, ob sich ein Zug darauf befindet, sondern sogar, welcher Zug genau es ist (Zugnummernerkennung). Hierzu benötigen Sie freilich Railcom®-fähige Lokdecoder.
----------------------------------------------------------------------------------------
Bei der PC Software bin ich noch etwas am testen, tendenz geht aber zu TrainController.
Über den ESU L.Net converter ist es ja möglich die Komunikation mit anderen Herstellern zu schaffen (LocoNet).
Die Rückmeldemodule sollten über L.Net "T" Buchsen zu verbinden sein.
Nun die große frage !
Welche Hersteller von Rückmeldemodulen sind hier zu Empfehlen !?
Hat jemand Erfahrung mit dem " mischen " von ESU und anderen Herstellern !?
Sollte bei PC Steuerung das Rückmeldemodul über RailCom verfügen !?
Ich würde mich über Erfahrungswerte, Meinungen die zur Lösung beitragen sehr freuen !
Gruß Jens
da ich gerade dabei bin meine aktuelle Steuerung von ESU Zentrale (ESU Detector und SwitchPilot) auf PC Steuerung umzustellen, überlege ich auch auf andere Hersteller bei den Rückmeldemodulen zurück zu greifen.
Warum das ganze ?
Die ESU Rückmelde Detectoren sind sehr gut aber auch sehr teuer, der ESU Detector 50094 ist im schnitt für 169€ zu bekommen und beeinhaltet 16 Rückmelder.
Das wird auf dauer ganz schön teuer .........
Da ich jetzt einen weiteren bräuchte, die überlegung eventuell andere Hersteller zu Integrieren um kosten zu senken.
Das anschließen sollte dabei funktionieren wie bei dem ESU Detector, ein Rückmelder anschluß pro getrennten Gleis abschnitt und fertig ist das Mondgesicht
-------------------------------------------------------------------
Quelle: ESU
Stromfühler
Der ECoSDetector kann 16 Gleisabschnitte überwachen Die Eingänge lassen sich per Steckbrücke einzeln umschalten zwischen Schalteingang (Masseeingang) oder Stromfühler. Der ECoSDetector ist also universell auf allen Gleissystemen verwendbar und somit die erste Wahl für alle 2-Leiterfahrer. Da die Eingänge, in denen jeweils maximal 3A Strom fließen dürfen, in zwei Gruppen separat voneinander mit Strom versorgt werden können, kann jeder ECoSDetector bis zu zwei Booster-Stromkreise abdecken. Optokoppler sorgen für eine zuverlässige Erkennung.
Zugnummernerkennung
Neben den konventionellen Gleisbesetztmeldern ist der ECoSDetector darüber hinaus in der Lage, vier der 16 Gleisabschnitte besonders zu überwachen: Mit Hilfe der RailCom®-Technik ("local detector") kann auf diesen Abschnitten nicht nur herausgefunden werden, ob sich ein Zug darauf befindet, sondern sogar, welcher Zug genau es ist (Zugnummernerkennung). Hierzu benötigen Sie freilich Railcom®-fähige Lokdecoder.
----------------------------------------------------------------------------------------
Bei der PC Software bin ich noch etwas am testen, tendenz geht aber zu TrainController.
Über den ESU L.Net converter ist es ja möglich die Komunikation mit anderen Herstellern zu schaffen (LocoNet).
Die Rückmeldemodule sollten über L.Net "T" Buchsen zu verbinden sein.
Nun die große frage !
Welche Hersteller von Rückmeldemodulen sind hier zu Empfehlen !?
Hat jemand Erfahrung mit dem " mischen " von ESU und anderen Herstellern !?
Sollte bei PC Steuerung das Rückmeldemodul über RailCom verfügen !?
Ich würde mich über Erfahrungswerte, Meinungen die zur Lösung beitragen sehr freuen !
Gruß Jens
Arnold_Huebsch - 16.02.19 16:22
Hi!
Wenn man eine hochwertige Zentrale, hier die EcoS mit modernem Bus hier CAN hat - weshalb wollte man dann Technik von übergestern damit verbinden? Das ist so als würde man einem heutigen Auto einen Zweitackter als Motor gönnen.
Der Preis der Rückmeldermodule ist sicher etwas bestimmendes, nur die LocoNet Melder, egal von welchem Hersteller, können viel weniger als die ESU Dinger. Anbetracht des eher geringen Volumens macht das nicht viel Sinn. Man handelt sich viel Ärger mit der Interoperabilität ein. Selbst wenn man mischt und die LocoNet Dinger nur zwischendurch zur Positionsbestimmung verwendet gibt's ein durcheinander. Alleine die Geschichte rund um RailCom schließt LocoNet und andere alte Busse kategorisch aus. die sind um Faktor 50-100 zu langsam. Via LocoNet kann man grad' einmal die Decoderadresse zurück melden vom restlichen Funktionsumfang nicht einmal gar nix.
Selbstverständlich kann man die verschiedenen Technologien mischen, man spart nur wenig Geld gibt aber die Möglichkeit neuer Technik ohne Vorteil auf. Mit RailCom kommen eine Fülle weiterer Möglichkeiten für uns Modellbahner. So kann ein Decoder Melden wo das Gleis verschmutzt ist, die Bremswege können bestimmt werden, Abstimmung von Loks in einer Traktion. Vieles können die Decoder derzeit nur ansatzweise. Daher ist das vielem Modellbahnern gar nicht bewusst.
Also da Du am Beginn des Aufbaus bist: lasst die 40 Jahre alte Technik es verdirbt den Spaß!
-AH-
Wenn man eine hochwertige Zentrale, hier die EcoS mit modernem Bus hier CAN hat - weshalb wollte man dann Technik von übergestern damit verbinden? Das ist so als würde man einem heutigen Auto einen Zweitackter als Motor gönnen.
Der Preis der Rückmeldermodule ist sicher etwas bestimmendes, nur die LocoNet Melder, egal von welchem Hersteller, können viel weniger als die ESU Dinger. Anbetracht des eher geringen Volumens macht das nicht viel Sinn. Man handelt sich viel Ärger mit der Interoperabilität ein. Selbst wenn man mischt und die LocoNet Dinger nur zwischendurch zur Positionsbestimmung verwendet gibt's ein durcheinander. Alleine die Geschichte rund um RailCom schließt LocoNet und andere alte Busse kategorisch aus. die sind um Faktor 50-100 zu langsam. Via LocoNet kann man grad' einmal die Decoderadresse zurück melden vom restlichen Funktionsumfang nicht einmal gar nix.
Selbstverständlich kann man die verschiedenen Technologien mischen, man spart nur wenig Geld gibt aber die Möglichkeit neuer Technik ohne Vorteil auf. Mit RailCom kommen eine Fülle weiterer Möglichkeiten für uns Modellbahner. So kann ein Decoder Melden wo das Gleis verschmutzt ist, die Bremswege können bestimmt werden, Abstimmung von Loks in einer Traktion. Vieles können die Decoder derzeit nur ansatzweise. Daher ist das vielem Modellbahnern gar nicht bewusst.
Also da Du am Beginn des Aufbaus bist: lasst die 40 Jahre alte Technik es verdirbt den Spaß!
-AH-
Hallo Arnold,
es ist ja schön, was die Dekoder mit RailCom seit fast 20 Jahren alles können sollen. Fakt ist aber: Sie könnten, aber sie tun‘s nicht. Wozu also Geld für einen rein theoretischen Vorteil ausgeben?
Jens
es ist ja schön, was die Dekoder mit RailCom seit fast 20 Jahren alles können sollen. Fakt ist aber: Sie könnten, aber sie tun‘s nicht. Wozu also Geld für einen rein theoretischen Vorteil ausgeben?
Jens
roadrunnertrix - 16.02.19 17:03
Hallo Arnold, Jens!
Vielen Dank für diese sehr ausführliche und verständliche Erklärung ! 👍
Mal abgesehen davon was railcom bis jetzt kann und vielleicht in der Zukunft noch dazu kommt, sprechen die anderen Argumente natürlich völlig dafür doch bei ESU zu bleiben.
Eins möchte ich bestimmt nicht, wenn ich schon (bildlich gesprochen) mit dem Porsche angefangen habe, möchte ich dem natürlich keinen lahmen VW Käfer vor die Stoßstange setzen !
Auch wenn das bedeutet das ich weiterhin mehr Geld für die Rückmelder in die Hand nehmen muss.
Ich kann ja auch alles andere als klagen was den Betrieb mit düsen Produkten anbelangt, alles funktioniert tadellos.
Vielen Dank nochmals für diese wichtigen Informationen !!
Gruß Jens
Vielen Dank für diese sehr ausführliche und verständliche Erklärung ! 👍
Mal abgesehen davon was railcom bis jetzt kann und vielleicht in der Zukunft noch dazu kommt, sprechen die anderen Argumente natürlich völlig dafür doch bei ESU zu bleiben.
Eins möchte ich bestimmt nicht, wenn ich schon (bildlich gesprochen) mit dem Porsche angefangen habe, möchte ich dem natürlich keinen lahmen VW Käfer vor die Stoßstange setzen !
Auch wenn das bedeutet das ich weiterhin mehr Geld für die Rückmelder in die Hand nehmen muss.
Ich kann ja auch alles andere als klagen was den Betrieb mit düsen Produkten anbelangt, alles funktioniert tadellos.
Vielen Dank nochmals für diese wichtigen Informationen !!
Gruß Jens
Arnold_Huebsch - 16.02.19 21:58
Hi!
Du hast ja sehr recht die Warterei war ätzend. Es gibt nur JETZT eine Reihe von Decodern die diesen Dinge alle können. Das hat gut 15 Jahre langes "schwadronieren" der Hersteller darüber etwas verzögert. Ursache waren gewisse Probleme zwischen den handelnden Personen. Schutzwälle wie Patente und ähnliches haben da überhaupt nicht geholfen.
Bei den guten Herstellern kann man die RailCom Features Großteils sogar per Software Upgrade nachladen, bzw. auf die genormten Varianten in Letztversion umstellen. Da geht jetzt schon recht viel. Daher auch meine dringende Empfehlung bei einem neuen Projekt keine Bremsen einzubauen.
-AH-
Zitat - Antwort-Nr.: | Name:
es ist ja schön, was die Dekoder mit RailCom seit fast 20 Jahren alles können sollen. Fakt ist aber: Sie könnten, aber sie tun‘s nicht. Wozu also Geld für einen rein theoretischen Vorteil ausgeben?
Du hast ja sehr recht die Warterei war ätzend. Es gibt nur JETZT eine Reihe von Decodern die diesen Dinge alle können. Das hat gut 15 Jahre langes "schwadronieren" der Hersteller darüber etwas verzögert. Ursache waren gewisse Probleme zwischen den handelnden Personen. Schutzwälle wie Patente und ähnliches haben da überhaupt nicht geholfen.
Bei den guten Herstellern kann man die RailCom Features Großteils sogar per Software Upgrade nachladen, bzw. auf die genormten Varianten in Letztversion umstellen. Da geht jetzt schon recht viel. Daher auch meine dringende Empfehlung bei einem neuen Projekt keine Bremsen einzubauen.
-AH-
Hallo,
es mag ja sein das Loconet (Patent von 1997) nicht zu den schnellsten Bussystemem gehört die es so gibt. Can (Patent von 1983/86) Bus (RS485) oder doch gleich Ethernet sind mit Sicherheit schneller.
Ich frag mich bei solchen Aussagen immer wo ist die Grenze von Loconet? Bei 10 Rückmeldern und Loks, bei 50 Rückmelder und Loks oder erst bei 100 Rückmeldern und Loks? Hat das schon mal jemand ermittelt und kann das auch belegen?
Für mich persönlich ist doch eher die Austastlücke im DCC Signal der Flaschenhals, es müssen da ja von als Beispiel z.B. 20 fahrenden Loks die Qos Meldungen und die Fahrstufen untergebracht werden? Geht das überhaupt in der kurzen Austastlücke?
Ich hatte mit diversen Herstellen schon Gespräche auf Messen zu dem Thema Railcom.
Da kamen manchmal schon lustige Antworten.
"Wir senden die Qos Meldungen nur alle paar Sekunden. Sonst bricht das zusammen das reicht aber auch."
oder
"Ja wir melden die Geschwindigkeit zurück aber auch nicht in Echtzeit sondern nur auf Anforderung oder halt auch nur einmal in der Sekunde"
oder
"Ja unserer Decoder können Railcom aber wir fühlen uns nicht an die Norm gebunden da wir kein Mitglied der Railcom Community sind"
Für mich persönlich ist Railcom eine gute und durchaus nützliche Ergänzung zum bestehenden Rückmeldesystem und ich mag das schon sehr das z.B. das lesen über POM und auch die Adressmeldung an das PC Programm und somit das anmelden automatisch im Programm funnktioniert. Aber solange sich nicht alle Hersteller eining sind wird/ist das genau so ein Schrotthaufen rein vom Protokoll her wie so vieles andere im Modellbahnbereich.
Gruß Stefan
es mag ja sein das Loconet (Patent von 1997) nicht zu den schnellsten Bussystemem gehört die es so gibt. Can (Patent von 1983/86) Bus (RS485) oder doch gleich Ethernet sind mit Sicherheit schneller.
Ich frag mich bei solchen Aussagen immer wo ist die Grenze von Loconet? Bei 10 Rückmeldern und Loks, bei 50 Rückmelder und Loks oder erst bei 100 Rückmeldern und Loks? Hat das schon mal jemand ermittelt und kann das auch belegen?
Für mich persönlich ist doch eher die Austastlücke im DCC Signal der Flaschenhals, es müssen da ja von als Beispiel z.B. 20 fahrenden Loks die Qos Meldungen und die Fahrstufen untergebracht werden? Geht das überhaupt in der kurzen Austastlücke?
Ich hatte mit diversen Herstellen schon Gespräche auf Messen zu dem Thema Railcom.
Da kamen manchmal schon lustige Antworten.
"Wir senden die Qos Meldungen nur alle paar Sekunden. Sonst bricht das zusammen das reicht aber auch."
oder
"Ja wir melden die Geschwindigkeit zurück aber auch nicht in Echtzeit sondern nur auf Anforderung oder halt auch nur einmal in der Sekunde"
oder
"Ja unserer Decoder können Railcom aber wir fühlen uns nicht an die Norm gebunden da wir kein Mitglied der Railcom Community sind"
Für mich persönlich ist Railcom eine gute und durchaus nützliche Ergänzung zum bestehenden Rückmeldesystem und ich mag das schon sehr das z.B. das lesen über POM und auch die Adressmeldung an das PC Programm und somit das anmelden automatisch im Programm funnktioniert. Aber solange sich nicht alle Hersteller eining sind wird/ist das genau so ein Schrotthaufen rein vom Protokoll her wie so vieles andere im Modellbahnbereich.
Gruß Stefan
Hallo Stefan
Das Problem ist ja nicht nur, dass die Datenrate begrenzt ist, LocoNet fehlt schlicht auch der Befehlssatz für die Übertragung aller möglichen Railcom-Infos.
Da haust du was durcheinander. Für Railcom brauchst du Meldeabschnitte, in denen sollte möglichst auch immer nur ein Decoder senden, sonst kann es zu Kollisionen kommen. Da es getrennte Bereiche sind, kann aber jede Lok ihre Lücke komplett selbst nutzen. Hier kommt dann aber wieder der Bus ins Spiel: Denn dort müssen die Meldungen der Railcom-Detektoren wieder gesammelt drüber und es entsteht ein Flaschenhals.
Viele Grüße
Carsten
Zitat - Antwort-Nr.: | Name:
Ich frag mich bei solchen Aussagen immer wo ist die Grenze von Loconet? Bei 10 Rückmeldern und Loks, bei 50 Rückmelder und Loks oder erst bei 100 Rückmeldern und Loks?
Das Problem ist ja nicht nur, dass die Datenrate begrenzt ist, LocoNet fehlt schlicht auch der Befehlssatz für die Übertragung aller möglichen Railcom-Infos.
Zitat - Antwort-Nr.: | Name:
Für mich persönlich ist doch eher die Austastlücke im DCC Signal der Flaschenhals, es müssen da ja von als Beispiel z.B. 20 fahrenden Loks die Qos Meldungen und die Fahrstufen untergebracht werden? Geht das überhaupt in der kurzen Austastlücke?
Da haust du was durcheinander. Für Railcom brauchst du Meldeabschnitte, in denen sollte möglichst auch immer nur ein Decoder senden, sonst kann es zu Kollisionen kommen. Da es getrennte Bereiche sind, kann aber jede Lok ihre Lücke komplett selbst nutzen. Hier kommt dann aber wieder der Bus ins Spiel: Denn dort müssen die Meldungen der Railcom-Detektoren wieder gesammelt drüber und es entsteht ein Flaschenhals.
Viele Grüße
Carsten
roadrunnertrix - 18.02.19 10:34
Moin zusammen,
Ich habe mich entschieden alleinig mit ESU Rückmeldern weiter zu machen. Beim Mixen scheint es zuviele wenn und aber zu geben.
Daher habe ich mir grade einen weiteren Detector 50094 Bestellt.
Trotzdem danke ich euch für die Hilfreichen Informationen zu diesem Thema !
Gruß Jens
Ich habe mich entschieden alleinig mit ESU Rückmeldern weiter zu machen. Beim Mixen scheint es zuviele wenn und aber zu geben.
Daher habe ich mir grade einen weiteren Detector 50094 Bestellt.
Trotzdem danke ich euch für die Hilfreichen Informationen zu diesem Thema !
Gruß Jens
Zitat - Antwort-Nr.: | Name:
Das Problem ist ja nicht nur, dass die Datenrate begrenzt ist, LocoNet fehlt schlicht auch der Befehlssatz für die Übertragung aller möglichen Railcom-Infos.
Das stimmt so nicht ganz. Soweit mir bekannt ist gibt es dazu eine Ergänzungsanfrage an Digitrax um noch alle zusätzlich möglichen Railcom Meldungen zu implementieren. Inoffiziell funzt es schon da im Fahrtregler der DR5000 die Qos Meldungen und die aktuelle Geschwindigkeit angeziegt wird.
Die Adressmeldungen sind ja schon lange Bestandteil des Digitrax Protokolls. Auch wenn da die Auswertung der Aufgleisrichtung auch etwas wirr ist.
Denke ich eher nicht. Die Austastlücke wird ja immer global erzeugt und alle Loks müssen dann dort die Daten reinquteschen oder versuchen das. Natürlich wird dies Austastlücke pereodisch erzeugt und vermutlich melden nicht alle Loks in genau der einen Austastlücke zurück aber ich wage zu bezeifeln das dass immer geht. Schon alleine der Rad/Schienen Kontakt führt dazu das da mit Sicherheit irgendwelche verstümmelten Telegramme ankommen die dann eine Austastlücke belegen und die dann vom Detektor noch aussortiert werden müssen.
Es gibt ja auch immer noch die Aussage das es möglich ist in einem Abschnitt bis zu 4 Loks melden können. Die würden dann wenn angesprochen genau im selben Moment melden wenn die über Railcom Kanal 2 die Aufforderung dazu erhalten. Das auslesen der Melungen erfolgt dann im Abschnitt des jeweiligen Melders das ist schon richtig.
Das alles hat aber so rein gar nichts mit dem Loconet Bus zu tun, sondern das ist eine reine DCC Geschichte. Loconet übeträgt ja nur das was empfangen wurde an die Zentrale.
Mich stört immer die Aussage das es aufrgund der langsamen Bus Geschwindigkeit von Loconet nicht geht ohne das es mir jemand devinitiv beweisen kann.
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;