Hallo Frank,

Zitat

---

Unglaublich: Der Decoder kann offentsichtlich die Motorumdrehungen messen/zählen.

---

Wie macht er das eigentlich? Und wie kann er selbständig z.B. einen deipoligen Popel-Motor von einem guten Fünfpoler unterscheiden?

Danke und Gruss,
Manfred

Hallo Manfred,

er macht es einfach, muss aber eingelernt werden!

Man muss erst mal irgendeine CV (Nummer leider nicht im Kopf) solange annähern , bis man den gewünschten konstanten Bremsweg hat. Die CV differiert je nach Modell beim gleichen Bremsweg. Den speichert man dann. Ich würde vermuten er merkt sich dabei die Umdrehungen * Pole (= "Kummutierereignisse"?).

Für einen sds wäre das wohl auch ein Kinderspiel. Aber obs bei dem "dank" Platine noch mit dem "konstanten Bremsweg" aus dem Third-Party Decoder klappt :

Viele Grüße
Frank

Hallo Manfred,

Richtung stellen muss.

Gruss Kurt

hallo Kurt,

Danke für den Link.

An irgendsowas dachte ich auch immer im Bezug auf eine Drehscheibenansteuerung. Wenn ich den Link richtig verstanden habe , misst man die EMK-Impluse am besten an einem Shunt der Motorleitung, und wertet mit OP aus.

Und doch Railcom, oops, muss ich noch mal gucken gehen, ich dachte HLU.

Danke und Grüße
Frank

Hallo Kurt,

hast recht Bidi=RailCom.

danke und grüße, schaue mir das morgen noch mal an.

Frank

Hi.
Nur um keine unnötige Verwirrung aufkommen zu lassen. Das mit der Genauigkeit von 1/10mm trifft auf die von mir bevorzugt (aber nicht ausschließlich) verwendeten Lenz Spur 0 Loks zu. Die haben alle serienmäßig eine geriffelte Schwungmasse, über die auch andere Features wie die Lastregelung oder der konstante Bremsweg geregelt (kontrolliert) werden. Vermutlich mit ein Grund, warum die Lenz Loks so phantastisch fahren.
Wenn man so hohe Genauigkeit braucht, muss man was vergleichbares in seinen Loks haben/einbauen. Wobei ich denke, ein Reedkontakt, wie er für den Sound bei Dampfloks nötig ist, dürfte wohl eine ausreichende Genauigkeit für den Normalfall liefern.

Hallo!
Weil hier diese Aussage getätigt wurde:

Zitat

---

Was ich meine ist folgendes... Es gibt doch diesen Werbespruch von wegen nur 2 Drähte ans Gleis, mehr braucht es bei Digital nicht. Das es so tatsächlich nicht ist, wissen wir inzwischen alle. Mit Railcom und den dazu gehörenden Detektoren braucht man nach der Tams Methode eben zwei Leitungen zusätzlich (für den RS-485 Bus), also 2 "Extra- Drähte".

---

NATÜRLICH *braucht* man "nur" zwei Drähte - ich fahre genau so!
Ich fahre aber auf Sicht, ohne Gleisabschnitte, Rückmeldung u.ä.

Mit anderen Worten heist das nicht mehr, als dass man bei Digitalbetriebe OHNE Abschnitte jede Lok auf jeder Position abstellen kann, dass jede Lok an jeder Position beliebige Funktionen auslösen kann (z.b. Entkuppeln).

Sobald man aber eine Rückmeldung - ich welcher Form auch immer, mit, oder ohne PC - haben will, *muss* man für jeden Abschnitt, der rückgemeldet werden soll eine extra Leitung einrechnen.
Entweder vom Abschnitt bis zum Schaltpult/PC, oder wenigstens bis zum Abschnitssmodul und dann einen "Rückmeldebus" bis zum Schaltpult/PC.

Bei Digitalbetrieb ist es ausserdem vorteilhaft, neben dem Gleis noch eine Ringleistung nutzen und alle paar Meter die DCC-Spannung einzuspeisen (wegen zb. der Übergangswiderstände der Gleisverbindungen).

DAS wären also die "zwei extra Leitungen" , die zitiert wurden....
Nun, wenn ich so eine 2-polige Ringleitung habe, kann ich daran aber auch die "Kilometersteine" (oder, wie sie auch immer heissen werden) anschliessen und mit Spannung versorgen, über die dann die jeweiligen Abschnitte versorgt werden.

Die 2-polige Ringleitung wird nun direkt mit der Zentrale verbunden. Ebenfalls werden diverse Dedectoren an die gleiche Leitung angeschlossen.

VON der Zentrale ZUR Anlage führen also in der Tat genau nur ZWEI Leitungen!

RailCom ist jetzt nichts anderes, als ein BIDIREKTIONALER DATENVERKEHR von der Zentrale zum Decoder und von diesem wieder zurück zur Zentrale/Dedektor.

Und sonst nichts!!!! GENAUSO, wie dies bei einem Netzwerk wäre - da gibt es auch nur zwei Leitungen für den gesamten Datenverkehr ... (Stichwort Telefon ...)

Railcom ist NICHT ABC, HLU, Gleisabschnittsmodul, Adressanzeige usw.

Was Ihr da also heiß diskutiert ist NICHT RAILCOM ! RAILCOM ist dafür nur die Grundlage .... nicht mehr und nicht weniger ...

Hallo Oliver, hallo Leute,

Zitat

---

Was Ihr da also heiß diskutiert ist NICHT RAILCOM ! RAILCOM ist dafür nur die Grundlage .... nicht mehr und nicht weniger ...

---

Sehr gut ausgedrueckt, danke dafuer

Bitte seht das Ganze etwas differenzierter. Die Funktionen, ueber die hier diskutiert werden sind Moeglichkeiten, Anwendungen, die eben auf RailCom basieren und jeweils einen unterschiedlichen Zweck dienen.

Die Adressanzeige (z.B. Lenz, Tams) ist eine davon, diese wird benoetigt, um eine Uebersicht darueber zu schaffen, welcher Gleisabschnitt von welcher Lok belegt ist. Dass da beim Tams-System noch ein RS485-Bus dabei ist ist ein Zugestaendnis an den Kunden und ist darin begruendet, dass Anzeige und Detektor voneinander getrennt sind. Wenn man einen Detektor und ein Anzeigemodul in ein Gehaeuse zusammenpackt hat man im Prinzip das, was Lenz auf seiner Homepage zeigt.

Die Meilensteingeschichte verfolgt einen ganz anderen Zweck. Damit laesst sich an der dafuer geeigneten Zentrale (duerfte auf Lenz und Zimo zutreffen) der Standort der Lok anzeigen, mit der man gerade faehrt. Zur Ueberwachung von Gleisabschnitten (Schattenbahnhof, Lokschuppen ect. ) ist das ungeeignet, genauso wie die Anzeigemodule ungeeignet zur "Zugverfolgung" sind.

Je nachdem was man benoetigt wird man sich die Komponenten zusammenstellen muessen und das koennte eine Einnahmequelle oder zumindest ein neues Betaetigungsfeld fuer die Fachhaendler sein. Man koennte einen Anlagenbauer vor Ort fuer einen gewissen Obulus (der vielleicht mit dem anschliessenden Kauf verrechnet wird) individuell beraten und die Moeglichkeiten aufzeigen. Je nachdem was der Anlagenbauer benoetigt kann er entsprechend investieren bzw. sparen.

So ist z.B. die Meilensteingeschichte fuer meine persoenlichen Beduerfnisse zwar interessant, wirklich benoetigen wuerde ich das nicht. Interessanter sind fuer mich die Adressanzeigen, wenn auch nur als Spielerei (auf 4qm kann ich voll auf Sicht fahren ). Wer dagegen viele nicht einsehbare Streckenabschnitte hat, wird sich ueber die Meilensteine freuen und Betreiber grosser Schattenbahnhoefe werden vermutlich Meilensteine und lokale Detektoren zur Adressanzeige kombinieren, wobei evtl. dem einen oder anderen auch die blosse Anzeige der Adressen der belegenden Loks reicht...

Was ich insgesamt etwas vermisse sind umfangreichere Informationen. Das, was ich selbst weis stammt groesstenteils von Kersten Tams, dessen Komponenten u.a. bei mir im Test sind. Ein bissi was findet man auf der Zimo-Homepage eine Seite mit grundlegenden Informationen kann man bei Lenz finden. Sucht man in Google nach RailCom findet man dieses Forum und Threads wie diesen . Das ist speziell ein Apell an Herrn Lenz als Initiator und Erfinder des Systems, hier ein wenig mehr Informationen zu veroeffentlichen, sonst koennte das RailCom-Thema schneller vom Tisch sein als es einem lieb ist (die meisten Meinungen sind wegen der Ungewissheit und mangelnden Informationen verhaltend bis abwartend).

Und natuerlich wuerde ich mich auch freuen, wenn Sie, Herr Lenz, auch an dieser Diskussion teilnehmen wuerden (wir beissen nicht, nicht mal virtuell )

