Technikfrage Railcom - Gleislänge

[Gelöschtes Mitglied 18598]

Hallo Leute,

ich denke mal wieder ein wenig krum...

Es geht um Railcom. Da ich die Gleisfreimeldung schon anderweitig gelöst habe (Hallsensoren als Achszähler), benötige ich noch eine punktförmige Zugidentifikation und dachte dabei an Railcom.

Nun ist das Problem die "Punktförmigkeit", heißt: ich möchte das Railcom-Detektor-Gleis so kurz wie möglich machen.

Ein Railcom-Detektor habe ich und der Anschluss an mein Bus-System ist kein Thema. Hier wird das "Event" Lok XYZ überfährt Melder ABC123 dann weitergeleitet und ausgewertet.

Hat jemand Erfahrungen mit den kleinstmöglichen Gleislängen, auf denen eine Lokadresse (nur Channel 1) noch in "normaler" Modellbahngeschwindigkeit sicher erkannt werden kann? Aktuell habe ich noch gut eine Loklänge verwendet. Würde aber gern auch Events zwischen zwei Weichen auslösen können - und das nicht anonym mit Reedkontakten/Hallsensoren, sondern je nach Lokadresse. Also z. B. nur Loks ab Adresse 50 oder so.

Danke vorab.
Robert

 

[ateshci]

Das Prinzip von railcom liegt darin, dass der Stromkreis von Decoder zum Sensor komplett geschlossen ist, d. h. keinerlei weiterer Kontakt zu anderen Gleisabschnitten besteht. Daher müssen für ein auswertbares Signal alle zur Stromabnahme beitragenden Räder/Achsen darin sein. Bei den meisten neueren Loks heißt das, es sind alle im Fahrgestell und evtl. bei Dampfloks sogar am Tender vorhandenen Achsen beteiligt. Kürzer geht nicht!

 

[Gelöschtes Mitglied 18598]

Danke...

Dann ist mir Railcom für die punktförmige Identifikation zu ungeeignet. Ich experimentiere gerade mit den RFID-Tags und selbstgewickelten Luftspulen im Kork unter dem Gleis. Vielleicht ist das besser für meinen Zweck geeignet.

Ich müsste dann zwar noch eine Konvertierung 64bit ID --> Lokadresse einbauen, aber das ist trivial.

Wäre cool, wenn die Lokdecoder bald irgendwie auch den Weg erfassen (und Rückmelden) könnten. also als eine Art "Kilometerstand". Dann könnte man wirklich punktgenau ermitteln, wo genau sich eine Lok im Gleis befindet. Vermutlich ist die Fehleraufsummierung dann der kritische Faktor und man muss den "Kilometerstand" wieder irgendwie "eichen"...

 

[Stardampf]

Wäre cool, wenn die Lokdecoder bald irgendwie auch den Weg erfassen (und Rückmelden) könnten. also als eine Art "Kilometerstand". Dann könnte man wirklich punktgenau ermitteln, wo genau sich eine Lok im Gleis befindet. Vermutlich ist die Fehleraufsummierung dann der kritische Faktor und man muss den "Kilometerstand" wieder irgendwie "eichen"...

Das ist ein interessanter Gedanke. So wäre es z.B. möglich, Wartungsintervalle nach Laufleistung festzulegen.
An eine punktgenaue Ortung glaube ich dagegen nicht. Kommt mal eine Lok ins Schleudern, ist die Ortung komplett im Eimer. Auch der Schlupf in Kurven ist eine weitere Fehlerquelle.
Andererseits muß man die Lokadresse auch nicht jedesmal neu auslesen. Man kann sie gemeinsam mit dem Zug ( der ja auch Abhängigkeiten erfordert) speichern und innerhalb der Fahrstraße weiterschieben. So gesehen sollte eine Identifizierung von Lok UND Zug am Einfahrsignal ausreichend sein.

 

[Gelöschtes Mitglied 18598]

Kommt mal eine Lok ins Schleudern, ist die Ortung komplett im Eimer. Auch der Schlupf in Kurven ist eine weitere Fehlerquelle.

Ja, also scheiden schon mal die Radsensoren (Edit: Besser Rad-Umdrehungszähl-Sensoren) aus. Vielleicht könnte man den zurückgelegten Weg auch mit Reflexlichtschranken (z. B. wie in modernen Computermäusen) ermitteln - oder optisch die Schwellen zählen

