RoboterNetz.de :: Thema anzeigen

NumberFive · Verfasst am: 10.06.2004, 09:26

Hallo Leute,

habe mal ne fragen wenn dieses Forum schon eine Standart Platine für robter
entwickelt hat. Könnten wir doch auch ein Standart software oder nicht ?
Ich würde sie shreiben wollen natürlich nicht alleine aber in gemeinschaft schon.

Und so stelle ich mir das Teilt vor: Auf dem robi gibt es ein PC der unter
Win200 läuft. Es gibt ein Miro controller der mit dem PC Kommuniziert (RS232). Als add on gibt es ein tcp verbindung zu Control Center (Zweiter PC)
das könnte man leicht über WLan machen. Eine MySql db ist das gehirn des robis. Der ablauf im Prggramm kann jeder slbst bestimmen da der Ablauf in der datenbank liegt. Der Controller ist egal da serial nun mal fast alle können.

Also Interesse ? dann kräftit Posten.
Es gibt Teile dieser Software schon ich erzäle nix was nicht zu programmieren währe. An alle die menen nicht programmieren zu können
Auch interresse äussern ich brauche für meinen Robi noch hard von der ich kein Ahnung habe.

Gruß

Flite · Verfasst am: 10.06.2004, 10:04

Hallo Number Five!

Klingt sehr interessant, was du da vor hast.

In welcher Programmiersprache möchstest du das ganze realisieren? Ich würde etwas plattformunabhängiges vorschlagen, so dass das Programm evtl auch auf Linux laufen würde.

Was soll das Programm alles verarbeiten / steuern? Was macht der uC?

Ich würde mir das im Moment so vorstellen:
Der uC tastet mittels Sensoren die Umgebung ab. In der Datenbank kann man dann (mit einer schönen Benutzeroberfläche) einen Sensor hinzufügen, seine Position am Roboter angeben und ihm eine Adresse zuweisen. Dieser Sensor wird dann vom uC eingelesen und von Programm über die Adresse abgefragt.

Ebenso kann das Programm Steuerbefehle geben (also die Motoren steuern).

Dann kann man in die Datenbank evtl. Scripts programmieren, in denen man fertige Ausweichmanöver, bzw. Suchmanöver (z.B. für Lichtsuche) einspeichert.

Grüße
Flite

NumberFive · Verfasst am: 10.06.2004, 10:48

Hallo Flite,

na so ähnlich war es gemeint.

Es gibt 3 Programme:

Den Konfigurator der schreib die Konfig in die Datenbank.
Die Robotcontroll die die Config liest und den Controller abfragen und so weiter. Und den Monitor der über WLAn mit dem Roboter kommuniziert.

Die Funktion des Cotroller hast du richtig verstanden so war das gemeint.
Weiteteil wohlte ich in C++ schreiben da ich da schon ein bisschen was fertig habe. Das mit de plattfrom unabhängigkeit wird wohl nicht gehen da
wir zu dicht an die Hardware müssen um schnell genug zu sein. aber Es steht natürlich jedem frei die C++ Codes nach Linux zu portieren.

Und noch ein klares statment java kommt nicht in betracht und dot.net auch nett. Den configurator und den Monitor könnte man in delphi shreiben
da hat man das mit der Oberfläche leichter. Ober wenn es sein muß in VB aber dann VB 6.0. Was ich bei mir noch rein mache ich ein Programm zu analysiren des Viedeo bildes. Das kann dann sein Erkennise auch an dier RobotControl weitergeben.

NumberFive · Verfasst am: 10.06.2004, 10:57

nachtrag:

wo die Sensoren sitzen ist für das prg nicht wichtig da die ablaufstuerung(script) sagt was er tut wenn das un das kommt alle sensoren bekommen ein nummer (1-254) und werte bereicht von 0-255 das sollte nach mein dücken reichen. eben so die Aktoren.

So seid fünf minuten läuft mein AVR jetzt kann ich weiter testen

Gruß

Johannes · Roboter Experte Anmeldungsdatum: 22.11.2003 Beiträge: 501

Moin Numberfive,
hast du dir schon mal meine Jufo-Arbeit runtergeladen? Ich habe so etwas ähnliches programmiert und werde demnächst die nächste Version starten.

Was mir vorschwebt: Eine Software, mit der es möglich ist, verschiedenste Hardwarekomponenten zu verknüfen. Das bedeutet: Man kann einen Roboter mittels eines Treibers, der speziell geschrieben werden muss (aber standardtreibver sind natürlich auch denkbar) in die Software einbinden.

