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

[marvin42x]

@NumberFive: Danke Dir das Thema Datenbanken werde ich aber in diesem Thread nicht vertiefen. Das ist heftig genug für einen eigenen Thread. und wie Du schon sagst macht das erst Sinn wenn die anderen Sachen stehen.

Netter Gruß

[NumberFive]

so ich hoffe das die daten dann auch dem nächst im dowload bereicht zu sehen sind habe Frank mal ne PN geschickt des wegen

[NumberFive]

So jetzt habe ich mal ein Readme runter getippt damit
so hoffe ich es auch jeder zu laufen bringt:

Readme zu Numberfive's RNCom / RN-Protoll Sachen

Installation:

Alle Programmteile in ein Beliebiges VerZeichnis Packen.

RNComNetworkLayer Einmal mit Parameter -RegServer starten da sollte
dann ein MessageBox Kommen und er sich sofort wieder Beenden. 
(Eintragen Regestry Windows).

die RNProtClient.dll mußt man mit dem programm regsvr32 (gehört zu windows)
in die regestry eintragen. Also regsvr32 RNProtClient.dll

Es werden nach dem Ersten Starten dann Ini Files erzeugt und die Muß
man dann anpassen.

Was macht was:

RNProtClient.dll Ist die Dll (Com-Objekt) Wo einem die Arbeit mit dem Protokoll
Abgenommen Wird. (Später)
Also Programme die das Protokoll Implementieren wollen müssen Hier drauf.

RNComNetworkLayer.exe das Programm händelt die Protokoll verschickung über
TCP Multicast. Com ExeServer SINGLETON

SerialServer.exe kümmert sich um die Daten/Protokoll umstetzung von TCP
nach Serial und umgekehrt.


Die RNComNetwork.ini

[RNComNetwork]
OwnIP=192.168.2.1		// Rechner IP wo das Programm läuft
MultiCastIP=224.0.0.0		// Die Multicast IP im Netz wenn man sich damit nicht aus kennt einfach so lassen den es gehen nicht alle adresse
MultiCastPort=44000             //  Wenn der Port nicht für was anders gebraucht wir so lassen   


Die SerialServer.ini

[SerialServer]
Comport=COM1			// Der port an dem der AVR Hängt
Baud=9600			// BAud rate der Rest ist Hard 8n1
ComNetwort=1			// Netz in dem der AVR Ist siehe RNCom definitionen

Das User Interface (RNProtClient.dll):

!! Achtung dieses Interface wir Sich noch Stark ändert den es soll Später das
bentzuen des Protokolls ganz einfach machen !!

Die Events:

[id(1), helpstring("Methode TraceIt")] HRESULT TraceIt(BSTR TraceTxt);
Ist eingendlich nicht so Wichtig aber hier sieht man was untendrunter so passiert

[id(2), helpstring("Methode NewData")] HRESULT NewData(LONG Network,LONG Adresse,LONG ID);
Wol das wichtigte Überhaupt ES sind neue daten da.
Netzwork und adresse wird hier mit geben damit man gleich weiß ist Broadcast oder für
mich

Die Proceduren:

[id(1), helpstring("Methode Init")] HRESULT Init();
das ist die Funktion um zu sagen nun kanns los gehen ich bin fertig

[id(3), helpstring("Methode SetOwnRNAdresse")] HRESULT SetOwnRNAdresse(LONG Adresse);
das ist meine Adresse es ist ein Long weil VB nix anders sauber erkennt
aber es sind nur werte zwischen 1 und 255 Zulässig

[id(4), helpstring("Methode GetDataAsString")] HRESULT GetDataAsString(LONG ID,[out, retval] BSTR *Data);
Hier kann man sich die daten holen als String daten die man normal nicht darstellen kann
werden in der Form <wert> übergeben also ein 0 byte sieht so aus <00>

[id(5), helpstring("Methode SetOwnRNNetwork")] HRESULT SetOwnRNNetwork(LONG Network);
das ist meine Netz zu dem ich gehöre es ist ein Long weil VB nix anders sauber erkennt
aber es sind nur werte zwischen 1 und 255 Zulässig

[id(6), helpstring("Methode SendString")] HRESULT SendString(LONG Network,LONG Adresse,BSTR bsData);
Hier mit Kann man daten Senden
Gleiches Spiel wie oben ein 0 Byte sendet man so <00> und ein < mit <<
Das habe ich so gemacht damit zur zeit mal alles testen kann Später muß man das Hofftlich nicht mehr benutzen

