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

[marvin42x]

@ PicNick:
Zwischenfrage:
Wiso eventuell geroutet?
Ich hatte es so verstanden das ab Server TCP/IP.
Was für mein Verständnis bedeutet das selbst auf dem unmittelbaren PC "genetzwerkt" wird?
Ziel-Klasse und Ident habe ich nicht verstanden. Sind damit Einheiten auf PCs gemeint oder die Units innerhalb eines Robi-Betriebssystem?

Im Moment haben wir, glaube ich zu verstehen, noch nicht richtig über die Pflichtenverteilung der PC-Komponenten(Server, PC-Module, Webserver, Applicationsserver) gesprochen. Ich sehe zurzeit einen Server auf der seriellen sitzen, der „dann irgendwie was weitergibt“
Weitergeben wäre für mein Verständnis TCP/IP
Daraus folgt, der Server muss dem Robi eine Eindeutige Adresse verschaffen. Er muss sogar den Units auf dem Robi (zB. Kompass oder so) eine eindeutige Adresse verschaffen.
Er selbst muss auch eine eindeutige Adresse haben. Also eine diesmal komplette Absenderadresse.
Dann muss noch jemand entscheiden wer das bekommen soll. Jetzt erstmal Broadcast.
Wenn ich mich in meiner Unerfahrenheit hier verrannt habe möge man mir das nachsehen.

Netter Gruß

[PicNick]

Nun, auch ein µC kann potentiell routen, wenn z.B. der adressierte Rechner nur über I2C oder einen anderen Bus zu erreichen ist. Oder denk an die RNBFRA mit dem CoProzessor.
Wie gesagt, da bewegen wir uns noch eine Ebene über dem Level-0, also der "vermittlungschicht". Egal, ob ein Frame von IP oder vom COM-Port kommt, es hat eine (applikations-) Ziel- und Absenderadresse.
Wenn die adressierte Applikation auf dem lokalen Rechner ist, dann macht diese weiter und tut den Teufel was. Wenn aber nicht, geht's über IP, I2C, RS232 oder Brieftauben weiter.

Klassen und Ident:
Klassen sind Geräte-Typen. Auf einem µC eben AD-Wandler, Kompaß, SF08, Stepper- oder DC Motoren.
Auf dem PC können das Slider, Progress-Bar, Radio-Buttons oder checkboxen oder was kompliziertes wie eine Radar-anzeige oder sonst ein graphisches Zeugs sein.
Die verhalten sich an sich gleich und werden von den gleichen Programmteilen behandelt, daher "Klasse"
Gibt es von einer Klasse mehrere Ausprägungen (µC:linker-rechter Stepper, PC: Graphische Anzeige 1-29) dann haben sie dieselbe Klasse, aber innerhalb dessen "Ident" 1-n)
Die PC-Klasse/Ident "Slider-4" wird ihren Wert an die µC-Klasse DC-Motor-1 schicken und "Slider-5" wird ihren Wert an die µC-Klasse DC-Motor-2
die µC Klasse/Ident ADC 1-8 werden auf einem PC Abnehmer finden z.B. Progress-bar 1-8.

Wie eben der Stellwert von so einem Slider seinen Motor findet, ist eben Aufgabe der Netzwerkes.
Das sind trivial-Beispiele, die aber z.B. bei einer Robby-Remote-Control absolut der Praxis entsprechen.

Komplexere Sachen, wie eine ODOMETRIE-Klasse, wirds dagen wohl nur einmal geben, dafür kriegt die aber daten von mehrern Sensoren und bedient auch mehrere Geräte.

Ob dazwischen die Daten über http dreimal auf ASCII und zurück konvertiert werden, ist dann eins drauf, ändert aber nix prinzipielles.

[ragnar]

@alle:
Bei der Implementierung meiner Schicht 1 ist mir noch ein Fehler im Protokoll aufgefallen.
Unser BCC kann den Wert der Kontrollzeichen annehmen. Damit gibt es bestimmte Nachrichten,
die nicht übertragen werden können. Ich schlage deshalb vor, dem BCC auf die Ausgangsdaten
anzuwenden und dann erst zu prefixed. Damit wird der BCC bei Bedarf auch geprefixed.


