Stand Railcom 2018? Grenzen? Nutzwert?

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby Zilli » 02.06.2018, 18:33

@Peter,
erhöhte Kosten fallen auf jeden Fall im Bereich der Rückmelder an, außer bei Diigkeijs DR5088RC wird da ja teilweise das doppelte für fällig.
Um es lückenlos zu machen, müssten dann auch die Schalt- und sonstigen Zubehördekoder ebenfalls Railcom unterstützen, das wiederum funktioniert auch nicht bei allen, auch Booster müssten dann entsprechend welche eingesetzt werden die den Railcom-Cut-Out unterstützen.
Daher bleib ich für mich auf der Schiene - nutzloses Gedöns. :beer:
MfG Uwe
Zentrale: Roco Z21
Fahrregler: Roco-WLAN-Maus, z21App, Multimaus
Rückmelder: DR5088RC, DR4088LN-CS, DR4088CS
Schaltdecoder: WD10 Kühn, DR4018, DR4024 (Servo)
PC-Software: Rocrail, TC9 Bronze
Zilli
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby RainerK » 02.06.2018, 18:51

Hallo Heinz,
Zilli wrote:...Um es lückenlos zu machen, müssten dann auch die Schalt- und sonstigen Zubehördekoder ebenfalls Railcom unterstützen...

die Notwendigkeit, diese Lücke zu schließen, sehe ich nicht,
weil der reale Railcom-Mehrwert "Positionserkennung" hier nicht greift
und das Auslesen von CV-Werten stationärer Dekoder kaum Nutzwert hat.

Die Möglichkeit, mechanische Weichenlage und/oder Belegungs-Status per Railcom zurückzumelden,
ist z.Zt. noch und IMHO auch für die weitere Zukunft eher exotisch.

Mein Fazit:
Zur Sinnhaftigkeit von Railcom bei Lok-Dekodern wurde schon genug geschrieben.
Für alle stationären Dekoder und Rückmelder sind die verschiedenen Bus-Systeme (u.a. LocoNet, CAN, RocNet, BiDiB, XPressNet)
so weitgehend etabliert, dass genügend Auswahl und preiswerte Angebote (u.a. DIY) verfügbar sind.

Wird Railcom verwendet, z.B. mit verteilten Detektoren zur Positionserkennung in Gleisabschnitten,
ist dafür ohnehin ein Bus-System erforderlich, sodass die Entscheidung für stationäre Dekoder
und Rückmelder z.B. des gleichen Bus-Systems leichtfallen dürfte.
Best Regards, es grüßt RainerK

Win10 64Bit / DCC++ with Arduino Uno / Motor shield and LocoNet GCA85, 50, 93 and 136.
Special interests: DIY electronic assemblies. http://www.rainermoba.blogspot.com
Planning replace the coincidence by the mistake
RainerK
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby HGuenther » 19.06.2018, 14:11

Die Rückmelder sind nicht über railcom, das würde auch voraussichtlich nicht gehen,
weil dafür gar kein Platz im DCC / Railcom Protokoll ist,
sondern über z.B. OpenDCC Meldeplatinen , S88, Xpressnet, Loconet, CAN etc. etc.

Rückmeldungen der Fahrzeugdecoder, wer sie sind und was sie grade machen,
aber schon.

Und auf die etwas frühere Frage zum Aufpreis für gute Railcom Decoder :
Es gibt einen Anbieter für Decoder, der in unsrem "Strassenbahn-Club" mit Hamburger Strassenbahn
sehr gern eingesetzt wird. Der Decoder "kann" nur Railcom Kanal 1 also -> "Ich habe Adresse xxx"

- wird nicht ausgewertet, weil die Modulanlage nur mit Handreglern gesteuert wird
- kosten bei Mengenabnahme unter 20 Euro bei einigen Händlern in der Region
- sind eigentlich recht robust und haben 4 normale, 2 unverstärkte Ausgänge, wenn man auf SUSI verzichtet

Davon hatte ich noch "einige" im Schrank, werden nun nach und nach für Strassenbahnfahrzeuge verwendet

Zukünftig nur noch Zimo, Döhler & Haas , TAMS einsetzbar unter BiDib / OpenDCC / Fichtelbahn.

Ich hoffe, dass die Decoderhersteller Railcom mehr Beachtung schenken,
selbst Kühn kündigt mittlerweile an, Kanal 2 zukünftig zu unterstützen., teilweise über Firmware-Update
mit all den Vorteilen der dann möglichen Auswertung

