[BBII]

Hallo,

ich habe auf einer mittelgroßen Anlage das Problem, dass Weichen aus TC heraus verzögert geschaltet werden, auch das Fahren ist recht ruckelig, Anfahr- und Bremsrampen sind sehr stufig. Ich habe z.B. einen Weichentest, dieser schaltet per TC-Makro am Anfang alle Weichen einmal durch, Schaltabstand im Makro 200ms. Sollte man tack-200ms-tack-200ms-tack-200ms erwarten. Real wird es zu 800ms-tack-tack-tack-tack-800ms-tack-tack-tack-tack. Dieses verzögerte Schalten tritt auch auf, wenn noch kein Zug in Bewegung ist. Startet man Zugfahrten, ist es ähnlich: die Geschwindigkeitsstufen springen etwa im Sekundentakt.

Natürlich denkt man da an Hardwareengpässe (PC zu schwach, Digitalsystem überlastet), aber so wirklich gefunden habe ich das Problem noch nicht. Nachfolgend mal die Daten und was ich bisher unternommen habe, um das Problem einzukreisen:

Daten Anlage:
3 Digitalsysteme für Fahren, Schalten, Melden. Schalten mit einer Intellibox (19200 Baud), Fahren und Melden mit einer TamsEC (57600 Baud).
Etwa 800 Melder, etwa 60 Züge, ca. 250 Weichen.

PC:
Dell, Win7 Quadcore, mehrere Bildschirme, nur für Modellbahn, nur TC laufend (aktuelle Version TC9.0A4), kein Netzwerkanschluß (offline), kein Virenscanner, möglichst wenig Treiber. Systemmonitor zeigt CPU-Load etwa bei 10-15%, Speicher bei 20% (1,5GB von 8GB).

Analyse:
PC-Auslastung ist moderat, kein Speicherswap, sollte also ausreichend performant sein.
Ich haben auf allen Schnittstellen Daten Logger draufgehängt und stelle fest:
TC sendet alle 10ms an die Zentralen einen Poll 0x78 0xCB (XEvtSTS) und erhält umgehend 00 als Antwort. Der Datenverkehr läuft schnell und ohne Probleme. Im Datenverkehr sehe ich dann z.B. beim Weichentest die blockweise Ausgabe von Befehlen.

Tests:
[list][*]Abklemmen der beiden TamsEC, nur die Schaltzentrale: die Weichenbefehle gehen gleichmäßig raus.
[*]Hinzufügen der 'Fahren'-Zentrale: die Weichenbefehle gehen gleichmäßig raus.
[*]Hinzufügen der 'Melder'-Zentrale: die Weichenbefehle ruckeln. Der Logger auf der Melderzentrale zeigt (nach der Initphase) keinen einzigen sich ändernden Melder. Das Meldersystem ist stabil, kein Flackern. Es wird mit 10ms Raster gepollt und jeweils 'no change' geantwortet.

Vielleicht war jemand schon mal in einer ähnliche Situation und kann mir Tipps geben, wo ich fallweise was verändern kann. Ich habe z.B. schon überlegt, die Melder auf HSI88 umzustellen.

[Erich Müller]

Hallo,

was passiert, wenn die IB mit der Melder-EC zusammen angesteckt sind, ohne die Fahr-EC?

Meine Vermutung geht dahin:
Wenn im o.g. Fall auch Störungen auftreten, sollte sich die Suche auf die Melder-EC konzentrieren: möglicherweise hat sie einen Defekt. (Es wäre aber denkbar, dass sie als Fahr-Zentrale noch tauglich ist.)

Wenn nicht, dann stören sich die beiden EC in ihrer Kommunikation mit dem PC - es soll ja vorkommen, dass man sich bei Zwillingsschwestern mal irrt...

[BBII]

Guten Tag,

Zitat

---

was passiert, wenn die IB mit der Melder-EC zusammen angesteckt sind, ohne die Fahr-EC?

---

Das Fahren ist auch 'stufig', sieht man z.B, bei Anfahren: Zug fahrt an, springt auf eine höhere Geschwindigkeit, bleibt da, springt höher, bleibt, ...

Zitat

---

Zentralen-Defekt?

---

Eher nicht, es sind Datenanalysatoren mit dran, die Kommunikation mit jeder Zentrale verläuft reibungslos. Es kann natürlich sein, dass sich auf einer höheren Ebene die 'Zwillingsschwestern' gegenseitig beeinflussen. Ich stelle heute mal die Rückmelder auf HSI88 um, vielleicht bringt das was.

[BBII]

Update:

ich habe mittlerweile die Melderzentrale durch HSI88 ersetzt. Dadurch sinkt das Ruckeln beim Weichentest signifkant ab. Trotzdem bleiben aber Unregelmäßigkeiten, beim Anfahren einer Lok sieht man diese Unregelmäßigkeiten sowohl optisch (ruckartiges Hochbeschleunigen) als auch im Datenlogger (mehrere Fahrstufen schnell hintereinander, dann wieder längere Pause).

