[Lindilindwurm]

Meine Anlage: CS2 betreibt Schaltdecoder & Steuerung, Züge fahren über 6017 Booster. Normalerweise klappt alles, ABER:

Manchmal sind Loks mit mfx- bzw. Sounddecoder nicht ansteuerbar und verhalten sie wie tot. Erst, sobald ich in der CS2 das Werkzeug-Symbol der Lok aufrufe (also das Fenster für die Einstellungen der Lok) wird sie angesprochen und sie schaltet sich ein. Verändert wird von mir sonst nichts an den Einstellungen, also es genügt, das Werkzeug-Symbol anzuwählen.

Was ist da los - wie kann ich das abstellen :

Danke für Eure Tipps & Tricks

[TT800]

Hallo Lindi,
Booster 6017 leiten den Rückkanal des mfx Decoders (zum Unterschied von 60173) nicht zur CS2 zurück. Die CS2 weiß also gar nicht, dass die Lok noch am Gleis ist und stellt nach einiger Zeit die Abfragezyklen nach dieser Lok ein. Durch den Aufruf des Konfigurationsmenüs wird die Lok wieder in die GFP Lokverwaltungsliste aufgenommen.

Da die CS2 auf diese Art nie zu einer Lok Rückmeldung kommen kann, frage ich mich, ob die Lok überhaupt als mfx-Lok an der CS2 geführt wird. Verstelle einmal an der CS2 die MM-Adresse - aber ohne dass die Lok am Gleis ist - sodass die Adresse im Decoder unterschiedlich ist. Geht dann die Lok auch noch?

[Werdenfels]

Zitat von TT800

---

Booster 6017 leiten den Rückkanal des mfx Decoders (zum Unterschied von 60173) nicht zur CS2 zurück. Die CS2 weiß also gar nicht, dass die Lok noch am Gleis ist und stellt nach einiger Zeit die Abfragezyklen nach dieser Lok ein. Durch den Aufruf des Konfigurationsmenüs wird die Lok wieder in die GFP Lokverwaltungsliste aufgenommen.

---

Hallo Stephan!

Dass der 6017 den Rückkanal nicht führt ist unstrittig. Ob die CS2 den Abfragezyklus einstellt, weiss ich nicht. Das ist mir auch egal.

Was nicht sein darf: Dass die CS2 nach einer gewissen Zeit keine Befehle mehr an nicht rückgemeldete Dekoder sendet! Das wäre ein Fehler im System! Schliesslich wird der 6017 ausdrücklich als Booster im System aufgeführt und sogar für M-Gleisnutzer empfohlen.

[Muenchner Kindl]

Moin,

Zitat

---

Schliesslich wird der 6017 ausdrücklich als Booster im System aufgeführt und sogar für M-Gleisnutzer empfohlen.

---

Vielleicht sollte die Empfehlung seitens des Herstellers um den Boosterlink von Tams erweitert werden

[nakott]

Hallo,

ich bin mir gar nicht so sicher, ob die CS2 überhaupt einen Abfragezyklen für die Loks hat. Wofür bräuchte sie diesen? Nach der Anmeldung kennt die CS2 die Lok und ab dann kann sie einfach die entsprechenden Fahrbefehle auf die Schiene schicken. Die Rückmeldung ist fürs Fahren doch belanglos. Erst wenn die CS2 die Lok programmieren will, dann muss sie wissen, dass die Lok da ist.

Ich weiß, dass es bei der CS1 anders ist. Aber von der CS1 Rückschlüsse auf die CS2 zu ziehen, ist nur bedingt anwendbar.

Vermutlich könnte est2fe hier Licht ins Dunkel bringen.

Dirk

[Lindilindwurm]

Auch sehr seltsam: Meine CS2 setzt nach dem Herunterfahren alle Loks auf Fahrstufe null, d.h. ich muss den ganzen Schattenbahnhof von Hand wieder anfahren. Der Haken in "Loks automatisch anfahren" ist allerdings gesetzt. Habe heute bei Märklin angerufen und um Rat gefragt, aber der Mitarbeiter wusste auch keinen Rat, außer probehalber die Booster mal wegzulassen und auszuprobieren. Aber ohne Booster fahren meine Loks eh nicht, vgl. oben?
Ich habe heute zufällig bemerkt, dass die Bremsabschnitte statt von den Boostern von der CS2 mit Schalt-& FAHRstrom versorgt werden, d.h. solange mfx-Loks in den Bremsabschnitten unterwegs sind, können sie sich auch bei der Zentrale melden. Vielleicht verursacht das die Probleme?
Beim großen C gibt es Booster-Überbrückungen für mfx-könnte das die Lösung sein?
Bin für Tipps dankbar - Lindi

[Lindilindwurm]

Hallo TT800,

meine CS hat die Loks schon als mfx-Loks, weil ich sie beim ersten Einspeichern auf dem Programmiergleis eingelesen habe. Vielleicht sollte ich alle diese mfx-Loks löschen und von Hnad neu anlegen?

[Torsten Piorr-Marx]

Zitat von Lindilindwurm

---

...Vielleicht sollte ich alle diese mfx-Loks löschen und von Hnad neu anlegen?...

---

Hallo,

