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

Na das ist aber ordenlich lese stoff da komme ich heute nicht mehr durch.
Aber ich werde dran bleiben.

Warte jetzt aber erstmal auf den Implemetierungs vorschlag.
Dann ist es nicht mehr so abstract.

Vieleicht kann man auch beides Implemetieren.

Gruß

> Ich hoffe nur, ich kann auch Johannes und NumberFive überzeugen an dem neuen Projekt mitzuarbeiten, auch wenn von smirs dabei nur ein paar Algorithmen übrigbleiben.

Das kann ich so nicht sagen, ich werde auf jeden Fall für meinen Roboter smirs verwenden und es weiterentwickeln. Sollten wir wie gesagt gute und sinnvolle Änderungsvorschläge finden, dann würden ich es gut finden, wenn die in smirs einfließen.

Schauen wir mal, ich bin gespannt auf die Vorschläge.

Gruß
Johannes

Hallo Freunde der Softwarekunst,
ich habe jetzt auf drängen (*&%$X³) mal das im Forum gekostete PDF „smirs guide.pdf“ 546 Kb gelesen.

Meine Erwartungshaltung war ein System das eine Modularisierung der Softwareteile regelt bzw. erzwingt.
Ich habe aber die Beschreibung eins Properhitären Datenformats vorgefunden das mit den TCP Standards in Pere to Pere gehandelt wird.
Zudem war eine Art Styleguide zur Implementierung der Clients dabei.

Fehlen mir noch Dokumente?

Hier an dieser Stelle möchte ich auf dieses Dokument schon mal eingehen... ohne auf Details wie „wie packe ich | in einen Datenstring?“ eingehen sondern schon mal was elementares Fragen vielleicht auch Vorlegen.

Gibt es später/jetzt standardisierte Datentypen oder ist das Stringformat beliebig zu interpretieren?
Wird/Ist die die Möglichkeit (abgesehen von Streams) Binärdaten zu übermitteln und ist hierfür dann Base64 oder gleich das HTTP-Protokoll like RFC vorgesehen?

Ich bräuchte eine Standardisierung der Wegstrecken.
Meile <-> Kilometer <-> Meter um im GUI nicht von Gummimetern erzählen zu müssen.
Auch eine Standardisierung anderer Phys. Einheiten wäre nett.
Die Bildübermittlung solle mir dann auch verraten können um welches Datenformat es sich handelt und mit welcher Konvertierung es gerade durchs Netz rauscht.
Mit diesen Features könnte ich dann eine Software schreiben die annähernd kompatibel zu andern Systemen die genauso verfahren ist.

Diese Fragen sind relevant für mein geplantes Standard-Web-GUI für Roboter.
Ich habe bislang geplant für den Datentausch wie gewöhnlich SOAP zu verwenden und weitere Systemteile sofern notwendig mit CORBA zu verschabbeln.
Ist S²MIRS als etwas ähnliches angedacht oder ist das Layer zu tief?

Ich habe noch nach weiteren Dokumenten gesucht aber die Webseite selbst erscheint mir ziemlich ähnlich.
Postet mal die Links mit den Doks, die man kennen muss um über pragmatischere Dinge zu texten, ohne in hypothetisches gefaselt abzuwandern.
Ich würde auch im Zuge meines WEB-GUIs mitprogrammieren ... nur muss ich das ganze erstmal verstehen.

Gruß,
Chris