... innerhalb der Fahrstraße weiterschieben. So gesehen sollte eine Identifizierung von Lok UND Zug am Einfahrsignal ausreichend sein.

Das klappt nicht ganz, wenn der Bahnsteig innerhalb einer Fahrstraße liegt. Ich habe im Moment das Gleis zwischen zwei Signalen in bis zu 5 Railcomabschnitten unterteilt. Jeder Abschnitt löst - zusammen mit der Lokadresse - ein bestimmtes Event aus, auf den meine "Lokführer" (Mikrocontroller) reagieren sollen. (Ich will nicht die Fahrstufen "Einmessen" müssen, wie bei den Computer-Steuerprogrammen - damit habe ich keine gute Erfahrung, da sich das mit zunehmenden "Alter" der Loks immer ändert...)

Die "Lokführer" sind via XPressNet an die Zentrale gekoppelt und können mit DCC-Adresse, Zuglänge, Anzahl der Achsen (Drehgestelle), Zugtyp, Maximalgeschwindigkeit etc. konfiguriert werden. Sie sollen die Züge selbständig steuern. Das klappt auch schon rudimentär, was Halt vor Signalen oder so angeht.

Ein Güterzug achtet nicht auf die "Zwischenevents" innerhalb einer Fahrstraße, sondern nur auf das "Befahren" des Railcomabschnitts vor dem Ausfahrsignal, so dass er daraufhin je nach Signalbild am Ausfahrsignal abgebremst oder zum Stehen gebracht wird.

Ein Personenzug achtet - je nach konfigurierter Länge - auf ein Zwischenevent "H-Tafel erwarten" und kommt daraufhin vor der H-Tafel zum Stehen.

Eigentlich möchte ich das System nun erweitern und mit noch mehr Events versorgen - so dass quasi an jeder Signaltafel ein Event erzeugt wird, und die "Lokführer" so die gleiche Information erhalten, wie ein "echter" Lokführer auf Sicht. Damit möchte ich dann Pfeif/Läuttafeln realisieren, oder auch dem Sounddecoder mitteilen, dass er das Ausschalten des Hauptschalters simulieren soll, wenn die Lok an einem entsprechenden EL-Signal vorbeifährt...


Hmmm.... es ist eben genau der umgedrehte Weg / eine andere Philosophie: Das Gleis soll - punktgenau - der Lok mitteilen, was der "Lokführer" an dieser Stelle für eine Information zum Steuern seiner Lok mitbekommt, statt: Sag mir welche Lok da gerade ist oder ob das Gleis belegt ist.

Mal sehen, bislang funktionieren die zwei Test-RFID-Empfänger ganz gut. Leider stören sich die beiden Empfänger je nach Abstand noch gegenseitig. Das muss ich noch in Griff bekommen...

Ansonsten muss ich eben die "Event-Triggerpunkte" doch mit Hallsensoren/Reedkontakten bauen und einen Mikrocontroller pro Triggerpunkt die Railcomadresse des gesamten Gleises ermitteln lassen. Dann muss ich aber die "Lokführer" so umprogrammieren, dass sie immer nur das erste Event beachten, und - je nach programmierter Anzahl der Drehgestelle pro Zug - die folgenden Events ignorieren, da sie ja dann bei jedem Drehgestell das Event auslösen. (Ich nutze bereits erfolgreich Magnete pro Drehgestell zur Auslösung der "Achszähler" für die Freimeldung meines Gleisbildstellwerks)

 

[ateshci]

Es gibt von Uhlenbrock das LISSY-Modul , damit kannst Du punktgenau rückmelden. Da Du aber XpressNet hast, ist eine genaue Identifikation nur mit einem LN/XpN Umsetzer möglich.

 

[Per]

Alle mir bekannten MoBa-Steuer-Stoftwaren haben eine Zugverfolgung implementiert. Jetzt brauchst du eigentlich nur eine, die das auch im manuellen Modus kann (Rocrail konnte es vor einem Jahr noch nicht (Robs Philosophie!), aktuellen Stand kenne ich nicht). Und schon reichen ein paar Adressemelder auf der ganzen Anlage aus, der Rest geht über jeden beliebigen Rückmelder und etwas Programmierung.

 

