[vikr]

Hallo,

gibt es das eigentlich so schön auch schon als "TCP-CAN-Monitor" um an den Central-Stationen mit den aktuellen Softwareversionen zu horchen?

MfG

vik

[bertr2d2]

Hallo Vik,

Zitat

---

Hallo,

gibt es das eigentlich so schön auch schon als "TCP-CAN-Monitor" .... ?

---

schon heute kann der can-monitor sogenannten Pcap (dank Rainer Müller auch NPcap) Dateien lesen. Das sind Netzwerkmitschnitte. Die Online Analyse wird bald nachgerüstet.

Ein Bitte: nicht Märklins Software mit ins Spiel bringen. Ansonsten bekommt irgend jemand wieder überflüssige Post von Rechtsanwälten.

Gruß

Gerd

[aftpriv]

Servus Gerd und Forianer

Zitat

---

Zitat

---

... gibt es das eigentlich so schön auch schon als "TCP-CAN-Monitor" .... ?

---

Ein Bitte: nicht Märklins Software mit ins Spiel bringen. Ansonsten bekommt irgend jemand wieder überflüssige Post von Rechtsanwälten.

---

Die M*rklin-Software wird überhaupt nicht mehr benötigt (wurde sie eigentlich noch nie) da es wesentlich andere (bessere?) Möglichkeiten gibt eine Modellbahn zu steuern.

Die Bastellösungen müssen nur DAU-fähig gemacht werden (ähnliches Problem wie mit Windoof und Linux)

Gruß
Alf

PS. die Welt steuert seine Modellbahn mit DCC-Protokol, einige wenige (!! !!) mit Motorola-Derivaten!

[bertr2d2]

Hallo Alf,

Zitat

---

Servus Gerd und Forianer

Zitat

---

Zitat

---

... gibt es das eigentlich so schön auch schon als "TCP-CAN-Monitor" .... ?

---

Ein Bitte: nicht Märklins Software mit ins Spiel bringen. Ansonsten bekommt irgend jemand wieder überflüssige Post von Rechtsanwälten.

---

Die M*rklin-Software wird überhaupt nicht mehr benötigt (wurde sie eigentlich noch nie) da es wesentlich andere (bessere?) Möglichkeiten gibt eine Modellbahn zu steuern.

---

sicher, Märklins Software ist letztendlich nur für einfache Steuerung praxistauglich. Man braucht noch eine (vollwertige) Steuerung. Aber das ist nicht das Thema hier. Es geht darum unnötige Scherereien im Vorhinein zu vermeiden. Märklins CS2 Software ist für mich aus bekannten Gründen tabu.

Gruß

Gerd

[aftpriv]

Hi Gerd

ich wollte damit nur aufzeigen wie widersinnig das Ganze ist, alle meckern über die hohen Kosten der Moba-Komponenten, bei Zentralen wird aber sinnlos Geld beim Fenster raus geschmissen.

Wie Du richtig schreibst, genügt für einfache Aufgaben eine von vielen Herstellern angebotene Zentrale. Wenn aber etwas mehr an Komfort oder Leistung verlangt wird, ist eine vollwertige Steuerung notwendig.

Diese vollwertige Steuerung erfordet einen PC oder Laptop (nicht billig, kosten einige 100 Teuros), der dann natürlich während Moba-Zeit meist für keine andere Aufgabe zur Verfügung steht.

Eine kostengünstige Lösung wie mehrfach hier im Forum aufgezeigt, ist die Verwendung eines Einplatinencomputers wie RaspberryPi, BananaPi oder BiggleBoneBlack (oder Andere). Dann sitzt die Intelligenz im Klein-Rechner und es wird keine teure Zentrale mit ihren "Mickimaus" (copyright Disney?)- Bildschirmen benötigt.

Das ganze zu einem Zehntel der Kosten einer Zentrale von diversen Moba-Herstellern.

Zitat

---