Und Rob war so nett, BiDib zu unterstützen, weshalb ich Rocrail weiterhin favorisiere.
Heinz Günther
--------------------------------------------------------------
OpenDCC, Fichtelbahn, RocRail, Z21 schwarz
H0 Hamburger Hochbahn U-Bahn, Modulanlage in Planung und in Bau
HGuenther
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby Zilli » 19.06.2018, 17:18

Ich tippe jetzt mal auf einen kleinen Denkfehler in deinen Zusammenhängen?
HGuenther wrote:Ich hoffe, dass die Decoderhersteller Railcom mehr Beachtung schenken,...

Soweit ich weiß bieten namhafte Lokdekoder-Hersteller, wie Zimo, ESU, D&H, alle vollumfängliches Railcom, entsprechend den derzeitigen Möglichkeiten.
Mit dem Hersteller Kühn hast Du natürlich recht, dieser wohl nicht alle Möglichkeiten, aber andere siehe erster Satz.
selbst Kühn kündigt mittlerweile an, Kanal 2 zukünftig zu unterstützen., teilweise über Firmware-Update
mit all den Vorteilen der dann möglichen Auswertung

Dazu müssten dann aber alle Dekoder an die Firma Kühn zurückgesendet werden, da es keine Möglichkeit gibt, dieses Firmware-Update selbst durchzuführen.
HGuenther wrote:Die Rückmelder sind nicht über railcom, das würde auch voraussichtlich nicht gehen,
weil dafür gar kein Platz im DCC / Railcom Protokoll ist,
sondern über z.B. OpenDCC Meldeplatinen , S88, Xpressnet, Loconet, CAN etc. etc.

Ohne Rückmelder die railcomfähig sind geht mal überhaupt gar nichts, soll heißen - natürlich müssen die Rückmelder Railcom können - wie sollen denn sonst die Lok-/Fumktionsdekoder die entsprechenden Daten "rückmelden"?
Das derzeitige Problem ist halt, die Funktionalität dieser Rückmelder. Aus eigenem Einsatz weiß ich, dass der DR5088RC von Digikeijs im Moment eben nur Kanal 1 zu 100% beherrscht, an der Funktionalität des Kanal 2 ist man bei Digikeijs am arbeiten. Ähnlich sieht es halt mit anderen Herstellern aus.
Diese railcomfähigen Rückmelder gibt es mittlerweile für fast alle Bussysteme, außer das veraltete S88 natürlich, und wie gesagt - ohne gibt es keine Railcommeldungen.
MfG Uwe
Zentrale: Roco Z21
Fahrregler: Roco-WLAN-Maus, z21App, Multimaus
Rückmelder: DR5088RC, DR4088LN-CS, DR4088CS
Schaltdecoder: WD10 Kühn, DR4018, DR4024 (Servo)
PC-Software: Rocrail, TC9 Bronze
Zilli
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby HGuenther » 20.06.2018, 10:26

Moin,

"Rückmelder" sind für mich Elektronikbausteine oder Schalter etc.
die an der Strecke / am Gleis Aktionen auslösen können und über einen "Auswerter"
dem Computer für die Steuerung weitergemeldet werden.

Sie haben daher nach meiner bescheidenen Meinung tatsächlich nichts mit Railcom zu tun

Railcom ist zwar prinzipiell eine Rückmeldung von DCC Decodern (meist für Loks, seltener für Zubehör / Wagendecoder)
mit der sie Ihre Lokadresse und eventuell auch Zustände / CV Inhalte melden können,
das sollte aber wirklich nur für Lokdekoder verwendet werden.

Wer seine Anlage mit zu viel "Railcom" Meldungen "verstopft"
wird irgendwann feststellen, dass überall Fehler auftreten, die er sich eventuell
nicht erklären kann, weil zu wenig Zeit im Protokoll vorhandenn ist, um
- Meldungen abzusetzen.
- auf die Meldungen der "anderen" zu lauschen, um mehrfache gleichzeitige Übertragung zu verhindern
- Meldungen / Befehle der Zentrale zu quittieren

Die Gleisbesetztmelder von OpenDCC / Fichtelbahn melden deshalb pro Gleisabschnitt
über das BiDiB Protokoll weiter und nicht mehr mit dem eigentlichen Railcom Protokoll,
Damit kann das "Verstopfen" minimiert werden