[Gelöschtes Mitglied 18598]

Hallo @Per

Danke für die Info. Eine Steuer-Software mit PC kommt für mich definitiv nicht in Frage.

Die Fahrstraßen werden ausschließlich mit dem GBS gestellt. Die Züge sollen aber selbständig fahren können - ohne PC.

Das funktioniert auch prinzipiell, bis auf Spezialfälle, wie z. B. verkürzter Halt am Bstg. oder so. Eben alles, was Zugspezifisch anders laufen soll.

Aktuell bastel ich gerade an der Idee, die Fahrstraßeninfo im Spurkabel für die Events zu nutzen... Dazu werde ich die Triggerpunkte in den Spurplan integrieren und die noch reservierte Ader im Spurkabel nutzen, um die Zugkategorie anhand der Fahrstraße mitzuschleifen. Durch die Kombination dieser Information mit dem Trigger kommt das richtige Event zu Stande, welches dann durch die „Lokführer“-Controller in XpressNet-Befehle zur Lok geschickt werden.

Alles ohne PC und ohne Moba-Steuerprogramm...

VG
Robert

 

[Per]

Ohne PC, aber 1000 µC. Macht es auch nicht besser.
Und glaub mir, ein RaspPi (oder einer besser ausgestatteten Frucht) unter der Anlage erleichtert vieles.

 

[Gelöschtes Mitglied 18598]

Also ich will jetzt keine Grundsatzdiskussion lostreten...

