Archiv verlassen und diese Seite im Standarddesign anzeigen : Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt
@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
06.03.2006, 15:02
@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ß.
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 ?
@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
07.03.2006, 07:41
@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
07.03.2006, 09:09
@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ß
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
07.03.2006, 18:40
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
07.03.2006, 22:37
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
08.03.2006, 00:19
@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ß
Morjen
Das is offenbar die debug-version vom mfc42. ahja. ich stell ein Set zusammen, das dann hoffentlich funzt.
NumberFive
08.03.2006, 07:44
Hat einer von euch eigendlich so ein funkmodul im einsatz ?
Wenn ja hätte ich da so ein paar fragen weil währe doch schade wenn der
SerialServer damit nichtklar käme.
@PickNik was mach dein rn_server eingendlich ? Kann ich den als gegen stück zum SerialServer betreiben ? Damit ich mein Protokoll im plementierung testen kann ?
Gruß
Anbei das gezippte.
@Marvin42 Das Bascom-Zeugs kennst du ja LBX->Bascom-libdir
RN_SERVER (Primi-Dödi-Teppen-Beta-Programm)
kann man auch zum Testen gegen einen anderen PC-Nehmen
COm-Port ausbessern, open clicken.
Er schickt sekundenweise die BYtes
STX 0x42 0x01 0x00 0x00 0xnn /ETX
data ist ein Zählbyte 0-255 im Kreis
Empfängt er was , zeigt er es an.
Das bASCOM -PROG zeigt die Zahl auf den Leds an.
Jede 1.5.sekunde schickt er das Extension-Port zum PC
STX 0x00 0x00 0x42 0x03 0xnn /ETX
sonst nix.
IP: wenn das port (42) geöffnet wird, kann man sich (IP-STREAM) connecten, RN_SERVER spielt dann Durch-haus IP<-->COM
es sind alle MFC42(d).dll dabei
Ich hab's ins download gestellt
http://195.128.164.40/RT_MUSIC/electronic/download/down.htm
marvin42x
08.03.2006, 08:59
@PicNick:
Danke, werde es vermutlich erst morgen ausprobieren können.
@NumberFive:
Ich habe zwei rn-funkmodule. Die sind aber noch nicht folgsam zu mir und senden immer nur die Hälfte von dem was sie sollen. Aber grundsätzlich arbeiten die transparent. Die serielle glaubt sie hätte ein Kabel dazwischen. Einzige Einschränkung:
wenn +++ kommt geht das Funkmodul in den Befehlsempfangsmodus, sendet ein OK und wartet ein paar Sekunden auf Anweisung, Kanaleinstellung und so was.
Netter Gruß
Sollen wir auf Level-0 was einbauen, damit niemals +++ kommt ?
NumberFive
08.03.2006, 09:18
ich glaube das die drei +++ AT standart sind meine das schon mal gelesen zu haben als sollten wir und da was überlegen.
Soll ich in den SerialServer was ein bauen damit man das Teil Initialiesieren kann oder eher nicht ?
Gruß
Beim AT-Standard ist das so mit den "+++" .
Eigentlich ist das eine Variante von Level-0, die bei der "normalen" UART eigentlich nicht dabei sein muß. Wir werden erstmal sehen, wo überall Unterschiede bestehen (halb-duplex, Sendepausen etc. ?)
Genauso wie ev. eine Modem-bedienung mit HW-Handshake.
Schau'n wir mal, und sammeln Info, wo was zu tun ist.
marvin42x
08.03.2006, 09:31
Stimmt, so gesehen.
der fliegt ja sonst immer raus.
Das Funkmodul ist ja für unser Konzept ein atraktive Lösung, wird also öfter mal eingesetzt.
Ich weis nicht ob man noch mit anderen Kandidaten rechnen muss die solche Alüren drauf haben?
Netter Gruß
Edit: Hier muss man ja hinne machen wenn man was aktuelles sagen will :-)
.. hinne machen ..
Jaja, da ist Action.
Wegen +++: keine Programmumbauten in der Panik, so oft kommt das ja nicht vor.
Also Info sammeln, was es in der Richtung so alles gibt
Bei IR z.B. wird's da auch was zu tun geben.
Gaaaaanz locker.
Klopf, klopf, ist wer zu Hause ?
Schaut mal, ob wir irgendwelche Widersprüche bei der Vermittlungs-Thematik haben
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_Vermittlung
... Eigentlich ist das eine Variante von Level-0, die bei der "normalen" UART eigentlich nicht dabei sein muß...
Ich hab auch so ein paar Funkmodule.
Da brauchts vermutlich einen eigenen Level-0 Treiber.
1. Da ja mehrere Funkmodule gleichzeitig dran hängen könne, brauchen wir die Adressen.
2. Halbduplex !
3. Kollisionserkennung ?
Wir sicher effizienter sein, Funkmodule-Treiber extra zu machen, da es ja keinen Sinn hat, eierlegende Allgemeinwollmilchsäue zu produzieren. Konzeptmäßig darf das kein Problem machen.
Ich muß mich mal schlau machen, wie man die Funk-module zu behandeln hat (doku ? robotik-hardware ?). Mach ich mal gerne, wenn Bedarf da ist.
marvin42x
09.03.2006, 15:47
Aus meiner begrenzten Sicht heraus sieht das für mich sehr gut und richtig aus.
Auch die Lösung Sensor-Rezeptor gefällt mir.
@PicNick:
Die neue Zusammenstellung läuft ohne Probleme. ich werde mich jetzt ein bisschen umschauen in Deiner neuen Betriebsystem Einrichtung.
Da ist ja kaum ein Schrank an der alten Stelle. Für mich als junger aufstrebender Programmiernachwuchs ist es natürlich Klasse ein System in der Evolution beobachten zu können.
Thema Neuling:
Wenn ich manches noch besser begreifen würde wäre das perfekt. Du hattest mal in einem Beitrag kurz ein paar Variablen-Namen-Gebungs-Konventionen von Dir beschrieben. Das war total hilfreich weil ich den Sinn der Variablen mit einem mal mitlesen konnte.
Es ist für Neueinsteiger recht hart mit scheinbar sinnlosen Kryptowörtern, die zudem augenscheinlich Engländer sind, zu kämpfen. Ich hatte sie dann manchmal mit suchen und ersetzen umbenannt, wenn ich was verstehen wollte. Da träumte ich dann von einer kleinen Erläuterungsliste von Variablen-Namen . Man könnte später mal drüber nachdenken ob das möglicherweise eine Überlegung wert sein könnte.
Das ist aber jetzt wirklich kein zentraler Punkt, sollte nur mal das Blickfeld eines Neulings beschreiben.
Netter Gruß
mmhhh. Es sollte geben "easy radio software guide"
Hat den wer ? ich hab ihn noch nicht finden können
@marvin42 Ich werd' mich bessern, nicht alles fällt einem selbst auf, man ist ja zum Fachidioten verkommen.
https://www.roboternetz.de/wissen/index.php/Betriebssystem_f%C3%BCr_Bascom
Hast du dort gelesen ? ein bißchen mehr Kommentar dazu.
marvin42x
09.03.2006, 16:52
@PickNick: Super, hatte ich in der jetzigen Form noch nicht gesehen. Ist sehr schön zu lesen. Das kann ich inzwischen wie ein Lehrbuch benutzen.
Thanks und netten Gruß
NumberFive
10.03.2006, 08:52
Na super mal wieder keine Benachrichtigung bekommen.
Das es hier was neues Gibt.
@PicNick
Schöne bilder und von grundsatz her stimme ich dir zu. Um aber die Routing table Füllen zu können muß das netz nachrichten verschicken wer wo sich an gemeldet hat. Das währe dann auch die Möglich Config fehler zu finden doppelte ID's. Spricht es muß eine art an meldung am System geben.
Habe ich das jetzt richtig verstanden das dein Betriebs system für Bascom sich schon mit dem Netz unterhalten kann ?
Zu den Funkmodulen:
Es gibt doch eingendlich nur Zwei ausnahmen bei den kein +++ und kein
Duplex betrieb. Oder gibt es noch mehr besonderheiten ?
+++ Diese Sache wäre am dringlichsten zu klären. Denn das müßten wir noch ganz unten im UART-Level-0 einbauen.
1/2 Duplex würde ich lieber noch ein paar "evaluierungstest" machen wollen, bevor wir uns krumm definieren. Aus Sicht des µC-Programmierers würde ich sagen, ich schließ mich mit einem Funk-Besitzer als Arbeitsgruppe zusammen und wir sehen uns an und testen auch.
Das Bascom Sys spricht unseren dzt. Level-0, und geht als Prototype mal von 16-bit addressen aus
STX / Ziel / Absender / variable Daten / BCC / ETX
Die Programm-infrastruktur ist so, daß man recht schnell verschiedene Verhaltensweisen der Schichten drüber implementieren bzw. anpassen kann.
Die Sache mit den "Routing" Tables seh ich so, daß es sowohl zwangsläufig eindeutige Ziele gibt, aber auch Teilnehmer, wo das nicht notwendig ist. Das letztere sind die, die immer von sich aus die Initiative ergreifen, das heißt, sie müssen ja nicht gesucht werden, die melden sich ja eh' von selbst (und Absender ist ja sowieso immer eindeutig)
Logo, wenn beim "Router" zwei teilnehmer auftauchen, die sagen, sie wären "RNBFRA-DC-Motor-links" muß was geschehen. Und vermutlich auch manuell, denn für sowas gibt's keine Computer-Logik.
Btw: Ragnar hat sich in der Wiki ausgetobt
https://www.roboternetz.de/wissen/index.php/RNcom_Schicht_1
Muß ich mir mal genau durchlesen, damit ich mitreden kann.
NumberFive
10.03.2006, 13:48
dann last uns doch einfach noch ins level 0 ein bauen das nicht + plus hinter einander übertragen werden dürfen son das das zweit dann maskiert werden muß dann sollte es die Funkmodems nicht mehr stören.
Der Halbduplex betrieb hatte halt nur gedacht man könnte dann die Daten einfach im SerialServer buffer bis die Leitung frei ist.
Aber wenn ihr erst mal testen wollt ist das auch gut.
Gruß
.... ins level 0 ein bauen das nicht + plus hinter einander übertragen werden dürfen...
Ich habe das gerade mal mit Testdaten geprüft.
Da brauch man nichts zu machen, denn es muss vor dem +++ eine kleine Pause kommen. Ich hab das so auch im Handbuch zu einem Modem gelesen habe.
+++ -- Escape Character Sequence. After you have connected to another modem, you may need to return to command mode to adjust the modem configuration, or more commonly, to hang up. To do this leave your keyboard idle (press no keys) for at least one second, then press "+" three times
Das sind meine Testdaten, übertragen mit Hyperterm im Modus "Textdatei senden". Mein Funkmodul RT868F4 geht damit nicht in den Command-Modus.
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbb
++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++
cccccccccccccccccccccccccccccccccccccccccccccccccc cccccccccc
dddddddddddddddddddddddddddddddddddddddddddddddddd dddddddddd
+++xxx+++xxx+++ +++ +++ +++ +++ +++ +++ +++
Test Test Test Test Test Test Test Test Test Test Test Test
marvin42x
10.03.2006, 16:17
Hier die Beschreibung des Funkmoduls RT433F4:
Mit Registerbelegung
http://www.robotikhardware.de/download/rt433f4.pdf
Hier Easy-Radio:
http://www.robotikhardware.de/download/er400_d.pdf
Da diese Module Kanalwechsel, Sendeleistung und Baudrateneinstellungen und zum Teil Emfangsstärkeinformation unterstützen. Wäre es zu überlegen sie als aktive Komponente zu betrachten die zur Navigation und zum Übertragungsmanagement gehören. Sprich irgendwer möchte die Dinger auch on the fly bedienen wollen. Also wegen meiner erstmal ausmaskieren aber endgültig wahlweise ansprechen können.
Ich würde gerne mittesten aber meine zicken bös mit mir rum. Ich hab denen schon gesagt, wenn sie so weiter machen kommen sie ins Heim.
@Vogon :
müssen wir nachlesen ob das für die anderen Funkmodule auch gilt, wäre ja schön.
Netter Gruß
NumberFive
11.03.2006, 08:25
wenn ich den Post von Vogon richtig interpretiere sollte den funkmodems uns protokoll nix aus machen da ja nie +++ am anfang steht.
Programieren Hier alle eingenlich den AVR mit Bascom ?
Ragnar hat wohl heute nacht die Seite aktualiesiert jetzt wird es echt interessant. warum er das Level für TCP neu definieren will ist mir zwar noch nicht klar aber das werden wir bestimmt bald lesen können.
Mit Seiner Schicht 1 könnte ich ganz gut leben aber warum hat er immer noch die Länge drin ?
Was ich ein bisschen schade finde ist das er da so runter definiert aber es nicht bespricht. Jetzt sieht es so aus als währe es besprochen sache.
Mal sehen was da noch so kommt.
Gruß
Morgen !
Also gut, die +++ sind für uns mal gestorben, und die 1/2 duplex Funkerei klären wir noch.
Nachrichten über TCPIP-Stream müssen vorn eine Länge haben, 16 Bit sind verbreitet, also solle es so sein. NEtwork Order oder nicht können wir noch klären, is mir so oder so recht.
Ohne die Länge wirst du unglücklich, weil du sonst bei IP nie sicher weißt, wo ein (daten) Paket anfangt oder aufhört oder vielleicht auch noch im nächsten Block fortgesetzt wird (heißt ja auch "STREAM").
Eigentlich betrifft das den "Level-0" bei IP, ("level-0" aus unserer Sicht)
BASCOM programmieren sicher nicht alle. Aber wenn es sich dort gut einbauen läßt, geht's mit allem anderen allemal. Im Gegensatz zu Bascom gibt's für GCC schon mindestens 27 Betriebsystem-varianten, dort brauchen wir nur die RNCom-Standards modularisieren, wenn überhaupt.
Ich werke gerade daran, auch für den COProzessor von der RNBFRA eine adaption zu machen und die dann in das "RNSX"-Servo Programm einzubauen.
Ist ein guter Test: 2 unabhängige µC und 1-2 PC. Wenn das geht, geht alles.
Ob man sich die PICs auch zur Brust nehmen soll, werden wir sehen. Da gibt's eigentlich ausser Assembler nicht so einen verbreiteten Standard wie Bascom.
...müssen wir nachlesen ob das für die anderen Funkmodule auch gilt, wäre ja schön...
Habe bei deinem Link zum Easy-Radio mal nachgeschaut.
Dort lese ich:
Die Programmier-Software sendet Text-Mitteilungen an die Module und diese Aktion kann über ein Terminalprogramm ....
Befehl Funktion Wert
ER_CMD#U1 UART Datenrate 2400
ER_CMD#U2 4800
ER_CMD#U3 9600
....
ER_CMD#P0 HF-Sendeleistung 1mW
....
ER_CMD#C0 Kanal 0 433.23 Mhz
...
Das ist also anders. Ob das mit dem Zeitverhalten auch so ist sollte jemand der diese Modula hat mal testen.
Da sie ja zur Datenübertragung gebaut werden liegt es ja nahe es so zu machen. In der DOC steht dazu nichts.
In der DOC zum RT433 und RT868 habe ich aber auch nichts dazu gelesen.
Was ich bei Easy geucht und nicht gefunden habe, waren konkrete Angaben zum Zeitverhalten bei Richtungsumkehr.
Ich glaub', Marvin hat ja das Zeugs, da werden wir schon noch dahinterkommen.
EDIT BTW, es gibt ja auch noch IR und anderes Teufelszeugs
marvin42x
11.03.2006, 11:58
Ich habe 2 Rn-funkmodule ausgestattet mit den Funkmodulen RT868F4 (FM-868...870MHz). Das sollten die gleichen sein wie die von Vogon.
Hatte gestern noch mit Ihnen in Freundschaft gesprochen aber konnte keine Einigung erzielen, jetzt kommen sie ins Heim für schwer erziehbare Funkmodule.
Wenn sie dann zurückkommen kann ich mich da rann machen.
Ich gehe mal gefühlsmäßig davon aus das die Erbauer der Funkmodule das Problem auch kannten und ein entsprechendes Design gemacht haben, aber man wird sehen…., den Weihnachtsmann soll’s ja auch nicht geben.
Netter Gruß aus der schon wieder eingeschneiten Hauptstadt
Ps. @PicNick: Sehr löbliches Tun, Deinen rn_server auf Port 42 horchen zu lassen ;-).
NumberFive
11.03.2006, 12:04
Also da wir unter der Paket grösse von tcp bleiben und ich ja ein start zeichen und ein eindeutinges ende Zeich habe glaube ich nicht das die länge so wichtig ist das sag mir zu mindestens mein erfahrung bis jetzt. aber es soll so sein.
dann würde der Tcp Stream also so aus sehen:
BYTE[0] = CTL_C_STX;
BYTE[1] = length Teil1
BYTE[2] = length Teil2
....
BYTE[N] = CTL_C_ETX;
die länge kommt das so rein
WORD Len;
memcpy(&Leve0[1],Len,2);
Ok ?
STX u. ETX brauchen wir bei IP nicht, natürlich auch kein Stuffing.
Am Einfachsten also (Längen-angaben immer daten-Netto)
Länge LSByte
Länge MSByte
Daten
memcpy is ok so.
:mrgreen: 42 is eine gute Wahl, denk ich. Etwas größer als 41 und trotzdem immer noch kleiner als 43 :mrgreen:
EDIT: btw: Meine IP send/receive haben so eine Art Auto-detect Mechanismus (optional).
Bei der ersten incom-Message probier ich die Varianten aus (Länge oder nicht, networkorder oder Intel) Wenn eins davon paßt, gilt das dann für die Dauer der ganzen Connection. Dann wird auch in dem Format zurückgeschickt.
Ein schönen eingeschneiten Sonntag wünsch' ich !
Kurz vorweggeschickt: Ich mach seit '92 praktisch nix anderes als Applikations-kommunikation von verschiedenen Plattformen (DEC-Alpha/VMS, IBM, PC, Sun, wasweissich) mit DecNet, IP, X25, Mq-Series, 3270, Wählmodem, Telnet, POP und Mail, (kermit *haha*), blabla.
Ich sag das nur, damit ihr wißt, daß ich eine gute Vorstellung habe, was mich einmal in der Hölle erwarten wird.
Und ich hab auch kein Problem, noch ein paar Layer zu definieren.
Aber im Zusammenhang mit µC, Robotern und harmlosen Amateur-Entwicklern bin ich mir nicht sicher, ob wir nicht das Ziel aus den Augen verlieren, nämlich ein einfaches Vernetzungssystem für PC- u. µC-Programme.
Wenn wir uns da was ausdenken, was dann aber nur abgefahrene Kampf-programmierer begreifen, geschweige denn anwenden können, halt ich das bei aller Perfektion für danebengeschossen.
Wir haben jetzt eine gute UART-Level-0 Verbindung, und mehrere Ansätze von Programmen, die von da einen Übergang zu IP bewerkstelligen können.
Wir können µC seitig mal Bascom recht gut einbinden.
Und User-programm connections zu IP können wir noch konfektionieren (mit DLL oä), aber erfinden brauchen wir das nicht mehr, das gibt's schon.
Im Grund fehlt uns doch nurmehr das Konzept, mit welchen angaben und woher hat er die findet jemand sein Ziel, ohne bei jedem Umstecken sein Programm frisch zu kompilieren ?
Hallo erstmal, ich habe mich die letzen Tage im Wiki rumgetrieben und ein paar Gedanken/Vorschläge niedergelegt, insbesondere für die Schicht 1:
https://www.roboternetz.de/wissen/index.php/RNcom_Schicht_0
https://www.roboternetz.de/wissen/index.php/RNcom_Schicht_1
https://www.roboternetz.de/wissen/index.php/RNcom_Schicht_2
Ich hoffe das ist ausreichend flexibel um uns nichts zu verbauen, gleichzeitig aber noch nicht zu kompliziert. Dynamisches Routing ist mit diesem Ansatz sicher möglich, trotzdem würde ich das ganze lieber noch etwas zurückstellen und momentan nur statisch routen.
@PicNick: Dynamisch Routen ist keine einfache Sache und ich erwarte nicht, dass Otto-Normalprogrammierer meine Seiten auf Anhieb versteht. Ich hoffe aber es ist trotzdem noch nicht zu kompliziert und gerade dies ist ein Teil von dem ich hoffe, ihn in einer Library verpacken zu können.
@PicNick: Betreffend der UART0-Spezifikation noch eine Frage:
Warum ist STX eigentlich als CTL_BASE+1 definiert, bzw. warum ist CTL_BASE+0 nicht genutzt ?
@PicNick:
Zwecks dem finden von Kommunikationspartnern: Prinzipiell spricht nichts dagegen, die Adressen innerhalb eines Subnetzes statisch zu vergeben. Wenn wir irgendwann einmal dynamische Adressvergaben haben, können wir immernoch einen Schicht3 Dienst einführen, der DNS spielt.
@Alle:
Warum eigentlich 2 Bytes für die Länge bei TCP-Stream Nachrichten ? 1 Byte müsste doch eigentlich reichen, länger als die maximale UART-Länge können wir sowieso nicht schicken.
ciao,
Ragnar
Tagchen ! Keine Sorge, wir schauen dir genau auf die Finger. Du schreibst keine Zeile in die Wiki, von der wir nix wissen :mrgreen:
Länge: weiss der Teufel, was sich die Router gegenseitig noch alles an Tabellen um die Ohren Hauen werden, was die Applikationen oder die UART garnicht zu sehen kriegen. Wenn wir 16 Bit definieren, brauchen wir uns darüber unser Leben lang nie mehr den Kopf zu zerbrechen. Vergeßt nicht, erst kommt die Länge, und dann erst Typ/adressen etc. d.h. es gibt keine Modifikationsmöglichkeit.
BASE + 1: kein Grund, der mir jetzt einfiele, das sind Hausnummern, Hauptsache, alle haben die gleichen. Gibt's einen Grund für eine Änderung ?
Dynamisch und begreifen: Nun, es kommt darauf an, was von der Sache beim Betrieb für den User spürbar bleibt, denk' ich. Ich kann das wahrscheinlich garnicht gut beurteilen.
marvin42x
12.03.2006, 17:25
Als Unerfahrener, (mit dem Risiko was falsch verstanden zu haben):
1. Erstmal ein einfaches System das niemanden/niefrauden überfordert und verfügbar ist.
2. Dabei die Möglichkeit für Wachstum nicht verbauen.
3. Erst im Folgeschritt Erweitern und verfeinern.
4. Ich glaube man kann ab und an auf die alten Programmier-Haudegen hören. Muss ja nicht zur Gewohnheit werden. :-)
Frage zur Wiki:
ragnar hat dankenswerter Weise schon eine menge Gedanken in die Wiki eingebracht.
Meine Frage:
Sollten wir etwas Neues in der Wiki erst dann RN-Com nennen wenn wir den Inhalt so beschlossen haben?
Davor würde es mir gefallen wenn es eine Diskussionsgrundlage genannt wird, an der Einigkeiten erarbeitet werde können.
Mit nettem Gruß
Solange es im Wiki im "Projekte" bleibt, haben wir noch Spielraum. Aber sicher sollten wir einen offiziellen Anstrich noch vermeiden. Das ist das dann wichtig, wenn es effektive Spezifikationen betrifft. Die derzeitigen Artikel sind ja in weiten Teilen nur Erörterungen, die kann ja eh' keiner anprogrammieren und zu kaufen gibt's auch noch nix.
Es ist mit gelungen, die Layer-0 Bascom-Library auch für den RNBFRA-CoProzessor zu adaptieren und hab' das gleich in das Servoprogramm eingebaut. Läuft jetzt so ab, daß der ATmega eine Message für die Sys-ID "S" (0x53) bekommt, das ist er nicht, also schickt er es einfach weiter. dahinter sitz der CoProc, der sagt juhuu, das zweite Byte der Adresse ist die Servo-nummer 1-10, und daher stellt er dieses Servo auf das Word ein, das er als Daten bekommt (600-2000).
Rücksenden kann er nicht, ist dzt. technisch problematisch, nur ein MAX da. Aber getestet hab ich's, vom programm her geht's.
Um die Servos auf der RNBFRA vom PC aus anzusteuern, brauch ich also auf dem Atmega selber garnix mehr.
Dzt. tu' ich mit dem RN-Server ein Servo von links nach rechts durchtickern. Toll *g*
Die Sache mir den Units bla bla ist für den kleinen 2313-er wahrscheinlich nix, soviel Platz ist da nicht, daß das viel sinn hat. Aber der Level-0 ist ja eh' auch extra zu betreiben.
marvin42x
12.03.2006, 18:39
@PicNick:
Da hüpft mein Kinderherz, wenn ein Servo hin und her macht.
Technische Frage:
Ich habe mein Board so gejumpert das der Mega32 zwei serielle Kontakte hat. Einmal zum Max232 und einmal zum CoProzesor.
Liegen bei Dir beide auf demselben seriellen Strang? Damit würde ja die Hilfsbrücke wie ich sie verwende entfallen?
Kann man das bei dir schon downloaden?
Mit ausgeprägtem Spieltrieb
M42x
Jetzt weiß ich nicht ? Ich hab das mit einem schrägen jumper so, daß der TX vom Atmega32 sowohl zum Max als auch zum RX vom CoProzessor geht. Also genauso wie bei allen meinen Backx Programmen.
Ich kann das Zeugs schon morgen zum Downloaden herrichten, wenn du magst, der RN_Server ist halt noch ein Dödi, volle Baustelle.
Mir fällt ein, ich werd morgen dicke Luft haben.
Ich stell meine augenblicklichen Schätze mal da rein
Message f. Servo
byte..byte..byte.byte..byte..WORD..byte..byte
STX 0x53 0x01 0x00 0x00 0x0nnn BCC ETX
Word : 600 - 2000 Servo position
Message f. LED
byte..byte..byte.byte..byte. byte..byte..byte
STX 0x42 0x01 0x00 0x00 0xnn BCC ETX
0xnn Bits für die LED
marvin42x
12.03.2006, 19:52
@PicNick:
Ich such mir hier einen Höcker. In diesem pdf wird das beschrieben:
Servotreiber RNS1.pdf, mit bild.
dazu gibt es ein Demoprogramm von Frank, wo beide varianten anprogrammiert sind:
Beispiel Prog Servo ser.bas
sorry ich finde den Link nicht aber wenn du willst maile ich es Dir.
Kinderherz: wenn Du mir was zum spielen reinstellst sage ich nicht nein.
Netter Gruß
Edit: Uups... da war ja schon wieder was neues... Danke :-)
Noch ein Edit: Da muss ich NumberFive zustimmen. Das Benachrichtigungssystem per Mail funktioniert oft nicht.
Das RNS1 ServoProgramm hilft uns nix, das ist vom Frank und weiß nix von unserem RN-COM
Ich hab vor einer Zeit das RNSX bereitgestellt, das ist fast das Gleiche + ein paar Features.
FÜr RN-COM wäre jetzt das RNSXNET interessant, und um das geht es.
marvin42x
13.03.2006, 09:00
Ja, das Servoprogramm ist nichts für uns. Mir ging es um den Umstand das es eine Variante gibt die den Reseveport des board als serielle benutzt. Im Demoprogram kann man dann schön sehen "print #2" .
Zusammengefasst: es gibt zwei Möglichkeiten.
1. den jumper über kreuz = gemeinsame serielle
2. patchkabel auf Reserveport = privates seriell zwischen den beiden controllern.
Eines Tages finde ich das pdf hier in der Riesenseite noch.
Netter Gruß
NumberFive
13.03.2006, 09:24
holla jetzt hänge ich mal ein Wochenende nicht hier rum und dann passiert so viel.
Warum das TCP und das Level0 bei TCP so unterschiedlich der sind ist mir noch nicht ganz klar ?
Wenn ich das hier alles richtig verstanden habe Könnte ich ja mal ein versuchen machen für die Servo an stuerung auf dem RN Borad zu Basteln. So was mit meiner dll und VB weil das hier doch wohl die Verbreites PC Sprache zu sein Scheint. Habe zwar kein Board hier aber wenn die Spezifikationen passen sollte es trotzdem gehen.
OK mein Klassen structur muß ich ordendlich umbauen aber das war wohl klar.
Was haltet Ihr da von wenn ich dem RN-Com NetworkLayer noch ein TCP Port verpasse auf den man sich Connecten kann ? So hätte mal dort dan zwei Ausgänge TCP und Com über die DLL ?
Ist nicht die Antwort auf alle Fragen 42 ?
@ragnar die Links sind mit Action=Edit ist das so gewohl oder nicht ich finde das ein bissle störent. Weil ich ja nur lesen will und nicht editieren.
marvin42x
13.03.2006, 10:25
Seriel rnbfra:
Sorry, na endlich gefunden:
https://www.roboternetz.de/phpBB2/viewtopic.php?t=1995
Edit: @NumberFive: Das mit der 42 siehst Du ganz richtig.
Netter Gruß
marvin42x
14.03.2006, 08:50
@NumberFive:
Einen TCP/IP-Port am RN-Com NetworkLayer schadet ja nicht wirklich oder? Ich bin ja immer für Optionen zu haben, manchmal staunt man wozu das gut ist.
Einen Servo versuchsweise per Spezifikation anzusteuern finde ich gut, sollten wir mal machen. Ich habe alles um das laufen zu lassen. Wir können das auf kurzem Weg über icq mal durchtesten.
@PicNick:
Ich jumper mein Board dann mal um wie Du es hast.
Netter Gruß
@Marvin42x: Du freust Dich, wenn sich Servos bewegen ?
Dann hab ich was für dich.
In der Zip file ein RN_SERVER.EXE und ein RN_CLIENT.EXE
1 Server starten, Open com, Open IP
2 Client starten, IP-Adresse einstellen , Open IP
Slider verschieben und Freude haben *g*
Von Layern und Routing-definitions ist das weit entfernt, aber ich will ja auch mal was ticken sehen.
marvin42x
16.03.2006, 20:39
@PicNick: Völlig richtige Einschätzung der Lage :-)
Schicksalshart ist, dass ich gerade jetz weg muss wo es lustig wird.
Freu mich immer über kleine Abstecher vom vernünftigen Weg der Rationalität.
Netter Gruß von jemandem der vermutlich weit nach Mitternacht noch schnell mal rumfummeln wird.
marvin42x
17.03.2006, 13:08
@PicNick:
Ich hätte da gern mal ein Problem.
seit der letzten Version vom 12.3. kann ich das sys.bas nicht mehr compilieren. Ich hatte erstmal versucht der Sache auf den Grund zu kommen weil die Version mit den blinkenden LED problemlos geht, auch jetzt noch. Gibt es da einen Unterschied der mir beim Suchen weiterhilft?
Vers. Bascom 1.11.7.8
Die Meldung, die NUR bei der letzten Version ab 12.3 auftritt.
Fehler: Selected chip and targed chip do not match ATMEGA32<>AT90S2323
Moment, die Meldung kommt eigentlich vom Brenner, wenn
$regfile="m32def.dat" (sys.bas) und das, was auf dem Programmier-kabel draufhängt, nicht zusammenpassen.
Bist du sicher, daß du auf dem richtigen Stecker steckst ?
was sagt er, wenn du beim Brenner auf das Fragezeichen klickst ?
marvin42x
17.03.2006, 14:03
@PicNick:
Andere Programme macht er, angefangen mit Versionen meiner eigenen Programme von früher, bis einschließlich zur Demo mit blinkender LED. Also früher 12.3.06.das kompiliere ich und übertrage es wie gewohnt und alles arbeitet wie es soll. Also Hardware, Stecker Schnittstellen, alles tut.
Ja, denke ich auch so, das ist eine Brennerfehlermeldung. Die Ursache ist nach meiner bisherigen Recherche das er nix vernünftiges zum brennen findet. Wenn ich nur den oberen Programmteil, der so allgemeines enthält kompiliere bekomme ich keine Fehlermeldung. Was ich als erstes gerne wüsste, ob das ein lokales Problem ist was nur mich betrifft.
Das angekündigte Fragezeichen entzieht sich erfolgreich meiner Entdeckung. Den Chip identifiziert der Brenner tadellos, falls das gemeint ist?
Ich würde das Problem erstmal auch hinten an stellen wollen wenn Du so gut wärst mir das sys Hex noch reinzustellen, dann könnte ich mich an dem Rest freuen und der Sache nebenbei auf den Grund gehen.
Netter Gruß
Eventuell probier mal, die Datei SYS.CFG zu löschen, vielleicht macht ihn da was nervös
Das Fragezeichen in der Mitte hab ich gemeint
marvin42x
17.03.2006, 15:11
@PicNick:
Na gut, ist ein Fragezeichen, ist aber echt gut getarnt.
So, und nun freu freu, hüpf rum, ähem macht man ja in meinem Alter nicht mehr. Also, alles tut und ich bin Herr über 10 Servos :-)
Du hast in myrncom.bas geschrieben: $lib "mybuffer.lbx" , "myrncom.lib"
Besser ist Du schreibst: $lib "mybuffer.lbx" , "myrncom.lbx"
Die alte Schreibweise stärkt auf der einen Seite mein Verständnis der Programiererei auf der anderen Seite habe ich den armen Compiler verdächtigt.
Netter Gruß
Ps. Danke für das schnelle Hex
LBX /LIB oops ! Ich werd' das gleich ausbessern.
Ich geh' nun daran, PC-seitig das Ganze ein wenig zusammenzuräumen und gleichartigen Schmus zu modularisieren. Is halt alles ein rumgefummel.
Schon bei dem Servo-Client sieht man, wo's fehlt:
Jetzt nimmt er ja einfach alle Servos unter seine Fittiche, das sollt man aber flexibler konfiguriern können.
Man sollte irgendwelche positionen als ausgangspunkt einstellen und speichern können, und natürlich auch abrufen.
Andererseits sieht man auch, wie leicht man noch einen 2313 dazuhängen könnte und mit einer zweiten Client-Instanz hätt man schon 20 Servos im Griff, ohne groß zu programmieren.
Naja, man werkt halt rum .
marvin42x
17.03.2006, 15:58
Stimmt, durch die neue Architektur ergeben sich interessante neue Optionen. Ich finde das neue System steht dem Board gut. Sehr transparent, wie ein gutes Sommerkleid.
Netter Gruß
...transparent....Sommerkleid.
o lala !
So. wieder Nachschub, insbes. für Marvin42x.
Das ist sozusagen mein Prototyp-Set, an dem ich die Möglichkeiten und Erfordernisse von Verteilung und dyn. oder statischem Routen überprüfen kann.
RNSXNET.HEX für RNBFRA-CoProzessor
SYS.HEX für mega32 u. RNBFRA
RN_SERVER.exe (PC) als Port Com <> IP
RN_CLIENT.exe (PC)als "User-Applikation", die die Servos steuert
RN_ADC.exe (PC) das die 8 ADC-Sensordaten empfängt und anzeigt
Alles äußerst anspruchslos.
Jede der x Applikationen(nicht eingeschränkt) sendet an den RN_SERVER, der es zusammenstuffed und mit STX u. BCC u. ETX an den µC schickt.
(Adressen, die der MEGA nicht kennt, werden einfach zurück/weiter geschickt, dadurch kriegt sie auch der CoProzessor).
Umgekehrt geht alles vom µC an alle IP-Kunden, die grad connected sind
RN_ADC fischt sich die ADC Werte, die der µC produziert, heraus und zeigt 0-1023 auf Progress-Bars an.
RN_CLIENT interessiert das alles nicht, aber er schickt dafür messages von Sliders an die 10 Servos.
Kommunikation zwischen den PC-Clients findet dzt. nicht statt
Die eigentliche Message besteht (prototyp)
Zieladr1 Zieladr2 Absender1 Absender2 Daten (byte oder short, je nach message)
An dem Servo-Client sieht man, daß es für solche Geräte eine Art Reservierung geben müßte. Wenn man 2 solche Clients startet, verstellen sich die gegenseiting natürlich die Servos. Da braucht's eine Regelung.
marvin42x
18.03.2006, 17:11
@PicNick:
Freue mich, dass das jetzt so sichtbar wird, warste ja fleißig
Habe leider wieder Familienkrach mit meinem Compiler. Jetzt hat er sich drauf verlegt nichts zu sagen, so zu tun als kompiliere er dann aber nichts zu machen und sich ohne Fehlermeldung davonzuschleichen.
Habe im schon ein altes sys.bin untergeschoben, das soll helfen sagt man aber dann nimmt der Brenner halt das alte sys.bin und brennt es brav.
Dein sys.hex mag mein Brenner nicht brennen weil er sagt da wäre ein Unterschied und Brenner die Unterschiede sehen sind recht ablehnend.
Du siehst alles in vollem Gange, das einzige was bei mir im Moment klappt sind die Türen.
Ich komm aber schon noch dahinter, keine Bange. Dein Compiler scheint besser erzogen als meiner.
Kann heute leider abends nicht mehr dran arbeiten, erst morgen.
Netter Gruß
Klingt ja sehr seltsam. Du mußt mir mal deine Konfigurationen verklamüsern. Schon mal mit dem Pony zu brennen versucht ?
marvin42x
18.03.2006, 17:47
Was mich wundert, dass Dein Compiler alles gnadenlos frisst und ein Binärfile draus macht, Nach dem Motto ich "weis schon was du meinst".
Du hast bestimmt ne KI-LIb drinn :-)
Ponny habe ich noch nicht probiert.
Das Hex was du mir als erstes geschickt hattest, hat er auch mit derselben Begründung nicht gebrannt, da war aber auch der Haken mit de lib drin, was Deinen Compiler aber scheinbar nicht sonderlich schreckt.
Ich vermute mal, dass es eine einfache Erklärung gibt und das am Ende alles gut läuft.
Das Pony werde ich aber trotzdem morgen mal ausprobieren.
Netter Gruß
Gut, das ist klar, bei mir findet er ja auch die .LIB und die .LBX, daher hab' ich's ja auch nicht gemerkt.
Und mein Kompiler/Computer weiß, wenn er nicht spurt, gibt's eins auf die Glocke.
(Ich hab' ein Bild vom Schrottplatz als Drohung eingescannt, seitdem ist er brav)
Sowas erinnert mich an ein Kindkeitstrauma: Ein Spielzeug am Heiligabend kriegen, aber keine Batterien drin, und zwei Feiertage vor der Nase, wo alle Geschäfte zu sind. *räusper,egal,naja*
marvin42x
19.03.2006, 21:36
@PicNick:
So, nachdem ich nun einen Tag mit der Betrachtung von Compilerunverträglichkeiten verbracht habe, habe ich das zur Seite gelegt. Habe mir ein Pony geschnappt und meinem Mege32 das Gehirn gewaschen. Mein Pony sagt zwar es kenne keinenMega32 aber wenn ich will ist es ihm egal und es schreibt dem der da dran hängt das was ich will ins Hirn, egal wer es ist und was es ist.
Womit ich jetzt noch vor Ende der Feiertage an Batterien gekommen bin, egal was Opas Herzschrittmacher dazu sagt.
Was jetzt wirklich schön funktioniert ist Deine kleine Programmfamilie.
Sieht so aus das ich langsam Rasenmäherblätter kaufen gehen muss, damit ich auf der Hardwareseite nicht ins Hintertreffen komme. Ich finde das total entspannen wenn alles so rund läuft, habe schon mal paar Sensoren rangehängt und das alles auf einer Servogetriebenen Halterung hin und her und rauf und runter geschwenkt und die Sensorwerte beobachtet. Sieht alles sehr plausibel aus.
So, aber jetzt gehe ich erstmal ins Internet, schnapp mir ne Waffe und rette die Welt, irgendjemand muss das ja machen.
Netter Gruß
Ps. Könntest Du mir mal Dein Bild vom Schrottplatz schicken? ;-)
Probier' mal, vielleicht hilft es ja
PicNick: Wie kommst du an das Foto von meinem Bastelzimmer ? :-k
Ich bekomme keine Verbindung zwischen RN_SERVER, RN_CLIENT, RN_ADC.
Woher haben die die IP-Adresse, die ist immer auf 172.31.33.122. Wenn ich die änder in meine eigen geht aber auch nix, das Programm sagt nur Err. [-(
Dass zuerst auf dem Server "OPEN" gesetz werden muss is ja klar, denk ich.
Das 172.31.33.122 is von mir, das mußt du für dich ausbessern, auch klar. Ich muß das erst einbauen, daß er die lokale Adresse gleich anbietet.
Eine Tücke: hast du zwei Netzwerk-karten ?
Sag mal "c:\>ipconfig" subnet mask ist ok ?
1 Wirf' mal den Server an, sag IP-Open -->
Jetzt sollte der server "open" sagen.
2 Internet explorer, sag ihm "http://nnn.nnn.nnn.nnn:42
Jetzt sollte der server "accept" sagen.
3 Internet explorer "abbruch"
Jetzt sollte der server "disconn" sagen.
EDIT: beliebt: Beistriche statt Punkt in der Ip-addresse
Meine IP bekomme ich vom DSL-Router 192.168.1.x
Der ipconfig meldet IP . . . 192.168.1.5
Subnet . . . 255.255.0.0
StadardGW . . . 192.168.1.1
Damit die IP nicht herumvagabundiert ist sie im Router an der MAC angenagelt.
Mein IE sagt: http://192.168.1.5:42/
Die Seite kann nicht angezeigt werden.
mach ich das mit FireFox, kommt:
Fehler: Port aus Sicherheitsgründen blockiert
Die aufgerufene Adresse fordert einen Port, der normalerweise nicht zum Browsen im Web verwendet wird. Die Anfrage wurde zu Ihrem Schutz abgebrochen.
Im RN_Server wechselt der Status im Fenster "IP-Port" wenn ich den Haken bei "On" mache auf Open.
Bei "Received" bleibt aber alles leer, auch im Logfile "RNComm.txt" taucht nicht ein Zeichen auf.
[-o<
Gut, dem Server kannst du ja ein anderes Port angeben, also auch 80
oder 8080 (1 < 65535), muß nicht 42 sein.
Fenster leer: klar, wenn keiner hinkommt.
Könnt' sein, daß sich irgendeine Sicherheitseinrichtung wichtig macht.
mmmhh. Hat wer eine Idee ?
PicNick:
Jetz komm ich aber auch ins Grübeln.
Firewall auf dem XP kann ja nerven ! Abschalten hat aber an der Situation nichts geändert.
Die Umstellung auf PortsNr. 8081 hat FireFox den Sicherheitsmeldung abgewöhnt, aber ansonsten - immer noch nix.
Misteriös finde ich auch das auf der COM-Verbindung anscheindend auch nichts ankommt. An einem Porttester sehe ich aber das beim Open die Handshake-Signale wechseln.
NumberFive
20.03.2006, 18:38
@PicNick
Machst du ein bind für den sever ?
@Nr-5: Logo, das ganze übliche Brimborium. Hab ich auf zig-Maschinen am Laufen. Bei Marvin42 geht's ja auch. Da steht irgendeine Schweinebacke auf der Leitung drauf.
Ich so einer Lage schick' ich halt immer unsere Netzwerker in den Krieg, die machen das gerne, meist sind sie ja auch schuld daran.
NumberFive
20.03.2006, 19:34
20.03.2006 19:27:41,000 CMain Neue Daten <A9>S<01><00><00><AB><B2><05><FD><AA>
20.03.2006 19:27:41,000 CMain Neue Daten S<01><00><00><A2><05>
Hier sagt meiner das die Prüfsumme nicht stimmt.
Wo ist der denk fehler ?
bei mir tut es auch auch mit zwei Netzwerkkarten.
Habe mal deinen Server gegen meinen laufen lassen serial.
Sieht so weit gut aus bis auf das Obere Problem rechtes du das ab mit ?
Gruß
Soda. Das ist eine Version von RN_SERVER, der zeigt nach Open die vollständige IP-addresse an, und man könnte sie auch eingeben. (vor open natürlich)
Unter der adresse MUSS er erreichbar sein, das gibt's ja nicht.
EDIT Hab aber gerade gesehen, das meine Firewall fragt, ob der da ein Port aufmachen darf. (auf einem anderen PC)
Noch'n EDIT: Wenn ich da ein Port aufmache, könnte da wer über das Internet zugreifen ?
Huraaaaaa ! Jetzt funzt.
Der neue RN_Server meldet sich jetzt ohne IP-Nummer. Da habe meine 192.168.1.5 eingegeben.
RN-Client und RN-ADC gestartet und IP eingegeben und schon geht alles.
Auch auf der COM sind Daten unterwegs.
Kann ich die Baudrate für die COM irgendwo einstellen - möcht mal den ASURO beglücken ?
Kaum macht man's richtig, geht's auch schon. tz, tz.
Baudrate is im Moment noch nicht, du siehst eh' die Menuepunkte, das is noch Baustelle .
RN_server: Gibt testweise einmal keine IP-Nummer ein und drück nur auf open. Würde mich interessieren, welche Ip-adresse er gehabt hätte.
(Übrigens 127.0.0.1 bei server und client geht auch, zumindest bei mir)
... welche Ip-adresse er gehabt hätte.
Ja, er findet jetzt die 192.168.1.5 O:) und den Rechnernamen meldet er auch ! 8-[
127.0.0.1 geht bei mit auch. :-$
Wenn ich da ein Port aufmache, könnte da wer über das Internet zugreifen ? Ich glaub schon das es geht. Aber wenn ich deinen Roby steuern soll möcht ich auch einen Videostream sonst fahr ich dir den eventuell an die Wand. [-o<
marvin42x
20.03.2006, 23:24
Ist aber schade, hier geht die Post ab und ich bekomme keine Nachricht.
Ich balge mich gerade noch mit meinem Compiler, hab mal nenn ältern angeworfen, der behauptet das die mybuffer lib already registert ist, klammer ich sie aus findet er nix. Wenn der nicht bald hin macht bekommt er das Bild
Hätte euch sagen sollen das ich ohne Eingabe von einer IP Adresse alles am laufen habe. Ich dacht ich hätte was falsch gemacht mit meiner IP und war froh das es ohne läuft.
Ich hatte noch versucht NumberFives Komponente mit einzubeziehen aber das ging noch nicht.
Netter Gruß
Edit: Mit dem neuen Server läuft es auch bei mir mit IP-Adresse
NumberFive
21.03.2006, 01:27
@PicNick
hast due meine Frage überlesen ?
wie sieht den dein TCP Protkoll aus vielleicht kann ich ja ein gateway bauen.
Gruß
Also, ich mach mir einen Socken
AF_INET, SOCK_STREAM, 0
dann bau ich mir die "sockadr_in" mit family AF_INET und entweder hostbyname oder inet_addr, je nachdem
mache "bind()" und dann noch "listen()"
wenn einer connectet, mach ich accept() und den nächsten listen()
Dann erwarte ich eine Nachricht vom connector, die mit "RN" beginnt, ab dann isser dabei
Ich hab bei den daten immer 16-Bit Länge im intel-format dann die Daten
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_Vermittlung#Prototype
NumberFive
21.03.2006, 08:08
20.03.2006 19:27:41,000 CMain Neue Daten <A9>S<01><00><00><AB><B2><05><FD><AA>
20.03.2006 19:27:41,000 CMain Neue Daten S<01><00><00><A2><05>
Hier sagt meiner das die Prüfsumme nicht stimmt.
Wo ist der denk fehler ?
bei mir tut es auch auch mit zwei Netzwerkkarten.
Habe mal deinen Server gegen meinen laufen lassen serial.
Sieht so weit gut aus bis auf das Obere Problem rechtes du das ab mit ?
Gruß
Wenn wir jetzt noch das problem lösen versuche ich mich heute abend mal an dem Gateway.
@marvin42x Hat du mal meine SerialServer an das Borad gehängt ?
Gruß
Mit AB meinst du das Prefixzeichen ? Nein, die Prüfsumme ist nur aus den Netto-Zeichen und auch BEVOR beim Prefixen 8 addiert wird.
das war ja im Original: (S=<53>)
<53>XOR <01>XOR <00>XOR <00>XOR <A2>XOR <05> ----> BCC:F5
sollte dann werden
<A9><53><01><00><00><AB><B2><05><F5><AA>
marvin42x
21.03.2006, 10:13
@NumberFive:
Mit der letzten Variante von sys.bas noch nicht. werde ich heute nachmittag machen. Davor hatte ich schon alles von Dir am laufen, einschließlich seriellen Server. ich kann jetzt aber nicht sagen, ob die laufende Datenübermittlung an der Seriellen vollständig gestimmt hat, muss ich noch mal überprüfen. generell hat er aber gesendet und verteilt. Du kannst mich auch über icq kurzfristig ansprechen wenn wir was am realen Board testen wollen.
Netter Gruß
NumberFive
21.03.2006, 13:26
@PicNick
dann hat ja mein Programm richtig reagiert.
der String kam nämlich von deinem RN_Server.
So ist Testen nicht gerade einfach.
Gruß
marvin42x
21.03.2006, 15:37
@PicNick:
Kann sein, dass ich auf der nach oben offenen Lästigkeitsscala bereits den Status „Stubenfliege“ erreiche aber ich weis immer noch nicht warum wir das nicht so machen:
Zitat Frank:
Nicht immer möchte man jedoch die Servo-Befehle ständig auf der normalen RS232 übertragen, schließlich braucht man diese Schnittstelle eventuell auch für andere Dinge. Auch dafür gibt es eine Lösung. Beim RNBFRA-Board gibt es einen Pin auf dem Roboternetz-Bus der als Reserve deklariert ist. Wenn dieser Pin mit einem Pin von JP16 verbunden wird (kann man über steckbares Kabel erreichen), dann kann man dafür eine unabhängige zweite RS232 nutzen. Klingt kompliziert ist aber kinderleicht.
So wüde in diesem Fall die Brücke aussehen. Die Ansteuerung erfolgt dann ganz einfach mit der Subfunktion ServoB. Siehe Bild
Pin D7 am Mega16 wird momentan nicht benutzt ist aber am RNB-Bus an PIN 47 rausgeführt (der als Reserve deklariert ist).
Dieser wird dann an den Rx Eingang des CoControllers angeschlossen.
Mit Bascom kann man jeden beliebigen Pin als Tx deklarieren, was wir mit
Open "comd.7:9600,8,n,1" For Output As #2
für den Mega16 tun, und so die Befehle an den CoController schicken können.
Netter Jruß
@Marvin: Output mit Software-UART würde ich gern vermeiden. Die Message für den Servo ist ~9Byte lang, d.h. der atmega ist bei 9600 Baud ca 9 mS lang bzw. bei 8MHZ für ~72000 Maschincycles blockiert.
marvin42x
21.03.2006, 15:52
Das ist ein echter Grund, dann versteh ich die Problematik. Würde ich als Hobbyprogramierer nie drauf kommen.
Netter Gruß
@NO-5:
Korrektur: das B2 muss ja vorher ein AA gewesen sein
(B2 - 8 = AA)
<53>XOR<01>XOR<00>XOR<00>XOR<AA>XOR<05> ----> BCC:FD
Also stimmt die Prüfsumme, die du gekriegt hast
53<A9><53><01><00><00><AB><B2><05><FD><AA>
marvin42x
21.03.2006, 20:06
So, ich habe mich ein wenig vergnügt und meinen Robi von Berlin Mitte und von Berlin Süd aus fernsteuern lassen. Was der Port 42 alles kann.
Messwerte waren auch überall verfügbar.
Das mag ja nicht zur Wahrheitsfindung beitragen aber Spaß hat’s trotzdem gemacht :-)
Netter Gruß
meinen Robi von Berlin Mitte und von Berlin Süd aus fernsteuern lassen.
Wie hast du das Problem gelöst? - :-b - Zusätzliche Kommunikation per Telefon?
Ich glaub schon das es geht. Aber wenn ich deinen Roby steuern soll möcht ich auch einen Videostream sonst fahr ich dir den eventuell an die Wand. [-o<
marvin42x
21.03.2006, 20:47
Mein Robi steht aufgebockt, die Räder berühren den Boden nicht. Ich habe aber eine Schwenkkamera drauf, kannste am Anfangsbild des Threads bisschen sehen.
Da sind außerdem Sensoren dran und die haben wir bewegt.
Wir haben auch mit Yahoo Messenger einen Videokonferenz geschaltet.
Wenn du die Web-cam an der Halterung anbringst kannst Du schon rumgucken.
Und wenn du das Notebook auf den Robi tust, das Wireles-Lan anwirfst, kannst Du schon fast rumfahren. Fehlen nur noch die Motorenansteuerungen. Nebenbei kann er dann noch Filesharing machen.
Netter Gruß
NumberFive
21.03.2006, 21:37
@PicNik
bitte helfe mir mal auf die sprünge.
<A9>S<01><00><00><AB><B2><05><FD><AA>
S<01><00><00><A2><05>
Habe ich das jetz richtig verstande du meinst das ich beim zurück rechen was falsch gemacht habe und so auf falsche prüfume gekommen bin.
TempBuffer[pos] = m_bLowLevel[x+2] & ~CTL_M_ADON;
das Heist die Zeile ist falsch. nur was oder hat sich was an den defintionen geändert und ich habe es nicht mit bekommen ?
warum 8 ?
#define CTL_M_MASK 0xF8
#define CTL_M_ADON 0x10
#define CTL_C_BASE 0xA8
#define CTL_C_STX CTL_C_BASE + 1
#define CTL_C_ETX CTL_C_BASE + 2
#define CTL_C_PFX CTL_C_BASE + 3
Gruß
Ragnar hat das mit dem addieren eingebracht und jetzt richten wir uns halt nach ihm und addieren beim prefixen die Zahl 8
also:
#define CTL_M_ADON 0x08
TempBuffer[pos] = m_bLowLevel[x+2] + CTL_M_ADON;
beim decodieren halt umgekehrt
NumberFive
22.03.2006, 07:41
Ok soll mir recht sein währe es dann aber nicht geschickt wenn wir diese defintionen auf eine wiki seite schreiben ?
dann habe ich und jeder ander was zum nach lesen wenn ein problem auf tritt und die da stellenung ist etwas Komprimierter.
Weil diese Änderung ist echt an mir vorbei Gegangen.
Das steht auch in der Wiki (spezifikationen) seit 8.3.2006
Is aber kein Vorwurf, in unser Panik mit den ganzen Layern geht sowas leicht unter.
NumberFive
22.03.2006, 11:26
Auf welcher seite habe gestern die mir bekannten druch gesehen weil ich halt vorher gucken wollte.
Gruß
NumberFive
23.03.2006, 08:03
@PicNick
würdest du mir den source zu Init der serial schnistelle schicken (PC) ?
ich suche da zur zeit nach eine Phänomen und ich finde es nicht.
Gruß
// Konstanden für Parity
#define P_NONE 0 // 0 = kein Parity Bit
#define P_EVEN 1 // 1 = gerade
#define P_ODD 2 // 2 = ungerade
#define P_SPACE 3 // 3 = immer 0
#define P_MARK 4 // 4 = immer 1
#define D_7BIT 0 // 7-Databits
#define D_8BIT 1 // 8-Databits
#define S_1BIT 0 // 1 Stopbit
#define S_1_5BIT 1 // 1.5 Stopbits
#define S_2BIT 2 // 2 Stopbits
int ComOpen (unsigned Nr,int Baud=9600,int Parity=P_NONE,int Stopbits=S_1BIT,int Databits=D_8BIT);
//************************************************** ***************************
// Öffnet eine serielle Verbindung
// Nr : Ist die Nummer des Com-Ports (0=COM1 1=COM2 ...)
// Baud : Ist die Bautrate
// Parity : 0 = kein Parity Bit
// 1 = gerade
// 2 = ungerade
// 3 = immer 0
// 4 = immer 1
// Stopbits : 0 = Ein Stopbit
// 1 = Ein/einhalb Stopbits
// 2 = Zwei Stopbits
// Bits : 0 = 7 Datenbits
// 1 = 8 Datenbits
// 7 = 7 Datenbits
// 8 = 8 Datenbits
// Ergibt 1 wenn eine Schnittstelle geöffnet wurde
int ComOpen(unsigned Nr,int Baud,int Parity,int Stopbits,int Databits)
{
static const int iPMode[]={NOPARITY,EVENPARITY,ODDPARITY,SPACEPARITY,MARKPA RITY};
static const int iSMode[]={ONESTOPBIT,ONE5STOPBITS,TWOSTOPBITS};
char cName[]="\\\\.\\COM1";
HANDLE hFile;
COMMTIMEOUTS sTo;
DCB sDcb;
if(Nr>=MAX_COM_PORTS)return 0;
if(bIsOpen[Nr])return 0;
cName[7]='1'+Nr;
hFile= CreateFile(cName,GENERIC_READ|GENERIC_WRITE,0,0,OP EN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);
if(hFile==INVALID_HANDLE_VALUE)
{
hFile=0;
return 0;
}
if(Databits==7)Databits=0;
memset(&sDcb,0,sizeof(sDcb));
sDcb.DCBlength=sizeof(sDcb);
sDcb.BaudRate = Baud;
sDcb.fParity = (Parity!=0)? TRUE:FALSE;
sDcb.fBinary = TRUE;
sDcb.Parity = iPMode[Parity];
sDcb.StopBits = ONESTOPBIT;
sDcb.fOutxCtsFlow = FALSE;
sDcb.fOutxDsrFlow = FALSE;
sDcb.fDtrControl = DTR_CONTROL_ENABLE;
sDcb.fRtsControl = RTS_CONTROL_ENABLE;
sDcb.fDsrSensitivity= FALSE;
sDcb.fAbortOnError = FALSE;
sDcb.ByteSize = (Databits)? 8:7;
if(!SetCommState(hFile,&sDcb))
{
CloseHandle(hFile);
return 0;
}
sTo.ReadIntervalTimeout = MAXDWORD; // 0 ms Read-Tomeout
sTo.ReadTotalTimeoutMultiplier = 0;
sTo.ReadTotalTimeoutConstant = 0;
sTo.WriteTotalTimeoutMultiplier= 1; // 1*2 ms Write Timeout
sTo.WriteTotalTimeoutConstant = 2;
if(!SetCommTimeouts((HANDLE)hFile,&sTo))
{
CloseHandle(hFile);
return 0;
}
hComFile[Nr]=hFile;
bIsOpen [Nr]=TRUE;
return 1;
}
NumberFive
05.04.2006, 08:08
Erst mal danke PicNick.
So ganz habe ich das Problem nicht gefunden aber hatte noch nicht wirklich die Zeit zu suchen.
@all
wie machen wir jetzt weiter ?
geht es über haupt weiter ?
Gruß
Hallo, No-5 !
Natürlich geht's weiter.
Level-0 hat sich soweit bewährt, da sind bei mir keine Probleme aufgetaucht.
Eine Ebene weiter oben würd ich ebenfalls prinzipiell alles lassen wie's ist.
d.h. die Nutzdaten bestehen aus
<16-Bit Zieladdr><16-Bit Sourceaddr> message-abhängige daten
Für IP ist vorne noch 16-Bit Länge
Alles, was von COM kommt, wird an alle IP -Clients geschickt
Alles, was über IP kommt, wird zu COM geschickt.
Allein damit läßt sich eigentlich alles machen.
Die sache mit dynamischen Routing tables hab ich derweil auf die Seite gelegt.
marvin42x
05.04.2006, 17:19
Frage:
@all:
Wollen wir als erstes Broadcasten oder porten, oder beides?
Mir als ahnungsloser würde Port etwas besser gefallen, warum auch immer.
Wir haben zZ. Einen seriellen Server für Broadcast und einen für Ports.
Wer macht jetzt was und welche Server nehmen wir erstmal?
Wo genau dockt UlrichC nachher an?
@NumberFive
Ich bin irgendwie noch nicht ganz im Bilde wie wir bis zu einem gedachten Visual Basic 2005 TCP/IP Port-Client Schulterschluss bekommen.
Welche Funktionen die Library die Du geschrieben hast anbietet.
Kann sein das ich das schon wissen müsste, aber sei so nett und helfe mir mal da kurz auf die Sprünge.
Was das serielle angeht, ich habe im Anfang dieses Threads einen schönen seriellen Porthandler vorgestellt, vielleicht hilf der Dir weiter. Der lief bei mir tadellos. Ich kann dir den auch mailen falls du brauchst.
@PicNick:
Neugier:
Hast Du schon Vorstellungen
a. welche Sensoren und Aktoren Du erstmal unterstützen willst?
b. In welschem Format ihre Werte im Einzelnen sein werden?
c. Welche Adressen Sie haben werden?
d. Haste mal was mit zwei Getriebemotoren ;-)?
@Johannes:
Gibt es an diesem Projekt etwas, was Dir gefällt oder nützt? Ich frag das einfach mal, weil die Entwicklung etwas andere Wege genommen hat als am Anfang gedacht war. Aber Teile eurer Grundidee meiner Meinung nach immer noch zu erkennen sind.
Netter Gruß
Ich habe auch noch Fragen:
@PicNick: Mich juckt es doch in den Fingern, denn ich möcht den ASURO mal dranhängen. Zum einen kann ich aber nicht auf die 1200 Baud umstellen, zum anderen vermisse ich eine Aufstellung der bisher festgelegten Spezifikationen.
Aus dem was ich jetzt sehe und gefunden habe:
Message f. Servo
byte..byte..byte.byte..byte..WORD..byte..byte
STX 0x53 0x01 0x00 0x00 0x0nnn BCC ETX
Message f. LED
byte..byte..byte.byte..byte. byte..byte..byte
STX 0x42 0x01 0x00 0x00 0xnn BCC ETX
Sehen die Daten auf der Leitung jetzt so aus:
Message Start
| Message
| | Message Checksum
| | | Message End
| | | |
.-----.-----. - .-----.-----.-----.
| STX | MSG | BCC | ETX |
'-----'-----' - '-----'-----'-----'
Wenn ich dass aus einander nehme erhalt ich das:
Message source Class
| Message source Ident
| | Message destination Class
| | | Message destination Ident
| | | | |
| | | | | Message
.-----.-----.-----.-----.-----. - .-----.
| SCL | SID | DCL | DID | MSG |
'-----'-----'-----'-----'-----' - '-----'
Eine Aufstellung/festlegung der "Class" :
0x53 := Servos ?
0x42 := Analog ?
NumberFive
07.04.2006, 07:33
@Vogon Meinen Serial Server kannst du auf 1200 Baud um stellen.
@all
Ich nehme jetzt PicNick's definition als gegeben an. Ich werde weiter hin das Multicast machen da ich so eine Gemeinsame Componete für die Rechner Komunikation habe. Und nicht so viele Ports offen lassen muß.
Es wird noch ein TCP Port das zu kommen der das Protokoll von Piknick untertützt damit man auch so was Connecten kann.
Damit VB ran kommt werde ich beispiele machen wenn es euch recht ist.
Wenn wir den ASURO ran bekommen das würde mir echt helfen weil:
https://www.roboternetz.de/phpBB2/viewtopic.php?p=172339#172339
Wie machen wir das mit den Classes Ok 0x53 und 0x42 sin weg ich bräuchte aber auch eine Oder zwei wie wollen wir so was regeln ?
Soweit
Gruß
pebisoft
16.04.2006, 10:22
geht wunderbar mit purebasic.
habe eine grafische oberfläche mit videocapture,gameboycambild und steuerbuttons sowie messdatenanzeige vom robby über funk auf der grafischen oberfläche.
ist alles sehr einfach zu realisieren. bei mir geht alles über funk vom robby zum pc und zurück. ist eigentlich keine herausforderung. nur ein bisschen rumproggen und schon läuft das ganze.
marvin42x
16.04.2006, 13:44
Ja, Purebasic ist auch eine schöne Alternative.
Ich würde mich über eine weitere Variante zu unseren PC-Clients freuen.
Wie Du gesehen hast ist das hier ein open Source Projekt mit einer offenen Architektur und zum Teil festgelegten Übertragungsprotokollen..
Wenn Du deinen Client an das im Wissensbereich vorgestellte Protokoll anpasst und den Quellcode freigibst würdest Du allen Purebasic -Liebhabern sicher eine große Freude machen.
Wir sind gerade dabei einige standard Classes und Indents festzulegen unter denen Hardware-Peripherie angesprochen werden kann. Das wäre dann sicher auch für Dich wichtig.
Würde mich freuen wenn da was wäre was denen die es nicht so gut drauf haben weiterhilft.
Netter Gruß
Hi, wie man wohl merkt, komm' ich in letzter Zeit zu nix.
Der Broterwerb kann manchmal lästig sein.
Nun, als zwischen- neben- hilfs- Produkt der RN-Server.exe mit einstellbarer Baudrate, sonst wie gehabt.
marvin42x
19.04.2006, 15:56
Leben ist hart aber ungerecht.
Da brauchen wir ja nicht fragen ob der alte Holzmichel noch lebt, weil:
Jaaa er lebt noch :-)
Viel Erfolg beim Broterwerben.
Netter Gruß aus der Stadt wo die Forsyzien sich zu blühen anschicken
Hallo an Alle!
So langsam kriege ich Entzugserscheinungen ;) Verfolge die Entwicklung hier höchstinteressiert, und wünschte ich könnte selbst mithelfen. Ich werde mich einklinken, wenn ich meine Chance sehe ;) :mrgreen:
Lieben Gruß aus Hamburg
marvin42x
27.04.2006, 22:53
:-)
So langsam kriege ich Entzugserscheinungen
so ist recht.
schön das Du das schreibst, so ein Feedback von "Aussen" tut dem Projekt auch mal gut.
Netter Gruß
Ja supi,
ich bastel ja auch im Background imma weida imma waida ....
Der Experimental-Server für die Webseitige GUI und der damit verbundenen XML-Komunikation läuft schon ne Weile:
http://www.ulrichc.de/cgi-bin/cu-soap.pl
(Dieser Link ist nur die HTTP-XML-Schnittstelle also keine Bildchen erwarten)
Ich hack derzeit noch an den Clients (das man mal was sieht)
Die Spez. etc. steht schon ... muß aber noch zu Papier gebracht werden ;-)
Netter Gruß,
Chris
NumberFive
28.04.2006, 08:17
Ich muß gestehen das ich arbeitsmässig ziemlich unter strom stehe und so auch nicht recht weiter komme. Ausserdem mußte ich auch mal an meiner Hardware weiter bauen leider tuen die Sensoren immer noch nicht so richtig.
Mal sehen vielleicht hat es ja dieses we hin das noch was mache. Leider muß ich das Protokoll auf der Multicast stream föllig umbauen. damit ich Picks telegramme nach bauen kann.
http://www.i-do-more.de/mine-robo/download/RN-Protokoll.zip
hier liegt immer die Aktuelle Software
http://www.i-do-more.de/mine-robo/download/VideoCapture.zip
hier liegt die anfänge der Video erkennung das soll später mal zusammen
laufen. siehe
https://www.roboternetz.de/phpBB2/viewtopic.php?p=179097#179097
Gruß
Hier habe ich einen guten Artikel und Software passend zum Thema gefunden:
********* Technologies *********
uC to uC to PC Communications using Mailbox
Multi-port, Multi-protocol Serial RAM
2 Way Wireless RF
http://www.botgoodies.com/
http://members.shaw.ca/botgoodies/Mailbox/MBControlPanel.jpg
I can monitor all of my important robot variables and send commands and variables to the robot.
http://members.shaw.ca/botgoodies/TwoWayRF/PC%20To%20Robot.jpg
Wenn ich es in der Schnelle richtig verstanden habe, verfolgt er die Methode "Memory-Mapping". d.h. im µC gibt's ein Speicherbereich, daß vom PC geholt bzw. beschrieben wird.
Auf dem PC hat er ein ähnliches Konzept wie wir dzt., nur setzt er voll auf Windows-Plattform, was mit aber nichts freudiges entlocken kann.
Da find ich (als Basis) unseren "simply stupid socket"-Layer besser.
Wenn's interessiert: Da ich die RNBFRA-Karte durch die zwei Prozessoren als Prüfstein für alle Netzwerk-Konzepte sehe (Pc-seitig gibt's keine vergleichbare Problematik), bastle ich (mit kleiner Flamme) an den Möglichkeiten.
Ich wärme grad die Variante auf: RNBFRA als I2C Multimaster-Netzwerk. Denn die rs232-split oder chain Lösung befriedigt mich nicht recht.
marvin42x
20.06.2006, 23:06
Hallo Leute, ich unterbreche mal ganz kurz die Stille.
Auch ich bin keineswegs verschwunden und auf dem Laufenden.
Hier gibt es was ganz spannendes:
http://www.heise.de/newsticker/meldung/74451
und direkt:
http://www.microsoft.com/downloads/details.aspx?familyid=66d1363e-36a4-46be-ad36-01bcfbfb4969&displaylang=en
Microsoft hat ein Geschenkpacket für Roboter Entwickler geschnürt.
Ich habe den Verdacht, dass wir damit PC-Seitig eine Menge Arbeit sparen können?
Kann da mal einer eine Meinung zu kundtun?
@PicNick:
Ich mach mir bisschen Sorgen um Deine Zähne, meines Wissens nach haben sich an der Kommunikation Mega32 zu Co auf dem RNBFRA schon einige die Zähne ausgebissen.
Aber jetzt ist ja erstmal Erdbeerzeit, dafür brauch man die Beißer glaube ich nicht so ;-)
Frage:
Ich habe in VB2500 Testweise und zum Üben einen TCP/IP-Client zusammengebaut der sendet auch brav an Deinen RN_Server und wenn vorneweg ein RN steht zeigt der Server auch das Gesendete in der Zeile unter Received an. Danach geht der Server auf Closed empfängt aber weiterhin alles mit RN vorneweg. Wenn ich es noch mal probiere.
Muss ich noch was machen damit er mich akzeptiert?
Mein Client empfängt ansonsten Problemlos von einem anderen Server.
Netter Gruß
..Sorgen um Deine Zähne..
An der Stelle ist Gelächter angesagt.
Ich bin gut unterwegs, mit dem Mega und dem 2313 ein Multimaster-Netz zu haben. Ich laß mich doch von so einem Plastik-Dödi nicht tyrannisieren. Ich muß das Zeugs aber noch für eine Anwendung konfektionieren.
Test-Client: müßt ich genaueres wissen. eigentlich geht das.
NumberFive
21.06.2006, 08:43
Ok zu runter laden und angucken hatte ich jetzt noch keine Zeit.
Aber was ich komisch finde nirgens ist so richtig beschrieben wie es geht nur das es ganz doll ist. das ist wieder typisch MS.
"Wenn ich 32 Bit getrunken habe behaupte ich auch das ich alles kann"
Soweit
NumberFive
21.06.2006, 09:34
https://www.roboternetz.de/phpBB2/viewtopic.php?p=191143#191143
@marvin42x du warst nicht der einzige nur andere Quelle
marvin42x
21.06.2006, 09:58
@PicNick:
Multimaster I2c wäre ja ein Ding. Das I2C wurde ja meines Wissens schon mal entnervt zur Seite gelegt, geschweige von Multimaster. Da drück ich Dir aber die Daumen, wäre ja eine hochelegante Lösung, da hätte der kleine sogar seine serielle wieder frei, wozu auch immer.
Der Mega32 als Gateway :-) .
Test-Client:
Wenn das normal geht, werde ich mich da noch etwas rein vertiefen. Beim Lösen eines Problems lerne ich immer am meisten.
Bascom:
Ich hatte ein Update gemacht und jetzt geht alles. Dass so ein winziger Versionsunterschied der Grund ist hätte ich jetzt mal nicht gedacht, zumal es bei den ersten Programmversionen noch ging. Nun denn, mein Compiler weis jetzt auch was ich meine.
@NumberFive:
Na dann ging es Dir beim Lesen der Beschreibung nicht anders als mir. Ich hatte es mir gestern Abend noch runter geladen, steige aber noch nicht ganz hinter.
Nicht der Einzige:
Ja, sehe schon, da werde ich mal mitlesen.
32 Bit:
Da sieht man, dass Du etwas jünger bist, nach 32 Bit würde ich schon unterm Tisch schlafen und nichts mehr behaupten :-)
Netter Gruß
Hallo PicNick,
Ich bin gut unterwegs, mit dem Mega und dem 2313 ein Multimaster-Netz zu haben.
... das interessiert mich jetzt auch. Weil ja bei mir 2 RNBFRA in 3 cm Abstand übereinander schweben, suche ich nach einer Möglichkeit, alle 4 uCs in einem einfachen Multimaster Betrieb zu betreiben.
Das hat zwar mit eurem tollen Projekt hier nur indirekt zu tun, aber ...
Gibt es für so einen Betrieb schon irgendwelche "Standards"? Man müßte sich ja Codes für Anfang und Ende des Master-Betriebs eines uCs ausdenken, ein Master müßte sich abmelden und es müßte klar sein, wer dann an die Reihe kommt. Zusätzlich müßte ein uC sich auch "zwischendurch" melden können, wenn er wichtige Daten braucht oder bereit stellt (Int2 durch PB2???). Und es müßte ein Weg gefunden werden, wie die anderen (nicht-uC-) Sklaven am I2C eingebunden werden können.
Hast du da schon eine Art Protokoll?
Gruß Dirk
Multimaster:
Mein erster Ansatz ist/war mal der, daß auf einem I2C Bus mehrere µC hängen, die von einander unabhängig so agieren können, daß sie ihre Nachrichten sicher durchbringen und auf Konflikte richtig reagieren, daß sie nicht hängenbleiben oder irgendwas verschluckt wird.
Konkret: Auf der RNBFRA-Karte sollen der Mega32 und der 2313 hemmungslos die übrige I2C Peripherie benutzen können, d.h. der 1213 wütet am Expansion-Port und der Mega mit dem Power Port.
Dazu hab ich den Mega als Multimaster konfiguriert, also mal Master richtung Output-PCF, mal Slave.
Der 2313 Co war eigentlich nur Master, er hat in der Schleife mal das Powerport und mal den Mega angequatscht. (normales Bascom I2C)
Mit der HW-TWI am Mega geht das eigentlich super, dem geht nix verloren, wenn ihm der 2313 mal in die Suppe spuckt, merkt er das und wiederholt seine Sendung, bis sie durch ist. Daß der mega mit 400 kHz fährt und der 2313 mit irgendwas langsamen, spielt keine Rolle.
D.h. Mehrere Megas mit Hw-TWI über I2C zu vernetzen ist so mal ein Klacks, da brauchst kein Protokoll, außer der eingebauten Arbitrierung.
Mit den 2313 Bascom Soft-I2C routinen ist das erwartungsgemäß so eine Sache. Der wartet nicht auf einen freien Bus, der fängt einfach an.
Also hab ich ihm mit dem Assembler erstmal eine Stop-Condition-detection eingebaut, und er sendet erst, wenn die da ist.
Das ist zwar etwas laborhaft theoretisch, war aber mal ein Versuch.
Auf diese Art geht das Ganze mal ganz gut, der Mega kann multimastern, wie er mag, und der 2313 kann auch dazwischen "mastern"
Was jetzt fehlt, ist dem 2313 eine anständige Arbitrierung einzubauen, und natürlich eine vernünftige Slave-Function mit erträglicher Bus-Speed.
Bis 100 kHz kann ich dzt. mitspielen, mal sehen, was geht.
(Da wird natürlich gestretcht, wo es geht, logo, wunder gibt's keine)
Und dann den ganzen Schmafu so zu konfektionieren, daß man das auch brauchen kann.
*stöhn*
EDIT @dirk:
etwas hat's schon mit dem Protokoll zu tun. Denn ich find' der Mega auf einer RNBFRA sollte sozusagen "routen" können auf die I2C.
Das durchschlängeln von RS232 will mir nicht unter die Nase
Erstaunlich, dass sich HW-TWI nicht durch Querschüsse des 2313 irritieren läßt! Was passiert denn, wenn der 2313 in einer Schleife auf PCFs zugreift, während der M32 mit ihm oder sonstwomit reden will?
Da müßte doch ein Chaos auf dem Bus herrschen?
Naja, ich verstehe zu wenig davon und werde mir Codes für Stop und Go hernehmen.
Gruß Dirk
Ich hab ja anderenorts berichtet:
https://www.roboternetz.de/phpBB2/zeigebeitrag.php?t=21164&highlight=
dass ich jetzt mal den RNBFRA-Coprozessor soweit habe, daß er als normaler I2C -Slave arbeiten kann.
Das ist in der Servo-Funkionalität etwas schwieriger, da er ja die ganze Zeit von Interrupts gebeutelt wird und nicht immer so hellhörig am Bus sein kann.
Aber immerhin, er tut es. D.h. nächster schritt ist ja, daß der CO auch Master spielt.
Da muß ich jetzt an den Soft-I2C-Master Routinen vom Bascom , die es ja eigentlich gäbe, basteln, denn die kennen keine Bus-Übernahme und Multimaster-Arbitrierung. Wenn ich Pech habe, muß ich sie frisch schreiben, naja, fummel, fummel.
Warum erzähl ich das in dem Thread ? Weil es um die Adressen geht.
Für das RN-Netz gehen wir ja von 16-Bit Sende- und EmpfangsAdressen aus.
Und normalerweise sind die I2C Geräte alle auf 8-Bit adressen (eigentlich ja 7) ausgelegt.
Bei selbstgemachten µC können wir ja basteln, aber die anderen, fertigen (PCF, LM75 etc.) sind ja, wie sie sind.
Gibt es Meinungen ? Sollen wir einen I2C Bus als "system" betrachten, mit 8-Bit identifizieren, und die Geräte drauf mit 8-Bit Sub-Adressen ansprechen ?
D.h. das "Gateway"/der Router nimmt 8 Bit der 16-Bit adresse und das ist dann die I2C Adresse. Die anderen 8 Bit wären dann eben die "Router" adresse.
Oder war das jetzt wirres Zeugs ?
marvin42x
08.07.2006, 12:37
@PicNick
Die überraschende Vielfalt an geäußerten Meinungen kann einen manchmal richtig erschlagen.
In dem ganzen Wirrwarr von Ansichten würde ich sagen: Du bist heute der Bestimmer.
Da Du so was schon lange genug machst, werden wir mit Deiner Lösung schon nicht so falsch liegen.
Respekt hier noch mal, dass Du deine www (werkstatt weit web) auf dem I2C-Bus zum laufen bekommen hast.
@NumberFive:
Mein Interesse an einem einfachen VB2005 Beispielclient der mit dem Server von PicNick über TCP/IP reden kann ist ungebrochen.
Das ich meinen Rasen immer noch von Hand mähe(trotz hohem Alter und gebrechen) will ich hier ja gar nicht besonders erwähnen.
Netter Gruß
marvin42x
12.07.2006, 13:27
@PicNick:
Die Frage rund um ein serielles Protokoll taucht recht oft in verschiedener Form im Forum auf.
Ich frage mich ob es nicht Sinn macht, das RN-Level 0 (seriell) als Fertigbaustein schon anzubieten.
Es ist ja schon am laufen und muss nicht zwingend auf die Fertigstellung des gesamten Projektes warten?
Ich meine, ich hab gut Fragen, die Arbeit hast ja Du, wo sie Dir mit dem I2C-Bus eh schon bis zum Hals steht.
Netter Gruß
Hallo, Berliner !
Nun, Gottseidank hab ich in meiner übergroßen Weisheit die Communications-Funktionen für µC ohnehin extra gestaltet, sodaß dieser Level-0 auch stand-alone angewendet werden kann. dzt. halt nur für Bascom.
Problem ist die PC-Seite: wenn einer mit dem RN-Server leben kann "as it is", ist auch das ja funktionabel, ohne daß man sich darüber hinaus mit dem RNcom beschäftigen muß.
Nur: eine "LBX" / DLL für Pc haben wir halt nicht.
PS: Brich' dir nicht das Kreuz mit Rasenmähen.
@Marvin42x
Ich hab ein paar sich abzeichnende Szenarien zusammengefaßt.
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_I2C-Bus
marvin42x
12.07.2006, 16:45
Wunderbar, musste ich zweimal lesen.
Wenn Du mal nicht mehr Programmieren willst kannst Du auch Rechtsanwalt für Erbschaftsangelegenheiten werden.
Das ist recht kniffelig aber aus meiner Sicht klar und logisch. Der Agent hat mir gefallen.
Von meiner Seite ein freudiges Nicken.
Zum RN Server:
Ja, ist mir schon aufgefallen, Deine Weisheitsanfälle.
Das hat mich auch auf den Gedanken gebracht.
Die RS232 Routinen auf der Bascom-Seite und auf der PC-Seite sind aus meiner Sicht Stan-Alon-Fähig.
Das mit den Libs wäre ja was für später.
Ich sehe bloß immer die Jungs mit dem Problem dastehen, wo das Gute doch so nahe ist.
Außerdem steigert das den Bekanntheitsgrad des Projekts :-)
Netter Gruß,
Ich muss jetzt noch schnell Rasen mähen gehen
marvin42x
16.07.2006, 20:44
Ich habe mal wieder im Wissensbereich über das Projekt nachgelesen. Da hast Du ja inzwischen noch mal eine menge Arbeit rein gesteckt. Mir gefällt es sehr gut. Prima strukturiert und trotz der Komplexität für mich gut zu verstehen. Auch die Serielle am PC ist angesprochen. Das sieht sehr solide aus.
Freu mich, dass Du das machst.
Netter Gruß
marvin42x
28.07.2006, 18:33
@PicNick:
Ich fass noch mal mein Verstehen zusammen:
Der I2C Bus hat 255 mögliche Adressen.
Egal ob da ein oder zwei RNBFRA mit ihren Co’s dran hängen.
Alle Adressen wären von allen Mastern aus ansprechbar.
Das bedeutet auch, dass ein zweites RNBFRA, welches I2C mitmachen will völlig umadressiert werden muss.
Ein Mega32-sys könnte also auf die Physikalische Peripherie seines Nachbar-RNBFRA zugreifen.
Das RNBFRA-Betriebssystem welches die serielle Schnittstelle handhabt(sys-ser) muss alle I2C-Busteilnehmer kennen. -----nee.. muss es nicht, es könnte ja auch über I2C Aufgaben an das sys ohne serielle übergeben werden.
Da die I2C-Busteilnehmer eh fest verdrahtet sind scheint die Undynamik der Adressen hier unkritisch.
Das Betriebsystem(sys) hat für alle ihm bekannten I2C-Teilnehmer eine eigene Behandlungsroutine bzw. für Gruppen gleichartiger I2C-Teilnehmer.
Es scheint eine in der Standart-Message gekapselte Master-Master-Message zur Leistungsverteilung denkbar. Das würde wohl der Agent übernehmen müssen.
Die Standard-Message hat zwei Byte. Das erste beschreibt die Unit das zweite die Unter-Unit?
Die Unter-Unit kann auch eine I2C-Adresse sein.
Da wir jetzt mit der Multimaster Erweiterung die Anzahl der möglichen Unter-Units über die 255 treiben könnten brauche wir ab 255 Unter-Units 3 Byte an Adresse.
Wäre die Frage:
Lassen wir Das Standard-Message-Format unverändert, was für kleine Systeme sicher besser wäre.
Wickeln wir bei über 255 Unter-Units die Adressierung gekapselt innerhalb der Standard-Message ab?
Machen wir gleich 3 Bytes Adresse?
Ist ja wie im Internet, denen reicht der Adressraum auch nicht mehr. Die Computergeschichte ist einen einzige Orgie an Adressraumerweiterungen. Da können wir ja gleich mit anfangen Geschichte zu schreiben ;-)
Netter Gruß
Hallo, Marvin !
RNBFRA-Adressen: Richtig, bei den PCF's muß man umstecken. Da man ja 8 Adressmöglichkeiten jumpern kann und 6 PCF's da wären, sollte das ja gehen. Bei den Atmega und Co- adressen kann man sich ja was ausdenken. Ich hab derzeit 6C und 6E für die Mega, und 68 und 6A für die Co.
Ich teste dzt. mit einer RNBFRA und einer zweiten Atmega-Platine kreuz und quer. Im Prinzip kein Problem, die Co's spucken aber gelegentlich in die Suppe, müssen noch räsoniert werden.
Ein paar Ansätze hab' ich da noch dazugeschrieben
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_I2C-Bus#Message_an_Master
Bei der Adress-Map-Routing-Bredouille darf man sich nicht verwirren lassen, sonst werden wir meschugge.
Ich bin unser R232-Router, über den Level-0 kommt eine Message daher
1. Ich habe eine "Unit" mit der adresse, also kriegt die es und fertig. z.B. ein Agent)
2. Kenn ich nicht.
2.1 Ich schick das Zeug einfach als General-Call über I2C weg (+Retour-adresse) und lass es drauf ankommen, ob sich wer rührt (PCF-en werden das nicht tun, logo)
2.2 Ich find eine Tabelle
16-Bit-sys-adresse <> 8 Bit I2C addresse Type: Master/peripherie
2.2.peripherie--> I2C standard , Level-0 daten werden teils geschickt, teils geholt.
2.2.master --> wie General Call, nur mit direkter I2C adresse
Gibt's ein NAK, wird das zurückgeschickt (level-0)
Bei General Call gibt's kein NAK, das ist einfach Pech für den Absender.
Empfang General Call: Entweder kann man was damit anfangen, dann sollte man dem Router was sagen, (Tabelle erweitern)
Oder nicht.---> Gibts noch ein Netzwerk, dann eben weiter. Wenn nicht, isses eben aus.
(Die Ursprüngliche Absende-Applikations muß sowas wie Timeouts kennen und damit umgehen)
Dynamisch könnte man machen:
Was der Router an (I2C) Geräten kennt, kann er dem PC ja mitteilen
Ist er kein Router, aber ein master, könnt er ja seine Geräte also Liste mit General Call beim Startup oder periodisch allen anderen bekanntmachen. ( Und ev. dem PC weitersagen)
Das wär im aktuellen Fall noch einfacher, denn dann gibt es gar keine Messages in Blitzblaue.
Erläuterung: General Call ist die Addresse NULL, die erkennen alle Master und können die Nachricht lesen, also ein Art I2C-Broadcast.
*schwitz*
marvin42x
28.07.2006, 22:35
@PicNick:
Das mit dem meschugge war ein wesendlicher Grund das hier noch mal für mich aufzurollen.
Deine Sicht mit den Augen eines Routers macht die Sache etwas tröstlicher.
Ich frage mich, ob ich nicht in einem meiner nächsten Leben als Router auf die Welt kommen sollte.
Ein paar Tabellen ein paar Regeln und der Rest ist mir egal, sollen doch die Anderen sehen was sie mit dem Quatsch machen den Sie so glauben hin und her schicken zu müssen.
Ansonsten erstmal alles klar soweit. Der Wissenbereich ist mit den Ergänzungen ja auch auf Ballhöhe.
Netter Gruß aus dem gewitterumwölkten Berlin
28,5° in
25,0° out
..Ein paar Tabellen ein paar Regeln und der Rest ist mir egal, sollen doch die Anderen sehen was sie mit dem Quatsch machen den Sie so glauben ..
Jaja, so ein Router hat eine interessante Lebenseinstellung. :-)
Gruß von der blauen *g* Donau, heute etwas moderater temperiert. In der Wahlkampfzeit (bei uns) machen sie halt alles, um Stimmen zu kriegen.
NumberFive
02.08.2006, 20:55
So Leute ich weiß habe lange nix geschrieben und leider wird das auch in absehbarer Zeit so bleiben den ich habe mir / uns eine Haus gekauf was zur Zeit Vorrang hat. Also bitte nicht böse sein.
Gruß
marvin42x
03.08.2006, 13:01
Es ist bei vielen Wesen auf diesem Erdball üblich, ab einem bestimmten Alter ein Nest zu bauen.
Gratuliere zum Haus und viel Erfolg beim Bau. :-)
Wir werden Dir fehlen.
Netter Gruß
Macht ja nix, dass ich jetzt bis ans Ende meiner Tage den Rasen von Hand mähen muss :-(
Es sind halt immer so ganz profane Sachen, die das menschliche Genie einsperren.
@Number5 : Auch von mir viel Glück, ich hab das hinter mir, dadurch weiß ich, was dich erwartet (wenn du vorne mit was fertig bist, fängst du hinten wieder an).
Per Aspirin ad Asthma ! (oder so ähnlich)
@Number5:
Das sich die Prioritäten ändern hab ich auch erlebt. Wenn du das mit dem Nestbau einigermassen auf die Reihe bekommen hast, stehst du ebenfalls vor dem Problem: Rasen mähen.
@marvin42x:
Ich vermute das du schon in der nächsten Mäh-Saisong einen neuen Leidensgenossen finden wirst. Warten wirs mal ab !!!
marvin42x
11.08.2006, 17:58
@PicNick:
Ich habe jetzt meinen TCP/IP Client soweit, dass er mit Deinem Server spricht.
Kannst Du mal gucken ob das so richtig ist.
Ich weis, dass Du nicht auf Windows - Programmierung stehst aber es wäre mir eine Hilfe, da mir da Number5 fehlt, wenn Du Dir das Programm mal ansiehst und mir ein paar Hinweise gibst.
Speziell Bytes receive und Client close zicken noch.
Das ist vom Schwierigkeitsgrad hier hart an der Kante für mich, da brauch ich etwas Rückendeckung.
Der Client ist über das Menü der GUI zu erreichen.
Ist alles voll die Baustelle aber ich ziehe das jetzt durch.
Ansonsten kommen als nächstes reale Adressen von Units die ich brauche.
Wenn wir da mal was festlegen könnten?
Des weiteren ist mir nicht klar ob wir das TCP/IP Byte-Array(die Message) schon definiert haben oder ob wir hier Ascci zwitschern?
Frage:
Das Teil ist 1100KB und geht nicht als Attachement (max400KB). Wie mache ich Dir das zugänglich?
In dem Sinne
Netter Gruß in die Alpen
marvin42x
11.08.2006, 20:50
So, ich habe Dir das mal gemailt, was besseres ist mir gerade nicht eingefallen. Ich muss mich da mal drum kümmern.
Netter Gruß
Morjen !
Wie bereits zurückgemail, ist alles da.
Ich werd wohl wirklich VB installieren müssen, mein Kollege will mir das eh' schon die ganze Zeit reindrücken.
(Wir haben in der Firma die Situation, daß jeder Entwickler seine eigene Präferenz zu eine Entwicklungsumgebung hat: Einer steht auf VB, ein anderer will mir unbedingt Delphi reindrücken. Und ich bin halt hauptsächlich C /C++ und Assembler. Naja)
marvin42x
12.08.2006, 11:36
Das finde ich sehr freundlich von Dir, dass Du dich für mich über Deine Abneigungen hinwegsetzt.
Ich werde sicher auch meine Hilferufe sparsam gestalten.
Netter Gruß
marvin42x
17.08.2006, 11:45
Ich brauche hier mal einen Tip
Ich habe die Absicht eine Art "Pressemappe" für dieses Projekt anzulegen.
Der Thread ist so groß, dass man das keinem antun sollte der sich nur mal informieren will.
Unten seht Ihr was mir in etwa vorschwebt.
Die Möglichkeiten Die ich sehe sind ein extra Thread oder irgendwie in der Wiki?
Oder macht man sowas ganz anders?
Oder macht man sowas nicht?
Hier ein Entwurf als Threaderöffnung:
Bitte in diesen Thread nicht posten!!
Diesen Thread habe ich eröffnet um einen aktuellen Kurzüberblick über das
Open-Source-Projekt:
Titel:
Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt
zu ermöglichen da der Haupt-Thread eine unübersichtliche Länge erreicht hat.
Ziel:
Fern Überwachung und Steuerung eines Multithreadfähigen-Roboters über einen lokalen PC und/oder über das Internet
--------------------------------------------------------------------
Einzelkomponenten:
---------------------------------------------------------------------
-----------------------Microkontroller---------------------------
Komponente :
Multithread-Betriebssystem für Mega32 insbesondere auf dem RNBFRA-Board
Programmiersprache: Bascom
Beteiligte: PicNick
Status: Rumpfsystem mit Beispielkomponenten läuft.
Komponente :
I2C Multimasterfunktionalität
Programmiersprache Bascom
Beteiligte: PicNick
Status: Rumpfsystem mit Beispielkomponenten läuft.
----------------------PC-------------------------------------------
Komponente :
Handling (RS232) der seriellen Schnittstelle auf dem PC zur Datenübertragung zwischen Roboter und PC
Name: RN-Server
Link:
Programiersprache: C
Beteiligte: PicNick
Status: läuft
Komponente:
Fehlertolerantes Protokoll für die serielle(RS232) Datenübertragung PC-Roboter
Link:
Name: RN-Protokoll
Beteiligte: PicNick, Ragnar, NumberFive
Status: läuft
Komponente:
Grafische Benutzer-Oberfläche zur Fernüberwachung und Steuerung eines Roboters. . Inklusive Einbindung von Kameras .
Datenanbindung: TCP/IP
Programmiersprache: Visual Basic 2005
Beteiligte: Marvin42x
Link:
Status: Vorentwurf in Kürze.
-------------------------PC/Internet-----------------------------------
Komponente:
Umsetzung des seriellen Datenstroms(RS232) in das TCP/IP-Protokoll(LAN/Internet) und Weiterleitung.
Programiersprache: C
Beteiligte: PicNick
Link:
Status: läuft
Komponente:
Grafische Benutzer-Oberfläche zur Fernüberwachung und Steuerung eines Roboters Browserbasiert
Programmiersprache: ?
Beteiligte: UllrichC
Link:
Status: in Vorbereitung
MrNiemand
22.08.2006, 19:47
So Marvin42x hat mich mal animiert hier bissle mit zu palaberen.
Ihr habt ja sicher schon meine Software gesehen, habt ihr mal den Telegramm Aufbau (TCP Schnittstelle) für mich was ich tun muss, das meine GUI weis wo z.b. der Bot aktuell ist? Der Thread ist nu wirklich zu lang zum lesen ;)
So, Männer, es geht wieder ein Stück weiter, schön langsam wird Tacheles gesprochen.
Vorläufiger Status (Besuch am Nachmittag, keine Zeit mehr)
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_Routing
marvin42x
28.08.2006, 15:32
Meinung:
Sehr schön gemacht, die kompakte Lösung der Misere.
Würde ich gerne so mitmachen.
Lamenta:
Mein alter indischer Freund Prakasch pflegte zu sagen: „Sometimes Live becomes difficult“.
Aber so ist das Leben.
Schade, dass ich jetzt mein Gehirn so anstrengen muss. Mein Freund meint: „Ist wohl ungewohnt für Dich“, soll er doch sehen wo er demnächst seine Tasse Kaffee herkriegt.
Unverfrorene Bitte:
Ich nehme Deinen Testserver zum Testen (wie der Name schon sagt).
Könntest Du dem die Neuigkeiten beibringen?
Wobei ja das Testprogramm auf dem Mega32 das ansatzweise auch können müsste, *verlegen grins*.
Frage am Rande:
Wie hast Du den TCP-Dialog Server Client realisier. Fragt der Client regelmäßig ob was da ist oder bekommt er unaufgefordert Nachricht?
Zurzeit hole ich da ungefragt einfach was ab.
Nützliche Info:
Wenn man zum Besuch zu nett ist bleiben der lange und kommen wieder.
Wenn man gerade ganz wichtige Sachen vor hat kann das zu Behinderungen führen.
Netter Gruß
Ps. Der Umstand ob man Besuch bekommt ist natürlich auch schon Aussagekräftig ;-)
Morjen !
Ich schreib eben grad das Konzept auf, meine ganzen PC- und µC-Fragmente müssen das natürlich dann lernen. Die Wiki ist sozusagen gleichzeitig auch meine Prog-Description.
Lustig wird ja díe auto-configuration von dem ganzen Zeugs. Mal sehen.
CLient-IP Ich verwend im Kern einen normalen "blocking" recv, allerdings in einem eigenen Thread, dadurch läuft alles andere derweil normal weiter. Der schreibt receive-messages in Socket-spezifische Queues, die von den anderen Threads unabhängig ausgelesen werden.
Die Kunst des Gastgebers ist es, seinen Besuch zum Dableiben zu bewegen, ohne ihn am Fortgehen zu hindern
LostInSpace
29.08.2006, 08:45
hi,
ich bin gestern auf diesen thread gestossen und bekam beim lesen ein immer breiter werdendes grinsen.
das von euch geplante system habe ich hier im prinzip seit fast 10 jahren im einsatz . ich betreibe hier ein hetrogen verteiltes system mit ca. 140 ports verteilt auf 4 controller/pc. diese gateways (rs232/tcp) sind mit 3 routern (pcs) verbunden, an die via tcp die steuerungsprogramme (ca. 20) angeschlossen sind. das gesamtsystem ist nicht perfekt, laeuft aber seit jahren relativ stabil.
mein ziel war damals, steuerungs-programme zu schreiben, die lediglich mittels eines einfachen apis auf die ports zugreifen. ob die ports nun lokal am pc, via rs232 oder via netzwerk erreicht werden, war und ist voellig egal. das api fuer die steuerungsprogramme ist sehr einfach gehalten. interessant bei diesem vorgehen ist die komplexitaet der steuerungsprogramme. was macht ein programm, wenn einzelne ports nicht mehr verfuegbar sind? konkurierende programme, die die gleichen ports nutzen usw.
bei interesse kann ich gerne schreiben, wie ich einzelne probleme geloest habe.
ps: mein system ist komplett (ausser den controllern) in c geschrieben und laeuft unter linux.
@LostInSpace: Täte mir leid, wenn wir Dich in den Glauben versetzt hätten, in dem Projekt wäre irgendwas wirklich "neu". Das "Tier" Konzept kann auch mit den genannten 10 Jahren locker mithalten.
Was an dem Netz-Konzept interessant ist, ist
Dass es überhaupt (für µC) einen Standard geben könnte
der auch für Anfänger anwendbar ist, d.h. in die gängigen µC Sprachen gut integrierbar ist.
Mit jedem Tag mit MS steigt meine Lust, auf Linux umzusteigen, hatte aber noch nicht ausreichend Zeit.
Daher wäre ein Linux-Wissender an Bord äusserst wünschenswert, und du bist auf jeden Fall herzlichst eingeladen.
Klar haben wir Interesse, man kann ja immer was lernen.
Es sollte Open Source sein, d.h. urheberrechtlich geschütztes wär' weniger gut.
marvin42x
30.08.2006, 15:47
@LostInSpace:
Hi, schön das Du dir das mit dem Thread angetan hast. Ich schließe mich dem was PicNick gesagt hat an. Was mir betont am Herzen liegt ist halt das Open Souce von einer funktionierenden Lösung für die, die neu sind, und von was Fertigem abkupfern können.
Und wie PicNick schon ausdrückt. Auf ein bisschen Zusammenarbeit haben wir immer Lust.
@PicNick:
Meinung:
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_Routing
wenn wir das Plug and Play so hinbekommen wie die Theorie es erwarten lässt wäre das die Erfüllung meiner Wünsche. Nicht aller, aber der zum Projekt gehörenden :-) .
Lamenta:
Hätte ich gewusst, auf was ich mich da einlasse, wäre ich besser baden gegangen.
Bitte:
Keine
Frage am Rande:
Kannst du schon Visual Basic 2005 lesen?
Ich habe mein Errorhandling für die GUI jetzt zu Version 1.0 erklärt.
Auch der TCP/IP-Teil nähert sich einer Funktionstüchtigkeit.
Der Vorentwurf der Benutzeroberfläche ist gemacht und die Einbindung von zwei Kameras läuft bereit. Wie immer, erstmal Fernsehen :-) .
Die Protokollauswertung und das Routing liegen derweil noch danieder.
Das scheint auch gut so, da Du ja die Lage ständig verkomplizierst ;-)
Insgesamt jede Menge Arbeit vor und hinter mir, da ich ja sozusagen aus dem Programmierkeller starte. Aber es wird.
Nützliche Info:
Regenschirm nicht vergessen.
Netter Gruß:
Ja
Kannst du schon Visual Basic 2005 lesen?
Mal sehen. Ich habe mir vom Kollegen die Ms Visual-Basic 6.0 Entenscheiss-Edition geben lassen. *seufz*
PC-Seitiges Routen: Ich denk, fürs Erste ziehen wir das µC-Seitig durch, d.h. Der RN-Server oder ein Äquivalent ist IMMER der Router für den ganzen µC Bereich, und IP seitig sehen wir dann weiter.
Kompliziert: Wir hatten mal einen Bundeskanzler, der war berühmt für den Satz "Das ist alles fuuuurchtbar kompliziert"
Lamenta: Hilft nix, jetzt steckste drin in der Bredouille :mrgreen:
LostInSpace
30.08.2006, 21:00
hi
@PicNick
mein breites grinsen bezog sich darauf, das ich mich noch gut daran erinnere, als ich einem guten freund 1994 sagte "ich will die lampe auf dem hof ueber mein netzwerk via spx vom wohnzimmer aus schalten". er hielt mich fuer leicht verwirrt.
nun zur sache
ich habe den thread gelesen und an der thematik grosses interesse, da ich mein system unbedingt 'renovieren' muss.
ich wollte gerne mal die bisher vorhande software zu diesem thema testen und studieren, habe aber ausser dem basic teil nichts gefunden. koennt ihr mir helfen?
wenn ich euer ziel richtig verstanden habe geht es doch um folgendes. es gibt eine schnittstelle auf dem pc und auf dem controller, zwischen denen daten ausgetauscht werden koennen. im regelfall geht es 'nur' darum, einen port (schalter, sensor ...) zu lesen oder zu beschreiben. diese schnittstelle soll einfach und fuer verschiedne programmiersprachen zur verfuegung stehen. ist das so richtig? wenn ja, ist diese schnittstelle schon definiert?
@marvin42x
zu deinem link in sachen routing. dein ansatz ist teilweise suboptimal. folgendes bezieht jetzt auf pcs, da dort genuegend resourcen zur verfuegung stehen. es gibt 2 arten von verbindungen. p2p und p2mp/mp2mp(nur router zu router). eine p2p verbindung ist zb pc <-(seriell)->controller oder pc<-(tcp)->pc (kann auf der gleichen maschine sein. in diesem fall ist kein routing erforderlich. eine p2mp verbindung erfordert immer einen router. im einfachsten fall startet man einen router. an diesen connecten sich die gateways und anwendungen. ein gateway koennte zb tcp2ser sein. besitzt ein pc 3 serielle schnittstelen, startet man fuer jede ein gateway, das sich mit dem router verbindet. eine mp2mp verbindung darf nur zwischen routen existieren.
diese vorgehensweise hat folgenden vorteil. das gateway ist nicht so komplex. in einfachen umgebungen ist nur eine app und ein gateway vorhanden.
MrNiemand
30.08.2006, 21:26
@ Picnick:
nochmal die Frage an dich, ob es mgl. wäre ein paar kompakte Infos zum TCP und / oder Rs232 Protokoll von euch zu bekommen, denn Marvin hätte meine Sofware (https://www.roboternetz.de/phpBB2/viewtopic.php?t=22483) ja gerne als Teil eures Projektes ;)
marvin42x
31.08.2006, 00:10
@PicNick:
Routen:
Das mit dem Routing habe ich zu vollmundig ausgesprochen, ich meine die programminterne Weiterleitung der Messages an die jeweilige Zielfunktion z:B. Anzeigeelemente und umgekehrt. Wäre da Mapping richtiger? Das Ding habe ich im Moment im Programm Dispacher genannt. Anyway
Kompliziert:
Du musstest ja unbedingt am I2C-Bus rumfummeln, jetzt haben wir den Salat.
Ablauf:
Mir ist es recht wenn erst die Microseite gemacht wird. Ich habe eh noch gut zu tun und für jetzt reicht mir das was wir haben zum Arbeiten.
VB6:
VB6 ist nicht sonderlich aufwärtscompatibel zu vb2005 und das Auslaufmodell.
Mit VB6 wirst Du vermutlich mein Programm nicht lesen können.
VB2005 kann VB6 Sachen weitgehend importieren und zu VB2005 Projekten umwandeln. Andersrum nicht. Und wir sind die, die die Zukunft machen.
3D virtuel Robotik:
MrNiemand arbeitet mitVB6. Er hat eine sehr schöne 3D Live-Darstellung realisiert, die ich auf der GUI-Seite als atraktive Alternative/Ergänzung sehen würde. Diese Entwicklung ist völlig Autark von unserem Projekt kann aber unser Protokoll lernen und am Funkverkehr teilnehmen. Würde mir riesigen Spaß machen wenn wir noch so was im Programm hätten.
Sofern wir unser Protokoll am laufen haben würde ich ihn gerne unterstützen damit das geht.
@LostInSpace:
Ich nehme das als Kompliment, dass Du glaubst, ich hätte den Artikel unter dem Link verfasst :-) .
Zum probieren eignet sich das PicNick Packet, glaube ich, am besten. Ich habe seinen Server noch nicht einmal zum Absturz bringen können :-) Ein Gemüt wie ein Schaukelpferd.
MYSYSLIB
http://www.oldformation.at/electronic/frame1.htm
wenn jemand zum Probieren den original TCP/IP -Datenstrom eines Mega32 braucht kann ich den auch für ein paar Tage oder auf Anforderung auf einer Webseite auf Port 42 zur Verfügung stellen.
Ich möcht Diskussionen, was denn wohl ein Repeater, eine Bridge, ein Router oder ein Gateway sei und was die zu tun haben, gleich garnicht eingehen, das soll'n sie auf der Uni machen.
Wir dürfen nicht vergessen, daß wir es bei µC mit Rechnern zu tun haben, deren Speicher schon voll ist, wenn wir nur die Namen der OSI-Schichten in ASCII reinspeichern wollen.
Optimal und Suboptimal wollen wir doch lieber generell daran messen, ob was funktioniert.
marvin42x
31.08.2006, 13:43
@LostInSpace:
Das mit der leicht zu handhabenden Lib oder so Siehst Du richtig, Das ist so angedacht.
Zurzeit läuft das aber noch direkt durchprogrammiert, ohne Lib.
Die Schnittstelle ist dazu noch nicht definiert.
Was definiert ist, sind das low Level RS232 Protokoll.
Der Aufbau der Message, Das Schichtenmodell und anderes ist in der Wiki dokumentiert.
Das kann man dort und angrenzende(steht immer unten an der Seite) finden:
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_Schichten
Was gerade umdefiniert wird ist das Adresshandling der Message.
Da PicNick es fertig gebracht hat einen Multimaster-Betrieb unter Bascom für die Microcontroller zum laufen zu bringen war das notwendig. Die können ja jetzt auch Netze bilden.
Die eingeschränkten Möglichkeiten der Kleinen zwingen da zu äußerster Optimierung damit sie das packen können.
Und wenn ich zustimmend sage: Dann machen wir erst den Microkontrollerbereich. Dann heißt das, PicNick macht das. Er ist zurzeit der Einzige der das kann und auch macht. Dazu stellt er auch noch einen Server und Testclients und das Bascom Multithread Betriebssystem für den Mega32 insbesondere auf einem RNBFRA-Board. Also viel Besuch kann er sich da nicht leisten :-) .
Für Die Anbindung ans Internet hat uns UlrichC was zugesagt
Die Situation scheint, wie auch für MrNiemand so zu sein das wir die Entwicklung der Kleinen abwarten müssen, da sie in diesem Fall der Maßstab aller Dinge sind.
Ich hoffe ich habe jetzt richtig wiedergegeben.
Netter Gruß
Alles klar, Marvin !
Status:
Ich jetzt zieh' die Sache mal µC-seitig durch bis inklusive RN-Server.
Da ja die Sache IP-seitig sowieso etwas anders aussieht, ist das kein Stilbruch. Für's erste könnten wir diese Seite auch mal lassen, wie sie ist.
d.h. der RN-Server kriegt nach wie vor von den PC-Applikationen eine 16-Bit ID als Ziel und versucht, das weiterzuleiten.
marvin42x
15.09.2006, 16:37
@PicNick:
Bevor ich noch mehr graue Haare bekomme.
Frage zumTCP/IP:
Mein TCP-Client empfängt z.Z. so was vom Server(hier Dezimal dargestellt):
0
0
0
130
3
35
2
160
0
0
130
0
216
1
91
Message Länge:15Bytes 0 0 130 3 35
Wobei die waagerechte Zeile das ist, was ich auswerte.
Der Rest rauscht mir noch unter dem Arm durch.
Die Messageblöcke können auch mal 36, 29, , 21, 22, lang sein.
Meine Frage: Muss ich mein Empfangsteil ändern oder muss ich eine Fang und Sortier Routine schreiben weil das bei TCP/IP so ist?
Auch detailliertere Auskünfte als ja und nein sind genehm :-)
mmmh. wiess jetzt nicht, wie sich der "receive" Befehl in VB anfühlt.
An sich hat IP die blöde Gewohnheit, das eine Message nicht unbedingt 1:1 in einem receive ankommt (oder mehrere messages)
Ich mach es immer so:
Ich hänge die Daten vom receive erstmal ganz einfach zusammen.
Loop:
Wenn wenigstens 2 da sind (das Längenwort) les' ist das, und warte, bis mindestens soviele Bytes da sind als da drin steht.
Dann weiss ich, daß eine Message komplett ist, die kann ich abarbeiten.
Sollten dann vom receive noch bytes übergeblieben sein, --> loop
Weiss nicht, ob das hilft ?
marvin42x
15.09.2006, 17:16
Danke für die promte Bedienung
Das hilft mir gut weiter.
Damit ist die Richtung klar und ich werd nicht an Fronten kämpfen wo es nichts zu holen gibt.
Netter Gruß
marvin42x
16.09.2006, 00:42
@PicNick:
Ich habe jetzt noch mal unsere ganzen Spezifikationen durchgesucht.
Den Aufbau der TCP/IP-Message habe ich nicht gefunden.
Der Netto Message -Aufbau ist klar (glaub ich jedenfalls).
DesClass, DestIdent, SourceClass, SouceIdent, DataWord.
Wobei eigentlich jeweils noch ein Node dazugehört. Aber das ändert sich ja eh noch.
Was mir vorschwebt ist noch ein Message -Beginn -Zeichen und Länge der Message. Ich meine nicht die Länge der aktuellen receive Daten sonder die Länge der RN -Message.
Damit könnte man die Allüren der TCP/IP Übertragung gelassen sehen und hätte auch die Notwendige Flexibilität bei größeren Nutzdaten Paketen die ja sicher noch ins Haus stehen.
Die Slider meiner GUI wackeln schon brav mit den Messages die ich so auffische. Also das Erkennen und Zuweisen des Empfangenen laufen schon.
Ich würde jetzt ungern das Erkennen des Anfangs mit den zwei 0 werten für DestClass und DestIdent machen weil ich das eh wider wegwerfen müsste.
Viel lieber wäre mir, wenn Dein Probeserver so nett wäre sich ein Anfangszeichen und eine Längenangabe auszudenken und dann erstmal so senden könnte. Da ich den Server andauernd brauche würde mir das sehr helfen.
In der Hoffnung nicht neben der Sache zu liegen
Netter Gruß aus dem gerade dunklen Berlin
Ich find die Spec jetzt auch nicht, steht zwar wo, aber wohl nicht dort, wo's hingehört. egal.
Dzt. is es so (RN-SERVER), daß die IP-Sendung so aussieht:
Datenlänge 2 Byte (= normales 16 Bit unsigned word)
Daten
Datenlänge ist exklusive Länge, d.h. um ein Message mit einem Byte zu schicken, kommen insges. 7 Byte:
Länge-1 00000005
Länge-2 00000000
ZielClass cccccccc
ZielIdent dddddddd
SrcClass cccccccc
SrcIdent dddddddd
Datenbyt bbbbbbbb
Irgendwelche start-stop steuerzeichen wären nicht möglich, da ja alles binär ist.
OT Mein Weib ruft zum essen, ich komme wieder
Ist noch wer da ?
Ich stell hier die Version 0000 dar, speziell für kleinere Systeme, die hab ich grad in der Entwicklung bzw. im Test.
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_Version_0.1
Der Artikel ist aber auch noch im werden.
marvin42x
18.09.2006, 17:08
Da hüpft ja meine Maus vor Vergnügen auf dem Schreibtisch rum.
Da war aber einer fleißig. Sauber.
Ein Freund von mir sagte: Da könnte man ja auch andere Sachen mit machen.
Er baut zurzeit an seinem Haus, wie Nr5, und kann momentan leider nur "Haus" sagen.
Ich kenne das, ich habe früher immer nur "Motorrad" gesagt.
Wenn ich dieses System sehe bekomme ich Lust ganz viele Sachen damit zu machen.
Aber im Moment kommt immer nur „Roboter“ raus wenn ich was sage
Ich freu mich jedenfalls riesig über das was Du da hinstellst.
Sonniger Gruß aus dem sonnigen Berlin
.. sonnigen Berlin..
haaaa-haaaa. bei uns schaut's eher mies aus. :-(
Einie Abstimmung wär gut betreffs Rn-Wiki :
Ich würde, wenn's keine Einwände gibt, die Serie "Network PC/µC" ziemlich radikal zusammenstreichen, auf einen eher theoretischen Teil und einen ganz konkreten auf der Basis des derzeitigen Standes.
Also µC seitig bis zum RN-SERVER.exe vulgo RN-Router.exe
Es is doch einiges hin und her und wenn und aber drin, das wohl mehr verwirrt als erklärt. Das liest ja so eh' keine Sau
Verfahren wie bei einer Hochzeit:
Wer was dagegen hat, spreche gleich, oder er schweige, bis daß der Tod eintritt.
marvin42x
19.09.2006, 14:07
:-)
Das ist meine Meinung.
Die Wiki soll uns ja begleiten und nicht wir sie.
Renovier mal.
Keiner kann uns daran hindern die Dinge die wir tun von mal zu mal noch besser zu tun.
Netter Gruß
Du bist in Deinem Alter noch ganz schön inovativ :mrgreen:
..Du bist in Deinem Alter..
Na muß ich ja sein, ich bin ja auch ein halbes Jahr jünger als du.
Dann isses wahrscheinlich eh aus :mrgreen:
marvin42x
19.09.2006, 16:44
Pass besser auf das Du nicht vorher unter einen automatischen Rasenmäher gerätst dessen Kommunikationsprotokoll fehlerhaft war. Wie ich gehört habe manipulieren die Vogonen zur Zeit an den Dingern rum um Herrschaft über sie zu erlangen.
https://www.roboternetz.de/phpBB2/viewtopic.php?t=1363&postdays=0&postorder=asc&start=88
Netter Gruß
*g* Ja, früher gab's immer Zettel an den Masten, daß diese Katze oder jener Hund entlaufen sei, jetzt gibt's bald Zetteln mit Bild von demotiviert entsprungenen Automowern *g*
Jaja, kaum werden sie intelligent, hören sie auf zu arbeiten.
Soweit ist der Mensch halt noch nicht.
Dann isses wahrscheinlich eh aus :mrgreen:
Da ich ja noch einige Tage mehr auf dem Buckel habe, wollt ich nicht warten bis die Schweden dein Protokoll einbauen.
Jetzt versuche ich halt das schwedische Protokoll zu verstehen.
Das das Ding auch zum Mähen taugt ist ja recht angenehm aber ohne Mods mit Lötkölben und an der Software wirds mir sonst zu langweilig.
smörrebröd, smörrebröd, rampampampam.
Wir geben der Hühn in die Töpf.
So, damit man nicht meint, wir machen nix.
Den dynamischen Aufbau der Routing-Tabelle hab ich mal "prototypisiert".
In der Zip sind:
RN_SERVER.EXE (PC)
RN_CLIENT.EXE (PC)
RNMASTER.HEX (f.d. Atmega32 auf einer RNBFRA 8MHZ, 9600 Baud)
RNSI2C.HEX (f.d. AT90S2313 detto)
Viel machen kann man nicht, nur mit dem RN_CLIENT die Servos bewegen.
(just watchen those Blinkenlichter)
Reine DEMO, es geht um den dynamischen Aufbau und Abbau der Tabellen, die im RN_SERVER als Tree-View gezeigt werden.
d.h. wenn man bei laufendem PC die RNBFRA abschaltet, verschwindet die Tabelle (nach ein paar sekunden), beim Wiedereinschalten baut sie sich wieder auf.
Ebenso für die RN_CLIENT-Applikation auf der IP -Seite.
Die Servo-Kommandos werden regulär geroutet, d.h. der Atmega32 weiß ursprünglich nix von dem Co-Prozessor.
Marvin42: Du hast doch eine 2. RBNFRA, glaub ich. Wie sind denn da die I2C-Adressen ? (Damit man den auch mal anhängen kann)
Next steps: konfektionierung (logo). Aber es wird auch aktuell, sich über die ausgetauschen effektivem Nutz-Daten und über das ID-Konzept Gedanken zu machen.
Jetzt bräuchte ich aktuelle Info, welche IP-Daten dzt. von den GUIs nun gesendet bzw. erwartet werden.
(gui-gui klingt eh' ein bißchen nach Versuchs-Meerschweinchen)
marvin42x
28.09.2006, 10:59
Freu freu.
Ich werde gleich wenn ich zu Hause bin alles ausprobieren.
Mein 2. RNBFRA ist genau so wie mein erstes. Also noch serienmäßig nach Anleitung gejumpert.
Ich ändere aber gerne für die gute Sache. :-)
Ich habe aber noch ein RN-Controll da habe ich noch nicht nachgesehen wie das Adressmäßig konfiguriert ist, ist auch serienmäßig.
Die GUI an der ich arbeite empfängt z.Z. vom alten Server die Messages, und zeigt sie in Levelmetern grafisch an.
Dann hat sie Slider mit denen man die Servos stellen kann. Das läuft jetzt noch gemäß dem jetzigen Message Aufbau.
Das ganze hält sich an die Beispiel-Clients von Dir
Tastendrücke mitbekommen kann sie auch schon.
In Kürze wertet sie auch die gesendeten I/O-Ports aus und stellt sie dar oder ändert sie.
Sachen wie Kompass und Motorenansteuerung sind noch außen vor.
Genau so einige Programmprobleme die aber auch gelöst werden.
Ich verbrauche halt noch viel Zeit damit mich in die Programmierung, speziell die Objektorientierte, einzuarbeiten.
MrNiemand hat bei seiner GUI ein etwas abweichendes Konzept. Er bekommt vom Roboter fertige Koordinaten die er auswertet. Dort wird die „Intelligenz „ auf dem Roboter erwartet.
Wenn wir das neue Protokoll am laufen haben werden wir noch besprechen wie wir die Einbindung in den Datenverkehr realisieren können.
Die Festlegung von typischen Daten samt typischer Adressen passt mir bestens in den Kram.
Ich meine Du darfst Chef sein und legst das meiste einfach nach bestem Gewissen, so Du drüber verfügst :-) , fest.
Da sind ja einige Sache die in Deinem Bascom Betriebssystem mit Terminalanbindung schon definiert waren.
Was wir aus meiner Sicht brauchen werden ist ein etwas dynamischerer Messageaufbau um auch kompliziertere Sachverhalte mit dem Roboter austauschen zu können.
Netter Gruß
Gut, ich tob' mich weiter aus, wir beiden sind offenbar eh' die letzten Mohikaner in der Thematik.
Wie dargestellt, möcht ich erstmal PC-seitig wenig bis nix ändern. Das lebt aber davon, daß die ID's systemweit eindeutig sind. Bei zwei RNBFRA's taucht aber eben das Problem der "nicht-eindeutigkeit" auf, abgesehen von den I2C-Adressen (zwei gleiche Systeme mit gleichen Basis-Geräten (ADC 0-7, Servo 1-10)
Bei den dzt. "Pfaden" ist das egal, denn durch die verschiedenen Pfade kann ich eigentlich gleiche ID's zulassen und finde immer den Weg.
Aber bei der Umsetzung PC-->µC (ID--->Pfad) ist dann eben "Servo-1" unklar.
Könnte darauf hinauslaufen, daß noch ein Mapping erforderlich ist: Logische ID---> physikalische ID.
Da käme dann wieder die "Config"-File ins Spiel, d.h. es wird manuell zugeordnet, was was ist.
Btw: Ich hab als Versuchsapplikation eine Art "RADAR" in Betrieb.
Da ist ein GP2D12 auf ein Servo montiert, das sich 180 Grad dreht und dabei am (PC) Schirm ein Radar-Bild der Umgebung erzeugt. Zweck: Test GP2D12 und Servo.
Ausserdem produziert er damit einen ordentlichen Traffic auf dem Netz.
Interesse ?
marvin42x
28.09.2006, 14:46
In der ersten Implementation hatte ich noch:
SourceNode, SourceClass, SourceID
DestinationNode, DestinationClass, DestinationID
vorgesehen.
Hatte dann aber gesehen, dass der Client keinen Node berücksichtigt.
Ich meine das hatten wir schon mal angedacht.
auf der TCP/IP -Seite wäre das problemlos zu verkraften.
Nur der Server hat dann das Problem am Hals damit umzugehen.
Da der aber das ganze Anmelden macht weis er ja wer da ist und weist dem einen Node-Wert zu die M32 Controller müssen selber ja auch eine ID haben. Jeder Teilnehmer auf der PC-Seite sollte eh genau so eine eigene Identität bekommen damit alle geregelt mitmachen können.
Das alles in dem vagen Bewusstsein völlig am Problem vorbeigeredet zu haben.
Bei dem im Moment noch in Aussicht stehenden Plug and Play würde ich ungern auf Config Files runterbrechen wollen. Vom Stil her sozusagen.
Netter Gruß, so von Mohikaner zu Mohikaner
marvin42x
28.09.2006, 21:37
Manno, das ist cool,
Da haste dem Fass aber den Boden raus getreten.
Ich habe es erstmal mit einem RNBFRA gemacht.
Mein Bascom Compiler hat erstmal wieder lauter Ausreden weil dies oder das nicht geht.
Wenn er nur einmal kommen würde und sagen: ist zwar nicht alles richtig gewesen aber ich habe es trotzdem geschafft. Nun hat er schon das neueste Update aber ab und an verstehen wir uns nicht. V 1.11.8.3. Na ja.
Er will jetzt explizit libs haben lbx reicht ihm nicht.
Ich glaube es wäre der Vollständigkeit halber und überhaupt gut wenn Du aktuell alle Libs die er braucht noch mal komplett beilegst, die sind ja nicht groß.
Die leg ich ihm dann in sein LIB –Verzeichnis und vielleicht kompiliert er ja dann.
Derweil waren die Bin und Hex sehr hilfreich obwohl er die auch erst nicht wollte.
Zurück zum Eigentlichen:
Wenn man das in Natur sieht, wie er seine Liste aufbaut lacht mir das Herz.
Selbst meine GUI listet er wenn ich sie connecten lasse.
Das hast Du aber richtig gut gemacht.
Servos arbeiten auch brav, ich meine heute auch besonders smoth, haste da ne Sanftlaufroutine drin?
Kann aber auch sein das ich gerade die rosarote Brille auf habe :-) .
So, nun genug gefreut, ich werde jetzt mal versuchen das zweite Board anzuknüpfen. Aber ich glaube da müssen wir vorher noch über Adressen reden?
Radar:
Den Beitrag habe ich ja voll übersehen.
Klar, ich habe auf der GUI auch einen Radarschirm Programmiert, da kann ich den gleich mit Daten versorgen.
Ich bin außer dem immer an Anregungen, Neuerungen und Spielzeug interessiert.
Netter Gruß aus einem vergnügten Berliner
... smörrebröd, rampampampam...
Galaktische Glückwünsche, an euch Großstadtindianer. Ihr bleibt auch weiter unter Beobachtung.
Wenn demnächst auf vielfachen Wunsch das Rasenwachstum eingestellt wird wird, werde ich mir ein RNBFRA zu sammen löten. Dann kann ich endlich auch mal mitreden.
marvin42x
28.09.2006, 23:38
Das mit dem Einstellen des Rasenwachstum halte auch ich für angemessen.
Ich bin immer sehr deprimiert wenn ich meine Inteligenz dazu einsetzen muss Rasenhalme um 2cm zu kürzen. Das erfüllt mich nicht wirklich.
Abendlicher Gruß
Hehehe. Ich hab' erst den Lavendel zwischen den Rosen zurückgeschnitten, weil wir soviele Motten garnicht haben. Die Rosen haben das aber nicht goutiert, ich schau' aus wie ein Wüstling.
marvin42x
29.09.2006, 12:19
Mottenschutz:
Ich vermute mal das Du da eigenmächtig gehandelt hast.
Beim Kürzen von Grashalmen ist das Beziehungsgeflecht mit der Umwelt etwas überschaubarer.
Unter diesem Aspekt wäre diese Tätigkeit, aus gegebenen Anlaß, als Einstiegsprojekt in die Gartenpflege ernstlich in Betracht zu ziehen.
Netter Gruß
Ps.
Radar:
wassn nu mit Geschenke?
marvin42x
29.09.2006, 15:36
@PicNick:
was muss ich anstellen um meine Gui-Devices auch so schön anmelden zu können?
Die Zuordnung der Sensoren und Aktoren zu den entsprechenden Anzeige-Elementen oder Steuer-Elementen mache ich ja zur Zeit in der GUI.
Bleibt diese Funktionalität dort oder dispacht/routet das nachher der Server?
Netter Gruß aus dem sonnigen Berlin
HiHo !
Die erste Nachricht, die der RN-Server kriegt, erwartet er vorne ein "RN". Der Rest der Zeile ist Text und wird dann auch angezeigt.
Solange er connected ist, hat er die ID=Socket-ID (bgnnnn). Diese ID läuft jeder seiner Messages nach wie ein Gestank. Dadurch find' ich auch wieder zurück.
Das Mappen od. Filtern Sensor -> Element wird wohl so bleiben. Das kann ja auch mehrfach werden (z.B. Anzeige numerisch & graphisch).
Bei Controllern kann er natürlich als Absender reinschreiben, was er will, er kriegt das bei einer Antwort dann als Zieladresse um die Ohren.
marvin42x
29.09.2006, 16:18
Ja , das mit dem RN mache ich ja schon so, Das registriert er und listet mich.
Ok dann werden die Klassen und IDs welche die GUI-Elemente haben nicht auf dem Server gelistet.
Die Absende Klasse und ID der GUI brauchen wir dann ja fürs erste garnicht.
Brauchen wir die überhaupt, wenn das Mapping in den PC-Applicationen bleibt?
Netter Gruß
Der Absender ist wie gesagt dazu da, daß eine Antwort von draussen für dein Programm identifizierbar ist. (wenn du z.b. gleichzeitig mehrere Messages an verschiedene Adressaten versendet hast und die kommen in verdrehter Reihenfolge zurück, weil die Geräte verschieden schnell sind)
Beim Ziel ist das die Frage. Bei der RNBFRA KArte direkt am Com-port wär das einfach, die ist ja immer eindeutig.
Aber wie bezeichnen wir z.B. die zweite (dritte) RNBFRA ? Wissen die, daß sie die zweite/dritte sind ?
Irgendwie müssen wir denen eine Identität geben.
Wir könnten sagen, die RNBFRA am Comport ist immer XYZ
aber eben die anderen ?
marvin42x
29.09.2006, 16:51
Jetzt hast Du mich, glaube ich, missverstanden.
wenn die GUI was losschickt muss sie das komplette Ziel angeben, klar.
Die GUI braucht aber Ihre Absende-Klasse, und Klasseninterne ID nicht eintragen.
Weil das keinen Interessiert und keiner das auswertet.
Der Message -Aufbau z.Z. ist aber mit vollem Ziel und vollem Absender
Sorry, ich sehe gerade. Ich habe noch nicht gesagt, dass meine GUI sinngemäß wie Dein Controller-Betriebssystem aufgebaut ist.
Also mit der kompletten Struktur von Klassen und Klasseninternen ID’s.
Damit bekomme ich auch ein übersichtliches, konfigurierbares Mapping hin.
Nun.
Der Controller, egal welcher, schickt seinen Kram eh bestenfalls an eine von mehreren GUI’s.
Womit er nur das Angeben muss. Die internen GUI -Klassen jucken ihn wenig. Die Adressier er ja nicht.
Meine Gedanken beziehen sich auf den IP-Bereich die Controller untereinander und zum Server brauchen schon alles z.B. beim Plug and Play.
Netter Gruß
marvin42x
29.09.2006, 16:58
Nachtrag:
Die GUI's nehmen ja nur eingeschränkt am Plug and Play teil.
Mehr solln se nich, hat der Wiener gesagt, na und, eben nicht, macht mir garnichts. dann sagen wir auch nix im Absender.
Netter Gruß
Also, z.B. die Servos sind in der Rn-Server-Tabelle mit der bisher üblichen ID eingetragen, also (&H53 u. &H01 - &H0A). Natürlich im Zweig des CoProzessors (ID = &H52 / &H00), denn den Atmega32 geht das ja jetzt nix mehr an, der schickt nur weiter.
D.h. entweder ist also das Servo#1 systemweit eindeutig mit &H53/01 , dann brauche ich sonst nix, dann muß sich der Co einer zweiten RNBFRA eben mit den Servos#11-21 anmelden. (das würde ich bevorzugen)
ODER jeder Coprozessor hat servos 1-10 , aber dann brauchen wir eine Angabe, welcher gemeint ist.
Bei IP können (müssen) wir die in die Anmeldung irgendwie noch eine ID reinquetschen. Wenn alle Applikationen point-to-point direkt mit dem Server reden, würde das dann reichen, dass die Burschen auch untereinander können.
EDIT: auf der PC-Seite haben wir kein Platzproblem, wir könnten da genausogut Text-Adressen zulassen.
EDIT II: Ich richt' mich PC-Seitig gern nach euch
Nachtrag:
Die GUI's nehmen ja nur eingeschränkt am Plug and Play teil.
Mehr solln se nich, hat der Wiener gesagt, na und, eben nicht, macht mir garnichts. dann sagen wir auch nix im Absender.
Wenn bei der Anmeldung eine GUI ein Kennzeichen liefert, wer sie wohl sei, haben wir auch da kein Problem
BTW: Was hieltest du/ihr davon, bei allen RnCOm Rechnern, die mitspielen wollen, die eigene I2C Adresse im EERAM ganz vorne zu speichern.
Dann kann man sie direkt im Pony oder im Bascom-Brenner einstellen, ohne in das eigentliche Programm angreifen zu müssen.
(Klaro ? EERAM auslesen, 1. Byte editieren, zurückladen)
Irgendwelchen "I2C Adresse-Setzen"-Befehlsfolgen würden entfallen. Schon garnicht kompilieren müssen.
Die üblichen Methoden sind sowieso etwas halbseiden, da man ja dazu meist alle anderen I2C Geräte deaktivieren muss oder sonst irgendwelche Tricky Things.
Und Pins jumpern kann es ja auch nicht sein.
Weiteres: Die Rechner-ID könnte man gleich dahinter speichern, und eigenlich auch einen Ident-Offset (das wäre +10 bei den Servos im zweiten RnBFRA, zum Beispiel)
marvin42x
29.09.2006, 20:53
Das mit dem EERAM hört sich gut an.
Ich bin leider nicht kompetent genug um das vollständig bewerten zu können.
Aber der Sound ist gut. Von mir aus gerne. Da kann man dann ein neues Programm laden und muss sich keine Gedanken um die ID zu machen.
Außerdem ist die Entscheidung ja nicht so schwerwiegend. Wenn es und nicht mehr gefällt machen wir es anders.
PC-Seitig:
Wir machen mal wie Du denkst, das sieht im Moment gut aus. Ich wollte nur mal ein bisschen lamentieren :-) .
Auch da werden wir sehen wie es sich bewährt und dementsprechend weiter verfahren.
Es beginnt wieder so eine schöne Zeit wo Ideen das Laufen üben und man zwischen Tests und Entwicklung immer im Wandel ist.
Nette Gruß
... Bei der RNBFRA KArte direkt am Com-port wär das einfach, die ist ja immer eindeutig....
Das möcht ich dir ja glauben, aber wie ist das wenn an dem Com-Port ein Funkmodul hängt, das sich mit mehreren Empfängern unterhalten möchte?
marvin42x
30.09.2006, 00:29
Ich sehe ja da PicNicks Vorschlag mit dem EERAM mächtig Fahrt aufnehmen.
Damit wäre eine Menge an Identitäts-Findung elegant vom Tisch.
Auch die Frage von mehreren RS232 Beteiligten. Was man ja auch bei einer Schnittstellen -Umsetzung auf RS485 erwarten müsste.
Netter Gruß
..Com-Port ein Funkmodul hängt, das sich mit mehreren Empfängern
Da wird zwar Bitmäßig "UART" gesprochen, aber die Kontrolle der Verbindungen zu den einzelnen Emfängern ist dann eins drauf.
Könnte ja genausogut auch Wählmodems sein.
Aber di hast recht: so schlampig sollt' man nicht sein, wir setzen ja "COM" mit der RS232-Kable Konfiguration gleich.
marvin42x
30.09.2006, 11:17
@PicNick:
PC-Seitige IP_Komunikation:
Da wir demnächst vermutlich auch Daten über die neue Infrastruktur schicken werden. Würde ich gerne noch mal über den Message-Aufbau auf der IP-Seite reden.
Schade ist, das ich ziemlich unerfahren damit bin, was aber auch seine Vorteile haben könnte. Ich kann also keine ausgefeilte Empfangsroutine herstellen die clever genug ist die Allüren der TCP/IP-Übertragung abzufedern.
Speziell ist hier die Eigenart der TCP-Verbindung gemeint die Pakete nicht so zu senden oder zu empfangen wie man sie schnürt.
Ich weis, dass Deine Clients damit kein Problem haben.
Meiner schon.
Mir wäre es lieber ich könnte die rein kommenden Pakete, egal wie Sie zusammengesetzt sind, schlicht aneinander hängen.
Gestützt durch ein Startzeichen und eine anschließende Längenangabe zurechtsägen.
Die nun eindeutigen Message nach unseren Spezifikationen, wie Adressen usw. auswerten.
Wie ich Eingangs sagte: Kann sein das ich zu unbeholfen mit dem TCP bin.
Da wir auf der IP-Seite aber keine Platznot haben würden wir eine leicht zu implementierende Messageform haben die auch ein Anfänger packt.
Eine andere Alternative wäre, das so in eine Dll zu packen das es seine Kanten verliert?
Was meinst Du?
GUI-Identität:
Das mit der GUI-ID würde mir stilmäßig gefallen. Alle sagen wer sie sind und was sie drauf haben.
Nur die PC-Aplikationen schweigen sich aus, das fühlt sich irgendwie schräg an.
Wobei ich auch mit schrägen Sachen gut leben kann.
Was meinst Du?
Netter Gruß
Ich muß mir mal anschauen, was sich mit dem IP Gerümpel machen läßt, damit man das einfach verwenden kann. Irgendwas DLL mäßiges, das ist wohl am ehesten sprachenunabhängig. Mal sehen.
Im Prinzip können wir das mit den ID's von irgendwem auch bleiben lassen.
Es gibt ja die Zieladresse "IAM", wo man eine ID hinterlegen kann. Wenn einer das sendet, isses gut, wenn nicht, kann man ihn halt nicht adressieren. wer nicht will, hat schon.
So, wieder mal ein Zwischen-Status.
In der ZIP
RNSI2C Folder Coprozessor-Zeugs
RN_COMM Folder Atmega32-Zeugs
BASC_LIB Folder div. Libraries
RN_Server.exe PC Appl.
RN_ADC.exe PC adc 0-4 auslesen und zeigen
RN_CLIENT.exe PC Servo-#1 bewegen
XVH1.exe PC Radar Servo#1 mit GP2D12 auf adc-1 (!)
Hinten und vorn Demo-Sauhaufen-Unstrukturiert-Programme
Wesenlich nach wie vor die messages und nicht sosehr, was sie tun.
RADAR bewegt Servo #1 hin und her
und liest GP2D12 werte von ADC # 1 (nicht von #0, der ist kaputt bei mir)
Anschauen und staunen, mehr is im Moment nicht drin'.
marvin42x
01.10.2006, 17:48
Gute Güte
Präsente für einige Kurzweil.
Sobald mich die niederen Alltagspflichten aus den Klauen lassen, werde ich mich sofort dran machen.
Klarer Fall das hier alles Baustelle ist.
Vorab den besten Dank für die Kollektion.
Netter Gruß
..niederen Alltagspflichten ..
Schon wieder mähen ?
Übrigens RADAR: ich bin absolut unglücklich mit dem erreichten Ergebnis. Irgendwie flattert der Output vom GP2.. und die Umrechnung auf cm ist offenbar auch unter der Sau. Ich muß mir nach unserem Netz-Massaker unter Laborbedingungen die Sache mal zur Brust nehmen.
Zur Erläuterung:
IP-seitig wird verwendet:
16-Bit Anzahl Bytes, die nun folgen
8-Bit Zieladr Klasse
8-Bit Zieladr Ident
8-Bit AbsAdr Klasse
8-Bit AbsAdr Ident
x-Daten
Ich hab noch kein "NAK" eingebaut, wenn das Ziel nicht gefunden wird. Da haben wir ja noch kein allgemeines Format vereinbart.
Die ADC schicken als Anwort ihren Getadc() Wert als 16-Bit Daten
(82 00 ---> 82 07)
Die Servo (53 00 ---> 53 09) kriegen
8 Bit = &H01
16 Bit Position (dez. 600- 2000)
marvin42x
01.10.2006, 19:05
Mähen:
Die Vogonen haben ja versprochen das Rasenwachstum demnächst auszuschalten. Dann habe ich mehr Zeit an meiner Rasenmäh-Zukunft zu basteln.
Danke, dass Du das noch mal so sorgfältig auseinandergeklappt hast.
Mir hilft so was ungemein.
auch so Doppeldefinitionen in dez. und hex. Da sehe ich gleich ob die Zuordnung und Umrechnung in meinem Programm geklappt hat. Auch wo der Wert steht, ob im Low oder High Byte.
Außerdem ist lieb das Du dem Nachwuchs schon mal eine Längenangabe spendiert hast :-)
ADC:
Joggele maulte auch schon rum was denn nu mit der Genauigkeit bei dem GP2 wäre. Er hatte es mit einem ganz anderen Programm ausprobiert. Ich kann mich erinnern als ich mal so was aufgebaut habe da war auch irgendwas nicht so richtig. Wäre interessant was es damit auf sich hat.
Netter Gruß
..eine Längenangabe spendiert ..
Ja, so bin ich halt :-)
Getadc(): Wird werden den Manf einspannen, der liebt das elektrische Erbsenzählen :mrgreen:
marvin42x
02.10.2006, 18:05
@PicNick:
Danke, das mit den kompletten Libs hat prima geklappt.
Mein Compiler macht wie er soll.
Ich weis nicht, was es war, aber wenn man es auf diese Art nicht rausfinden muss ist mir das ganz lieb.
Deiner kleine TCP/IP Herde geht es prächtig, alle verstehen sich und schwadronieren miteinander rum.
als einziger ist der CoController noch nicht so recht bei der Sache. Aber das wird daran liegen, dass ich ihm noch nicht die richtige Weisung eingespielt habe.
Dieser Post ist jetzt nicht als Aufruf zur Fehlersuche gedacht, das mach ich schon alleine noch richtig. Ich wollte nur mal melden, dass die Sachen nicht achtlos in der Ecke liegen wenn von mir nichts zu hören ist.
Netter Gruß
Immer mit der Ruhe, wir haben ja alle unsere peripheren Störfaktoren.
Btw: Beim Coprozessor ist mir folgendes aufgefallen: Beim Brennen wird öfters mal der EEPROM als collateral-schaden vernudelt. Und wenn im ersten byte auf einmal 00 als I2C-Adresse steht, klappt die Sache dann nicht.
ggf. kontrollieren (read eeprom to Buffer, Edit &H68, write Eeprom)
marvin42x
05.10.2006, 02:05
Danke für den Tip jetzt läuft alles. Ein schöner Ausblick.
Du hast mit deinen Testclients früher eine GUI fertig als ich :-)
Netter Gruß
Leute, das interessiert mich jetzt, weil ich dem CoProzessor gerade ein paar Aufgaben beibringe:
Also, z.B. die Servos sind in der Rn-Server-Tabelle mit der bisher üblichen ID eingetragen, also (&H53 u. &H01 - &H0A). Natürlich im Zweig des CoProzessors (ID = &H52 / &H00), denn den Atmega32 geht das ja jetzt nix mehr an, der schickt nur weiter.
D.h. entweder ist also das Servo#1 systemweit eindeutig mit &H53/01 , dann brauche ich sonst nix, dann muß sich der Co einer zweiten RNBFRA eben mit den Servos#11-21 anmelden. (das würde ich bevorzugen)
ODER jeder Coprozessor hat servos 1-10 , aber dann brauchen wir eine Angabe, welcher gemeint ist.
Da ich dabei bin, dem CoP als Slave weitere Augaben nahe zu bringen (es gibt ja diese schon: 10 Servos ansteuern, IR-RC5-Kommunikation,- weiteres ist in Arbeit), bin ich sehr daran interessiert, dass ein fertiger CoP in eurem System ansprechbar ist.
Warum ist das ein Problem mit dem Ansprechen von 2 CoPs bzw. deren Servos???
Man kann ihnen doch unterschiedliche I2C-Adressen geben, unter denen sie angesprochen werden können. Jeder würde als Slave bestimmte Aufgaben bekommen. Der Server würde also die I2C-Adressen kennen und braucht zusätzlich noch eine Kennung für die Art der Aufgabe (Aufgabe heißt hier z.B. "Ich bin ein CoP, der 10 Servos ansteuert = RNSI2C"). Mein Ziel wären noch weitere Aufgaben, so dass man eine Kennung bräuchte.
Identifizierung z.B.:
H68/1 ist ein CoP zur Ansteuerung von 10 Servos mit der Adresse H68.
H6A/2 ist ein CoP zur IR-Kommunikation mit Adresse H6A
Die 1 oder 2 legt fest, welche Aufgabe der CoP hat. Ein CoP mit 2 muss auf andere Weise angesprochen werden, als ein CoP mit 1 (Bei 2 z.B.: Lesen eines IR-Empfangspuffers oder Senden eines IR-Codes).
Oder habe ich da was nicht verstanden?
Grund meiner Frage:
Ich möchte weitere Anwendungen für den CoP schreiben, aber das natürlich so, dass ihr hier die Typen genau so gut einbauen könnt, wie den RNSI2C.
Sollte man da etwas vereinbaren? (oder liege ich voll neben der Spur???)
Gruß Dirk
Hallo, Dirk !
Das "Problem" liegt im Routing, also im Umsetzen der ID in einen physikalischen Pfad. Am I2C Bus MUSS ja sowieso jeder eine eindeutige Adresse haben.
Umd es taucht auch eher erst auf, wenn Applikationen einzeln und von verschiedenen Leuten entwickelt werden (was durch einen Standard ja möglich ist, und das is ja auch der Zweck)
Wenn irgendein begnadeter PC-oder Linux Entwickler eine geniales Servo-steuerprogramm entwickelt, und es spricht einfach die Servos 1-10 an, muß bei einem Einsatz festgelegt werden, sind das diese 10 Servos oder jene.
Also kein technisches Problem, man muß aber irgendwas vereinbaren.
Ich persönlich würde ja eher diese "ID" als Rollenname einsetzen, und zwar danach, was das Gerät tut.
Nimm an, ein SERVO #1. Was heißt das ? eigentlich garnix.
Ich würde eine ID vergeben, die aussagt, was das Servo tatsächlich tut.
Nimm einen Hexapoden, eine Kundschaft für viele Servos. Mir schiene es sinnvoll, wenn es da die IDs gäbe: Kniegelenk links hinten, Schulter rechts mitte, etc.
Denn eine PC anwendung mit einer Hexapodsteuerung muß sich ja danach richten, und servo 1 - 99 ist ja im Grunde bedeutungslos.
Und wenn ich das so mache, sind ja ALLE Geräte im Netzwerk automatisch eindeutig.
ID Schrittmotor links
ID Schrittmotor rechts
ID ADC-Batteriekontrolle
ID ADC GP2D12 links vorne
ID ADC GP2D12 rechts vorne
etc.
Dann kann einer perfekte PC Programme schreiben, ohne deine I2C Adressen zu wissen oder sonst was. eben weil alles Standard ist.
Hallo PicNick,
ja, das mit den IDs für die Funktionen des Slave verstehe ich.
Aber wie ist das auf der Slave-Ebene mit den einzelnen Funktionen, die ein,- sagen wir genormtes-, Programm haben könnte.
Beispiel:
Dein RNSI2C kann ja nicht nur die 10 Servos ansteuern, sondern auch noch per I2C-Befehl seine Adresse geändert bekommen.
Bei meinem RNIRI2C gibt es 3 Funktionen: IR-Empfangspuffer lesen, ein Kommando+Adresse senden und I2C-Adresse ändern. Wie kann oder sollte man das "normieren"? Es macht ja Sinn, die zusätzlichen Funktionen transparent zu machen!
Mein aktuelles Projekt ist z.B. ein DCF77-Decoder mit I2C-Ausgabe für den 2313,- das klappt schon ganz gut und ist in der Testphase.
Ich würde also in eurem Projekt zur Zeit folgende IDs beantragen:
ID IR-RC5: Empfangspuffer lesen
ID IR-RC5: Adresse+Kommando senden
ID DCF77: Zeit einlesen
ID DCF77: Uhrzeit Softclock stellen
Was bleibt als Frage:
Wer "weiss" auf den höheren Ebenen eigentlich, welche Funktionen es auf Ebene des 2313-Slaves gibt und wie sie ausgeführt werden?
Bei deinem RNSI2C ist das z.B. CMD (1) | srvNr | srvpos, bei meinem IR-Slave ist das CMD (0) | RC5-Adr | RC5-Cmd für das Senden, dazu kommt noch das Empfangen, da auch evtl. mit unterschiedlicher Größe des Empfangspuffers.
Ähnlich wird es auch beim DCF77-Slave aussehen. Da wird dann noch dazu kommen, dass man auch die "Betriebsart" des DCF77-Decoders per I2C-Befehl ändern kann. Dafür würde ich dann sozusagen noch eine weitere ...
ID DCF77: Betriebsart (Parameter) einstellen
... brauchen.
Für fast jeden Slave bräuchte man auch eine ID fürs Ändern der eigenen Adresse:
ID IR-RC5: I2C-Adresse ändern
ID DCF77: I2C-Adresse ändern
Ich weiss nicht, ob ich klar gemacht habe, was ich meine. :-k
Macht es Sinn, da eine Art Standard zu beschreiben? Z.B. könnte man bestimmte Funktionen des Slave immer auf dieselbe Weise durchführen:
-> Hauptsendefunktion: START | 0 | n Bytes_to_send | STOP
-> Parameter ändern: START | 1 | n Parameter | STOP
-> I2C-Adresse ändern: START | 2 | neue Adresse | STOP
Gruß Dirk
Man muß unterscheiden zwischen ID und Gerätefunktion. Eine bestimmte Gerätefunktion (lesen, schreiben, etc) und auch der Aufbau der Nutz-Daten sind Vereinbarungen zwischen Gerät und Appilkation, die das nützt, das spielt für unser Netzwerk keine Rolle
Das Netzwerk und das Routing ist sozusagen der Briefträger, der verteilt Briefe, was in denen drin steht, geht ihn nix an.
Sinnvoll wäre es, Die Nutzdaten immer mit einem "Command" (byte?) beginnen zu lassen
Bei deinen Geräten seh ich das so:
RC5 könnte es theoretisch mehrere geben, also wäre eine ID z.B,
IR_RC5 + Nummer 1 bis Nummer x
Das, was dann zu tun ist (lesen, schreiben), ist dann ein Kommando
Dein Beispiel als vollständige Message wäre dann:
-> Hauptsendefunktion: START | RC5#1 |Absender | CMD=0 | n Bytes_to_send | STOP
-> Parameter ändern: START | RC5#1 |Absender | CMD=1 | n Parameter | STOP
-> I2C-Adresse ändern: START | RC5#1 |Absender | CMD=2 | neue Adresse | STOP
Anm: Die Absenderangabe ist bei unserem Netzwerk meistens garnicht notwendig, denn das Netz weiß ja immer, wer den Brief in den Briefkasten geschmissen hat.
okay, verstanden -> wunschlos! O:)
Gruß Dirk
Gleich eine Anfrage an die Gemeinde:
Es wäre günstig, wenn sich ein Programm beim RN-Server meldet, daß es auch gleich die Protokoll-art (smir und was weiß ich) mitteilen würde.
In weitem Bereich kann ich dann automatisch drauf eingehen.
Any suggestions ? Vorschläge ? wer (welche Protokolle) ttäten denn mitspielen wollen ?
(mir is alles recht, was STREAM-Sockets betreibt)
LostInSpace
06.10.2006, 13:27
hi,
ein tipp zu eurem ip problem.
wichtig ist der unterschied zwischen udp und tcp. das projekt sollte nur tcp verwenden, da bei udp nicht garantiert wird, ob ein packet auch angekommen ist.
bei tcp wird alles ueber den ip-stack gecheckt. treten fehler in der uebertragung auf, kann dies einfach abgefragt werden.
nun zum problem:
frau sendet ein datenpaket mit einer laenge von 600bytes. im empfaenger werden diese auch ankommen, nur evtl. nicht in einem stueck. es kann sein, das das paket beim senden vom ip-stack fragmentiert wird (stichwort zb mtu). der empfaenger liest nun in seinem empfangspuffer 400bytes. er weiss nicht, ob noch weitere daten folgen.
die loesung fuer dieses problem wurde schon einige seiten zuvor in diesem thread genannt. frau muss auch hier mit start- und stop-sequenzen arbeiten. gelesene daten werden in eine queue geschrieben und beim empfang einer stopp-sequenz wird aus der queue ein neues 'packet' gelesen.
Du hast recht, ip kann einem mit seinem blocks ganzschön freude machen.
Ich selbst empfehle die Kombination Länge(short)/Data (um transparente Daten zuzulassen). Das tun auch viele andere, manche nehmen auch 32-bit längen, scheint mir aber überdrüber.
Start-Stop zeichen verwendet bei Ip keiner, den ich kenne (also nicht professionell, sonst weiss ich nix, ja, eventuell EDI)
Das zusammenschustern von den Daten beim receive muß halt so oder so immer gemacht werden, die Exception-behandlung aber auch, was soll's
EDIT
Achja, die ganzen Internet geschichten gibt's auch noch, aber das ist nicht für transparente daten
marvin42x
06.10.2006, 14:09
Dass der Server in Grenzen alternative Protokolle zulässt finde ich genial.
Damit wäre einer meiner stillen Wünsche wahr.
Schöne Sache.
Netter Gruß
..alternative Protokolle ..
Gibt's aktuelle Doku zu den fraglichen Protokollen ?
Ich hab das im Streß etwas verschludert.
marvin42x
06.10.2006, 14:42
Da brauchst Du Dir keine Gedanken machen, da war glaube ich nichts was Du hättest mitbekommen können.
Was ich weis:
MrNiemand:
Das Protokoll von MrNiemand erwartet zurzeit echte Koordinaten, also ein Ansatz der erst bei einem laufenden Roboter relevant wird.
Zu Alternativen wird er sicher selbst was sagen können. Nach meinem Kenntnisstand ist aber große Bandbreite zur Adaption vorhanden.
Wir hatten uns unterhalten und er wäre an einer Sende und Empfangsroutine in VB6 interessiert.
Ich werde mal sehen ob ich da an eine Antwort komme.
UllrichC:
Möglicherweise hat er noch was dazu zu sagen.
Marvin42x:
Marvin hat weiterhin Probleme professionell zu sein und würde sich erstmal gerne aus dem RN-Protokoll ausklinken und sich ein Dussel-Einfach-Protokoll mit Startzeichen und Längenangabe wünschen bis er aus den Windeln ist. Da das Jahre dauern kann wäre eine Sonderanbindung mit dem berüchtigten Marvin-Du-Dussel-Protokoll gewünscht, was Programmtechnisch auf der Serverseite nicht allzu schwer sein sollte
Netter Gruß.
Gut Marvin , dann mach eine genaue Spezifikation von deinem MDD-Protokoll und man wird gucken
LostInSpace
06.10.2006, 15:12
ho ho,
ich sprach von tcp, nicht von ip. ich sprach von start/stop sequenzen, nicht zeichen.
Start-Stop zeichen verwendet bei Ip keiner, den ich kenne (also nicht professionell, ...
der war gut! #-o
und wie willst du dann bei einem binaer-stream ein effektives framing durchfuehren?
marvin42x
06.10.2006, 15:33
Das Ist sehr fürsorglich von Dir.
Ich will Die Geduld auch nicht über die Massen strapazieren.
Ich werde mich klugerweise nach dem richten wie wir es im RN- Projekt festlegen.
Was ich für mich persönlich bräuchte ist neben der Längenangabe, die ja existiert ein eindeutiges Startzeichen, der Rest Standard. Es wäre lieb von Dir wenn Du die Festlegungen für das Startzeichen übernehmen würdest, das würde uns das Gelächter ersparen wenn ich es machen würde.
Der Name MDD-Protokoll gefällt mir :-)
Ist übrigens ab jetzt übernommen.
Zur Serveranmeldung kommt jetzt der String „RN-MDD-Name“ :-)
Auf diese Weise bleibt das RN Seriös und wir können auch Ausnahmen wie diese zulassen.
Die Überlegung mit den Dll’s ist ja unbenommen davon.
Das Du das mit der Protokollwahl gemacht hast ist richtig nett.
Freu mich.
Netter Gruß
@Lostinspace
Aaah, ein Fachmann.
Zur Klarstellung: Wir sind hier schlampig. IP ist für uns Anwender die schwarze Wolke, die hinter allen "socket" calls verbirgt. Dass sich dahinternoch 57 schichten mit unterschiedlichen Hobbies rumtreiben, haben wir zwar schon gehört, das nutzt uns im täglichen Leben aber nix.
@Marvin42:
Ich habe nun, ach, Juristerei und Medizin...... Blödsinn.
VB2005 installiert und dein projekt mal angesehen.
Also, für Frischoperierte und Rekonvaleszente ist der VB-Express ka nix, ich muß schon sagen. uiuiuiui.
Aber ich werd' mich schon durchbeissen. Dranbleiben, Männer !
NumberFive
09.10.2006, 08:03
Holla,
habt ihr gas gegeben das dauert ja woche bis ich da wieder dran bin.
Sehr schön das das so ist. wollte eigendlich nur ein bisshen lesen um nicht ganz raus zu kommen aber bei dem speed reicht ein morgen leider nicht.
Mal ne Frage fährt einer von euch zur RobotLiga ?
Gruß
Hallo, NumberFive !
.. RobotLiga..
Ich jedenfalls eher nicht. :-)
@marvin42x
Klingt wie angekommen.
Ist gerade alles auf dem Drucker (Der Thread), werde mir heut abend im Hotl mal alles reindrehen.
Gibts von den 146 Seiten auch eine Hörbuchversion?
@NumberFive
Auf die RobotLiga schaff ichs nicht. Aber auch die Chellange wenns die noch gibt.
Schöne Grüße
marvin42x
09.10.2006, 15:45
@NumberFive:
Schön von Dir zu hören. Du bist offenbar gesund und voller Tatendrang.
Weiter so.
Eines Tages werde ich mir auch die Freude gönnen und zu einer Roboterveranstaltung fahren. Zurzeit eher nicht um bei der Wortwahl eines meiner Vorredner zu bleiben.
@UlrichC:
:-) das Hörbuch wird im Sachbuchverlag oder einschlägigen Fachgeschäften im Dezember, noch passend zum Weihnachtsgeschäft erhältlich sein.
Wenn Du nicht warten willst lese eher nur den letzten Teil. Das ganze Ding wäre eine Zumutung. Tut mir leid, aber wir sind halt Plaudertaschen :-)
Ansonsten siehst Du das ganz richtig. Es stehen jetzt Erwägungen an die sich um das Internet drehen.
Du kommst sozusagen wie gerufen.
Netter Gruß
Hi, Marvin42x ! Na, hast du die Hände wieder frei ?
Hab rumgestöbert in der MS Robotics-Geschichte und auf W3 von wegen Soap, DSSR und anderen Schweinereien. Hab auch einen (kurzen) Thread aufgemacht.
Um da mitzuspielen, müßt' sich wer herstellen und so'n art Gatway schreiben. d.h. die Anmeldung beim RN-Server geht dann in eine Subscription beim MS robotics über (so etwa)
Was interessant ist, ist, daß der Grundgedanke sehr unseren Vorstellungen entspricht.
Für Roboter-Newcomer ist das aber strenge Kost, kommt' mir vor.
marvin42x
09.10.2006, 16:29
@PicNick:
Ja der Alltag will auch mal an erster Stelle stehen aber nu habe ich alle zu aller Zufriedenheit erlegt.
So wie Du das Robotic beschreibst sehe ich es auch.
Bisschen strenge Kost.
Aber liegt auf unserer Linie.
Das Üble ist der „Treiber“ danach wird es langsam einfacher.
Ein Pferdefuß ist, das UlrichC, wenn ich richtig informiert bin, dem möglicherweise ablehnend gegenübersteht. Da wüsste ich auch gerne wie er das ganze in Bezug auf unser Projekt sieht.
Der Vorteil der im Vordergrund steht ist halt das es ein Standard ist. Unabhängig ob man Microsoft nun liebt oder nicht.
Erstmal Netter Gruß
Weil, jetzt kommen bei mir noch die Gesellschaftlichen Pflichten.
Habe nun ein wenig gelesen.
(Soweit ich euren Quererbeschreibungen folgen konnte)
Es gibt nun einen RN-Server der bisher mit der Hardware kommuniziert, aber nun auch mit anderen (RN-)Servern über TCP/IP quatschen möchte (richtig?)
Hierfür ist ein Protokoll gesucht... das bereits den Namen RN-Marvin-Du-Dussel-Protokoll hat.
Und eine Anmeldepozedur ? ... gibt es eine Quintesenz (so eine Art "was inzwischen geschah)
Server<>Server
Server<>Internet
Bitte an dieser Stelle schon Antworten denn ich bin mir nicht ganz sicher ob das oben geschriebene passt oder ob ich noch mehr lesen muss.
(Ich habe nur die letzten drei gelesen ;-), der Rest ist Schmierpapier bis 2010 )
Ich habe nichts gegen MS-Robotics es ist eben nur ein System von vielen ... im Bezug auf das Projekt hier, sehe ich diese MS-Suite aber nicht im Mainstream der Entwicklung.
Ich würde im Umgang mit dieser Technologie eher von einem evtl. AddOn zum RN-Server - Suite Protokoll-Standard etc. sprechen als von einer echten Kommunikationsplattform bzw. Hauptanbindung.
Das Problem ist nämlich die Halblebigkeit der Microsoft-Standards.
Wenn man alles drauf setzt geht man dem Neuling-Standard vielleicht baden oder hängt sich damit gar auf eine Plattform die den RN-Protokoll-Standard(dieses Threads) irgendwann in dieser speziellen Niesche überfällig macht.
Wenn man es anhackt (AddOn Treiber nach RN-Server) ist man dabei aber nicht zwingend (Viele Partys, mehr Spaß).
Zudem kann man einen runden RN-Server mit Protokoll und Definition schnell mal auf ein anderes Betriebssystem bringen oder (wenn er einfach, klein und schlank genug bleibt) auch schneller verstehen als einen MS-Klotz.
Denn TCP/IP gehört zu den Grundlagen von Informatik, hingegen ist MS-Robotics sicher nicht die erste Wahl eines "Jeden" Programmierers.
Ich schätze zudem das es viele Leute im Nebel dieses Fachbereichs gibt, die bei der Aufforderung MS-Framework zu installieren um ein Servo zu bewegen keinen Spaß mehr daran haben werden.
Schöne Grüße und bis bald
Hallo, UlrichC !
Der Status quo ist jener:
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_Version_0.1
Die µC Seite ist noch unkonfektioniert, tut aber das Wesentliche.
RN_SERVER.EXE (PC-Progr.) ist als beta-0.nix Version auch fertig
Dann gibt es 3 verschiedene Demo-Applikationen dazu,
eines für Servo-ctrl,
eines für die raw adc werte,
eine Servo/GP2D12 radar anwendung
Jetzt sind wir grade dabei, die VB2005 Applikation von MArvin42 so hinzubringen, daß er auch mitspielen kann.
Dabei war eben der Gedanke, beim Anmelden der PCAppl->Server eine gewisse Protokoll-auswahl zu machen, damit man mehr Auswahl in der Anbindung hat. (MDD z.B)
Und da ist nun die Sache mit MS Robotics aufgetaucht.
so, jetzt weißt Du's
EDIT: Wenn du auch mal probieren willst und une RNBFRA hast
http://www.oldformation.at/electronic/download/down.htm
Ein komplettes "little networker" set
Das ist der Vorteil bei den MS VC++ Sachen: man braucht nix installieren
marvin42x
10.10.2006, 00:30
@UlrichC:
Danke für das runde Statement. Ich stehe der Robotic Sache zwar positiv gegenüber, sehe aber auch das Deine Einschränkungen Hand und Fuß haben.
@all:
Wenn wir mal testweise, ohne dass ich der Meinungsfindung vorgreifen möchte, annehmen Robotic Studio als zusätzliche Option zu sehen.
Wie würde dann die Alternative aufgebaut sein?
Reines TCP/IP über den Draht geht ja verhältnismäßig easy (räusper, jedenfalls für einige mehr und für anderen weniger).
Der Server hat gezeigt, dass er Multi Client fähig ist.
Da wir jeden Fussel auf den Boards einzeln adressieren können kann es auch Spezialisierungen geben wie z.B. erwähntes Radar und nebenher eine Anwendung die nur die Servos ansteuert.
Die Komunikation von PC-Aplikationen untereinander über den Server wäre wohl auch denkbar. Da wir ja über eine komplette Empfänger und Absende Adresse verfügen.
So.
Jetzt das ganze im Internet habe ich schon ausprobiert.
Berlin Süd-PC-Router-DSLmodem-Intenetprovider- Internetprovider-DSLmodem-Router-PC Berlin Mitte.
Würde vermutlich bis Wien oder Kalkutta reichen :-)
So was läuft überraschend klaglos.
Und zwar in beide Richtungen. Meint: Servo in Süd von Mitte aus ansteuern.
AD-Werte von Süd nach Mitte liefern.
Weiter:
Wie würde man sich das vorstellen wenn ich an meinem Arbeitsplatz hinter einer Firewall nachsehen will ob und was der Roboter treibt.
Oder verschärft: der Robo hat ein Ereignis und meldet das ungefragt, also ohne Anforderung.
Netter Gruß
NumberFive
10.10.2006, 07:32
Das Thema Multicast habt ihr wohl föllig auf gegeben ?
Gibt es schon was was auf der RN-Control läuft ? Am besten mit source dann kann ich mir den Teil mal ansehen.
Leider ist auf dem Hof noch sehr viel zu tun so das ich nicht viel machen kann aber die Winter hier oben sind lang und kalt (Schneereich).
Wir haben ca. 150 m Gehweg zum sauber halten in sofern muß ich jetzt was tun oder es ist Hand arbeit angesagt.
Ganz schöner Zwiespalt
..150 m Gehweg zum sauber halten ..
Du brauchst offenbar eine Schneefräse mehr als einen Rasenmäher
NumberFive
10.10.2006, 08:20
Ob mähwerk oder schnee frässe sollte eigendlich egal sein muss halt sein wie beim trecker man kann die Machine Tauschen.
1..Robotic Studio als zusätzliche Option zu sehen.
Wie würde dann die Alternative aufgebaut sein?
2 Reines TCP/IP über den Draht geht ja verhältnismäßig easy
3 Die Komunikation von PC-Aplikationen untereinander über den Server wäre wohl auch denkbar. Da wir ja über eine komplette Empfänger und Absende Adresse verfügen.
4 der Robo hat ein Ereignis und meldet das ungefragt, also ohne Anforderung.
1) Eine Entscheidung steht nur an, wenn wir sozusagen das PC-seitige garnicht mehr machen wollten, sonden auf MS Robotics umsteigen wollten. Das scheint mir aber eh' nicht empfehlenswert, so handsam ist das Robotics auch wieder nicht.
2) Eben. Auch deine Applikation bringen wir zum fliegen. Langsam blicke ich ja eh' durch.
3) wie 1) soweit, wie wir sind, gibt's kein halten mehr
4) Das Problem is nix Robby-spezifisches. Incoming calls durch die Firewall brinden alle Administratoren zum schwitzen. Bei uns geht das nur mit RSA-Key.
@All: Da ich mit der derzeitigen TCPIP Variante (Stream) einige Jahre (>15) gute Erfahrungen gemacht habe, würd' ich dabei bleiben wollen, vor allem, weil ich bei Multicast den Benefit nicht sehe (IMHO)
Gibt es schon was was auf der RN-Control läuft ? Am besten mit source dann kann ich mir den Teil mal ansehen.
Möchte auch mein Interesse an einer RN-Control Version anmelden. \:D/
Hallo Vogon ! Du kannst das Downloadset
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_Version_0.1#Weblinks.2FDownload
ruhig verwenden, er behauptet halt, es wären drei PCF vorhanden, aber das soll dich nicht stören.
Viel mehr praktisches als mal gucken ist eh' nicht drin.
µC seitig sind eh' alle sourcen etc. dabei
Ich wäre auch für TCP/IP ... das ist einfacher zu portieren, weil keine Checks nachgebaut werden müssen.
Ich schließe mich mal dem Interesse für das RN-Controll an und werde am WE die das Downloadset (=Suite) auch laden.
Ich habe hier sehr restriktive Verbindungen ins Inet und kann deshalb fast nix downloaden. (Aber SOAP funzt das hab ich schon gescheckt.)
Schöne Grüße
marvin42x
10.10.2006, 20:21
Die Wegfindung scheint ja recht einmütig zu sein. Ich für meinen Teil Schließe mich mal sicherheitshalber an.
Das TCP/IP ist aus meiner Sicht das was ich mir vorgestellt hatte.
Das mit dem Robotic Studion kann ich auch so sehen wie hier beschrieben.
Netter Gruß
Vom Konzept her würde ich die Strukturierung/Granulierung der PC-Applikationen beliebig zulassen.
Da es ja keine (praktischen) Einschränkungen gibt, wieviele IP-Connections zum "RNServer" eine Anwendung haben kann, kann auch jeder einzelne Slider ruhig seinen eigenen Socket für seine Messages betreiben.
Was sinnlos wäre, ist, wenn eine PC-Anwendung unbedingt über einen einzelnen Socken alle Connections abwickelt. Es erfordert mehr Aufwand, ev. Responses wieder zuzuordnen, also mehr Infrastruktur.
Diese Verteilung (Message->Socket) muß der RN-Server sowieso machen.
Weil ich schon begonnen habe, nehme ich mir der VB Express mal näher zur Brust und schau, wieweit sich ClassLibraries und DLLs machen lassen, die dem einzelnen Anwender den Zugang erleichtern und gleichzeitig durch Verkapselung die Standards sichern.
Es ist ja nicht jeder ein abgefeimter Programmentwickler.
marvin42x
11.10.2006, 12:38
Wunderbar,
Ich hatte die Absicht dieses Thema als Frage hier einzustellen.
Nun habe ich die Antworten schon vorher.
Ich überlege ob man das Verfahren der vorverlegten Antwort nicht ausbauen sollte. Das verkürzt so einen Thread ungemein :-) .
Thema:
Ich habe anhand der Einzelanwendungen von PicNick gesehen, dass das eine wirklich brauchbare Architektur ist.
Was sich durch die Art des Servers und der Adressierung auch nahe legt.
Ich für meinen Teil würde dann erstmal diesen Weg verfolgen wollen. Da verspreche ich mir die größte Anzahl von Vorteilen.
Danke an PicNick noch mal für die TCP/IP -Herzklappen für meine Anwendung. Jetzt läuft das ganz prima.
An diesem Vorfall kann man auch sehen wo es für Alltagsmenschen schwierig wird. Darum finde ich den Ausblick auf eine Kapselung oder jedenfalls Bereitstellung von „Protokollhandlern“ ganz wichtig für einen „Barrierefreien Zugang“(sagt man jetzt so) zum RN-Netz.
Netter Gruß
*g* An den "Herzklappen" sieht man, daß es oft die kleinen Dinge des Lebens sind, die's ausmachen *g*
Diese modularisierung und DLLisierung entspricht auch meiner Intention, da ich mich zwar gerne in ein Problem verbeiße, aber wenn's mal geht, will ich es gerne einpacken und nicht mehr reingreifen müssen, weil dann stinkt's mir.
So *schwitz*, jetzt hab ich tatsächlich meine erste VB2005Express-Turbo-Spezial IP Anwendung zusammengefummelt, die auch prinzipiell funzt.
Ich muß ja sagen, die Thread-Safe-Callback-Event-Notification-Furzerei ist ja keine Lercherl, wie man bei uns sagt.
Na was soll's.
Keine Sorge, ich werd' ab nun nicht mehr jeden Schritt publizieren.
marvin42x
11.10.2006, 15:45
Warum nicht, Du hast mindestens einen interessierten Leser.
Das kann nicht jeder von sich behaupten.
Und ab und an ein Statement vermittelt das Gefühl im Bilde zu sein.
Stell Dir mal vor Du hörst beim Autofahren nicht mehr ob der Motor noch an ist.
Musste andauernd in den Rückspiegel gucken warum Du noch fährst. Ob es der Motor ist oder der LKW hinter Dir, der dich schiebt.
So jetzt bin ich ein klein wenig abgeschweift.
Ich freu mich jedenfalls.
Netter Gruß
Dank' auch, wär ja sonst peinlich gewesen :oops:
Ich versuch' mal ganz bewußt eine absolute MinimalLösung für das IP-RnMsg-Gefummel zu machen, die man dann als Beispiel anbieten kann.
Hallo, UlrichC !
Der Status quo ist jener:
https://www.roboternetz.de/wissen/index.php/Network_Controller/PC_Version_0.1
LÖSCHANTRAG ?
Das war zu schnell, bin erst gestern nach Hause gekommen...
Helf mir mal bitte üer die Strasse und gib mir einen aktuellen Link.
CU
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.