wie legt man denn mfx-Loks von Hand an? Das ist doch gerade der Witz, das die sich selber anlegen, oder?

[est2fe]

Hallo Lindi,

also alle Loks löschen und von Hand neu anlegen bringt nichts. Nach dem Löschen werden sich alle mfx-Loks, sofern alles so läuft, wie vorgesehen und das System auch heil ist, sich wieder automatisch anmelden.

Was sind dies denn für mfx-Loks, die dieses Verhalten zeigen?
Sind das immer die Gleichen, oder sind davon gundsätzlich alle mfx-Loks betroffen?

Ich möchte durch die Frage rausbekommen, ob eventuell die neuen mfx-Decoder von M* da ein Problem haben.

Ich könnte mir vorstellen, dass wenn so ein neuer Decoder nach dem Power-Up und gültigen mfx-Datenpaketen, aber nie ein Paket direkt an ihn nach einer gewissen Zeit vorsichtig wird, und dann erst mal nicht auf Fahrbefehle reagiert.
Meines Wissens sendet die CS2 keine "mfx Verify"s. Ob das immer noch so ist, müsste mal ein CS2-User mit einem Terminalprogramm und TCP-IP-Sniffer, der auf dem CS2-Port mithört, und danach eine Protokollauswertung vornimmt, verifizieren.
Wenn die CS2 dann in das Lok-Bearbeitungs-Menü geht, kann ich mir auch vorstellen, dass da gewisse mfx-Befehle versendet werden wo auch solche dabei sind, welche den Decoder wieder zur Mitarbeit bewegen.

Leider habe ich keine CS2 um das jetzt im Detail nachzuprüfen.

Zudem müsste mal geklärt werden, ob Decoder nach einer gewissen Pause von Daten an ihn einfach misstrauisch werden.

Ich könnte mir vorstellen, dass wenn man eine mfx-Lok aus dem Refresh löscht und später wieder anmelden lässt, ohne an die Lok auch nur einen einzigen Fahrbefehl zu senden, dann die CS2 runterfährt, und nach einem kompletten Neustart meint, die Lok sei nach 10Min. ohne einen einzigen Fahrbefehl an sie ansprechbar, dass sie dann die Mitarbeit verweigert. Irgend so ein Effekt muss das wohl sein.

Pass mal genau auf, wenn das mal wieder passiert, und dann überlege genau, was du vorher (und da ist die vorherige Spielesession auch dabei, die auch mal ein paar Tage zurückliegen kann) alles angestellt hattest, speziell auch mit dieser Lok.

Dass es da einen Effekt gibt, der noch ungeklärt ist, ist offensichtlich. Nur wie finden wir den? Da hilft nur intensives Beobachten ob da ein System dahinter steckt und ein genaues Erinnern an das, was vorher geschehen ist.

Gruss

est2fe

[nakott]

Zitat von Lindilindwurm

---

Ich habe heute zufällig bemerkt, dass die Bremsabschnitte statt von den Boostern von der CS2 mit Schalt-& FAHRstrom versorgt werden, d.h. solange mfx-Loks in den Bremsabschnitten unterwegs sind, können sie sich auch bei der Zentrale melden. Vielleicht verursacht das die Probleme?

---

Zwischen dem 6017 Bereich und dem CS2 eingebauten Booster Bereich muss unbedingt Fahrstrom UND Masse getrennt sein. Ebenso zwischen CS2 eingebauten Booster und weiteren mfx Boostern.

Zitat von Lindilindwurm

---

Beim großen C gibt es Booster-Überbrückungen für mfx-könnte das die Lösung sein?Bin für Tipps dankbar - Christof

---

Das Ding nennt sich Booster Link und kommt eigentlich von Tams. Er macht 6017 Abschnitte rückmeldefähig. Suche hier im Forum mal nach Booster Link.

Dirk

[Lindilindwurm]

Hallo Dirk,

dass Fahrstrom UND MASSE getrennt sein müssen, wie du schreibst, stimmt für CS2 und 6017 aber nicht - das ist ja gerade der Punkt, nicht auf mfx-Booster umzusteigen. Meine ganze Anlage basiert auf EINEM Masseleiter; das aufzutrennen wäre unmöglich.
Seltsam: Ich war vorhin nochmal an der Anlage, und diesmal lief alles wie gewünscht - KA warum. Das ist das schöne an Wackelkontakten bzw. sporadischen Fehlern ...

[Lindilindwurm]

@ est2fe
Ja, ich werde das mal systematisch beobachten. Vielleicht hat es etwas mit den Bremsabschnitten zu tun gehabt, die versehentlich von der Decoder-Einspeisung betrieben wurden und daher doch mfx-Signale aufs Gleis gebracht haben...
Ich habe jedenfalls die Verkabelung gerade geändert und werde weiter beobachten.

[Torsten Piorr-Marx]

Zitat von Lindilindwurm

---

...Seltsam: Ich war vorhin nochmal an der Anlage, und diesmal lief alles wie gewünscht - KA warum. Das ist das schöne an Wackelkontakten bzw. sporadischen Fehlern ...

---

Hallo,

hast Du zwischenzeitlich vielleicht mal ein Backup eingespielt? Danach sollen sich erstmal alle Loks wieder an der Zentrale melden, bevor sie sich wieder steuern lassen.

