Hallo,

meine Frage richtet sich an die Systems Spezis:

Haltet Ihr es für möglich 2 CS zusammen zu betreiben?
Ziel ist, ein weiteres vollwertiges Fahrpult an entfernter Stelle aufzubauen.
Ich meine damit eine Art von Master Slave Modus.
Die zweite CS würde dann als Fahrpult dienen und vielleicht könnte man noch den internen Booster für einen separaten Stromkreis nutzen.

Wenn dies möglich wäre, dann würde ich mir glatt noch eine 2. CS zulegen.

Wie sind Eure Meinungen?

Viele Grüße

Achim

Hallo Achim!

Wir haben das hier vor einiger Zeit schon mal diskutiert.

Grundsätzlich dürfte dies realisierbar sein. Ich finde die Idee persönlich auch nicht uninteressant. Bei M* dürften allerdings andere Baustellen Vorrang haben. Von daher würde ich mir in absehbarer Zeit keine große Hoffnung machen.

Eine selbstgestrickte Lösung halte ich ohne Eingriff in die Software für kaum realisierbar.

Zitat von V188

---

Hallo,
...
und vielleicht könnte man noch den internen Booster für einen separaten Stromkreis nutzen.

Wenn dies möglich wäre, dann würde ich mir glatt noch eine 2. CS zulegen.

Wie sind Eure Meinungen?

Viele Grüße

Achim

---

Hi Achim,
und wenn Du einmal falsch verdrahtest, ist mindestens eine CS futsch.

Aber zu dem Thema gibt es ja Kollegen die können Dir das super erklären.

Hallo Achim,

vermutlich kann man die zweite CS per Schienenausgang an den so genannten Sniffereingang der ersten CS anschließen. Das bringt aber einige Einschränkungen mit sich: erhöhten Konfigurationsaufwand und möglicher Weise können an der Slave-CS nur Motorola-Loks gefahren werden.

Hallo Achim,
hier ging es los.

Guten Abend

Wir sind im Besitz zweier CS`n. Ich habe schon öfters mal darüber nachgedacht es einfach auszuprobieren. Theoretische Überlegungen halten mich allerdings davon ab. Selbst wenn ich die beiden Stationen zu 100% voneinander trennen würde, wäre mir das Risiko zu groß das etwas passiert.
Ich habe immer zwei Stromkreise.
Der Fahrbetrieb wäre stark eingeschränkt. Eine Lokomotive muss auf beiden Stationen angemeldet sein, sonst läuft nichts. Hierbei stellt sich die Frage ob die MFX Lokomotiven der Zweit- CS auch verraten welche interne Adresse sie der Erst- CS mitgeteilt hat. Spätestens bei Überfahrt einer Trennstelle in den nächsten CS Stromkreis wäre Schluss. Die Geschwindigkeit auf der Zweit- CS muss schon voreingestellt sein. Es spielt dabei keine Rolle ob es sich um eine MFX oder MM Lokomotive handelt.
Wer dieses Problem löst sollte sich bei M* melden. Man wird sich freuen dass die Boosterproblematik gelöst wurde.
Die Idee mit dem Sniffer ist mir auch schon gekommen. Allerdings lassen sich die CS`en in der Praxis nicht verbinden.
Bleibt der CAN Bus (daran wird später eine Slave CS mit Sicherheit angeschlossen). Dieser ist nach meiner Information nicht für den Betrieb einer vollwertigen zweiten CS ausgelegt. Wer weiß auch schon genau wie der CAN Bus geschaltet ist.

Für mich persönlich wäre im Moment die dezentrale Weichensteuerung interessant. Dabei werden dieselben Probleme wie oben beschrieben auftreten . Da die Weichendecoder nicht Rückmeldefähig sind, können die entsprechenden Impulse nicht in der CS verarbeitet werden.

Hallo Michael,

weder bei Tante M* noch bei Onkel ESU ist es derzeit möglich, 2 Master zusammen zu schalten. Ich habe mal mit dem Chef von ESU am Telefon gesprochen und er hat mir gesagt, dass man an so was noch nicht gedacht hat. Ich habe dann seine Gedanken schon in die richtige Richtung gelenkt. Aber, das wird erst kommen, wenn sie keine anderen Sorgen mehr haben.
Bezüglich CAN kann ich derzeit nur so viel sagen, dass es prinzipiell problemlos möglich wäre, da zwei Master zusammen zu schalten. Allerdings ist, zumindest beim CAN von Tante M* zur Zeit im Programm nichts vorgesehen, dass ein Master auch mal Slave spielen würde. Ein Master will immer ein Master sein, und sich nicht beugen! So ist es leider momentan vom Protokoll her implementiert! Leider ist es daher, weil ein Master keinen Slave-Mode hat deswegen nicht möglich, zwei oder gar mehrere Zentralen zusammenzuschalten. Für die Modulleute wäre so was aber ideal!
Wenn zwei Master zusammen gesteckt würden, dann ist, bedingt durch den Protokollaufbau, keine Kommunikation über den CAN mehr möglich, weil es da dann sofort zu Transmission-Errors kommt (für die Fachleute: Es wird zwei Sender geben, welche gleiche CAN-IDs mit unterschiedlichen Daten senden, und dann kommt es zur Kollision, und der Bus wird gerissen), und nach 128 Versuchen, einen Frame vergeblich an einen Busknoten zu senden, schaltet die CAN-HW auf Fehler und verabschiedet sich mit einer Meldung an die SW vom Bus. Was die SW daraufhin macht, habe ich noch nicht ausprobiert!
Aber hier jetzt noch eine Kuriosität:
Bisher hat eine MS und die CS vor dem Update immer nur reines Tante M* -CAN Protokoll (M-CAN) gesprochen. Nach dem Update spricht eine MS mit der CS immer noch M-CAN und der Sniffer in der CS spricht ECoSLink mit der CS! Das nur so nebenbei. Ich denke dass Tante M* selber das nicht mal weiß! Die Hauptsache ist doch, dass es einfach funktioniert, oder

