[Muenchner Kindl]

Hallo,

in einigen Threads ist ja bereits die Rede davon aber jetzt ist es endgueltig offiziell: Es gibt eine Schnittstelle, mit der RailCom-Meldungen an den PC gesendet werden und sogar zwei Softwareloesungen, die dieses Interface offiziell unterstuetzen.

Der RailCom-Link aus dem Hause Tams wird von den Programmen Windigipet und ModellSTW unterstuetzt, dank offenem Protokoll ist es auch fuer andere Anbieter moeglich, diesen zu unterstuetzen.

Links:
RailCom-Link
Windigipet (Meldung)
ModellSTW
Naehere Infos
Pressemitteilung

[kaeselok]

Hallo Thomas,

danke für die Info. Ich hoffe, dass ich das jetzt alles richtig verstanden habe, was ich da gelesen habe?!

Das Interface zum PC selbst kostet 70 Flocken. An dieses kann man max. 24 Detektoren anschließen, die die Rückmeldungen von Lokomotiv-Decodern an das Interface übermitteln, welches sie dann an eine PC-Software weiterreicht?

Ich glaube auch verstanden zu haben dass man nicht viele Detektoren benötigt und diese mit "Rückmeldern" nicht verwechselt werden sollen, ja?!

Naja, ich frage jetzt mal nach meinem Lieblingsszenario und Du sagst mir, ob das jetzt geht oder immer noch Zukunftsmusik ist?!


1) Zug fährt in einen Kopfbahnhof, die Zuglok kuppelt automatisch ab und fährt an den Prellbock.
2) Der letzte Personenwagen hat eine stromführende Kupplung an der z.B. eine positive Spannung anliegt
3) Eine neue Lok fährt von einem Abstellgleis auf den letzten Personenwagen zu.
4) Die Kupplung der Lok rastet in den Personenwagen ein

und nun passiert folgendes:

Der Decoder in der Lok "erkennt" das positive Spannungssignal durch die Verbindung mit dem Personenwagen (meinetwegen mit Zusatzschaltung). Jedenfalls erkennt der Decoder an einem EINGANG eine 1, anstatt einer 0 und übermittelt diese nun via RAILCOM via Detector via Interface an den PC.

Der PC stoppt sofort die Lok, schaltet um und der neu zusammengestellte Zug fährt aus dem Kopfbahnhof raus.

Ich hoffe das Szenario verständlich dargestellt zu haben?

Es gibt natürlich noch x weitere Konstrukte. Knackpunkt ist: Gibt es Decoder die nicht nur Funktionsausgänge haben, sondern eben auch EINGÄNGE und die Zustände aus ihrer Umgebung an den PC melden können?!


Wenn das geht dann steige ich um. Versprochen.


Gruß,

Kalle

[nakott]

Hallo Thomas,

das klingt ja super!

Wie lange dauert denn die Erkennung. Oder anders gefragt. Wie lange muss die Lok im Detektor-Abschnitt verweilen, bis die PC-Steuerung die Lok-Adresse kennt?

@Kalle:

ich gebe Dir mal ein anderes Beispiel, wofür man das man toll einsetzen kann:

PC-Steuerungen haben eine Zugverfolgung. Somit weiß der PC immer, welche Lok in welchem Block ist. Immer? Nein nicht immer, denn wenn man eine Lok neu auf Gleis setzt, dann muss man bis jetzt dem PC sagen, welche Lok das ist. Ab dann klappt die Zugverfolgung. Über diesen Adapter teilt die Lok via RailCom der PC-Steuerung die Adresse der Lok mit und man muss es von Hand nicht mehr selber machen.

Oder man denke an eine Anlage, die teilweise von Hand und teilweise automatisch via PC gesteuert wird. Am Übergang der Bereiche wäre eine solche Erkennung super.

Gruß Dirk

[Gast]

Hallo Thomas,

am Lenz-System konnte man in Dortmund bereits die vollautomatische Erkennung der Lokrichtung und der Loknummer im Gleisabschnitt vorgeführt werden. Kann dieses System auch die Ausrichtung der Lok im Gleisabschnitt anzeigen (2-bittige Rückmeldung).

Wird hierbei die rückgemeldete Geschwindigkeit z.B. eines Zimo-Decoders angezeigt?

Wird die Lok selbsttätig angelegt?

Wird die Zugnummernverfolgung nun duch die Adressrückmeldung ersetzt. Wenn ja, wie soll das gehen, bei 24 Abschnitten, und was soll das kosten je Abschnitt?

Zitat

---

Es wurde eine unbekannte Lok gemeldet vom 3. Tams RC Link Detector 18 mit Digitaladresse 150!"

---

Und ist das Anlegen hier nur noch ein weiterer Dialog zu Nummern und Dateneingabe?: Und dann verliessen sie Ihn ?

Wird die Möglcihkeit CV-Inhalte abzufragen irgendwie sinnvoll im Context der Software verwendet?