[TT800]

Servus an alle,
da gibt es in der Zwischenzeit viel zu kommentieren.

Zitat von Werdenfels

---

Das wäre ein Fehler im System! Schliesslich wird der 6017 ausdrücklich als Booster im System aufgeführt und sogar für M-Gleisnutzer empfohlen.

---

Nun, ganz so ist es nicht. Es steht nirgends, dass ein Booster 6017 OHNE direkter Gleisstrom-Versorgung irgendeines Nachbarbereiches durch die CS2 empfohlen wird. Da Lindi schreibt, dass die Züge nur über die 6017 fahren, kann es ja nie zu einer mfx-Neuanmeldung kommen. Allerdings ist in der Zwischenzeit klargestellt, dass Lindi das CS2-Programmiergleis für die mfx-Neuanmeldung verwendet hat.

Zitat von Muenchner Kindl

---

Vielleicht sollte die Empfehlung seitens des Herstellers um den Boosterlink von Tams erweitert werden

---

In diesem Fall würde er aber nur über eine besondere Schaltung helfen, weil der direkt von der CS2 betriebene Nachbar-Gleisbereich fehlt. Siehe auch TAMS Anschlußplan:

Zitat

---

Wenn der Booster, der in der Zentrale integriert ist, nicht zur Versorgung der Anlage eingesetzt wird, verbinden Sie den Anschluss (3) direkt mit dem Boosterausgang der Zentrale

---

Zitat von nakott

---

Ich weiß, dass es bei der CS1 anders ist. Aber von der CS1 Rückschlüsse auf die CS2 zu ziehen, ist nur bedingt anwendbar.

---

Bis jetzt hat niemand irgendwelche Rückschlüsse von der CS1 auf die CS2 gezogen.

Zitat von Lindilindwurm

---

Auch sehr seltsam: Meine CS2 setzt nach dem Herunterfahren alle Loks auf Fahrstufe null, d.h. ich muss den ganzen Schattenbahnhof von Hand wieder anfahren. Der Haken in "Loks automatisch anfahren" ist allerdings gesetzt. Habe heute bei Märklin angerufen und um Rat gefragt, aber der Mitarbeiter wusste auch keinen Rat, außer probehalber die Booster mal wegzulassen und auszuprobieren. Aber ohne Booster fahren meine Loks eh nicht, vgl. oben?

---

Die CS2 kennt verschiedene HALT-Befehle:
System Stopp: dieser Befehl geht an einen bestimmten GFP, die Stromzufuhr abzuschalten; alle aktuellen Einstellungen bleiben erhalten; nach einem System Go - Befehl werden alle früheren Fahrbefehle wieder gesendet, bzw. je nach Decoder ausgeführt.
System Halt: dieser Befehl geht an einen bestimmten GFP, alle Lokomotiven in seinem Bereich inklusive Bremsverzögerung zum Stillstand zu bringen (Fahrstufe 0) - ohne aber die Stromzufuhr abzuschalten. Das ist sinnvoll beim definierten Herunterfahren der Anlage.
Lok Nothalt: dieser Befehl geht an eine bestimmte Lok und entspricht keiner Fahrstufe.

Zitat von Lindilindwurm

---

Ich habe heute zufällig bemerkt, dass die Bremsabschnitte statt von den Boostern von der CS2 mit Schalt-& FAHRstrom versorgt werden, d.h. solange mfx-Loks in den Bremsabschnitten unterwegs sind, können sie sich auch bei der Zentrale melden. Vielleicht verursacht das die Probleme?

---

Ganz im Gegenteil; die CS2 freut sich über die Rückmeldung einer lang vermissten Lok Aber bitte nicht auf die von Märklin vorgeschriebenen Trennwippen (zwischen CS2 und 6017 Bereichen) für den Schleifer vergessen!

Zitat von est2fe

---

Meines Wissens sendet die CS2 keine "mfx Verify"s. Ob das immer noch so ist, müsste mal ein CS2-User mit einem Terminalprogramm und TCP-IP-Sniffer, der auf dem CS2-Port mithört, und danach eine Protokollauswertung vornimmt, verifizieren.

---

Wenn ich das nicht schon lange machen würde, könnte ich nicht mitreden. Die "mfx Verify" werden natürlich gesendet; ich konnte sie aber bis jetzt nur auf Grund von konkreten Ereignissen nachweisen.

Zitat von est2fe

---

Wenn die CS2 dann in das Lok-Bearbeitungs-Menü geht, kann ich mir auch vorstellen, dass da gewisse mfx-Befehle versendet werden wo auch solche dabei sind, welche den Decoder wieder zur Mitarbeit bewegen.

---

Ja, zum Beispiel der "mfx-Verify" Befehl, der immer als erster gesendet wird.

Zitat von est2fe

---

Zudem müsste mal geklärt werden, ob Decoder nach einer gewissen Pause von Daten an ihn einfach misstrauisch werden.
Ich könnte mir vorstellen, dass wenn man eine mfx-Lok aus dem Refresh löscht und später wieder anmelden lässt, ohne an die Lok auch nur einen einzigen Fahrbefehl zu senden, dann die CS2 runterfährt, und nach einem kompletten Neustart meint, die Lok sei nach 10Min. ohne einen einzigen Fahrbefehl an sie ansprechbar, dass sie dann die Mitarbeit verweigert. Irgend so ein Effekt muss das wohl sein.

