Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt

[Johannes]

Hi,
das wäre schön, wenn smirs mal verwendet wird. Bald sind Semesterfereien und dann werde ich mich auch wieder an meinen Roboter setzten, auf dem dann auch smirs laufen soll. Bin dann natürlich auch bereit, die Main Control weiterzuentwicheln und Schwachstellen auszubessern. Das System ist ja relativ vollständig, wurde jedoch noch nicht so richtig auf Herz und Nieren getestet. Momentan sind die JAVA und Win-Versionen nicht kompatibel, da ich eigenständig den MMC-Mode entwickelt und in der Java Version implementiert habe, der die Vernetzung von mehreren Robotern ermöglicht.

Wie schon angedeutet, sind die Java-MC, eine .NET-DLL sowie ein VB.Net-Beispielprogramm auf http://smirs.mindrobots.com verfügbar. Dazu stehen einige Informationen über die Funktionsweise des Systems beschrieben.

Also wie gesagt, ich würde mich freuen, wenn wir was daraus machen, denn es war ne Menge Arbeit und es wäre schade, wenn sie nur für mich allein war.

Gruß
Johannes

[PicNick]

Was ich noch nicht weiß (vielleicht auch schlecht gelesen ):

Was ist Controllerseitig schon da ?

[Johannes]

Controllerseitig hat Numberfive eventuell schon was gemacht. Allerdings hat das nichts mit smirs zu tun, da dieses nur von Rechner zu Rechner funktioniert. Wie auch sonst, die Controller sind ja alle verschieden.

Gruß
Johannes

[PicNick]

Nu, ein Portfolio oder Specs kann man trotzdem anlegen.
Was man dann braucht, ist eine Bridge, Router oder möglich gar ein Gateway auf einem der Rechner, der IP auf "smirs232" umsetzt und vice versa.

[Johannes]

Na es muss so funktionieren. Man definiert, wie du schon sagst, ein "Telegramm" (so heißt es bei smirs) mit den Befehlen, die per RS232 an den Mikrocontroller gesendet werden können bzw. dieser sendet. Diese werden auf dem Rechner von einem smirs-Modul entgegengenommen.

Praktischerweise könnte man das Mikrocontroller-Rechner-Telegramm an das smirs-Telegramm anpassen. Denn dann könnte man vom Mikrocontroller aus z.B. den Befehl "GET|..." senden, und das RS232-Modul würde diesen String nur weiterleiten. Das Modul hätte also relativ wenig Arbeit.

Dieses RS232-Modul ist dann universell, aber die Implementierung auf dem Mikrocontroller muss jeder selbst machen. Natürlich können dann auch wieder Module für die verschiedenen Controller-Sprachen angeboten werden.

Gruß
Johannes

[PicNick]

Nur, wenn das Protokoll tatsächlich auch am low-level auf ASCII beruht, müßte der Controller ziemlich viel konvertieren, um da mitspielen zu können. Transparente Übertragung sollte es schon sein.

Halt ich nicht für machbar (f.Controller) bzw. sinnvoll.

[Johannes]

Ja, könntest du recht haben. Aber wäre ja auch anders möglich, das RS232-Modul übersetzt dann eben.

Gruß
Johannes

[PicNick]

Jetzt komm' ich mir so destruktiv vor:
Dann wiederum müßte das RS232 Modul mehr über die Daten wissen, als ihm gut tut. Wie sollte der vier Byte von einem Int32 unterscheiden können, ohne die Strukturen zu wissen ?
Jede Änderung würde alle Bestandteile treffen.
Man müßte sich bei einem Mikro/PC Netz mehr nach dem schwächsten Glied richten. Auch ein Tiny sollte irgendwie mitspielen können, sonst wird das nur eine RPC (Remote procedure call) -Middleware für PCs untereinander.
Ich will nicht Schwarzmalen und schlecht machen, aber ich seh da Probleme.

[Johannes]

Denkbar wäre auch eine Lösung, bei der mit Hilfe einer Konfigurationsdatei festgelegt wird, was wann passiert.

Gruß
Johannes

[PicNick]

*seufz*
Datenkonversion, Config-Files, routing-, mapping-tables, ....
Das wird ein Portalprozess als Gateway zu den Mikros. Da hilft kein Zappeln.
Das is ja nicht unbedingt was Schlechtes, aber es muß euch klar sein.
Die homogene Kommunikationsschicht für Module aller Art auf jeder Platform ist es halt nicht mehr.