Druckbare Version
Hi,
beim Durchlesen ist mir das mit dem ConnectionType aufgefallen. Ich bin am überlegen, ob wir das nicht wieder rausnehmen sollten, da es nicht viel Sinn macht. In so einem Fall nimmt man lieber eine MC auf demselben Rechner und kommuniziert dann über den MMC-Mode.
Gruß
Johannes
P.S. Irgendwie ist meine Website gerade down, hab schon an den Support gemailt.
Johhanes ich brauch den Connect Typ denn es gibt Teile wo der connect nicht ab gebaut werden soll auch wenn die Verbingung weg ist.
Das TCP modul für den AVR kann kein Stehenden Verbindungen.
Ausser dem in machen System wird es tölichsein wenn die Verbindung weg
ist hier sollte es die Möglichkeit geben drauf reagieren zu können.
Werde noch die Möglichkeit eines Trigger auf das Event bereitstellen damit man drauf reagieren kann.
Was machst du wenn der Navigator weg ist ?
ich lebe in der Welt der Hochverfügbarkeits systeme mit Oracle RAC und sonsitigen redundancen. So wie es im Bereich der BOS halt sein muß Lebenszeich und deren Überwachung sind mir heilig.
Gruß
Genau deshalb sollten wir diesen Modus rausnehmen. Der Modus war dazu gedacht, dass der TCP-Server der MC in eine wartende Position geht, wenn ein Modul nicht mehr verfügbar ist. Anwendung: Eine GUI, die sich auf einem anderen Rechner befindet, zu dem teilweise keine Verbindung vorhanden sein kann. Normalerweise müsste sich das Modul dann ganz neu anmelden, was bei einer GUI nervig wäre, schließlich will man ja nur Daten abfragen.
Normale Module, die für die Steuerung des Roboters wichtig sind, befinden sich ja sowieso auf dem selben Rechner wie die MC selbst. Und wenn dort mal ein Modul nicht mehr reagiert, muss die MC Alarm schlagen und nicht einfach warten, bis es wieder kommt.
Verwendet man Module, verteilt auf mehrere Rechner, dann sollte man den MMC-Modus verwenden. Dieser sorgt dann auch dafür, dass nach einen Verbindungsausfall die auf der Strecke gebliebenen Daten wieder synchronisiert/nachgesendet werden.
Also, ist alles nur für die Sicherheit.
Gruß
Johannes
Warum nicht Module im Netzauf teilen da hat man richtige rechenpower (Cluster).
Für mich würde es schon Sin machen den Natigator nicht auf der Selben Maschine wie die GUI laufen zulassen.
Aber ich denke das wir uns eh schon wieder zu sehr abmühen passieren Tut hier eh nix mehr jetzt schreiben nur wir. und vom Thread erfasser ist nix mehr zu hören.
Gruß
...bitte bitte weiter machen. Ich denke schon das ihr auf dem richtigen Weg seit.Zitat:
Zitat von NumberFive
Wenn ich nix dazu sage, soll das ja keine Ablehnung sein. Ich hab nur keine gute Idee dazu. :-k
Was mir prinzipiell durch den Kopf geht: Die beste Technik zur Planung, Arbeitsteilung, Überwachung und der dazu nötigen Kommunikation liefert die Natur. Ist ja auch kein Wunder - die experimentiert ja schon seit Millionen von Jahren.
Da kann man sicher auch Lösungsansätze für dieses Projekt finden. 8-[
Wenn es interessiert, ich hab ein paar Aspekte von Netzwerken hier beleuchtet. ohne irgendwelche Präjudizien für bestimmte Lösungen, soweit das möglich war
https://www.roboternetz.de/wissen/in.../Network_MC/PC
@NumberFive
Wenn man den Thread offen hat ist oben und unten rechts eine Knopfleiste. Eines der Symbole stellt wahrscheinlich ein Auge dar. Ich meine die Funktion :“Zeige wer den Thread gesehen hat“.
Dort sind alle die mitlesen aufgelistet mit Datum letztes ansehen und Anzahl der Ansichten. Ich weis z.B. das der alte Vogone seit geraumer Zeit ein interessiertes Auge auf diesen Thread hat *grins*. Auch Frank behält das Thema im Auge.
Alle die an diesem Projekt Maßgebliches beisteuern sind überproportional oft am lesen. Es sind alle im Projekt die ich mir erträumt habe. Außerdem haben wir einen sehr konstruktiven und kompetenten Mitstreiter dazubekommen.
Dieser Thread ist sehr kompakt. Wenn jemand in dieses Thema einsteigt findet er hier die geballte Ladung.
Zur Zeit habt ihr das Thema viel strukturierter und kompetenter vorangetrieben als ich das könnte. Die Ausrichtung ist zur Zeit dermaßen in meinem Sinne das ich erstmal nur den Mund halte um den Fluss nicht zu stören.
Ich flatter zur Zeit dem Projekt fachlich hinterher wie der Fuchsschwanz an der Autoantenne. Nebenbei hat PicNick noch einen sehr schönen Artikel über die Problematik und die Zusammenhänge der PC-Microcontroller-Komunikation geschrieben. Das muss ich erstmal als Unkundiger verarbeiten.
Zusammenfassung:
Für mich ist seit Tagen Geburtstag alle sind dabei was ganz tolles zu zaubern wo ich was von abkriege.
Ich wollt mich eigentlich nicht lächerlich machen aber nun, mir liegt das Projekt sehr am Herzen und ich freu mich die ganze Zeit wie ein kleiner Junge, wie das hier abgeht.
Ja, Frank hat mir eben ne PM geschrieben und gesagt, dass wir die Infos auch in den Download-Bereich stellen sollen. Ich habe leider im Moment mit meiner Website Probleme, ich weiß nicht, ob jemand von euch schon einen Blick in die längere Beschreibung werfen konnte. Ich habe die Datei noch auf einen anderen Server gepackt: http://mitglied.lycos.de/mindrobots/smirs/guide.pdf
> Warum nicht Module im Netzauf teilen da hat man richtige rechenpower (Cluster).
@Numberfive
Ich bin ein großer Freund von Modulen auf verschiedenen Rechnern. Aber dazu ist der MMC-Mode gedacht. Lies dir mal das Dokument durch und du wirst begeistert sein :-)
Gruß
Johannes
Sorry noch mal das meine Sprachlosigkeit für Unmut gesorgt hat.
NumberFive hat den momentanen Bedarf mE. richtig benannt.
„Wir müssen nur mehr Definieren um es zu einem Baukasten machen zu können“
Zum Multimodulbetrieb:
frage ich mich inzwischen, ob der nicht schon eher gebraucht wird als man denkt
Mal ein Blick auf die serielle Baustelle:
Nachdem ich mir den Artikel von PicNick zu Gemüte geführt habe stellte sich mir eine Frage: Sollten wir uns beim seriellen Protokoll die Einschränkung leisten und nur ein Protokoll haben?.
Die Telekom hat z.B. bei Ihren DSL-Anschlüssen bei guter Verbindung die Option „Fast Path“. Damit können Onlinespieler ihren Ping verkleinern, nehmen aber Fehler in der Datenübertragung in kauf weil die Telekom schlicht die Fehlerkorrektur abschaltet.
Wenn ich nun sehe das auch kleine Microcontroller mitmachen wollen wo das OSI-Modell eh nicht mehr so ausdifferenziert werden kann würde sich anbieten das die sich ein Protokoll wünschen dürfen.
Einen Faktor vielleicht noch. Man hat bei Onlinespielen bis zu einem Ping von ca. 250ms ein Gefühl von Echtzeit darüber wird es ätzend. 60ms sind dagegen volles Echtzeitgefühl. Bei 9600baud wird das schon eng wenn ich später mal mein selbst geschriebenes Verhaltensmodul am laufen habe.
Zum Thema Betriebsystem auf dem Microcontroller:
Es spricht m.E. nichts dagegen wenn es mehrere Betriebssysteme für dasselbe Board gibt, solange sie das Protokoll können. Da brauchten wir dann keine Glaubensfragen austragen. Und hätten Vielfalt die sich gegenseitig inspirieren kann.
Netter Gruß
Vielen Dank PicNick, dieser Artikel ist wirklich gut und er kommt imZitat:
Zitat von PicNick
wesentlichen zu den Ergebnissen, zu denen ich gestern auch gekommen
bin (hatte leider kein Netz).
Im wesentlichen denke ich, dass wir bei unseren Planungen
schichtorientiert denken müssen. Das ganze wird doch ein recht
umfangreiches System und Schichten werden uns helfen, das ganze
besser zu planen, besser zu verstehen und besser zu implementieren.
Klar definierte Schichten sind das A und O an der Geschichte.
PicNick hat schon einen Anlauf gemacht, diese Schichten zu definieren,
ich möchte es nochmal versuchen bzw. meine Meinung dazu sagen.
Ähnlichkeiten mit ISO/OSI sind nicht ausgeschlossen, ich will aber
keineswegs darauf rumreiten. Es geht mir außerdem erstmal nur darum,
welche Aufgaben diese Schichten haben sollen, nicht, wie sie konkret
implementiert werden können.
Schicht 1: Übertragung
- - Definiert Protokolle für die Übertragung eines Frames über verschiedene Hardwaremedien.
- Inhalt des Frames (Sender, Empfänger) nicht wichtig
- verbindungslos (keine Antwort des Empfängers)
- nicht zwingend abgesichert (Nachrichten können verloren bzw. kaputt gehen)
- Schnittstelle zu Schicht 2: sendFrame(data, length)
Schicht 2: Routing
- - Definiert Frames mit Adressen für Sender und Empfänger
- Jeder Teilnehmer ist ein Knoten und hat eine global eindeutige Adresse
- Alle Knoten sind gleichwertig.
- Die real vorhandene Topologie der Knoten wird versteckt.
- Eventuell erleichtert eine zweistufige Topologie (lokal/entfernt) die Implementierung.
- Routet die Frames zwischen verschiedenen devices
- Kennt alle verfügbaren Geräte der Schicht 1
- Entscheidet bei ausgehenden Nachrichten, welches device die Nachricht schickt
- Entscheidet bei eingehenden Nachrichten, ob der Frame an ein
anderes device geschickt an Schicht 3 weitergeben wird.
- eventuell eine automatische Vergabe von Adressen (bei PicNick: enumeration)
- Schnittstelle zu schicht 1: receiveFrame(data, length)
- Schnittstelle zu Schicht 3: sendFrame(sender, data, length)
Schicht 3: Verbindung
- - Kann zusätzliche Verbindungseigenschaften realisieren (durch Steuerdaten)
Mögliche Eigenschaften:
- Datenintegrität (CRC)
- Empfangsbestätigung (Acknowledge)
- Verbindungsorientierter Nachrichtenaustausch (Acknowledge mit Wiederholung)
- ping
- Schnittstelle zu Schicht 2: receiveFrame(sender, data, length)
- Schnittstelle zu Schicht 4: sendFrame(connectionType, receiver, data, length)
Schicht 4: Dienste
- - Weist den Daten eine Struktur und eine Bedeutung zu, z.B. Kommandos und Parameter
- Definiert Kommandos für gemeinsame Dienste
- Diese Dienste bilden die Essenz einer gemeinsamen Steuersoftware, GUI, etc
Mögliche Dienste sind z.B.
- Verzeichnisdienst/Discoverydienst
- Heartbeat/Ping
- Debuggingschnittstelle
- Schnittstelle zu Schicht 3: receiveFrame(sender, data, length
Anmerkung: Diese Architektur ist im wesentlichen darauf ausgelegt, einzelne
asynchrone Nachrichten zu übertragen. Ich möchte noch kurz begründen,
warum ich verbindungsorientierte 'Streams' nur stiefmütterlich
behandelt habe:
- Streams brauchen viel Rechenzeit und vergrößern das Datenvolumen
- Die korrekte Behandlung von Streams in uCs ohne Threads ist schwierig (Parallelität).
- Die meisten Dienste lassen sich problemlos auf verbindungslosen Nachrichten abbilden
- Teilnehmer können jederzeit wegfallen.
uCs werden ohne Neustart des Gesamtsystems neu programmiert, Programme neu
gestartet, etc. Streams können dies nicht verhindern sondern nur feststellen.
Der einzige Ausweg aus der Situation ist die Dienste darauf auszulegen,
störungsresistent zu arbeiten, z.B. den Betrieb nach Wiederverfügbarkeit
beider Kommunikationspartner automatisch wieder aufzunehmen.
Sind die Dienste aber sowieso störungsresistent ausgelegt, kann man auch
unsichere Verbindungen in Kauf nehmen.
Anmerkung 2:
Für mich zeichnet sich ab, dass wir das Projekt in zwei große Teile
zerlegen können. Zum einen die Implementierung eines Nachrichtensystems
(Schichten 1-3), zum anderen die Definition allgemeiner Dienst für
Roboterkomponenten (Schicht 4)
@NumberFive:
Wir arbeiten hier nicht für andere sondern für uns selbst. Zumindest
mir geistert diese Idee schon längere Zeit im Kopf herum und dies
hier ist nur der richtige Anlass. Ausserdem kommen wir gut voran
auch wenn man noch keinen Code sieht.
Das ganze ist jetzt erstmal ein Vorschlag. Ich bitte um Rückmeldung.
ciao,
Georg