Hallihallo,

habe gerade festgestellt, dass die CS3, wenn mfx und DCC Protokoll aktiv sind, es bis zu 2 Sekunden dauert bis ein DCC Befehl, zB. Licht an, an der Lok ankommt

Die CS2 zeigt so ein Verhalten nicht - Knopf gedrückt und Licht brennt quasi sofort

Jetzt bin ich gerade etwas irritiert, weil zB. Momentfunktionen mit 1er Sekunde, hier Achtungspfiff, nicht von der CS3 durchgereicht werden! Die CS2 es aber problemlos beherrscht!

Nette Grüße
KHPM

Hallo KHPM,

wieviele Loks sind in der Zentrale mit irgendeiner aktiven Funktion bzw fahrend drin?

Wir hatten mal ein ähnliches Problem mit unserer Vereins-ECoS und da waren bei den über 400 gespeicherten Fahrzeugen ziemlich viele dabei, bei denen z B noch Licht an war und das sendet die Zentrale dann regelmäßig an die Gleise (Refresh-Zyklus), denn die Zentrale weiß ja nicht, ob die entsprechende Lok noch drauf steht. Reaktionszeit waren teilweise 5-10 Sekunden...
Lösung bei uns war (nach einem Hinweis / Tipp von der ESU-Hotline), konsequent immer alles ausschalten.

Gruß
Railstefan

Hallo Railstefan,

an der CS3 (in Testbetrieb) sind 30 Fahrzeuge angemeldet, wobei nur 6 auf der Schiene stehen! Bei der CS2 (Anlage) sind über 100 angemeldet und zirka 15 sehen auf der Schiene!

Hab im CS3 Menu auch noch nichts in der Richtung gefunden

Nette Grüße
KHPM

Hallo KHPM,

es kommt nicht nur auf die Anzahl angemeldeter Fahrzeuge an, sondern auf die Anzahl mit irgendeiner aktivierten Funktion.
Bei uns war es reines DCC-Protokoll - das mag aber bei anderen Protokollen / Zentralen anders sein, als bei uns.
Bei uns stehen meist so um die 50 Loks auf der Anlage, aber da ja mal gewechselt wird, passierte es schon mal, dass Loks mit Licht runtergenommen wurden und davon merkt die Zentrale ja nichts und die Lok bleibt im Refresh-Zyklus drin, der somit immer mehr Befehle enthält und damit länger dauert.
Dazu findet sich bei der ECoS auch nichts in den Menüs - es war Fleißarbeit: jede Lok einzeln aufrufen, schauen und alles ausschalten, was noch an ist.

Hast du denn mal geschaut, ob Loks alle ausgeschaltet sind und keine Fahrstufe haben?

Gruß
Railstefan

Hallo KHPM,
die CS3 mag es nicht wenn Lokeinträge im DCC Format mit gleicher Adresse vorhanden sind.
Da kommt es zu diesem Verzögerungseffekt, diese Erfahrung musste ich machen.

Hallihallo,

alle Funktion der vorhanden Loks auf der CS3 jetzt ausgeschaltet, keine Lok mit gleicher DCC Adresse im CS3 Lokmenue vorhanden - Problem mit zirka 2 Sekunden Verzögerung bleibt

An CS2 und Intellbox1 kein Problem, es wird verzögerungsfrei geschaltet! Nun ja die CS3 ist wahrscheinlich doch noch nicht fertig entwickelt, immer noch betastatus

Also warte ich auf das nächste Masterupdate und eigentlich bin ich mit der CS2 mehr aus zufrieden

Nette Grüße
KHPM

Hallo KHPM,

Zitat von khpmueller im Beitrag #6

---

alle Funktion der vorhanden Loks auf der CS3 jetzt ausgeschaltet, keine Lok mit gleicher DCC Adresse im CS3 Lokmenue vorhanden - Problem mit zirka 2 Sekunden Verzögerung bleibt