Ich gebe zu, das hier in meiner Antwort ist teilweise "kopiertes Fremdwissen" u.A. aus dem OpenDCC Wiki / Forum
aber es sollte trotzdem korrekt wiedergegeben sein
und hoffentlich meinen letzten Beitrag erklären.
Heinz Günther
--------------------------------------------------------------
OpenDCC, Fichtelbahn, RocRail, Z21 schwarz
H0 Hamburger Hochbahn U-Bahn, Modulanlage in Planung und in Bau
HGuenther
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby rjversluis » 20.06.2018, 10:56

Hallo Heinz Günther,

manche Hersteller von RailCom Detektoren vergessen zu 'entprellen' und senden dann pausenlos die gleiche Meldungsinhalt.
Mit solche Detektoren ist eine 'Verstopfung' vorprogrammiert.

Für Automatisch fahren ist RailCom überflüßig, aber kann nützlich sein bei zB Fahrzeuge welche mit ein Akku unterwegs sind und die Ladezustand melden, um es dann nach 'Home' fahren lassen zu können wo das Ladegerät bereit steht. (Funktioniert schon mit BiDiB OpenCar)
Auch ist es praktisch wenn ein RailCom fähige Gast Lok aufgegleist wird und in ein Accept Ident Block fährt wo die Adresse und Platzierung von RailCom in Rocrail übernommen wird.
Auf QoS, Gleiseverschmutzungsgrad, könnte man IMHO verzichten, und es wäre Wünschenswert wenn man die einzelne RailCom Infos zu- oder abschalten könnte.

RailCom benutzen um Wagons zu erfassen ist nicht realistisch; Teuer, Einbaugröße, Stromabnahme, ... Da wäre RFID eine bessere alternative.
Aber auch bei Wagons und Züge gibt es mittlerweile neue Ideen:
viewtopic.php?f=56&t=15875
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBUS - CANGCx ] - [ G: CBUS - CANGCx ]
rjversluis
Site Admin
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby ulf325 » 20.06.2018, 11:04

HGuenther wrote:Wer seine Anlage mit zu viel "Railcom" Meldungen "verstopft"
wird irgendwann feststellen, dass überall Fehler auftreten, die er sich eventuell
nicht erklären kann, weil zu wenig Zeit im Protokoll vorhanden ist

Die Railcom-Rückmeldung erfolgt ja nicht über den DCC-Bus, sondern über einen Datenbus, bei mir zB über XpressNet, der DCC Bus wird damit also nicht "belastet"
Auch die Kommunikation findet sozusagen "lokal" statt, die Railcom-Melder haben einpolig getrennte Rücmleldeabschnitte, was in diesem Abschnitt zwischen Railcom-Detektor und Lokdekoder kommuniziert wird bekommt der Rest der Anlage gar nicht mit. Das Ganze ähnelt einem GBM-Baustein und ist auch ebenso aufgebaut. Tatsächlich wird Railcom+GBM in der Regel kombiniert, aber getrennt ausgewertet weil Railcom als GBM zu langsam ist; jedenfalls viel langsamer als ein simpler Stromfühler.

Etwas anderes ist POM-Read, das geht wirklich über DCC und dementsprechend funktioniert es ab einer gewissen Ausdehnung der Anlage auch schlecht bis gar nicht mehr
mfG: Ulf aus Magdeburg

H0 2L DCC, Roco z21, 3x Blücher GBM16 mit Railcom

Anlagenvorstellung
Modelleisenbahnfreunde Magdeburg
ulf325
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby vikr » 20.06.2018, 23:18

Hallo Uwe,
Zilli wrote:Da ist und bleibt zu klären "Was" macht für "Wen" genau "Welchen" Sinn?
Wenn ich mir das ESU System Ecos II anschaue, dann macht dieses System Sinn für jemanden, der nicht mit Software/PC fahren/schalten will. Da hier ein großes Display enthalten ist, mit dem fast alles abgebildet werden kann. Durch die Nutzung von Railcom+ kann der Nutzer eine Lok mit einem entsprechenden ESU-Dekoder auf das Gleis stellen und diese meldet sich automatisch mit allen vorhandenen Funktionen an. Für den Nutzer von ESU-Komponenten macht das Sinn, selbst der größte digitale Laie hat damit keine Arbeit. Für ESU macht es Sinn in punkto Kundenbindung, der Kunde kauft nun vorrangig ESU-Komponenten.