Die Bastellösungen müssen nur DAU-fähig gemacht werden (ähnliches Problem wie mit Windoof und Linux)

---

Damit diese Lösungen ein größeres Publikum ansprechen könnten, wäre dies einer der Hauptpunkte

Gruß
Alf

[vikr]

Hallo,

Zitat

---

Die Bastellösungen müssen nur DAU-fähig gemacht werden (ähnliches Problem wie mit Windoof und Linux)

---

"nur DAU-fähig gemacht" ist - insbesondere in Verbindung mit abwärtskompatibel und preisgünstig - gerade nicht trivial!

MfG

vik

[aftpriv]

Hallo Vic

Zitat

---

Zitat

---

Die Bastellösungen müssen nur DAU-fähig gemacht werden (ähnliches Problem wie mit Windoof und Linux)

---

insbesondere in Verbindung mit abwärtskompatibel und preisgünstig - gerade nicht trivial!

---

erkläre mir mal was Du damit meinst!
Wie weit abwärts kompatibel willst Du die Digitalsteuerung machen - runter auf Analog?

Heute gängige Systeme sind weltweit DCC und deutschlandweit zusätzlich Motorola in Betrieb, alle Anderen (FMZfmz usw) sind obsolete.

Gruß Alf

[Erich Müller]

Hallo Alf,

Zitat

---

Heute gängige Systeme sind weltweit DCC und deutschlandweit zusätzlich Motorola in Betrieb, alle Anderen (FMZfmz usw) sind obsolete.

---

Du erzählst das heute schon zum zweiten Mal...
mfx blendest du dabei wohl aus?

Motorola ist zumindest zur Loksteuerung auch obsolet, seit es mfx gibt - und die neue ZIMO-Decoder-Generation soll mfx können; hoffen wir mal, dass sie das besser können als Piko...

[aftpriv]

Hallo Erich

ich erzähle nicht zum zweiten Mal, ich zitiere nur nochmals das Zitat von Vic!

Für mich ist der direkte Vorgänger von mfx das Mororola-Format, deshalb auch keine explizite Nennung von mfx.

Ob Motorola wirklich schon obsolet ist will ich nicht kommentieren, glaube es aber (noch) nicht.

Gruß
Alf

PS: ob die Zimo´s was unter mfx taugen wird sich sicher in der nächsten Zeit zeigen.

[Erich Müller]

Hallo Alf,

auch wenn vor mfx Motorola war, haben beide nichts miteinander zu tun. Mfx ist nicht die Weiterentwicklung von Märklin-Motorola. Ebensowenig wie der VW Passat die Weiterentwicklung des VW 1600 ist oder der New Beetle vom VW Käfer - auch da sind es nur die Marke und die vier Räder, die beide gemeinsam haben.

P.S. Das hier sind keine Zitate von vik, die sind ganz allein auf deinem Mist gewachsen:

Zitat

---

PS. die Welt steuert seine Modellbahn mit DCC-Protokol, einige wenige (!! !!) mit Motorola-Derivaten!

---

Zitat

---

Heute gängige Systeme sind weltweit DCC und deutschlandweit zusätzlich Motorola in Betrieb, alle Anderen (FMZfmz usw) sind obsolete.

---

Und glaube mir: MM2 mit 14 Fahrstufen und nur 4 Funktionen ist obsolet. Aktuell ist DCC oder mfx.

Ach ja - Deine Einlassungen zum Protokoll sind nicht nur sachlich falsch, sondern auch t: weil es hier um CAN geht. Das hat mit Gleisprotokollen rein gar und überhaupt nichts zu tun.

[Rainer Müller]

Hallo,