Insgesamt ist die Situation für mich recht unbefriedigend.

[sbuehne]

Hallo,
ich hatte ein ähnliches Problem in der Konfiguration TC und IB (allerdings noch IB I).
Die IB schaffte es nicht, die Operationen schnell genug auf das Gleis zu bringen. Die Folge ware zu spät schaltende Weichen und Loks, die regelmäßig zu weit fuhren.
Was ein wenig Abhilfe schafft, ist es den IC-Bus auszuschlaten (Sonderoption 33 = 0), wenn Du keine Märtklin Steuerpults angeschlossen hast. Das beschleunigt die IB ein wenig.

Ich habe mich dann aber entschlossen Schalten und Fahren zu trennen und die IB nur noch für das Weichenschalten verwendet. Das ging so einigermaßen, allerdings hatte bei mir die IB auch gerne mal einen Reset zwischendurch gemacht, so dass ich sie jetzt durch eine Tams RedBox ersetzt habe.
Die RedBox ist deutlich schneller in der Verarbeitung als die IB.

Grüße
Stephan

[BBII]

Hallo,

wie oben schon geschrieben: es sind keine IB I im EInsatz, ich benutze 57600 Baud und ich kann keinerlei Verzögerung auf der Hardwareseite erkennen (habe das mit exakten Zeitstempeln mitprotokolliert): TC schickt alle 10ms einen Poll raus, und erhält sofort die Antwort.

[sbuehne]

Hallo W.,
weder der PC noch die Geschwindigkeit der seriellen Schnittstelle sind das Problem, sondern das Senden des Schaltsignal. Bei der Tams z.B. sieht das folgendermaßen aus:

Zitat K.Tams:
"Die Mindestdauer eines Schaltbefehls ist 10ms, eher mehr. Es werden 16 Befehle hintereinander weg gesendet um sicher zu gehen, dass der Decoder das empfangen hat. Danach muss wieder ein Refresh-Zyklus für Fahrdecoder eingeschoben werden und dann kommt der nächste Befehl dran. Also rein theoretisch würde ich sagen, dass das Schalten einer Weiche so um die 200ms dauert."

Bei der IB wird das nicht viel anders sein. Du siehst das da 57500 Baud auf der Schnittstelle ziemlich bedeutungslos sind, da das Senden des Signals und die Prozessierung der unterschiedlichen Befehle (Lok und Schaltbefehle) in der IB der limitierende Faktor sind.
Du kannst also davon ausgehen dass ca. 5 Schaltbefehle/ Sekunde abgearbeitet werden können, aber auch nur, wenn die IB das so wie oben beschrieben macht. Wenn nun noch Loksteuerbefehle dazu kommen, also Geschwindigkeitsänderungen, wird es eher langsamer, da die dann auch noch verarbeitet werden müssen.
Serielle Schnittstellen sind gepuffert, d.h. der PC kann die Befehle an die IB absetzen und bekommt von dort auch eine Bestätigung über den Empfang.
Das heißt aber nicht, dass sie nun direkt zum Dekoder geschickt werden. Das dauert eben pro Schaltbefehl z.B. 200ms.
Beispiel: TC schaltet eine Weichenstraße und schickt z.B. 15 Schaltbefehle zur IB. Das dauert nur Microsekunden. Die IB quittiert den Empfang und beginnt nun mit dem Senden der Schaltbefehle. Angenommen jeder Schaltbefehl dauert 200ms dann sind das nun 200 x 15 = 3 Sekunden bis alle Befehle abgesetzt wurden.
Das ist jetzt noch etwas vereinfacht, da hier noch die Ausschalbefehle für die Dekoder hinzukommen, was auch wieder Zeit kostet.

Da kann der PC noch so schnell sein, dararan wird sich nichts ändern. Einzige Chance ist Schalten und Fahren zu trennen und wenn zu viele Weichen geschaltet werden müssen, müssen dann auc noch die Weichen auf verschiedene Systeme aufgeteilt werden. Ich glaube bei Dir würde schon helfen Fahren und Schalten zu trennen und in TC eine Schaltpause von 200ms für die IB einzutragen.

Grüße
Stephan

[BBII]

Guten Tag,

darf ich nochmal auf die bereits geschilderte Hardwaresituation und erfolgte Tests hinweisen: Weichen, Fahren, Rückmelden sind bereits auf drei Digitalsysteme verteilt. Siehe oben. Und wenn es an Schaltzeiten, DCC-Wiederholungen etc. des Digitalssystems für Schalten liegen würde, dann müßte dieses Stottern auch vorhanden sein, wenn nur das Schaltsystem mit TC verbunden ist. Tut es aber nicht. Und wenn nur das Meldesystem angeschlossen ist, dann sehe ich auch dem Datenverkehr zum Schaltsystem durchgängigen Verkehr, aber eben die Schaltbefehl kommen stottrig aus TC raus. Und beim Meldesystem sehe ich auch flüssigen Datenverkehr (nur das Frage/Antwortspiel: hast du was / nein, aber das kommt alle 10ms).