Hallo Joachim,

die Position einer Lok wird gar nicht mitgeteilt. Das System funktioniert nur als ein/aus und kann keinerlei Zugpositionen verfolgen oder intelligent verarbeiten.

Es merkt sich nach dem Neustart nur, welche Befehle Loks und Weichen hatten und lässt sie so wieder weitermachen. Vorher fahrende Loks fahren wieder an usw.

Ein S88 Rückmelder gibt der Zentrale nur an, dass er ausgelöst wurde, aber diese weiß nicht, von wem.

Daher meine Idee, dass man mit deinen S88 die Möglichkeit nutzt, freiprogrammierbare Befehle für unbestimmte Loks mit S88 Lok-Erkennung zusammenzuführen.

Dazu muss aber ein bestimmtes Fahrzeug an einer Stelle erkennbar sein und das S88 so programmierbar sein, dass es die Erkennung in eine einstellbare variable, von dem erkannten Fahrzeug abhängige S88 Kontaktmeldung übersetzen kann.

Also z.B. Lok x hat mich gerade passiert, ich melde S88 Nr. 45 als belegt. Die Zentrale hat unter S88 Nr 45 den Befehl hinterlegt, Lok x bei Belegtmeldung pfeifen zu lassen und für 45 sec. anzuhalten.

Das würde dann ermöglichen, dass je nach Programmierung Lok x an der Stelle 1 (diese befindet sich z.B. an der Bahnhofseinfahrt) z.B. den Befehl erhält zu pfeifen und durchzufahren, Lok y, die z.B S88 Nr 46 erzeugt, an der Stelle 1 aber den Befehl anzuhalten (Personenzug im Bahnhof).

Die CS 2/3 Memorys funktionieren im Grunde wie Makroaufzeichnungen, die fast beliebig lange Befehlsfolgen abarbeiten können. Damit kann man alles programmieren, was man auch durch Tastendrücke kann, also z.B. Fahrstraßen, aber auch Kupplungswalzer, Lokfunktionen usw.
Ausgelöst werden sie entweder manuell oder durch ihnen zugeordnete S88-Meldungen.

Leider aber kann man über das S88 der Zentrale normalerweise nicht mitteilen, welches genaue Fahrzeug einen Punkt der Anlage passiert, sondern nur, dass irgendein Fahrzeug dort ist.

(komplizierte Fahrzeugbefehle sind bislang NUR dann sinnvoll, wenn immer nur dasselbe Fahrzeug Z auf einer Strecke fährt. Dieses kann dann z.b. Abbremsen und umkehren usw, aber wenn auch andere Fahrzeuge x oder y diese Stelle passieren, lösen sie diese Befehlsfolge aus, wodurch dann fälschlich wieder Fahrzeug z seine Befehle bekommt, obwohl es den bestimmten S88 gar nicht selbst ausgelöst hat).

Das ist sinnvoll für automatische Befehlsfolgen von Weichenstraßen oder Blocksystemen, aber noch interessanter wäre eben eine Möglichkeit, bestimmte Fahrzeuge an bestimmten Stellen S88 Befehlsfolgen auslösen zu lassen.

Kannst du das?

Hallo Lindi,

Das ließe sich hinkriegen. Grundsätzlich ist das kein Problem. Die Einspeisung von Rückmeldungs-Paketen, so wie für die CS2 definiert (nur dafür habe ich eine Spezifikation), ist per Netzwerk möglich. Netzwerk heißt, die CS2(oder CS3?) wird ans Netzwerk angeschlossen und mein Melder-Prozess erzeugt dieses Mapping.
Auf diesem Weg ist der Adressraum, der für das CAN Protokoll definiert ist, leicht zu erreichen. Die Abfolge des Einbindens eines neuen Melders ist mir noch nicht ganz klar, aber das wird man rauskriegen. Hat der Melder seine Adresse, kann man jedenfalls reichlich viele Kontaktnummern nutzen; soweit habe ich das verstanden.

Es muss aber klar sein: CAN Signale wird es von mir nicht geben, ist auch unnötig, da jede CS2 (3?) das in ein transparentes UDP Paket auf der Netzwerkleitung in beide Richtungen übersetzt.