ich wollte schon länger den CAN-Monitor auch unter Windows betreiben, damit man die Wiresharkaufzeichnungen, die unter Windows gemacht wurden, nicht erst auf einen anderen Rechner transferieren muss. Dem Zweck entsprechend ist nur die Analyse von Aufzeichnungen vorgesehen.
[quote="Rainer Müller" post_id=1869656 time=1536166329 user_id=1332]
Deutlich sperriger wird die Aufgabe für den Windows-Desktop. Dort fehlen viele der benötigten Headerdateien oder sind anders; dass man nur den Teil für die PCAP-Analyse betreiben will und nicht das CAN-Capture macht es wieder etwas einfacher. Aber es gibt diverse Hürden:
- die der libpcap entsprechende wpcap.dll hat ein Generationenproblem, sie versteht nur das pcap-Format und nicht das WS-favorisierte pcapng-Format (ng = new generation).
- der MS-Compiler (aus VS17) interpretiert manche Datenstrukturen anders als der gcc, das erfordert Nacharbeiten in den Headerdateien.
- wann die Einfärbecodes interpretiert oder als Text ausgegeben werden scheint noch ein Geheimnis von Windows zu sein.
Jedoch ist die Hoffnung da, dass das noch irgendwann was wird.
[/quote]
Für Programmierfreudige hier nun die Dateien für MS Visual Studio:

Das Archiv enthält zwei Unterverzeichnisse; das mit dem Namen "can-monitor" die eigentlichen Projektdateien:
- can-monitor.c ist unter Linux compiliert funktionsgleich Gerds Original, bei Windows werden im Wesentlichen per "ifndef" die nur für Livebetrieb notwendigen Teile ausgeklammert.
- can-monitor.h und crc-ccitt.c sind unverändert von Gerd kopiert
- *.sln und *.vcxproj braucht Visual Studio als Make-Ersatz
- wpcap.lib beschreibt die Schnittstelle zur dynamisch gebundenen wpcap-Bibliothek.

Das zweite Unterverzeichnis "linuxinc" enthält zusammengesammelte Hilfsdateien, die Fehlendes aber unter Linux Übliches bei Windows nachrüsten und einige Anpassungen zwecks Compilierbarkeit unter VC enthalten und evtl. auch für andere Projekte zu gebrauchen sind.
Die beiden Verzeichnisse müssen nebeneinander stehen, dann kann man über Visual Studio über die sln-Datei die Erzeugung der 32-Bit-Version, die auch unter 64-Bit Windows läuft, anstoßen.

Bei Wirehark vor Version 3 wurde beim Start des CAN-Monitors die wpcap.dll automatisch im Pfad gefunden, seit Version 3 "versteckt" npcap sie in einem privaten Verzeichnis (bei mir C:WindowsSysWOW64Npcap). Damit der Programmstart also dann klappt, kopiert man wpcap.dll und packet.dll von dort ins Verzeichnis, in dem schon can-monitor.exe steht. Dafür kann die neue Version jetzt auch pcapng-Dateien lesen und nicht mehr nur die älteren pcap.


Gruß
Rainer

[joachimkr]

Hallo zusammen,

ich habe mir von Gerd mal die lua-Datei geholt, und mit Wireshark über das Netzwerk dann mitprotokolliert, wie ein Besetztmelder "S88 Link" sich in das System einbindet ( oder die CS2 das tut ).
Ich steige nicht durch. Ich sehe die Felder aus CAN und sehe Kommandos, response-Bit, sehe wie der Melder Konfigurationsdaten --- tja, bekommt oder schickt, das kann ich nicht unterscheiden. Ich sehe dort ASCII Klartext, der Stückweise übertragen wird.
Die CS2 zeigt den S88 Link an, mit einer Nummer. #15275 - die ist für mich ein Knackpunkt. Die CS2 soll den Melder ja einbinden und wenn er mal kaputt ist, muss man den ersetzen können. Also müsste sie eigentlich diese Nummer frei vergeben und der Melder muss sie als 'Adresse' nutzen.

