Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt

[ragnar]

@UlrichC:
Ok, das mit der GUI klingt ja super so. Klingt zwar auch
nach viel Arbeit aber wenn du dich anbietest da ein
Grundgerüst zu schreiben

Eins möchte ich aber noch klarstellen:
Das System wie ich es hier geplant habe (nennen wir es mal
uCom) und smirs sind zwei verschiedene Paar Stiefel. Beide
haben zwar ähnliche Ziele (Kommunikation zwischen Roboter-
modulen) aber unterschiedliche Voraussetzungen, vor allem
in der Hardware. Smirs erfordert relativ große Rechner mit
IP-Anbindung. uCom hingegen soll bis hinunter zum kleinsten
uC skalieren. Der Nachteil von uCom ist natürlich, das das
System Beschränkungen hat, dafür kann man eben auch Roboter
die nur auf uCs aufbauen noch anschliessen (und das sollten
die meisten hier im RN sein).

Noch was: Beide Systeme sind dafür ausgelegt, mehrere Roboter-
komponenten und u.U. auch mehrere Roboter zu verbinden. Der
Plan ist, die GUI dann als einen Teil in diese Infrastruktur
einzuklinken. Es ist also nicht der Plan, hinter dem Application
Server bzw. der GUI noch weitere Applikationen/Roboter
anzuschliessen. Wenn man es gratis dazubekommt soll es mir
natürlich recht sein, aber es sicher kein Designziel.

Und jetzt noch ein Wort zu SOAP. Prinzipiell finde ich die
Idee mit SOAP/XML schon ziemlich reizvoll, insbesondere weil
man typisierte und selbstbeschreibende Daten/Funktionen verwenden
kann. Allerdings ist SOAP auch ein Protokoll, das nicht unbedingt
wenig Overhead erzeugt (in der Übertragung und in der Verarbeitung).
Auf einem PC mag das tragbar sein, auf einem uC mit zweikritischen
Aufgaben aber nicht. Ich hatte bisher immer ein Datenformat mit
einem Byte 'Command' im Auge, der dann implizit die Struktur der
restlichen Daten bestimmt. Wobei es natürlich auch möglich wäre,
das es ein Command 'SOAP' gibt, das nun mal nur die dickeren bzw.
die nicht zeitkritischen uCs implementieren.

ciao,
Georg

[NumberFive]

Hallo Leute,

es muß Kongretter werden sonst steige ich aus.
Ich habe schon mal wochen lange diskutiert nd dann wochen Programmiert und jetzt habe ich viel gelernt und das wars dann das wäre dann das dritte oder vier mal hier im forum.

Ich versuche das jetzt mal ein bisschen zu trennen UlrichC hätte gerne einen der für Ihn alles macht. Was sicher auch für die meinsten VB programmieren hier unter uns zu trifft. UlrichC zwar aus anderen gründe aber das ist ja mal egal.

Wir sind uns einig das echte textteile für RS232 und für AVR einfach zu heftig sind oder in der PC welt kein problem und schön weil sie lesen kann.

Drum bin ich der Meinung das wir das trennen müssen so weh wie das auch tut.

PicNick hat folgen auf bau beschrieben:

HEADER / SOURCE-ID / DESTINATION-ID / MsgNR / Action /DataLen / Data (optional).......

Den finde ich gar nicht mal schlecht.
Wir müssen nur ein Teil tauschen die MsgNR denn nummer eindeutig durch das sytem zu bekommen wird nix.
Ich würde daraus ein resposnummer machen mit der größe ein WORD das sollte hin passen.

Meine Defintion von der Message:

HEADER = 3 byte => immer RNM => RoboterNetzMessage
SOURCE = 2 Byte => WORD 0000 und FFFF dürfen nicht verwendet werden.
DESTINATION = 2 Byte => WORD 0000 und FFFF dürfen nicht verwendet werden.
resposnummer = 2 Byte => WORD
Action = 2 BYte => WORD => 65535 Aktionen
DataLen = 2 Byte => WORD wieviel Bytes kommen noch bis ende
Data = 0 Byte bis 65535