Ich lass mich ja gerne - vorzugsweise durch überzeugende Antworten auf obige Fragen - eines besseren belehren: Aber das was ich bisher erkenne, scheint mir allenfalls noch eine weitere Beta-Debug-Lösung fürs Seelenheil ehrgeiziger Entwickler zu sein, und keine realen Wert für den Kunden zu haben.

Viele Grüße
Frank

[kaeselok]

Hallo Dirk,

ja, diesen Vorteil habe ich auch erkannt.

Aber wenn die Decoder auch noch Möglichkeiten hätten, Eingänge auszuwerten und diese rückzumelden, oh Mann, die Möglichkeiten wären schon enorm!

- Ladegutvorgänge: Ein Kran lädt Kisten, Container, usw. auf einen Zug (und der kriegt das mit ...)
- Bilden und Lösen von Doppeltraktionen von Loks - ähnliches Beispiel wie bei meinem Kopfbahnhofscenario, das "Ankuppeln" der Loks wird "erkannt"
- Ablaufbergszenarien ...
- ICE verreckt auf offener Strecke, BR 150 fährt los, kuppelt an und schleppt ihn ab (ähnlich Kopfbahnhofszenario)
- Tunnelrettungszug trennt sich und fügt sich wieder selbst zusammen

...

Ideen habe ich genug!


Gruß,

Kalle

[Tom Blikstad]

Ich habe 50 Stück Märklin mfx-Loks. Sie haben natürlich keine Sender für RailCom. Aber ich will es beurteilen was zu tun.

Welche Esu- oder Kühn-Dekoder haben schon RailCom ?

Dass WinDigipet RailCom schon integriert hat ist ja schön.

[jatypc]

Zitat von kaeselok

---

Der Decoder in der Lok "erkennt" das positive Spannungssignal durch die Verbindung mit dem Personenwagen (meinetwegen mit Zusatzschaltung). Jedenfalls erkennt der Decoder an einem EINGANG eine 1, anstatt einer 0 und übermittelt diese nun via RAILCOM via Detector via Interface an den PC.

---

Das geht doch - rein theoretisch
Du musst nur Rueckmeldungsfunktion in einen Lokdecoder integrieren - oder - z.B. ein RailCom (Weiche-,Gleisbesetzung-,...) Rueckmeldungsmodul in eine Lok oder Wagen einbauen. Bei groesseren Spuren soll das eigentlich kein Problem sein

Pavel

[Muenchner Kindl]

Hallo Frank,

nur eine kurze Antwort von mir, ich muss nochmal weg:

Zitat

---

Kann dieses System auch die Ausrichtung der Lok im Gleisabschnitt anzeigen (2-bittige Rückmeldung).

Wird hierbei die rückgemeldete Geschwindigkeit z.B. eines Zimo-Decoders angezeigt?

---

Nein

Zitat

---

Wird die Lok selbsttätig angelegt?

Wird die Zugnummernverfolgung nun duch die Adressrückmeldung ersetzt.

---

In der Software, sofern sie es unterstuetzt, ja. In der Zentrale nein.

Zitat

---

Wenn ja, wie soll das gehen, bei 24 Abschnitten, und was soll das kosten je Abschnitt?

---

Nicht jeder hat eine Clubanlage Zuhause stehen. Der MEC Lehrte kommt derzeit mit 12 Abschnitten aus. Jeder Abschnitt kostet 25EUR.

Zitat

---

Und ist das Anlegen hier nur noch ein weiterer Dialog zu Nummern und Dateneingabe?

---

Das ist Sache des Programmes. Ich habe mit ModellSTW gearbeitet, da folgt natuerlich noch ein Dialog.

Zitat

---

Wird die Möglcihkeit CV-Inhalte abzufragen irgendwie sinnvoll im Context der Software verwendet?

---

Kommt auf die Software an, dem RC-Link ist das wurst, was mit den gelieferten Daten passiert.

Zitat

---

Aber das was ich bisher erkenne, scheint mir allenfalls noch eine weitere Beta-Debug-Lösung fürs Seelenheil ehrgeiziger Entwickler zu sein, und keine realen Wert für den Kunden zu haben.

---

Naja, fuer den "gewoehnlichen" Kunden ist das sehr wohl eine Loesung. Er bekommt eine Realtime-Gleisbesetztmeldung mit echten Daten und kann seine Decoder auf dem Hauptgleis auslesen. Ist mehr als was es vorher gab. OK, der Grossanlagenbetreiber kann damit vielleicht wenig anfangen (wobei WDP meines Wissens nach mehrere RC-Link zulaesst, also dann entsprechend mehr Abschnitte) aber der Betreiber einer feinen Anlage mit einer Handvoll Schattenbahnhofsgleise bekommt ein sauber funktionierendes System.

Dirk,

Zitat

---

Wie lange dauert denn die Erkennung. Oder anders gefragt. Wie lange muss die Lok im Detektor-Abschnitt verweilen, bis die PC-Steuerung die Lok-Adresse kennt?

---

unter 1sec.

weitere Antworten spaeter, ich muss nochmal weg

[jatypc]

Zitat von kaeselok

---