Tatsächlich gibt die ECoS die RailCom-Nachrichten (zumindest aus Kanal 1) über die ECoSDetektoren 50094 0nd 50098 komplett weiter, zeigt aber selbst nur die Adresse (alternativ den in der ECoS hinterlegten Namen) korrekt an. Die Aufgleisrichtung kann man z.B. unter TC oder WDP zwar sehen, sie wird aber auf dem Display der ECoS (bis aktuell v4.3.2) selbst nicht angezeigt, was den Nutzen für die von Dir angesprochenen ESU treuen Modellbahner ohne PC unnötigerweise einschränkt.

MfG

vik
vikr
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby vikr » 20.06.2018, 23:38

Hallo Ulf,
ulf325 wrote:
HGuenther wrote:Wer seine Anlage mit zu viel "Railcom" Meldungen "verstopft"
wird irgendwann feststellen, dass überall Fehler auftreten, die er sich eventuell
nicht erklären kann, weil zu wenig Zeit im Protokoll vorhanden ist

Die Railcom-Rückmeldung erfolgt ja nicht über den DCC-Bus, sondern über einen Datenbus, bei mir zB über XpressNet, der DCC Bus wird damit also nicht "belastet"
Auch die Kommunikation findet sozusagen "lokal" statt, die Railcom-Melder haben einpolig getrennte Rücmleldeabschnitte, was in diesem Abschnitt zwischen Railcom-Detektor und Lokdekoder kommuniziert wird bekommt der Rest der Anlage gar nicht mit.

Ist das wirklich so?
Die Bandbreite für Railcom-Nachrichten ist durch die Anzahl der Railcom-Lücken limitiert, diese wieder durch die Anzahl der DCC-Pakete. Falls es sich um eine Multiprotokollzentrale handelt, bei der auch mehrere Gleisprotokolle aktiv sind, kann nur die DCC-Protokoll-Zeit Railcom-Lücken enthalten. Zudem kann erst wieder das zweite DCC-Paket nach einem Paket für irgend ein anderes Protokoll eine Lücke enthalten, damit der Decoder das PacketEndBit erkennen kann, um etwas in die dann erwartbare Lücke zu schreiben.
Zumindest wenn RailcomPlus eingeschaltet ist, müßten meiner Meinung auch alle Railcom-Nachrichten aus allen Abschnitten, auch aus denen hinter einem Railcom-Detektor, über das Gleis am globalen Detektor der Zentrale eingelesen werden. Und da ist mit Kollisionen im Kanal 1 schon zu rechnen...

Die Bandbreite für Railcom-Rückmeldungen scheint mir schon in einem praktisch wirksamen Ausmaß begrenzt, vielleicht plädiert Wolfgang Kufer auch deshalb für eine irgendwie geartete Beschränkung des Traffics auf Kanal 1?

MfG

vik
vikr
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby HGuenther » 21.06.2018, 12:13

Wenn Railcom / Railcom plus verwendet wird,
"belastet" dies grundsätzlich erstmal die DCC Übertragung
bis zu dem Punkt, wo eine "Übersetzung" in eine andere Übertragung stattfindet.

Wenn alle Gleisbesetztmelder auf Gleissignale reagieren sollten, wie das oft der Fall ist,
werden sie alle das Railcom Signal mindestens bis zum vorgeschalteten Booster "verschleppen"
Wenn viele GBM Gleise gleichzeitig auch Railcom übertragen müssen
kann, muss aber nicht, das Signal verstümmelt werden, weil alle "durcheinanderrufen"
oder Decoder zur falschen Zeit senden / das falsche Signal senden.

Meine bisherigen Decoder senden nur auf Kanal 1, was bedeutet,
pro Abschnitt der ausgewertet werden kann sind voraussichtlich max. 2 Signale zu unterscheiden,
da alle nicht am Bus "lauschen" sondern munter allen, die es schon wissen, erzählen
"ich bin ein railcomfähiger Decoder mit Adresse xxx und wiederhole mich gerne öfter"
oder
sie antworten erst in der zweiten railcom Lücke, wenn der "Anfragende" nicht mehr damit rechnet

Da ich aber mit Railcom plus arbeiten möchte kann ich nur Decoder nutzen, die sauber über Railcom Kanal 2 zur rechten Zeit antworten
- ich will Mehrfachtraktion haben, bis zu 4 Decoder im gleichen Abschnitt
Ich habe Triebwagen mit 1 bis 4 Wagen, die bis max. 8/9 Wagen einen Zugverband bilden beim Original
also Mehrfachtraktion theoretisch von 8 eines Types oder 3-4 vom anderen Typ
das wird selbst mit Railcom plus schon heikel