Aktionen im Bereich von 0 bis 4000 sind fest definiert und drüber darf jeder machen was er will
ich denke 4000 Sollte reiche die zahl ist aber nur aus gedacht.

Wird könnten so eine art DHCP machen:

wenn was online geht dann muß es grundsätzlich mal so eine Nachricht schicken:
RNM HEADER
<00><00> SOURCE
<FF><FF> DESTINATION
<00><00> resposnummer
<00><00> Action
<00><00> DataLen

Das ist jetzt die Broadcast anfrage nach einer eingener ID.

Kommt inerhalb von 5 sec keine Antwort war man wohl der Erste und darf sich was aussuchen.

Bekommt man die Antwort:
RNM<ID des Senden modules><00<00><00><00><00><01><00><01><Neue ID>
Gibt es einen der die Id's vergibt.

Bekommt man:
RNM<ID des Senden modules><00<00><00><00><00><02><00><00>
kann man sich zwar eine aus suchen aber diese ID's sind schon in verwendung.

Das baucht man natürlich nur wenn man unbedingt dynamiche adressen vergabe braucht.
Im internet muß auch einer die Ip's in den DNS reinkopfen.

Wie finden ich meinen Weg:
RNM<ID des Senden modules><FF><FF><00><01><00><03><00><00>
Wird jetz von dem modul gesendet. Trift es jetzt auf ein Teil welche weiß das es Procy spiel muß
wird einfach RNM<ID des Senden modules><FF><FF><00><01><00><03><00><01><ID des Proxy moduls>
daus und wenn ein zweite kommt kommt noch ein word dran.

Was ist ein Proxymodul:
ein AVR der zu Beispiel eine RS232 hat und auf der anderen seite ein IC2 Bus muß jetz sein ID anhängen.
und per RS232 weiter schicken so weiß der PC die ID'S die Hinter dem AVR am RS232 Port hängen.

Wenn jetzt ein PC modul an der AVR Hinter dem Proxy AVR was schicken will macht er einfach:
RNM<ID des Senden modules><id Procy><resposnummer><00><04><länge nachricht><nachricht>
wo bei die nachricht wieder ganz normal auf gebaut ist mit ausnahme des RNM vorne dran.

Bei PC => IC2 verbindung muß halt die ID und die Adresse des I²C Gleich sein.

So jetzt bin ich mal gespannt.
In den 4000 Actions könnte man dann auch nocht die smir's Telegramme verstecken.
gibt halt ein großes Dokument aber mit ein bisschen sorgfallt sollte es klappen.

Auf dem PC könnte man dann in der smirs welt nocht die ID's durch namen ersetzt dann wird es lesbarer.

so jetzt habe ich mir die halbe nach um die Ohren gehauen nur weil ich diesen text nicht lassen
konnte obwohl ich eineglich mal mein Robi zum laufen bringen sollte.

Gruß

[UlrichC]

So nochmal (ich sollte eigentlich was anders tun),
@marvin42x
Sorry...Die Visonen gehen bei mir immer so schnell aus.
Bei Roboterschwärmen denke ich eigentlich gleich an Online-Games *itsReal*

@ragnar
Ja ich werde mal einen Prototypen der GUI schreiben.
Das umliegende System der Webapplikation aber nicht vom scretch programmieren.