Hallo an Alle,

immerhin habe ich mich die letzten Tage schon einmal angemeldet. Lese die Beiträge schon seit längerer Zeit und finde Niveau und Umgangsformen auf einem hohen Level. Anerkennung und Lob, auch an die "Aufsicht".

Das mit den eigenen Beiträgen wird sicher noch kommen. Jetzt befinde ich mich auf dem Weg zu einem Railcom Meeting das 750 km entfernt stattfindet. Ja wo wohl.

Gruß an Alle

Bernd Lenz, Lenz Elektronik GmbH

den Firmenzusatz werde ich in Zukunft weglassen.

Hallo nochmal,

etwas zum Photopeter moechte ich loswerden:

Zitat

---

Also da ist ESU wohl vorgeprescht und hat einen "Ist schon da-" Standard setzen wollen (ähnlich der neuesten WLan Generation, deren Specs noch gar nicht verabschiedet sind, sich alle Chiphersteller aber längst geeinigt haben und fleißig Geräte auf den Markt werfen).
Vorausgesetzt das es bei ESU vernünftig funktioniert, wäre es schon bedauerlich, wenn andere Hersteller hier wieder ihr eigenes Süppchen kochen würden.

---

Wenn ESU da ohne vorhandenen Standard einen "Ist-schon-da-Standard" zusammenwurstelt und diejenigen, die die Standards erarbeiten (RailCom-Arbeitsgruppe) etwas anderes definieren ist das das Problem von ESU. Dann haben nicht die anderen ein eigenes Sueppchen gekocht sondern ESU muss sein voreilig gekochtes Sueppchen ausloeffeln, bzw. sich anpassen.
ESU muss sich als Lizenznehmer an die Standards halten und nicht der Lizenzgeber an ESU.

Hallo Bernd Lenz,

Zitat

---

Das mit den eigenen Beiträgen wird sicher noch kommen. Jetzt befinde ich mich auf dem Weg zu einem Railcom Meeting das 750 km entfernt stattfindet. Ja wo wohl.

Gruß an Alle

Bernd Lenz, Lenz Elektronik GmbH

den Firmenzusatz werde ich in Zukunft weglassen.

---

es freut mich, auch von Ihnen zu lesen und wuensche fuer die 750km(!) eine gute Fahrt.
Wegen mir muessen Sie den Firmenzusatz nicht weglassen, solange dieser in Zusammenhang mit sachlichen Beitraegen steht und nicht der reinen Werbung dient
Vielen Dank auch im Namen der Anwender fuer das Lob bezueglich des Niveaus

Hallo!

Zur Aussage:

Zitat

---

Betreiber grosser Schattenbahnhoefe werden vermutlich Meilensteine und lokale Detektoren zur Adressanzeige kombinieren

---

möchte ich nur erwähnen, dass dies - überwachen / beeinflussen von Gleisabschnitten mit Anzeige der Digitaladresse und Rückmeldung sowohl an ein normales Gleisbild, als auch an einen PC - von ZIMO schon seit es ZIMO gibt, gelöst ist!

Natürlich gibt es inzwischen auch andere Lösungen (z.b "Lissy" u.ä.) aber NEU ist das alles nicht!
Dazu "braucht" man also kein Railcom - Railcom ermöglicht dies nur nun AUCH und u.U. einfacher.

Interessant sind die "Kilometersteine" imho im Zusammenhang mit einer autarken Fahrzeugbeeinflussung unter bestimmten Bedingungen.
Z.b. soll nur eine bestimmte Lok aus einer Richtung kommen, wenn sie in eine Linkskurve fährt den Sound des Schienenquitschens abspielen. Ist sie aus der Kurve raus, ist auch der Ton aus. Für mich hätte so ein Kilometerstein also solche u.ä. Spielereien.
Ebenso warte ich auf eine Signalbeeinflussung als HLU OHNE Gleisbaschnitssmodule wie MX9 und Buskabel etc.
Das höchste der Gefühle ist eben die bereits erwähnte 2-polige Ringleitung.

Ich habe als Gartenbahner aber ganz andere Ansprüche, als der klassiche H0-Bahner - was sich ja schon bei den Funktionen, die ich mir in meinen Loks erwarte, wiederspiegelt!
Eine H0-Lok muss gesteuert werden können und das Licht muss schaltbar sein. Wenn sie jetzt noch das rote Rücklicht, oder bei USA-Loks den einen oder anderen Lichteffekt (Ditchlights u.ä.) kann, ist das eh schon meist alles, was man sich in H0 wünscht und Platzmäßig verbauen kann.
Jetzt kommt noch Soun dazu - wird bei einigen Fahrzeugen aber schon schwer bis nicht möglich sein, weil einfach der Platz nicht vorhanden ist.

Effekt wie, automatisch ferngesteuertes Entkuppeln, zu öffnende Türen, Panthografensteuerung usw. wird man vielleicht bei *einem* Modell realisieren - wenn überhaupt.

Bei meinen Gartenbahnfahrzeugen gibt es in JEDEM Modell alle erdenklichen Funktionen - eben alle, die das jeweilige Modell können soll (wenn Türen, dann sind diese zu öffnen, Kupplung ist überall realisiert, Lichteffekte auch, Rauch nicht nur bei Dampfloks - da gepulst wo möglich, oder wenigstens Lastabhängig, sondern auch bei Dieselloks und natürlich lastabhängig usw.) Sound hat sowieso jedes Modell und der ist je nach Betriebssituation entsprechend - um diesen noch lebendiger zu gestalten warte ich daher noch auf den einen oder anderen Effekt ... und da kommt mir Railcom sehr gelegen!

Mit anderen Worten: Railcom ist die Basis, die bestimmte Anforderungen und Wünsche erst ermöglichen wird - jemand der diese Anforderungen nicht hat, wird auch die Basis nicht brauchen.
Nur darf man deswegen NICHT automatisch davon ausgehen, weil man selber diese Anforderung nicht hat, dass diese "eh keiner braucht"!

Hi.

Zitat von Muenchner Kindl

---

...Wenn ESU da ohne vorhandenen Standard einen "Ist-schon-da-Standard" zusammenwurstelt und diejenigen, die die Standards erarbeiten (RailCom-Arbeitsgruppe) etwas anderes definieren ist das das Problem von ESU...

---

Natürlich ist das dann ein Problem von ESU, aber leider nicht nur von ESU. Denn alle Kunden, die jetzt eine Ecos haben (dürften nicht wenige sein) und eben das nun mal vorhandene Feature "Weichenrückmeldung übers Gleis" nutzen (wollen), sind genau so "gelackmeiert". Vor allem, wenn von einer entsprechenden Normierung noch weit und breit nichts zu spüren ist. Wie gesagt, ich gehe davon aus, das ESU hier einfach die im Haus bereits vorhandene MFX Technik auf DCC und Railcom übertragen hat, und deswegen so schnell ein entsprechendes Produkt im Markt hat. Es würde mich nicht wundern, wenn es (vorausgesetzt MFX überlebt so lange) es in 2, 3 Jahren einen "K89- MFX" Weichendecoder von Märklin (vorausgesetzt Märklin überlebt so lange) gibt, der verdächtig große Ähnlichkeit mit dem ESU Switchpilot hat.
Wobei ich vermute (hoffe), dass man als User im Zweifel nur ein Software- Update der Decoder und der Ecos machen muss und eigentlich im Alltag gar keinen Unterschied feststellt.

Vielleicht könnte Herr Tams oder Herr Lenz mal "aus dem Nähkästchen" plaudern, wie weit es um diese (imho elementare) Railcom Anwendung bestellt ist. Ich würde mir für meinen "Eigenbedarf" eine "2 Stufen Lösung" wünschen. Zum einen eine einfache Meldung des Decoders: "Jawoll, ich habe den Befehl zum umschalten bekommen und ihn ausgeführt. Die Weiche XY steht jetzt meinem Kenntnisstand nach auf Abzweig", welche der Decoder auf Anfrage (oder kontinuierlich) aussendet. Zum anderen dann natürlich das Rückmelden echter Kontakte z.B. an den Weichenzungen oder am Stellservo, um eine wirklich 100% Kontrolle zu ermöglichen. Die 100% Lösung wäre dann für wichtige Weichen wie z.B. die Einfahrtsgruppe im SBHF sinnvoll und die "Einfach- Lösung" dann z.B. in der Ausfahrtsgruppe oder bei weniger wichtigen Abstellgleisen u.Ä.

Ganz kurz dazu:

Zitat

---

Denn alle Kunden, die jetzt eine Ecos haben (dürften nicht wenige sein) und eben das nun mal vorhandene Feature "Weichenrückmeldung übers Gleis" nutzen (wollen), sind genau so "gelackmeiert".

---