- die Fahrzeuge sollen sich anmelden, wenn sie auf das Gleis gestellt werden, ohne dass ich sie
manuell überprüfen muss

- die Fahrzeuge können, entsprechende Firmware vorausgesetzt, Verschmutzung melden
Die Zentrale kann daraus (geht theoretisch wirklich) rückschliessen
-> immer an der gleichen Stelle -> Gleis verschmutzt, Reinigungszug losschicken
-> immer die gleiche Lokadresse -> Personal alarmieren, Zug reinigen

Daher dürfen z.B. meine Signale, weitere Rückmelder, Weichendecoder
entweder nicht über die gleiche Zentrale / den gleichen Booster laufen
oder sie dürfen nicht DCC als Befehlsprotokoll nutzen

Meine zusätzlichen Rückmelder werden vermutlich S88 mit IR LED am Zug und Fototransistor beim Gleismelder sein
ähnlich wie bei Uhlenbrock, nur anders umgesetzt

Meine Signale mache ich mit BiDiB / NeoControl und LED Steuer-ICs
Meine Weichen mit Motoren / Servos über BiDib Komponennten

Und ich befürchte, für meine Loksteuerung über DCC / railcom plus
muss ich die Zugverbände vorkonfigurieren, damit nie mehr als 4 Decoder
im gleichen Gleisabschitt auftreten

Also Zugverbände nur mit Fahrzeugen mit min. 2 Wagenpro Decoder


Mir graust es schon, wenn ich lernen muss, Macros zu erzeugen
und ich immer schwanke zwischen
- ich verstehe BiDiBus nicht
-ich verstehe Rocrail nicht
und
- der Decoderhersteller hat seine Hausaufgaben nicht gemacht

Bei Fichtelbahn / OpenDCC gibt es eine nette Liste,
welche Decoder gut / relativ gut mit Railcom plus funktionieren
und welche Decoderhersteller das noch nicht so gut "können"
http://www.opendcc.de/info/railcom/rail ... rview.html

Mittlerweile lese ich in den Wiki's und Foren seit ungefähr einem Jahr ständig,
vorher mehrere Jahre unregelmäßig

Auf meine jetzigen Pläne beschränke ich mich seit grob einem Jahr
als ich in Stuttgart die Strassenbahnanlage aus Schwerin bei "Kleine Bahn ganz groß"
und ich mit dem hauptverantwortlichen über "BiDiB" ins gespräch gekommen bin.

Meine Fahrzeugsammlung habe ich 2003 begonnen

meine Module habe ich ca. vor 10 Monaten angefangen zu bauen

Fahren kann ich vermutlich frühestens in 1 jahr, so mir meine kleine Tochter
die Zeit dafür lässt bzw. wenn ich endlich "Renntier" bin, ich bekomme wenigstens noch eine Rente ...


Ich habe schon einiges an Planung über den Haufen geworfen, weil ich überall neugierig hinsehe
und feststelle, "Du Dummie hast schon wieder Geld verbrannt" durch falsche gekaufte Hardware
- erste Versuche mit MM Decodern ohne wirkliche Funktionen
- nächste Versuche mit DCC decodern, die nicht das machen, was ich will
- Decoder gefunden, die preiswert sind und viel können, aber mit den jetzigen Zielen inkompatibel
- Fahrzeuge gekauft mit guten Markendecodern, die aber trotz Patentmitbesitz
nicht vollständig railcom plus tauglich sind
- Fahrzeuge gekauft, in denen eigentlich gar kein Platz ist für Decoder
weil gebraucht wenigstens bezahlbar, als Neu-Fahrzeug wären sie umrüstbar,
aber mindestens doppelt so teuer (ohne Decoder)

Um das Thema jetzt von meiner Seite wieder abzuschliessen:

Wenn Railcom eingesetzt wird, läuft es prinzipiell grundsätzlich
über das Gleis mit DCC dem Datenstrom in der "Austastlücke"
Damit ist pro Gleisabschnitt oder pro Booster die Anzahl Meldungen pro Minute eingeschränkt
Pro Gleisabschnitt kann man bei einigen Steueranlagen damit leben, z.B. bei BiDiB
Pro Booster kann es kritisch werden
Loconet / Xpressnet können zwar bedingt auch DCC Informationen übertragen,
da muß man aber genau wissen was man tut
mit den anderen Protokollen für Modellbahnen steht es mit der Weitergabe
von Railcom Meldungen nicht unbedingt zum Besten