Aber wenn die Decoder auch noch Möglichkeiten hätten, Eingänge auszuwerten und diese rückzumelden, oh Mann, die Möglichkeiten wären schon enorm!

---

Jetzt ohne Spass - ich denke, dass es nun LokDecoderhersteller erkennen muessen und solche Funktion einbauen. Technisch soll es gehen.

Gruss,

Pavel

[TRAINer]

Zitat von jatypc

---

Zitat von kaeselok

---

Aber wenn die Decoder auch noch Möglichkeiten hätten, Eingänge auszuwerten und diese rückzumelden, oh Mann, die Möglichkeiten wären schon enorm!

---

Jetzt ohne Spass - ich denke, dass es nun LokDecoderhersteller erkennen muessen und solche Funktion einbauen. Technisch soll es gehen.

Gruss,

Pavel

---

Bald reichen 8-polige Decoder (Funktionsausgänge) nicht mehr aus. Spass beiseite wäre es möglich z.B. bei Esu Dekoder (wenn überhaupt möglich) die Funktion per Software Update aufzuspielen, weil ich habe immer 1 oder 2 Ausgänge unbenutzt und könnte diese dazu als Eingang nutzen oder ist es ein Hardware Problem. Weil man kann ja nicht immer neue Dekoder kaufen.

[Muenchner Kindl]

Hallo,

ich versuche jetzt mal, eine ausfuehrlichere Antwort auf die vielen Fragen zu geben:

Kalle:

Zitat

---

Das Interface zum PC selbst kostet 70 Flocken. An dieses kann man max. 24 Detektoren anschließen, die die Rückmeldungen von Lokomotiv-Decodern an das Interface übermitteln, welches sie dann an eine PC-Software weiterreicht?

---

Alles richtig.

Zitat

---

Ich hoffe das Szenario verständlich dargestellt zu haben?

---

Wenn ich ehrlich bin... nicht ganz. Nach alledem was ich aber von Deinen Ausfuehrungen verstanden habe duerfte das auch nicht mal Zukunftsmusik sein.

Nochmal zur Funktion:
Ein RC-Decoder sendet stetig Daten aus. Grundsaetzlich ist das die Adresse, es koennen aber auch andere Datenpakete sein wie z.B. Ist-Geschwindigkeit und/oder Fuellstand.
Befindet sich eine solche Lok in einem Abschnit, welcher von einem lokalen Detektor ueberwacht wird nimmt dieser die Daten auf und gibt sie, sinnigerweise zusammen mit seiner eigenen Adresse, weiter. Hier kommt uebrigens eine Info fuer den Frank die Detektoren RC-D1 von Tams uebertragen nur Adressmeldungen, CV-Broadcast und Ack-Codes. Die tatsaechliche Richtung sowie Geschwindigkeit ect. kommt nicht durch einen RC-D1, dazu aber gleich nochmal mehr.
Der RC-Link empfaengt diese Daten und wertet sie aus. Meldet sich ein Detektor nicht wird eine Gleisfrei-Meldung an den PC abgesetzt. Aendert sich die gesendete Adresse muss diese mehrmals bestaetigt werden, dann wird diese als Besetztmeldung an den PC gesendet.
Die Steuersoftware bekommt also nur die Deltameldungen mit und ist damit kaum belastet. Auch werden die Datenleitung zum PC keine grossen Herausforderungen gestellt, wir haben uns fuer 19200 bps entschieden, 300 Baud haetten auch gereicht.

Zu Franks Detailfragen:
Wenn Du Dir die weitere Produktpalette von Tams, insbesondere Decoder, ansiehst, da wirst Du feststellen, dass diese RailCom-maessig nur den Mindeststandard erfuellen. Das macht sie moeglicherweise guenstiger aber auch, hinsichtlich RailCom, flinker und stabiler (mein Eindruck). Die Decoder, die mir am meisten Probleme bereiten kommen von Zimo. Nicht alle aber ein paar Exemplare hoeren einfach im Stand zum Senden auf. Das passiert bei den Decodern von Tams nicht. Ebenfalls sehr stabil verhalten sich hier Lenz Gold (ich habe einen recht alten) und LoPi 3.0 (aktuellste Version). Selbst wenn also die Detektoren und der RC-Link die Ist-Geschwindigkeit verarbeiten wuerden, es wuerde nicht mit allen funktionieren. Warum das mit der tatsaechlichen Richtung nicht unterstuetzt bzw. weitergemeldet wird weis ich nicht, bei einer Mittelleiteranlage wuerde das uebrigens auch nicht funktionieren.

Zitat

---

am Lenz-System konnte man in Dortmund bereits die vollautomatische Erkennung der Lokrichtung und der Loknummer im Gleisabschnitt vorgeführt werden.

---

Davon habe ich gehoert und ich bin sicher, dass Lenz hier was grosses plant. Ich gehe ferner davon aus, dass der RailCom-Bus insgesamt leistungsfaehiger ist als das Tamssystem. Nachdem ich aber als derjenige, der die Firmware programmiert hat, weis, was da schon in der Minimalkonfiguration ueber die Leitung prasselt, wird er auch leistungsfaehiger sein muessen, wenn all die moeglichen Funktionen unterstuetzt werden sollen.

