Hallo ST-Oldie, hallo alle anderen,

Ich spar mir mal ein Zitat zu ST-Oldies Meinungen.
Ausser das sie mich fachlich ärgern. Das reicht dann jetzt auch an Unsachlichkeit.

Zurück zur neuen Sachlichkeit:

* Mono ist kein Clone, sondern eine alternative Implementierung der .NET-Spezifikation, die recht gut funktioniert. Technisch gesehen ist eine gewisse Windows-Nähe höchstens bei GUI-Komponenten zu bemerken, vieles anders lässt sich generisch verwenden. Manchmal müsste man drumherum programmieren, aber das geht und tut nicht weh. Das hat man überall.

* Die "Probleme" mit CdB-Software lagen nicht an Mono, sondern daran, wie die Software programmiert ist. Das ist ok, Thorsten hatte mir mal gesagt, er sei kein Programmierer, jedenfalls nicht für solche Sachen. Dafür ist die Software ziemlich gut - aber halt nicht für die Spezialitäten anderer Betriebssysteme angepasst. Das ist so und das ist ok, und ausserdem kann das auch nicht jeder, weil man dazu eine gewisse Erfahrung benötigt. Für mich war es der grundsätzliche Versuch, und ich weiß auch, wo ich hinlangen müsste.

* Deine Lösung mit PHP scheint dir gut zu helfen, aber deine Aversion gegen Javascript ist weitgehend unberechtigt. ActionSkript hat auch so seine Probleme, PHP auch ... Die Angriffsfläche ist immer so groß, wie das Feld, das ich biete. Und Javascript wird oft genug dazu genutzt, um in PHP-Programme (oder auch JSP/JSF/ASPX/...) einzubrechen. Zudem lege ich dir den Begriff "same origin policy" ans Herz. Löcher gibt es immer - aber weniger mit JS als mit dem anderen Kram.

* Letztendlich ist es Banane, mit was man einen Client programmiert - erstmal braucht man einen Server, der die Daten der Hardware weitergibt und einen Client, der sie verwendet. Den Client kann man programmieren, mit was man will, der Server bedient dann CAN. Vorausgesetzt, die Architektur geht in eine Client-Server-Richtung.

* Nein, ich halte diese Trennung Server-Client nicht für overengineered, sondern für folgerichtig - der Server läuft auf einer einzigen Plattform für mehrere Betriebssysteme und kann dadurch besser gewartet werden und die Clients kann sich jeder selbst bauen, wenn ihm der Standard-Client (Javascript|JavaFX|PHP) nicht gefällt.

* Aus Erfahrung würde ich CAN-Daten nicht durchleiten und in irgendeinem Client "dekodieren" lassen - das macht lieber der "Konfigurations-Server" und der bereitet das alles so auf, das ein Client die Daten hübsch und schön weiter verarbeiten und darstellen kann.

* Bevor die Frage kommt: sobald man ein Kommunikationsprotokoll definiert hat, das trägt, kann man sich einen Client auf der Basis der Technologie bauen, wie man will. Von mir aus im Textmodus, kann auch nett sein.

* Doku gibt es zwar nicht, ist aber auch nicht so tragisch - es würde halt eine Fleißarbeit werden, den CAN-Bus auszuwerten - ja und? Etwas Spass braucht der Mensch.

* Binaries: ich muß Dich enttäuschen, auch Java hat keine "Binaries" im Sinne eines direkt in Prozessorcode umgewandelten Programms - das "Binary" kann man ganz einfach in Java-Code zurück-umwandeln. Vielleicht mit anderen Variablennamen, aber das ist dem Bytecode-Compiler eh wurscht.

* Ich fände es jedenfalls schick, eine Software zu haben, die alle Module von CdB unter einem Dach "grundkonfiguriert" (auch wenn es schick aussieht und sicher viel Mühe bei der Erstellung gemacht hat: ich brauche keine Oszi-Simulation im Konfigurator) und evtl. sogar offen ist für weitere Module von "Privat-Herstellern"

Gr.,
Martin

Hallo Martin,

Quote

mra schrieb:Doku gibt es zwar nicht, ist aber auch nicht so tragisch - es würde halt eine Fleißarbeit werden, den CAN-Bus auszuwerten - ja und? Etwas Spass braucht der Mensch.

Also Reverse Engineering. Ja, wer spaß daran hat. Aber damit dürfte man wohl eher wenigre Leute ansprechen, die das machen als wenn es eine Doku gäbe.

Quote

mra schrieb: Ich spar mir mal ein Zitat zu ST-Oldies Meinungen. Ausser das sie mich fachlich ärgern. Das reicht dann jetzt auch an Unsachlichkeit. Zurück zur neuen Sachlichkeit:

Also mir damit jetzt zu zwischen den Zeilen zu unterstellen, ich wäre unsachlich oder würde bestimmte Dinge nicht wissen, bloß weil ich Formulierungen verwende, die dir nicht gefallen und bestimmte Dinge anders bewerte, ist jetzt kein feiner Zug.

Tschüß
Michael

Hallo Michael,

Quote

ST-Oldie schrieb: mra schrieb: Ich spar mir mal ein Zitat zu ST-Oldies Meinungen. Ausser das sie mich fachlich ärgern. Das reicht dann jetzt auch an Unsachlichkeit. Zurück zur neuen Sachlichkeit: Also mir damit jetzt zu zwischen den Zeilen zu unterstellen, ich wäre unsachlich oder würde bestimmte Dinge nicht wissen, bloß weil ich Formulierungen verwende, die dir nicht gefallen und bestimmte Dinge anders bewerte, ist jetzt kein feiner Zug. Tschüß Michael

