Druckbare Version
https://www.roboternetz.de/wissen/in..._Controller/PCZitat:
Zitat von UlrichC
https://www.roboternetz.de/wissen/in...pezifikationen
https://www.roboternetz.de/wissen/in...ller/PC_Praxis
Ja, alles Baustelle, immer den Helm aufsetzen.
Gehbehinderte bitte immer den Stock mitnehmen :mrgreen:
@PicNick:
Baustelle:
Da ich ja beschlossen habe meine Anwendung zu zersägen stellt sich die Frage an welcher Stelle.
Im wesendlichen, denke ich, ist das schon klar. Ich würde aber gerne die Schnittstelle genauer mit Dir besprechen.
Du hast ja gesehen, dass ich den TCP -Kram bei mir schon in einer Klasse beheimatet habe.
Ich denke wenn ich Dich richtig verstanden habe, wird das auch konzeptionell so bleiben, nur kompakter und leicht zu handhaben.
Mein Bedarf wäre jetzt im Vorfeld entweder eine grobe Übereinkunft der Klassenaufrufe.
So etwas wie ClientSend(data,lenght), oder was in der Art.
Oder einen rudimentären Baustein. Der muss noch nicht richtig arbeiten aber zum ran denken zu gebrauchen sein. Das könntest Du mir mailen oder ähnlich weil das noch nichts aus dem öffentlichen Programm wäre.
Das hätte den Vorteil für mich, dass ich unabhängig von der endgültigen Fertigstellung weiterbasteln kann und am Ende nicht so arg danebenliege falls Das Konzept doch noch anders aussieht als ich es jetzt sehe.
Netter Gruß an den Hotspot südlich von mir
Ich würde sagen, wir behalten in der Version 0.1 konsequenterweise an der Prämisse fest, daß eine ID (class /Ident) gesamtsystemweit eindeutig ist. Das, was sich dynamisch ändern kann, ist der "Pfad".
Momentan, auch bei deiner GUI, isses ja so, daß jeder Slider ja seine Message mit einer Zieladresse (Class/ident) losschicken könnte und sie würde ankommen
Momentan tut RN-SERVER ja immer noch alles IP-Seitg broadcasten, d.h. auch irgendein Progress-Bar könnte seinen ADC-Wert nach der Absender Cls/Ident problemlos rausfiltern.
Also, eigentlich macht deine GUI ja ohnehin genau das, soweit ich das mitgekriegt habe. Ob dein Gui nun überladen ist oder nicht, im Prinzip is ja alles da.
Was wir da brauchen, ist jetzt eine definitive u. verbindliche Liste der IDs, damit das jeder einprogrammieren kann.
Ein Feature, was wir machen sollten:
Man kann sich von RN_SERVER die ID-Liste abholen, und jedes VB-Gerät kann sich dann aus einer Combobox die ID's selbst zuordenen, die er braucht.
Das sollt' man dann aber schon speichern können, damit man es nicht nach jedem Start wieder machen muß.
Nächster Step: Auch die IP-Clients liefern eine Art "I-AM" Liste ab, damit RN_Server auch zwischen den GUIs routen kann.
*luftholen*
Next: VB-seitig könnt' ich mir vorstellen, das jeder unserer "ID-Classen" auch eine VB-Klasse entspricht. Dann könnt man z.B. Servo-Slider einmal runterprogrammieren, und dann beliebig wo einbauen.
Also "LEGO" Prinzip.
Wohl gesprochen weißer Mann:
Insgesamt:
Bin ich ganz Deiner Meinung.
verbindliche Liste der IDs: Sehe ich auch so.
ID-Liste abholen und Combobox: So soll es sein.
IP-Clients liefern eine Art "I-AM" Liste ab: Die Götter haben meine Gebete erhört ;-).
Würde jetzt jemand beispielsweise auf die Idee kommen, die Funktionalität eines Orchestrators auszubilden. Könnten wir ihm sagen: Kein Problem, es existiert zu jeder Zeit eine aktuelle Kenntnis über den Netzstatus mit Informationen über alle Netzteilnehmer inklusive deren Adressierbarkeit. Aber das wäre natürlich nur dann wenn jemand auf die Idee käme.
"LEGO" Prinzip: freu freu, Das wird ein schönes System.
TCP-Class:
Ich gehe jetzt mal davon aus das sich da erstmal strukturell nicht viel ändert. Und klinke den jetzt in die jeweilige PC -Applikation ein.
Edit:
TCP-Class meint hier die Programminterne TCP/IP-Funktionalität. Nicht die Class aus der Adresse.
Netter Gruß
Wir werden in der Wiki einfach eine Liste beginnen, zumindestens das Wichtigste und AllgemeinsteZitat:
verbindliche Liste der IDs:
Für solche Sachen werden wir gleich in der "Klassenliste" fixieren (s.o), wie die entsprechenden "cls-ident" heissen, dann geht das ganz locker.Zitat:
..."I-AM" Liste abliefern............ID-Liste abholen
wenn wir mit den "Classes" strukturieren, ist vielleicht ein "treeview" übersichtlicher. Das können wir aber halten, wie wir wollen.Zitat:
.. Combobox:
so habe jetzt mal die neuste version vom rn_server runter geladen.
mal sehen wann ich richtig zu testen komme der schnell test war erfolgreich.
Im Layer0 hat sich ja nix geändert so das ich schnell an den rest gehen kann. Leider verstehe ich die https://www.roboternetz.de/wissen/in...pezifikationen
Seite nicht so wirklich.
Ist zb. HBT Heartbeat das erste Byte nach Target und source ?
wenn ja wie setzt sich Target und source zusammen ?
Ich werde mit wohl einen TCP -> Multicast Konverterschreiben dann kann ich meine Applaktion am Multicast stream lauschen lassen.
Warum ? ganz einfach dann kann ich in meinem Netz überall einfach lauschen und brauche keine IP adressen zu konfigurieren (DHCP).
Mehr als ein Robo im netz ist die an und abmeldung auch leichter.
Aber bis dahin werde ich noch viel Zeit brauche da ich meine Hütte her noch winterfest bekommen muß. Aussdem muß ich den Roboter kram erst mal wieder aus packen und sortieren. (Umzug)
@PicNick:
was sehe ich im log file ?
Gruß
Große Freude, NumberFive ist wieder da :-)
@NumberFive
Ich hätte großes Interesse auf der Basic -Seite ein bisschen Synchronisierung zu betreiben.
PicNick greift mir ja jetzt immer unter die Arme wenn es stockt und ich denke Projektseitig sind wir auch einer Meinung.
Das bedeutet praktisch, dass ich, wenn fertig, auch seine TCP/IP –Funktionalität verbauen werde.
Ich habe selber eine die jetzt läuft aber Standardisierung ist in.
Meine ersten Demo -Komponenten laufen schon und ich würde gerne mal ausloten ob wir was Gemeinsames haben.
Mit gegenseitigem Austausch von was weis ich.
@PicNick
Entwicklungsstand:
Es existieren jetzt 3 schlanke Mehr –Instanzfähige Einzelkomponenten die am Netzverkehr teilnehmen können.
Wer will kann dann 200 Servos über 200 Slider ansteuern :-)
Oder 100 AD –Wandler im Auge behalten :-)
Irgendwann bräuchte er natürlich noch mehr Monitore :-)
Die konfig Files dafür sind jetzt in Arbeit
Alles Demo, aber durchaus schon Funktionsfähig.
Simulator:
Wie schon bemerkt besteht ein Bedarf an einem künstlichen Datenstrom um Netzwerk-Komponenten zu testen, ohne jedes Mal die Hardware an den Tisch schieben zu müssen.
Mein Vorschlag:
Der RN –Server hat neben den normalen seriellen Schnittstellen ein Pseudo- –Com Port der eigentlich TCP/IP Port ist.
An den kann sich jeder einen Simulanten ranhängen.
Da kann es einen Standard –Simulanten geben aber auch Eigenbauten.
Dadurch würden wir ohne große Änderungen am Server im Konzept bleiben.
Ich habe auch keine darüber hinaus gehende Hintergedanken dabei…..
Server:
Kannst Du das Path-List Fenster größenveränderbar machen?
Ich freu mich immer so an dem Beteiligten –Baum.
Und ich sehe dann immer auf einen Blick wer dazukommt.
Netter Gruß
Tach, Männer !
@No-5 : HBT ist selbst ein Target
TCP bzw. Heartbeats dienen dazu, auch verlorengegangene / inoperable Teilnehmer erkennen zu können. Wenn alles nur forward-sendet, ist man nie sicher, wer dran hängt und wer nicht.
Im Moment geht ja alles noch mit Sichtkontrolle, aber wenn's richtig remote wird, ist die Sache verschärft.
Weiters sind durch TCP auch regelrechte Sessions möglich, mit eventuellen Geräte-reservierungen, d.h. wenn im Netz einer an einem Servo rumwerkt, kann es nicht gleichzeitig auch ein anderer tun. (ist aber dzt. nur eine Option)
Marvin: der rn-server ist dzt. noch wirklich ein sauhaufen. Die Skalierung der Fenster nach Window-größe ist ein Gefummel, das ich mir erstmal gespart habe, aber einfach größer ist wohl kein Problem.
:-) für 200 Servos brauch' ich auf jeden Fall 194 Simulanten. :-)
DLL für VB etc.: hab das angetestet, kein Problem, eigentlch sogar sehr einfach.
Status VB 2005:
MrNiemand war so nett eine frische XP Installation für einen Praxistest für die Problematik rund um
Visual Basic 2005,
Framework 2.0 und
Window Installer 3.0.
Zur Verfügung zu stellen.
Das Ergebnis war recht beruhigend.
Wenn die notwendigen Komponenten, also Framework 2.0 und Installer 3.0 installiert sind läuft das.
Diese Komponenten sind in Vista standardmäßig enthalten. Womit sich in ferner Zukunft der Aufwand verringert.
Was noch nicht geht ist eine Namensauflösung der Ziel –IP.
Es muss also derzeit noch die IP –Adresse eingegeben werden.
Eine tragbare Einschränkung erstmal.
Ansonsten läuft das grundsätzlich gut, eben auch quer durch die Republik.
Die Kontrolle ob 100 % jedes Datenpaket auch ankommt ist zurzeit noch nicht gegeben.
@PicNick:
Am neuen Server ist irgendwas mit der Durchleitung , was der alte vollständig macht.
Ich nehme für Datendauerläufe deswegen noch den alten samt alter µ Systeme.
Da im Moment eh alles am fließen ist, ist das nur als Hinweis zu sehen, wenn Du den mal am Wickel hast. Da Mein Programmer gerade den Geist aufgegeben hat kann ich noch nicht mal herausfinden wer hier nicht folgsam ist.
Netter Gruß
Ps. Wir machen bei reger Nachfrage ein Simulanten Heim auf :-)