Tom:

Zitat

---

Ich habe 50 Stück Märklin mfx-Loks. Sie haben natürlich keine Sender für RailCom. Aber ich will es beurteilen was zu tun.

---

Loete einen FD-R von Tams parallel zum Lokdecoder und die Lok sendet RailCom

Zitat

---

Welche Esu- oder Kühn-Dekoder haben schon RailCom ?

---

ESU: Lopi3.0 (neueste Version)
Kuehn: vermutlich alle, die demnaechst herauskommen?

Ich hoffe, nicht allzuviel Klarheiten beseitigt zu haben

Achja, das Projekt entstand in enger Zusammenarbeit mit WDP, ModellSTW, Tams und mir. Es ist also nicht irgendein Betabastelkram.

PS: Zum Thema Ueberwachung und Abschnitte. Hier kommt es auf die Software an. Vielleicht reichen ganz wenige RailCom-Abschnitte, damit die Zugverfolgung an bestimmten, strategisch wichtigen Stellen, abgeglichen werden kann. Bei meiner bescheidenen Anlage gibt es derzeit 7 Detektoren, mit insgesamt 10 habe ich jeden Abschnitt ueberwacht.

[Peter Müller]

Zitat von Gast_001

---

Aber das was ich bisher erkenne, scheint mir allenfalls noch eine weitere Beta-Debug-Lösung fürs Seelenheil ehrgeiziger Entwickler zu sein, und keine realen Wert für den Kunden zu haben.

---

Sehe ich anders. Zwar noch nicht fertig und deshalb noch lange nicht für jeden interessant, aber es zeigt die Marschroute, in die es geht. Und das ist wichtig! Schließlich baut man eine Modelleisenbahn-Anlage über viele Jahre auf, muss aber früh schon Richtungsentscheidungen treffen. Wenn ich jetzt noch beim Rohbau bin, kann ich mich aber schon über bidirektionale Kommunikation in fünf Jahren freuen und entsprechende Vorkehrungen treffen bzw. Betriebsabläufe planen. Die Idee wird sicherheitshalber von mehreren Firmen getragen, in sofern würde mich auch eine einzelne Insolvenz nicht aus der Bahn werfen.

[ThKaS]

Moin Thomas

Zitat von Muenchner Kindl

---

ESU: Lopi3.0 (neueste Version)

---

Was heißt das? Hardwaretechnisch aus neuester Produktion oder SW-seitig neueste Firmware?

[Muenchner Kindl]

Zitat von ThKaS

---

Moin Thomas

Zitat von Muenchner Kindl

---

ESU: Lopi3.0 (neueste Version)

---

Was heißt das? Hardwaretechnisch aus neuester Produktion oder SW-seitig neueste Firmware?

---

Soviel ich weis neueste Firmware. Da gibt es aber sicher Kollegen, die Dir da besser Auskunft geben koennen.

Sounddecoder mit RailCom gibt es derzeit uebrigens nur von Zimo.

[Muenchner Kindl]

Zitat von Peter Müller

---

Zitat von Gast_001

---

Aber das was ich bisher erkenne, scheint mir allenfalls noch eine weitere Beta-Debug-Lösung fürs Seelenheil ehrgeiziger Entwickler zu sein, und keine realen Wert für den Kunden zu haben.

---

Sehe ich anders. Zwar noch nicht fertig und deshalb noch lange nicht für jeden interessant, aber es zeigt die Marschroute, in die es geht. Und das ist wichtig! Schließlich baut man eine Modelleisenbahn-Anlage über viele Jahre auf, muss aber früh schon Richtungsentscheidungen treffen. Wenn ich jetzt noch beim Rohbau bin, kann ich mich aber schon über bidirektionale Kommunikation in fünf Jahren freuen und entsprechende Vorkehrungen treffen bzw. Betriebsabläufe planen. Die Idee wird sicherheitshalber von mehreren Firmen getragen, in sofern würde mich auch eine einzelne Insolvenz nicht aus der Bahn werfen.

---

Hallo Peter,

eine Definition von "fertig" gibt es heutzutage fast nicht mehr. Kaum glaubt man, etwas ist "fertig", schon kommt das Nachfolgegeraet.
Auch das Tams-System wird einem stetigen Wandel unterliegen und so wie es heute bereits eine CS2 gibt ist ein RC-Link 2 auch nicht ausgeschlossen. Vielleicht kommen von den Kunden ja Wuensche, die hier noch gar nicht erwaehnt wurden, da nutzt es nichts, jahrelang ein Funktionsmonster am Kunden vorbeizuentwickeln.

Das Protokoll laesst sich jederzeit erweitern, auch die Hardware des RC-Link selbst ist noch nicht am Ende und wenn Lenz seinen RC-Bus fertig hat und sein Protokoll freigegeben hat, lassen sich sicher auch Schnittstellen dazu realisieren. Das koennte dann so aussehen, dass fuer die Schattenbahnhofsueberwachung die einfachen Tams-Detektoren ausreichen, fuer den Rest verwendet man die umfangreicheren Lenz-Geraete.