PS: An die Doktorarbeitschreibsler ...etwas pragmatischer wäre net schlecht, denn ich bin Informatiker und kein Theologe. Und der glaube an ein System das multi private, public semiperstent, private persistent, private kill... rollback public .. watch hangoff .. deadloop ... watch external, handeln kann ist bei mir und zudem Naturwissenschaftlich schon widerlegt.
Ihr lauft damit Gefahr durch Seiteneffekte die KI zu erfinden ;-)
DON`T PANIC

Hi UlrichC
Ich kann Dir nur ganz grob einige Sachen aufzeigen wie ich sie sehe.

Ragnar hat weiter vorne ein Schichtenmodell vorgeschlagen.
Schicht 1 Übertragung
Schicht 2 Routing
Schicht 3 Verbindung
Schicht 4 Dienste
Ragnar z.B.möchte bis Schicht 3 bei der Entwicklung helfen.

Nach diesem Modell sind
Deine geplante GUI Schicht 4 .
Deine angeregte Festlegung von Werten Schicht 4.

Zur Zeit liegt der Fokus auf den Schichten 1,2 und 3 um der Schicht 4 die Plattform-Unabhängigkeit zu schenken.
Bevor das nicht steht kann man der Schicht 4 nicht sagen was sie vom Datenverkehr erwarten darf und was sie erfüllen muss.


Die Datenübertragung wird im Bereich PC-Mikrocontroller aus Performancegründen vermutlich Transparent, also keine Strings.
PC-PC müssen wir abwarten wohin die Meinung sich verdichtet.
Netter Gruß

In Richtung UlrichC
Ich würde/werde den Weg gehen, daß beim Startup und auf Anforderung vom µC eine Liste/Portfolio der Geräte zur Registrierung verbreitet wird. dabei sollte u.a jedes Gerät auch (codiert) mitteilen, welche Datenformate /strukturen es verwendet. Also auch implizit oder explizit, welche Einheiten verwendet werden (Raw, gummimeter, Degree/rad, etc. oder auch strukturiert, wie z.b. GPS oder DCF77 daten.
Es gibt ja auch bei Floatzahlen Unterschiede. Und auch Byte -Order, usw., wenn man will.
Das klingt wilder, als es ist, denn die meisten Geräte sind ja durch eine Bezeichnung ("LM75") ausreichend definiert, und auf einem PC ist es ein Leichtes, ein passendes "Dictionary" a la XML zu den Geräten zu führen.

Ziel ist es, möglichst viel Konversionen und Mappings auf den PC zu verlagern, denn der hat Platz und Leistung.

@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.

Also gegen xml über tcp habe ich was das ist zu viel Mühl pro telegramm.
Um 4 Byte rüber zu bekommen muß ich 20 schicken da mach ich net mit.

Für Konfig vielleicht noch aber ich für die Telegramme.

Gruß

Auf PC-Basis muss man denke ich keine Bytes zählen.
Zudem produziert jedes Protokoll ein gewisses maß an Müll ...
VAR|20
Oder
<VAR=20 />
?
Ok 7 Bytes Mehr.. ;-)


Man könnte SMIRS-Notationen in XML verbauen und beliebig erweitern... ohne alle anzuleiten einen neuen Parser zu schreiben.
Die Parser gäbs sogar schon fertig... die Notation wäre bekannt und die Regeln hierfür wären also schon geschrieben.
Um ein Properhitheeres Format soweit zu bringen, das es Objekte ... Strukturen und deren Verschachtelung bzw. Abhängigkeiten handeln kann ... ohne den Entwicklern einen Knoten in die Birne zu projektieren ist ein Haufen Arbeit bzw. Erklärungsbedarf notwendig.
Das was ich bisher von SMIRS gelesen habe ist nicht zu verachten, nur mit XML um vieles Ausbaufähiger. Und vor allem auch mächtiger – und vielleicht auch Kompatibler zu anderen Systemen.
Ich könnte Viewer, Parser, Validatoren, Analyzer etc. verwenden die es schon fertig frei gibt... Zudem könnte durch eine kleine SOAP-Packung die Roboter übers Internet vernetzen ... ohne neue Gateways Proxis NamingServices DNS und der gleichen selbst schreiben zu müssen.

Wie getextet ... auf Treiberebene wäre es fast egal wie angebunden wird... hier könnten dann Strings – Byteformate und Flags geschoben werden... ob die Variablen dann Public , private , persistent, transient , temporär oder internal sind wäre egal...
Wichtig wäre nur die Schnittstelle zu einem evtl. Server die bei allen Modulen gleich wäre.
Da könnte man/sollte man mit „A<1 Byte><1Byte>E“ verfahren und dies zum Standard erklären. Nur auf der PC-Seite muss man alle Feinheiten der Softwaretechnik bieten ... ein eigenes Format würde da zu sehr begrenzen.

Einem Entwickler (nich API Entwickler) ist das XML-Gemehre dann auch herzlich egal...solange die Schnittstelle funzt. Ermüsste nämlich selbst keine Sockets PufferdReader BinStreams .. QStreams , ByteArrays (wow so viele Sprachen) programmieren ... er hätte ja seine Schnittstelle die fern ab von Send und Recive wäre.

Schnittstelle:
Name
Description
Params
Status
Command
... wie auch immer.

Funktionen:
Int GetParam(„key“)
String GetParam(„key“)
bigEndian GetParam(„key“)
Image GetParam(„key“)
T<Class> GetParam(„key“)
Set...

Module * GetModule(“Name”)

u.s.w.

Ich will hier nicht die Funktionsweise eines ApplicationServers erläutern .
Wie gesagt nur so ne Vorstellung.
Will eigentlich auch nur ne Web-GUI ... wie meine Livecam nur mit Roboter-Fahrwerk ;-)

Netter Gruß,
Chris

EDIT: Die Schnittstelle ist nur proforma..also nicht hinterdacht.
EDIT II:Durch den kompiler geht se auch nich ... einer Programmiersprache entspricht se auch nich ... nur einer Intension ;-)

Insofern hat Chris natürlich recht: wenn man mal soweit ist, daß man derartiges andenkt, wird man den Teufel tun und was Neues zur Applikationsanbindung erfinden. Selbst wenn es in epische breiten geht ("XML") ist trotzdem der Standard an sich dann mehr wert als geniale Eigenkonstrukte.
Denn für Standard gibt's auch Standardprodukte aller Art.

Ich seh keine wirklichen Konflikt mit den Überlegungen über die diversen Layer drunter. Das ist ja mehr die Frage, wie man dann irgendwo oben PC-saftware anbinden will.

Richtig! Ich texte hier auf jeden Fall nicht von der eigentlichen Hardwareanbindung ;-) denn im Falle von XML texte ich ja von der Vernetzung über die Rechnergrenzen hinaus ... und nicht von der Vernetzung mit dem Rechner selbst... denn das will ich mir sparen.

Die Anbindung der unteren Layer über eine einheitliche Schnittstelle (zu diesem Layer).
Also die obere Schicht(en) Abgrenzen von dem was drunter kommen mag.

z.B.
Man packt die Hardwareanbindung in eine Treiber DLL (DynamicLinkLibary WÍN) oder SO(SharedObject LIN) diese dann durch einen/diesen/jenen ApplicationsServer geladen/entladen wird und die Anbindung zwischen zwei Programmteilen herstellt.
Die DLL-Schnittstelle muß fest vorgeschrieben sein um die Funktionszugriffe des ApplicationServers nicht in leere Laufen zu lassen.

Es können beliebige DLLs, ActiveX oder SO oder von diesem Programmteil (ApplicationServer ) geladen und miteinander verbunden werden.

Das Programmteilstück das alle lädt und verbindet hat schon einen festen Namen (sowie die Architektur) nennt sich ApplicationServer in der Softwaretechnik.
Das ist also alles nix neues ... nur bewährtes.
Die DLLs oder SOs vielleicht auch AktiveX

Die einzelnen Module (Treiber, Oberflächen, Auswertungen ...) können je nach Auslegung der Schnittstelle in verschiedenen Sprachen geschrieben sein.

Als Hilfe zur Programmierung gibt es dann Klassen von denen man ableiten kann bzw. muss um alle benötigten Schnittstellenfunktionen bedienen zu können ohne selbst welche bauen zu müssen.
Für C könnte man ähnliche Konstrukte mit Standard Bibliotheken anwenden.
Die Module (interne und externe) können sich untereinander über den ApplicationServers unterhalten.
...über Messagepoolin, Message-Stack, Message-Spooler, Datei, Messageque, SharedMemory-Handling oder Windows Messaging wie auch immer... das ist Bier des Applikationserverbauers ;-)
(Ich glaube NumberFive macht so etwas ähnliches in seiner Version).
Ob man dann wirklich XML einsetzt ist auch offen... er sollte jedenfalls eine Netzübergreifende standardisierte Geschichte wählen die auch Lösungen für Binärdaten und Strukturen sowie Objekte (serialize Geschichten) an Board hat.

Praktisches Beispiel WebGUI mit Roboter und CAM.
1.Roboter mit Cam (is klar)
<Kabelsalat>
2.Microprozellor (*XXX)
<RS232>
3.Treiber (Modul des Systems) (*XXX mit fester Schnittstelle)
<ApplikationServer>
4.GUI (Modul des Systems) <-> Messdatenerfassung <-> Steuerung

*XXX = Frei wählbare Auslegung der Programmierung ... in diesem Bereich möchte ich derzeit nicht mitquatschen.

Das ist so im groben die etwas anders beschriebene Fassung.
Das mit den Abgeleiteten Treibern gibt eben die meiste Freiheitsgrade und lenkt das richtige Ergebnis.
Eine Treiberbibliothek könnte vielleicht beim anhacken des Roboters über RS232, Parallel , USB, Infrarot ;BlueT...
helfen... nur sind die Möglichkeiten und Variationen sind mannigfaltig.


Netter Gruß,
Chris

PS: Ich werd mal eine Architektur malen... es ist nun alles a bisl verwirrend wenn man es nicht schon kennt... zudem will/muss ich ernsthaft so was basteln um Bilder und Strukturen übers Netz (WWW) zu bekommen.