OK, es geht zwar um ungelegte Eier aber wenn es denn so waere, dann waere auch das ein Problem von ESU. Wenn die sich das RailCom-Papperl drankleben wollen muessen sie auch den RailCom-Standard einhalten, nicht umgekehrt.
Dass das Material evtl. aus der mfx-Entwicklungsabteilung kommt waere keine Entschuldigung.
Aber wie gesagt, es geht um ungelegte Eier, auf denen wir nicht weiter herumtrampeln sollen.

Hallo Thomas,

Zitat

---

Zugerkennung
Pendelzugsteuerung
Lokabhängige Schattenbahnhofsteuerung
Digitale Blocksteuerung
Geschwindigkeitsmessung
Anfahr- und Bremsverzögerung an Signalen
Automatische Steuerung von Sonderfunktionen
Arbeitet ohne jede Gleisunterbrechung

LISSY besteht aus einem Infrarot-Sender, der am Fahrzeug montiert wird, und einem Empfängermodul, dessen beide Infrarot-Sensoren ins Gleis eingebaut werden. Die vom Infrarot-Sender gemeldete Lokadresse und Zugkategorie wird vom Empfänger erkannt und ans LocoNet übermittelt. Zusätzlich sind, ohne den Einsatz eines Computers, verschiedende automatische Steuerfunktionen zu realisieren: LISSY erkennt die Lok und zeigt an, welcher Zug auf Gleis x des Bahnhofs eingefahren ist. LISSY steuert den Pendelzugverkehr im Endbahnhof der eingleisigen Nebenbahn. LISSY verwaltet Ihren Schattenbahnhof und findet selbständig für jeden Zug ein individuelles Gleis und lässt bei Bedarf die Züge automatisch wieder aus dem Schattenbahnhof herausfahren. LISSY ist ein neuartiges Blocksystem für Digitalanlagen und steuert die Blockstrecken auf der Anlage automatisch, ohne Einsatz eines Computers. LISSY bremst jede Digital-Lokomotive vor einem roten Signal mit der decoderinternen Bremsverzögerung langsam ab. LISSY misst die Geschwindigkeit vorbeifahrender Lokomotiven maßstabgetreu. LISSY schaltet situationsabhängig den Sound von Lokomotiven, z.B. den Pfeifton vor dem Tunnel oder das Signalhorn am Bahnübergang vor der Pfeiftafel. LISSY blendet bei Fahrten in unsichtbare Bereiche (Schattenbahnhof, Tunnel) den Sound von mit "IntelliSound" ausgerüsteten Lokomotiven aus. LISSY schaltet das Licht einer bestimmten Lok nach einer bestimmten Zeit ein oder aus, z.B. wenn der Lokführer die Lok abgestellt hat. LISSY steuert die Geschwindigkeit von Loks, z.B. in Bahnhofseinfahrten oder Langsamfahrstrecken. LISSY arbeitet ohne jede Gleisunterbrechung und kann deshalb leicht nachträglich in jede Modellbahnanlage eingebaut werden.
Die Kontrolle erfolgt über das Display der Intellibox oder über das LocoNet-Display Art.-Nr. 63 450.

---

(Kopiert von der Uhlenbrock-Seite: Uhlenbrock -> Produkte -> Digital ->
Automatik -> LISSY)

LISSY benötigt LocoNet, der "Kilometerstein" (oder "Meilenstein", wie im Thread öfters geschrieben) nach ZIMO - und dort im MX82 Weichendecoder realisiert - setzt auf RailCom (Ähmm, tut er das wirklich, auf dieser zusätzlichen Kommunikationebene, siehe Zitat unten) und ist, bzw. wäre damit vom Gerätebus des jeweiligen Systemlieferanten unabhängig.

Welchen Leistungsumfang ZIMO damit anstrebt, ist
einstweilen unklar, da kein ZIMO-Fahrzeugdecoder und auch keiner anderer Hersteller den Kilometerstein mit seinen Infrarotsignalen bisher unterstützt.
Jedenfalls ensteht hier wieder Normungsbedarf, wenn die Sache nicht proprietär bleiben soll.

Beide Verfahren teilen sich eine Gemeinsamkeit: Sie arbeiten punktuell und nicht linear oder abschnittsbezogen und eben "lokindividuell" - das "LI" in LISSY - nicht auf den ganzen Zug bezogen wie eine Belegtmeldung.

Je nach gefordertem Sicherheitsstandard überschneiden sich die Lösungsangebote - punktuell vs. abschnittsbezogen - weitgehend.

Zitat

---

Der Magnetartikel Decoder als "elektronischer Kilometerstein"

Nicht nur die RailCom Hardware, sondern auch Anschlüsse für Infrarot-Leuchtdioden (sende- und empfangsseitige) wurden in alle MX82 seit Produktionsbeginn im Jahr 2005 vorausschauend eingebaut; waren bisher allerdings ohne Funktion. Jetzt wird die Funktion "Kilometerstein" in Betrieb genommen, eben falls durch die Software-Version 9, welche in den zukünftigen neuen MX82 von Vornherein enthalten ist, und in "ältere" durch Update eingebracht werden kann.

Die Funktion "Kilometerstein" bedeutet das permanente Infrarot-Aussenden eines in (neuen) Konfigurationsvariablen des MX82 zu definierenden Daten-Codes. Dazu wird am betreffenden Ausgang ("infrarot out") eine handelsübliche Infrarot-Leuchtdiode angeschlossen, und diese zwischen den Gleis-Schwellen eingebaut.

Die Funktion "Kilometerstein" wird im MX82 (alle Typen) praktisch kostenlos mitgeliefert, da natürlich die normalen Aufgaben wie Weichen- und Signalschalten uneingeschränkt weiterhin übernommen werden.

DIe ZIMO Großbahn Decoder sind für den Anschluss von Infrarot-Empfangsdioden vorbereitet, welche in Zukunft (nach entsprechenden Software-Updates des Decoders) das vom MX82 ausgesandte Signal beim Überfahren der entsprechende Stelle empfangen und auswerten können. Für zukünftige ZIMO Decoder anderer Baugrößen ist diese Technik ebenfalls vorgesehen.

Es wird verschiedene Anwendungen für diese zusätzliche Kommunikationsebene geben: allgemeine Information des Decoders über die aktuelle Position, Beeinflussung von Geschwindigkeit und Fahrtrichtung (Anhalten, Langsamfahren, Pendeln, ...) Auslösen von Funktionen (Pfiffe, .. als flexiblere Version der alten Methode "Reed-Kontakte"), Beeinflussung des Sounds (z.B: Voraus-Indikation einer kommenden Steigung), u.a.

Übrigens: Die Technik des "elektronischen Kilometersteins" hat auch viel mit Vorbildtreue zu tun, allerdings bezogen auf den zukünftigen Eisenbahn-Betrieb. Das gerade in Erprobung befindliche ETCS (European Train Control System) wendet "elektronische Kilometersteine" an (von hier stammt die Bezeichnung ...), welche zwar nicht auf Infrarot-Basis, aber nach der gleichen Logik arbeiten, um den Zügen die genaue aktuelle Position zu übermitteln.

---

Das obige Zitat stammt von der ZIMO-Seite.
(Sind die hier angeführten "Kilometersteine" nicht jene "Euro-Balisen", die der Korrektur der durch das GPS ermittelten Zugsposition dienen?)

Gruss,
Manfred

Hallo,

nachdem sich hier eine sehr interessante und auch kompetent besetzte Diskussionsrunde zusammengefunden hat, möchte ich auch mal meine Gedanken zu dem Thema äußern.

Zuerst einmal denke ich, dass dieser Schritt eine bidirektionale Kommunikation einzuführen der richtige ist. Zu den darauf basierenden Anwendungen wird uns in den kommenden Jahren bestimmt noch manch unerwartetes begegnen, an das wir heute noch nicht denken.

Was die Lösung der Kilometersteine mit Infrarot Übertragung angeht, so bin ich wie auch bei der Lissy Lösung skeptisch, denn eigentlich habe ich keine Lust noch Dioden in den Fahrzeugen oder Gleisen einzubauen und zu justieren. Ich denke BiDi sollte eher den Weg ebnen davon wegzukommen.

Für eine Rückmeldung eines Abschnittes würde ich sagen sollte die Zentrale oder ein anderer globaler Detektor die vorhanden lokalen Detektoren nach ihrem Zustand und der darin befindlichen Adresse abfragen. In einem Zwischenschritt könnte diese Meldung auch über ein Hersteller spezifisches Bussystem laufen, doch das Ziel wäre meiner Meinung nach die Übertragung übers Gleis.

Weiter würde ich mir wünschen das es die Möglichkeit gibt, über Railcom DCC Befehle abzusetzen. So könnte z.B. der lokale Detektor der Lok in dem Abschnitt einen Haltebefehl geben und diese so gezielt anhalten. Auch Funktion könnte man so an einem bestimmten Punkt auslösen lassen. Also die Zentrale empfängt die Railcom Message und wandelt diese in einen DCC Befehl um.