Ich meinte mich selbst, da ich mich sichtlich über Deinen Artikel aufgeregt hatte.
Gut?

Gr.,
Martin

Hallo Michael,

Quote

ST-Oldie schrieb: mra schrieb:Doku gibt es zwar nicht, ist aber auch nicht so tragisch - es würde halt eine Fleißarbeit werden, den CAN-Bus auszuwerten - ja und? Etwas Spass braucht der Mensch. Also Reverse Engineering. Ja, wer spaß daran hat. Aber damit dürfte man wohl eher wenigre Leute ansprechen, die das machen als wenn es eine Doku gäbe.

Ein Stückweit schon, ja.
Aber nicht vollständig, denn die grundsätzlich benötigten Nachrichten sind in der Märklin-Doku zu finden, sowie bspw. auch beim MäCan-Projekt

Gr.,
Martin

Hallo Michael & Martin,

ich denke, Ihr habt beide Recht. Ein Gutteil lässt sich schnell durch Reverse-Engineering herausfinden aber es bleiben Fragen. Ich habe das schon vor einiger Zeit mal gemacht:
GleisReporter Deluxe Fragen
um die CAN-Frames zu analysieren.

Alles was ich heraus gefunden habe ist hier eingeflossen (insbesondere für den GleisReporterDeluxe):
CAN-Monitor

Code

void cdb_extension_grd(struct can_frame *frame); void cdb_extension_set_grd((struct can_frame *frame); void cdb_extension_wc(struct can_frame *frame);

Leider bleibt ein Teil ungeklärt. Vielleicht kommt ja doch irgendwann eine Doku ;-)

Gruß

Gerd

Hallo Martin,

Quote

mra schrieb: ST-Oldie schrieb: mra schrieb: Ich spar mir mal ein Zitat zu ST-Oldies Meinungen. Ausser das sie mich fachlich ärgern. Das reicht dann jetzt auch an Unsachlichkeit. Zurück zur neuen Sachlichkeit: Also mir damit jetzt zu zwischen den Zeilen zu unterstellen, ich wäre unsachlich oder würde bestimmte Dinge nicht wissen, bloß weil ich Formulierungen verwende, die dir nicht gefallen und bestimmte Dinge anders bewerte, ist jetzt kein feiner Zug. Ich meinte mich selbst, da ich mich sichtlich über Deinen Artikel aufgeregt hatte. Gut?

Ok, ich hatte die Unsachlichkeit in dem Zusammenhang auch auf mich bezogen.
Ja, alles ist gut! Kein Problem.

Tschüß
Michael

Hi,

Quote

bertc3p0 schrieb: Leider bleibt ein Teil ungeklärt. Vielleicht kommt ja doch irgendwann eine Doku ;-)

Würde es denn helfen, wenn man anbietet, mit an der Erstellung einer solchen Doku zu arbeiten? Das würde ja dann von der Arbeit eine Entlastung darstellen.

Tschüß
Michael

Hi,

also ich sehe hier mehrere Baustellen und fasse mal zusammen:

(1) Dokumentation
(2) Konfigurationsprogrammsuitearchitekturfestlegung :-)

Zu (1): das müssten wir klären, ich denke auch, dass das klärbar ist.

Zu (2): Ich habe herausgehört, das ein Programm schon plattformunabhängig sein sollte, dem stimme ich zu. Ich habe bereits mit einem Prototyp ("Proof of concept" ) in Java/JavaFX begonnen, weils mich interessiert hat. Könnte - muss aber nicht - eine Basis sein. Wenn ich in den nächsten Tagen dazu komme, kann ich den Prototypen auf Github stellen.

Was die Grundarchitektur betrifft:

* Sollte erweiterbar sein (also nicht: jedes Modul bekommt eine eigene Software, sondern nur noch ein "Plugin" oder eine Servicebeschreibung oder was-auch-immer-noch)

* Client-Server vs. Fat-Binary: Hat beides seinen Charme, wenn man das aber als Client-Server aufsetzt, kann ein Nutzer einen (GUI-)Client schreiben, den er will mit dem Framework das er kennt und will. Der Server übersetzt nur die CAN-Kommandos in abstrakte und generische Kommandos und packt das alles in z. B. JSON (sehr beliebt geworden), oder (wer sich das antun will) in SOAP. Für die Strecke zwischen Server und Client (GUI!) würde ich CAN und Bits und Bytes als Rohkost vermeiden. Kann man ja in der abstrakten Service-Message mitliefern, so als Gadget, muss man nicht. Das Protokollformat JSON-RPC gibt da einiges her.

So, noch alles gewürzt mit weiteren Gedanken ...

Euch schöne Feiertage und einen guten Rutsch (Wenn wir uns nicht mehr lesen)

Gr.,
Martin

Hi,

sollten wir dazu einen neuen Thread eröffnen?

Denn das Thema hat sich ja gewandelt.

Ich hatte eigentlich nur die Info veröffentlichen wollen, daß meine Software für einen CAN - Ethernet Proxy mit der CS2 Ethernet Schnittstelle jetzt auf der CAN Seite auch mit der CC-Schnitte zusammen arbeitet.

Jetzt sind wir bei einer Überlegung einer plattformunabhängigen Software für die Konfiguratrion der CdB Module.

Tschüß
Michael