---

Das ist sicher ein Zusammenspiel von den Befehlen "mfx-Verify", "Lok Zyklus Beenden", "Lok Discovery", "System mfx Neuanmeldezähler setzen" und dem manuellen Aufruf einer Lok aus der CS2 Lokliste. Abgesehen davon, dass eigentlich nur der Verify-Befehl auch die Decoder-ID schickt und vielleicht damit den Decoder aus einer Art Stand-by weckt oder ihn vom Einschlafen abhält, führt sicher ein "lange nicht durch einen Lokbefehl angesprochen werden" genau zu so einem stand-by Zustand. Die CS2 vermeidet aus gutem Grund unnötigen Datenverkehr und nützt dazu die Möglichkeit der "Zwiesprache" mit den Decodern. Man stelle sich den Datenverkehr vor, wenn der Refreshzyklus immer alle Loks der Lokliste umfassen müsste!

Vor allem die "Ausweichlösungssucher" zur Ausstattung einer Anlage von einem Hersteller und aus einer gemeinsamen Technologiestufe wissen oft gar nicht, warum das Eine oder Andere nicht (so gut) funktioniert und klagen natürlich darüber. Fehlende Rückanäle sind dafür ein gutes Beispiel. Fast alle CS2/CAN-Befehle sehen Quittierungen vor - oft auch mit Werten: z.B. bei Geschwindigkeiten zur Synchronisierung, Qualitätsränge der Kommunikation oder bei Verifizierungen. Der Grund ist, bessere Betriebsqualität zu haben. Wenn ich solche Verbesserungen behindere, darf ich mich über die eingangs geschilderten Probleme nicht wundern. Ein 6017 ist und bleibt bei einer CS2 ein Kompromiiies, sonst wäre ja nicht der 60173 entwickelt worden.

"Aber mfx ist ja nur zum automatischen Anmelden da und darauf könnten wir auch verzichten ..." tönt es nicht so aus vielen Kehlen?
Nein nicht aus vielen, nur aus einigen; die meisten freuen sich über den Technischen Fortschritt in der Steuerung von Modellbahnlokomotiven und genießen ihn auch ..... heute Abend unter dem Weihnachtsbaum?

Frohe Weihnachten!

[Lindilindwurm]

Hallo Stephan und Torsten, vielen Dank für eure Hinweise. Ich habe tatsächlich auch einmal ein Backup eingepielt; ich werde weiter beobachten, nachdem ich nun die Verkabelung der Bremsabschnitte geändert habe.

SCHÖNE WEIHNACHTEN

[Petje]

Hallo Stefan,

Ich habe meine Anlage met 6017 Booster ausgestattet. Jetzt möchte ich die CS2 benutzen und die mfx Loks mit mfx steuern.

Heisst das jetzt das wenn die Loks einmal angemeldet sind an der CS2 diese Loks immer über mfx gesteuert werden oder gibt es (weil fahrt nur auf 6017 Strecke) eine Art Time-out und schaltet die CS2 für diese Loks auf MM2 weil sie sie nicht mehr "gesehen" hat?

[TT800]

Zitat von Petje

---

Heisst das jetzt das wenn die Loks einmal angemeldet sind an der CS2 diese Loks immer über mfx gesteuert werden oder gibt es (weil fahrt nur auf 6017 Strecke) eine Art Time-out und schaltet die CS2 für diese Loks auf MM2 weil sie sie nicht mehr "gesehen" hat?

---

Man muss sich immer bewusst sein, dass die CS2 zwei Ebenen der Steuerung hat:

1. das GUI (Graphical User Interface), also die Bedienoberfläche für den Benutzer, deren Konfiguration in den Backup-dateien (und intern) gespeichert wird. Nach einer Lok-Neuanmeldung wird dort die Lok (eigentlich deren Decoder) in die Lokliste dauerhaft aufgenommen. Für den Benutzer unsichtbar ist dort das zutreffende (und nur das eine) Steuerprotokoll (MMx, DCC, mfx) inklusive der jeweiligen Lokadresse für jede Lok hinterlegt. Spezialisten können das aus jeder Backup-datei "lokomotive.cs" herauslesen. Wenn auch im Decoder eine MM-Adresse hinterlegt ist, damit auch das alte Steuergerät 6021 Zugriff auf die Lok haben kann, bleibt eine einmal eingetragene mfx-Lok in der CS2 immer eine mfx-Lok.

2. den GFP (Gleis Format Prozessor), der die Steuerbefehle des Benutzers im GUI in der für den jeweiligen Decoder richtigen Datensprache (Steuerprotokoll) und über ein die elektrische Leistung verstärkenden Booster auf die Schiene schickt, bzw. die Rückmeldungen der Decoder zur Kenntnis nimmt und an die richtigen Steuerelemente weiterleitet. Der GFP hat eine eigene Liste "aktiver" Loks, die er von sich aus ständig mit Lokbefehlen versorgt (Refreshzyklus).