[digi_thomas2003]

Hallo Thomas,

Zitat von Muenchner Kindl

---

...

Zitat

---

am Lenz-System konnte man in Dortmund bereits die vollautomatische Erkennung der Lokrichtung und der Loknummer im Gleisabschnitt vorgeführt werden.

---

Davon habe ich gehoert und ich bin sicher, dass Lenz hier was grosses plant. Ich gehe ferner davon aus, dass der RailCom-Bus insgesamt leistungsfaehiger ist als das Tamssystem. Nachdem ich aber als derjenige, der die Firmware programmiert hat, weis, was da schon in der Minimalkonfiguration ueber die Leitung prasselt, wird er auch leistungsfaehiger sein muessen, wenn all die moeglichen Funktionen unterstuetzt werden sollen.
...

---

Frage: Bedeutet das nun, daß die Erkennung der Lokrichtung bei Euch ausgeschlossen ist und bleiben wird? Oder wäre dieser Punkt noch für eine Ergänzung sinnvoll?
Das würde das Aufsetzen einer Lok auf einen überwachten Abschnitt und die Meldung an den PC nochmals deutlich vereinfachen: Die Lok meldet einfach noch, in welcher Richtung (links/oben bzw. rechts/unten) sie steht - es ist am PC kein zusätzlicher Benutzereingriff mehr erforderlich.
Wie ist das denn in WDP und ModelStw gelöst? Diese Programme müssen doch auch wissen, wie rum die Lok steht?

Fragt mit herzlichen Grüßen

[Muenchner Kindl]

Hallo Thomas,

Zitat

---

Frage: Bedeutet das nun, daß die Erkennung der Lokrichtung bei Euch ausgeschlossen ist und bleiben wird?

---

Die Lokrichtung kommt nicht aus dem RC-D, deshalb haben wir sie auch nicht im RC-Link integriert. Warum der RC-D das nicht unterstuetzt weis ich nicht, ausgeschlossen ist nie etwas.

Zitat

---

Wie ist das denn in WDP und ModelStw gelöst? Diese Programme müssen doch auch wissen, wie rum die Lok steht?

---

Zu WDP kann ich nichts sagen, ModellSTW ist das wurst. Ein Gleis wird belegt gemeldet und die Lokadresse im GBS angezeigt, waehrend die Richtung von der Steuerung vorgegeben ist. Eine Richtungsangabe von RailCom hat mir persoenlich bisher nicht gefehlt. Es ist zudem so, dass es das bisher auch nicht gegeben hat, abgesehen von dem Demoaufbau auf der Messe.
Hier findest ein Screenshot meiner bescheidenen Anlage mit RailCom, eines der Gleise ist von einer V140 belegt.

[DiegoGarcia]

Hallo Thomas,

vielen Dank für Deinen Bericht und vor allem für die Infos auf Deiner Homepage. Toll!

Nun zum praktischen Teil habe ich ein paar PC-seitige Fragen:
- RC-Link USB: gibt es da einen Treiber auch für MacOS-X? Und für Linux?
- Auf Deiner HP steht, feste Baudrate 19200. Gilt dies bei V24-Anbindung (DIN 9-pol RS232) oder auch für USB?
- Ist bei Kauf der Hardware RC-Link von Tams auch die Schnittstellen-Dokumentation mit dabei? Habe diese nur bei Dir auf der HP gefunden, nicht aber bei Tams selber.

Danke für die Antworten
Diego

[kaeselok]

Hallo Thomas,

ich formuliere meine ursprünglichen Ideen einfach mal um:

Ich hätte gerne Lok-Decoder die nicht nur Funktionsausgänge haben, sondern auch EINGÄNGE. Sprich: Die Lokdecoder können was melden ...

Ist dafür Railcom geeignet? Oder anders gefragt: Hat man neben der Rückmeldung der Lokdaten auch daran gedacht zusätzliche Daten, die z.B. eben von EINGÄNGEN kommen, auch weiterzureichen?!


Viele Grüße,

Kalle

[Muenchner Kindl]

Hallo Diego,

Zitat

---

- RC-Link USB: gibt es da einen Treiber auch für MacOS-X? Und für Linux?

---

Da muesste ich mal nachsehen, ich glaube schon.

Zitat

---

- Auf Deiner HP steht, feste Baudrate 19200. Gilt dies bei V24-Anbindung (DIN 9-pol RS232) oder auch für USB?

---

19200 gilt bei V24 sowie USB.

Zitat

---

- Ist bei Kauf der Hardware RC-Link von Tams auch die Schnittstellen-Dokumentation mit dabei?

---

Das weis ich nicht aber wenn, dann steht da nicht mehr als auf meiner Homepage

Kalle,

Zitat

---

Ich hätte gerne Lok-Decoder die nicht nur Funktionsausgänge haben, sondern auch EINGÄNGE. Sprich: Die Lokdecoder können was melden ...