@NumberFive
Ich möchte nicht alles machen lassen, lediglich eine Standard Programmierschnittstelle.
Denn eine Protokollschnittstelle ist sehr erklärungsbedürftig somal der Standard-Roboter in weiter ferne liegt.
Mir ist klar daß ich die auch selber schreiben muß. Und ich habe schon x mal hier geschrieben das diese dann auch auf Smirs aufsetzen kann.
Aber solange keine Einigkeit gefunden ist ... und der SMIRS-Entwickler sich noch über erweiteungen am Protokoll verschweigt... dreh ich Daumen und schreibe WWW-GUI
... ob dann die Oberfläch nur mit eigem Zeug funzt oder auf einer Schnittstelle sitzt ... ist dann ein portierungsaufwand von wenigen Stunden für mich.
Und ich werde einen Teufel tun um hier erstmal fröhlich Prototypen (ferner www-GUI) zu schreiben um hinterher festzustellen das die SMIRS verwendet werden soll.

Denn die Teile die ich dann bereitwillig programmieren würde...
AppServer
Objekt zur Ableitung (schnittstellen)
Treiber für den ersten Roboter (Demo/Vorlage)
... schreiben sich nicht von selbst.
(Steht da alles schwarz auf Blau)

...jetzt muß ich aber wieder anderes tun.

Netter Gruß, SO LONG AND THX FOR ALL THE FISH,
Chris

EDIT:
Boa bin ich durchnächtigt... ich raf den Text nicht mehr.
Das beste ist wenn ich vorerst nur mit dem Modulen WWW-GUI und dem eigenen Robotermodul (auf tcp/ip basis) beginne..in zwei-drei Wochen muß mir dann einer sagen auf welchen Standard ich aufsetzen kann. (um mein gehack zu verschabeln) ... hierzu brauche ich erstmal keinen anderen Code (selbst ist die Frau)
Den Appserver habe ich schon bei einem weiteren bekannten programmierer angefragt... wenn muß dann wird.

@NumberFive
Ich schreib Dir eine Mail wenn ich wieder fit bin

[UlrichC]

Hallo nochmal (ich bin eigentlich gar nich da *pssst*),
ich hab nochmal in der Mittagspause den Kopf rauchen lassen.

Also meine Intension ist wirklich so ne Art VB-ActiveX Com+ für Module (Nur ohne Registrie) ... darum diese mini-plattform AppServer für Plattformunabhängige komunikation .. die ähnlich wie AktiveX bedient werden kann. ...über Aufruf der registrierten Funktionen... ohne Protokoll...sondern mit einer Programmierschnittstelle.
Dies muß aber auch nicht unbedingt ein Standard werden. Lediglich ein Feature/Bereicherung des Standarts. Denn ich könnte auch dieses Ding einem evtl. Standard anpassen. Intern könnte ich aufgrund der Trennung von Protokoll und Programmierung verfahren wie ich wollte.

Denkbare Architekturen von AppServer aus.
AppServer<->AppServer
..oder
AppServer<->LoginServer (SMIRS)
..oder
AppServer<->RN-VerbindungsLayerHandler

... dies kann dann später wenn der Standard funzt programmiert werden.

Auf den Teil der Architektur bin ich noch nicht eingegandgen daher ist dies was neues aber eine weitere Abgrenzung ... so könnte ich ja fröhlich beginnen.


Gruß,
Chris

[ragnar]

@NumberFive
Zur Umsetzung von Binärdaten auf Menschenlesbare Daten:
Ja, menschenlesbare Daten wären schön, sind aber auf dem uC nicht
zu machen. Wenn ich dich richtig verstanden habe, willst du die
Binärdaten an irgendeiner Stelle _im_ Kommunikationssystem in
Menschenlesbare Daten umsetzen.

Für einen Teil der Daten (z.B. Adressen) ist das eine gute Idee.
Allerdings würde ich die Adressen erst direkt vor der Darstellung
(z.B. im Debuggingtool) umsetzen.

Bei den verbleibenden Daten ist dies noch schwieriger. Diese hängen
nämlich z.B. vom Kommando ab. Um die Daten umzusetzen muß der
Umsetzer also wissen wie er die Daten zu verstehen hat. Das ist
fehlerträchtig, denn es kann jederzeit neue Kommandos oder geänderte
Datenstrukturen geben. Um die Daten möglichst lokal zu halten, würde
ich auch hier die Daten erst direkt vor der Ausgabe umsetzen. Das
Schlimmste was dann passieren kann ist das die ausgegenen Daten nicht
gültig sind.

