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

[PicNick]

@Marvin42x: Da das connectivity-Problem ja nix neues ist, gibt's auch eine Menge Ansätze dazu, keine Sorge. Ob unser Konzept eine Verbreitung erlangt, wird allein davon abhängen, wie gut und attraktiv die letzliche User-Anbindung sich darstellt. Deshalb bin ich ja so dahinter, ein easy-to-use interface für Bascom zu machen, da das ja das Klientel darstellt, das sich mit anderen Konzepten die Hände bricht.
Genauso kommt's auf die PC-Seite an. Auch ein Beginner muß da sofort (bald) einen Zugang finden können.
Die Power-User, die sowohl für µC als auch für PCs abgefahrene Programme mit 57 DLL's installieren, sind nicht unsere Kundschaft, die machen sich das eh' lieber selber (Kein Programmierer stirbt, eh' er nicht wenigstens einen Compiler und/oder ein Betriebssystem neu erfunden hat)

[marvin42x]

@PicNick:
Das war mir jetzt aber aus dem Herzen gesprochen. Genau das ist mein Ansatz. Da bin ich ja wieder optimistisch und vergnügt

Besten Dank und Netter Gruß.

[PicNick]

BTW, Männer : Ich kann mir für die Mikrokontroller eine Menge Begriffe als Bezeichnung für die Applikations-"Module" vorstellen
ADC 1- 8
Battery-Check
GP2D12
SF08 (10) front, rear, etc.
Stepper left/right
DC PWM Left/right
Servo 1- nn
und so weiter und so fort.

Was für Art Begriffe sind eigentlich bei den PC#s angedacht ? Kann ja nicht alles einfach nur "GUI 1-99" heissen ?

[ragnar]

@PicNick:
Dann belassen wir die Addition bei geprefixten Daten. Aber ich habe im Moment nur 8 Kontrollzeichen und addiere auch nur 8.

Zum Testen bräuchte ich übrigens ein PC-Programm. Mit NumberFives SerialServer gehts leider nicht. Weitere Kandidaten
sind immer willkommen.

Zu den Nacks: Eine sequenznummer mit 8bit wäre eine Lösung für die Nacks, ich persönlich würde die Nacks aber gerne
rein über Pings bzw. Timeouts beim Absender einbauen. Die Programme die ein Nack wirklich brauchen, können das viel
einfacher handhaben und erschlagen auch gleichzeitig abgestürzte Knoten, alle anderen die die Nacks einfach ignorieren
würden belasten das Netz nicht zusätzlich.

Zur Nummerierung der Schichten: Na gut, lasst uns die Schichten von 0 aus zählen.

@PicNick:
Von Multicasts bin ich auch nicht so begeistert aber wenns funktioniert dann ist es ok. Das es über Multicasts
geht heisst ja nicht, dass wir nicht eine zweite Möglichkeit mit z.B. TCP einführen können.


Zum Routing: Ich habe mir was ausgedacht und bin dabei, es ins Twiki zu hacken.


Ragnar

[NumberFive]

@ragnar

Warum geht es nicht ?
Kann ich mal die Logs haben ?
Was hast du gegen Muticast ?
Bitte erkläre das mit dein Nack Idee genauer.

@Alle

Ich denke das ich für die PC seite so sachen machen
Jostick abfrage für den Hand betrieb
Datenlogger (Mysql)
Kartenwriter (Mysql)
Mit den AStar algorytmus ein Pathfinder
Karten Viewer da mit man sich auch ansehen kann
wie die errechnte Karte aussieht.

Und natürlich ein ein Oberfläsche mit der man was sieht.

Gruß

[marvin42x]

@NumberFive:
Das ist ne Menge die du da vorhast. Ich freue mich über solche Sachen sehr.
Ich glaube du müsstest dich mal mit PicNick ins einvernehmen setzen wegen der Namensgebungen.
@all:
Es besteht beim rnbfra bereits eine hypothetische Sensorzuordnung die ich für ganz plausibel halte.
https://www.roboternetz.de/download/dokurnbfra1.2.pdf
siehe z.B Seite 6 Pinbelegung

Da würden mir PicNicks Namensvorschläge schon gefallen.
Wir werden früher oder später eh eine Liste der gebräuchlichen Sensoren und Aktoren brauchen. Die wird vermutlich auch nicht soo lang sein.
Wenn PicNick an seinem Betriebssystem schraubt wird er das möglicherweise auch alsbald brauchen.
Ich fände es auch nicht schlecht wenn dann beim Testen auch real vorkommende Daten übers Netz fliegen. Damit würden die Testerei Schichtenübergreifend möglich und aussagefähig.

Eine Detailfrage: kann man in den Ini-files die Option von Kommentarzeilen schon recht früh implementieren?

Netter Gruß

[PicNick]

ACK/NAK Beim Marsrover und anderem hat sich gezeigt, daß die Sache nicht so heiß gegessen wird.
Explizite ACK haben wir fast garnicht verwendet, sondern einfach nach Erledigung der Aufgabe (kann ja auch dauern) eine "Status" Meldung als wiederum normale FWD Message gesendet. ("status" heißt z.B. "POWER-IS-ON"). Da Kommandos ja meist aus soll-ist vergleichen stammen, kann der Absender damit oft mehr anfangen als mit "OK"
NAK auf einzelne Messages ist ja auch nicht so häufig. Wenn, dann geht meist eine Message verloren, weil irgendeiner grad im Streß war, und dann gibts in der Form eh' kein NAK.
Wurde etwas adressiert, was es dort nicht gibt, ist das ja auch kein "Betriebs-zustand", mit dem eine autonome Software was anfangen könnte, sondern da hat's was Grundsätzliches in der Konfiguration.

Bleibt hauptsächlich der "total-NAK", d.h. aus dem Ausbleiben von Heartbeats oder Ähnlichem wird geschlossen, daß sich irgendeine System-komponente verabschiedet hat.

Trotzdem müssen wir, besonders für die entwicklung von komplexen Systemen, wo's ja auch Programm-Fehler gibt, und wo Analysebedarf herrscht, die NAK-Schiene durchziehen. ("Wieso bleibt der Robby nicht stehen, wenn ich es sag'?". Wo und wieso ist der Befehl versandet ?)
Is ja meist so, daß eh' alles funzt, nur irgendwas Bestimmtes geht in einer bestimmten Situation eben doch nicht. Ich liebe intermittierende Fehler, die nur an jedem 3. Sonntag auftauchen

[NumberFive]

Ok die Beschrieben fehler hasse ich auch.

Deswegen schreiben mein sachen so viel.
Aber was nutz es wenn du nur zu hören bekommst es tut nicht

Aber was du jetzt genau mit dem NACK/ACK willst habe ich ehrlich gesagt nicht verstanden.

@marvin42x
das ist das was ich für meinen Robi brauche. Klar wenn ich mir dann auch dinge saugen kann bin ich bestimmt nicht böse.

Das mit den Ini files gucken ich mir gleich mal an.

Schön wenn wir jetzt schon Namen habe aber mir fehlen noch ein paar ebenen im protokoll. Also ich Stelle es mir am ende so vor in der dll gibt es die Funktion GetBatPower() wie kommt jetzt das richtig als nachricht am AVR an mit userer Level0 defintion bis jetzt jawohl nicht oder ?

Gruß

[NumberFive]

So jetzt habe ich mal was gebaut.

Das Ini File

[ERRORS]
4=No Adressentry found for Client Name # Der Client Stehe nicht in der Adressliste
5=Message Konfig not found

[ADRESSE]
Client1=1|78     # Hier werden die Cleint's eingetragen 1|78 bedeutet Netz 1 Adresse 78

[MESSAGE]
Ping=0|1         			# 0 Parameter und das CommandWord ist 1
MNTest1=3|2|BYTE|WORD|CHAR[23]		# 3 Parameter CommandWord 2 Para1 ist ein BYTE WORD und dann noch 25 zeichen

Ich habe mal die Binarys Updatet und und das Level1 für mich einbisschen weiter definiert.

BYTE[1] = Netz
BYTE[2] = Adresse

aber das kennt ihr ja schon

BYTE[3] und [4] = das Command Word

BYTE[xx] der Rest einfach an einander Gereit. So wie es in der INI definiert wird.

Ich mach mal mit dieser definitio weiter bis von euch was kommt in der hoffnung nich alles neu machen zu müssen später

Gruß

[marvin42x]

@PicNick:
Hatte verschlafen das Du eine neuere Version deines sys.bas eingestellt hast. Anbei ist noch ein rn_server der will immer ne Lib (MFC42D.DLL), wenn er sie hat gefällt sie ihm nicht. Habe mal gegoogelt:
http://www.easy-coding.de/mfc-dlls-t111.html
vielleicht ist der Server aber noch nicht zum Spielen?
Netter Gruß