Deine Frage ist nach meinem Wissensstand so zu beantworten:
Solange irgendwelche Daten mittels mfx-Protokoll an der Schiene liegen, bleibt jeder mfx-Decoder für alle anderen Protokolle gesperrt. Und damit bleibt er immer - auch im 6017 Bereich - (nur) als mfx-Lok erreichbar.

Je nach Decoder ist das Verhalten unterschiedlich,
- ob das mfx-Signal eine bestimmte (Du nennst es time-out) Zeit ausbleibt. ESU schreibt in der mfx/M4 Betriebsanleitung, dass nach 4 Sekunden Ausbleiben eines mfx-Signales der Decoder seine mfx-Ausschließlichkeit aufgibt und für andere Protokolle (MM2) offen ist. Er wird aber erst wieder zum exklusiven mfx-Decoder, wenn es wieder mfx-Signale im Gleis gibt. Ob diese neuerlichen mfx-Signale vom Decoder "geprüft" werden, ob er sie anerkennen soll, weiß ich leider noch nicht. Es steht im Raum, ob er "seine" eigene Adresse erkennen muss, ob er seinen Befehlsgeber (die UID des GFP) im Signal erkennen muss, ob er die Zuordnung seiner Adresse mit seiner mfx-UID erkennen muss oder eben gar nichts Inhaltliches.
- ob die Digitalspannung überhaupt ausbleibt. Der vorhin beschriebene Zustand ist bei ESU-Decodern bereits nach kurzer Stromlosigkeit der Fall. In diese Kategorie fallen alle Probleme, die sich durch schlechte Schienenkontakte ergeben. Jemand hat als Grenze der Stromlosigkeit 50 msec ermittelt.

Zitat

---

schaltet die CS2 für diese Loks auf MM2 weil sie sie nicht mehr "gesehen" hat?

---

Wenn es aus meinen Ausführungen nicht klar geworden ist - die CS2 schaltet nie von selber auf ein anderes Protokoll; der GFP löscht die untätige Lok aber nach einiger Zeit aus dem Refreshzyklus. Normalerweise genügt aber ein einfacher Fahrbefehl im GUI, um die Lok wieder in den Zyklus aufzunehmen.

Das vom Threadersteller aufgezeigte Problem ist in den Randbedingungen noch zu wenig erläutert, um eine endgültige seriöse Diagnose abzugeben. Wie immer eine Verkettung von mehreren Faktoren, die nicht immer exakt reproduzierbar ist.

Also Petje, grundsätzlich ist keine Besorgnis angezeigt, wenn alles andere stimmt ...

Frohe Weihnachten

[Petje]

Stephan,

Danke für deine aufklärende Worte.

Frohe Weihnachten.

[est2fe]

Hallo Stephan,

> Der GFP löscht die untätige Lok aber nach einiger Zeit aus
> dem Refreshzyklus.

Dem kann ich in der Form nicht zustimmen, wenn ich die CAN-Spec. zur CS2 lese. Das macht laut der Spec. die GUI bzw. die Zentrale mit einem CAN-Befehl an den GFP.

Also bitte mal prüfen, was passiert, wenn man eine CS2 runterfährt, und dann wieder hochfährt. Bekommen dann alle angemeldeten mfx-Loks mindestens ein mfx-Verify oder einen Fahrbefehl mit FS 0?
Wenn nein, dann sendet der GFP für diese Loks auch nichts
auf das Gleis, weil er nach dem Booten von der vorherigen Session sich nichts merkt.
Das Dumme ist vielleicht, dass eventuell das Gateway am Anfang nicht alle CAN-Frames durchleiten könnte, weil es eventuell am Anfang noch nicht vollständig initialisiert ist. Ich hoffe jedoch, dass man auf dem PC alle CAN-Befehle, auch das Anmelden des GFPs an der Zentrale sieht. Wenn dem so ist, dann einfach mal alles mitloggen, was da am Anfang so an den GFP versendet wird.

Wenn keine Fahrbefehle oder mfx-Verifys nach dem Booten kommen, dann einfach mal die Anlage ein paar Minuten bis zu einer 1/2h so stehen lassen, aber _nicht_ im Stop-Modus, sondern schon mit aktiver Gleisspannung. Danach alle mfx-Loks mal fahren lassen.
Ich bin gespannt, was da so alles an mfx-Loks noch fährt?

Übrigens versenden die MS1, CS1 und ECoS immer zyklisch, zwischen die Fahrbefehle gestreut, ihre eigene UID, fragen danach ob sich jemand anmelden will, und fragen auch jede mfx-Lok mit einem mfx-verify in äquidistanten Abständen. Ich meine, das wäre so in einigen 100ms-Abstand gewesen und hängt auch von der Anzahl abgemeldeter mfx-Loks ab. Die CS2 macht das aber meines Wissens anders bzw. lässt den mfx-verify bei normalem Fahrbetrieb einfach weg. Schade eigentlich, denn dadurch könnte man mit einem Lok-Rückmelder zurückmelden in welchem Rückmeldeabschnitt sich die mfx-Lok gerade befindet. Ich weiss, bei vielen angemeldeten mfx-Loks dauert das auch relativ lange.