Wird könnten so eine art DHCP machen:
[...]

Was du beschreibst hat leider ein Problem:
Der "DHCP" Response kann nicht so ohne weiteres zurückgeschickt
werden denn der Anfragende hat ja noch keine Adresse.

Prinzipiell natürlich trotzdem möglich, es liegt dann aber in
der Routingschicht und ist eine spezielle Nachricht außerhalb
des Msg-Modells von dir (eine Schicht drunter)

Ein weiteres Problem dabei: Wie können die Module dann
untereinander kommunizieren? Woher erfahren sie die
(dynamisch vergebene) Adresse ihres Kommunikationspartners?
"DHCP" erfordert also auch eine Art "DNS" (bzw. eine Registry),
mit der man die Adresse seines Kommunikationspartners anhand
bestimmter Merkmale (Name, angeboteten Dienste, ...) heraus-
finden kann.

Zu deinen Ideen zum Routing:
Das ganz große Problem das ich bei dir sehe ist, daß die
Knoten hinter Proxys ihre eigene Adresse nicht kennen (denn
die wird ja vom Proxy 'mitbestimmt'). Außerdem sind mir die
unterschiedlich langen Adressen noch etwas suspekt und mir ist
nicht klar, wie Nachrichten zwischen verschiedenen Modulen
geroutet werden sollen. Außerdem muß bei deinem Ansatz IMHO
immer eine Oberste Ebene als Bezugspunkt existieren.

ciao,
Georg

[PicNick]

Hallo, ihr da vom Thread der Doktoranden und Nachtarbeiter !
Ich leb' schon auch noch.
Immer wenn's kompliziert wird, geh' ich gern den Weg der "Ausserstreitstellung", d.h. ich schau mir einmal genau an, was nicht strittig ist und trotzdem unerlässlich. Das versuch ich mal zu lösen, auch um zu sehen, wo's hapert. Da nehm ich auch ein paar Leerkilometer in Kauf.
Wir haben nämlich dauernd die Stituation, daß vor diesem und jenem eigentlich vorher noch was anderes zu klären wäre, und das setzt sich fort und man kommt zu keinem Ende oder Anfang oder, schlimmer, was weiß nicht mehr was Ende oder Anfang ist.

Egal: da bei mir PCs und Midranges durch die berufliche Tätigkeit immer ein leichtes Grausen auslösen, schau ich mir einmal genauer die Umsetzungsmöglichkeiten auf AVRs an. Ein paar Versuche hab' ich ja schon gemacht, Marvin42 weiß das.
Ich halte es nämlich auch für wichtig, eine ZUMUTBARE Library dafür zu entwerfen. Wenn der µC nämlich nix anderes mehr kann als netzwerken, setzt sich das Ganze niemals durch.

Mal sehen

[UlrichC]

Hallo,
ich kann die Finger nicht raushalten.
Aber spezifizieren mag ich nun nicht...

Ich wollte nur mal einen Ansatz bzw. ein Punkt wo die Meinungen vielleicht noch Auseinanderlaufen untermalen
Und zwar ...

Ich halte es nämlich auch für wichtig, eine ZUMUTBARE Library dafür zu entwerfen. Wenn der µC nämlich nix anderes mehr kann als netzwerken, setzt sich das Ganze niemals durch.

Ja das sollte auf jeden Fall auch das Ziel sein und zwar an beiden Enden des Systems.