Der Treiber kann nun Datenbereiche (z.B. Variablen) anmelden. Über diese Variablen kann dann die Software Daten von dem Roboter bekommen und ihm schicken.

Nun ist es mölglich, Beziehungen zwischen diesen Variablen zu setzten. Es gibt eine Scriptsprache, in der Funktionen definiert werden können, die ausgeführt werden, wenn sich beispielsweise eine Variable ändert. In diesem Fall kann dann das Script eine Variable einer anderen Hardwarekomponente ändern. Als Beispiel könnten dann so Roboter wissen, wo die anderen gerade sind, etc.

Die Software bietet weiterhin die Möglichkeit, Daten des Roboters anzuzeigen. Diese Anzeigemöglichkeiten werden als Plugins eingebunden, sodass man sich auch selbst ein spezielles Anzeigefeld programmieren kann. Diese Felder können dann mit Variablen verbunden werden. Natürlich können solche Plugins auch Variablen verändern und nicht nur anzeigen.

Dieses Problem habe ich mit ActiveX-DLLs gelöst. Bei der anmeldung wird dem Plugin ein Objekt übergeben, mit dem auf die Daten der Software und somit auch auf die Daten der eingebundenen Hardware zugegriffen werden kann.

Das alles funktioniert bei mir ganz gut, ich habe es mit Visual Basic geschrieben. Leider, und deshalb werden wir wohl nicht zusammenarbeiten könne, will nun die neue Software in JAVA schreiben. Auch ich wäre ein einem Gemeinschaftsprojekt interessiert.

Der zweite Schritt wäre dann eine Software für den Roboter selber. Du weißt, dass ich ja auch auf meinem nächsten Roboter einen PC installieren will. Vielleicht kann aber auch eine einzige Software diese ganzen Dinge abdecken, je nachdem, welche Plugins registriert werden. Die Roboter-Software bräuchte ja keine Anzeigeelemente, die PC-Software aber vielleicht schon.

Naja, vielleicht können wir ja wenigstens Ideen austauschen. Aber ich hatte vor, einige Funktionen auch mit C++ zu schreiben, gerade die Dinge mit den Plugins. Aber die Grundstruktur wäre schon ganz gut gelöst mit Java, besonders die grafischen oberflächen. Die C++-Routinben könnte man dann ja für mehrere Systeme kompillieren, oder erst einmal bei Windows bleiben.

Aber auf jedenfall ne interessante Diskussion, besonders weil ich sie schon vor kurzem selbst aufmachen wollte.

Schaut mal in meine Arbeit, ganz hinten bei "Control Desk":
http://www.mindrobots.de -> zum Download runterscrollen.

Gruß
Johannes

Johannes · Roboter Experte Anmeldungsdatum: 22.11.2003 Beiträge: 501

P.S. Ich lege bei so einer Software großen Wert auf Konfigurationsmöglichkeiten und offenen Schnittstellen. Was pezielles kann keiner gebrauchen. Das Verhalten des Roboters sollte schon durch eigenen Quellcode festgelegt werden können. Die Software sollte nur als Unterstützung dienen und einfach zu verwenden sein (auch von der programmiertechnischen Einbindung eigener Erweiterunge).

NumberFive · Verfasst am: 10.06.2004, 15:30

Hallo Status bericht:

Folder Test aufbau ist realiesiert:

Termil VT100 macht den controller mit 38600 Baud.
SensorCatcher kümmert sich um die verabeitung der serialen daten

Daten format AXXE A SensorNummer SensorValue E
MessageCatcher ist per Com mit Sensorcatcher verbunden.

MessagesCatcher hat folgende Funktionen:
Sprachausgabe am PC Lautsprecher
Lenbensüberwachung so weit möglich (Rest und rechner neu start fehlt noch)
Verbindung zu Mysql Datenbank
Programm interpreter

Der Programm Interpreter wird jedes mal auf gerufen und durch läuft das programm wenn neu sensor daten an fallen. Auf die Sensor daten kann man per variable zu greifen.

Anbei nun das programm das interpretiert werden kann:

