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ß
Druckbare Version
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
Wenn bei der Anmeldung eine GUI ein Kennzeichen liefert, wer sie wohl sei, haben wir auch da kein ProblemZitat:
Zitat von marvin42x
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)
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ß
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?Zitat:
Zitat von PicNick
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ß
Da wird zwar Bitmäßig "UART" gesprochen, aber die Kontrolle der Verbindungen zu den einzelnen Emfängern ist dann eins drauf.Zitat:
..Com-Port ein Funkmodul hängt, das sich mit mehreren Empfängern
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.
@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'.
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ß
Schon wieder mähen ?Zitat:
..niederen Alltagspflichten ..
Ü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)
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ß
Ja, so bin ich halt :-)Zitat:
..eine Längenangabe spendiert ..
Getadc(): Wird werden den Manf einspannen, der liebt das elektrische Erbsenzählen :mrgreen:
@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)
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:
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.Zitat:
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.
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:
Anm: Die Absenderangabe ist bei unserem Netzwerk meistens garnicht notwendig, denn das Netz weiß ja immer, wer den Brief in den Briefkasten geschmissen hat.Zitat:
-> 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
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)
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
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ß
Gibt's aktuelle Doku zu den fraglichen Protokollen ?Zitat:
..alternative Protokolle ..
Ich hab das im Streß etwas verschludert.
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
ho ho,
ich sprach von tcp, nicht von ip. ich sprach von start/stop sequenzen, nicht zeichen.
der war gut! #-oZitat:
Start-Stop zeichen verwendet bei Ip keiner, den ich kenne (also nicht professionell, ...
und wie willst du dann bei einem binaer-stream ein effektives framing durchfuehren?
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 !
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 !
Ich jedenfalls eher nicht. :-)Zitat:
.. RobotLiga..
@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
@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ß