Ist dafür Railcom geeignet?

---

Prinzipiell wuerde ich sagen Ja. Derzeit und wohl in naher Zukunft nein, bzw. nicht bekannt.

Zitat

---

Hat man neben der Rückmeldung der Lokdaten auch daran gedacht zusätzliche Daten, die z.B. eben von EINGÄNGEN kommen, auch weiterzureichen?!

---

Wie gesagt, derzeit nicht.

[JSteam]

Hallo Frank,

Zitat

---

Es wurde eine unbekannte Lok gemeldet vom 3. Tams RC Link Detector 18 mit Digitaladresse 150!"

---

unbekannt bedeutet in dem Zusammenhang nur, dass Win-Digipet bis zu dem Zeitpunkt noch nicht wusste, dass diese Lok per RailCom ihre Adresse melden kann. Ist die Lok in der WDP Datenbank bereits vorhanden, kann eine Verknüpfung hergestellt werden. Ist die Lok noch nicht vorhanden, kann diese per Assistent bequem angelegt werden. Übrigens, beim Anlegen der Lok sind vom Anwender keine weiteren Angaben mehr erforderlich um eine in WDP lauffähige Lok in die Datenbank zu bekommen. Insofern sehe ich hier auf jeden Fall einen Nutzen.
Ich gehe davon aus, dass deine Kritik einer Erkenntnis entspringt, die einer praktischen Anwendung des System zu Grunde liegt. Meine Anmerkungen sind jedenfalls entsprechend getrieben...

[ronaldhelder]

Hallo,

hier muss ich doch mal einspringen, denn dies:

Zitat

---

Zitat:
Hat man neben der Rückmeldung der Lokdaten auch daran gedacht zusätzliche Daten, die z.B. eben von EINGÄNGEN kommen, auch weiterzureichen?!


Wie gesagt, derzeit nicht.

---

sehe ich doch anders. RailCom von Tams (also die Kombination von MC und RC-link) hat die Möglichkeit, jede CV aus zu lesen. Wenn ein Lokdekoder diesen Eingang dann in eine CV schreibt, und die Software weiss, welche CV es ist, dann kann diese CV von der Software ausgelesen werden und so einen entsprechende Aktion einleiten. Die Hardware ist dafür also vorbereitet, wir brauchen nur noch den Dekoder mit Eingängen.

Es ist überigens so, dass die Software im Moment die Algemeine Funktionen von RailCom implementiert hat: die wichtigste Funktion ist das Auswerten der Adresse, damit die Software aktiv die Lok beeinflüssen kann. Auch bei den (un)bekannten Softwaresteuerungen mit eingebautem Zugverfolgung kommt dies zu Nutzen. Denn auch hier ist nicht immer für jeden Abschnitt bekannt, welche Lok gerade draufsteht. Beispiele hierfür kann man selber bedenken, aber Beispiele sind: Eine neue Lok wird aufgegleist; eine Lok kommt aus dem Handbedienten Abschnitt auf die von der Software überwachten Abschnitt; ein Vorspann wird aufgelöst, und eine Lok bleibt im Block stehen; usw. Als extra ist jetzt das komfortabel zufügen von Loks und das auslesen und programmieren von CVs auf dem Hauptgleis implementiert.

Die Software hat jedoch noch viel mehr Potenzial in sich, nur sind jetzt die Anwender dran: der hardware ist auch heute schon für viele Aufgaben vorbereitet, die Anwender müssen aussagen was sie jetzt brauchen / haben wollen. Die Softwarelieferanten können dann ihre Programme darauf abstimmen.

Auch das automatische Umlaufen einer Lok, oder das Ankuppeln einer zweiten Lok wie hier oben diskutiert, lässt sich heute mit geeigneter Software schon realisieren, ohne Anpassungen an der Hardware.

Ich denke dass RailCom mit dieser Erweiterung ein Schritt weiter kommt, sicher wenn die Anwender mit (realistischen) Wünschen kommen die in der Software relativ einfach ein zu binden sind.

[Gast]

Hallo Jürgen,

Zitat von JSteam

---

Hallo Frank,

Ist die Lok in der WDP Datenbank bereits vorhanden, kann eine Verknüpfung hergestellt werden.

---

Im Falle eine vorhanden Lok in der Lok-DB musste ich doch bisher erst gar keine Verknüpfung anlegen, wo liegt hier der Vorteil?

Zitat

---

Ist die Lok noch nicht vorhanden, kann diese per Assistent bequem angelegt werden.

---

Zur bequemen Anlage bedarfte es bisher doch auch keines Assistenten, was leistet der RC-Link den jetzt letztendlich anderes , als das Ausfüllen des bisherigen Nummernfeldes für die Adresse?

Zitat

---

Übrigens, beim Anlegen der Lok sind vom Anwender keine weiteren Angaben mehr erforderlich um eine in WDP lauffähige Lok in die Datenbank zu bekommen. Insofern sehe ich hier auf jeden Fall einen Nutzen.

---