[marvin42x]

So, habe Das RN-Com System von NumberFive ausprobiert damit wir das auch mal auf einem fremden System überprüft haben.
1 PC
über Router
1Notebook
Außer das ich vergessen habe den Netzkabelstecker einzustecken, ähemm….läuft alles wie es soll, bin richtig begeistert. Broadcast vorwärts rückwärts, hin und her .
Macht richtig Spaß.

Ich habe die DLL jetzt ins Window system32 Ordner kopiert, ich hoffe das war richtig.
Die MulticastIP habe ich nicht geändert, nur die jeweilige RechnerIP ins ini-file eingetragen.
Die gesamte Einrichtung ist für einen Ungeübten etwas fummelig aber mit NumberFives Anleitung geht das einwandfrei und wir wollen ja hier erstmal nur testen.
Ich habe beim Start die Reihenfolge: erst RNComNetworkLayer.exe dann Serialserver.exe und dazu dann noch RNProtVB.exe eingehalten.

Nettes Broadcasting

[marvin42x]

Frage:
Wie sind die Vorstellungen bei dem konkreten Beispiel-Komplett-System auf Mega32-Basis, generell.
Sind Werten die der Mikro schickt vom Mikro linearisiert, umgerechnet, mit offset, oder wie auch immer oder wird er nur nackt senden?
Können wir eine vorläufige Beschreibung der zu erwartenden Werte die gesendet oder empfangen werden erstellen?

Dann braucht z.B. UlrichC sich nicht zu langweilen und auch andere High-Level-Ansätze können schon mal ihre Startlöcher graben.

Und hier mal ein Vorschlag zur Vermittlung, der nur als Einstieg gemeint ist.

Routing/Dispatcher:
PicNick hat im Wissensbereich die Frage der Listen/Tabellen bereits Skizziert.
https://www.roboternetz.de/wissen/in...PC_Vermittlung
Das was dort steht scheint mir sehr konstruktiv, folgerichtig und unstrittig.
Wenn sich dort noch,, oder hier im Thread, von irgend jemand, ein strittiges Beispielsweise config-file einfinden könnte?

Über den vorläufigen Aufbau und die Regeln der ini-files müsste aus meiner Sicht als nächstes Einigkeit herrschen.

Ich könnte mir vorstellen, dass wir dafür Textdateien nehmen.
Das hätte den Vorteil, dass dort von Hand als auch vom Programm jederzeit editiert werden kann.

Es müssten mindestens 2 ini-file Typen sein:
1 Adressen
2 Teilnehmer-Config (Robi,GUI, Logger, usw.)

Es sollten meiner Meinung nach Kommentarzeilen möglich sein die durch ein Sonderzeichen markiert sind z.B. (#)
Das würde ich mir für alle Dateien dieses Typs wünschen (hilft den Anfängern)

Adressen:
Die Robis haben im ini-file Klartextnamen und ein Äquivalent Binär?
Die Komponenten von Robi haben im ini-file Klartextnamen und ein Äquivalent Binär?

Teilnehmer-Config:
1 Komandobeschreibung:
Hier steht welche Kommandos Robi kann und in welcher Form er sie erwartet.
2 Werte:
Hier steht welche Werte Robi senden kann und wie die aussehen und was sie bedeuten.


Zusammengefasst:
Das ini-file hat einen Namen
Das ini-file ist eine Textdatei
Das ini-file hat Komentarzeilen
Das ini-file hat Rubriken:
Das ini-file muss ganz oder teilweise versand fähig sein.
Wie gesagt.
Dies hier ist nicht die Lösung sondern eine Provokation

Netter Gruß

[ragnar]

@PicNick:
Statt der Addition können wir gerne auch bitweise Negation (XOR 0xFF) verwenden. Du kannst
aber auch auf ein char (signed) jederzeit 8 addieren und auch bekommst trotzdem ein richtiges
Ergebnis (-128 + 1 = 0). Solange deine Variable 8 bit hat funktioniert die Addition unabhängig
von signed oder unsigned.


@PicNick:
Betreffend des von dir beschriebenen Routings einige Fragen:

1.) Wie wird das 'Nack' mit der verworfenen Nachricht assoziiert? Oder wird das Nack
einfach so an den Empfänger zurückgeschickt? Wenn ja, was kann der Empfänger mit dieser
Information anfangen wenn er sie nicht einer ausgegangenen Nachricht zuordnen kann?