Das System habe ich aber noch nicht begriffen, wie diese Nummer in den Melder kommt, oder wie die CS2 die Nummer vom Melder bekommt - der Hersteller muss sich bei der Nummernvergabe ja eigentlich nach der CS2 richten und dort muss irgendwie ein Mapping eingebaut sein, wie nun Melder 15275 auf Kontaktnummern zu mappen ist.

Ich baue gerade einen Melder mit Raspberry als Teilnehmer über die CAN2UDP Bridge in der CS, muss auf dem Raspberry verstehen, was von der CS2 kommt. Dass ich die CS2 nicht kenne, das kommt nun erschwerend hinzu...
Bin nun für weitere Tipps dankbar, wie ich verstehen könnte, was da läuft.

Viele Grüße,
Joachim

[bertr2d2]

Hallo Joachim,

das Lua-Skript war nur ein 'Proof of Conecpt' und wurde nicht weiter verfolgt.
Der can-monitor (läuft unter Linux/RPi) hat insbesondere durch die Arbeit von Rainer einige Updates erfahren. Er kann auch PCAP Files lesen, wobei das Lesen direkt auf dem CAN-Bus für Dich interessanter sein sollte, wenn Du die Geheimnisse des LinkS88 lüften willst.

Gruß

Gerd

[vikr]

Hallo Joachim,

Zitat von joachimkr im Beitrag #37

---

Die CS2 zeigt den S88 Link an, mit einer Nummer. #15275 - die ist für mich ein Knackpunkt. Die CS2 soll den Melder ja einbinden und wenn er mal kaputt ist, muss man den ersetzen können. Also müsste sie eigentlich diese Nummer frei vergeben und der Melder muss sie als 'Adresse' nutzen.

---

die CS2 vergibt bei ersten Anstecken eines Link s 88 eine Gerätenummer. Diese Gerätenummer kann von Anwender im Setup der CS2 geändert werden. An diese Gerätenummer werden Kontakte "geknüpft". Nach Anmeldung können alle bisher in der CS2 an dem alten Link s 88 dem neuen Link s 88 zugeordnet werden. Das Gerät mit der alten Gerätenummer kann dann aus der Geräteliste gelöscht werden und steht wieder zur Verfügung.

Zitat von joachimkr im Beitrag #37

---

Dass ich die CS2 nicht kenne, das kommt nun erschwerend hinzu...
Bin nun für weitere Tipps dankbar, wie ich verstehen könnte, was da läuft.

---

Die Geräte-UIDnummer taucht in der CAN-Nachricht zur Kontaktabfrage etc. auf.
In der - über den eingebauten Webserver - abrufbaren Doku in der CS2 (im Gegensatz zur CS3) sind die Nachrichten auch ganz gut beschrieben.

MfG

vik


edit: einmal Gerätenummer durch Geräte-UID korrigiert.

[joachimkr]

Hallo Gerd, Hallo Vik,

Mein Raspberry sitzt per LAN mit auf dem Bus. Er verlässt sich auf die Brückenfunktion der CS2.
Kann der CAN Monitor das ebenfalls? Oder muss ich eine CC Schnitte dranbauen? Der -i Parameter deutet darauf hin. Was gebe ich an, wenn Netzwerkverkehr abgehorcht werden soll, falls das geht?

Mein Wireshark Versuch läuft auf einem Laptop nebenher. Nicht so aussichtsreich, wenn Du bereits etwas besseres hast, probiere ich das.

Die CS2 Doku innerhalb eines Web-Interface?! Das ist Spitze, da werde ich schauen! Danke für den Tipp!

Viele Grüße,
Joachim

[Eckhart]

Zitat von joachimkr im Beitrag #37

---

Das System habe ich aber noch nicht begriffen, wie diese Nummer in den Melder kommt, oder wie die CS2 die Nummer vom Melder bekommt - der Hersteller muss sich bei der Nummernvergabe ja eigentlich nach der CS2 richten und dort muss irgendwie ein Mapping eingebaut sein, wie nun Melder 15275 auf Kontaktnummern zu mappen ist.