Was ich leider so in Railcom noch nicht sehe, ist die Möglichkeit, dass der Dekoder in einer Lok eine Broadcast Message der lokalen Detektoren empfängt und dann selber darauf reagieren kann. Hier sehe ich im Moment nur die Variante, dass die Zentrale diese Informationen, wenn sie sie von den lokalen Detektoren erhält, den Dekodern in eine CV schreiben. So könnte der Dekoder in der Lok seine Position bestimmen, analog zu der Infrarot Methode wie bei Zimo beschrieben.

Gruß
Michael

Hallo!

Zitat

---

... Zum anderen dann natürlich das Rückmelden echter Kontakte z.B. an den Weichenzungen oder am Stellservo, um eine wirklich 100% Kontrolle zu ermöglichen.

---

Wenn schon eine *echte* Rückmeldung, dann ausschließlich die Stellung der Weichenzunge! Nicht irgendwelche Kontakte am Stellmotor selbst.
Die übrigens bei Servoantrieben NICHT nötig sind!
Einfach, weil an der Datenleitung des Servos eben genau die Daten anliegen, die dafür nötig sind, um den Servo in die gewünschte Stellung zu bringen und diese dann auch zu HALTEN!
Wenn man nun also den Stellarm manuell bewegt (so man das überhaupt könnte), würde dieser automatisch von selbst wieder in die gewünschte Endstellung zurückdrehen.
Allerdings wird man das nicht so ohne weiteres und vorallem zerstörungsfrei für das Getriebe des Servos zusammenbekommen.

Deshalb steuert der Stellarm normalerweise ja nie direkt, sondern immer über eine Feder o.ä. die Weichenzungen an. Dadurch kann man diese ja auch Aufschneiden (so das Herzstück nicht polarisiert ist) - genaus , wie bei einem Motorantreib (immer davon ausgehend, dass der Antrieb selbst funktioniert).

Bei einem herkömmlichen Weichenantrieb (nicht Motorantrieb) wird ja meist beim Aufschneiden auch der Antrieb verstellt, bzw. kann ich diesen trotz digitalem Signal manuell verstellen - DANN "braucht" man irgend eine Form der Rückmeldung und da reicht dann schon die Gewohnte über eben Kontakte des Antriebs.

Ich selbst nutze Servos zum Stellen von Weichen - die Servostellung brauche ich nicht abfragen - die Stellung der Weichenzungen aber schon eher, da ich nicht weis, ob nicht ein Stein o.ä. das Anliegen der Weichenzunge verhindert.

DAS ist allerdings ein "Problem" und Wunsch, das schon seit Modellbahngenerationen exisitert, aber meist aus Gründen des Aufwandes kaum realisiert wurde. Rückmeldungen gibt es ja schon seit "Analogzeiten" - das ist ja nix Railcom-spezifisches ... nur wer hat schon SO eine Rückmeldung realisiert? Die meisten nutzen lediglich Kontakte des Stellmotors oder der Endabschaltung - fragen also alles nur nicht die tatsächliche Stellung der Weichenzunge ab

Railcom könnte jetzt lediglich die Rückmeldeleitungen "einsparen", da die Kommunikation ja nun in beide Richtungen über die Schiene statt findet.

Hallo Michael,

(Sorry an Thomas, Danke für M3 Aufklärung, den ich lange Zeit als Michael titulierte)

Zitat

---

Was die Lösung der Kilometersteine mit Infrarot Übertragung angeht, so bin ich wie auch bei der Lissy Lösung skeptisch, denn eigentlich habe ich keine Lust noch Dioden in den Fahrzeugen oder Gleisen einzubauen und zu justieren. Ich denke BiDi sollte eher den Weg ebnen davon wegzukommen.

---

Obwohl sich ja der Wegfall der Gleistrennungen mit dem Mehraufwand der Loknachrüstung verrechnen liesse, und die Rechnung ggf. auch zu Gunsten der Loknachrüstung ausfallen könnte, haben die punktuellen Lösungen aus meiner Sicht einen wesentlichen Nachtteil: Sie erfordern zur sinnvollen Auswertung meist eine Intelligenz in Form von programmierbarer Zentrale bis hin zum PC. Sie sind also nur was für grosse globale Lösungen. Da sie im Stand nicht nicht kommunizieren, sind sie meineserachtens schwieriger handhabbar.

Zitat

---

Für eine Rückmeldung eines Abschnittes würde ich sagen sollte die Zentrale oder ein anderer globaler Detektor die vorhanden lokalen Detektoren nach ihrem Zustand und der darin befindlichen Adresse abfragen. In einem Zwischenschritt könnte diese Meldung auch über ein Hersteller spezifisches Bussystem laufen, doch das Ziel wäre meiner Meinung nach die Übertragung übers Gleis.

---

Ich denk auch das das "Bussytem" noch lange notwendig sein wird, da ansonten die Anlage nicht beliebig wachsen kann. Eine Standardisierung bzw. Vereinheitlichung des Bussystems würde der DCC-Welt aber sehr zu gute kommen.

Es handelt sich beim RailCom rein elekrotechnisch um eine Sende- und nicht um ein Abfrage-System, so das Lok(Weichen)-Info sendende Anwendungen bevorzugt sein werden. Das Abfragen spezieller Info geschieht nur in sehr indirektem kleinem Rahmen, da hier auch DCC selbt erst mal zur Formulierung der Abfragen weiterentwicklt werden müsste.

Zitat

---

Weiter würde ich mir wünschen das es die Möglichkeit gibt, über Railcom DCC Befehle abzusetzen. So könnte z.B. der lokale Detector der Lok in dem Abschnitt einen Haltebefehl geben und diese so gezielt anhalten. Auch Funktion könnte man so an einem bestimmten Punkt auslösen lassen. Also die Zentrale empfängt die Railcom Message und wandelt diese in einen DCC Befehl um.

---

Das der lokale Detector der Lok einen Befehl gibt, geht nicht über Railcom, eigentlich nicht mal über DCC. Lokale Lokbeeinflussung jedweder Form war eigentlich immer schon eine Lücke in Digital der Digitalen Welt, RailCom stopft diese nicht. Mittlerweile biten vermehrt die Hersteller entsprechende Zusatzeinrichtungen an. Was die Fahrbefehle in DCC angeht, ist hier ABC hoffentlich der Standard, das einfach und effektiv. Mehr und differenzierter gabs wohl nur bei Zimo HLU. Komliment an Zimo, das sie ABC trotzdem unterstützen. ABC wird den Grossbahnern und einigen H0-Bahnern an dieser Stelle wahrscheinlich zu wenig sein, da hier keine Sounds und Sonderfunktionen getriggert werden können.

Ach ja, Du hast Recht: Lokaler Detector UND ABC in einem Gerät wären was Suuuuper Feines. Geniale Idee! Herr Rapp, bitte an die Arbeit ! Ein "BM-RailCom" wäre ne tolle Sache, z.B. wenn er 4 Schaltaugänge hätte, die per "BroadCast"-Mapping jede beliebe RailCom-Loko-Info auswertbar machen würden. Am besten mit LS150 Treiber dahinter.

Zitat

---

Was ich leider so in Railcom noch nicht sehe, ist die Möglichkeit, dass der Dekoder in einer Lok eine Broadcast Message der lokalen Detektoren empfängt und dann selber darauf reagieren kann. Hier sehe ich im Moment nur die Variante, dass die Zentrale diese Informationen, wenn sie sie von den lokalen Detektoren erhält, den Dekodern in eine CV schreiben. So könnte der Dekoder in der Lok seine Position bestimmen, analog zu der Infrarot Methode wie bei Zimo beschrieben.

---

ABC ist das BraodCast von Gleisabschnitt an alle den jeweilgen Gleisabschnitt befahrenden Loks. RailCom ist das Broadcast der LokInfo an die lokalen Detectoren aller befahrenen Gleisabschnitte und an Booster/Zentrale.

Wieso sollte die Loko ihre Position bestimmen? Was kann sie damit anfangen? Ich habe den Nutzen nicht nicht verstanden, vielleicht weil ich in Kenntnis und unter Akzeptanz des faktischen schon "betriebsblind" bin. Könntest Du das noch mal ausführlich und gesondert erklären :

Viele Grüße
Frank

Hallo Frank,

Zitat

---

Zitat

---

Was die Lösung der Kilometersteine mit Infrarot Übertragung angeht, so bin ich wie auch bei der Lissy Lösung skeptisch, denn eigentlich habe ich keine Lust noch Dioden in den Fahrzeugen oder Gleisen einzubauen und zu justieren. Ich denke BiDi sollte eher den Weg ebnen davon wegzukommen.

---

Obwohl sich ja der Wegfall der Gelistrennungen mit dem Mehraufwand der Loknachrüstung verrechnen liesse, und die Rechnung ggf. auch zu gunsten der Loknachrüstung ausfallen könnte, haben die punktuellen Lösungen aus meiner Sicht einen wesentlichen Nachtteil: Sie erfordern zu sinnvollen Auswertung immer eine Intelligenz in Form von programmierbarer Zentrale bis hin zum PC. Sie sind also nur was für grosse globae Lösungen.