Dieses Mapping auf Befehlsfolgen, Makros ist auch nur in der von Dir beschriebenen Weise sinnvoll.
Die Meldung von Schaltgleisen, wie bei S88 lässt sich offenbar mit CAN bzw. Netzwerk auch ohne Polling umsetzen. Die Kommunikation der Besetztmeldung in die CS kann also über Netzwerk in der einen oder anderen Weise erfolgen.

Ich hatte an die Ausgabe eines Schließers gegen Gleis-Masse, bzw. potentialfrei gedacht.
Er wird im von mir gedachten Anwendungsfall, Überwachung der Zugvollständigkeit, auch erst wieder frei, wenn der letzte Waggon des Zuges den Melder überfährt. Dieser Schließer fällt übrigens auch ab, wenn das Gleis spannungsfrei wird.

Wenn der Schließer unnötig ist, weil die Melder über meinen Melderprozess zentral ins Netzwerk einspeisen, ist sein Verhalten ja egal. Aber die 'frei'-Meldung käme auf jeden Fall erst am anderen Ende desselben Zuges oder wenn der nächste Melder erreicht wird und der Zug nur 1 Auslöser hat.
Bei Richtungsumkehr von einem Zug mit nur 1 Auslöser wird er ebenfalls erst bei erreichen des nächsten Melders in anderer Richtung frei.

Viele Details.

Viele Grüße
Joachim

Eine Ergänzung möchte ich einbringen, die als Verbesserung gedacht ist:
Die Schließer-Kontakte am Rückmeldegleis würden wieder eine ausladende Verdrahtung mit sich bringen.
Es erscheint mir praktischer, wenn ein der Zentrale nahes Interface mit vielen Kontakten diese Aufgabe für alle Rückmelder übernimmt.
Das vermeidet sehr viel umfangreiche, weiträumige Verkabelung in Fällen, wo nur diese Kontakte für die jeweilige Zentrale genutzt werden können. Außerdem kommt es meiner Intention näher, die Besetztmeldung möglichst nicht verdrahten zu müssen.
Das schließt ja nicht aus, so ein Relais nachrüsten zu können.

Im Normalfall soll der Rückmelder-Prozess, meine Software, alle Meldungen per Netzwerk-Protokoll bei der Anlagensteuerung einspeisen. Keine Kabel.
Bei Märklin CS2 (und 3) sowie RocRail geht das. Weitere Zentralen/Steuerungen müssen noch geprüft werden.

Moin,

ich habe gerade einmal die 1. Seite dieses Threads nachgelesen; alle Teilnehmer scheinen bis dahin noch nichts von RailCom gehört zu haben. Nun sind es leider nur neuere DCC-Decoder, die Rückmeldungen über Adresse, Fahrstufe, geschaltete Funktionen usw. über den am Rückmeldeabschnitt angeschlossenen, lokalen RailCom-Detektor aufnehemen und an die Zentrale weiterleiten können. Die Meldung geht blitzschnell. Das ist leider nichts für mfx oder mfx+, doch schon über 5 Jahre am Markt. Schaut mal über den Märklinzaun nach z.B. Tams.

Bin ganz deiner Meinung.

Es wäre halt gut, wenn man die Railcom+ - und die Märklinwelt (allein die Größe des Marktes!) doch sinnvoll zusammenbringen könnte.
Es gibt es ja sogar separate Railcom+ Sender, die man z.B. an Wagen/Loks usw. leicht zusätzlich anbringen kann.

Ich glaube, ein Melder, der empfangene Railcom+ -Identifizierungen in freiprogrammierbare S88-Rückmeldenummern übersetzen kann, wäre nicht schlecht für den Anfang. (Wieviele S88-Kontakte kann man eigentlich maximal anschließen? Das begrenzt die Möglichkeiten natürlich).

Das müsste halt ein Fachmann in ein Produkt übersetzen.

Zitat von Schwanck im Beitrag mfx-Rückmeldegleis

---

Moin,

