[klausR]

wer hat einen PC an der Märklin-CS2 hängen? ( oder umgekehrt

[juemo]

Hallo Klaus,

es gibt noch keine Anbindung der CS2 an den PC. Ich bekam vor ca. 2 Wochen von unserm Chef die Info, vor dem Jahreswechsel wird es wohl nichts werden. Tante M muß/will noch fehlende Informationen liefern.

Das Fleisch ist willig ..........

[Udo Nitzsche]

Zitat von juemo

---

es gibt noch keine Anbindung der CS2 an den PC.

---

Habe ich jetzt was verpasst?

Die Hardware (Ethernet-Schnittstelle) ist vorhanden und die aktuelle Schnittstellenbeschreibung kann - im Gegensatz zur CS2 - von jedermann (!) von der Märklin-Homepage heruntergeladen werden.

Was darin noch fehlt, ist die Abfrage der s88-Bausteine, da diese momentan noch nicht über die GUI-GFP-Schnittstelle (CAN-Bus) geführt werden.

Dennoch: Loks könnte man mit einem geeigneten Programm schon vom PC fernsteuern. Solche Programme gibt es noch nicht - alle kommerziellen Anbieter warten da wohl noch auf die s88-Abfrage...

[surfer35]

Ich denke mal,da meinte jemand ein fertiges Programm,was käuflich zu erwerben ist.

Gruß Guido

[DiegoGarcia]

Zitat von klausR

---

wer hat einen PC an der Märklin-CS2 hängen? ( oder umgekehrt

---

Frederik hat den PC an der CS2: http://www.mrrailnet.com/
(wie immer ist er einer der ersten, wenn nicht sogar der Erste).

[sd]

Hallo,

es gibt da noch meinen experimentellen Konverter für serielle 6051-Befehle (zu finden bei http://sourceforge.net/projects/steg). Damit kann man jedes Programm, das 6051-Interface-Befehle absetzen kann, an der CS2 betreiben.

Ich habe es mit der Märklin Software 60512 sowie einer Demo von Windigipet getestet und es funktioniert ohne größere Probleme.

Das Programm kann übrigens s88-Module abfragen. Diese Funktion ist in der CS2 erst mal nur experimentell realisiert und deshalb noch nicht dokumentiert.

Gruß, Stefan

[DiegoGarcia]

Zitat von sd

---

Das Programm kann übrigens s88-Module abfragen. Diese Funktion ist in der CS2 erst mal nur experimentell realisiert und deshalb noch nicht dokumentiert.

---

Hallo Stefan,

danke für die Infos, ich glaube Du hattest das schon mal hier gepostet, aber ich habe leider den Thread nicht wiedergefunden. Also dann gebührt aus meiner Sicht Dir der Titel "Erster".

S88 und CS2 - darfst Du berichten wie Du es programmiert hast?

Ciao
Diego

[Lichtleiter]

Hallo,

ich habe mir das eben mal durchgelesen (die CAN/ETH-Spec) und bin fast vom Stuhl gefallen!

UDP und 13 Byte große Pakete können nicht wirklich deren Ernst sein, oder?

Noch dünner kann man das Brett nicht bohren!!!

Was die ESU Spezifikation mit ihrer textbasierten Schnittstelle an "Geschwätzigkeit" zuviel hat (ist aber wenigstens TCP), hat die CS2 DEUTLICH zuwenig.

An M* (bzw. Guido Weckwerth, wie auch immer er gerade firmiert ): Ethernet bzw. IP ist nicht CAN und ein Gateway dazwischen muß deutlich mehr leisten!!!

Gruß, Jörn

[ChristianS]

Zitat von Lichtleiter

---

An M* (bzw. Guido Weckwerth, wie auch immer er gerade firmiert ): Ethernet bzw. IP ist nicht CAN und ein Gateway dazwischen muß deutlich mehr leisten!!!

---

Werd doch mal konkreter, was du verbesser wolltest!

[kaeselok]

Ich vermute mal Jörn stört sich am UDP Protokoll wo man nie sicher sein kann ob Pakete auch beim Empfänger ankommen weil es eben keine Quittung gibt.
Aber auch ich frage mich warum das gerade hier verwendet wird?!


Viele Grüße,

Kalle

[Lichtleiter]

Zitat von ChristianS

---

Zitat von Lichtleiter

---

An M* (bzw. Guido Weckwerth, wie auch immer er gerade firmiert ): Ethernet bzw. IP ist nicht CAN und ein Gateway dazwischen muß deutlich mehr leisten!!!

---

Werd doch mal konkreter, was du verbesser wolltest!

---

Hallo...

- während vielleicht die Steuerung der Loks über UDP gemacht werden kann, weil das Signal ja sowieso ständig wiederholt wird, braucht man für die Übermittlung von "Einmal"-Ereignissen, wie Zubehördecoderschaltungen, oder Rückmeldungen ein Protokoll mit einer Datensicherungsschicht (auch OSI Layer 2 genannt). Dazu verwendet man beim Internetprotokoll überlicherweise TCP, oder implementiert die Sicherungsschicht auf der Basis von UDP selber (davon ist aber nichts zu erkennen bei Märklin)

- Paketgrößen von 13 Byte sind, wenn sie zudem noch zyklisch wiederholt werden (was bei der Abbildung des CAN Buses der Fall ist), das allerübelste, was man einer Netzwerkinfrastruktur antun kann. Die Router (DSL;Ethernet, WLAN, etc.) werden dabei abkotzen. Sogar das VoIP Protokoll zur Internettelefonie (RTP), paketiert i.d.R. mindestens 160 Byte weise und steht damit sogar schon in der Kritik, dass es das Netz zu sehr belastet.

- Jedes 13 Byte UDP Paket hat einen Headeroverhead, der in keinem Verhältnis zu den übertragenen 13 Byte Payload steht.

u.s.w.

Das Protokoll ist auf einem informatischen Niveau das, wenn man es mit der Automobiltechnik vergleichen würde, bedeutet... dass ein Hersteller, nach der allgemeinen Verfügbarkeit von Airbags, es wieder mit ein paar Luftballons im Handschuhfach probiert...

Gruß, Jörn

[Gast]

Hallo Järn,

spätestens im Gleis oder zum MA-Decoder gilt bei Modelbahn-Steuereungen traditionell "fire and forget".

Bei grösseren Anlage installiert man zum Schalten deswegen eine seperaten Booster, damit Funken im Gleis nicht einen Weichenbefehl zerstören. Da praktisch alle Datenpaketverluste bei den Fahrbefeheln im Gleis liegen, werden traditionell Fire and Forget - Strukturen genutzt.

Bzgl. des IPs als PC-Schnittstelle kann ich aber Deine Bedenken im Bezug auf Funknetzte teilen. Es gibt natürlich auch Hersteller , die nutzen auch beim PC-Interface gesicherte Verbindungen.

Revulutionär diesbzgl ist der RailCom-Entwurf der optional einen Gleis-Rückkanal zur Sicherung von Loko-Befehlen im Gleis nutz. Damit erübrigt sich zumindest theoretisch auch die Lokbefehlwiederholung nach einem Acknoledge. Allerdings ist der wohl bisher nur Zukunftssmusik. Ob man den wertvollen schmalbandigen Rückkanal wirklich zu Lasten anderer sonst denkbarer Funktionalität nutzt, halte ich dennoch für unwahrscheinlich.

Viele Grüße
Frank

[Gast]

Hallo Jörn,

Zitat

---

13 Byte große Pakete

---

was ist an den 13 Byte so dramatisch :

Danke Frank

P.S. :

Sorry, habe die Antwort jetzt erst gelesen.

Ich lkann dazu nur sagen: Das "Gateway" gibt wohl vorteilhaften direkten Zugriff auf den Märklin-Bus, dessen Nachrichten in Teilen dem mfx-Gleis-Format sehr nahe stehen. Folglicherweise (denn das Gleis muss mit minimalen Paketlängen auskommen) sind die Märklin-Bus-Pakete zwecks schneller latenzfreier Umsetzung auch klein, und folglich auch die Schnittstellenpakete aus des Gateways.

Was soll der PC jetzt machen? Warten bis 160 Bytes zusammenkommen?
Also bis der User 2 Weichen, 3 Sonderfunktionen und 13 Fahrbefehle abgesezt hat?

Bezüglich der möglichen Datenvolumina im Fahrbetrieb ist der Ethernet sicherlich oversized und nicht notwendig, aber er macht die Übertragung doch auch nicht zwangsweise langsamer? Ausserdem kann er ja noch für schnelle Updates, Lokbilder und Screenshots genutzt werden.

Nochmal Grüße
Frank

[est2fe]

Hallo Jörn,

1. Sorry, aber da hast du die Spec. nicht richtig gelesen!
Alle wichtigen Befehle werden quittiert.

2. Die Befehle werden nicht zyklisch wiederholt, wie auf der Schiene üblich! Das ist ja das Gute am CAN! Kein Polling oder sonst was, und man ist sich sogar halbwegs sicher, dass wenn die CAN-HW so ein Datenpaket bei der SW abliefert, dass das auch 1. wirklich gesendet wurde und 2. in aller Regel auch fehlerfrei übertragen wurde! Was braucht man mehr. Das ist der ideale Bus für so eine Aufgabe! Besser geht es nicht.

3. Die CAN-Befehle haben nun mal eine 29-Bit-ID, einen 4-Bit DLC und max. 8 Datanbytes, welche auf dem CAN sogar gesichert übertragen werden. Warum soll man denn das für den PC aufblasen!

Also ich finde das recht gut gelöst! Das ist viel besser als alles, was bisher dagewesen ist! Denke bitte daran, dass auf dem CAN auch kleine µCs damit zurecht kommen müssen! Und bitteschön, warum soll man die auf dem CAN schon relativ kurzen aber effektive Nutzdateninfos nur für den PC mit Null an Mehr-Info versehen? Das macht in meinen Augen keinen Sinn, sondern generiert nur Blindleistung auf beiden Seiten. Darauf können aber beide Seiten wirklich verzichten und aus der Ersparnis vielleicht echte Wirkleistung machen.

Gruß

est2fe

[G.Nosse]

Hallo,

Zitat von Lichtleiter

---

- während vielleicht die Steuerung der Loks über UDP gemacht werden kann, weil das Signal ja sowieso ständig wiederholt wird, braucht man für die Übermittlung von "Einmal"-Ereignissen, wie Zubehördecoderschaltungen, oder Rückmeldungen ein Protokoll mit einer Datensicherungsschicht (auch OSI Layer 2 genannt).

---

Die Datensicherungsschicht existiert auf Ebene 2 nur theoretisch (LLC) und wird beim Einsatz von IP-basierten Protokollen nicht angewendet, da hier das Ethernetformat nicht nach IEEE 802.3, sondern nach dem DIX-Standard eingesetzt wird.

Zitat von Lichtleiter

---

Die Router (DSL;Ethernet, WLAN, etc.) werden dabei abkotzen.

---

Wer betreibt denn seine Modelleisenbahn über Router?

Ansonsten ist Deine pauschale Kritik am verbindungslosen UDP völlig haltlos, solange wir uns in einem LAN befinden, warum sollen denn bitte schön hier Pakete verloren gehen? Der Vorteil ist eindeutig die Geschwindigkeit durch fehlendes Handshaking und Flusskontrolle. Und was die Paketgröße angeht, vermutlich liegen einfach nicht mehr Nutzdaten an.

[Gast]

Hallo ,

Zitat

---

- Paketgrößen von 13 Byte sind, wenn sie zudem noch zyklisch wiederholt werden (was bei der Abbildung des CAN Buses der Fall ist), das allerübelste, was man einer Netzwerkinfrastruktur antun kann. Die Router (DSL;Ethernet, WLAN, etc.) werden dabei abkotzen. Sogar das VoIP Protokoll zur Internettelefonie (RTP), paketiert i.d.R. mindestens 160 Byte weise und steht damit sogar schon in der Kritik, dass es das Netz zu sehr belastet.

---

Auch hier scheint ein Missverständnis vorzuliegen. Am CAN wird meineswissens nichts wiederholt sondern gesichert übertragen.

Erst der GFP (Gleisformatprozessor) übersetzt die einmalig einkommenden Befehle in sich zyklisch wiederholende Befehle auf dem Gleis.

Also 3 unterschiedliche Strecken:

Vom PC per Ethernet zum Märklin-Bus-Gateway 1*UDP
Vom Gateway an alle GFP 1* gesichert via MärklinBus(over CAN)
Von GFP via mm/mfx periodisch wiederholend (n*) durch Gleis an Loko.

Es gibt als keine 1:1 Relation der Schnittstellenbefehle zu den Gleisbefehlen


Auch die Zitat "geschwätzige" ECos TCP-Schnittstelle ist keine Problem fürs Ethernet. Aber deren Inhalt lässt vermuten, das die Schnittstelle erst mal die ECos-Applikation anspricht, die dann (wenn sie Zeit hat) den ECos-Bus informiert.

Die CS2 kann mas sich eher als 2 Geräte vorstellen :

1. Das Gateway, das auf den Märklin-Bus zugreift

2. Die (GUI-)Applikation die auch auf den Märklin-Bus zugreift.

Gruss Frank

[Lichtleiter]

Zitat von Gast_001

---

Was soll der PC jetzt machen? Warten bis 160 Bytes zusammenkommen?
Also bis der User 2 Weichen, 3 Sonderfunktionen und 13 Fahrbefehle abgesezt hat?

---

Hallo Frank,

...ja, genau! Üblich und sinnvoll ist ein Paketierungsintervall welches die Daten eines bestimmten Zeitrasters zusammenfasst.

Gruß, Jörn

[Lichtleiter]

Zitat von est2fe

---

3. Die CAN-Befehle haben nun mal eine 29-Bit-ID, einen 4-Bit DLC und max. 8 Datanbytes, welche auf dem CAN sogar gesichert übertragen werden.

Warum soll man denn das für den PC aufblasen!

---

...weil IP eben ein ganz anderes Protokoll über eine heterogene Physik mit ganz anderen Eigenschaften ist!

Gruß, Jörn

[Lichtleiter]

Zitat von G.Nosse

---

Die Datensicherungsschicht existiert auf Ebene 2 nur theoretisch (LLC) und wird beim Einsatz von IP-basierten Protokollen nicht angewendet, da hier das Ethernetformat nicht nach IEEE 802.3, sondern nach dem DIX-Standard eingesetzt wird.

---

...wir reden hier nicht über "CAN über Ethernet" in einer dezidierten Umgebung, sondern über eine heterogene IP Infrastruktur, bei der ein Medium auch Ethernet sein kann. Und hier sind nunmal Sicherungsschichten in der logischen IP Ebene (z.B. TCP) üblich.

Zitat von Lichtleiter

---

Die Router (DSL;Ethernet, WLAN, etc.) werden dabei abkotzen.

---

Zitat von G.Nosse

---

Wer betreibt denn seine Modelleisenbahn über Router?

Ansonsten ist Deine pauschale Kritik am verbindungslosen UDP völlig haltlos, solange wir uns in einem LAN befinden, warum sollen denn bitte schön hier Pakete verloren gehen? Der Vorteil ist eindeutig die Geschwindigkeit durch fehlendes Handshaking und Flusskontrolle. Und was die Paketgröße angeht, vermutlich liegen einfach nicht mehr Nutzdaten an.

---

Ich denke, dass nur ein Teil der Benutzer den PC direkt über ein X-Kabel (bzw. die automatische RxTx Umschaltung) betreibt. Die Annahme, dass in einem lokalen Netz keine Daten verlorengehen, ist natürlich vollkommen abwegig und es als Vorteil darzustellen, dass auf eine Sicherung verzichtet wird ebenso.

Gruß, Jörn

[Gast]

Zitat von Lichtleiter

---

Zitat von Gast_001

---

Was soll der PC jetzt machen? Warten bis 160 Bytes zusammenkommen?
Also bis der User 2 Weichen, 3 Sonderfunktionen und 13 Fahrbefehle abgesezt hat?

---

Hallo Frank,

...ja, genau! Üblich und sinnvoll ist ein Paketierungsintervall welches die Daten eines bestimmten Zeitrasters zusammenfasst.

Gruß, Jörn

---

Das ist nicht dein Ernst.

[Lichtleiter]

Zitat von Gast_001

---

Zitat von Lichtleiter

---

Zitat von Gast_001

---

Was soll der PC jetzt machen? Warten bis 160 Bytes zusammenkommen?
Also bis der User 2 Weichen, 3 Sonderfunktionen und 13 Fahrbefehle abgesezt hat?

---

Hallo Frank,

...ja, genau! Üblich und sinnvoll ist ein Paketierungsintervall welches die Daten eines bestimmten Zeitrasters zusammenfasst.

Gruß, Jörn

---

Das ist nicht dein Ernst.

---

Hallo Frank,

doch, IP ist KEIN Medium, bei dem alles ad hoc gesendet wird, wenn dieses eine untragbar hohe Fragmentierung bedeutet (was es in diesem Fall tut!). Man legt eine "Ende zu Ende Latenz" fest, und defragmentiert innerhalb dieses Intervalls den Datenstrom.

Z.B. könnte man 20 Millisekunden nehmen, was maximal 50 Übertragungen, bzw. Pakete pro Sekunde bedeutet (eine Auflösung die über einer fünfzigstel Sekunde liegt, haben Modellbahnsteuerungen sowieso nicht). es werden also immer alle Daten eines 20ms Intervalls zusammengefasst und übertragen (außer sie überschreiten die festgelegtze maximale Paketgröße, dann wird schon vor Ablauf des Intervals übertragen und evtl. der Intervalltimer neu gestartet)

Dieses Vorgehen ist konform zu den Vorstellungen nationaler und internationaler Normungsgremien. Es ist "state of the art" für die Protokolldatenübertragung synchroner Medien wie CAN über asynchrone Medien wie IP über heterogene Infrastrukturen.

Gruß, Jörn

[Gast]

Hallo zusammen,

Zitat von Lichtleiter

---

Z.B. könnte man 20 Millisekunden nehmen, was maximal 50 Übertragungen, bzw. Pakete pro Sekunde bedeutet (eine Auflösung die über einer fünfzigstel Sekunde liegt, haben Modellbahnsteuerungen sowieso nicht). es werden also immer alle Daten eines 20ms Intervalls zusammengefasst und übertragen (außer sie überschreiten die festgelegtze maximale Paketgröße, dann wird schon vor Ablauf des Intervals übertragen und evtl. der Intervalltimer neu gestartet)

---

Danke für den Hinweis. Die von Dir genannten 20ms entsprechen der Grössenordnung in der MoBa üblicher Latenzzeiten, also auch aus meiner Sicht, ein angemessenens Verfahren.

Es hat hier einige Beiträge gegeben , die berichtet haben, das eine Update des CS erst nach mehrmaligem Versuch geklappt hat. Wenn ich annehme, das eine IP Verbindung immer über die ganzen Verbindungszeit UDP (ungesichert) oder TCP (gesichert) ist, so würde das bedeuten, das auch das CS2-Update via UDP erfolgt : Könnte das der Grund dafür sein, das das Update manchmal wiederholt werden muss :

Grundsätzlich gehört die Latenzzeit für mich zu den potentiell bedenklichen Gründe gegen den Einsatz von Ethernet als PC-MoBa-Schnittstelle in vielfältig genutzten Netzen (VoIP, Internet, MoBa,etc.). Die von Dir genannte Latenz von 20ms scheint mir bereits eine brauchbare Grössenordnung, und wird von den schnellen seriellen MoBa-Systemen sogar in der Summe über alle 3 Teilstrecken (PC->Interface, Interface->Gleissignalprozessor, Gleissignalprozessor->Loko) erreicht oder gar unterboten.

Zitat von Lichtleiter

---

Es ist "state of the art" für die Protokolldatenübertragung synchroner Medien wie CAN über asynchrone Medien wie IP über heterogene Infrastrukturen.

---

CAN gilt meineswissens genauso als asynchron: CAN und Loconet (zwei Standards für Systembusse in der MoBa, also der Bus der die Steuerdevices verbindet) gelten als asynchron, da ihre Devices (Steuergeräte, Interfaces, Rückmeldeempfänger, bidirektionale Booster) jederzeit in den halpduplexen Bus senden können, der aber immer nur ein Paket gleichzeitig übertragen kann. Bei gleichzeitigem Versuch 2er Devices wirklich gleichzeitig zu senden, kommt zwangsläug ein Kollisionsverfahren zum Einsatz (ähnlich Ethernet), das ein Device zum erneuten Sende-Versuch zwingt, was zumindest beim CAN hervorragend funktionieren soll. Aber weil so die Devices aus Sicht Ihrer Anwendung jederzeit senden können, wann sie wollen, und nicht wenn sie dran sind, ist CAN ein asynchroner Bus.

Zitat von est2fe

---

2. ... Das ist ja das Gute am CAN! Kein Polling oder sonst was, und man ist sich sogar halbwegs sicher

---

Sowohl das Kolllisionsverfahren des CAN als auch das Pollen eines synchronen RS485 sind keine wirklich die Laufzeit belastenden Grössen.

Grüße Frank

[Markus Herzog]

Hallo Frank,

Zitat von Gast_001

---

Es hat hier einige Beiträge gegeben , die berichtet haben, das eine Update des CS erst nach mehrmaligem Versuch geklappt hat. Wenn ich annehme, das eine IP Verbindung immer über die ganzen Verbindungszeit UDP (ungesichert) oder TCP (gesichert) ist, so würde das bedeuten, das auch das CS2-Update via UDP erfolgt : Könnte das der Grund dafür sein, das das Update manchmal wiederholt werden muss :

---

Das Update der CS2 erfolgt per rsync via ssh und damit dann also per TCP (die Shell-Skripte dazu kann man sich wunderbar in dem downloadbaren Updates ansehen).
Ich würde mal vermuten die Probleme tauchen bei temporärer Überlastung des Update-Servers und damit auftretenden Timeouts auf.

Grüße
Markus

[Gast]

Hallo Markus,

Zitat

---

Das Update der CS2 erfolgt per rsync via ssh und damit dann also per TCP

---

Danke, "per TCP", das ist die gewünschte Entwarnung.
Grüße Frank

[sd]

Hallo,

ich kann die Kritik an UDP nicht nachvollziehen. Das ist in diesem Fall die optimale Lösung.

Die eigentliche Kommunikationsschnittstelle ist ja der CAN-basierte Märklin-Bus. Um diesen auf Ethernet herauszuführen, bleibt nur UDP übrig, da die Eigenschaften von CAN und UDP etwa vergleichbar sind.

TCP hat einen gewaltigen Overhead und ist durch das Handshake nicht mal ansatzweise echtzeitfähig. Die Sicherung bringt nichts, da CAN selbst ungesichert ist. Und die verbindungsorientierte Kommunikation verhindert einen Broadcast, wie es CAN macht.

TCP ist ein Protokoll rein für das World Wide Web, in der Automatisierungstechnik hat es nichts zu suchen.

Ich habe es beruflich mit der Entwicklung verteilter Computersysteme zu tun, die tw. Realzeitanforderungen und eine Zeitauflösung von 1 ms haben, und wir benutzen fast nur UDP zur Kommunikation. Wir haben noch nie festgestellt, das im lokalen Netz mal ein Telegramm verlorengegangen ist, und auch das Timing ist genau. Größere Jitter sind eigentlich nur unter Windows feststellbar, weil der Timer von Windows wesentlich ungenauer ist als der von Linux.

Letztendlich kommt es nicht auf die theoretischen Grenzen an, sondern darauf, dass es in der entsprechenden Umgebung funktioniert. Und das tut es.

Gruß, Stefan