Dann könnte man doch mal den bequemen Assistenten auch ohne RC-Link freigeben, die anderen Angaben werden ja nicht vom RC-Link befriedigt, sondert es wird hier Verzicht seitens WDP geübt.

Zitat

---

Ich gehe davon aus, dass deine Kritik einer Erkenntnis entspringt, die einer praktischen Anwendung des System zu Grunde liegt.

---

Nein, erstens würde ich ja sonst nicht so dumme Fragen stellen,
und zweitens fahren wir über XPressNet und das kennt keinen RC-Link .
Ein RailCom Integration in unsere Anlage müsste mindestens Dinge wie die

- CV-Programmierung auf dem Gleis auch vom XPressNet-Handregler (Lesen und Schreiben)

- Adress- und Aufstellrichtungserkennung der Lok,

- Belegtmeldung des Abschnitts aller Stromverbraucher,

liefern.

Selbst das würde kaum reichen , meinen Verein vom Sinn grösserer Investitionen zu überzeugen. erst beim echten Tacho, oder bei der Einsparung von Belegtmeldern durch eine entsprechend denkbare Positionsmeldung mittels "RailCom-Tachowelle" könnten sie schwach werden.

Hallo Thomas,

erst mal Danke für die (oftmals nciht mehr selbstverständlcihe) Info, uach wenn Du jetzt die kritischen Fragen abbekommst .

Zitat von Thomas

---

Der RC-Link empfaengt diese Daten und wertet sie aus. Meldet sich ein Detektor nicht wird eine Gleisfrei-Meldung an den PC abgesetzt. Aendert sich die gesendete Adresse muss diese mehrmals bestaetigt werden, dann wird diese als Besetztmeldung an den PC gesendet.

---

Das heisst, das ein nicht RailCom meldendes Fahrzeug auch keine Belegtmeldung auslöst?

Zitat

---

Nicht jeder hat eine Clubanlage Zuhause stehen. Der MEC Lehrte kommt derzeit mit 12 Abschnitten aus. Jeder Abschnitt kostet 25EUR.

---

Die RCD 1 kosten zwischen 20,- und 30,- je Abschnitt. Damit droht die flächendeckende Melder-Ausstattung teurer als die Decoderausstattung der Loks zu werden.

Ich glaube sogar , das das Ding elektrotechnisch gut ist, der 4 fach B-Melder von Tams ist es ja auch. Aber die Kosten erlauben auch für den Normalo wohl maximal punktuellen Einsatz, oder einen grob unterteilten über die erfoderlichen Enzelabschnitte eine PC-gesteuerterten vollständig rückgemeldeten Anlage.

Wie sieht es das mit Kompabiliät/Kaskadierbarkeit zu untergeordneten herkömmlichen Stromfühler-Meldern aus : Wenn die nicht gegeben ist, ist das Ding für den 2L PC Fahrer praktisch unbrauchbar

Wenn man davon ausgeht, das so wenigstens praktische Erfahrungen zu RailCom-Adressmeldung gesammelt werden können: Das ganze erscheint mir dennoch als ein voreiliger Schnellschuss, der Aufweichung geplanter Standards Vorschub leisten könnte.

Mit Begriffen wie "RC-Link", "RailCom-Link", "RC-Talk" schaffen genauso Verunsicherung wie Digital(CC) 2, M(fx)3 und M(fx)4. Die Digitaltechnik ist für den Kunden schon schwierig genug, man muss das existierende Minimum an Struktur nicht noch einem unnötigen Wettlauf um des Kaisers neue Kleider opfern.

Trotzdem Grüße
Frank

[JSteam]

Hallo Frank,

gerade für den Betrieb einer größeren Anlage (mit entsprechend vielen Loks) würde sich das System hervorragende eignen. Deine Fragen sollten in dem vom mir verfassten Testbericht beantwortet worden sein.

[Muenchner Kindl]

Guten Morgen Frank,

Zitat

---

erst mal Danke für die (oftmals nciht mehr selbstverständlcihe) Info, uach wenn Du jetzt die kritischen Fragen abbekommst

---

Ich bin an dem Projekt aktiv beteiligt und stehe auch dazu bzw. dahinter.

Zitat

---

Das heisst, das ein nicht RailCom meldendes Fahrzeug auch keine Belegtmeldung auslöst?

---

Wie auch? Erkennt der Detektor von Lenz einen Decoder ohne RailCom?. Der von ESU angekuendigte Detektor kann das, da ist aber auch ein S88-Rueckmelder integriert, ist dafuer auch "etwas" teuerer.
Der parallele Einsatz von S88 kann durchaus sinnvoll sein. Erstens, um auch nicht-RC-faehige Fahrzeuge zu melden, aber auch fuer eine ggf. notwendige punktuelle Meldung. Via RailCom wird gemeldet, dass Gleis X von Lok Y belegt ist, nicht jedoch wann sich Lok Y genau auf Hoehe von Signal Z befindet.

Zitat

---

Die RCD 1 kosten zwischen 20,- und 30,- je Abschnitt. Damit droht die flächendeckende Melder-Ausstattung teurer als die Decoderausstattung der Loks zu werden.