Daher sollte man wirklich genau nachdenken, brauche ich Railcom, kann meine Anlage das,
wo sind die Grenzen der Verarbeitung von Nachrichten
bis meine zentrale "um Hilfe ruft"

Unsere Strassenbahn Modul-anlage läuft deshalb aus gutem Grund
mit einer 15 Jahre alten Lenz Zentrale
ohne railcom
mit Lenz XPressnet Handreglern für jedes Fahrzeug
Und wenn wir die zentrale an der falschen Stelle einspeisen in die Modulanlage
gehen selbst DCC Befehle vereinzelt verloren
Die arbeiten aber mit der vollen Versorgungssannung
Raicom arbeitet mit einem Bruchteil davon

Die Modulanlage hat eine Länge von je nach Vorführung, 6 bis 25 Metern als doppelgleisige
Module und Endschleifen

Wir wollen die Anlage vielleicht aber auch mal per Computer steuern,
vermutlich aber trotzdem ohne railcom
(zu viele teilweise auch 15 Jahre alte DCC Decoder diverser Hersteller, die teilweise nicht mehr existieren)
Heinz Günther
--------------------------------------------------------------
OpenDCC, Fichtelbahn, RocRail, Z21 schwarz
H0 Hamburger Hochbahn U-Bahn, Modulanlage in Planung und in Bau
HGuenther
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby RainerK » 21.06.2018, 13:14

Hallo Heinz Günther,

Deine Absichten und Wünsche in Ehren, aber je mehr Buchstaben über RailCom (mit oder ohne "plus") verfasst werden,
um so mehr verstärkt sich der Eindruck, dass RailCom immer mehr zu einem aufwändigem Selbstzweck mutiert,
während der Nutzen überschaubar gering bleibt: Rückmeldung von Adressen bzw PoM bei Mobil-Dekodern. Punkt!

Alles Andere ist - etwas salopp ausgedrückt - überflüssiger Kokolores :roll:
Best Regards, es grüßt RainerK

Win10 64Bit / DCC++ with Arduino Uno / Motor shield and LocoNet GCA85, 50, 93 and 136.
Special interests: DIY electronic assemblies. http://www.rainermoba.blogspot.com
Planning replace the coincidence by the mistake
RainerK
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby rjversluis » 21.06.2018, 16:50

Moin,

so wie ich es verstehe gibt es ein DCC Durchsatz, 18Kbit?, Einbruch schon alleine durch diese Cut-Outs. Ob diese Cut-Outs mit Daten gefüllt sind oder nicht ist egal.
RailCom Abschnitte sind Elektrisch getrennt und sind deswegen nur Lokal aus zu werten, und werden nicht über DCC weiter geleitet, und dabei gibt es kein Übersprach Chaos.
Ein Globale RailCom Detektor ist IMHO Blödsinn und sollte nicht verwendet werden. Diese müsste dann wirklich den Daten Chaos versuchen zu filtern. Wenn nur ein Lok im Einsatz ist kann man es verwenden, sonnst... Abschalten.

RailCom kann ein Sinnvolle Erweiterung sein, aber es sollte doziert verwendet werden. Eine Ansatz welche Peter&Basti verwendet ist mM nach doziert; Das ganze Block ist ein RailCom GBM und am enter werden Magneten verwendet.

Alternativ zu RailCom:
https://forum.opendcc.de/wiki/doku.php?id=ocs:opencar
Wenn es mit Autos funktioniert, warum sollte es mit Loks nicht funktionieren. Dann ist man gleich weg vom DCC.
Auf die Schiene steht dann nur Strom, oder der Lok hat ein Akku an Bord und ist somit ein 'e-Lok'.
Die Cars send über RF ihre position zurück; Könnte man auch bei Loks so machen.

DCC Cut-Outs ist einfach eine Notlösung. (Walkie-Talkie)

Was ist eigentlich RailCom Plus? Channel 2?
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBUS - CANGCx ] - [ G: CBUS - CANGCx ]
rjversluis
Site Admin
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby Zilli » 21.06.2018, 18:22

Was ist eigentlich RailCom Plus?