---

Die Frage ist ja, was ich mit den Informationen machen will. Will ich sie direkt vor Ort nutzen (bsp. Zugnummernanzeige), so brauche die Intelligenz vor Ort und je nach Anwendung kann man die dann noch geringfügig anpassen aber im großen und ganzen kann solche Applikationen mehr oder weniger aus der Box benutzen.
Will ich aber irgendwelchen anderen Bereiche beeinflussen, so muss ich die Verknüpfungen ja irgendwie den Modulen beibringen. Das über CVs oder ähnliches zu machen ist natürlich sehr aufwendig. (sieh Lissy und TrackControl) Hier ist zum in Betrieb nehmen auf jeden Fall ein PC oder eine Zentrale mit großem Display hilfreich. Wobei dies ja ein einmaliger Vorgang ist.

Was wäre deine Alternative? Die gesamte Intelligenz gleich zentral anzusiedeln?
Was jetzt ein größerer Aufwand ist, das Gleis aufzutrennen und die Kabel anzuschließen oder die Loks umzubauen und zusätzlich noch die entsprechenden Dioden im Gleis zu versenken, muss man wohl von Fall zu Fall betrachten. Doch stelle ich mir den Umbau von Loks komplizierter vor, zudem dort bei manchen Menschen die Hemschwelle auch größer sein dürfte.

Zitat

---

Zitat

---

Für eine Rückmeldung eines Abschnittes würde ich sagen sollte die Zentrale oder ein anderer globaler Detektor die vorhanden lokalen Detektoren nach ihrem Zustand und der darin befindlichen Adresse abfragen. In einem Zwischenschritt könnte diese Meldung auch über ein Hersteller spezifisches Bussystem laufen, doch das Ziel wäre meiner Meinung nach die Übertragung übers Gleis.

---

Es handelt sich beim RailCom rein elekrotechnisch um eine Sende- und nicht um ein Abfrage-System, so das Lok(Weichen)-Info sendende Anwendungen bevorzugt sein werden. Das Abfragen spezieller Info geschieht nur in sehr indirektem kleinem Rahmen, das hier DCC erst mal zur Formulierung der Afragen weiterentwicklt werden müsste.

---

Soweit ich das verstanden habe, gibt es ja zwei Bereiche in Railcom. Zum einen den Broadcast, der z.B. zur Anzeige der Lokadressen verwendet wird und dann noch das gezielte Abfragen eines Dekoderwertes. Wobei mir hier noch nicht klar ist, ob sich der Dekoder selber meldet, wenn er etwas zu Senden hat oder ob er dort von der Zentrale gepollt wird.

Das Melden des Zustandes der Kilometersteine ist ja auch eine sendende Applikation. Nur dass man dafür einen Befehlssatz analog zu den Weichenrückmeldungen definieren müsste.

Zitat

---

Zitat

---

Weiter würde ich mir wünschen das es die Möglichkeit gibt, über Railcom DCC Befehle abzusetzen. So könnte z.B. der lokale Detektor der Lok in dem Abschnitt einen Haltebefehl geben und diese so gezielt anhalten. Auch Funktion könnte man so an einem bestimmten Punkt auslösen lassen. Also die Zentrale empfängt die Railcom Message und wandelt diese in einen DCC Befehl um.

---

Das der lokale Detector der Lok einen Befehl gibt, geht nicht über Railcom, eigentlich nicht mal über DCC. Lokale Lokbeeinflussung jedwewrder Form war eigentlich immer schon eine Lücke in Digital der Digitalen Welt. Mittlerweile versuchen vermehrt die hersteller das durch Zusastzeinrichtungen zu lösen. Was die Fahrbefehle in DCC angeht, ist hier ABC hoffentlich der Standard, das einfach und effektiv. Mehr und differenzierter gabs wohl nur bei Zimo HLU. Komliment an Zimo, das sie ABC trotzdem unterstützen.

Ach ja, Du hast Recht: Lokaler Detector UND ABC in einem Gerät wären was Suuuuper Feines. Geniale Idee! Herr Rapp, bitte an die Arbeit !

---

Ja aber genau hier ist der Punkt. Welche Nachrichten über Railcom versendet werden ist ja egal. Und wenn ich nun eine Message definiert habe, die einen DCC Befehl enthält. So könnte jeder Dekoder oder andere an das Gleis angeschlossenen Baustein diese Befehle senden. Die Zentrale (oder ein globaler Detektor mit Anschluss an den Bus der Zentrale) empfängt diese Railcom Messages und übersetzt sie originales DCC, welches sie dann wieder auf das Gleis schickt.
So könnte man prinzipiell auch Handregler direkt ans Gleis anschließen.

Hier hätte man in einem lokalen Bremsmodul alle Informationen beisammen. Über die Broadcast Message erfährt der lokale Detektor die Adresse der Lok oder den Zugtyp. Über Railcom sendet er dann an die Zentrale einen Befehl, dass diese Lok nun einen bestimmte Geschwindigkeit fahren soll. Die Zentrale passt den DCC Datenstrom dementsprechend an.
Die bisherigen Bremsgeneratoren hatten ja das Problem mit Kurzschlüssen, da sie nur den DCC Datenstrom in ihrem Abschnitt angepasst haben.

ABC war hier der Versuch dies zu umgehen, indem in einer Ebene außerhalb von DCC kommuniziert wurde. Das erfordert daher entsprechende Dekoder in den Loks. Wobei ich sagen muss, dass dies von der Einfachheit, was die zusätzliche Streckenausrüstung angeht, genial ist.

Zitat

---

Zitat

---

Was ich leider so in Railcom noch nicht sehe, ist die Möglichkeit, dass der Dekoder in einer Lok eine Broadcast Message der lokalen Detektoren empfängt und dann selber darauf reagieren kann. Hier sehe ich im Moment nur die Variante, dass die Zentrale diese Informationen, wenn sie sie von den lokalen Detektoren erhält, den Dekodern in eine CV schreiben. So könnte der Dekoder in der Lok seine Position bestimmen, analog zu der Infrarot Methode wie bei Zimo beschrieben.

---

Nochmal: ABC ist das BraodCast von Gleisabschnutt an alle den Gleisabschnitt befahrenden Loks. RailCom ist das Broadcast der LokInfo an die lokalen Detectoren aller befahrenen Gleisabschnitte und an Booster/Zentrale.

Wieso sollte die Loko, Ihre Position bestimmen? Was kann sie damit anfangen? Ich habe den Nutzen nicht nicht verstanden, vielleicht weil ich in Kenntnis und unter Akzeptanz des faktischen schon "betriebsblind" bin. Könntest Du das noch mal ausführlich und gesondert erklären :

---

Das die Loks ihre Information bestimmen, so habe ich zumindest den oben zitierten Text von der Zimo Hompage verstanden. Also der Kilometerstein sendet über Infrarot seine Kennung an den Lokdekoder. Dieser ist nun so programmiert, dass er entweder direkt darauf reagiert (Geräusch abspielen) oder er sendet die Meldung "bin gerade an Kilometerstein xy vorbeigekommen" über Railcom an den globalen Detektor.

Wenn sich diese Identifikation der Kilometersteine auch direkt über Railcom an die Lok übermitteln lassen, dann gut. Ansonsten bin ich wie gesagt gegen eine Infrarotlösung und würde eher vorschlagen, dass der Kilometerstein mit seinem lokalen Detektor die Adresse der überfahrenden Lok ausliest. Diese Message dann über Railcom an den globalen Detector weitergibt, oder direkt diese Information in einen DCC Befehl, der über Railcom verschickt wird, umsetzt ("Lok xy soll Geräusch abspielen / anhalten").
Die Zentrale könnte nun, wenn die Intelligenz wirklich in der Lok gespeichert werden soll, an der Lok einen entsprechenden CV umprogrammieren und dort den Kilometerstein xy eintragen. Dann kann der Lokdekoder von mir aus auch selbständig reagieren und z.B. ein Geräusch abspielen.

Ich wäre aber wie gesagt dafür, diese ganze Intelligenz lokal im Detektor abzulegen. Ob dies nun das Auslösen von Funktionen oder die Änderung von Geschwindigkeiten sind. Und um hier die größtmögliche Freiheit zu haben, würde ich mir einen Kommunikationsweg für DCC Befehle über Railcom wünschen.

Ich hoffe ich habe es jetzt etwas verständlicher ausgedrückt.

Gruß
Michael

Hallo Frank,

Zitat

---

Die Frage ist ja, was ich mit den Informationen machen will.

---

Genau das sollte bei jeder Überlegung im Vordergrund stehen. Leider ist es oft so, das manche Produzenten immer noch unter dem Zwang stehen, etwas beweisen zu müssen, z.B. das sie etwas „Auch“ oder „Besser“ oder „Umfangreicher“ (z.B. 32.000 Loco-Funktionen) können, und somit bestimmte Lösungen am Markt dutzendweise auftreten. Wenn der Mobahner mehr nach konkreten Lösungen für seine Vorstellungen suchen würde, würder diese sicherlich grösste Marktsegment nicht nötig sein, und in Folge weniger für Verwirrung sorgen. Andererseits senkt es die Preise, das ist ja auch schon was.