---

Wie schon erwaehnt, vermutlich ist gar keine flaechendeckende Ausstattung notwendig. Bei mir ist es eine bezahlbare Spielerei, die ich aber auch zur Durchfuehrung des Projektes benoetigt habe (Lasttests ect.). Es kommt auf die Strategie an und was die Software ermoeglicht. Da ich da noch nicht so tief eingestiegen bin hier ein Beispiel wie ich mir das vorstelle:

Ich habe einen Schattenbahnhof mit meinetwegen 10 Gleisen, einem Zufahrsgleis und einem Abfahrtsgleis. Es reicht im Prinzip, wenn das Zufahrsgleis mit einem Detektor ausgestattet ist. Wird es von Lok X befahren und die Fahrstrasse ist fuer Gleis 7 gestellt, dann weis ich, sobald der S88-Melder Gleis 7 als belegt meldet, dass das nur Lok X sein kann.
Nachteil: Schleicht sich in der Nacht der boese Thomas in den Keller und tauscht Lok X gegen Lok Y merkt das die Software natuerlich nicht. Wenn also ein boeser Thomas im Haus wohnt muss man wohl alle Schattenbahnhofsgleise detektieren, dann merkt das die Software sofort wenn er am Werk war

Was den Preis angeht, es hat keiner behauptet, dass mit RailCom alles billiger wird. Das System ist leistungsfaehig und man kann einen Mehrwert daraus ziehen, das kostet.
Es gibt Leute, die ruesten ihre Loks mit Sounddecodern aus und loeten dafuer um die 100 Taler auf den Tisch, damit die Lok ein blechernes Tschu Tschu Tschu Puff Puff von sich gibt, da beschwert sich auch keiner. Ist fuer diese Leute auch ein Mehrwert und wenn es ihnen das wert ist ist es doch schoen.
Ausserdem werden Lenz und ESU (andere Anbieter von lokalen Detektoren sind mit nicht bekannt) ihre Geraete auch nicht gerade verschenken und was das RailCom-Bus-Gateway von Lenz kostet weis heute auch noch keiner. Wenn der das Leistungsspektrum hat, was die Busarchitektur vermuten laesst wird das womoeglich kein Schnaeppchen werden, bei den Preisen fuer die ESU-Detektoren wurde bereits ausreichend gestoehnt.

Ich verstehe auch den Hype um die Lokrichtung nicht ganz. Nur weil es Lenz mit einem Demogeraet auf zwei Messen vorgefuehrt hat? Die Fahrtrichtung, und auf die kommt es doch an, ist doch von der Software vorgegeben, wozu muss ich da noch die Aufgleisrichtung der Lok wissen? Gibt es auch beim Original nicht und ausserdem, wie hast Du das bisher gemacht?
Das "Anmelden" in der Software ist ein Feature, welches von den Autoren praktisch als Beiwerk mitgemacht wurde. Notwendig war das nicht, wir hielten es aber fuer eine nette Spielerei. In ModellSTW ist es so, dass wenn eine dem Programm nicht bekannte Lok via RailCom gemeldet wird, deren Adresse im GBS angezeigt wird. Ist sie im System hinterlegt erscheint stattdessen der Name. Die Erkennung und Anmeldung kann auch deaktiviert werden, ohne Einschraenkung des sonstigen Umfangs. Bei ModellSTW kann ich ferner definieren, ob die Gleis-belegt-Information vom RC-Link oder von einem S88-Melder kommt.

Zitat

---

Wie sieht es das mit Kompabiliät/Kaskadierbarkeit zu untergeordneten herkömmlichen Stromfühler-Meldern aus

---

Was meinst Du? Die Programme, die das bisher unterstuetzen lassen beides kombinieren.

Zitat

---

Das ganze erscheint mir dennoch als ein voreiliger Schnellschuss, der Aufweichung geplanter Standards Vorschub leisten könnte.

---

Welche geplanten Standards? Du meinst nicht vorhandene Standards. Derzeit unterstuetzen zwei Programme unterschiedlicher Preis- und Leistungsklasse "unseren" Standard, der nicht nur vorhanden ist sondern auch ausgereift. Wenn da noch ein oder zwei Anbieter aufspringen, das Protokoll ist einfach und oeffentlich zugaenglich, was glaubst Du, was dann Standard wird? Der geplante, der mal auf einer Messe zu sehen ist oder der vorhandene, den man kaufen und bei bereits zwei Loesungen uneingeschraenkt nutzen kann?

Zitat

---

Mit Begriffen wie "RC-Link", "RailCom-Link", "RC-Talk" schaffen genauso Verunsicherung wie Digital(CC) 2, M(fx)3 und M(fx)4.

---

Sorry Frank, das ist Kaese. Man muss den Dingen einen Namen geben, das machen andere auch. Bei ESU heisst ein Detektor "EcosDetektor", bei Lenz "LRC130", bei Tams eben "RC-D1". Was erwartest Du? Dass sich alle bei der Namenskonvention an Lenz orientieren? Waere das fuer den Kunden uebersichtlicher?