Ich meine, die zeitlichen Abstände sind auch in dem Dokument von Stefan Krauss angesprochen. Bin gerade nur zu faul zum suchen ...

Gruss

est2fe

[Lindilindwurm]

(gelöscht)

[TT800]

Servus,

Zitat von est2fe

---

> Der GFP löscht die untätige Lok aber nach einiger Zeit aus dem Refreshzyklus.

Dem kann ich in der Form nicht zustimmen, wenn ich die CAN-Spec. zur CS2 lese. Das macht laut der Spec. die GUI bzw. die Zentrale mit einem CAN-Befehl an den GFP.

---

Aber genau so steht es in der offiziellen Märklin CS2/CAN Offenlegung: Beschreibung des Systembefehles "Lok Zyklus beenden"

Zitat

---

Lok aus Verwaltungsliste des Gleis Format Prozessor löschen. Die Lok erhält keine Befehle mehr (kein Refreshzyklus)

---

Systembefehle betreffen immer den Gleis Format Prozessor direkt und bestimmen die Funktionsweise, bzw. die Zustände. Desweiteren werden Zustände des GFP weitergemeldet.
Das GUI - oder wie es in der Offenlegung heißt: das Bediengerät - erteilt natürlich dem GFP die Systembefehle. Wer sonst? Mein nächster Satz war auch: "Normalerweise genügt aber ein einfacher Fahrbefehl im GUI, um die Lok wieder in den Zyklus aufzunehmen."
Ich führe gerne eine Grundlagendiskussion, vor allem zur persönlichen Wissenserweiterung - aber bitte meine Aussagen nicht aus dem Zusammenhang reißen.

Zitat von est2fe

---

Also bitte mal prüfen, was passiert, wenn man eine CS2 runterfährt, und dann wieder hochfährt. Bekommen dann alle angemeldeten mfx-Loks mindestens ein mfx-Verify oder einen Fahrbefehl mit FS 0?
Wenn nein, dann sendet der GFP für diese Loks auch nichts auf das Gleis, weil er nach dem Booten von der vorherigen Session sich nichts merkt.

---

Nach meinen Erklärungen (weiter oben im Thread) über die Unterschiede der Systembefehle STOPP und HALT ist klar, dass nur das "Bediengerät" entscheidet, welche Fahrbefehle der GFP an die "aktiven" Loks zu senden hat. Das ist ja auch alles im backup file abgespeichert.

Ich verwende übrigens bewußt den Ausdruck "aktive Loks" für Loks im Refreshzyklus - zum Unterschied von "angemeldeten Loks", also Loks in der gesamten Lokliste der CS2.

Zitat von est2fe

---

Ich hoffe jedoch, dass man auf dem PC alle CAN-Befehle, auch das Anmelden des GFPs an der Zentrale sieht. Wenn dem so ist, dann einfach mal alles mitloggen, was da am Anfang so an den GFP versendet wird.

---

Ich habe vor längerer Zeit schon etliche verschiedene Sequenzen "mitgeschnitten"; nach einem "System GO" Befehl habe ich zum Beispiel folgende Konversation protokolliert:

00300F3600
0031B70108435342E401170000

1. Zeile:
Das ist ein "Teilnehmer PING" zur Suche von Steuergeräten am CAN-Bus.
2. Zeile:
Antwort mit Bekanntgabe der Geräte UID, und dessen Softwarestandes (0x 01 17 > also 1.23)

Diese Sequenz wird vom Booten weg etwa alle 12 Sekunden am CAN-Bus gesendet. Bei einem angeschlossenem Slave Bediengerät, das über den CAN-Bus kommuniziert, müsste dann eine weitere "Teilnehmermeldung" aufscheinen.

Auch das "Lok Discovery" - also das Auslesen der Decoder UID - ist eine interessante Prozedur. Aber das führt uns allerdings schon etwas weit weg vom Thema dieses Thread.

Zitat von est2fe

---

Wenn keine Fahrbefehle oder mfx-Verifys nach dem Booten kommen, dann einfach mal die Anlage ein paar Minuten bis zu einer 1/2h so stehen lassen, aber _nicht_ im Stop-Modus, sondern schon mit aktiver Gleisspannung. Danach alle mfx-Loks mal fahren lassen.
Ich bin gespannt, was da so alles an mfx-Loks noch fährt?

---

Ich verspreche, so bald als möglich zu testen.

Zitat von est2fe

---

Übrigens versenden die MS1, CS1 und ECoS immer zyklisch, zwischen die Fahrbefehle gestreut, ihre eigene UID, fragen danach ob sich jemand anmelden will, und fragen auch jede mfx-Lok mit einem mfx-verify in äquidistanten Abständen. Ich meine, das wäre so in einigen 100ms-Abstand gewesen und hängt auch von der Anzahl abgemeldeter mfx-Loks ab.
Ich meine, die zeitlichen Abstände sind auch in dem Dokument von Stefan Krauss angesprochen. Bin gerade nur zu faul zum suchen ...

---

Also mit dieser Studie unter dem Titel "Beschreibung des mfx-Schienensignals" habe ich so meine Bedenken. Man kann zwar sehr viel Interessantes - vor allem über die Grundlagen der Datenpakete in der Schiene - darin lesen, aber so allgemein gültig sollte der Titel nicht lauten. Es wird zwar das offizielle Märklin CS2/CAN Dokument auch als Quelle zitiert, doch stimmt etliches damit nicht überein. Zum Thema "mfx Verify" heißt es zum Beispiel:

Zitat

---

Datenframes ohne ein Kommando (also nur Adresse + Checksumme) erwarten eine einfache 1Bit-Rückmeldung vom angesprochenen Decoder. Damit lässt sich feststellen, ob unter der angegeben Adresse (SID) zur Zeit ein Decoder erreichbar ist.
Dieses Kommando wurde bisher noch bei keiner Zentrale beobachtet, sondern experimentell ermittelt.

---

Abgesehen davon, dass laut Märklin Dokument der Befehl auch die mfx-UID enthält, wurde dieser Befehl noch bei keiner Zentrale beobachtet???
Woher kommt dann die Vermutung, dass dieser Befehl bei den "ESU-Steuergeräten" alle 100ms gesendet wird?
Oder ein anderes Beispiel betrifft den PING-Befehl: Märklin beschreibt den Befehl total anders und betont, dass darauf keine LokDecoder antworten.
Möglicherweise ist das Dokument nur für die "ESU-Geräte" und deren Kommunikation gültig. Das kann ich nicht beurteilen, weil ich kein derartiges Gerät habe. Aber je mehr ich mich mit der andiskutierten Problematik beschäftige, desto mehr wachsen meine Zweifel über die in der genannten Studie beschriebenen "Verhaltensregeln" der mfx-Decoder, die ich leider bisher ungeprüft akzeptiert hatte.

EDITIERTER ZUSATZ: Nach meinen letzten Erkenntnissen dürften manche Diskrepanzen darin begründet sein, dass die erwähnte Studie nur den auf den Schienen befindlichen Datenverkehr beschreibt - aber die Märklin CS2/CAN Protokoll Offenlegung sich eben dem CAN-Bus widmet, der über das Gateway zugänglich ist. Dazwischen arbeitet der GFP, der manche (befohlene) Subprozesse selbsttätig ausführt und nur die Ergebnisse an den CAN-Bus meldet. Deshalb kann man auch die Datenstrukturen der Meldungen nicht so leicht gegenseitig zuordnen.

Zitat von est2fe

---

Die CS2 macht das aber meines Wissens anders bzw. lässt den mfx-verify bei normalem Fahrbetrieb einfach weg. Schade eigentlich, denn dadurch könnte man mit einem Lok-Rückmelder zurückmelden in welchem Rückmeldeabschnitt sich die mfx-Lok gerade befindet. Ich weiss, bei vielen angemeldeten mfx-Loks dauert das auch relativ lange.

---

Warum brauche ich dafür unbedingt einen mfx-Verify Befehl?
Jeder Lokbefehl wird mit einer Quittierung, in der die SID steht beantwortet:
- beim Geschwindigkeitsbefehl sogar inklusive des momentanen Geschwindigkeitswertes
- beim Richtungsbefehl sogar inklusive der momentanen Richtung
- beim Funktionsbefehl sogar inklusive des momentanen Wertes einer bestimmten Funktion

EDITIERTER ZUSATZ:
Die Dinge liegen komplizierter als ich zunächst angenommen habe. Die Quittierung kommt nämlich vom GFP und bestätigt nur die Weitergabe des Fahrbefehls an die Schiene. Mehr darf man da nicht hineininterpretieren, weil ich alle diese Meldungen auch bei nicht aufgegleister Lok erhalten habe.

Die Nichtverwendung des "mfx-Verify" im normalen Fahrbetrieb kann ich bestätigen. Um die Idee des Rückmeldeabschnittes zu verfolgen, bräuchte ich aber doch nur einen "mfx-Verify"-Befehl über Ethernet auslösen.

Das alles bedingt natürlich Rückkanaltauglichkeit der gesamten Anlage - und damit sind wir wieder beim Thema des Threads.

[Lindilindwurm]

Ich will nochmal zu einem Randproblem nachfragen:

Ich hatte ja schon geschrieben, dass meine Schalt-Decoder usw. direkt von der CS2, die Gleise über 6017 versorgt werden.

Ich hatte bisher die Bremsbausteine als Decoder verdrahtet, d.h. also Rot/Braun an CS 2, ebenso den ansteuernden k83. Dies allerdings verbindet ungewollt die CS2 mit den Gleisen, nämlich über die Bremsabschnitte.

Ich habe nun den Bremssbaustein rot/braun an einen 6017 angeschlossen; rot/gelb grün werden von einem k83 angesteuert, der als decoder seinen Saft von der CS2 erhält.

Ist das Problem jetzt wirklich gelöst, oder verbinde ich dann erst recht CS2 mit 6017, wenn ich die Bremsbausteine braun/rot an 6017 anschließe? Was passiert im Bremsbaustein mit dem "Steuerungssignal", also grün/GELB /rot vom Dekoder k83 - denn dieser wird ja nach wie vor von der CS betrieben

Danke für Tipps - Lindi