Zitat

---

Will ich sie direkt vor Ort nutzen (bsp. Zugnummernanzeige), so brauche die Intelligenz vor Ort und je nach Anwendung kann man die dann noch geringfügig anpassen aber im großen und ganzen kann solche Applikationen mehr oder weniger aus der Box benutzen.

---

Richtig und Richtig. Was man lokal erledigen kann, sollte man besser auch lokal erledigen, Der Loop über intelligente Zentralen und PCs zurück an den Einsatzort ist immer eine Verkomplizierung, ein potentieller Störgrund, und eine zeitliche Verzögerung, und somit für ein Steurungssystem qualtitätsmindend.

Zitat

---

Will ich aber irgendwelchen anderen Bereiche beeinflussen, so muss ich die Verknüpfungen ja irgendwie den Modulen beibringen. Das über CVs oder ähnliches zu machen ist natürlich sehr aufwendig. (sieh Lissy und TrackControl) Hier ist zum in Betrieb nehmen auf jeden Fall ein PC oder eine Zentrale mit großem Display hilfreich. Wobei dies ja ein einmaliger Vorgang ist.

---

Zitat

---

Was wäre deine Alternative? Die gesamte Intelligenz gleich zentral anzusiedeln?
Was jetzt ein größerer Aufwand ist, das Gleis aufzutrennen und die Kabel anzuschließen oder die Loks umzubauen und zusätzlich noch die entsprechenden Dioden im Gleis zu versenken, muss man wohl von Fall zu Fall betrachten. Doch stelle ich mir den Umbau von Loks komplizierter vor, zudem dort bei manchen Menschen die Hemschwelle auch größer sein dürfte.

---

Der PC bleibt bei hier mit weit verbeiteten preiswerten Standarddecodern ab mittleren und gerade bei grossen Anlagen die billigste Alternative. Nicht die beste, Nicht die Ergonimischste und auch nicht die lehrreichste oder verständlichste. Ein komlexes virtuelles Modell simuliert alles im PC und „kommandiert“ die Anlage, die sich allerdings bei allzu günstigen Komponenten dagegen zu wehren weiss.

Die Alternative: Seit den 60ern funktion weltweit jedes Vorbild mit ca 14 Relais pro Weiche unübertroffen ergonomisch bedienbar (2-Tasten-Prinzip, unerreicht mit dem PC, trotz Milliarden von „Relais“). Das ist aber nur möglich, weil es den Lokführer und Signal gibt. Die Technik braucht dem Steuerer nur das Steuern besagter Elemente zu ermöglichen, der Lokführer macht den Rest.

Die mangelnde lokale Beeinflussungsmöglichkeiten im Digitalsystem der Moba hat die PCs und intelligentere Zentrale erforderlich gemacht.
Die Lösung: Die Loko muss „Signale“ und „Tafeln“ sehen können. Da wir wissen das das so nicht geht, ist hier die Weiterleitung der Info über Signalbilder und Weichenstellungen an die Loko notwendig, und somit lokale Zugbeeinflussung.

Zitat

---

Soweit ich das verstanden habe, gibt es ja zwei Bereiche in Railcom. Zum einen den Broadcast, der z.B. zur Anzeige der Lokadressen verwendet wird und dann noch das gezielte Abfragen eines Dekoderwertes. Wobei mir hier noch nicht klar ist, ob sich der Dekoder selber meldet, wenn er etwas zu Senden hat oder ob er dort von der Zentrale gepollt wird.

---

„Eigentlich“ sendet der Loko-Decoder erst mal immer nur sein Adresse ins Gleis. Andere Info (Route? Geschwindigkeit? Traktionsart? Zuglänge? ich weiss es nicht? ) sind als konfigurierbare Daten vorgesehen. Der Decoder könnte auch auf einen an Ihn adressierten Befehl mal was besonderes erzählen. Z.B. während der Pom_Programmierung auf dem Normal-Gleis, bei der man bisher ja nicht die aktuellen werte auslesen konnte. Dies könnte man global im Handregler oder Lokal am Display an der Strecke anzeigen. Werbung für eine meineserachten noch bessere Lösungen bitte bei Lenz nachlesen (Stichwort V3.6).

Es gibt also beides Broadcasten und Antworten auf gefragtes bzw. gepolltes. Den Pollen kommt eine besondere Bedeutung zu: Da im DCC normalerweise die fahrenden Lokos kontinierlich wiederholend Ihre Fahrbefehle erhalten, kann dieser zyklisch wiederholte Bgleichzeitig als Pollen verwendet werden, so das es sogar denkbar ist, das die Lokos mittels dieses „Pollens“ syncgronisiert und somit quasi gleichzeitig und faktisch nacheinander verständlich ins Gleis senden.

Zitat

---

Das Melden des Zustandes der Kilometersteine ist ja auch eine sendende Applikation. Nur dass man dafür einen Befehlssatz analog zu den Weichenrückmeldungen definieren müsste.

---

Wäre ein Beispiel für pollend, jedesmal wenn die Loko Ihren zyklischen Farbefehl bekommt, sendet sie auch den zuletz überfahrenen KM-Stein ins Gleis. So senden alle Lokos quasi gleichzeitig an die Zentrale, auch ohne Gleisabschnitte. Da die Weichen keine zyklisch wiederholten Befehle erhalten, ist das Verfahren so einfach nicht übertragbar. Deswegen weiss ich leider nicht, und habe auch keine Vermutung , wie die Weichen RM via RailCom in die Zentrale kommt :

Zitat

---

Ja aber genau hier ist der Punkt. Welche Nachrichten über Railcom versendet werden ist ja egal. Und wenn ich nun eine Message definiert habe, die einen DCC Befehl enthält. So könnte jeder Dekoder oder andere an das Gleis angeschlossenen Baustein diese Befehle senden. Die Zentrale (oder ein globaler Detektor mit Anschluss an den Bus der Zentrale) empfängt diese Railcom Messages und übersetzt sie originales DCC, welches sie dann wieder auf das Gleis schickt.

---

Das geht so nicht. Komplette DCC Befehle sind zu lang für RailCom (ich glaube einmal 12 und optional nocxh mal 24 Bit pro DCC-Befehlstakt sind drin, vorsicht, könnte mich irren). Niremand ausser der Zentrale kann DCC-Befehle generieren, da die Befehls-Codierung keine unterschiedlichen Befehle zwei Quellen zulässt. Damit kommt man wieder in die ursprüngliche Bremsmodul-Problematik, bei der das Bremsmodul letztendlich eine eigene Zentrale ist, deren Übergang zur richtigen entsprechend problematisch ist.

Bleibt also nur Info zu Senden und mittelbar über Systembus oder direkt über die Zentrale die Info auszuwerten und entsprechende befehle zu generieren. Damit sind wir wieder bei den „Intelligenten“ Zentralen bzw. bei PCs.

Zitat

---

Hier hätte man in einem lokalen Bremsmodul alle Informationen beisammen. Über die Broadcast Message erfährt der lokale Detektor die Adresse der Lok oder den Zugtyp. Über Railcom sendet er dann an die Zentrale einen Befehl, dass diese Lok nun einen bestimmte Geschwindigkeit fahren soll. Die Zentrale passt den DCC Datenstrom dementsprechend an.

---

Hier liegt der Vorteil von ABC zumindest in der Paarung mit Railcom in dem oben erdachten „BM-Railcom“ . Der Lokale Detector wird wie ein Dispatcher angewiesen, auf bestimmte Loko-Info entsprechendes zu veranlassen. In obiger Version analog über Schaltausgänge, oder durch ABC-Beeinflussung (Lok anhalten oder weiterfahren).

Was Dir vorschwebt wäre wohl es die KM-Stein Variante: Die Lok sendete an Zentrale die Position und Ort und die zentrale sendet entsprechende Befehle. Eigentlich ein Geschichte für globales Railcom (das meineswissens auch immer trotz lokalem Detector vollständig mithört).

Der Unterschied ist die Frage wen und wo programmiert man: Lokal oder global? Meineserachtens ist lokal einfacher und sicherer. Global wird umständlicher ab evtl billiger, da eine embedded Zentrale oder PC vermutlich günstiger sind, als zig Lokele Auswertungen.

Zitat

---

ABC war hier der Versuch dies zu umgehen, indem in einer Ebene außerhalb von DCC kommuniziert wurde. Das erfordert daher entsprechende Dekoder in den Loks. Wobei ich sagen muss, dass dies von der Einfachheit, was die zusätzliche Streckenausrüstung angeht, genial ist.

---

ABC war kein Versuch , sondern ABC ist eine funktionierende Alternative. Unsere Verein-Modulbahn käme nicht mehr ohne aus.