ich habe gerade einmal die 1. Seite dieses Threads nachgelesen; alle Teilnehmer scheinen bis dahin noch nichts von RailCom gehört zu haben. Nun sind es leider nur neuere DCC-Decoder, die Rückmeldungen über Adresse, Fahrstufe, geschaltete Funktionen usw. über den am Rückmeldeabschnitt angeschlossenen, lokalen RailCom-Detektor aufnehemen und an die Zentrale weiterleiten können. Die Meldung geht blitzschnell. Das ist leider nichts für mfx oder mfx+, doch schon über 5 Jahre am Markt. Schaut mal über den Märklinzaun nach z.B. Tams.

---

Zitat

---

Bin ganz deiner Meinung.

Es wäre halt gut, wenn man die Railcom+ - und die Märklinwelt (allein die Größe des Marktes!) doch sinnvoll zusammenbringen könnte.
Es gibt es ja sogar separate Railcom+ Sender, die man z.B. an Wagen/Loks usw. leicht zusätzlich anbringen kann.

Ich glaube, ein Melder, der empfangene Railcom+ -Identifizierungen in freiprogrammierbare S88-Rückmeldenummern übersetzen kann, wäre nicht schlecht für den Anfang. (Wieviele S88-Kontakte kann man eigentlich maximal anschließen? Das begrenzt die Möglichkeiten natürlich).

Das müsste halt ein Fachmann in ein Produkt übersetzen.

---

Grundlage ist Railcom - in Märklin Signalwelt nicht verwendbar. Auch nicht in mitgezogenen Anhängern. Auch eine 'beschleunigte' Mfx Meldung ist nicht machbar, ohne die Dekoder zu stören

Ich nenne mal ein paar technische Hindernisse, die einer Gleis-gebundenen Übertragung im Wege stehen:
Die Einspeisepunkte von Boostern sind niederohmig, bis die sog. Austastlücke des Boosters, eine Freischaltung, ein Zeitfenster öffnet. Der Railcom Dekoder schickt dann aus seiner gepufferten Energie seinen 250kbit/sec Burst. Es gibt - auf die Anlage gesehen - nicht allzu viele dieser Lücken, deswegen hat man im BiDiB von Herrn Kufer ja auch konsequent Gleisabschnitte mit eigenem Booster und RailCom Empfänger. Dann geht schon was, man kann dann ev. sogar noch die Istgeschwindigkeit holen oder anderes. Aber vor allem die Adresse als Identifikation.
Die Mfx Decoder sind hierbei völlig außen vor. Deren Verfahren setzt auf 'Aufmodulation' und verlässt sich auf eine höhere Ausgangsimpedanz des Boosters bei höheren Frequenzen. Die Mfx Dekoder werden nicht hochohmig und dämpfen das Signal eines Railcom Dekoders damit ab. Die stören also.
Aber bis so ein Paket kommt, muss es angefordert werden und keine Kollision sollte das verzögern. Wenn das ganze fährt, wird das drastisch unsicherer. Bei Märklin Gleisen ist die Häufigkeit von Störungen durch kurzzeitige Kurzschlüsse größer, wahrscheinlich aus geometrischen Gründen an Weichen und Kreuzungen. Damit ist die Sicherheit einer erfolgreichen Übertragung kleiner.
Deswegen ist der Rückmelder per Massekontakt dort so erfolgreich, sie funktioniert einfach.

Um den kilometerlangen Drahtwirrwar zu vermeiden und trotzdem sichere Rückmeldung zu bekommen, habe ich auf den Funkkanal gesetzt. Da fest installierte Komponenten senden, ist das auch schnell und zuverlässig.

Zitat

---

Bin ganz deiner Meinung.

Es wäre halt gut, wenn man die Railcom+ - und die Märklinwelt (allein die Größe des Marktes!) doch sinnvoll zusammenbringen könnte.

---

Da bin ich ganz bei Dir, ich habe auch alles zugleich laufen. DCC, MM2, Mfx.

Zitat

---

Es gibt es ja sogar separate Railcom+ Sender, die man z.B. an Wagen/Loks usw. leicht zusätzlich anbringen kann.

---

Das wird nicht klappen, wenn man keine Austastlücke hat und wenn man sie hat, versacken die 30mA Sendungs-Strom in der Anlage. Es sei denn, man ist bereit, alle Meter einen Abschnitt aus Booster und Railcom Empfänger zu plazieren. Das ist mir zu aufwändig.