PS: Das Problem, dass ich alle Loks manuell anfahren musste, ist nicht wieder aufgetreten. Ich vermute, dass es mit dem oben erwähnten Einspielen eines Backups zu tun hatte... Aber die mfx-Loks bleiben mir weiter immer wieder stehen.
PPS: Respekt, welche Fachkenntnis hier im Forum vorhanden ist!!!

[TT800]

Hallo Christof,
zu Deinem Bremsbaustein Problem kann ich leider nichts beitragen, weil ich so etwas nicht habe. Wie ich aber schon früher geschrieben habe, sehe ich kein Problem in der Einspeisung von "Bahnstrom" der CS2. Was begründet Deinen Änderungswunsch?

Wenn Du CS2-Bahnstrom von der Anlage fernhalten willst, dann schließe halt auch den k83 inklusive Bremsbaustein an den zugehörigen Booster an.

Nur mixen würde ich nicht, solange ich nicht die Schaltung kenne.

Zum Ausgangsproblem:
Ich habe meinen letzten Beitrag nach meinen letzten Erkenntnissen editiert. Für den normalen Fahrbetrieb sind ganz sicher keine Rückmeldungen der Lokdecoder erforderlich. Anders verhält es sich natürlich, wenn man in das Konfigurationsmenü einsteigt.

Kannst Du beschreiben, bei welchen Decodern das vorkommt und bei welchen nicht; Du solltest auch beschreiben, was der betreffende Decoder wie lange vorher zuletzt gemacht hat. Du hast auch noch immer nicht geschrieben, um welchen Decoder (Lok) es sich überhaupt handelt.

[Lindilindwurm]

Hallo Stephan,

ich habe inzwischen tatsächlich gar keinen CS-Strom mehr am Gleis, nur noch 6017-er Strom. Ergebnis: Märklin mfx-Loks sind gar nicht mehr ansprechbar, obwohl sie im Lokmenue der CS vorhanden sind.

Alle nicht-mfx Loks fahren problemlos - allerdings mit einem Vorbehalt: Ich habe in etlichen Loks ESU-Sound-Decoder, und weiß nicht mehr bei allen sicher, ob das normale Loksounds sind oder Loksound mfx. Dass die mfx-Loks zu Beginn noch gelaufen sind, lag offenbar an den versehentlich mit CS-Strom gespeisten Bremsabschnitten.

Warum ich trenne? Die Anlage ist fest aufgebaut und eingeschottert, besteht aber zu wesentlichen Teilen aus Metallgleisen. Eine Trennung der Masse ist daher nicht machbar. Lösung: Alle Schienen bekommen ihren Saft von 6017, alle Decoder direkt von der CS2.

Ich habe mir dieser Tage Booster-Links von Tams bestellt; ich hoffe, das Problem damit zu lösen!

Zum Problem, dass die Loks ihre Fahrgeschwindigkeit verlieren: Dies tritt anscheinend dann auf, wenn ich nach einer Änderung z.B. am Memory ein Backup erstelle - habe ich gestern gemacht und irgendwann später die CS normal heruntergefahren und abgeschaltet. Ein Backup wurde nicht wieder eingespielt. Heute erneut: Alle Loks auf Fahrstufe 0... Sehr plöt.

Grüße
Lindi

[TT800]

Zitat von Lindilindwurm

---

Erst, sobald ich in der CS2 das Werkzeug-Symbol der Lok aufrufe (also das Fenster für die Einstellungen der Lok) wird sie angesprochen und sie schaltet sich ein. Verändert wird von mir sonst nichts an den Einstellungen, also es genügt, das Werkzeug-Symbol anzuwählen.

---

Für alle, die auch versuchen, die Ursache zu finden, meine derzeitigen Testergebnisse: Das Aufrufen des Werkzeugsymbols erzeugt einen "mfx-BIND" und danach einen "mfx-VERIFY" Befehl. Der mfx-BIND Befehl teilt dem Decoder mit der entsprechen UID die in der CS2 vorgemerkte SID zu und haucht ihm damit wieder das Leben ein. Soweit so klar; aber warum hat der Decoder seine SID vergessen?

Was der GFP schienenseitig selbsttätig macht, kann ich mangels technischer Ausstattung derzeit leider nicht feststellen. Ich kann lediglich auf dem CAN-Bus die Daten beobachten und analysieren und da gibt es spätestens alle 10 Sekunden nur einen - leider von Märklin undokumentierten - Systembefehl, der meiner Vermutung nach den GFP auffordert, Decoder abzufragen. Dieser Systembefehl ist auch immer beim Auslesen der Decoder-UID oder dessen CV beteiligt, wobei dann als Byte 7 die Anzahl der jeweils abzurufenden Werte (maximal 4) eingetragen ist.

Der Befehl hat das SubCommand 0x 30 01, gefolgt von 0x 30 00, schaut also so aus:
00 00 0300 06 435342e4 30 01 00 00
00 00 0300 06 435342e4 30 00 00 00

Vielleicht kann ihn jemand interpretieren. Wenn meine Vermutung stimmt, dann hilft das aber leider nicht, die Ursache der toten Lok im 6017-Bereich aufzuklären.

@ est2fe:
Habe nach einem CS2-Bootvorgang über eine Stunde lang die Anlage unbeschäftigt lassen -> die Loks reagierten danach sofort auf den Fahrbefehl.