---

Zitat von vikr im Beitrag #39

---

die CS2 vergibt bei ersten Anstecken eines Link s 88 eine Gerätenummer. Diese Gerätenummer kann von Anwender im Setup der CS2 geändert werden. An diese Gerätenummer werden Kontakte "geknüpft".

---

Zur Orientierung, wenn du die Spezifikation vor dir hast:

Alle Geräte (z.B. S88 Link) melden sich beim Anmeldeprozess (Kodierung mit Teilnehmer-Ping und Statusdaten-Konfiguration) mit einer UID (64 Bit) an und die behalten sie auch! Die ID Verwaltung der "weichen" Geräte ID (16 Bit) erfolgt mit dem CAN "Systembefehl", CAN-ID 0x00 und Sub-CMD 0x0C. Man kommuniziert mit dem Gerät über die UID. Der Fragende kodiert das Response-Bit mit 0, das Gerät antwortet mit 1. Mit DLC 5 fragt man das Gerät nach seiner derzeitigen "weichen" Geräte ID. Das Gerät antwortet mit DLC 7 und teilt seine "weiche" Geräte ID mit. Wenn man selber den DLC 7 benutzt kann man die "weiche" Geräte ID damit neu setzen.

Die Rückmeldungen werden mit "Rückmelde Event" CAN-ID 0x22 kodiert. DLC 5, auf der "weichen" Geräte ID gesendet, schaltet die Rückmeldungen des Gerätes ein (wenn das nicht bereits das CS2/3 GUI, oder ein PC Programm, getan hat), Ab dann kommen die Rückmeldungen mit 0x22, dem Response-Bit auf 1, sowie dem "weichen" 16 Bit Gerätekenner (aus der vorherigen Beschreibung) der 16 Bit Rückmeldekontaktnummer und dem Staus des Kontaktes. Die S88 Link Kontaktnummern sind die aus seiner Bedienungsanleitung (intern am Anfang, 1. S88 Bus 1000+ etc. etc)

Gruß, Eckhart

PS: Du solltest, für die Kommunikation mit der CS2/3 nicht UDP, sondern TCP benutzen!

[DiegoGarcia]

Ich empfehle das hier mal zu lesen:

RE: Märklin 60883 - LinkS88; erster Testbericht

Ciao
Diego

[vikr]

Hallo Joachim,

Zitat von joachimkr im Beitrag #41

---

Mein Raspberry sitzt per LAN mit auf dem Bus. Er verlässt sich auf die Brückenfunktion der CS2.

---

die Frage ist, was genau muss Dein Raspberry machen, um von der CS2 klaglos als Gerät akzeptiert zu werden, so dass die Daten - wie bei den Hersteller eigenen Geräten - verarbeitet werden.

Zitat von joachimkr im Beitrag #41

---

Die CS2 Doku innerhalb eines Web-Interface?! Das ist Spitze, da werde ich schauen! Danke für den Tipp!

---

Ja, die etwas versteckte Seite der CS2, die Märklin leider bei der CS3 ersatzlos gestrichen hat...

MfG

vik

[Eckhart]

Zitat von vikr im Beitrag #44

---

die Frage ist, was genau muss Dein Raspberry machen, um von der CS2 klaglos als Gerät akzeptiert zu werden, so dass die Daten - wie bei den Hersteller eigenen Geräten - verarbeitet werden.

---

Für einen "proof of concept" kann man sich auch erstmal auf ein ohnehin vorhandenes Rückmelde-Gerät draufbeamen. Man gibt, bei der Konfiguration dieses Gerätes, einfach mehr S88 Decoder an, als es hardwaremäßig im jeweiligen S88 Strang überhaupt gibt und "fälscht" mit seinem eigenen Gerät die Rückmelde-Event Nachrichten in diesen Bereich hinein. Final sollte man dann trotzdem irgendwann alles voll implementieren!