Zur den Adressen:
@PicNick: Deine Idee mit den Zielklassen finde ich zwar relativ interessant, ich glaube
da vermischen sich aber Schicht 2 und Schicht 4. Meiner Meinung nach sollte die
Schicht 2 nur zwischen beliebigen Adressen vermitteln, unabhängig davon welche Klasse bzw.
welchen Typ diese Knoten haben.

Die Klasse eines Knotens würde ich erst auf Schicht 4 einführen, daran hängt schon relativ
viel highlevel-Bedeutung. Ich hatte da auch eher an 'Dienste' gedacht. z.B. könnte ein
Knoten mit einer bestimmten Adresse den Dienst "Motorcontrol" anbieten, während ein anderer
die Dienste "Bumper", "Infrarotsensoren" und "US-Sensoren" anbietet. Ein Knoten kann also
mehrere Dienste anbieten und die Dienste haben erstmal nichts mit den Adressen zu tun.


@NumberFive: Die Idee mit den 2 Bytes für die Adresse finde ich gut, 8-bit Adressen sind
zu wenig, 24-bit Adressen sind zu lang (schwieriger zu routen, länger zu übertragen). Ich
hatte hier schonmal einen Vorschlag gemacht, den ich jetzt nochmal aufgreifen will:

2 Bytes Adressen, davon 1 Byte "Netz#", 1 Byte "Knoten#"

Für beide Bytes gilt: 0=Broadcast, entweder "0.x" innerhalb des Netzes "x"
oder "0.0" an alle Knoten insgesamt. 255=reserviert.


Wie ist das jetzt mit dem Routing ?
Ich habe mal ein Bild gemalt, wie ich mir das vorstelle. Alles, was innerhalb der RNcom
Wolke ist, hat eine RNcom Adresse und wird als RNcom geroutet. Innerhalb von RNcom gibt
es verschiedene Medien. Eines davon ist LAN. Dabei werden über vorher konfigurierte
IP-Verbindungen RN-Frames übertragen. Geroutet wird dabei eigentlich zweimal - einmal
auf RNcom Ebene (auf die IP-Verbindung), ein zweites Mal das IP-Paket innerhalb des
IP-Netzes. Eventuell wird am Empfänger dann nochmal auf RNcom Ebene geroutet.

Ganz konkret bedeutet das: ein RN-Com Knoten kann nicht direkt mit einer
bestimmten IP-Adresse kommunizieren. Ein Programm kann aber z.B. auf einem bestimmten
Port lauschen und dort eine RNcom Verbindung anbieten. Um nun eine GUI mit diesem Rechner
zu verbinden konfiguriert der User seine GUI automatisch die IP-Verbindung aufzubauen.
Der RNcom Router stellt dann fest, welche RNcom Netze hinter der neuen Verbindung stehen
und routet dann automatisch.


Und zum Schluß noch was ganz anderes:
Lasst uns dem Kind doch noch einen Namen geben. Ich würde die Schichten 1-3 (den ganzen
Kommunikationskram) gerne unter einem Namen zusammenfassen (z.B. RNcom oder uCcom). Und
dann für die Schicht 4 einen Namen der mehr auf die Intelligenz bzw. die Softwaremodule
anspielt.


BTW: Ich würde erst gerne die Schichten 1-3 festzurren bevor wir über Schicht 4 spekulieren.

ciao,
Ragnar

[NumberFive]

Grund sätzlich finde ich das was ragnar geschrieben gut auch das bild gefällt mir. Nur warum auf Big Bots nur Linux laufen darf verstehe ich nicht auf mein wird windows laufen.

Reichen uns 253 Konten auf den Sub Systemen ? Auf einem PC (welches Betriebs system auch immer) Reichen sicher 253 Programme die auf das Netzzugreifen können aber am AVR ? kommt es sicher auf die Defintion an was man noch als Konten ansprechen kann. Den inhalt würde ich gerne auch noch etwas weiterhinten definieren. Wobei ich mich gerade fragen ob die defintion als Slider X oder so was wirklich die Richtige ist ich denke die Aufteilung nach was ist besser also Sharp mit entferungs angabe in cm Motorcontrol mit werten 0-255 für den Speed und ein byte für die Richtung.
Und so weiter. Ob die darstellung dann als Silder oder sonst was ist sollte der GUI überlassen bleiben.