Zitat

---

Ich glaube, ein Melder, der empfangene Railcom+ -Identifizierungen in freiprogrammierbare S88-Rückmeldenummern übersetzen kann, wäre nicht schlecht für den Anfang. (Wieviele S88-Kontakte kann man eigentlich maximal anschließen? Das begrenzt die Möglichkeiten natürlich).

---

Das bringt dem Märkliner noch nix, denn er kriegt aus obigen Gründen keine Railcom Botschaft. Gar keine, wenn er die Mfx Methodik der Zentrale nutzt. Es gibt, je nach Zentrale und Software zwischen 16k und mehr Meldungs-Kontaktnummern. Da ist Platz.

Zitat

---

Das müsste halt ein Fachmann in ein Produkt übersetzen.

---

Das versuche ich. Als Elektro-Ing und Software-Entwickler müsste ich das können, wenn ich denn das nötige Wissen über das ganze Zeugs beieinander habe. Bis jetzt habe ich Zuversicht, das zu knacken. Die Grundlage, im Gleis eine schnell fahrende Voll-Metall-Lok mit RFID zu lesen, habe ich.

Hallo,

ausserdem kann der S88-Bus keine Adressen zurückmelden.

S88 ist einfach nur ein Schieberegister was "belegt" oder "frei" melden kann.

Märklin verbaut ein modernes System in der Zentrale (den seit Jahrzehnten im Kfz-Bereich bewährte CAN-Bus) nutzt ihn aber nicht.

Peter

Zitat

---

....... Märklin verbaut ein modernes System in der Zentrale (den seit Jahrzehnten im Kfz-Bereich bewährte CAN-Bus) nutzt ihn aber nicht.

Peter

---

.... und warum wohl ? ...... weil sich mit dem Sammelsurium an S-88-Zubehör immer noch gute Geschäfte machen lassen, vorwiegend von eingefleischten "Kabelverlegern" von Gestern.
So, das habe ich jetzt absichtlich mal überspitzt formuliert denn dies birgt auch die Gefahr dass sich die Kid´s von Heute nicht mehr für die Technik von Gestern interessieren, vor allem auf Grund des aufgerufenen Preises dieser "Altgeräte".

nix für ungut
Hubert

Gut... Joachim, nur müsste sich dein Gerät in der Märklinwelt sinnvoll nutzen lassen, sonst braucht es keiner.

Außerhalb Märklin gibt es bereits Railcom+, das ist also kein Markt mehr. Da gibt es schon esu, tams, ...

Nur innerhalb Märklin fehlt eine Identifikation, die der Märklinzentrale mitteilt, welche Lok gerade eine bestimmte Position passiert.

Hallo Lindi,

Zitat

---

Nur innerhalb Märklin fehlt eine Identifikation, die der Märklinzentrale mitteilt, welche Lok gerade eine bestimmte Position passiert.

---

Das wird dann allerdings Radio für Gehörlose, weil die Zentrale - zumindest nach meiner derzeitigen Kenntnis - diese Information weder verstehen noch verarbeiten kann.

Ob das CDB-System damit mehr anfangen könnte, sei dahingestellt. Dort nutzt man zwar den CAN-Bus, aber auch, soweit ich weiß, keine Lokidentifikation in Verbindung mit der Rückmeldung.

Für mich bleibt dann auch die Frage offen, welchen realen Mehrwert die identifizierte Rückmeldung bringt. Auswerten und somit nutzen können sie derzeit nur Computerprogramme, aber zumindest in meinem Horizont bringt sie keine Möglichkeiten, die nicht anderweitig längst realisiert sind: durch die logische Verfolgung der Zugfahrten "weiß" die Steuerung, welcher Zug wo ist und welchen Kontakt auslöst, und viele Programme können sogar virtuelle Kontakte zuverlässig auslösen, indem sie den genauen Ort des Zuges zu jeder Zeit berechnen. Das ist zwar prinzipiell technisch komplizierter, hat aber den Vorteil, daß der Kontakt durch Veränderung von Zahlenwerten verschoben werden kann und man nicht an der Anlage herumfummeln muß mit möglicherweise unangenehmen Folgen für die Ausgestaltung.