Und hierbei möchte ich noch zus. Intensionen loswerden.
Eine Kapselung des Protokolls in eine verständliche bis einfache Schnittstelle für den Verwender.
Jedenfalls habe ich die Fahne auf der PC-Seite des Systems hierfür auch schon gehalten.
..und das nicht aus Einfachheits- bis Faulheits- gründen...sondern
Eine Programmierschnittstelle (+Spezifikation) verbaut in einer Bibliothek (Lib) ist sozusagen die Lebensversicherung des Systems.
Das Protokoll + API selbst kann sich dann *ändern wenn es notwendig wird.
Der Verwender des Systems sollte einfach durch kompilieren seines Codes mit der "dann neuen Lib" Standardkonform bleiben ohne eigenen Code ändern zu müssen.

Jedenfalls ist man das als Programmierer/Anwender so gewohnt.
Falls sich wirklich Anwender für einen eventuellen *Standard finden sollten dann sollten diese über alle Versionen erhalten bleiben.
Ich würde als Normal-Modul-Programmierer (nicht API Schreiber) wahre Freudensprünge im Dreieck machen,
wenn ich alles wegen eines Denkfehlers oder einer Erweiterung die eine Änderung des Protokolls zu Folge hatten,
die Kommunikation umtexten müsste.

Diese Schnittstellenfunktionen werden so oder so geschrieben ... nur wenn die nicht in der Lib zur API liegen muß diese jeder für sich anpassen.
In einem Fall wären es [Support "+Punkte"] im anderen [Standard "-Punkte"].

*Änderungen ... gibt’s oft:
... neue Features neue Bugs *isKlar* Workarounds
... andre Encodings (Vielleicht wird mein Unicode nun doch anders Interpretiert)
... mehr Funktionalität (Vielleicht wird alles aufgebohrt ... und man muss explizit den verwendeten Standard im Protokoll mitschicken... um gewohnt verfahren zu können)
... anderes Handling des Protokolls (Vielleicht müssen Commands vorgeschoben oder bestätigt werden)
... schnellere Reglungen (vielleicht ändert sich die Kommunikation grundlegend um Connects/Syncs zu sparen)
... obsolet Commands (manche zuerst als sinnvoll erscheinenden Funktionen des Protokolls werden ersetz / oder erweisen sich als unsicher)
... mehr Sicherheit (vielleicht läuft in naher Zukunft alles Verschlüsselt durch die Leitung)
... weitere Interfaces (feileicht müssen die Adressräume geändert werden weil die vorgesehenen 2 Byte doch nicht reichen)
etc.

*Standard wird nur verwendet wenn es Vorteile bringt.. Vorteile sind verschieden geartet
... Kompatible Zusatzsoftware
... Zeit/Kostenersparnis
... KnowHow-Gewinn
... Funktionsgewinn
etc.

Ist schon wieder ein Roman geworden... *sorry*

Netter Gruß,
Chris

[marvin42x]

Aus meiner Berufspraxis, die nichts mit Programmieren zu tun hat, weis ich, dass ein Pendeln zwischen Überlegungen und Prototypen am fruchtbarsten für Entwicklungen war.

Ich würde daher vorschlagen diese Möglichkeit in Betracht zu ziehen.

Die Liste der Vorteile ist lang. Weder nur Überlegung noch nur Prototyping vermögen das zu leisten.

Wir müssen auch bedenken, dass die serielle Kommunikation eines Textes im Forum Schwierigkeiten hat mit der Darstellung mehrerer mehrdimensionaler Topologieentwürfe wie sie hier erörtert werden. UlrichC hat da mit seiner Grafik schon mal zur geeigneteren Waffe gegriffen. Prototypen erzwingt Festlegung und bildet gleichzeitig die Idee beispielhaft ab ohne Änderungen im Weg zu stehen. Er ist gleichzeitig von allen einsehbarer Stand der Dinge.
Frage:
Wäre es sinnvoll eine minimale Topologie aufzubauen die z.B. zwei Sachen kann. Get var und Put var um am Objekt weiter zu Entwickeln.
Das würde sich dann in etwa so anhören:
Auf der einen Seite haben wir bereits mindestens ein lauffähiges Betriebssystem für einen Mega32 wenn man das modifiziert, das es put und get für eine variable kann. Die lib dazu auch minimal auf diese zwei Funktionen beschränkt.
Wie die Lib das macht wäre erstmal egal
Wie das Prokoll aussieht wäre erstmal egal.
Der Apserver sollte zu Studienzwecken nur…….usw.