Ich werde die dll und den exe server (SerialServer) noch so um bauen das es mit Multicast und windows tut muß leider noch ein zwischen schicht ein ziehen da windows nur eine programm erlaubt auf dem Multicaststream zu hören. Aber ich habe da schon eine Idee wie ich das löse. Kann mir jemand sagen ob das unter linux genauso ist ?

Leider bin ich durch eine Magendam grippe etwas geschächt zur zeit so das der Output nicht ganz so hoch wie ich das gerne hätte.

Ansonsten habe ich echt das gefühl es geht vorwärts und in die Richtige richtung. Hat durch zu fall jedmand das dokument gelesen von den ich den Link gepostet habe ?

Gehen ein Namen habe ich auch nix.

Werden nachher auch mal ein bild malen wie ich es Programmiert habe bzw. wie ich es bis jetzt relaisiert habe.

Soll ich in die exe so ein dauer sende Funktion einbauen die betimmte an zahl von telegramme immer im kreis sendet ?

Gruß

[PicNick]

Unser BCC kann den Wert der Kontrollzeichen annehmen. Damit gibt es bestimmte Nachrichten, die nicht übertragen werden können.

??? war da nicht was mit bytestuffing ? Wieso sollte bcc eine Ausnahme sein ?

[NumberFive]

So jetzt habe ich mal ein bild gemalt

Bild hier  

[marvin42x]

Einige Testfunktionalitäten im Server wäre sicher, besonders am Anfang, sehr nützlich.

253/253 Programme/Konten müssten aus meiner Sicht für den Großteil der Aufgaben ausreichen. Das unter dem Hintergrund das Dieses Protokoll nicht zwingend das einzige bleibt. Sprich: Zukunftsoption Protokollaushandelung.

Ich habe auch nichts gegen einen Namen für das Kind.
RN-com macht sich doch ganz gut.

Das Dokument habe ich quer gelesen. Für die Sache braucht man eine gute Software

ragnars Zeichnung trifft meine Vorstellung, soweit ich das im Moment sehen kann.


@NumberFive: Gute Besserung.

[PicNick]

@ragnar: Ich war wahrscheinlich mißverständlich. Natürlich hat die Vermittlung keine Einsicht in die Bedeutung der Adressangaben, d.h. die weiß natürlich nix von Klassen und so Zeugs.

[ragnar]

Unser BCC kann den Wert der Kontrollzeichen annehmen. Damit gibt es bestimmte Nachrichten, die nicht übertragen werden können.

??? war da nicht was mit bytestuffing ? Wieso sollte bcc eine Ausnahme sein ?

Stimmt natürlich. Ich hatte da noch was falsches in Erinnerung. Der BCC läuft also nur über die reinen Daten ohne jegliche Kontrollzeichen.

@PicNick:
BTW, ich habe mir gerade deinen Empfangscode von Seite 9 angeschaut und sehe da, dass du die Zeichen mit Prefix immer als "char &~ MASK" überträgst. Korrigier mich bitte wenn ich falsch liege: Das ist doch etwas anderes als eine Addition und wenn es geht ist es ein Spezialfall?

@NumberFive:
Noch eine Anmerkung zu deinem Bild: Die Netze müssen nicht zwingend an einzelne Rechner gebunden sein. Theoretisch kann eine Adresse überall liegen und ein Netz kann sich auch über mehrere Rechner verteilen. Genauso kann ein Rechner mehrere Netze beinhalten. Was praktisch alles möglich bzw. effizient ist, hängt nur von den Routern ab.

@PicNick:
Kannst du nicht mal deinen Schicht1 Code posten ? Ich würde meinen mal gerne testen.

ciao,
Ragnar

[marvin42x]

@PicNick: Danke für die neue Doku, mit den klaren Dokus im RN-Wissen kann man schön gezielt die Probleme angehen.

Da hat die Unstrittigkeitsbewegung wieder Terrain zur Besiedlung freigelegt.
https://www.roboternetz.de/wissen/in...PC_Vermittlung

Netter Gruß aus der vorlauten Stadt