Gruß, Eckhart

[vikr]

Hallo Eckhart,

Zitat von Eckhart im Beitrag #45

---

Für einen "proof of concept" kann man sich auch erstmal auf ein ohnehin vorhandenes Rückmelde-Gerät draufbeamen. Man gibt, bei der Konfiguration dieses Gerätes, einfach mehr S88 Decoder an, als es hardwaremäßig im jeweiligen S88 Strang überhaupt gibt und "fälscht" mit seinem eigenen Gerät die Rückmelde-Event

---

ich glaube eher nicht, dass es Joachim darum geht, eine normale S88-Belegtmeldung zu simulieren. Es geht um den förmlichen erfolgreichen Anmelde-Dialog eines CAN-Gerätes mit der CS2.

MfG

vik

[joachimkr]

Hallo Ihr zwei,

Ich bin mit dem S88 Link angefangen weil
a) er über CAN, also theoretisch über die Bridge UDP/CAN der CS meldet
b) er nicht abgepollt wird, sondern aktiv meldet

Mein Raspberry meldet Ereignisse, die ich über RFID Reader erzeuge und an den Raspberry per Bluetooth LE weitergebe. Der S88 Link meldet Änderungen, nicht Status. Die RFID Ereignisse haben die gleiche Qualität.
Das passt also, mich zu verhalten, wie ein S88 Link.

Wenn nicht anders möglich, starte ich also wie solch ein Gerät. Da die Konfigurationsdaten Text zu sein scheinen, die nur der S88 Link versteht und die CS2 einfach puffert / bewahrt, dürfte da Spielraum sein.
Irgendwo gab es eine Tabelle, wie die 64 bit UID zusammengesetzt sind. Da waren Artikel von Fremdherstellern drin, bzw. beschrieben, wie die UID codiert ist. Völlig zufällig ist die UID nicht, sondern in Felder gegliedert.
Was ich also brauche, ist
a) eine UID die akzepziert wird
b) ich muss ein Besetztmelder werden, wie der S88 Link, so dass ich eine 'Soft'-ID zugeordnet bekomme und Kontaktnummern nutzen kann.
Da die CS aus der UID ihr Verhalten, ihre Interpretation ableitet, was da auf CAN auf broadcast antwortet, muss ich das richtig tun. Ich glaube, dass Teile des UID eine laufende Nummer sind und die wird in der CS Konfiguration angezeigt.

Ihr habt mir schon echt im Verständnis weitergeholfen!
Auch der verlinkte Artikel hilft!

Für mich ist noch unbeantwortet ist die Frage, ob der CAN Monitor auch über LAN lauschen kann. Wenn ja, wie bringe ich ihn dazu?

Vielen Dank!
Joachim

[bertr2d2]

Hallo Joachim,

Zitat von joachimkr im Beitrag #41

---

Mein Raspberry sitzt per LAN mit auf dem Bus. Er verlässt sich auf die Brückenfunktion der CS2.
Kann der CAN Monitor das ebenfalls? Oder muss ich eine CC Schnitte dranbauen? Der -i Parameter deutet darauf hin. Was gebe ich an, wenn Netzwerkverkehr abgehorcht werden soll, falls das geht?

---

die CC-Schnitte ist kein vollwertiges CAN-Interface und ist auch nicht SocketCAN kompatibel und somit mit dem can-monitor nicht nutzbar. Zudem überteuert und langsam. Es gibt günstigere und bessere CAN-Interfaces.
Der i-Parameter gibt das CAN-Interface an.
Wenn Du wirklich analysieren willst, wie etwas bei Märklin funktioniert, dann kommst Du um ein (vollwertiges) CAN Interface nicht herum. Ich bin mir nicht sicher, ob wirklich alle CAN-Frames auf dem Netzwerk gespiegelt werden. Wobei beim LinkS88 alle Pakete auch auf dem LAN (UDP/TCP) gespiegelt werden, wenn ich mich recht erinnere.