An CS2 und Intellbox1 kein Problem, es wird verzögerungsfrei geschaltet! Nun ja die CS3 ist wahrscheinlich doch noch nicht fertig entwickelt, immer noch betastatus

Also warte ich auf das nächste Masterupdate und eigentlich bin ich mit der CS2 mehr aus zufrieden

---

Kann auch sein das der berüchtigte C4 in piko Loks (falls vorhanden) die verzögerung verursacht.

Bart

Zitat von khpmueller im Beitrag #6

---

…
Also warte ich auf das nächste Masterupdate und eigentlich bin ich mit der CS2 mehr aus zufrieden

Nette Grüße
KHPM

---

Zitat von Railstefan im Beitrag #4

---

....... davon merkt die Zentrale ja nichts und die Lok bleibt im Refresh-Zyklus drin, der somit immer mehr Befehle enthält und damit länger dauert.

---

Hallo KHPM,

Frage: Hast du an der CS, die so lange zum Senden braucht, auch S88 Rückmelder dran?

Gruß est2fe

Hallo KHPM,

Zitat von est2fe im Beitrag #11

---

Hast du an der CS, die so lange zum Senden braucht, auch S88 Rückmelder dran?

---

Hallihallo,

das ist nur eine C-Gleis Testanlage mit DCC Weixhendecodern an der CS3, keine Rückmeldungen oder Bremsmodule!

Nette Grüße
KHPM

Zitat von Lokführer01 im Beitrag #10

---

Zitat von Railstefan im Beitrag #4

---

....... davon merkt die Zentrale ja nichts und die Lok bleibt im Refresh-Zyklus drin, der somit immer mehr Befehle enthält und damit länger dauert.

---

Refresh-Zyklus? Das war wohl nix. Der Befehl wird einmal ausgesendet und dann war's das. Was soll denn da aufgefrischt werden. Da müsste ja nach paar Minuten nichts mehr gehen, wenn da R-Zyklen gesendet werden, weil die zusendene Datenpakete immer länger würden. Außerdem, wo sollen den die Befehle zwischengespeichert werden, damit der Prozessor weiß, was er alles senden muss?
Also, einmal Befehl raus und Schluss ist oder meinst du, dass auch die Weichen laufend irgendwelche Befehle bekommen, wenn nichts passieret?

---

Zitat von khpmueller im Beitrag #1

---

Hallihallo,

habe gerade festgestellt, dass die CS3, wenn mfx und DCC Protokoll aktiv sind, es bis zu 2 Sekunden dauert bis ein DCC Befehl, zB. Licht an, an der Lok ankommt

Die CS2 zeigt so ein Verhalten nicht - Knopf gedrückt und Licht brennt quasi sofort

Jetzt bin ich gerade etwas irritiert, weil zB. Momentfunktionen mit 1er Sekunde, hier Achtungspfiff, nicht von der CS3 durchgereicht werden! Die CS2 es aber problemlos beherrscht!

Nette Grüße
KHPM

---

Zitat

---

In Wirklichkeit ist es so, dass die CS2/3

* jeden Befehl sofort massiv sendet (5-10x)
* Fahrbefehle aller fahrenden Loks dauernd regelmäßig wiederholt
* Weichenbefehle nur kurz wiederholt
* Funktionen von Loks in einem langsamen Zyklus wiederholt

Der Vorgang an sich ist komplex, aber das sichert ab, dass Loks auch wieder anfahren sobald das Signal grün wird, wenn sie am roten Signal standen während "ihr" Befehl gesendet wurde.

---

Nun erzähle mir mal, wo die Befehle gespeichert werden, damit diese wiederholt werden können, wie du schreibst. Da ich in der Digitaltechnik firm bin, würde mich das echt interessieren.
So wie du das schreibst, würden dann mit der Zeit so viele Datenpakete auf dem Bus sein, so das nichts mehr läuft. Bei 4.5 und 9kHz Übertragungsrate müssten viele Datenpakete, auch Frams genannt, übertragen werden und jeder Befehl würde erst nach 20 - 30 sek. zur Ausführung kommen.
Also, wo werden die Befehle zwischengespeichert?