insert into PrgCode (RunningNumber,Code) values ( 0,'IF SENSOR01 = 01');
insert into PrgCode (RunningNumber,Code) values ( 1,'Trace war gleich');
insert into PrgCode (RunningNumber,Code) values ( 2,'ELSE');
insert into PrgCode (RunningNumber,Code) values ( 3,'Trace war nicht gleich');
insert into PrgCode (RunningNumber,Code) values ( 4,'ENDIF');
insert into PrgCode (RunningNumber,Code) values ( 5,'IF SENSOR53 = 53');
insert into PrgCode (RunningNumber,Code) values ( 6,'Trace war gleich');
insert into PrgCode (RunningNumber,Code) values ( 7,'SendMessage SensorWatch Test');
insert into PrgCode (RunningNumber,Code) values ( 8,'ELSE');
insert into PrgCode (RunningNumber,Code) values ( 9,'Trace war nicht gleich');
insert into PrgCode (RunningNumber,Code) values (10,'ENDIF');
insert into PrgCode (RunningNumber,Code) values (11,'Trace vor ende');
insert into PrgCode (RunningNumber,Code) values (12,'END');

NumberFive · Verfasst am: 10.06.2004, 15:51

Hallo Johannes,

ich mag halt kein java aber was heist das schon in unserem fall.
Das jedemen zu programmieren gibt. Nein dein arbeit habe ich nocht nicht gelesen war aber auch unterverschluß. Aber warum willt du auf java gehen ?
Allso irgend macht man schell prg als in delphi wenn man ein oberfläschen brauch. Mal ne frage wie komme ich von java aus an andere dinge
gibt es com oder dll aufrufe ?

Aber was du da beschreibst kann mein teil doch schon fast.

Ich habe zur zeit drei EXE SensorCatch, MessageCatcher, RoboCam

Master ist MessageCatch der ein Com interface zu verfügung stellt.
An diesem Meldet Sich so die Cam wie Auch der SensorCatcher an
DAs Interface ist sehr small hat nur Zwei Events Halt und MsgOut
Und drein funktionen Connect MsgIn und Trace

Im MsgIn oder MsgOut wird immer ein BSTR durch geben der So aussieht
MSG|ALIVE
MSG|DATA|Test
ACTION|MOTIONDETECT|

das sind beispiele
das mit den Addon's ist noch eine Idee

Aber jetzt werde ich erstmal dein Arbeit lesen

Gruß

Johannes · Roboter Experte Anmeldungsdatum: 22.11.2003 Beiträge: 501

Moin,
schau die mal meine Arbeit an. Wir müssen erst einmal auf den selben Nenner kommen. Bei mir ist es so, dass ich noch keine konkrete Anwendung vor Augen habe, sondern nur Ideen, was man gebrauchen könnte.

Mit Java kann man nicht auf dlls zugreifen. Das sind halt Sachen, die es nur bei Windows gibt. Aber Java kann mit C++-Code kommunizieren. Mit Java könnte man dann die Oberfläche, also die gesamte Benutzerschnittstelle machen. Der große Vorteil wäre, dass man dann auch die Java-Plugins auf verschiedenen Plattformen verwenden könnte. Man müsste dann nicht zwischen den verschiedenen Betriebsystemen einen Struch ziehen. Nur die Grundsoftware wäre mit den C++-Routinen speziell, was aber nicht so problematisch wäre.

Aber man müsste die Oberfläche nur einmal machen.

Ich programmiere schon lange mit Visual Basic und möchte mich nun von WYSIWYG trennen. Aufwendige Sachen sind einfach schwer zu verwalten, unübersichtlich und eingeschränkt. Ich bin mir da mit Java sehr sicher.

Wenn wir zusammenkommen und eventuell sich noch ein paar Leute finden, dann könnten wir ein Gesamtschema erstellen. Da wir ja schon Erfahrungen mit den Sachen haben (schließlich habe ich schonmal so eine Software geschrieben und du bist ja auch gut dabei) würden wir bestimmt etwas Gutes zu Stande bringen.

Gruß
Johannes

Johannes · Roboter Experte Anmeldungsdatum: 22.11.2003 Beiträge: 501

Noch etwas zur meiner momantanen Software (Control Desk): Da gibt es nur die Möglichkeit der Variablen, Daten auszutauschen. Bei einer eventuellen neuen Version würde ich einen Gateway-Kanal vorschlagen, den alle eingebundenen Komponenten abfragen. So wäre zum Beispiel eine Fernsteuerung wesentlich einfacher zu realisieren.

Gruß
Johannes

NumberFive · Verfasst am: 10.06.2004, 17:30

Hallo Johannes,