Ein Mega32 der, über einen Apserver, auf einer GUI in einem Textfeld seine Batterispannung ausgibt.
Auf dieser Basis ließe sich vortrefflich:
Erweitern
Verwerfen
Neu entwerfen
Erfahrungen einbauen
Probleme erkennen
Aufgabenbereiche abgrenzen
Schnittstellen erschaffen……..na ja usw.
Netter Gruß

[Vogon]

... Ich hatte bisher immer ein Datenformat mit einem Byte 'Command' im Auge, der dann implizit die Struktur der restlichen Daten bestimmt. Wobei es natürlich auch möglich wäre, das es ein Command 'SOAP' gibt, das nun mal nur die dickeren bzw. die nicht zeitkritischen uCs implementieren ...

... das lässt mich an P-Code denken.
Ob ich jetzt unter einer virtuellen Maschine einen Prozessor oder einen Roboter verstehe. Ist doch auch nichts anderes.

[NumberFive]

In der Hoffung das Frank weiterhin mit liest.

Könnten wir im Download bereich eine Ordner haben ?
Ich würde mein SMIRS zeug gerne mal hoch laden aber mein HP
ist ein HP bei T-online privat page und da reicht werde Traffing noch Platz
auf die Dauer.

Zu rück zum Thema ich würde auch gerne ein alpha im plemetierung machen da wird es einfach leichter. Ich muß so was sehen / Programmieren dann wir es für mich einfach leichter und vor allem kann man mal messungen machen wie lange was wirklich dauert.

Desweiteren würde ich den Thread gerne Trennen aber wenn wann dann mehr lesen muß Application layer und Protokoll layer oder wir gewönnen uns an es Obentrüber zu schreiben um was es gerade geht. Bitte diesen Post nicht falsch verstehen es ist nicht mein Thread und es sind nur vorschläge.

Zur alpha im Plementierung:
Von mir kommt immer nur windows software (win2000) und wenn AVR dann c software.

Jeder der was für das Projekt programmier muß sich im klaren sein das sich das protokoll morgen komplett ändert bist die Defintion mal steht.

Zu Protolllayer:

Ich habe noch mal drüber nach gedacht und ein paar änderungs vorschläge.
ID's / Adresse sind vor erst mal per hand zu vergeben. das Dynamisch ver geben von ID's ist ein Option die wir erst später realiesieren. Also im source vorsehen aber zur Zeit würde uns das nur auf halten und wir haben genung andere Probs zu lösen.

Ich würde gerne das Protokoll teilen AVR Welt und PC Welt um es den PC Programierern einfachen zu machen und das Protoll notfalls auch lesen zu können. Zweiter vorteil man würde sich mit den 0 Bytes als C++ Programierer nicht so um bringen (Stringklassen). Aber auch Delphi oder VB hat glaube ich so ihr probs mit 0 Bytes im string. Bei java weiß ich es nicht wirklich.

Wie soll es laufen:

Bild hier  

Angehängtes Bild betrachten und jetzt geht es los.

RNM Low sollte so was Byte Oritiertes sein damit der AVR sich nicht einen Abbricht und das RNM Hight sollte doch ziemlich Text oritiert sein damit man es schnell lernen kann und wir viele schöne Module bekommen.

In meinen Bild sieht mal schon das wir dann beide Welten haben und man beides nutzen kann. die MC könnte erst mal so weiter leben und und die Eine änderung sollte sich realtiv schnell ein bauen lassen.

auf der LOW seite würde ich gerne das
RNM HEADER
<00><00> SOURCE
<FF><FF> DESTINATION
<00><00> resposnummer
<00><00> Action
<00><00> DataLen

