ei, mir schwant ja schon der Graus'
Anbei ein Zip:
Das Prog
RNSI2C.BAS /BIN/HEX sollte in den CO-Proc
RNMASTER.BAS/BIN/HEX sollte in den Atmega32
Die sollten sich besser vertragen.
Wunderbar, TreeView steht auch erst an zweiter Stelle.
Das I AM noch nicht gefragt ist passt mir auch gut in den Zeitplan.
Woran ich starkes Interesse habe ist Die Option mit einem Client was zu senden was der Server dann Broadcastet. Mir wäre es sogar recht wenn der auf einem anderen Port sendet, dem Simulantenport.
Aber unterschiedlicher Port ist nicht Hauptsache.
Das ganze brauche ich für Mapbuilding Versuche und zur allgemeinen Netzaustestung.
Des Weiteren soll da später auch ein Datenbank Client senden können.
Durchleitung:
Alter Server:
Message Länge: 8Bytes 0 0 130 3 252 2 0
0
0
130
3
252
2
127
Message Länge: 8Bytes 0 0 130 2 150 0 0
0
0
130
2
150
0
22
Message Länge: 8Bytes 0 0 130 5 71 3 0
0
0
130
5
71
3
195
Message Länge: 8Bytes 0 0 130 6 69 3 0
Message Länge: 8Bytes 0 0 130 1 254 0 0
Message Länge: 8Bytes 0 0 130 0 64 1 0
Message Länge: 8Bytes 0 0 130 3 144 0 0
Message Länge: 8Bytes 0 0 130 7 255 3 0
Message Länge: 8Bytes 0 0 130 5 25 0 0
Message Länge: 8Bytes 0 0 130 2 21 1 0
Message Länge: 8Bytes 0 0 130 4 98 1 0
Message Länge: 8Bytes 0 0 130 6 60 2 0
Message Länge: 8Bytes 0 0 130 1 8 1 0
Message Länge: 8Bytes 0 0 130 5 232 2 0
Message Länge: 8Bytes 0 0 130 0 10 2 0
Message Länge: 8Bytes 0 0 130 3 96 1 0
Message Länge: 8Bytes 0 0 130 2 194 1 0
-Neure Server:-------------------------------------------------------------
Message Länge: 8Bytes 0 0 0 0 254 0 0
0
0
0
0
254
0
125
Message Länge: 8Bytes 0 0 0 0 76 3 0
0
0
0
0
76
3
202
Message Länge: 8Bytes 0 0 0 0 89 1 0
0
0
0
0
89
1
216
Message Länge: 8Bytes 0 0 0 0 28 1 0
0
0
0
0
28
1
159
Message Länge: 8Bytes 0 0 0 0 47 3 0
Message Länge: 8Bytes 0 0 0 0 0 0 0
Message Länge: 8Bytes 0 0 0 0 53 0 0
Message Länge: 8Bytes 0 0 0 0 252 0 0
Message Länge: 8Bytes 0 0 0 0 66 1 0
Message Länge: 8Bytes 0 0 0 0 39 0 0
Message Länge: 8Bytes 0 0 0 0 60 1 0
Message Länge: 8Bytes 0 0 0 0 196 1 0
Message Länge: 8Bytes 0 0 0 0 184 2 0
Netter Gruß
Ps. Danke für die Spielsachen, immer gern genommen.
Die ersten zehn Millionen Jahre waren die schlimmsten. Und die zweiten Zehn Millionen Jahre, die waren auch die schlimmsten.url
ei, mir schwant ja schon der Graus'
Anbei ein Zip:
Das Prog
RNSI2C.BAS /BIN/HEX sollte in den CO-Proc
RNMASTER.BAS/BIN/HEX sollte in den Atmega32
Die sollten sich besser vertragen.
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Das Sys ist gesprächiger
Ich nehme das Sys gerne, weil es so schön vor sich hin plappert.
Das RNMASTER macht natürlich einen schöneren Treeview, muss man zugeben.
Netter Gruß
Die ersten zehn Millionen Jahre waren die schlimmsten. Und die zweiten Zehn Millionen Jahre, die waren auch die schlimmsten.url
Alle gut in die Winterzeit gerutscht ?
Wenn Dinge kompliziert werden, hilft es manchmal, Schwerpunkte zu setzen.
Schau'n wir mal, daß die PC-Applikationen alle miteinander können, wenn du einverstanden bist.
Eigentlich sollte RN_SERVER alles, was bei IP einkommt, auf alle anderen IPs 1:1 verteilen.
Läßt sich das verifizieren ?
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Danke, Gut reingerutscht, Heute noch keine Fehler gemacht.
Also dann…..
Server:
Ich denke wir können Erstmal auf direkte Adressierung verzichten.
Jede PC –Applikation horcht ob es für sie interessant ist. Wenn ja benutzt sie halt die Message.
Ob es Interessant ist erkennt sie ja daran, von wem das kommt. Das bedeutet das die PC-Apps Eine Identität brauchen die als Absender mit gesendet wird. Bei 3 Slidern im Moment kein Problem.
Neue Gegebenheit:
Da wir jetzt ein neues Konzept von Einzelkomponenten verfolgen stellt sich eine neue Option:
Es ist bei meinem Projektteil vorgesehen.
1. Zusammenrottungen von Einzelkomponenten zu einer GUI als Verein zu behandelt.
2. Das sich beliebig viele unterschiedliche Vereine jeweils über ein Konfigurationsfile bilden können.
Diese Vereine die sich da bilden sollten auch einen Namen, oder Nummer haben.
Das ganze sehe ich unabhängig von dem gesendeten RN –Anmeldestring via Server
Frage:
Wie wollen wir das Adressmäßig lösen?
Netter Gruß aus der neuen Zeit
Die ersten zehn Millionen Jahre waren die schlimmsten. Und die zweiten Zehn Millionen Jahre, die waren auch die schlimmsten.url
Software Entwicklung:
Visual Basic 2005:
Ich sehe im Laufe der Arbeit, dass sich viele Softwarebausteine bilden.
Aus meiner Sicht ist es Arbeitssparend wenn wir einen Pool gemeinsamer Komponenten bilden würden die wir einheitlich benutzen und weiterentwickeln.
Wir würden auch, da es ja Open Source ist, Anderen die Möglichkeit geben, einzelne Komponenten zu benutzen, die sie nicht extra selber schreiben müssten.
Beispiele sind ein Errorhandler, Ein IniFile Erzeuger, ein Treeview, eine Singleton Fenster Routine, usw.
Das gilt logischerweise jeweils nur für eine, jetzt meine, Programmiersprache.
Als Testlauf kann ich mir das auch als separaten Ablauf vorstellen in dem nur Entwickler und Komplizen von Entwicklern Zugang haben. Wenn uns das nicht gefällt können wir es auch wieder sein lassen.
Mein Motiv dabei ist.
Eine Homogene Softwareumgebung zu erstellen die leicht zu Pflegen und zu Verbessern ist.
Die begrenzte Zeit die ein jeder hat zu schonen.
Der Bausteinbildung Vorschub zu verleihen
Zu einem guten Ergebnis zu kommen.
Von Anderen und ihrer Arbeit zu profitieren.
Wie gesagt, das alles ist ein Vorschlag von mir unter dem Aspekt, dass es ja eh Open Source werden soll.
Netter Gruß
Die ersten zehn Millionen Jahre waren die schlimmsten. Und die zweiten Zehn Millionen Jahre, die waren auch die schlimmsten.url
uff, uff, ne menge.
GUI e.V. : Wir haben dzt. eine Identität so eines Vereins, nur ist das halt nur Text. Auch ohne spezielle IAM könnt' da noch eine Netz-ID reinquetschen.
Aber besser wär's, überhaupt zu einem formalen Aufbau zu wechseln, solange wir noch jung sind. Denn bald werden auch die Versionen eine interessante Information sein. ("hat der dieses oder jenes schon drauf oder nicht")
Mir wäre es einfach, wenn wir da ein Key-Value-Format nehmen würden
Key1=value1 , Key2=value2 , ....;KeyN=valueN
ID=nnnnn , NAME=aaaaaaaaa , VERS=mmm , DESCRIPT=aaaaa
(alternative statt "ID" IDC=class, IDI=ident )
Für den Absender isses so soder so nur ein String, aber ich tu' mir leicht beim zerlegen, und wir können jederzeit was hinzufügen, ohne bestehende Applikationen zu tangieren.
Also:
KEY ID, IDC, IDI, VERS, NAME, ......
"="
value numerisch oder text, je nachdem (nix hexadezimales)
"," Argument-Seperator oder nix, wenn nix mehr kommt
Reihenfolge egal, alles optional ( Wenn keine ID, dann hat er eben keine)
Das "RN" am Anfang müßte dann nicht mehr sein
*puff* für Erste
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
*next*
Für das Startup ist die Zusammensetzung eines GUI e.V. natürlich wichtig. Aber beim laufenden Betrieb bin ich mir jetzt nicht sicher, was eine GUI-ID für eine konkrete ´Bedeutung hat.
Gibt es die gleiche Komonente (ID-mäßig) in verschiedenen, gleichzeitig laufenden GUI e.V ?
Kannst du einfach mal vor Dich hinspinnen und erzählen, wie du dir so eine Roboter-Session idealerweise vorstellst ?
Die Frage geht danach: Was ist dynamisch variabel, und was ist fest definiert ?
(Ich mein, dem Robby kann ja kein neuer Haxen wachsen, nur weil man auf der anderen Seite einen Slider dazustartet)
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
GUI e.V. Teil 1:
Hört sich sehr gut an.
Machen wir erstmal so.
Du brauchst das für den Server ja noch nicht so dringend einbauen wenn der erstmal nur beim Broadcasting bleibt.
Broadcasting würde mir im ersten Schritt schon reichen.
Den Rest wickeln ja dann Die PC-App’s ab.
Damit hast Du mich schon mal vom Hals und deine Ruhe
Netter Gruß
Die ersten zehn Millionen Jahre waren die schlimmsten. Und die zweiten Zehn Millionen Jahre, die waren auch die schlimmsten.url
Ok, wie gesagt, eigentlich sollte er das broadcasten machen. Bitte schau mal, ob's wahr ist
(Nicht die erste "ID" Message, logo) Oder soll er doch ?
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Lesezeichen