So jetzt habe ich deine Arbeit das erste mal durch und habe sie mir aus gedruckt. Werde sie sich noch eins zwei mal lesen müssen bis alles bis ins kleinste vertsanden habe aber das wird schon. Mal grundsätzlich habe ich auch ein großßes interesse mit dir zusammen zu arbeiten. Druch die
Verwendung von Com braucht ich in mein konzept nicht zu pollen
da ich event habe. das hei wenn jemand das möchte kann er es so fort weitergeben. es so gar in weitenteil gethreaet so das kein behinderungen auftreten. Was ich vor hin ver gessen habe die Tcp verbindung zum Control PC gibt es auch schon.

Nur mal ganz ehrlich ich finde es sehr schwer das alles hier rüber zu bringen aber ich werde es weiter versuchen.

Hast du dir mal alle bilder von mir auf mein HP angesehen ?
da war auch eines der Software drauf.

Wo mir noch ein bischen das verständins fehlt ist der Teil mit der Hardware
die Hängt doch auch bei dir adem controller oder nicht ?

Oder ging es da mehr um die Tür die du in deiner aus arbeitung ansprichst ?
was ich mir noch gut vorstellen könnte ist folgendes du kannst in dem prg das ausgeführt wird den Befehl eingeben Send TCP 127.0.01 DATA
dann könnte ich die daten einfach an ein adresse schicken. im gegen zu mach ich ein port auf an dem man was schicken das auch wieder die Programm verarbeitung an stösst. So wäre man Platform und soft un ab hängig un niemand kann das habt programm zu stehen bringen. Für die Remot verbindung ist so was schon implementier nur da steht die Verbidung so das der Remote pc wenn er einmal angemeldet immer daten schicken kann. (Fernsteur quasi um sonst). Um tcp nachrichten zu empfangen sollte es auch in java was geben.

So jetzt werde ich mal ein bild malen damit klar wird was ich meine

Gruß
Warum willst du auf dem roboter PC ein desktop für was ?

Johannes · Roboter Experte Anmeldungsdatum: 22.11.2003 Beiträge: 501

Moin!

> Warum willst du auf dem roboter PC ein desktop für was ?

Nein, will ich gerade nicht! Der Grundstock sollte gerade ohne irgend eine grafische Oberfläche sein.

Ja genau, mache mal eine Skizze. Auch ich werde vielleicht nochmal etwas hier posten, um meine Vorstellung darzustellen. Dann können wir schauen, was wir von dem allen gebrauchen können und wie man es realisieren könnte.

Also mit der Hardware ist das folgendermaßen. Meine Software läuft momentan nur auf dem PC. In ihm ist ein Treiber eingebunden, der per Funk mit dem Controller kommuniziert. Auch eine elektrische Tür hätte einen Treiber. Wenn der Roboter nun durch die Tür will, schickt er per Funk eine Nachricht (also er setzt eine Variable, aber das würde ich dann lieber mit so einem Gateway lösen). Nun hat der Treiber der Tür eine Variable (Status offen oder zu). Und es gibt eine Beziehung zwischen der Variable des Roboters und der Status-Variable der Tür, sodass der Status auf offen gesetzt wird, wenn der Roboter etwas entsprechendes sendet.

Dazu muss ich aber sagen, dass zum Zeitpunkt der Präsentation das noch nicht realisiert war, sondern nur theoretisch machbar gewesen wäre. Wir sind mit dem Thema nicht ganz fertig geworden, und darunter fiel auch die Anwendung unserer Software Zwinkern

Aber da es bei uns um den Ablauf des Systems ging, hat es für den 3. Platz gereicht.

Gruß
Johannes

Johannes · Roboter Experte Anmeldungsdatum: 22.11.2003 Beiträge: 501

Ich war eben auf deiner Seite, aber ich habe kein entsprechendes Bild gefunden. Kannst du nochmal den genauen Link sagen?

Gruß
Johannes

P.S. Ich bin jetzt für zwei bis drei Stunden nochmal in der Schule, aber dann komme ich nochmal ins Forum. Und dann geht es hier auch von meiner Seite weiter Zwinkern

NumberFive · Verfasst am: 10.06.2004, 18:17

nun mal ein übersichts bild
bis auf den roten teil ist alles exitent natürlich fehlen noch gewisse internet funktionen aber es tut und läst sich aufbauen.

Was meine Aussage zu Thema Sensor angeht die Menge liegt Zur zeit nur aun den verwendeten Protokoll zur RS 232 das habe ich hatlt mal so definert.

A<sensornummer 1-254><sensorwerte1-254>E