Zitat

---

Was ich leider so in Railcom noch nicht sehe, ist die Möglichkeit, dass der Dekoder in einer Lok eine Broadcast Message der lokalen Detektoren empfängt und dann selber darauf reagieren kann.

---

So ist ja auch der lokale Detector nicht definiert, er empfängt nur von der Loko. Die gegenrichtung ist zur zeit ABC oder HLU, wenn auch bei weitem nicht so differenziert einsetzbar wie DCC-Befehle.

Zitat

---

Das die Loks ihre Information bestimmen, so habe ich zumindest den oben zitierten Text von der Zimo Hompage verstanden. Also der Kilometerstein sendet über Infrarot seine Kennung an den Lokdekoder. Dieser ist nun so programmiert, dass er entweder direkt darauf reagiert (Geräusch abspielen) oder er sendet die Meldung "bin gerade an Kilometerstein xy vorbeigekommen" über Railcom an den globalen Detektor.

---

Ganz vielen Dank für die Info. Wenn der km-Stein nämlich auch per Infrarot noch mehr „Befehle“ an die Loko senden kann, als die ABC kann,
so lässt sich damit die lokale Steuerung , bzw. das Sehen des Lokführers lokaler Tafeln z.B. zum Pfeiffen und Stromabnehmer einziehen

Zitat

---

Wenn sich diese Identifikation der Kilometersteine auch direkt über Railcom an die Lok übermitteln lassen, dann gut. Ansonsten bin ich wie gesagt gegen eine Infrarotlösung und würde eher vorschlagen, dass der Kilometerstein mit seinem lokalen Detektor die Adresse der überfahrenden Lok ausliest. Diese Message dann über Railcom an den globalen Detector weitergibt, oder direkt diese Information in einen DCC Befehl, der über Railcom verschickt wird, umsetzt ("Lok xy soll Geräusch abspielen / anhalten").

---

Verstehe, dazu würden abber dann die wertvollen RailCom-Channels doppelt belastet: Einmal zur Übertragung an lokalen Detector und Nochmal zur Übertragung von lokalen Detector zu Globalen. Für letzeres wäre der Systembus der geeignetere, das dieses ungleich höhere Datenvolumina bewältigen kann. Am Gleis hat man das Wunderwerk eines ErnergieDatenStroms. Dies hat seine Grenzen. Die Daten die über Ihne gehen sind besonders wertvoll und teuer. Bei RailCom womöglich mehr noch als bei DCC.

Zitat

---

Die Zentrale könnte nun, wenn die Intelligenz wirklich in der Lok gespeichert werden soll, an der Lok einen entsprechenden CV umprogrammieren und dort den Kilometerstein xy eintragen. Dann kann der Lokdekoder von mir aus auch selbständig reagieren und z.B. ein Geräusch abspielen.
Ich wäre aber wie gesagt dafür, diese ganze Intelligenz lokal im Detektor abzulegen. Ob dies nun das Auslösen von Funktionen oder die Änderung von Geschwindigkeiten sind. Und um hier die größtmögliche Freiheit zu haben, würde ich mir einen Kommunikationsweg für DCC Befehle über Railcom wünschen.

---

Jetzt hab ich verstanden. Habe aber die zitierten Vorbehalte bzgl. Machbarkeit. Intelligente lokale Detectoren die via ABC, Schaltausgang oder Infrarot die Loko und Weichen befehligen würde ich sehr begrüssen. Die Kombi aus ABC für die 3 Fahrstufen und Infrarot sonstiges lokales, das im dem fahrenden Zug übermittelt werden soll, scheint mir zur Zeit das maximal machbare an Lokaler Beeinflussung, und es wäre toll, wenn jemand das alles in ein „Zauberkästchen“ packen würde


Ich hoffe ich habe es jetzt etwas verständlicher ausgedrückt.

Danke hast Du,
und Grüße Frank

Hallo Frank,

erst mal vielen Dank auf den Hinweis mit der V3.6 bei Lenz, die war noch an mir vorbeigegangen.

Ich denke was unsere Meinung über den PC darstellt, sind wir uns einig.

Zitat

---

„Eigentlich“ sendet der Loko-Decoder erst mal immer nur sein Adresse ins Gleis. Andere Info (Route? Geschwindigkeit? Traktionsart? Zuglänge? ich weiss es nicht? ) sind als konfigurierbare Daten vorgesehen. Der Decoder könnte auch auf einen an Ihn adressierten Befehl mal was besonderes erzählen. Z.B. während der Pom_Programmierung auf dem Normal-Gleis, bei der man bisher ja nicht die aktuellen werte auslesen konnte. Dies könnte man global im Handregler oder Lokal am Display an der Strecke anzeigen. Werbung für eine meineserachten noch bessere Lösungen bitte bei Lenz nachlesen (Stichwort V3.6).

---

Tut mir Leid, aber da finde ich auf der Hompage nur die Anzeige der CV im LRC120. Was meinst du damit?

Was die Lösung über ABC Bausteine mit Railcom angeht, so denken wir in die gleiche Richtung. Ich wollte auch nicht abstreiten das ABC funktioniert, das war rein gar nicht meine Absicht. Nur wollte ich gerne von ABC weg, um flexibler zu sein. Da ABC ja leider nur einen sehr begrenzten Befehlssatz hat und zudem nicht mit allen Dekodern funktioniert.
Ich wollte halt anstelle der ABC Befehle einen "ordentlichen" DCC Befehl generieren lassen. Da dieser ja nur von der Zentrale gesendet werden kann, ist die Frage wie kommt er dahin. Bleibt zum einen ein separater Bus oder der Baustein wird regelmäßig von der Zentrale / globaler Detektor gepollt und übermittelt den Befehl so zur Zentrale.

Das dies natürlich zusätzliche Datenrate kostet ist mir klar. Was aber hier noch nicht kam, ist dass man durch Quittierung der Befehle sich ein gelooptes Aussenden sparen kann und nur noch Befehlsänderungen übertragen muss. Von daher wäre in dem DCC Zyklus durchaus Platz zum Pollen der Kilometerbausteine. Das man dies sinnvoller auf einem separaten Bussystem macht bestreite ich nicht, doch dann ist man wieder Hersteller abhängig.
Vor allem fällt mir als ein solches Bussystem im Moment nur LocoNet ein. X-Bus ist durch seine Beschränkung auf 31 Teilnehmer wohl nicht in der Lage noch viele lokale Detektoren mit aufzunehmen. Bei den anderen Bussystemen kenne ich keine offen gelegten Protokolle, so dass ich dies einschätzen kann.

Was die Übertragung eines DDC Befehls in einer Channel2 Fenster einer Railcom Message angeht, so mag das sein, dass dies von der Länge nicht in einem geht. Da könnte man den Kilometerstein ja auch entsprechend mehrmals pollen. Gut geht dann wieder auf die Datenrate aber bei kleinen Anlagen durchaus die Möglichkeit auf das Gleis als alleinigen Steuerbus zu kommen. Für größere Anlagen dann natürlich sinnvoller Weise auf einem separaten Bus.

Die Zentrale braucht aber weiterhin keine zusätzliche Intelligenz, außer dass man ihr die Liste der zu pollenden Dekoder mitgibt oder die Steuerinformationen analog zu denen von anderen Eingabegeräten aus dem Bus weiterzuleiten..


Die Kilometerstein Variante setzt wohl auf eine zentrale Intelligenz. Also Broadcast der Kilometerstein / Infrarotübermittlung und lokale Detektoren in den Dekodern. Diese Position wird dann an den globalen Detektor von den Lokdekodern übermittelt. Also im Prinzip genau andersherum als die obere Variante. Broadcaster und lokale Detektoren sind vertauscht und da man die Auswertung dieser Informationen wohl nicht im Lokdekoder selber machen will, braucht man wohl eine zentrale Intelligenz.
Aber mal eine andere Überlegung: Wenn man schon die lokalen Detektoren in den Lokdekoder verbaut, warum nutzt man dann die Broadcast Message der Kilometersteine nicht für Steuerinformationen? So könnte man Geschwindigkeiten vorgeben oder Funktionen auslösen und zwar an alle Loks in diesem Abschnitt, also auch Mehrfachtraktionen. Wobei dort die leicht verzögerte Übermittlung auch zu Problemen führen könnte, denn die Loks fahren ja erst nacheinander in den Abschnitt ein. Dafür bleiben Mehrfachtraktionen bei der oberen ja wohl außen vor, zumindest, wenn man es ohne ABC macht. Die Frage wäre auch wie man dann die Steuerinformationen der Zentrale mit den aktuellem Lokstatus wieder synchron kriegt. Dafür müsste der Dekoder wohl beim nächsten Pollen diese geänderten Informationen zurücksenden. Dies macht dann aber eine virtuelle Verfolgung in einem PC Steuerprogramm wohl unmöglich.


