Hallo Stefan (JoMa),
das mit den kurzen Rückmelderabschnitten kann ich verstehen, was du da verfolgen willst.
Jetzt kommt es auf deine Anlage und die Anzahl der gleichzeitig fahrenden Züge an, die du da hast.
Hast du insgesamt nur "recht wenig", macht es nichts aus, wenn du kurze Rückmelder hast. Fahren da
aber mehr als 5 Züge gleichzeitg, und jeder Zug hat auch noch sagen wir mal 20 Achsen und jede Achse
erzeugt dann ein Rückmeldeereignis, hast du recht schnell auf dem Rückmeldebus ein richtiges
"Rückmeldegewitter". Dann kommt es recht schnell vor, dass man da kurzzeitig mehr als 10 Rückmelde-
Ereignisse pro Sekunde erzeugt werden.
Jetzt kommt es darauf an, wie deine Steuerung aufgebaut ist und funktioniert. Mit Steuerung meine
ich, entweder deine Zentrale oder ein externes Steuerungsprogramm. In der Regel funktioniert das so,
dass wenn da ein RM-Ereignis eintrifft, der Programmteil, der die RM-Ereignisse verarbeitet, ausgeführt
wird, und der dann alle Unterfunktionen abklappert und schaut, ob er was machen muss. Dauert das "etwas"
länger weil du z. B. recht viel programmiert hast, oder deine Anlage etwas umfangreicher ist, kann es
schon mal sein, dass das Steuerungsprogramm noch nicht ganz mit der Abarbeitung eines kompletten
Zyklusses fertig ist, aber dann schon wieder das nächste RM-Ereignis eintifft. Wenn das der Fall ist, und
dieser Zustand länger andauert, kommt dein Steuerungsprogramm einfach nicht mehr hinter her und es
kann dann sein, dass es RM-Ereignisse verliert oder einfriert oder oder. Da kommen dann die komischsten
Sachen zum Vorschein. Meine CS2 z. B. ist dann einfach mal für einige Zeit eingfroren, als es auf dem
RM-Bus zu viele Ereignisse gab. (Das war aber wegen einem defekte RM-Modul das ständig RM-Ereignisse
produziert hat, ohne dass da was angelegen ist, also so ca. 50Hz-Brummen oder so was ==> Massefehler).
Deswegen versucht man schon vom Aufbau her, die Rückmeldeereignisse so zu gestalten, dass es reicht
zum richtig Steuern, aber nicht zu viel und zu unnötigen Ereignissen führt, welche dann die Steuerung
komplett erden.
Deswegen wird das in der Regel so ausgeführt und in den Steuerungsprogrammen gemacht, dass man
auf Flanken reagiert. Die Steuerung betrachtet einen Block als belegt, wenn mind. eine steigende Flanke
auf "belegt" statt gefunden hat. Weiteres ab- und wieder einschalten (Prellen) ändert am Belegtzustand
aber in der Regel dann nichts mehr. Aber, jedes RM-Ereignis führt trotzdem dazu, dass die
RM-verabeitenden Programmteile jedes mal bei jeder Änderung aufgerufen werden. Es könnte ja ein
Ereignis dabei sein, das zu einer Änderung des internen Zustandes beiträgt.
Ein konkretes Beispiel von mir aus der jüngsten Zeit:
Ich habe eine Modulanlage wo ich derzeit ca. 10 Züge gleichzeitig fahren lassen kann. Das erzeugt
dann auch entsprechend viele Ereignisse. Bei mir waren es im Durchschnitt im Normalbetrieb
ca. 10 Ereignisse pro Sekunde (Fahren und Schalten), was eigentlich noch nicht so sehr viel ist,
und in der Regel auch problemlos von allen daran beteiligten Komponenten fehlerfrei verarbeitet
werden kann.
Ein Teil der Strecke besteht noch aus alten M-Gleisen. Die habe ich mit insgesammt 3 x S88DC-
Rückmeldern (Stromfühler) ausgestattet. Die Belegung ist auch recht voll, es sind pro 8er Block nur
1 bis max. 2 Melder frei. Also das sind "nur" ca. 40 Rückmelder (ist eigentlich nicht viel).
Durch einen konstruktiven Fehler melden diese S88DC-RM bei einem Kurzschluss auf einem Kanal, und sei
der Kurzschluss auch nur sehr kurz, gleichzeitig alle 8 RM-Blöcke als belegt. Das erzeugt natürlich auf dem
Rückmeldebus einen ganzen Blumenstrauss an Rückmelde-Ereignissen. Zuerst werden alle 8 Melder als belegt
gemeldet, und kurz danach diejenigen welche in Wirklichkeit frei sind, als unbelegt. An zwei Stellen ist es
mir passiert, dass durch den weichen schalldämmenden Untergrund bei schweren Lokomotiven das M-Gleis
so weit in die Dämmung gedrückt wurde, dass dann der Schraubenkopf, mit welchem das Gleis befestigt
war, mit dem Schleifer einen Kurzschluss fabriziert hat. Das war nur ganz kurz, aber bei dieser und bei einer
andern Lok dann immer zu einem sehr kurzen Überstom mit dem 8-fach-Blumenstrauss an Rückmeldeereignissen
geführt hat. Meine CS hatte das noch problemlos weggesteckt, aber das daran angeschlossene RocRail hatte
damit so seine Probleme. Es kam immer wieder zu der Situation, dass in RocRail dabei Fehler auftraten.
Das betraf jetzt nicht nur das Problem, dass auf unbelegten Abschnitten jetzt auf einmal Phantom-
Rückmeldungen statt fanden, sondern dass diese Geisterrückmeldungen trotz freiwerden (in der CS unbelegt)
in RocRail aber als belegt stehen geblieben sind, was dann den ganzen Betrieb angehalten hat. Dann musste ich
immer von Hand die Geister-Rückmeldung, die ja in Wirklichkeit schon lange weg waren, in RocRail von
Hand zurück setzten. Das war sehr lästig und es hat mich über 1 Jahr gekostet, bis ich das geblickt hatte,
was da vor sich geht. Das zum Thema viele Rückmelde-Ereignisse gleichzeitig. Das Thema ist zum Glück jetzt
seit ca. 1 Monat Geschichte.
Jetzt habe ich an diesen 2 Stellen die Schrauben etwas weiter eingedreht und siehe da in RocRail funktioniert
auch auf einmal alles wie es soll. RR hatte also mit diesem Blumenstrauss an vielen kurzen Rückmeldungen
ein Problem. Es kam sogar hin und wieder vor, dass dabei der RR-Server einfach abgestürzt ist.
Dann fahren alle Züge auf einmal unkontrolliert mit ihrer aktuellen Geschwindigkeit weiter oder
bleiben einfach stehen und das führte unweigerlich nach kurzer Zeit ins globale Chaos! Wenn ich das nicht
sofort bemerkt hatte, dann war das Ergebnis dannach, dass ein Teil der Züge entgleist waren, weil ein
anderer Zug unkontrolliert aufgefahren ist. So eine Situation dann zu bereinigen kostete mich regelmässig
viel Zeit und war eine richtige Spassbremse!
Gruß est2fe