(Abtrennung von viewtopic.php?t=46316,-dekoderverhalten-in-verschiedenen-systemen.html#488731 ) Was bisher geschah:
Zitat von est2fe
Hallo Manfred,
> Für etwas, das es offiziell gar nicht gibt, M3, scheint das auf der Tamse
> verdammt gut zu funktionieren, wenn ich das halbwegs richtig
> mitbekommen habe.
> Und: Ist das Kernstück von mfx nicht die selbständige Anmeldung?
Auch das Kernstück ist nicht dasselbe! Eine mfx-Anmeldung besteht aus 2 verschiedenen Prozeduren.
Die erste Prozedur ist das Auslesen der UID eines Decoders. Dabei sendet der Decoder nur eine "1-Bit-Rückmeldung". Ich nenne es jetzt mal einfach so. Da fragt die Zentrale, ob sich ein Decoder anmelden will. Wenn ja, dann soll er mal "Piepsen". Der Decoder geht dann her und zieht einen Strom von ca. 150mA mit einer Frequenz von ca. 53kHz.
Die Tamse nimmt ihre DCC-Rückmelde-Erkennung und schaut nach, ob da ein Strom gezogen wird. Die Nativ-mfx-Zentralen nehmen ein Zwischensignal des RDS-ICs, welches das Vorhandensein des Trägers mit 53kHz anzeigt. Schon da sind also Unterschiede vorhanden.
Sind alle 32 UID-Bits des Decoders ausgelesen, dann gehen alle Zentralen her und teilen dem Decoder seine zukünftige SID mit. Die SID wird als "Kurzadresse" gegenüber der 32-bittigen UID dem Decoder von der Zentrale vorgegeben.
Für die Tamse ist es hiermit erledigt. Sie kann den mfx-Decoder nun ansprechen und ihm Fahr- und Funktionsbefehle mit Hilfe dieser SID zusenden. So weit so gut.
Für die Nativ-Zentralen beginnt nun erst die Arbeit. Die haben bisher nur einen mfx-Decoder, der auf eine kurze Schienenadresse (SID) hört.
Sie beginnen nun, den Decoder auszufragen. Dafür ist eine andere Prozedur notwendig, welche die Tamse ohne den RDS-IC nicht machen
kann. Es werden nun mfx-CV-Reads an den Decoder gesendet, und er sendet dann im Rückmeldesignal mit den 53kHz/150mA in der Phasenlage die abgefragten Bits der CV-Werte an die Zentrale zurück. Als eine der ersten CVs werden da z. B. der Lokname, dann die Funktionen usw. ausgelesen.
Die CS2 zeigt diese Werte nun dem Benutzer, und er kann dann schon mal mit der Lok fahren, während sie im Hintergrund noch den Rest ausliesst. Die CS1 V2.0.4 und die MS1 lesen zuerst alles aus, und zeigen erst dann dem Benutzer die Lok zum fahren. Wenn da in der Zwischenzeit jetzt noch was schief geht, dann kann es sein, dass der Benutzer die Lok auch gar nicht zu Gesicht bekommt.
Deswegen ist die Wahrscheinlichkeit, dass man einen mfx-Decoder mit der Tamse steuern kann, wesentlich höher, als mit den Nativ-Zentralen.
Gruß
est2fe
Zitat von digilox1
Hallo est2fe,
herzlichen Dank für Deine Erläuterungen.Zitat
Die CS2 zeigt diese Werte nun dem Benutzer, und er kann dann schon mal mit der Lok fahren, während sie im Hintergrund noch den Rest ausliesst. Die CS1 V2.0.4 und die MS1 lesen zuerst alles aus, und zeigen erst dann dem Benutzer die Lok zum fahren. Wenn da in der Zwischenzeit jetzt noch was schief geht, dann kann es sein, dass der Benutzer die Lok auch gar nicht zu Gesicht bekommt.Heisst das, dass die CS 2 vordergründig deutlich weniger Anmeldeprobleme hat als die CS 1 bis V2.0.4, weil eine Lok von der CS 2 bereits zur Fahrt freigegeben wird, wenn der Decoder von der Zentrale nicht vollständig eingelesen werden konnte?
Wird er nun während des Betriebs ständig dazu aufgefordert, den Rest der noch nicht eingelesenen Daten zu übertragen?
Ohne jede funktionelle Einschränkung, wenn die Rückmeldeverbindung längere Zeit nicht arbeitet - warum auch immer?
Zur MS 1: Wenn ich die Postings hier lese, scheint mir, dass die MS weniger Anmeldeprobleme hat als die anderen Geräte.
Auch glaube ich mich zu erinnern, dass jemand schrieb, dass die MS weniger Daten auslese, weil sie diese nicht nutze und deshalb auch weniger Zeit benötige für das Einlesen eines Decoders.
Gruss,
Manfred
Zitat von est2fe
Hallo Manfred,Zitat von Manfred
Heisst das, dass die CS 2 vordergründig deutlich weniger Anmeldeprobleme hat als die CS 1 bis V2.0.4, weil eine Lok von der CS 2 bereits zur Fahrt freigegeben wird, wenn der Decoder von der Zentrale nicht vollständig eingelesen werden konnte?Das würde ich nicht unbedingt so sagen wollen. Ich kenne die Innereien der CS2 nicht.
Zitat von Manfred
Wird er nun während des Betriebs ständig dazu aufgefordert, den Rest der noch nicht eingelesenen Daten zu übertragen?Meines Wissens ja.
Zitat von Manfred
Ohne jede funktionelle Einschränkung, wenn die Rückmeldeverbindung längere Zeit nicht arbeitet - warum auch immer?Da gab es mal bei manchen MoBa-Kollegen wohl eine Meldung, dass die Daten der Lok nicht vollständig ausgelesen werden konnten.
Zitat von Manfred
Zur MS 1: Wenn ich die Postings hier lese, scheint mir, dass die MS weniger Anmeldeprobleme hat als die anderen Geräte. Auch glaube ich mich zu erinnern, dass jemand schrieb, dass die MS weniger Daten auslese, weil sie diese nicht nutze und deshalb auch weniger Zeit benötige für das Einlesen eines Decoders.Ja, die MS1 liesst weniger Daten aus.
Gruss
est2fe
Zitat von TT800Zitat von est2fe
Als eine der ersten CVs werden da z. B. der Lokname, dann die Funktionen usw. ausgelesen. Die CS2 zeigt diese Werte nun dem Benutzer, und er kann dann schon mal mit der Lok fahren, während sie im Hintergrund noch den Rest ausliesst.Dem muss ich leider widersprechen. Im Hintergrund wird nichts mehr ausgelesen. Ich habe den CS2-Anmeldevorgang von einigen mfx-Loks am CAN-Bus protokolliert, und da passiert beim Anmelden folgendes:
1. GFP liest nach dem Aufgleisen der unbekannten Lok selbständig die Lok-mfxUID aus und meldet sie auf den CAN-Bus. (Dauer: 10 sec. - in dieser Zeit merkt man an der CS2 nichts)
2. GUI vergibt provisorische SID (Wertevorrat 1 - 4) und liest über den GFP folgende CV/Indexwerte des Decoders in dieser Reihenfolge aus: ProduktID, HerstellerID, Lokname, Bildcode (nur 1 Byte und daher nicht mit dem Farbbild in der Lokliste verwechseln!), MM2-Primäradresse, Vmax, Vmin, Anfahrbeschleunigung, Bremsverzögerung, Lautstärke, alle Funktionssymbole inkl. allgemeiner Info wie Moment oder Dauerfunktion - aber keine Mappinginformation. Nun erst wird die endgültige SID (von 5 aufwärts) vergeben und der Benutzer kann die Lok durch Klick auf das rote mfx-Symbol in ein Fahrpult aufnehmen und steuern. (Dauer: 15 sec. - dieser Vorgang wird am Display mit Fortschrittsbalken gemeldet)
Und war die Lok schon bekannt und wurde nur neu aufgegleist, das heißt sie hat nicht zum Neuanmelden "gepiepst", passiert am CAN-Bus überhaupt nichts und die Lok kann sofort gefahren werden. Sie ist ja schließlich in der Lokliste vorhanden.
Hallo digilox1 und est2fe, setzen wir hier fort.
Zitat von digilox1
Wozu dient eine provisiorische SID und warum braucht es vier davon?
Also vorweg - ich weiß es nicht. Ich glaube aber, dass das mit der gesamten CS2-Systemarchitektur zusammenhängt. Das was in Bezug auf die mfx-Neuanmeldung früher die CS1 allein gemacht hat, soll bei der CS2 in allen Boosterbereichen auch funktionieren. steamer01 berichtet z.B., dass seine Anlage aus 2 CS2 und 8 Booster besteht. Wo auch immer und wieviele neue mfx-Loks sich auf der Anlage neuanmelden wollen - das braucht rasche und zum Teil gleichzeitig ablaufende Prozeduren. Ohne Zeitverzug können wahrscheinlich bis zu 4 Neuankömmlinge ausgefragt werden, und wer als nächster fertig wird, bekommt die nächste freie (endgültige) SID. Läuft aber bei einer Lok etwas schief, so würde im Falle der Verwendung einer schon endgültigen SID der Neuanmeldungszähler durcheinanderkommen.
Zitat
Wenn Mapping-Informationen nicht gelesen werden, heisst das nicht, dass sie nicht vorhanden sind, sondern z.B. von einer CS 1 ausgelesen werden können?
Die Steuerzentrale muss nicht wissen, welche Aktivitäten mit einer konkreten Funktionsnummer verbunden sind. Das weiß der Decoder - und mit mapping meint man genau diese Zuordnung, die man "dem Decoder" und nicht "der Steuerzentrale" mitteilt. Natürlich muss der Mensch als Benutzer wissen, was sich hinter einer konkreten Funktionsnummer verbirgt. Und dazu dient das "sprechende" Symbol (Piktogramm) am Fahrpult.
Zitat
Wenn ich das richtig verstanden habe, liest nach Deiner Protokollierung die CS 2 auch alles aus, was sie kann und erst dann wird die Lok zur Fahrt freigegeben?
Nein, nicht was sie kann, sondern was sie zum Fahr- und Steuerbetrieb der Lok braucht.
Zitat
Also doch gleiches Freigabeverhalten wie bei einer CS 1?
Da muss ich passen - ich habe keine CS1
Zitat
Die CS 1 kann doch mappen, dann wird sie auch die Mapping-Informationen aus dem Decoder abrufen können?
Natürlich wird sie vernünftigerweise die aktuell im Decoder abgespeicherten Zuordnungen zuerst lesen, bevor sie verändert werden. Aber das ist ein Vorgang zur Konfiguration eines Lokdecoders und nicht zum Fahren oder Steuern nötig.
Zitat
Weshalb wird die MM-Primäradresse überhaupt ausgelesen?
Hat der Anwender denn neuerdings optional (von mir aus auch versteckt) die Möglichkeit, alternativ mit MM zu fahren und sich diese Adresse auch anzeigen zu lassen, falls der Rückmeldekanal ausfällt im Laufe der Zeit?
Und warum wird nur die Primäradresse ausgelesen?
Auch das weiß ich nicht. Und der Idee, alternativ mit MM zu fahren, kann ich mich überhaupt nicht nähern. Die einzige Erklärung, die ich hätte, wäre die, dass alle Daten, die im Konfigurationsmenü vorhanden sind, gemeinsam gleich bei der Neuanmeldung gelesen werden. Sie sind übrigens in einer Backupdatei der CS2 ebenfalls enthalten.
Zitat von est2fe
Hallo Stephan,
ok, so wie du das beschreibst ist das wohl der letzte Stand der CS2. Gut akzeptiert. Ich kann das ja (noch) nicht nachmessen. Offensichtlich wurde die Vorgehensweise gegenüber den früheren Versionen wohl etwas angepasst. Was passiert nun, wenn man die Lok nun einstellen will und in das Lok-Konfigmenü geht?
Eigentlich muss dann die CS2 die angezeigten Daten zuvor zuerst lesen. Das Menü wird dann vermutlich ein klein wenig verzögert angezeigt. Das ist auch eine Vorgehensweise, vermutlich nicht mal die Schlechteste.
Gruss
est2fe
Wie auch schon aus dem oben Gesagten hervorgeht, die CS2 hat alle Daten für das Konfigurationsmenü - soferne sie überhaupt im Decoder vorhanden sind - schon bei der Neuanmeldung gemeinsam ausgelesen. Sie sind auch in der "lokomotive.cs" gesichert. Von daher brauchen sie nicht und werden auch nicht neu eingelesen. Was ich aber bei Aufruf des Konfigurationsmenüs beobachtet habe, ist das Absetzen eines "mfx-Bind" mit nachfolgendem "mfx-Verify".
Ein Auslesen der Decoderdaten erfolgt erst durch den "CV Auslesen"-Button - nach einem neuerlichen "mfx-Verify" zum Start.
Zur Klarstellung:
Meine Beobachtungen beruhen nur auf den LOG-protokollen über den Datenverkehr am CAN-Bus in der CS2 zwischen GFP und GUI. Ich habe den dabei stattfindenden Datenverkehr auf der Schiene nicht beobachtet.
