@marvin42x
In meinem Beitrag bezog mich eher auf S²MIRS... das sollte ich mir durchackern.
Klar GUIs liegen immer auf der oberen Anwendungsebene nur ich dachte mir hier die eigene Implementation der darunterliegenden Ebenen sparen zu können.
Wenn ich warte mit meinen Beiträgen bis die Kiste soweit ist ... erzählt man mir dann vielleicht: "geht nett, mach was anders"

So etwas wurde ja schon manchmal erdacht ... das letzte mal war es eine Frau die die Laube hinterher BlueToth nannte .. wenn ich mich nicht irre.

Ja nun mal weiter
Für gewöhnlich hat man für die Programmierung Treiber und Schnittstellen... es gilt doch diese hier zu Standardisieren?

Ok, das mit den Layern klingt irgendwie wie Standard TCP/IP ...
Gar nicht so übel wenn man das wirklich in einen Contoller packen könnte.

Als ich den beginn des Thread verfolgte glaubte ich an eine Lösung wie den ODBC-Standard nur für Controller
-gepaart mit einem TCP/IP fähigen Applikationserver und einer Standard-Schnittstelle für Module
-die per Ableitung in C++/Java verwendet werden kann.

Die Protokollhackerei ist nicht wirklich prof. Einsatzfähig... jedenfalls nicht als Architektur... ich will mal erläutern was ich unter einer Standard Schnittstelle verstehe.

1. Ein Applikationsserver
-Der alle Module laden/entladen/verwalten kann.
-Mit einer Schnittstelle zu TCP/IP ... zum aufsetzen an andere Server
-Eine Schnittstellebibliothek für IC/2 und RS232 ... macht die Arbeit der Treiberprogrammierer einfacher
-Ein Master Bussines-Objekt das zur Einhaltung der Standards zwingt... hier setzen alle auf die ins System wollen
-Mit einer Oberfläche (für den händischen Eingriff) ... man will ja sehen was passiert.

2.Bussines-Objekt Styleguide
-Anleitung zur Implementation eigener Module. (Das können Treiber .. Oberflächen oder auch alg. Steuerungen sein)


Weiteres...
Zwischen den Modulen könnte reinstes XML über den Applikationserver gehandelt werden (ohne Sockets aufzureisen)
Die Module der Controller/Driver/AVR/PIC was auch immer Schicht könnten verfahren wie Sie wollten solange Sie im eigentlichen Modul (dem Treiber) kompartibel zum Appserver sind.
Für TCP/IP also von Rechner/Roboter zu Rechner/Roboter könnte SOAP (XML-Protokoll) eingesetzt werden ... aber über die Schnittstellen des Applikationservers.

Also im Grunde ein vorgefertigtes System .. das arbeit abnimmt und freiräume lässt.
In einer Hochsprache... mit Treibern zu den Controllern ... netten GUIs
Eine Art DEV Studio/Plattform/BDE für Roboter.

So hätte jeder eine Baustelle... Treiber , Server , Kommunikation, Protokolle , Oberflächen .
http://www.ulrichc.de/project/cu-www-gui/

@PicNick
Prima, ein + für die Kommunikation zwischen den Geräten.
Ein trivialer Variablenchat reicht eben nicht aus.

Im groben setze ich also doch richtig auf ... hab also nicht viel überlesen

Netter Gruß,
Chris @all

PS: Das mit der Prakmatik ist so ne Sache... Wenn man die Praxis kennt ist es einfacher im reversemode ein System zu schachteln...
Andersrum läuft man Gefahr ein System zu bastelln das hinterher keiner praktisch einsetzen möchte. (gibts ja oft)
So verwende ich Beispielsweise auch nur CORBA wenn ich muß ... und SOAP weil ichs mag und ODBC weil ichs kenn und brauch.