Verwenden denn ich denke das geht schon in die richtige richtung.
Ich stelle mir die Frage warum wenn ich Über die RS232 an den AVR gehe den Dahinterliegen AVR von dem Motor Controller zum beispiel wirklich direckt er reichen muß. In meinen Augen eigendlich nicht. Wenn ich mehr als ein gerät direckt erreich will / muß baue ich den I²C bus dann habe ich da keine Probs die meinsten RN Borad können den Ja. Im PC I²C Adapter würde ich dann per Ini oder regestry ein Übersetzung tabelle von Name auf ID's Führen.

Wenn wir den Proxy weg lassen und dafür Feste befehle bauen wird das ganz nicht so komplex und wird erreichen schneller was verwendbares.

Um das was ich mein zu verdeutlichen:
RNM HEADER
<00><34> SOURCE
<00><99> DESTINATION
<00><54> resposnummer
<00><99> Action
<00><03> DataLen
<00><01> DataByte
<00><01> DataByte
<00><50> DataByte

Hier schickt das RS232 Modul (ID 34) and den AVR (ID 99) den Befehl 99 (Stellemotor leistung) des Motor's 1 in Richtung 1 (Vorwärts) auf 50 %.

Ob jetzt der PWM Generator auf dem AVR sitzt oder der AVR einem Andere AVR was mit teilt ist ja eineglich egal und das kann jeder mache wir er will.
Hat er eine RN Motorcontroller würde er das Selbe Telegramm ein fach über den I2C bus jagen und das Tut. Ok dafür muß man den Robi ein bisschen in logische Teile auf teilen aber ein standart ist immer auch ein Kompromiss.

Wie kommt jetzt der Navigator an den AVR, Ich gehe davon aus das der Navigator ein PC Programm ist, ganz einfach über die Multicast Adresse.

er jagt ein Telegramm raus das so aussieht (ist nur ein beispiel bin für vorschläge offen) <byte><byte><RNM><ADRESSE AD='RS232'><RESPOS ID = '54'/><ACTION ID = '99'/><DATALEN Value = '3'/><DATA01 Value='1'><DATA02 Value='1'><DATA03 Value='50'></ADRESSE></RNM>

Die Zwei Byt am anfang um bei Wlan sicher zu stellen das das Telegramm voll ständig war. nach dem an es nun hat und die ersten zwei byte's abschneidet sollte man es ein XML Parser zu fressen geben können wenn ich XML richtig verstanden habe. So hat man beides ein Telegramm was einem beim Coden auf dem AVR nich um bringt wo man auch ein klassen / lib für machen kann und ein PC Telegramm was man relativ gut lesen kann aber von prinzip sind sie gleich. Für die Fraktion die sich nicht mit dem Protokoll layer rum ändern wollen wurde ich ein dll machen die ein Com Objekt ist die der man nur die Multicast adresse gibt und die Einge adresse und dann kommen Event's wenn für einen was neues da ist dort Kann man dann mit Metoden die Aktion und die daten abfragen. So das einem das Protokoll egal sein kann. UlrichC mach bestimmt auch ein .so file für die Linux Jungs unter uns.

Was haltet Ihr von meiner Idee ? Ok ich habe mich sehr weit vor gewagt aber so kann ich mir das einfach besser Vorstellen. Achso auch ein simirs Client kommt natürlich an das Mutlicast es gibt ja den befehl Transfer damit kommt das Modul dann an die Multicast geschichte. Und die MC hat eine Adresse auf der Multicast seite.

Wenn wir uns auf den Nachrichtenauf bau einigen können könnte man anfangen die Action zu definieren. Das währe dann Applications layer 1.

Gruß
PS: ich hoffe es ist einiger massen zu verstehen

Schade ich darf keine Bilder mehr hoch laden sagt das forum zu mir
Deshalb habe ich das mal als link ein gefügtmal sehen wann die Telekom mir aufs dacht steigt.