Eigentlich müsste jetzt eine Box her, an die man mehrere Zentralen anstöpseln kann, und die dann die Kopplung aller Zentralen auf logischer Ebene bewerkstelligt. Die Box verhält sich gegenüber den Zentralen wie ein Slave, sendet dann aber alle empfangenen Daten an die anderen weiter, natürlich über intelligente Filter und so weiter...

Gruß est2fe

Hört hört,
näheres? Zum Protokollaufbau. Würde ich gerne haben.

Hallo Josef,

dafür ist es noch etwas früh, weil der Booster noch nicht raus ist. Wer weiss, was sich Tante M* da noch alles einfallen lässt! Und dann wäre es ja gleich am Anfang schon wieder veraltet

Bist du überhaupt in der Lage mit einem µC oder gar PC an den CAN ranzukommen, oder ist das pure Neugierde? Die Tools dafür sind nicht ganz billig! Wenn ja, ist es ja auch kein großes Problem mehr, da mal ein Log-File zu machen, und die Daten genau anzuschauen! Man kommt schon dahinter, was die da treiben. Da ist nichts verschlüsselt, zumindest beim M-CAN nicht.

Abwartenden Gruß

est2fe

Hallo est2fe,

ich denke, dass die Standardbauteile da auch eine Verschlüsselung gar nicht hergeben. CAN ist ja entwickelt in lokalen, begrenzten, eher statischen Umgebungen und nicht für Netzwerke mit tausenden von Teilnehmern und einer gewissen Dynamik.

Wolfgang

Hallo Wolfgang,

in unserem Umfeld bei der MoBa hier ist der CAN auch nicht für viele Teilnehmer ausgelegt! Man hat es hier auch mit einer relativ begrenzten Teilnehmeranzahl zu tun. Eine Zentrale, vielleicht noch ein zwei oder 3 MS, dann den Sniffer, und dann in Zukunft noch ein paar Booster.
Aber denke dran, die CAN-Transceiver haben auch nur einen max. Fan-Out von 128 Receivern! Mehr geht nicht! Und wenn man mehr will, muss man zwischenpuffern. Dass Tante M* so was macht, ist sehr unwahrscheinlich!

Zur Verschlüsselung: Die Nutzdatenbytes könnte man bequem verschlüsseln, und wenn es nur mit einem XOR von der Quersumme der ID wäre. Aber nichts von all dem ist gemacht worden!
Danke! Die hier genannte Methode wäre problemlos mit dem eingesetzten µC möglich gewesen, und schon hätte es keiner mehr in endlicher Zeit und mit vernünftigem Aufwand knacken können.

Gruß

est2fe

Hallo est2fe,

Aber hier jetzt noch eine Kuriosität:
Bisher hat eine MS und die CS vor dem Update immer nur reines Tante M* -CAN Protokoll (M-CAN) gesprochen. Nach dem Update spricht eine MS mit der CS immer noch M-CAN und der Sniffer in der CS spricht ECoSLink mit der CS!


wo sieht man den die Daten von dem Ecos Link.? Auf dem normalen CAN habe ich die noch nicht gesehen.... Sind da zwei CAN in der CS?

Gruß Thorsten

P.S. das mit dem Zitat muss ich noch üben

Hallo Thorsten,

nein, das ist physikalisch ein und derselbe Bus.
Da ist es ESU geglückt, das ECoSLink-Protokoll und das M-CAN-Protokoll durch geschicktes Vergeben von Knotenadressen beim M-CAN-Protokoll, parallel, ohne dass sich die beiden Protokolle in die Haare bekommen, auf dem CAN laufen zu lassen.

Gruß

est2fe

Hallo,
ist denn das etwas Neues? Im Hilfstext der CS steht ja "Ecoslink" drin. M* wird das auch schon bekannt sein.

Hallo est2fe,

aber manchmal begeistert mich auch die Schlichtheit manch anderer Zeitgenossen.
Im Ernst, den großen Ehrgeiz, solche Protokolle zu entschlüsseln hege ich nicht mehr, man wird mit den Jahren ruhiger.
Andererseits bräuchte ein guter Freund von mir als Rentner eine Aufgabe, das Protokoll sagen wir mal für den PC zu erschließen. Mal schauen.

Hallo Josef,

ist es da aus steuerungstechnischer Sicht nicht besser, das Ethernetprotokoll herzunehmen? Das ist auch etwas beschrieben, im Gegensatz zum CAN-Protokoll.

Gruß

est2fe