Von daher sehe ich eben den Nutzen der identifizierten Rückmeldung erst, wenn die Hochleistungs-Zentralen, die auch gewisse Automatiksteuerungen ermöglichen, diese Art der Rückmeldung verwerten können. Ansonsten ist der Informationsgehalt des modernisierten s88 völlig ausreichend - und wie Kersten Tams richtig schreibt, ist der s88 besser als sein Ruf.

Railcom ist in meiner Anlage nicht einsetzbar, aus mehreren, beschriebenen Gründen. Grundlegend ist, dass ich digitale Mischtechnik fahre und die Anlage dermaßen viele Weichen hat, dass ich ca. 50-60 Abschnitte bräuchte. Ich denke, dass die Kosten bei Railcom nicht zu verachten sind, bei mir und für mich: zuviel. Und da die Hälfte Märklin ist, sowieso nicht operabel.
S88 hat inzwischen ja spätestens seit S88N etwas vereinfachte, reduzierte Verdrahtung. Aber die ist fast irrelevant: Die Märklin Zentralen verarbeiten tausende Kontakte (>16000), die über entweder CAN oder alternativ auch Netzwerk gemeldet werden, Netzwerk ist für meine Anlage perfekt. S88 erlaubt durchaus Verschwendung für Meldungen der Sorte 'Lok 120 überfährt Punkt 2106'.
Damit ist man aus der Situation raus, dass es 'Radio für Gehörlose' wäre.
Damit kann die Märklin CS eine Menge beginnen. Railroc als Beispiel für Steuersoftware kann das ebenfalls, hat sogar schon eine Verwaltung für zusätzliche Kennungen von Waggons, Loks über RFIDs.
Wenn ich jetzt gar keine Meldeleitungen habe und die Meldungen bei Railroc über Netzwerk einspeise, logisch als S88 verwerte, bin ich am Ziel.
Wer eine CS von Märklin hat, ist ebenfalls am Ziel. Bei ESU müsste man viele Kontaktnummern spendieren, über andere Zentralen weiß ich weniger, aber S88 können alle.

.... genauso einfach war das gedacht:

Rückmeldung eines Schienenkontaktes über die Schiene an eine CS2 z.B.
Nicht mehr und nicht weniger !

Gruß
Hubert

Über die Schiene klappt das definitiv nicht, wenn es außerhalb des Programmiergleises geklappt hätte, dann gäbe es längst ein Produkt von Märklin.
Mfx kann das geforderte nicht leisten!
Aber von der Schiene über eine schnelle Funkverbindung an die CS2/3 ist machbar.

Zitat

---

........ Mfx kann das geforderte nicht leisten!

---

.... warum eigentlich ? ... die Lok ist bereits automatisch angemeldet und es müßte nur eine ja/nein Entscheidung rückgemeldet werden, die m.E. nicht so "zeitkritisch" wäre, wenn ich z.B. an verschmutzte Radreifen denke die ja jetzt auch schon den S88 manchmal verzögern.

Gruß
Hubert

Hallo Hebert,

Zitat

---

es müßte nur eine ja/nein Entscheidung rückgemeldet werden, die m.E. nicht so "zeitkritisch" wäre

---

auf welche Frage genau und von wem gestellt?

MfG

vik

.... von Hebert ?

Zitat

---

Zitat

---

........ Mfx kann das geforderte nicht leisten!

---

.... warum eigentlich ? ... die Lok ist bereits automatisch angemeldet und es müßte nur eine ja/nein Entscheidung rückgemeldet werden, die m.E. nicht so "zeitkritisch" wäre, wenn ich z.B. an verschmutzte Radreifen denke die ja jetzt auch schon den S88 manchmal verzögern.

Gruß


Hubert

---