Zitat

---

Für mich ist noch unbeantwortet ist die Frage, ob der CAN Monitor auch über LAN lauschen kann. Wenn ja, wie bringe ich ihn dazu?

---

Wie gesagt, der can-monitor kann PCAPs lesen (tcpdump und wireshark Mitschnitte). Live Capture wollte ich mal implementieren, ist aber auf der Todo-Liste nach unten gerutscht.

Zitat von DiegoGarcia im Beitrag #43

---

Ich empfehle das hier mal zu lesen:
RE: Märklin 60883 - LinkS88; erster Testbericht

---

In Diegos Artikel steht IMHO auch schon alles Wesentliche zum LinkS88 drin.

Ich habe nicht so richtig verstanden, was Du eigentlich mit der Analyse des LinkS88 willst. S88 Meldungen werden auch ohne "Anmeldung" verarbeitet. Den Code hatte ich Dir auch schon geschickt, wie man S88 Frames generiert.

Gruß

Gerd

[joachimkr]

Hallo Gerd,

Zitat von bertr2d2 im Beitrag #48

---

Hallo Joachim,
...Ich habe nicht so richtig verstanden, was Du eigentlich mit der Analyse des LinkS88 willst. S88 Meldungen werden auch ohne "Anmeldung" verarbeitet. ...
Gruß
Gerd

---

In meiner Einfalt nahm ich an, dass ich nur dann eine Verarbeitung im Gleisplan der CS und ihrer Steuerungsketten erwarten kann, wenn die CS den Melder, seinen Bus und seine Kontaktnummer kennt. Spätestestens bei einem zweiten Raspberry oder hohen Kontaktzahlen würde ich diese Notwendigkeit sehen.

Habe ich etwas noch nicht verstanden?

Vielen Dank,
Joachim

[bertr2d2]

Hallo Joachim,

Zitat von joachimkr im Beitrag #49

---

In meiner Einfalt nahm ich an, dass ich nur dann eine Verarbeitung im Gleisplan der CS und ihrer Steuerungsketten erwarten kann, wenn die CS den Melder, seinen Bus und seine Kontaktnummer kennt. Spätestestens bei einem zweiten Raspberry oder hohen Kontaktzahlen würde ich diese Notwendigkeit sehen.

---

wie die Information der Kontaktauslösung gewonnen wird, ist doch letzendlich unerheblich. Ein Rückmelder kann anbieten, das er über die CS eingestellt werden kann, wie das beim LinkS88 auch der Fall ist (z.B. Buslänge, S88 Timing und Kontaktkennungsoffset). Das ist aber nicht zwingend notwendig.
Die Kontaktkennung umfasst 16 Bit -> 65536. Reicht das nicht aus ?

Gruß

Gerd

[Rainer Müller]

Hallo Joachim,

Zitat von joachimkr im Beitrag #47

---

...

Für mich ist noch unbeantwortet ist die Frage, ob der CAN Monitor auch über LAN lauschen kann. Wenn ja, wie bringe ich ihn dazu?

Vielen Dank!
Joachim

---

eventuell (ich habs nicht getestet) geht das indirekt. Für deine Linux-Distribution gibt es sicher einen Virtual-CAN-Treiber, so eine Art Loop-Device für CAN. Du startest diesen Treiber und lässt auf dem Rechner sowohl can2udp aus Gerds Sammlung als auch den CAN-Monitor laufen, beide mit dem Parameter "-i vcan0". Der can2udp schickt dann die UDP-Meldungen an den vcan0, wo sie der CAN-Monitor abholt und live anzeigt.

can2udp und can-monitor haben keinen direkten HW-Bezug und lasen sich auch auf einem "richtigen" Linux-Rechner compilieren und ausführen, sofern die notwendigen Headerdateien da sind und du die UDP-Pakete dorthin leitest.

Gruß
Rainer