Aber bei "109.00 EUR inkl. Mwst." (Quelle: https://secure.freiwald.com/seiten/register2.htm) könnte ich mir (wenn ich sie (die µC's) nicht schon längst im Einsatz hätte) insgesamt 198 µCs kaufen, die das tun, was sie sollen... Einen µC brauche ich pro Zug und so viele Züge will ich noch nicht mal zur Hauptverkehrs-Schicht fahren lassen

Selbst wenn ich andere "freie" Moba-Software einsetze, habe ich immer noch das Problem, dass dann die Software ALLES machen will - also auch die Fahrstraßen selbst schalten will - und da hört es bei mir auf. Mein Szenario zum Glücklich-Sein sieht ein REALGETREUES GS II Sp 64 b vor - und das kann und will ich keinem PC in die Hand geben, denn die machen daraus nur Murks und Ärger. Ich will "Fahrdienstleiter spielen können" und bin kein Trainspotter oder Sammelstücke-Präsentierer...

[Ironie an]
...dass am Ende die Züge dann doch auch noch über die Modellbahn fahren sollten, ist für mich Nebensache - Hauptsache irgendwas löst dann auch meine gestellten Fahrstraßen wieder auf...
[Ironie aus]

Es soll ja auch FDL geben, die in all ihren Dienstjahren noch nicht einmal aus Ihrem Stellwerksfenster geschaut haben - sofern sie überhaupt eines haben und nicht meilenweit in einer BZ im Dunkeln hocken

 

[Zilli]

zumal bei der 109 Eur-Version eh kein Railcom gebraucht wird, das wird frühestens ab Version Silver unterstützt.
Aber ein Raspi mit Rocrail erleichtert das Moba-Hobby doch um einiges und kostet nicht allzu viel.

 

[Gelöschtes Mitglied 18598]

Aber ein Raspi mit Rocrail erleichtert das Moba-Hobby doch um einiges und kostet nicht allzu viel.

und hilft MIR dennoch keinen Millimeter weiter.

 

[Stardampf]

Hi basis77,
so ganz verstehe ich Dein Konzept noch nicht.
Du fährst digital, mit Decoder in der Lok, gesteuert über Xbus.
Gesteuert wird das Ganze zentral über ein Gleisbildstellpult nach Vorbild, welches über ein Netz von Mikrocontrollern, die dezentral/ortsgebunden jeweils einzelne Events auslösen sollen. Zwischen den myC's muß eine Art Bus existieren, der alle myC's untereinander sowie mit der Zentrale verbindet, um Einfluß auf die Lokdecoder nehmen zu können.
Liege ich soweit richtig?

Du willst nun an jedem einzelnen myC die Lokadresse auslesen, um festzustellen, ob das auszulösende Event für diesen Zug gültig ist, oder nicht. Daraus schließe ich, daß der einzelne myC nicht 'weiß', wo (im Gleisplan) er sich befindet.
Wahr oder nicht wahr?

Der Vorteil einer 'zentralen Logik' (PC mit Steuerungsprogramm) besteht darin, daß man nur relativ wenige und dabei relativ 'dumme' Sensoren braucht, die nur JA oder NEIN 'sagen' müssen (Besetztmeldung, Weichenstellung ua.).

Eine dezentrale Logik muß viel aufwendiger vernetzt werden, da hier nicht nur ja/nein-Aussagen weitergemeldet, sondern Entscheidungen getroffen und der hier 'dummen' Zentrale dann präzise 'befohlen' werden. Dazu bedarf es mehr 'Intelligenz' an JEDEM Event-myC/Sensor. Entweder durch punktuelles auslesen der Lokadresse oder z.B. indem man einerseits jedem Event-myC 'Ortskenntnis' verleiht und mit Hilfe der am Stellpult festgelegten Fahrstraße innerhalb des Netzes der myC's eine Kette der für diese Zugfahrt 'gültigen' Event-myC's erzeugt.

P.S.:
Punktuelles Auslesen der Lokadresse könnte alternativ auch mit Barcode funktionieren.

 

[TTbauer]

PC-lose Steuerung? Dann schaut euch doch mal TRACKSWITCH an. Auch nicht die eierlegende Wollmilchsau, aber in seinen Möglichkeiten sehr umfangreich und lässt Platz für Kreativität.

 

[Gelöschtes Mitglied 18598]

Hallo S.D.,

Liege ich soweit richtig?

nicht ganz.

Hier das Konzept, wie ich es jetzt baue - und zwar ohne Railcom:



Wobei alles grau und schwarz unterlegte bereits existiert. Die blassroten Railcom-Detectoren werde ich abschaffen, die beiden roten "Trigger-Module" werde ich nun hinzufügen.

Legende:
SZ- Startziel-Modul GBS
WE- Weichen-Modul GBS
AZ- Achszähler-Modul GBS
TR- Trigger-Modul (neu)
LO- Lok-Operator

Alt: Railcom-Detectoren an den Triggerpunkten hatten Events mit Lok-Adresse auf den Eventbus gelegt.
Neu: Die Triggermodule ermitteln die Lok-"Adresse" (eher Identifizierung des LO's) aus dem Spurplan.

Dazu wird die Lok-Identifizierung anhand der eingestellten Fahrstraße von einem S(Z)-Modul zum anderen (S)Z-Modul weitergegeben, sobald der Haltfall des Signals des S(Z)-Modul eintritt. Dieses Weitergeben über eine spezielle Ader im Spurkabel wird von den Trigger-Modulen gelesen und gemerkt. Damit können Sie bei Eintreten ihres Trigger-Ereignisses (z. B. Hallsensor) das gleiche Event auf den Eventbus legen, wie bisher die Railcom-Detectoren.

Das gleiche Prinzip wird bei der Zugnummernanzeige in realen Stellpulten angewandt.

Herausforderung dabei ist, initial die entsprechende Gleisbelegung in den SZ-Modulen zu konfigurieren. Dies geschieht auch bei der großen Bahn (zwar im Dr S, aber unerheblich) mit z. B. einem ZNP 801.

Da ich nur relativ selten "neue" Züge (andere Loks schon eher, aber die programmiere ich dann eh mit der gleichen Adresse) auf die Anlage bringe, kann ich die Programmierung der Grundbelegung auch manuell vornehmen - oder eben bei Bedarf einmalig am "Einfahrgleis" meines Bahnhofs via Railcomdetector.

Wie gesagt: Ich verstehe nicht, weshalb ich all das funktionierende (grau/schwarz dargestellte) wegwerfen soll, und durch einen PC/Raspi/whatever mit Moba-Software (egal ob frei oder sauteuer) ersetzen soll. Zumal die realgetreue Nachbildung des GBS dabei die größte Schwierigkeit darstellen würde. Dieses "zweifelhafte Vergnügen" hatte ich bereits vor Jahren und deshalb entstand das GBS in dieser Form.