Ich würde meinen ein Versuch von absoluter Kundenbindung. :P
Ist glaube ich von ESU, zumindest benutzen die das weitestgehend für ihre Produkte. Was gut ist, man stellt eine Lok mit einem Railcom+-Dekoder auf das Gleis und dieser Dekoder meldet sich automatisch mit allen existierenden Funktionen und Adresse am System an, natürlich nur von ESU (mind. Ecos II).
Nur dafür wäre mir aber das gesamte System viel zu teuer.
MfG Uwe
Zentrale: Roco Z21
Fahrregler: Roco-WLAN-Maus, z21App, Multimaus
Rückmelder: DR5088RC, DR4088LN-CS, DR4088CS
Schaltdecoder: WD10 Kühn, DR4018, DR4024 (Servo)
PC-Software: Rocrail, TC9 Bronze
Zilli
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby smitt48 » 21.06.2018, 21:02

Hi,

natürlich nur von ESU (mind. Ecos II)


Auch ECoS 1, nicht ECoSReloaded (hat kein Railcom Hardware). Der Firmware ist fuer alle 4 ECoS Versionen gleich.

mfg Tom
Kind regards,
Tom Smit
Kralendijk, Bonaire - Dutch Caribbean

Märklin M & K-rails with ECoS2 (4.2.4) - Win10
RoSoft: S88n & WDD switch & SDD signal decoders
Display: Tri-ang from 1950's, Märklin from early 1960's
In build phase
smitt48
 

Re: Stand Railcom 2018? Grenzen? Nutzwert?

Postby peter&basti » 21.06.2018, 21:52

Hallo Heinz,

ich habe Dein Referat zum Thema Railcom gelesen, dazu nur so viel in meinen Worten:

- Ich habe RailCom im Einsatz mit BIDIB GBM16T (Belegt)meldern
- Es braucht derartige (Belegt)melder um RailCom Informationen zurückzubekommen
- Das hat jetzt nichts mit DCC Overload oder sonstigem Chaos zu tun.
- BIDIB GBM16T meldet Belegtmeldungen zuverlässig und völlig unabhängig von Railcom (das sind 2 paar Schuhe). Dafür hat der Melder auch eine Rückmelderadresse. Das hat mit Railcom jetzt genau gar nichts zu tun.
- Technisch bedingt (irgendwo muss ja Railcom ausgewertet werden) haben die GBM16T Bausteine Railcom - ich sage mal "Railcom Leseeigenschaften" zusätzlich an Bord. Diese Informationen werden ebenfalls über das BIDIB Protokoll übermittelt und belasten den DCC Dialog mit den Decodern in keinster Weise. Es findet keine zusätzliche Belastung der DCC Zentrale statt weil die Rückmeldung über einen anderen Weg erfolgt.

Ob Railcom mit seinen vorhandenen Features jetzt Sinn macht oder nicht mag jeder für sich selbst beurteilen.

Ich habe meine Anlage flächendeckend mit diesen Möglichkeiten ausgestattet weil:

1. ich an jeder Stelle der Anlage Lokdecoder auslesen kann und auch möchte
2. aus meinen ZIMO's die reale Geschwindigkeit zurückgemeldet bekomme
3. mit QoS erkenne, was und wo ich effizient putzen muss
4. bei einer gelegentlichen Gastlok sofort die Adresse erkenne, sobald diese am Gleis steht und diese dann in RR anlegen kann.

Ich weiß dies sind für viele Kollegen Nebensächlichkeiten. Aber ich bin interessiert daran, die derzeit mögliche und verfügbare Technik auszureizen und dies habe ich umgesetzt.

Für mich nicht notwendig ist die aktuelle Positionsmeldung von Loks via Railcom. Das habe ich abgeschaltet, weil das Rocrail serienmäßig kann und besser.

Für die Waggonerkennung (initial beim Aufgleisen) habe ich RFID im Einsatz, den Rest (die Nachverfolgung) erledigt Rocrail serienmäßig)

Just my 2 cents.
Liebe Grüße / best regards
Peter


System: DCC 2-Leiter H0, Rocrail 64bit auf Win10 Pro 64
Traktion: OpenDCC GBM
Fahrweg: RocNetNode & GCA PI01/2/3, GCA41/Arduino RFID, GCA145 Drehscheibe, etc.
Decoder: 99% Zimo
Experimentell: MQTT & Node-Red
peter&basti
 

Previous

Return to Basisfunktionalität (DE)