Worauf ich hinauswill: 'Nack' macht meiner Meinung nach nur am lokalen Router sinn, wo der
Router direkt auf das Absenden reagieren kann. Schau dir mal IP an, da ists auch nicht anders.
Ein 'No Route to Host' bekommst du nur, wenn dein lokaler Router nicht weis wohin mit der
Nachricht. Ist die IP beim Ziel nicht bekannt, dann gehts stillschweigend schief.

2.) (aus Anforderungen/uController): Wie soll der uC eine Empfängeradresse für z.B. Sensordaten finden ?
Prinzipiell per Broadcast zu senden verschwendet IMHO Ressourcen, das Paket wird ja auch an jeden
anderen uC geschickt. Besser wäre eine Registrierung des Empfängers beim uC. Der Client registriert
also seine Adresse beim uC und jedesmal wenn der uC Daten generiert werden diese an alle registrierten
Adressen verschickt.

Prinzipiell ist das aber sowieso mal kein Problem der Routingschicht.

3.) DNS ist gute Idee, aber fürs Routing auch nicht wichtig.

4.) Wie sollen die Routingtabellen aufgebaut bzw. synchronisiert werden?


@NumberFive:
1.) Kannst du bitte mal genau beschreiben, was dein Programm alles kann? Am besten aus Sicht der
jeweiligen Schichten.

2.) Wie überträgst du die Nachrichten übers LAN?

3.) Gibts deine Programme auch als Binary? Ich habe gerade keinen Compiler greifbar und wills auch
mal ausprobieren.

4.) Welches Nachrichtenformat für Schicht2 verwendest du? Welche Adressen?


@Alle: Wer hat jetzt alles eine Implementierung der Schicht1-UART mit der ich meinen
Schicht1-UART testen kann?

@Alle:
Als nächstes sollten wir verbindlich festlegen, welche Nachrichten wir auf Level2 (Routing)
brauchen. (Adressformat, dynamisches Routing, ...)

@marvin42:
Ini-Files und anders sind implementierungsspezifisch und werden wohl nicht Standardisierbar sein.


Ragnar

[PicNick]

Jetzt hab' ich grad' einen Roman geschrieben, da bin ich rausgeflogen, super.

Add/XOR Mit gefällt XOR FF schon sehr. Aber ich tät sagen, lassen wir es mal, wie's ist. ( + 16 / 0x10 )

NAK: klaro, Rücksende-adressen ohne unique Msg-Referenz geben nix her, wenn der Absender mehrer Nachrichten am Laufen hat. Manche haben aber nur einen Partner, da ist jedes NAK genauso eindeutig.

Sprich: über den genauen Aufbau von Sende-Rücksendeadressen sollten wir uns bald klar werden.



NAK lokal/router etc. : Im möcht IP als Transport-Büffel für die PCs in unserem Netzwerk haben. Wenn irgendwo ein I2C gerät krepiert, dann soll das jeder im RN-Netz auch wissen können.


TEST: Welche Plattform brauchst du ? PC ? µC ?

[PicNick]