Also genau vier Bytes lang 0 geht nicht da ich das nicht durch die COM schicht bekomme wenn ich den standart nich verlassen möchte. wenn Also
so ein telgramm von Controller kommt geht es weiter an den MessageCatcher der setzt dann die Variable SENSORXX mit dem gelieferten wert ist die variable nicht vor handen wir sie erzeugt.
Dann wird der Prg interpreter gestartet.
In meiner Idee währe es so garmöglich das Prg zu lauf zeit zu wechseln. den der MessageCatcher lädt da prg zu programm start.
das heist mann kann es in der db aus tauschen. wenn dann das neu programm haben will braucht man nur per remote sagen neuladen und schon kann es weitergehen.

NumberFive · Verfasst am: 10.06.2004, 18:22

Hallo Johannes

Natürlich geht es dann weiter du hast mein "Kampf" Geist geweckt.

Johannes · Roboter Experte Anmeldungsdatum: 22.11.2003 Beiträge: 501

Moin Numberfive,
vielen Dank für die Zeichnung, ich werde nun versuchen, deinen Ansatz zu verstehen Zwinkern

Könntest du nochmal genau erklären, was der MessageCatcher für eine Aufgabe übernimmt?

Gruß
Johannes

Johannes · Roboter Experte Anmeldungsdatum: 22.11.2003 Beiträge: 501

Zur Information: Obwohl ich mich gerade mit Numberfive per ICQ getroffen habe, haben wir entschieden, unsere Diskussion hier fortzuführen, damit andere User alles mitverfolgen können und eventuell auch ihre Ideen beisteuern können.

Zu den Programmiersprachen: Ich denke schon, dass wir die Stärken der Programmiersprachen ausnutzen sollten. Wir müssen nur klare abgenzungen machen und einen Kommunikationsweg finden, auf den von beiden Seiten zugegriffen werden kann. Ich habe von dem ganzen TCP ehrlich gesagt keine Ahnung, vielleicht könntest du mir das mal kurz erläutern.

Gruß
Johannes

NumberFive · Verfasst am: 10.06.2004, 21:08

Hallo johannes,

also der MessgeCatcher mach eingegenlich nicht so viel und doch alles
klingt komisch aber so ist es.

Er stell ein COM interface zu verfüggund das vo anderen Application genutzt werden kann. besser als dll laden den da läuft das andere im eingen process raum un kann mich nicht abschissen.

wenn jetzt ein nachricht über das TCP inface kommt oder über das COM interface versuche er sie zu interpretieren. ES gibt nachricht die intern gehändelt werde und nachrichten die als daten interprtiert werde.
wenn jetzt ein nachricht kommt die daten enhält
werde die variablen gestzt und der programm interpreter gestarten.

Der Programm Interpreter hat zur zeit zwar nicht viel funktion aber der läuft auch erst seit heute. Zu beispiel kann der jetzt be bestimmten variablen zu ständen daten wo hin schicken.

Beispiel:

SensorCatcher schickt SENSORDATA|SENSOR|63|VALUE|63
MessageCatcher Setzt jetzt die Variable SENSOR63 auf 63 und
Startet den programm interpreter wenn du dir das prg weiter oben im Thread an guckst was du was am Controler an kommt oder ?

NumberFive · Verfasst am: 10.06.2004, 21:27

zu thema tcp:

also das ist ein netzwerk protokol aber ich denke das weiß hier jeder.
wo es genaug im osi modell liegt weiß ich auch nicht mehr. jetzt gibt es funktion (meines wissenes in alle sprachen) mit den man die dies packete lesen und schreiben kann. einer ist halt server und einer Client. bei mir läft das dann so die ersten 2 bytes sind die länge des folgenden string der beliegt sein kann auser 0 byte das liegt aber an meiner porgrammierung.

Aufgrund de nachr frage von Johannes per Icq:

dll -> seid windows 2.0 programm Code der zur laufzeit in das programm geladen werden kann der code läuft im selben process raum. der programmier muß das interface für die Funktionen kennen sonst kann er sie nicht an sprechen.

COM dll oder inprog server imprinzi das selbe wie ein dll aber die interface beschreiung ist standart und die berschreibung wird in der regestry ab gelegt jeder kann sinch das interface an guken.

exe mit com interface oder out proc server stell ein interface bereit aber die soft ware läuft in ein eigenen process bereich. für das marshalling zeich windows verantort lich aber programmier fehler. schicken ein ander nicht unbedingt ab es seiden man schaft es windows zu killen.

es gibt dann noch dcom aber das würde jetzt zu weit führen.