Hallo Andreas (Lokführer01),

wenn ich mir das bisher veröffentliche CAN-Protokoll so ansehe und das, was der andere Andreas schreibt durchlese,
komme ich zu dem Schluss, dass die Lok-Befehle (incl. deren Funktionen) eigentlich nur im GFP zwischengespeichert
werden können.
Ich habe bisher nicht beobachtet, dass auf dem CAN Befehle wiederholt werden (mit Ausnahme der regelmässigen
mfx-seek und der Geräteanfragen). Weichenschaltbefehle werden nur für die 2 - 4 mal wiederholen im GFP
zwischengespeichert, und dann wohl vergessen.

Gruß est2fe

Hallo est2fe,

vielen Dank für deine Ausführung. Das bestätigt auch meine Aussage. Mir ist nämlich nicht bekannt, dass in der Zentrale ein RAM-Speicher vorhanden ist und die paar Bytes des Zwischenspeichers im Prozessor reichen nicht aus, dass dort ellenlange Befehle gespeichert werden. Selbst wenn ein externer Speicher vorhanden wäre, würde dieser nach eine Wille "überlaufen".
Noch mal Danke.

Hallo Lokführer01,

Zitat von Lokführer01 im Beitrag #15

---

Da ich in der Digitaltechnik firm bin, würde mich das echt interessieren.
So wie du das schreibst, würden dann mit der Zeit so viele Datenpakete auf dem Bus sein, so das nichts mehr läuft. Bei 4.5 und 9kHz Übertragungsrate müssten viele Datenpakete, auch Frams genannt, übertragen werden und jeder Befehl würde erst nach 20 - 30 sek. zur Ausführung kommen.
Also, wo werden die Befehle zwischengespeichert?

---

Zitat von Lokführer01 im Beitrag #15

---

Mir ist nämlich nicht bekannt, dass in der Zentrale ein RAM-Speicher vorhanden ist und die paar Bytes des Zwischenspeichers im Prozessor reichen nicht aus, dass dort ellenlange Befehle gespeichert werden. Selbst wenn ein externer Speicher vorhanden wäre, würde dieser nach eine Wille "überlaufen".

---

Zitat von Lokführer01 im Beitrag #17

---

Mir ist nämlich nicht bekannt, dass in der Zentrale ein RAM-Speicher vorhanden ist und die paar Bytes des Zwischenspeichers im Prozessor reichen nicht aus, dass dort ellenlange Befehle gespeichert werden.

---

Guten Morgen @khpmueller

Gibt es etwas Neues

Hatte gestern Zeit und war an der Anlage, habe mich an dein Problem erinnert und probiert in wie weit sich die Funktionen bei DCC Decodern schalten lassen.
Verzögerungen konnte ich an Loks die mit DCC-Format angesprochen werden nicht feststellen. Ich betreibe meine CS3 mit Multiprotokoll und ca. 25 Loks auf der Anlage, 100 Einträge in der Lokliste.


Welchen Softwarestand hat deine CS3

Hast du die CS3 mal getrennt von der Anlage hochgefahren und mit paar separaten Gleisen getestet

Hallo Ingo,

was ich gestern so nebenbei festgestellt habe, tritt das Problem bei mir nur mit Uhlenbrock Decodern auf, welche auch Piko verbaut hat!

Ich kann die Sache gerade aus Zeitgründen nicht weiter verfolgen.

Nette Grüße
KHPM

Hallo KHPM,
könnte es sein, dass bei den Decodern der berühmt berüchtigte C4 in den Piko-Loks das Übel ist?
Volker

Zitat von volkerS im Beitrag #22

---

Hallo KHPM,
könnte es sein, dass bei den Decodern der berühmt berüchtigte C4 in den Piko-Loks das Übel ist?
Volker

---

Hallo Viktor,

Zitat von vikr im Beitrag #12

---

und wieviele Rückmeldungen sollten da eigentlich pro Minute in etwa verarbeitet werden...

---