Tabellenaufbau: Wenn auf einem Rechner eine Applikation gestartet wird, muß sie sich ja zu unserem Netzwerk connecten, vorher kann er ja nich kriegen oder senden. Lokal entsteht so eine Tabelle also ziemlich automatisch/elektrisch. Dieser Rechner verteilt nun seine Zu- oder Abgänge von Applikationen (sprich adressen) an die anderen (Routing) Rechner.
Wenn es ohnehin nur einen Central-Routing-Node gibt, entfällt das Verteilen natürlich.
D.h. ("INI-File") Jeder Teilnehmer weiss, wer er ist. Jeder Rechner weiss, wo und wie er seine(n) Routing-Rechner erreichen kann. (IP, Port-#).

Im Prinzip ist jeder Router, der mehr als ein Level-0 Modul hat

[PicNick]

Und noch ein's: Technisch gäbe es keinen Grund, Adressfelder unbedingt mit fixer Länge auszuführen. Ich weiß aber nicht, wie gut VB oder JAVA mit variablen Feldlängen zurechtkommen ?

PS: eine (optionale) Messagereferenz kann man der Absender-adresse zuordnen, aber man kann das auch als eigenständiges Attribut einer Message sehen.

[NumberFive]

http://www.i-do-more.de/mine-robo/do...-Protokoll.zip

hier gibts die Binarys wollte den Link zwar nicht so officell machen Frank scheint im Moment auch keine Zeit zu haben da im Downloadbereich mein Posting noch nicht auftaucht.

Ich finde schon das die Adresse ein Fixe Länge haben sollten sonst müssen wir wieder ein trennzeichen aus machen. Für VB und auch java würde jeweils ein DLL an bieten damit ersten schneller geht bei anbinden und wir normalfall im unter grund was ändern können ohne das gleich die Applikationen geändert werden müssen.

So wir müssen und glaube ich mal einig werden wo welche Schichten an fangen bzw aufhören und wo wir dan fangen zu zählen Level0 oder Level1.

Ein Level2 habe ich (noch nicht) in mein Programm integiert weil ich alles im nach hinein nicht wieder ändern wohlte. Bis auf die Defintion das Byte 1 und Byte 2 Netz und Adresse sind ist alles so wie es bis jetzt hier definiert worden ist.

Wie Funktioniert es:

SerialServer: Hört Ständig auf dem Eingestellten Comport und prüft die daten auf dem Level0 mit Prüsumme wurde ein Telegram als richtig erkannt wird es an die Netzschicht (RNComNetworkLayer.exe) weiter geben.

RNComNetworkLayer: macht nichts Anderes als Auf der ein stellten Multicast Adresse / Port zu hören und zu senden.

RNProtClient.dll: Verbindet sich mit dem
RNComNetworkLayer auf der Einen Seite und mit dem Client Programm auf der anderen Seite. Hier ist wie im Serial server das Protokoll dir wie es hier bis jetzt definiert wurde.

Ablauf :

Com X >> SerialServer >> Protokoll Prüfung auf anfang Ende Prüsumme >> NetzwerkLayer >> Clientdll >> Protokoll prüfung >>Suchen ist der Empfänger bei mir ? ja Melden und speicher des Telegrams >> Client kann sich die Daten holen.

Für die Prüfung ob der Client bei mir ist habe ich das mit der adresse und dem Netz Implemiert. damit nicht der Client entscheiden muß wann er was an nimmt und wann nicht.

Alles was für ein Bestimmtes Netzankommt (Inifile SerialServer) wird auf der Com Ausgeben. Ok bei mein Impelmetierung gibt es immer mindestens zwei Netze sonst besteht die Gefahr wenn PC Programm sehr viele telegramme Austauschnen das der AVR der per RS 232 an gebunden ist zu kochen beginnt. Es währe hier sich auch kein Thema entweder zu enstellen oder Dynamisch adresse auf der Com Seite auf zu bauen (Router) damit nicht alles rüber geht das ist dann sache der weiteren Definition.

wenn mal die Verbindung auf die RS232 nicht braucht funktioniert das ganze natürlich auch ohne der Serial server.

Man kann also mit der Software so wie sie jetzt ist Pratisch daten im Netz (PC Lan) wie auch an die Seriale Schicken die Seriale muß sich aber nicht auf dem rechner befinden wo man das Telegramm abschickt.

Ich habe das interface der DLL als Text oder String interface ausgelegt damit es keine Problem in der Sprachen gibt. Aber das habe ich ja weiter oben schon beschrieben.

Ich bin beim Programmieren darauf gekommen das wir das TCP nicht lesbar machen müssen den wenn die DLL da ist sollte es kein problem sein seine Anwendung anzu binden. Durch die verwendung von Multicast gehen ich auch einem Problem aus dem weg nämlich die Ganze Port konfigurtion und solche sachen. Da ist die Erfahrung von der MC/Simirs das mit den Ports und so ist für viele nicht so einfach zu verstehen. Ich brauche so auch keine Routing informationen zu mindestens nicht auf der PC Seite.

Ich weiß in der Linux welt gibt es kein dll aber hier gibt es so files die in meinen Augen genauso Funktionieren.

OK die Netzlast ist etwas höher da alle das Telegram bekommen auch wenn es auf dem PC keinen Abnehmer dafür gibt. Aber ich denke das wir im Nomal fall eh nicht mehr als vielleicht 3 PC's in dem Netz haben.

ich hätte gerne im Level1 oder level2 gerne ein Zahl (MSG ID) die immer erhöht wird dann könnte ich das Nack selbst bauen und die Applikation bekämme dann die Information konnte zu gestellt werden oder nicht und weiß auch noch welches Telegramm es war. Also 0 - 255 wenn wir oben sind fangen wir wieder bei 0 an. Das Sollte in meinen Augen reichen.

Oh mann jetzt habe ich aber ordenlich was getipp verteht man das Überhaupt ? Sind alle Fragen beseitigt ?