Wie man sieht, sind dies unterschiedliche und auch sich gegenseitig ausschließende Ansätze. Doch sie zeigen, was für Möglichkeiten einem die bidirektionale Kommunikation bieten kann. Wie und wer dies nun Produkte umsetzt, das wird die Zukunft zeigen.

Gruß
Michael

Hallo Michael,

ich muss ins Bett, lese deswegen morgen noch mal richtig.

Ich glaube wir haben aber gerade den Infrarot als Sender für erweiterte lokale Lokobefehle erfunden. Und nach dem, was weiter oben Manfred /Digilox schreibt, und Du bereits angedeutet hat, war Zimo mal wieder schneller.

Die Mischung aus ABC und Infrarot wäre wohl eine echte Bereicherung .

Danke für die Ideen und bis bald
Frank

p.S. : in der Einsparung des geloopten Aussendens sehe ich auch grosse Weiterentwicklung, die die so frei werdende Übertragungszeit tatsächlich für erweiterte Funktionalität freischaufeln könnte. Sowas würde man auch "gesicherte Datenübertragung" bezeichnen können, und den Mobahner im Fall der Fälle über evtl. Missstände im system informieren.

Hallo!
Vielleicht verstehe ich ja etwas falsch, aber ABC steht für "AutomaticBrakingControl" -> siehe:
http://www.digital-plus.de/digitalplus/digitalplus_abc.php

Das "Bremsmodul" ist im Grunde nichts weiter, als Dioden, die das DCC Signal Asymetrisch machen, wodurch der Decoder (wenn er dies auswerten kann) eben abbremst und anhält.

Von WELCHEM "Befehlssatz" sprechen wir hier bitte?!

Leute seit mir nicht böse, aber wenn ich diese Beiträge so lese drängt sich mir der Verdacht auf, dass einige keine Ahnung haben was ABC technisch ist, von Railcom - trotz mehrfacher Erklärungen - ganz zu schweigen und was ABC mit Infrarot zu tun hat, entzieht sich mir auch (eine Lok die nicht fährt, kann ein Sendesignal auch nicht aufnehmen, wenn sie es eben nicht überfährt - agal ob nun HLU, ABC, oder einfach manueller Halt).

Hier werden Dinge diskutiert, die nichts miteinander zu tun haben und zu Konstrukten verwurschtet, die abenteuerlich sind.

Hallo Oliver,

wie schon gesagt der "Befehlssatz" von ABC ist sehr gering. Er kennt nur die Zustände: Anhalten, verminderte Geschwindigkeit, keine Beeinflussung und das für eine Fahrtrichtung. Das dies über die Asymmetrie des Digitalssignals läuft ist klar.

Franks Idee war ja nun, dass ein lokaler Detektor dynamisch entscheidet ob er das Signal asymmetrisch verändert je nachdem welche Lok vorbeikommt. So könnte man z.B. Personenzüge im Bahnhof anhalten lassen und Güterzüge durchfahren, unabhängig von der Signalstellung.
Da er aber gerne mehr Einfluss auf den Lokdekoder haben wollte, dann die Idee anstelle von ABC eine Infrarot Kommunikation. Also Lok wird durch lokalen Detektor erkannt und dementsprechend werden über Infrarot dann entsprechende Befehle ein paar cm weiter übertragen. Hier ließen sich neben Geschwindigkeitsänderungen z.B. Funktionsbefehle übertragen.

Wie schon geschrieben, halte ich persönlich von der Infrarot Methode nicht sonderlich viel, da sie zusätzlichen Mehraufwand bedeutet. Und auch auf ABC würde ich verzichten wollen.

Wenn du die von mir angesprochenen Befehlssätze angeht, so meinte ich welche analog zu den in RP 9.3.2 (komm gerade nicht auf die NMRA Seite, deswegen kann ich nicht nachschauen obs die war) definierten z.B. zur Rückmeldung der Weichenlage. Also zum einen eine Message mit dem ein lokaler Detektor die empfangene Lokadresse dem globalen Detektor mitteilen kann.
Zum anderen eine Möglichkeit über eine Message der Zentrale die Aufforderung zu geben einen DCC Befehl abzusetzen.

Gruß
Michael

Servus Michale!
Ohne jetzt den Oberlehrer hervorzukehren - auch wenn ich das doch tue

Ein "Befehlssatz" ist ein DCC-Befehl, wie er von der Zentrale versendet wird. Man könnte auch noch die HLU-Methode von ZIMO als "Befehlssatz" bezeichnen. Auch ein DCC-Bremsgenerator versendet einen Befehl.

ABC versendet keine Befehle. Hier wird nur mittels Dioden das DCC-Signal asymetrisch gemacht. DAS wiederum muss der Decoder auswerten können, um dann die vordefinierte Konfiguration abzuarbeiten.
Also entweder immer anzuhalten, oder nur in einer Fahrtrichtung etc.

Es gibt aber derzeit nur einige Decoder, die ABC auswerten können - noch weniger, die HLU verstehen (nicht vergessen - das sind unterschiedliche Systeme!).

Was Dir vorschwebt - wenn ich Dich richtig interpretiere - ist, dass eine Lok nun auf einen bestimmten Abschnitt fährt, via Railcomdedektor erkannt wird um welche Lok(adresse) es sich handelt und dananach entschieden wird, ob die Lok nun mittels ABC anhält oder nicht.
was sich so NICHT im Decoder realisieren lässt. Es wüden auch keine "Befehel" versandt werden. Es würde lediglich der Railcomdedektor das DCC-Signal entweder direkt, oder über Dioden (also asymetrich) an die Gleise des Abschnittes anlegen.

Dies ist aber im Grunde schon jetzt realisierbar - halt ohne Railcom, eben zb. über Gleisabschnittsmodule via "Bus" mit Rückmeldung an den PC o.ä.
Ich fürchte es wird sich mit Railcom da auch nicht viel ändern - nur der "Bus" würde entfallen - an einem Ende wäre nach wie vor ein Gleisabschnitssmodul, am Anderen der PC.

Das liegt aber daran, dass die "Intelligenz" nicht im Decoder, sondern eben in der Zentrale/PC liegt.

Selbst wenn ein Kilometerstein mit Infrarotsignalen einen bestimmten Befehl aussendet, müsste der Decoder über eine Intelligenz verfügen um diese auszuwerten und danach entsprechend zu handeln.

Mit derzeitigen Decodern und CPUs , Speicher etc. ist das SO nicht möglich. Obwohl ja Uhlenbrock mit der Pendelautomatik die Intelligenz dafür in den Decoer gepackt hat, was ZIMO zb. in der Zentrale abwickelt, ist das nicht vergleichbar.

Vorstellbar wäre, dass eine "Teilintelligenz" an den Dedektor abgegeben wird, der eben bei Erkennen bestimmter DCC-Adressen das "ABC-Signal" anlegt. Dieser Dedektor ist wie ein Decoder konfigurierbar. Ich schreibe also in seine CVs auf welche Adressen er wie reagieren soll.
Er kann aber keine Befehle selbst absetzten - das sieht die Technik derzeit nicht vor. Er müsste immer an die Zentrale rückmelden.

Nur ist dann so ein Dedektor nicht mehr billig! Der Vorteil von ABC ist ja, dass es konkurenzlos billig ist - sonst könnten ja alle ZIMOs HLU und MX9 nutzen! Oder eben entsprechende PC-Programme mit Gleisabschnitssmodulen und DCC-Bremsgeneratoren.

Technisch ist auch heute schon alles realisierbar. Aber es muss erstens benutzbar sein und zweitens bezahlbar!

Hallo Oliver,

Zitat

---

Von WELCHEM "Befehlssatz" sprechen wir hier bitte?!

---

wie hatten uns "stillschweigend" darauf geeinigt.

ABC als zwei 3 wertige Befehle in den isolierten Abschnitt anzusehen

3 Befehle nach Osten :
{"Frei Fahrt" (HP1); "Langsame Fahrt" (HP2); "Halt" (HP0)}

und dieselben 3 Befehle nach Westen:
{"Frei Fahrt" (HP1); "Langsame Fahrt" (HP2); "Halt" (HP0)}

Das Geniale daran, ist das so die Himmels/Gleisrichtung angegeben werden kann.

HLU kann mehr, ist aber auch komplexer und teurer. Wie das hier mit Himmelsrichtungen ist, weiss ich nicht mehr, aber ich glaube sie könnens auch :

ob analog oder digital codiert (wenigsten HP2 hat ja zumindest digitalen Flair) war dabei nicht wichtig. Deswegen bricht man für HP2 auch etwas mehr Elektronik als nur für HP0 und HP1 .

Grüße
Frank

p.S.: "Brems... - EDIT: "Bremgenerator " war gemeint - meint landläufig was anderes. Ein Mini-Zentrale bei der wirklich ausschliesslich der digitale Halt-befehl generiert wird, und die Schinen so komplex beschaltet werden müssen, das man das Wort getrost vergessen kann . Allenfalls noch etwas zur Umrüstung von klassichen Analoganlagen, mit 2-gleisig getrennter Z-Schaltung.