Johannes bei TCP auf dem local rechner geht es natürlich genauso wie über netzt. Mach ich in der firma sehr oft. Ausserdem du auf Mysql zu greifst gedas so oder auf ein Oracle oder es gibt tausend fällt wo das dein windows kiste macht.

Gruß

Johannes · Roboter Experte Anmeldungsdatum: 22.11.2003 Beiträge: 501

OK, danke für die Erklärung, ich werde mich mal über diese COM-Objekte informieren. Aber ich nehme mal an, dass es die nur unter Windows gibt.

Wäre es nicht theoretisch möglich, alle Kommunikationen der Einzelkomponenten per TCP zu regeln? Das wäre natürlich gar nicht mal so unpraktisch, da Plugins auf mehreren Rechnern verteilt sein könnten.

Wenn ich mal an meine Software denke, könnte man dann ja per Netz auf einen Server zugreifen und Sensordaten abfragen. Natürlich nur mit entsprechender Autentifizierung.

Sag mal, ginge das nicht nur mit exe-Files und TCP?

Gruß
Johannes

NumberFive · Verfasst am: 10.06.2004, 21:51

hallo johannes,

Com Dlls sind ActivX-dll nur ohne Oerfläsche nur reiner Code.
Die kennst du laut deiner Ausführungenn aus deiner HP.
Alle Componeten auf TCP Basis an zu binden fände ich
aus Geschwindigkeits gründen nicht so dolle aber ist durch aus programmierbar. Aber was spricht da gegen das produkt so zu bauen das es zwei standart Addons gibt den SensorCatcher und die Video Erkennung.
wenn dann wriklich mal die protierung auf Linux kommt kann dann immer noch mal drüber nachen denken. das zu ändern. der Sensor catcher
kann ja so erweitern das er ein etwas groß zügigeres Interface hat as das bis jetzt ist. dann pass auch wirklich jeder Controller dran. In anbetracht meiner erfahrungen hier im Forum braucht jeder so ein programm was die seriale ein liest. und das viedeo progr finden auch guten an klag. also
könnte man schon ein paket draus machen.

Achso ein add on habe ich noch mehr aber das wurde von mir nicht mehr gepfelgt da kann den RCX von Lego mit ansteuern. Aslo rund um eigendlich schon relativ komplett um ein robi mit PC zu bauen.

Wenn ich mal spinne:
Standart Board hier aus den netzt unsere Software drauf und roboter fährt.
Fast wie ein baukasten den mach fast unendlich erweitern kann. den der Avr ist frei programmierbar und der Messages catcher in gewissen grenzen auch. Man könnte bei dem konzept sogar ein Internet Client bauen.
Dann kann jede den robi per web seite steuern. dann musst halt nur noch ein zweite cam für bild auf den robi machen.

Johannes · Roboter Experte Anmeldungsdatum: 22.11.2003 Beiträge: 501

Ja, wunderbar. Also wie müssen aber die Sachen unbedingt logisch trennen.

Grundstruktur: Entspricht soweit ich es verstanden habe deinem MessageCenter. Es sollte die variablen verwalten etc.

Addons: Die habe ich früher Plugins und Treiber genannt, aber die kann man zusammenfasssen. Schließlich ist alles ein Programm, dass sich in das System einklinkt.

Was mir allerdings noch nicht ganz gefällt ist die Sache mit dem Sensor-Catcher und der Cam. Im Prinzip ist das alles wunderbar, und wir könnten dann natürlich auch Addons programmieren und mit zur Verfügung stellen.

Ich habe nur etwas mit der Schnittstelle Probleme. Ich habe das Gefühl, dass die Sache an dieser Stelle zu speziell wird. Wenn COM-DLLs die Ähnlichkeit mit ActiveX-Dlls haben, wie du es oben beschrieben hast, dann muss doch in dem Grundprogramm ein Verweis auf diese dort sein.

Wie soll es dann möglich sein, auf andere neue Addons zuzugreifen? Also, wie sollen dann neue Addons hinzugefügt werden. Das müsste man dann per Late Binding machen (wie ich es auch im Moment habe)...

Wenn wir ein Cam-Addon haben, sollte es meiner Meinung nach möglich sein, beispielsweise auch zwei Cams anzusteuern. Auch wenn es kaum jemand macht, wäre das prinzip ganz gut.

Wollen wir uns nicht auf eine Schnittstelle erst einmal beschränken? Und ich glaube nicht, dass die GEschwindigkeit zu gering werden würde, wir übertragen ja keine Bilder o. Ä..

So, morgen geht es weiter. Aber ich glaube, es wird Zwinkern

Gruß
Johannes