Die Mfx Decoder könnten was melden, keine Frage. Aber sie dürfen nicht alle immer vor sich hinplappern 'ich heiße 33' - Es braucht einen Anlass.
Ich habe hier im Forum schon von Verzögerungen um eine halbe Sekunde gelesen - das ist viel zuviel.
Es gehen offenbar viele Zeitfenster bis zur Meldung verloren.
Was sowohl Railcom als auch Mfx verbindet, ist der Umstand, dass im Wendebetrieb meist doch nur ein Dekoder da ist (Funktionsdekoder am anderen Ende setze aber auch ich ein). Da hat S88 definitiv den Vorteil, dass die Anwesenheit reicht.

Hallo zusammen,

Zitat von Schwanck im Beitrag mfx-Rückmeldegleis

---

..... noch nichts von RailCom gehört zu haben. Nun sind es leider nur neuere DCC-Decoder, die Rückmeldungen über Adresse, Fahrstufe, geschaltete Funktionen usw. über den am Rückmeldeabschnitt angeschlossenen, lokalen RailCom-Detektor aufnehemen und an die Zentrale weiterleiten können. Die Meldung geht blitzschnell. Das ist leider nichts für mfx oder mfx+, doch schon über 5 Jahre am Markt. Schaut mal über den Märklinzaun nach z.B. Tams.

---

Hallo Peter,[quote="Peter BR44" post_id=2016136 time=1569842875 user_id=4178]

hier ein paar Zahlen von Thorsten Mumm zu den Sendezeiten.
SX-Protokoll benötigt 75 ms
MM-Protokoll 14 ms
DCC 7ms
mfx/M4 4 ms
[/quote]
das scheint mir ein Mißverständnis. Hier im Thread geht es in erster Linie um die Rückmeldezeit.

MfG

vik

Die Meldezeit setzt sich aus diesen Übertragungszeit und der davor liegenden Zeit bis zur Ausgabe zusammen.
An dem Protokoll liegt es also zunächst nicht.
Was ich persönlich beobachte, ist oft eine gewisse Zeit, bis Mfx Decoder ein Paket als für sie bestimmt akzeptieren. Das sind dann Wiederholzyklen der Zentrale, bis ein Kommando angenommen wird. Was in den verlorenen Zyklen schiefgelaufen ist, verraten sie nicht
Wenn also jemand berichtet, er hätte eine halbe Sekunde Verzögerung beobachtet, glaube ich das.

Zitat

---

Die Meldezeit setzt sich aus diesen Übertragungszeit und der davor liegenden Zeit bis zur Ausgabe zusammen.
An dem Protokoll liegt es also zunächst nicht.
Was ich persönlich beobachte, ist oft eine gewisse Zeit, bis Mfx Decoder ein Paket als für sie bestimmt akzeptieren. Das sind dann Wiederholzyklen der Zentrale, bis ein Kommando angenommen wird. Was in den verlorenen Zyklen schiefgelaufen ist, verraten sie nicht
Wenn also jemand berichtet, er hätte eine halbe Sekunde Verzögerung beobachtet, glaube ich das.

---

Mit einer halben Sekunde Verzögerung hätte ich keine Probleme, da der S88-Bus in Praxis oft noch größere Verzögerung aufweist durch verschmutzte Gleise bzw. Räder, wenn man die klassische Auslösung durch Isolierung einer Schienenseite beim Gleis zu Grunde legt.

Hubert

Eine halbe Sekunde wäre auf meiner Anlage, wo ein Weichenfeld mit dem nächsten abwechselt, schon unbrauchbar. Man müsste bei so großer Toleranz schon einen weiteren Abschnitt vorher hinzunehmen, dort zu früh auf Schneckentempo runterregeln, um am Ziel so einigermaßen genau vor Weichen und Signalen zum Stehen zu kommen.
Mein Melder schafft < 50 msec insgesamt, von Einfahrt in das Meldegleis bis Meldung in der Zentrale und das auf 10 msec genau. Der größte Ungenauigkeitsfaktor ist der Unterschied der Loks/Waggons untereinander. Der ergibt sich aus den Feldstärken für den Leser, die bei Kunststoffmaterial und Zinkdruckguss recht unterschiedlich sind.
Eine gleiche Lok wird immer gleichartig schnell erkannt.
Da ich etliche TGVs, ICEs und andere Schnellzüge fahren lasse, muss das einigermaßen gut klappen, sonst gibt das Probleme im Bahnhofsbereich.