Das Wichtigste an der ganzen Automation ist, denke ich, das Protokoll, das sehr genau diskutiert werden sollte. Nicht dass wir später feststellen, dass wir mit unserem Protokoll nicht weit kommen und später alles umschmeissen müssen... Hier mal ein paar Gedanken, die ich mir zum Thema gemacht habe: CAN 2.0B als Grundlage fände ich sinnvoll, da sehr viele Adressen möglich sind und die meisten Controller dies unterstützen. * CanOpen wäre eine Idee, da man das Projekt damit halbwegs Standardkonform bauen könnte, und vielleicht andere CanOpen Komponenten mit einbeziehen kann. + ein Quasi-Standard + ausgereift - nur 127 Knoten möglich (wenn ich richtig informiert bin) * Nachrichtenorientiertes Protokoll + Entspricht 1:1 dem CAN-System, keine Umwandlung nötig + wenig Overhead - maximal 8 Bytes Nutzdaten - nicht sehr flexibel * Erweitertes nachrichtenorientiertes Protokoll: Anweisungen werden auf mehrere CAN-Nachrichten aufgeteilt und von den Controllern wieder zusammengesetzt (wie TCP-Pakete) + Flexibilität + einfacheres Debuggen (Anweisungen können in Klartext dekodiert werden und müssen nicht in 8 Bit versteckt werden) - größerer Overhead * Adressenorientiertes Protokoll + System verständlicher, da jeder Busknoten eine feste Adresse erhält, die angesprochen werden kann - Dürfen zwei Knoten mit der gleichen Adresse auftreten? - "Umwandlung" Nachrichten <-> Adressen nötig * Erweitertes adressorientiertes Protokoll (siehe erweitertes nachrichtenorientertes Protokoll): + Flexibilität + einfacheres Debuggen - größerer Overhead - "Umwandlung" Nachrichten <-> Adressen nötig Hab ich eine Möglichkeit vergessen? Praktisch fände ich es, wenn man sich an bestehenden Protokollen orientieren könnte, z.B. an TCP/IP Um es noch genauer zu erklären, was ich mit "einfacheres Debuggen" meine: Wenn ich meine Anweisungen in 8 Bytes kodiere, könnte eine Nachricht so aussehen: "0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 0xFF" - was beispielsweise lauten könnte: Port 3 (0x03) wird eingeschaltet (0xFF) Nicht gerade auf den ersten Blick ersichtlich. Wenn ich aber beispielsweise "port3=on" über den Busübertrage, könnte ich die Nachricht in einem Busanalyser im Klartext ablesen. Der Mikrocontroller müsste zwar dann das "port3" erst dekodieren um zu wissen welcher Pin gemeint ist und das "on" ebenso, aber Fehler könnten so schneller gefunden werden, denke ich. Desweiteren könnte man beispielsweise einfache Schaltbefehle per RS232<->CAN-Konverter absetzen. Im Falle einer Adressvergabe der Knoten könnte man die CAN-IDs vielleicht Netzwerkähnlich mappen, die 29 IDs könnte man in 5 Bits und 3 Oktette aufteilen, z.B. 15.244.14.29, die einen Knoten beschreiben. Oder man lässt das letzte Oktett aus der Adresse weg und verwendet dieses, um z.B. Nachrichten für einen Knoten zu adressieren. Beispiel: Der Knoten hat die Adresse 15.244.14, wenn die Nachricht "45" beispielsweise beschreibt: "Zeige deinen Betriebsstatus", so schickt man eine Nachricht mit der CAN-ID 15.244.14.45 ins Netz, die dann die gewünschte Nachricht übermittelt. Dann könnte man schon anhand der ID das Netz strukturieren: Die ersten 5 Bits (0-32) geben beispielsweise das CAN-Netz an, wenn ich mehrere CAN-Busse in einem Haus fahre. Das nächste Oktett ist z.B. für einen bestimmten Raum (Wohnzimmer) und das 3. Oktett beschreibt den Knoten (an dem z.B. Lampe1 hängt). Das 4. Oktett könnte man beispielsweise defaultmäßig auf 0 belassen, wenn man dem Knoten eine Nachricht schickt. Beispiel: Die Nachricht "port1=an" an die ID 0.5.3.0 schickt an default_bus.wohnzimmer.lampencontroller die Nachricht "port1=an", der Controller schaltet daraufhin das Licht an. Wenn ich dagegen eine andere ID beim letzten Oktett verwende (die der Controller natürlich kennen muss), kann ich beispielsweise irgendwelche Eigenschaften des Controllers setzen oder auslesen, die mit dem Schalten nix zu tun haben (z.B. eine Beschreibung des Busknotens im Klartext) Ich hoffe ich habs einigermaßen verständlich rübergebracht, was ich meine. Ganz einfach ist das Ganze nicht, aber das wird sich hoffentlich im Laufe der Zeit geben. Und wie immer: Bitte schreibt Eure Meinung dazu, und wenns Fragen gibt, immer her damit! :)
@Ithamar hallo ithamar! wir versuchen gerade unter dem forum microcontroller eine cpu auf die welt zu bringen (MIN-SPS), die unter unter umständen auch für dieses vorhaben geeignet sein könnte. derzeit sind wir dabei, uns einmal entsprechend zu formieren und die grundlegenden dinge die diese kleine sps können soll festzulegen. bezüglich busprotokoll ist einmal can-open2.0 und modbus vorgesehen. mit diesen beiden dingen können schon mal 90% der anforderungen abgedeckt werden. außerdem sind wir in der lage, dieses gerät auch in entsprechenden stückzahlen herstellen zu können, damit eine gute verbreitung ermöglicht werden kann. im konkreten habe ich von einen kunden die anforderung für solch ein gerät mit can-bus (oem-lösung) weiter anfragen sind auch bereits vorhanden und somit auch in der industrie vielleicht anwendbar. schau am besten mal in unser mini-sps thema - vielleicht ergibt sich in irgend einer art und weise eine möglichkeit, gemeinsam daran zu arbeiten. lg peter
> * CanOpen wäre eine Idee, da man das Projekt damit halbwegs > Standardkonform bauen könnte, und vielleicht andere CanOpen > Komponenten mit einbeziehen kann. CanOpen ist IMHO zu komplex. Was soll mit CanOpen-Kompatibilität konkret erreicht werden? Können die teuer kaufbaren CanOpen-Geräte konzeptionell dann ins [OS-Hb]-Konzept eingebunden werden? > * Nachrichtenorientiertes Protokoll > * Adressenorientiertes Protokoll > Hab ich eine Möglichkeit vergessen? Warum nicht beides vereinen? Damit schränkt man sich in der jetzigen Planungsphase noch nicht vorzeitig ein und kann beide Konzepte, je nach Anwendungsfall (oder da wo das ein oder andere besser passt), nutzen. Konkret könnte das so aussehen: Ein Aktor erhält eine Botschaft, daß er eine Aktion ausführen soll. (Adressorientiert). Ein Regensensor verschickt erst eine Botschaft, wenn es regnet (Ereignisorientiert). Als dritter wichtiger Konzeptpunkt würde ich zyklische Meldungen sehen - z.B. Temperatursensor meldet zyklisch alle 60s seine aktuelle Temperatur (Broadcast; könnte man auch als ereignisorientiert einordnen - 60s sind um...). > Nachricht so aussehen: "0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 > 0xFF" - was beispielsweise lauten könnte: Port 3 (0x03) wird > eingeschaltet (0xFF) Ich denke, dass das zuviel unnötigen Overhead produziert und im Betrieb zu wenig/keinen Nutzen bringt. > die 29 IDs könnte man in 5 Bits und 3 Oktette aufteilen, z.B. > 15.244.14.29, die einen Knoten beschreiben. Vorsicht, was passiert, wenn zwei Knoten gleichzeitig auf einen dritten Knoten zugreifen wollen? Dann senden beide Knoten die gleiche CanId - das kracht!! Es muß ausgeschlossen sein, daß zwei unterschiedliche Knoten den gleichen CanIdentifier verwenden. Eine Möglichkeit das zu umgehen, ist, die eigene und busweit eindeutige Knotenummer in die CanId einzubauen.
@peter: Hört sich gut an! Ich kann nur für mich sprechen, aber ich find die Idee gut, mit einer SPS kommunizieren zu können. Egal ob sie jetzt den Bus steuert, oder als einer der Teilnehmer drinhängt, praktisch ist es allemal. Wenn wir einen gemeinsamen Nenner finden können - gern. Ich denke dass das die Anderen auch interessieren würde. Ich muss mich erst mal in Euer Projekt einlesen, Ihr habt ja schon einiges gesammelt - und Ihr könnt ja ab und zu mal hier reinschauen...
@andy_ref: >CanOpen ist IMHO zu komplex. Was soll mit CanOpen-Kompatibilität >konkret erreicht werden? Können die teuer kaufbaren CanOpen-Geräte >konzeptionell dann ins [OS-Hb]-Konzept eingebunden werden? Kann ich so nicht bestätigen, im einfachsten Fall besteht die CANopen-Komunikation aus einem NMT-Startup d.h. eine ID die der Master an alle Knoten sendet und die Knoten legen dann los über ihre PDO's Nutzdaten sprudeln. Wenn du natürlich den gesamten Umfang aller Device-Profile für I/O, Drivers, Programmierung, Multimaster, ... abbilden willst, gebe ich dir Recht. Gruss Peter
Also mir ist auf jeden Fall wichtig, das Rad nicht neu zu erfinden. Erstens ist eine komplette Neuimplementierung ein Haufen Arbeit und zweitens ist es sicherer, auf bereits erprobtem aufzubauen. Eine Anlehnung ans TCP/IP Protokoll fände ich praktisch, da das ja DAS Protokoll schlechthin ist und viele Vorteile bildet - ganz kann man es natürlich nicht übernehmen, sonst könnte man gleich die Hausautomation auf dem Netzwerk aufsetzen, aber die Rosinen kann man sich ja rauspicken :) Praktisch fände ich beispielsweise sowas wie Broadcast-IDs, wenn diese ID (z.B. als Remote Frame) gesendet wird, könnten sich alle Knoten angesprochen fühlen und ihre Fähigkeiten publizieren. Das könnte dann die Steuerungssoftware auffangen und ihre Daten entsprechend visualisieren. Klar dürfen sich die IDs nicht überschneiden und mann muss auch überlegen wie man das mit den Masken macht, aber das Prinzip fände ich nicht schlecht...
zu canopen: http://www.mikrocontroller.net/forum/read-1-263599.html#new ich denke wir sollten für die Pc software noch ein layer einfügen, damit man dann alles auf meheren verschidenen Bussen abbilden kann. ethernet, can, eib.... sollen wir das wiki nach dem Osi-schichtmodell structurieren, zumindest der protokoll und bus part?
Also ich fänd den Vorschlag gut, in dem anderen Topic habe ich ja schon mal so nen groben Umriss aufgegliedert, aber das passt hier natürlich besser hin: Layer 1: Hardwareebene (Verkabelung) Layer 2: Busebene (CAN/I²C/EIB/?) Layer 3: Buskoppler/Aktoren/Sensoren Layer 4: Protokollebene (CANOpen/eigenes Prot.) Layer 5: Aktionsebene (Nachrichten, Adressen, ...?) Layer 6: Objekt-Abstraktion (z.B. Lampensymbole, virtuelle Schalter,...) Layer 7: Die Anwendung allgemein Wobei die Zuordnungen zu den einzelnen Ebenen noch geklärt werden müsste. Bevor wir was ins Wiki stellen, würd ich das aber gerne hier noch etwas diskutieren, damit wir eine vernünftige Version einbauen können... Die Austauschbarkeit halte ich für sehr wichtig, ein modularer Aufbau (wo möglich) is erstens besser zu durchschauen und kann auch besser von mehreren Leuten bearbeitet werden. Mein Java-Testprogramm habe ich beispielsweise auch so aufgebaut, dass es eine Klasse zur Datenübertragung gibt. Und diese baut auf anderen Klassen auf. Beispiel: Ich kann über einen Seriell->CAN Konverter auf den Bus zugreifen. Wenn ich in die Schnittstelle Daten - Serieller Port noch mein Modem-Modul einbaue, kann er über einen Modem auf ein entferntes Netz zugreifen. Das Programm ist übrigens wirklich nur zum Test, ich will nicht mit irgendwas vorpreschen... Aber zu Beginn würde ich mal vorschlagen, diskutieren wir mal über die untersten beiden Schichtebenen, der Hardware-Ebene (Verkabelung) und der Busebene. Dazu greife ich einfach mal die Vorschläge auf, die schon genannt worden sind: Layer 1: - Verkabelung bevorzugt per TP-Kabel, andere Arten (z.B. Klingeldraht) auch möglich - Wahlweise Bus oder Bus-über-Stern-Verkabelung - Optionale Stromversorgung über Buskabel - minimal mögliche Buslänge: ca. 500m (reicht das?) Die Steckerbelegung wird ja in einem anderen Thread diskutiert, das müssen wir hier nicht machen Layer 2: - Busprotokoll CAN - andere Protokolle können folgen Welche Busprotokolle könnte man noch unterstützen (sofern sich Leute finden, die sich drum kümmern wollen, mir langt CAN)? Was fällt Euch noch dazu ein?
- minimal mögliche Buslänge: ca. 500m (reicht das?) meinst Du nicht maximal 500m ? Was machst Du denn unter 500m ;-)
Naja du musst genau lesen ;) minimal mögliche Buslänge... Anders formuliert: Der Bus soll mindestens 500m lang sein können und trotzdem einwandfrei funktionieren - damit auch größere Installationen einwandfrei funktionieren. Denn wenn man beispielsweise das Bus-über-Stern Verkabelungsprinzip nimmt, kann man bei 500m Kabellänge und 25m Durchschnittslänge für die einzelnen Knoten grad mal 20 Lampen/Schalter/... anschließen. Und 25m hört sich auch übertrieben an, aber das sind 12,5m vom Verteiler zum Knoten (hin- und zurück) - und durch die Kabelschächte (vielleicht noch in ein anderes Stockwerk) kann das durchaus zusammenkommen... Okay da gibts einige Möglichkeiten der Optimierungsmöglichkeiten, aber ich will damit nur verdeutlichen, wie schnell man auf 500m kommen kann... Ach ja, schon wieder zu viel getextet - kürzere Kabel gehen natürlich auch :P
Kann man Can auch Sternförmig verteilen? Also ohne Rueckleiter so das es kein Bus in Sternform ist.
Also ich hab mir noch ein paar Gedanken zum Ansprechen der Busknoten gemacht: Meine Idee wäre es, sowohl mit Adressen als auch mit Nachrichten zu arbeiten. Für CAN-IDs stehen ja 29 Bit zur Verfügung, da kann man einen Teil der Bits für Adressen vergeben, die müssen eindeutig sein, dürfen also nicht mehrfach vergeben werden, und den anderen Teil für Nachrichten-IDs, die mehrere Knoten ansprechen können. Um nochmal meine Idee von weiter oben aufzugreifen: - Die ersten 5 Bits könnte man für die Kennzeichnung des Netzes verwenden. Das wären 32 Bereiche, die man noch unterteilen könnte, etc. So könnte man in einem (größeren) Haus verschiedene Bussysteme definieren, die an sich unabhängig voneinander funktionieren, aber durch einen Router Daten austauschen können. - Die nächsten 8 Bits könnten für die Vergabe einer Stockwerks-ID dienen, damit unterscheidet man verschiedene Ebenen. Nimmt man das erste Bit zum Toggeln, könnte man zwischen 127 Adressen für Stockwerke und 127 Nachrichten-IDs für Telegramme an Empfänger des gesamten Stockwerkes unterscheiden. - Das nächste Byte könnte einen Raum beschreiben, wenn man die Werte 0 und 255 (wie bei Ethernet) für besondere Aufgaben reservieren würde, hätte man noch 254 Nummern für die Aufteilung auf die Räume. Man könnte natürlich auch ein Bit zum Toggeln zwischen Adress-IDs und Nachrichten-IDs verwenden, dann hat man zwar "nur" 127 Raum-Adressen, aber noch weitere 127 Nachrichten-IDs, die eben Nachrichten an "alle Räume" schicken könnten. - Die letzten 8 Bits könnten dann schliesslich und endlich den Knoten beschreiben, beispielsweise wieder 127 IDs für Knoten-Adressen und weitere 127 für Nachrichten-IDs. Was haltet Ihr vom Prinzip? Macht das Sinn oder eher nicht? Je länger ich überlege, desto weniger gefällt mir das Unterscheiden zwischen Nachrichten-IDs und Adressen auf jeder Ebene. Vielleicht würde es da eher Sinn machen, nur die Adressen in der Form zu unterscheiden und die IDs einfach "global" festzulegen, und nur ein höherwertiges Bit zum Toggeln verwenden... Natürlich könnte man auch andere Unterteilungen verwenden, warum ich gerade 5,8,8 und nochmal 8 Bit gewählt habe, liegt daran, dass man die Adressen dann schön wie IPs in der Schreibweise "a.b.c.d" schreiben kann, oder in einer Verwaltungssoftware "Netz.Stockwerk.Raum.Knoten" Ausserdem habe ich mir gedacht, dass eine Skalierbarkeit des Systems wichtig ist und man mit einer CAN-Message nur 8 Bytes versenden kann. Hier könnte man das erste Byte als "Zähler" verwenden, man hätte zwar nur noch 7 Byte für Nutzdaten, aber durch den Zähler kann man meherer nachfolgende Nachrichten verketten und dann von der Software wieder zusammensetzen lassen. Man sendet einfach eine Nachricht mit dem Zählerstand (z.B. 5), zählt eins runter und schickt die Nachricht mit den nächsten Daten, etc. Ist der Zähler beim Empfänger auf 0 gesunken, setzt dieser die Daten wieder zusammen, überprüft evtl. ob alle Daten vorhanden sind und verarbeitet diese. Damit könnten z.B. auch Texte übertragen werden, nicht nur kryptische Zahlen... Was haltet Ihr davon? Optimieren kann man sicher noch einiges, aber es ist zumindest mal ein Anfang...
@Ithamar, die Aufteilung der Knotenadressbits muss nicht festgelegt werden. Jeder wie er es mag. Allerdings sollte das Ereignis selbst ( z.B. Taster 0 wurde gedrückt ) mit eingeplant werden. Die letzten Bits wären da schon genau richtig. Auch muss ich im Protokoll nicht festlegen ob das Gesendete eine Event oder eine Adresse war. Die Empfänger erkennen das in Ihrer Auswertung schon anhand der Erkenntnis das es die eigene Adresse war. Das "Ereignis" ist dann der auszuführende Befehl. Koopi
@Ithamar, was ich auch noch für wichtig halte: 29 Bit sind sehr viel. Nicht als Adressraum aber es muß ja auch jeder Aktor eine Compareliste haben mit der er die für ihn wichtigen Frames filtert. Ich habe bei mir für 12 Aktoren 50 Einträge. Mit dem drumherum sind das ruckzuck einige Hundert Byte die durchsucht werden müssen. Koopi
@Koopi genau deswegen halte ich eine Aufteilung für sinnvoll. Denn mit sinnvollen Aufteilungen können Masken gesetzt werden, mit denen jeder Knoten bestimmen kann, ob eine Nachricht für ihn relevant ist oder nicht. Aber wenn man keine Festlegungen trifft, ist beispielsweise ein Router-Baustein nicht ohne weiteres implementierbar, jeder müsste anhand seiner Adressverteilung die Firmware umprogrammieren. Und dann ginge der Vorteil eines gemeinsamen Projekts wieder teilweise flöten. Natürlich ist es ein Bastelprojekt, und jeder sollte seine Einstellungen so vornehmen können wie er will, aber nicht jeder will das, denke ich. Wenn ich beispielsweise sage, bestimmte ID-Bereiche sind für eindeutige Adressen reserviert, kann eine Visualisierungssoftware das Netz überprüfen, und wurde eine ID doppelt vergeben, schlägt sie Alarm. Die letzten Bits für Events zu vergeben, halte ich für nicht schlecht, das könnte man ja mit einbauen. Aber gewisse Vorgaben würde ich schon festlegen - zwar gemeinsam, dass jeder seine Vorschläge mit einbauen kann, aber doch so, dass sich jeder an gewisse Richtlinien hält. Sonst könnte ja jeder seinen eigenen Hausbus bauen, dann ist er komplett frei, hat aber auch die ganze Arbeit allein zu bewerkstelligen...
@Ithamar, ich glaube nicht das wir mit Masken was anfangen können. Die Aktoren wären zu sehr eingeschränkt. Ich habe mir die Maskenprogrammierung am "ELV-Hausbus" angeschaut. Dabei habe ich keine sinnvolle Anwendung gefunden, wenn ich genug Platz für die individuelle Zuordnung habe. Die Masken verlangen eine sehr disziplinierte Planung die sehr fehleranfällig ist. Wenn ich mir meine Comparelisten so anschaue, da finde ich auch keine Anwendung bei der ich sagen würde hier ist eine Maske hilfreich. Ich lasse mich aber gerne eines besseren belehren. Koopi
Die Alternative zu 29bit wären 11bit, und das ist ziemlich wenig. Ich habe bei mir noch eine "spezielle" Anforderung, die besagt, dass ein Knoten die Funktion eines anderen übernehmen kann (zusätzlich). Dazu läd er die Konfiguration des zu simulierenden Knotens, und tut dann anschließend so, als ob er dieser Knoten wäre. Das geht aber nur, wenn in den 29bit die eigene (echte) und die simulierte Adresse codiert ist (sonst wären die IDs nicht eindeutig). Gruß, Matthias
Die benutzung von Masken wäre für einen Router interessant. Will man z.B. zwischen Stockwerken einen HUB einrichten, kann dieser alle Pakete ignorieren, die auf dem selben Stockwerk (wie der HUB) unterwegs sind. Matthias
@MNR, auch da hätte ich schon wieder ein Problem. Der Knoten oben an der Treppe soll mit einem Taster das Licht nach unten bedienen und mit dem Anderen das Flurlicht in der aktuellen Etage. Außerdem möchte ich vom Wohnzimmer aus die Rollos der Kinder betätigen. Das ist nicht ausgedacht, das lebe ich so. Noch wichtiger mein Webserver muss alles sehen, sonst brauche ich ihn nicht. Die beiden Etagen unterscheiden sich auch in dem zugeteilten Adressbereich, aber ein Filter zwischen den Stockwerken würde mir nicht helfen. Koopi
@MNR, @alle 11 Bit sind zu wenig. Wenn man aber z.B. 5 von den 29 Bit nicht nutzt ist man schon nur noch bei 3 Byte. 4 Bit immer konstant + High-Adresse, Low-Adresse und Event. Zumindest eine Überlegung wert. Koopi
Ich denke, hier muß man sich den Unterschied von Ereignis- und Adressprotokoll klar machen. Ereignisse müssen immer überall hin, da der/die Empfänger entscheidet, ob er damit was anfangen kann. Adresspakete sind aber im allgemeinen an einen bestimmten Empfänger/Gruppe gerichtet. Der Webserver empfängt alle Ereignisse. Und er kann über das Adressprotokoll auch alle Empfänger erreichen. Wie man die 29/24 Bit verteilt, ist aber tatsächlich nicht trivial... Ich bin im Moment bei: 1. Byte: echte Adresse 2. Byte: Absenderadresse (echt oder simuliert) 3. Byte: Pakettyp (weiter unterteilt) Wobei ich aber auch keinen Router/HUB/Switch plane, und mir 256 Adressen völlig ausreichen. Gruß, Matthias
@Koopi: Das war auch meine Idee - die oberen 4 Bits sind dafür da, das Netzwerk zu kennzeichnen - wenn man nur eins hat, sind die natürlich alle 0. Ich würde mich gern soweit es geht an die IP-Protokollfamilie halten. Im Internet und in lokalen Netzen ist diese Technik seit Jahren erfolgreich in Betrieb und sehr flexibel. So sollte unser Bus auch sein. Beispiel mit der Routing-Geschichte: Werden zwei Busse über einen Router verbunden, achtet der nur auf die oberen 4 Bits - ist das Ziel ausserhalb des lokalen Netzes, schaut er ob er die Nachricht weiterleiten soll oder nicht. Da gibt es zwei Möglichkeiten: Entweder er leitet einfach alles weiter, was nicht für das lokale Netz bestimmt ist (ist am einfachsten zu programmieren) oder er schaut, ob sich hinter ihm ein Netz befindet, für das die Nachricht bestimmt ist. Dazu braucht er natürlich Tabellen, die ihm diese Informationen mitteilen, was etwas mehr Aufwand bedeutet, aber weniger Traffic erzeugt. Für die Maske bedeutet das, dass die obersten 4 Bits maskiert werden, ist die AND-Verknüpfung erfolgreich, wird das Paket verarbeitet, ansonsten ignoriert. Wenn man jetzt noch Sonderfälle (z.B. Broadcast-Adressen) einführt, kann man auch netzübergreifend arbeiten, was z.B. wichtig für eine Visualisierungssoftware ist. Damit wären die 4 Bits schon mal weg - jetzt könnte man noch 3x8 Bits (oder wie auch immer die Aufteilung ist) vergeben. Ein Teil davon wäre sinnvoll für Nachrichten-IDs (beispielsweise indem man das höchste Bit toggelt), der andere Teil für Adressen. Dann könnte man zum Beispiel nach Stockwerken strukturieren, muss man aber nicht. Genauso wie ich ein 10.0.0.0'er Netzwerk für LANs entweder als ein riesiges Netz mit vielen Adressen aufteilen kann (Subnetzmaske 255.0.0.0) oder als mehrere kleine (mit beispielsweise Subnetzmaske 255.255.255.0), könnte ich das dann hier auch tun. Und damit stellt das "im Erdgeschoss ein Gerät im 1. Stock bedienen" gar kein Problem dar, denn der Router kann das ja weiterleiten. Wenn man mit Routern arbeiten will. Meine Idee war lediglich, einen Vorschlag für die Strukturierung zu machen, indem man nach Stockwerken gruppiert. Das hätte lediglich für die Übersichtlichkeit was zur Folge, an der Funktionsweise ändert sich nichts, genauso wie ich der Lampe im Keller die ID 1 geben könnte, dem Schalter im 2. Stock die ID 2, dann im Erdgeschoss fürs Rollo die ID 3, etc... Das funktioniert natürlich genauso, aber schöner wärs z.B. die Lampe im Keller hat 1.1, das Rollo im Erdgeschoss die ID 2.1 und der Schalter im 2. Stock die ID 4.1 - dann sehe ich sofort was wohingehört...
Ich sehe keinen Nutzen in CanIdBits, die das Subnetz näher bestimmen sollen. Routing im Hausnetz ist wirklich unnötig und vermutlich sogar unerwünscht, da ein Protokollknoten oder Debugmonitor dann nicht alles mitbekäme... oder habt ihr Angst den Bus zu überlasten? @MNR: > 1. Byte: echte Adresse > 2. Byte: Absenderadresse (echt oder simuliert) > 3. Byte: Pakettyp (weiter unterteilt) Was meinst du mit echter Adresse und was mit Absenderadresse? Pakettyp würde ich in der CanId weiter oben bei den höherwertigen Bits anordnen - dann lassen sich die verschiedenen Pakettypen (=Botschaftstypen?) in einem CanTrace besser unterscheiden und filtern/sortieren (rein fürs Auge). Prinzipiell würde ich deiner Aufteilung aber zustimmen. Und noch was ganz anderes zum Thema Maskierung: Selbst wenn jeder Knoten alle CanIds per Software auswerten müsste - viel Zeit würde das nicht kosten. Ich gehe mal von großzügigen 20us aus, um zu entscheiden, ob das aktuelle CanTelegramm für den Knoten interessant ist oder nicht. Das nächste Telegramm kommt (bei 100kBit/s Übertragungsrate) im Schnitt 1ms später (bei 100% Buslast!). Das macht dann maximal 2% Prozessorauslastung... also fast vernachlässigbar - bei langen Nachrichten oder weniger Buslast noch weniger!
@and_ref: Routing find ich deswegen sinnvoll, dass z.B. bei einem Kurzschluss auf der CAN-Leitung nicht der ganze Bus tot ist, sondern nur ein Segment. Und es dient der schöneren Strukturierung bei größeren Netzen. Für ein paar Teilnehmer rentiert sich es nicht, aber was ist wenn mal größere Projekte oder unterschiedliche verbunden werden sollen? Beispielsweise möchte ich einen Hausbus aufbauen und dann noch einen kleinen Steuerungsbus, der mit Hausbus nicht unbedingt viel zu tun hat, aber einige Überschneidungen gibts schon. Mit nem Router könnte man das schön trennen, und nur ein paar Kommandos übertragen.
> Routing find ich deswegen sinnvoll, dass z.B. bei einem Kurzschluss > auf der CAN-Leitung nicht der ganze Bus tot ist, sondern nur ein > Segment. Keine Frage - da reicht aber eine dumme Bridge oder wie auch immer du das bezeichnen magst. Routing in Abhängigkeit der CanId/Daten hat damit aber nichts zu tun. Auftrennen des Busses in physikalisch verschiedene Can-Segmente macht natürlich Sinn. > möchte ich einen Hausbus aufbauen und dann noch einen > kleinen Steuerungsbus Hausbus und Steuerungsbus???
@and_ref, bei mir muss jeder Knoten alle Frames auswerten. Im Extremfall mit ca. 50 Einträgen vergleichen. Das ist ein Vergleich mit mehrfach indizierten Variablen. Das sind bei mir ca. 600us. Mein Bus läuft mit 10KBit. Das macht bei mir nur 10%. Aber es gibt ja noch viele andere Dinge die erledigt werden möchten. Das summiert sich. @Ithamar, wofür gibt es echte und Absenderadresse? and_ref ich trenne meine Segment indem ich zwei Busmodule mit den seriellen Schnittstellen verbinde und im Transparentmodus betreibe. So sind die Segmente physikalisch getrennt aber die Daten werden übermittelt. Koopi
> bei mir muss jeder Knoten alle Frames auswerten. Im Extremfall mit > ca. 50 Einträgen vergleichen. Ok, ich ging davon aus, daß jeder Knoten nur eine Adresse ((pro Nachrichtentyp)) hat, auf die er hören muss. D.h. aber auch in deinem Fall, daß wenn die 50Einträge "verbraucht" sind, dann kann der Knoten keine neuen Telegramme sprich Informationen mehr annehmen - richtig? Wie viele Einträge (und wozu) hast du eigentlich in einem typischen Knoten in Gebrauch (~10?).
@and_ref, jedes Frame ( z.B. Taster 4 des Knoten 0x204 wurde losgelassen ) auf das ein Aktor reagieren soll ist mit seiner Knotenadresse und dem Ereignis in die Compareliste eingetragen. Desweiteren steht in dem Eintrag noch welcher der Aktoren ( 12 pro Modul + 4 virtuelle ) mit welcher Anwendung ( z.B. Monokippstufenfunktion EinAusFunktion Rollofunktion usw. ) und welchem Event ( z.B. Rollo expliziet runter ) bearbeitet werden soll. Damit lassen so ziemlich alle Gemeinheiten erschlagen. Ich habe ca. 50 Einträge für 12 Aktoren. Die Rolloaktoren verbrauchen die meisten Einträge, da sie von alle möglichen Tastern mit dem "lange gedrückt - Event" betätigt werden. Da habe ich die 50 Eintäge im Erdgeschossrollomodul fast erreicht. Koopi
Ich zitiere mich mal selbst: "Ich habe bei mir noch eine "spezielle" Anforderung, die besagt, dass ein Knoten die Funktion eines anderen übernehmen kann (zusätzlich). Dazu läd er die Konfiguration des zu simulierenden Knotens, und tut dann anschließend so, als ob er dieser Knoten wäre. Das geht aber nur, wenn in den 29bit die eigene (echte) und die simulierte Adresse codiert ist (sonst wären die IDs nicht eindeutig)." Dafür brauche ich die "echte" (physikalische) und die "Absenderadresse". Für Funktionen, die ein Ereignis auswerten, ist es egal, wer das Ereignis sendet. Diese reagieren auf die "Absenderadresse". Matthias
@Matthias, ein ganzes Byte dafür! Na gut. Da ja die Sensoren und oder Aktoren nicht doppelt vorhanden sind stellt sich mir die Frage: was macht man mit dem Zwillingsbruder? Koopi
Also, ich sitze im Wohnzimmer, und will in der Küche was schalten. Dann drücke ich auf meinem Wohnzimmerknoten "Küche" und der funktioniert dann wie der in der Küche. Trotzdem funktioniert der in der Küche auch ganz normal. Man muß das nicht in die ID codieren. Könnte man auch in den 8 Bytes Daten unterbringen. Würde sich aber grundsätzlich nichts dran ändern. Matthias
@Matthias, ist von der Idee her nicht schlecht. Ich habe auch manchmal die Anwendung für einige Tasten. Dafür habe ich aber dem zu schaltenden "Küchen-Aktor" ein Doppelklick des Wohnzimmerknoten zugeordnet. Wenn du einen ganzen Knoten kopieren willst kannst du den Aktoren doch beide Knoten "zuordnen". Ich versuche immer jede Ausnahme zu vermeiden. Koopi
Naja, der Gag ist doch, dass ein Knoten temporär die Funktion jedes beliebigen anderen Knotens übernehmen kann. Das würde ich deshalb so machen, weil die Taster auf den Knoten nur Ereignisse senden. Die Actoren haben dann Ereignislisten. Matthias
@Matthias, < die Funktion jedes beliebigen anderen Knotens übernehmen kann > naja wie willst du einem Modul mit z.B. 6 Tastern erklären das es temporär Modul 8 von 23 möglichen simulieren soll. Wenn du nun sagst binär zweimal den dann den ... Auch gut. Aber nicht vergessen zurückzuschalten. Ich denke da wieder an meine Frau. Wenn die im Wohnzimmer steht und sich wundert warum draussen immer die Strassenlaterne mit der Wohnzimmertaste geschaltet wird. Wir sollten uns lieber einen PDA kaufen, der die Webseite des Servers aufruft und uns alles zur Verfügung stellt. Mein PDA macht das mit WLAN. Ab morgen kann es sowieso jedes Handy. Wir müssen nur die Webseite erstellen und das Handy ( z.B. MDA PRO ) demnächst für 1 Euro kaufen. Koopi
Das zurückschalten passiert automatisch nach 10 sekunden, wenn eine Frau in den Räumen detektiert wird (dann wird auch der Programmiermodus ausgeschaltet) :-)). Die Knoten wären sind bei mir grundsätzlich ahnlich aufgebaut, das käme schon hin. Das mit dem PDA hört sich gut an, ist bei mir mein Notebook, schleppe ich immer mit mir rum. Matthias
Also lasst uns mal zusammenfassen, was wir haben... Ich denke wir sind uns einig, dass wir den Knoten sowohl Adressen zuweisen wollen, als auch Nachrichten verschicken, die für mehrere Knoten bestimmt sein können, richtig? Eventuell soll bei der adressorientierten Methode auch die Absender-Adresse mitcodiert werden (bei Nachrichten macht das ja keinen Sinn). Was haben wir noch? Auch wenn die Mehrzahl hier gegen die Subnets sind, so würde ich die 4 obersten Bits für Erweiterungen reservieren, um flexibel auf neue Anforderungen reagieren zu können... Und dass ein Knoten die Arbeit eines anderen Knoten übernehmen kann - ist sicher nett, aber zwingend notwendig finde zumindest ich das nicht - dafür gibts sicher nen Workaround, ausserdem wurde ja schon der PDA angesprochen... Hab ich soweit alles richtig zusammengefasst? Frage ist jetzt, wie die Bits verteilen, bzw. was wir generell festlegen und was jeder selbst vergeben darf. Mehrere IDs pro Knoten, quasi wie die Ports im Internet? Also beispielsweise 2x8 Bit für Adressen im Netz, die restlichen 8 Bit für "Ports"? Oder andere Vorschläge?
kurzer einwurf: tcp/ip ist meinermeinung nach overkill... sollte aber vllt nicht ganz verworfen werden... viel interessanter finde ich für sowas udp :) http://www.rfc-editor.org/rfc/rfc768.txt ob man jetzt das ganze auf IP draufsetzt sei dahingestellt... da könnte man ein LightIP draus machen :) auf jeden fall auch interessant ist http://www.rfc-editor.org/rfc/rfc791.txt :) prinzipiell würde ich vorschlagen das ganze IP kompatibel zu machen,da sich dann recht einfach gateways basteln lassen würden... z.b gibts bei mir 2 gebäude.. wlan ist demnächst vorhanden .. dann könnte der temp-sensor über so eine einfache bridge über ethernet laufen :) und ganz nebenbei ist das ganze schon recht lange in verwendung => die meisten probleme die sich ergeben sind bekannt... (fragmentierung, laufzeiten, abstürze,...) 73
Genauso denke ich auch, deswegen habe ich gesagt, eine Anlehnung an die IP-Protokollfamilie fände ich nicht schlecht... Klar kann man nicht alles übernehmen, schon allein weil CAN anders aufgebaut ist - aber wo man abschauen kann, sollte man das machen, wenns was bringt ;) Übrigens: Noch einer, der für Routing wäre, also ganz so abwägig ists doch nicht oder?
Nein, das ist nicht abwegig. Es ist nur die Frage, wo willst du hin? Die meisten wollen vermutlich "nur" ihr Haus damit automatisieren, und dann ist das overkill. Mann könnte sich die Option ja für eine zweite Aufbaustufe offenhalten. "Eventuell soll bei der adressorientierten Methode auch die Absender-Adresse mitcodiert werden (bei Nachrichten macht das ja keinen Sinn)." M.E. nach macht das nur bei Ereignissen Sinn, woran sollen die Empfänger sonst die Relevanz erkennen? Matthias
Ich will einfach verschiedene Möglichkeiten offenhalten. Nichts ist schlimmer als später festzustellen, dass man einen groben Schnitzer bei der Planung gemacht hat - diesen dann rauszubekommen ist schwer bis unmöglich. Warum soll auf IPv6 umgestellt werden? Weil die IP-Adressen ausgehen. Damals dachte niemand, dass irgendwann so viele Geräte vernetzt werden sollen, jetzt haben wir den Salat ;) Okay, ich glaube nicht, dass unser Projekt irgendwann so groß wird, aber vorsorgen kann man ja oder? Und nehmen wir mal an, unser System funktioniert mal so gut, dass evtl. sogar ein paar Knoten in Serie gehen und es eine günstige Alternative zu anderen Bussystemen bietet - vielleicht wäre es auch für größere Projekte interessant. Nein, ich bin nicht größenwahnsinnig, aber ich glaub auch nicht, dass Linus Torvald damals damit gerechnet hätte, was sein Betriebssystem für einen Erfolg haben wird... Bezüglich der Absenderadressen: Wenn ich die IDs als Knoten-Adressen "missbrauche", macht es Sinn, zu erfahren, welcher Absender die Nachricht geschickt hat. Aber wenn ich bei Nachrichten die Absender unterscheiden will, kann ich ja einfach ne andere ID vergeben und weiss dann, dass die nur ein bestimmter Knoten verwendet. Ich würd das offenlassen ob jetzt in die IDs ein Absender mitcodiert wird oder nicht - aber von den Richtlinien her fänd ich es sinnvoller, einfach erst mal ne strikte Trennung zwischen IDs und Adressen zu machen, z.B. durch ein höherwertiges Bit.
ich würd einfach einen ip ähnlichen header machen und udp übertragen...
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
zeile 1,3-5 würd ich reinmachen.. wobei src und dest auf jeweils 2 byte
gekürzt werden und time-to-live durch einen flags-block erweitert wird
:)
drinnen ist also Version,Total-Length,Checksum,Src,Dest,Flags für
allerhand (z.B Routing-Subheader,Receive-Notification,...)
da drüber noch udp:
0 7 8 15 16 23 24 31
+--------+--------+--------+--------+
| Source | Destination |
| Port | Port |
+--------+--------+--------+--------+
| | |
| Length | Checksum |
+--------+--------+--------+--------+
|
| data octets ...
+---------------- ...
wobei man sich hier die checksumme sparen könnte.. oder eben oben im ip
header...
damit wäre schon mal viel erledigt...
ist schon eine weile her, dass ich mich mit can gespielt hab aber statt
die ziel-adresse im header einzubaun kann die ja gleich in der can-frame
sein.. interessiert ja eigentlich nicht.. fürs routen geht das packerl
an den router, der holt sich den sub-header (flag) und da steht dann
drinnen wos eigentlich hin soll... fertig..
damit das ganze wieder nett wird kommt dest aus dem header raus und src
wird 29+3 bit groß.. die 3 bits könnten doch schon als flags hergenommen
werde.. mal schaun was man da alles braucht :)
damit würde der header eigentlich schon halbwegs vernünftig ausschaun
und auch am i2c noch halbwegs funktionieren... ca 11 bytes header sind
meinermeinung nach ok...
73
@Hans Jetzt bin ich etwas verwirrt. Eine CAN Message besteht nur aus 3Bytes + 5Bit ID und 8 Bytes Daten. Wenn du 11 Byte Header hast, wo tust du denn dann die Nutzdaten hin? Die ID ist unter CAN nicht normiert, man kann also damit machen, was man möchte. Die einzige Einschränkung ist, das 2 IDs niemals gleichzeitig auftretten dürfen. Wenn man sich an Standards orientieren möchte, sollte man sich vielleicht mal CanOpen anschauen. Finde ich aber auch oversized. Matthias
Zu LINUX: Ich denke, wenn Linus Thorvald gewußt hätte, was aus seinem Projekt mal werden würde, und er versucht hätte, das zu berücksichtigen, gäbe es heute kein LINUX. Man kann sich endlos vorher Gedanken machen, was kommen könnte, irgendwann muss man mal anfangen. Und wenn die Ziele zu hoch gesteckt sind, werden sie nicht erreicht. Matthias
Jein, da kann ich dir nur teilweise Recht geben. Linux ist einfacher skalierbar als unser Projekt - deswegen sollte es eine bessere Vorplanung geben. Wenn Linux nur für 486'er PCs geschrieben worden wäre, würd es heute auch nicht in dem Maße Linux geben... Ist ja auch egal, es gibt zig Argumente für und wider... Aber ob eine Nachricht beispielsweise maximal aus 8 Bytes bestehen darf oder ob wir einen Mechanismus implementieren, der auch zusammengesetzte Nachrichten erlaubt, ist beispielsweise entscheidend. Denn berücksichtigt man das nicht und stellt später fest, dass man eigentlich mit 8 Bytes nicht auskommt, alle aber schon fest vergeben sind, dann schaut man dumm aus der Wäsche... Anfangen ja, so bald wie möglich, ich würd am liebsten auch gestern anfangen, die Knoten zu bauen. Aber ohne eine halbwegs vernünftige Planung sehe ich das Projekt bald scheitern...
Hallo, ich merke schon - ihr schwebt in anderen Gefilden als ich. Aber mal rein "ketzerisch" und theoretisch betrachtet: Was spricht eigentlich gegen eine xml Klartext Message welche alle Informationen (Empfänger, Sende, Subnetz, Nutzdaten) in sich selber enthält und erstmal broadcast verschickt wird? (Natürlich über die das entsprechende Schnittstellen Protokoll - dh. bei einer RS 232 direkt und bei can über mehrere Frames verteilt). Die einzelnen Empfänger lesen mit und filtern selber aus. Das bedeutet zwar einen höheren Programmieraufwand mit Stringverarbeitung für die XmlMessagedecodierung bietet aber dafür einen quasi beliebigen Erweiterungsfreiraum und Skalierbarkeit. Ich denke auch das die gängigen neueren Controller damit nicht überlastet wären - und das die meisten mittlerweile eh in einer textfähigen Hochsprache arbeiten. Ein anderes Problem ist sicher die Netzbelastung welche bei einer xml so ca bei faktor 4-10 liegen dürfte. Allerdings arbeiten wir nicht mehr mit 120 Baud Modems und im Zeitalter des VideoStreaming dürften die paar SteuerVariablen eigentlich kein Problem darstellen oder? Nebenbei: gibt es eigentlich irgendwo Untersuchungen/Richtlinien über den Traffic bei Gebäudeleittechnik? Auch die Adressierung bzw Neztopologie stellt bei einer frei skalierbaren Message kein Problem entweder so eine xmlElement Subnet existiert oder eben nicht. und auch ein element SubnetTyp wäre relativ frei definierbar()nur mehrfachverwendung des gleichen Elementnamen sollten vermieden und koordiniert werden. (wie beim dnic;-).Ein Einbau einer Bridge oder eines Gateway wäre kein Problem. Eine beliebig lange Textnachricht kann immer umgesetzt werden. Bei welcher Lösung auch immer. Ich möchte nicht festgelegt werden auf eine beschränkte Anzahl fester Nachrichtentypen wie Licht an oder aus bzw. Rolladen hoch und runter. Es macht zwar Sinn solche optionalen normierten Variablen in einem HausnetzProtokoll aufzunehmen aber es darf sich nicht darauf beschränken. So wäre eine wichtige Funktion für mich die Übertragung von beliebigen Meldetexten auf Display sowie die möglichkeit der Fernsteuerung/Regelung von tech. Anlagen. Eine freie Skalierung von Nachrichten wäre somit für mich unumgänglich. Und zur Zeit wüsste ich nicht wie dies mit einen festen Byteorientierten DataFrame gelöst werden könnte. guß Reinhard
darum will ich ja udp :) auf den ports sitzen die sensoren.. z.b port 1 ist ein temp sensor.. da schickst einfach ein packet hin und erschickst dir dann die daten zurück... leeres paket schickt die anzahl der sensoren, und ein byte im paket sagt dann welchen sensor.. so läuft das dann überall.. der heizungssteuerung sagst du einfach nur welcher knoten in welchem raum ist.. der schickt dann an den knoten ein packet auf port1 und weis damit welche sensoren da sind und holt sich die daten... und wenn du unbedingt xml schicken willst dann leg auf port2 halt einen xml-parser .. nur ist das overkill was die hardware anbelangt finde ich... ich will das ding bei mir zweckentfremdet über i2c laufen lassen und da solln die nodes im schlimmsten fall mega8 sein ;) @MNR soweit ich das weis kannst du ja meherer data-frames direkt hintereinander schicken... und soweit ich das sehe geht sich so eine temp-sensor abfrage in 13bytes aus...also 2 dataframeshintereinander.. und und damit bist du mehr oder minder komplett von der bit-problematik befreit.. weil da sind bereits 2 bytes für ports drinnen ;) 73
Also ich versuch nochmal zusammenzufassen - wie es aussieht, sollen mehr als 8 Bytes übertragen werden, da CAN das nicht von Haus aus bietet, müssen wir uns selbst was stricken. Spontan fallen mir zwei Möglichkeiten ein: 1. wir nehmen von den Datenbytes ein oder zwei Bytes für Übertragungsinformationen weg, die beispielsweise einen Zähler für mehrere Pakete beinhalten. Vorteil: Es können mehrere Pakete zu einem großen zusammengefasst werden. Nachteil: Weniger Nutzdaten pro Paket, mehr Overhead durch mehrere Datenpakete, die versendet werden müssen. 2. wir reservieren bestimmte IDs, die für einen Nachrichtenzähler verwendet werden. Beispiel: Die letzten 8 Bit stellen einen Zähler dar - man splittet die zu sendende Nachricht in x mal 8 Bytes auf und setzt den Zähler auf x. Gesendet wird die höchste ID zuerst, dann kommt die nächstgeringere, solange bis der Zähler auf 0 ist - damit weiss der Knoten dass alle Daten da sein sollten und er sie verarbeiten kann. Vorteil: Alle 8 Bytes können für Daten verwendet werden. Nachteil: Es stehen weniger IDs für Adressierungen zur Verfügung. Bei beiden Verfahren muss darauf geachtet werden, dass auch wirklich alle Pakete ankommen, ansonsten muss eine Neuübertragung angefordert werden. Wichtig finde ich, ist, dass die CAN-eigenen Funktionen möglichst gut ausgenutzt werden. Das sind die Prioritäten, die Remote Frames und die Error Frames... Damit alle Möglichkeiten erschlagen werden, könnte man bestimmte ID-Bereiche vergeben, einmal für Adressen, dann für einfache Nachrichten und dann vielleicht für einen mit zusammengesetzten Nachrichten. Oder fällt jemand ne bessere Möglichkeit ein?
Den IdBereich möchte ich nach möglichkeit nicht missbrauchen...
im übrigen wäre es sinnvoll den IP Header mal für unsere zwecke zu
kastrieren.. das probelm mit fragmenten wäre da drinnen nämlich auch
behandelt...
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Ex-IP+UDP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SourceId |Flags|Fragment Offset| CheckSum |Len|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | UserData |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
das sollte doch reichen oder seh ich da was falsch?
damit können wir fragmentiert senden, wissen wohers kommt, checksumme
ist drinnen, 16bit port adressen, 3 bytes userdata und ein extra
flag..
einzige einschränkung:11bit device-ids...
maximale anzahl von verschiedenen endpunkten liegen jetzt also bei
11bit*256=524288 ich glaub das reicht für jedes einfamilienhaus ;)
2 flags brauchen wir zum fragmentiert schicken.. ein 3. ist
ungenutzt..damit könnte man das zur len dazunimmt könnte man das
port-byte wegschalten und auf 4bytes zugreifen.. mit 3bit-im len-feld
ist das auch adressierbar...
ist len <4 schaut das ganze so aus:<port><n*user-byte> sonnst halt
<4*userbyte>
fslls man "raw-devices" haben will geht das damit auch ;)
ich hab mir mal 8bit genommen als frame-offset feld.. damit sind bis zu
2048byte große blöcke ohne extra zerstückelung machbar...
ich glaube das sollte schonmal ein ansatz sein :)
73
Wie wärs mit 2 Protokolle: 1 kleines (8 Byte Nutzdaten) für den normalen Prozessdaten austausch und ein längeres (n Byte) für komplexere Übertragungen? Bei CANopen wird unterschieden zwischen dem PDO (Prozess Daten Objekt) ,eben das "normale" 8Byte Protokoll und dem SDO (Service Daten Objekt, eine Sequenz von beliebig vielen Frames als Protokoll für den Objektbibliotheksaustausch bzw EDS gedacht. (Zur Zeit arbeitet übrigends ein Gremium daran diese XML Konform zu überarbeiten ;-) ) hierzu ein Zitat aus http://www.can-cia.org/press/index.php?pdf=/articles/de/2004-05-24-2 >>>>>>> Servicedatenobjekte (SDO) Ein Servicedatenobjekt (SDO) liest Einträge oder schreibt Einträge in das Objektverzeichnis. Das SDO-Transportprotokoll erlaubt es, Objekte jeder beliebigen Größe zu übertragen. Das erste Byte des ersten Segmentes enthält die notwendige Flusskontrollinformation. Unter anderem enthält es ein Toggle Bit um das Problem von doppelt erhaltenen CAN-Nachrichten zu lösen. Die nächsten drei Byte des ersten Segmentes beinhalten den Index und Sub-Index des Eintrages ins Objektverzeichnis, das gelesen oder geschrieben werden soll. Die letzten vier Byte des ersten Segmentes stehen für Nutzerdaten zur Verfügung. Das zweite und alle folgenden Segmente (welche denselben CANIdentifier benutzen), enthalten das Control-Byte und bis zu sieben Byte Nutzerdaten. Der Empfänger bestätigt jedes Segment oder einen Segmentblock, so dass eine Peer-to-Peer-Kommunikation (Client/Server) stattfindet. >>>>>>>>>>>
So ein Mix aus "normalem" und "erweitertem" Datenstrom finde ich sinnvoll, denn für ein einfaches Licht an/aus brauche ich den Überhang nicht. Frage ist, wie man zwischen beiden unterscheidet. Gibts da irgendein Bit, das man toggeln kann? Diesen IP-ähnlichen Aufbau finde ich nicht schlecht. Genial wärs natürlich, wenn man irgendwann mal CAN-Pakete über IP verschicken kann, ähnlich wie PPPoE. Auch wenn das vielleicht momentan nicht benötigt wird, aber eine Netzwerk-Infrastruktur ist oft vorhanden, warum also nicht nutzen? Aber wichtig wäre erst mal zu gucken, ob 4 Byte Nutzdaten ausreichen. Die restlichen 4 Byte für Informationen verwenden zu können wär ned schlecht, allerdings muss man auch bedenken, dass ich dann für Netto 8 Byte gleich Brutto 16 Byte + 2x den CAN-Header übertragen muss. Je langsamer die CAN-Übertragung ist, desto mehr wird der Bus auch belastet sein. Bei 100 kbit/s wären das 12,5 kbyte/s, bei einer maximalen Länge eines Datenpaketes von 111 Bits könnte man 115 Pakete pro Sekunde verschicken. Allerdings sind da keine Remote-/Errorframes mit eingerechnet. Für einfache Schaltkommandos langt das locker, aber was ist mit Geräten, die zyklisch z.B. im Sekundentakt Daten übertragen oder vielleicht noch häufiger? Könnte der Bus damit überlastet werden oder ist noch alles im grünen Bereich? Ich denke mal, dass das kein Problem darstellt, aber erstens habe ich noch nicht die Praxiserfahrung und zweitens denke ich, sollte man sowas gleich bei der Planung berücksichtigen. Im Übrigen: Sollten wirklich Geräte eingebunden werden, die den Bus stark belasten, z.B. irgendwelche Messgeräte, macht ein Routing wieder Sinn, um die Auslastung gering zu halten...
ich weis zwar nicht wie ich auf die dumme idee gekommen bin einen extra
crc einzubaun... hat der can doch drinnen ;)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Ex-IP+UDP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SourceId | Len |Flg| Port |Fragment Offset|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UserData |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
so jetzt hab ich glaubich die wunderwuzi-frame ;)
die 1.2 byte sind wichtig.. der rest kann userdata sein ;)
ist len<=4 wird das port immer und der frameoffset nur wenn ein bit in
flg gesetzt ist übertragen
len=5 => flg=00; kein frameoffset
len=6 => kein port und kein frameoffset
an ein bestimmtes port gehn also bis zu 5byte in einer frame... an port
0 auch 6 ;)
muss geteilt werden kann man also max4 byte schicken...
0 bytes an port0 brauchen also 2bytes ;)
8bytes brauchen trotzdem wieder 2 frames.. nur wie oft wird sowas
übertragen... temp-sensor 2 bytes.... 8schalter=>1byte...
73
@ithmar ich zitiere mal aus antal.de: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CANopen - festgeschriebener minimaler Funktionsumfang Die CANopen-Spezifikation beschreibt einen minimalen Funktionsumfang, den ein CANopen-Gerät erfüllen muß. Solche "Minimum Capability Devices" sind zwar als Standardprodukt nicht sonderlich sinnvoll, aber um eine "schlanke" Implementierung für spezielle Applikationen zu ermöglichen, sind viele Funktionen als optional eingestuft. Jedes CANopen-Gerät muß das CANopen-Objektverzeichnis (Tabelle 1) kennen. In diesem Verzeichnis, das denen von Profibus und Interbus-S sehr ähnlich ist, sind alle für dieses Gerät relevanten CANopen-Objekte eingetragen. Lesende und schreibende Zugriffe erfolgen mit einem Service Data Object (SDO). SDOs werden für Änderungen im Objektverzeichnis und für Statusabfragen verwendet. Jedes CANopen-Gerät verfügt über mindestens ein SDO, dem zwei CAN-Identifier zugeordnet sind. SDOs nutzen das "Multiplexed Domain Transfer Protocol" der CAL-Spezifikation. Mit ihm lassen sich Daten beliebiger Länge übertragen, wobei die Daten gegebenenfalls auf mehrere CAN-Nachrichten aufgeteilt (segmentiert) werden. In der ersten CAN-Nachricht des SDO sind vier der acht Byte mit Protokollinformationen belegt. Für Zugriffe auf Objektverzeichniseinträge mit bis zu 4 Byte Länge genügt folglich eine einzige CAN-Nachricht (expedited Transfer). Bei Datenlängen größer 4 Byte erfolgt eine segmentierte Übertragung, bei der alle auf die erste CAN-Nachricht folgenden Segmente des SDO jeweils 7 Byte Nutzdaten enthalten können. Das letzte Segment enthält eine Ende-Kennung. Ein SDO wird bestätigt übertragen, das heißt, der Empfang jedes Segments wird durch eine entsprechende CAN-Nachricht quittiert. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> so wie ich das verstehe wird durch einen normale PDO (nachrichtentyp SDO Ankündigung) die Sendung angekündigt. danach schaltet der empfänger auf SDO empfang bis die sondersequenz vorbei ist. zwei CAN systeme über internet zu verbinden ist eigentlich(theoretisch! kein großes Problem) man muß nur einen Knoten (am besten PC) als IPTransceifer auslegen welcher einen IPSocket enthält. über diesen werden alle CAN Nachrichten einfach unbehandelt in ein UDP packet gepackt/gekapselt und an eine gegenstelle übermittelt. Dort werden sie wieder ausgepackt und unbesehen in das dortige Netz gesendet. Ich glaube das nennt man kopplung auf schicht 7 !? ;-) . Von daher muß man sich keine Gedanken über Protokoll kompatibilität machen. Die möglich der (SDO)Sonderwertübertragung ist mir persönlich wichtig. In CANopen zbsp werden diese allerdings in einer niedrigen und asynchronen Priorität gesendet. da der Bus wohl kaum permanent mit steuerspitzen belastet ist sehe ich hier kein Problem. Trotzdem könnte ich mich mit einem Routingmodell anfreunden. Allerdings sollte man hier wie bei SDO<>PDO eine optionale Lösung finden die nicht jeder implementieren muß: 1 Modell ala Simpel für "Hausnetze ohne Subnetze" 1 Modell ala Multiple für strukturierte Netze Das heißt mann müßte in der ID/Adressvergabe eine Lösung finden welche simple adressen ermöglicht aber strukturierte adressen nicht verbaut. Müsste doch möglich sein? inwieweit sieht CAN eigentlich Subnetze vor?
Klar, ich bin auch der Meinung, so einfach wie möglich, aber ausbaubar. Natürlich wird jemand, der ne kleine Wohnung vernetzt, von Routing nix wissen wollen - daher war meine Idee, die ersten 5 Bits einfach zu reservieren - bei kleinen Netzen sind alle einfach 0, bei größeren vergibt man den Netzen einfach ne Nummer. Dann kann man ganz einfach die Netze erweitern und braucht sich aber nicht mit Dingen rumärgern, die man nicht braucht. Und 5 Bits weniger sind immer noch 24 Bits, mit denen man einiges anstellen kann. Notfalls kann man die ja auch für andere Dinge verwenden... @Hans: Der Vorschlag gefällt mir schon sehr gut, eventuell könnte man daran noch ein wenig feilen, aber das Prinzip find ich gut. Wäre quasi Layer 3 im OSI-Modell. @Reinhard: Die Idee, das aus CanOpen zu übernehmen, finde ich auch nicht schlecht - also prinzipiell können Standard-Frames versendet werden mit 8 Bytes und ein spezieller Frame kündigt die Übertragung von unseren "Spezialpaketen" an - das wäre zwar ein Frame Overhead, aber würde schön trennen zwischen normalen und erweiterten Paketen. Vielleicht könnte man dazu irgendwie die Remote Frames zweckentfremden?
Noch ein Nachtrag: Gestern habe ich eine Mail von meinem Professor für Automatisierungstechnik bekommen, der durch Zufall diese Diskussion verfolgt hat. Er hat mir erlaubt, Auszüge aus der Mail zu posten, die möchte ich euch nicht vorenthalten: <Zitat Anfang> 1. aus CAN Open würde ich übernehmen( jedoch 29 Bit verwenden!): Festlegung von festen Stationsadressen (mehr als 8 Bit?) - PDO und SDO) - der Blocktransfermechanismus wie bei SDOs sollte ausreichen. Evtl um "Portkennung" erweitern (siehe Bitbus). Nur min. SDO-Objekte Hersteller,Typ) unterstützen. - Networkmanagement IDs + Kommandos - optional Nodegarding um Stationsausfall zu erkennen. 2. Für die eigentliche Logik/Automatisierung würde ich Netzwerkvariablen verwenden (wie bei LON !) und beim Hochlauf entsprechende "Tabellen" in die Knoten laden. Diese können dann autark Schaltfunktionen ausführen. Variablen werden vom Erzeuger als Broad-/Multicast versendet und nur von den Knoten ausgewertet, die einen entsprechenden Tabelleneintrag haben. Dazu benötigt man jedoch eine Art Konfigurationstool um die logischen Verbindungen zu erstellen ( hier ähnlich zu EIB) Für die Kodierung von Kommandos,nachrichten und Stationsadressen in IDs würde ich mir die J1939 für Nutzfahrzeuge anschauen. Dort kann man eine alternative Variante ableiten, ähnlich der die Sie zur Zeit diskutieren. <Zitat Ende> Ich habe noch keine Zeit gefunden, die J1939 anzuschauen, aber werde das nachholen sobald ich kann.
tjo dann machen wirs doch so:
16bit Node-ID
8bit Variable-ID/Port
5bit Flags {Broadcast,Fragmented,LastFragment,SignedInt,X}
wird gebroadcastet darf folgendes als userdata drübergehn:
1,2Byte Länge:Integer (sie flag SignedInt)
4Byte Länge:Float
das wäre dann der wert für die übertragene variable...
wird nicht gebroadcastet:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Ex-IP+UDP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SourceId |Fragment Offset| UserData |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UserData |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
port und frame-flags sind im Id-Bereich...
16bit Node-Adressen sind sicher keine falsche idee, weil mann dann
"netze" aufziehn kann...
die oberen 8bit sind dann netz-Id und die unteren 8 die dazugehörigen
nodes... für alle die da haben wollen/brauchen...
damit sollte eigentlich jetzt fast alles erschlagen sein...
den standart werd ich mir mal geben wenn ich nicht gerade unter stress
leide ;)
Das programmieren werden wir dann einfach über einen block-transfer auf
ein bestimmtes port machen...z.b port 0 ist generell das
programmierport...
pro zu programmierender variable steht dann ein block ...
<16bit SenderId><8bit VariableId><8bit allfällige flags><1,2 oder 4byte
vergleichswert>,...
1280bytes können als ein paket übertragen werden.. das macht dann im
schlimmsten fall 160 variablen und im besten fall 256... sollte doch
reichen
73
Angehängte Dateien:
-
overview_saej1939.jpg
13 KB
da stimme ich deinem Prof weitgehend zu. die benutzung von can 2B war mir auch schon die ganze Zeit im kopf und ich hatte mich schon gefragt warum wir uns so auf die 11bit eingeschossen hatten. SDO PDO hatte ich ja auch schon angesprochen. Was ist hier mit "Porterkennung" gemeint? Bei den Netzwerkvariablen und Kommandos hatte ich mir eigentlich ursprünglich "frei erweiterbare" xml Packete vorgestellt die von den einzelnen Knoten ausgewertet werden. Aber ich gebe zu das man so nicht richtig die hervoragende CAN Infrastruktur nutzen kann. Mein Konzept hatte ich ursprünglich auch für die 485 bzw ethernet konzipiert. Ich muß mir auch nochmal den LON ansehen (hat da jemand nen guten Link?) Die EIB Programmier/KonfigurationsPhilosophie hat mir eigentlich nicht so gut gefallen. (ich bin auch lieber am programmieren als am projektieren) das jonglieren mit den geräteadressen und die zuordnung der wenigen festen spez. Funktionen fand ich nicht so berauschend. jedenfalls bin ich von der SPS her ein anderes Paradigma gewohnt. Auf jedenfall muss hier noch mal grundsätzliche das Programmierkonzept besprochen werden. Erst danach kann man das Protokoll Sinnvoll festlegen! ZBSP -Ob jeder Knoten eine völlig individuelle Software bekommt. -Die Software aufgeteilt wird in ein "OSHB"-OS und Individuelle Applikationen. -Die Software aufgeteilt wird in ein "OSHB"-OS und verschiedene optionale Standard-Module. -Es existiert nur ein Grund OSHB-OS. Die Eigenarten werden Parametriert/Projektiert und das Verhalten über Netzwerkkommandos und Variablen gesteuert. Oder eben ne sinnvolle Mischform.... Die Idee mit der J1939 hat mich nachhaltig begeistert. (Unter anderem weil bei mir eh noch ein NMEA2000(Bus auf zbsp Segelyachten) Projekt ansteht welches auf der J1939 basiert.) Da ich davonn ausgehe das der OSHB eher für Hobby und SemiProfis gedacht ist als für die Industrie sollte das Schwergewicht auch mehr in der universialität und Kostenvermeidung liegen als in der Perfektion. Da macht es schon Sinn wenn man in seinem Haus, Wohnmobil, Auto und Schiff die gleiche Technik verwendet. Auch durch die Massenherstellung bedingt könnten Bauteile preiswerter bezogen werden (zBsp von Schrottplatz). Auch ähneln sich die Aufgaben und Problematiken eines Fahrzeuges und eines Privathauses (Anzahl der Knoten, licht schalten, Motor bzw Heizung regeln , Kommunikation usw) mehr als die ähn lichkeit mit einem Gebäudekomplex (EIB) oder Fertigungsstrasse (Profibus, CANopen) Von daher ist es Sinnvoll dort auch "anleihen" zu machen. Ich habe mal als anhang eine J1939 übersicht eingefügt. Weiterhin habe ich mal eine Beschreibung eines j1939 Anzeigerätes gefunden welches als Muster für ein OSHB Bedienpanel dienen könnte.. http://www.fwmurphy.com/pdf/PV-04094N-G.pdf bis denne.. reinhard
zum thema routing: was habt ihr da im Sinn? die Anwendung von Router welche nach vorliegenden Routingtabellen die nachricht weitersenden oder eher einfache Buskoppler/Repeater welche einfach einen bestimmten Adressbereich ausmaskieren und filtern?
Sowohl als auch - einerseits wäre ein echter Router, der mit Routing-Tabellen arbeitet, nicht schlecht. Genauso geht natürlich auch ein erweiterter Repeater, der rudimentäre Routing-Funktionen hat, besser gesagt einfach die Broadcast Domäne begrenzt. Ich denke das kann man je nach Bedarf implementieren, oder eben ganz weglassen wenn man nur ein einziges Netzwerk betreibt...
routing dürfte das kleinste aller probleme sein.. btw in mein letztes posting.. das X-flag wird zu Variable/IsRawData... ists eine variable gilt gleichen wie für den broadcast fall.. bis auf dass hier 2bytes SenderId+1,2 oder 4byte variablen-wert übermittelt wird.. gebraucht z.b beim fernsteuern von licht..vom pc aus... damit sollten wir jetzt den spagat aus rein auf variablen-basierenden bus und datenübertragung ala ethernet machen können... 73
Eigentlich sehe ich dann keinen Grund ein komplexes Adresssystem zu
kreieren. Es könnte also jeder seine eigenen Adressen/Adressbereiche
frei verteilen (CAN 2.0 B Konform!?)und über jumper oder Parametrierung
einstellen.
Oder würde es Sinn machen gewisse Adressbereiche(nach Funktion oder
Localität?) zu normieren/reservieren.
zbsp aufgrund Gruppenbildung, Vordefinition von Gruppensendungen
("Zentrale an alle Leuchtstoffröhren") oder ("brennt im 1 Stock noch
Licht")
reinhard
> Oder würde es Sinn machen gewisse Adressbereiche(nach Funktion oder > Localität?) zu normieren/reservieren. Das halte ich schon für sinnvoll - nur so kann man die Knoten anderer ohne großes Umprogrammieren in das eigene Projekt aufnehmen. Natürlich muss es auch genügend Spielraum geben, eigene Bereiche und Adressen zu definieren, aber es sollte schon gewisse Standards / Empfehlungen geben. Beispiel könnte ein Broadcast-Bereich dazu dienen, die Knoten nach ihren Fähigkeiten abzufragen. Dann kann die Verwaltungssoftware neue Knoten identifizieren, anhand einer XML-Beschreibung auf der Festplatte bzw. aus dem Internet die Fähigkeiten anzeigen und bereitstellen. Dann kann man relativ einfach die Knoten zentral verwalten, ohne groß neue Firmware aufspielen zu müssen, etc. Genauso wäre es denkbar, einen Broadcast-Bereich für Firmware-Updates zu definieren. Bestimmte Knoten, die man vorher in einen Programmiermodus setzt, bekommen dann per Broadcast die neueste Software, so wie es in einem anderen Thread schon vorgeschlagen wurde...
@Hans ich halte jetzt eigentlich doch eine gängige CAN konforme Adressierung (MSG Objekt/Funktionsorientiert) für sinnvoller als eine IP konforme (Adressorientiert) die das bedingt sich schon aus dem Aufgaben und Umgebungs gebiet . CAN - wenig Adressen- kaum struktur - wenig nutzdaten pro päckchen - wenig eigenintelligenz der empfänger WAN - viele Adressen - chaotische struktur - viel nutzlast pro verbindung - relativ hohe intelligenz der knoten. Da bietet sich schon an das gleich in der Adresse schon die Funktion mit berücksichtigt wird um den (dummen)Knoten zu entlasten. Falls wirlich mal eine nachricht fernverschickt wird so kann das ja in einem Gateway umverpackt werden. So macht man sich in der Hauspost ja auch keine gedanken über Postleitzahlen. entscheidend ist der name drauf und richtiger eingangskorb ;-) für den Externverkehr ist die Poststelle zuständig. Von daher halte ich es als zu verfrüht sich jetzt schon gedanken über die einzelnen Bits der Adresse zu machen. Ich möchte lieber vorher noch die Typisierung der Nachrichtenarten, die Verteilung der Intelligenz, das Zugriffsverfahren wie event, zyklisch, polling, Server oder Peers , erfordrliche antwortzeiten usw, klären und die Verteilung der Funktionalität . Erst wenn ich genau weiss was verschickt wird kann ich mir gedanken um die genaue Verpackung machen. bis denne.. reinhard
>Genauso wäre es denkbar, einen Broadcast-Bereich für Firmware->Updates >zu definieren. Bestimmte Knoten, die man vorher in einen >Programmiermodus setzt, bekommen dann per Broadcast die neueste >Software, so wie es in einem anderen Thread schon vorgeschlagen >wurde... wenn wir schon beim Thema Firmware sind: hat sich schon jemand Gedanken gemacht über die Controller Software? Ich habe da so die Idee das man ein (pro ControllerTyp) Betriebsprogramm OS entwickelt welche alle Basisfunktionen/Objekte des OS-HB enthält (wie CAN Protokollhandling,Nachrichtenauswertung/erstellung, Portzugriff, SDO,PDO tabellen). Dieses läuft dann als virtuelle Maschine VM auf den Controller . Zusätzlich enthält es in einem Speicherbereich eine(intern oder ext i2c EEPROM) Befehlsliste oder Anwenderapplikation welche von der VM interpretiert wird. Die Befehlsliste besteht aus einzelnen Token welche jeweils eine Basisfunktion repräsentiert. Die einzelnen Token könnten über die CAN Nachrichten eingelesen werden oder auch seriell geladen werden. Weiterhin könnte ein Compiler konstruiert werden welcher aus einer reduzierten und OS-HB angepassten Hochsprachdialekt (Basic oder Java?)eben diesen Tokencode erzeugt. Als Anleihe könnte man mal die c.control foren aufsuchen, dort gibt es projekte wo an solchen Projekte gearbeitet wird (zbsp openMikro) Der Nachteil wäre ein hoher einmaliger Programmieraufwand um die VM pro ControllerTypzu entwickeln. Dagegen stände der Vorteil das 1. danach eine Application von jedem schnell erstellt werden kann. 2. Einzelne Befehle oder ganze Makros schnell während des Betriebes manuell oder automatisch eingespielt werden können. 3. Möglichkeit des Aufbaus von Controllerunabhängigen StandardBibliotheken und Treiber aber dies ist wohl ein thema für ein extra thread gruss reinhard reinhard
Hmm ein OS hört sich schon toll an, ist aber dann schon fast zu hart finde ich. Zumindest zum Anfang... Das müsste ja auf verschiedenen Controllern laufen, braucht CPU und Speicherkapazität und es stellt sich die Frage ob die Kosten-/Nutzenrechnung aufgeht. Vielleicht sollte man das ein wenig nach hinten schieben, wenn wir überhaupt mal ein funktionsfähiges System haben - dann können wir OS und die Programmierung auch noch besser spezialisieren. Zum Thema Adressen, Bits etc.: Ich denke das Protokoll und die grobe sonstige Strukturierung muss Hand in Hand geschehen. Definierst du nur z.B. die Antwortzeiten, legst du vielleicht was fest, was man gar nicht so festlegen kann, weil z.B. der Bus zu langsam, die Messages zu lang sind und demnach zu lang brauchen... Auch wenns schön wäre, alles der Reihe nach zu entwickeln, beispielsweise das OSI-Modell einfach von vorn bis hinten durch, so denke ich würden wir da früher oder später auf Schwierigkeiten stoßen...
also ich bin schon verdammt weit weg von IP mit meiner vorstellung... aber nicht ganzweg.. stell das das broadcast bit ein und schon schickst du messages.. an alle.. stell das bit aus und du schickst pakete an 1ne station und kannst IP-ähnlich zugreifen.. sonnst ist ja das "port" ja deine message-id oder wie auch immer dus jetzt nennst.... im prinzip kann man eine variable als status variable oder wie auch immer nennen willst... 73
>Hmm ein OS hört sich schon toll an, ist aber dann schon fast zu hart >finde ich. Zumindest zum Anfang... ;-) ich meinte ja nur so (weil du schon beim Firmwareupdate wars..), dass ich schon weitergehende Gedanken habe bezüglich der Befehlsvariablenübergabe und den zu übertragenden Nachrichtenarten. >Das müsste ja auf verschiedenen >Controllern laufen, braucht CPU und Speicherkapazität und es stellt muß nicht aber man hätte die Möglichkeit! Ansonsten muss man bei der Controllersoftware eben anfangs darauf achten das man zwischen Basisaufgaben wie Protokollhandling ,Schnittstellenansteuerung... und spezielle Aufgaben des jeweiligen Controllers unterteilt. Das Ganze in vielen kleinen Funktionsbibliotheken gepackt, die auf allen Versionen die gleiche Bezeichnung und Parameter haben. Diese könnten dann auf allen Controllern gleich angesprochen werden. Sie dann auch durch einzelne Tooken ansprechen zu können wäre keine Utopie. Wichtig wäre nur das vor der Programmierung die Funktionen spezifiziert werden.... aber gut später. >sich die Frage ob die Kosten-/Nutzenrechnung aufgeht. welche Rechnung?? :-) >Zum Thema Adressen, Bits etc.: Ich denke das Protokoll und die grobe >sonstige Strukturierung muss Hand in Hand geschehen. Definierst du Klar. Meine Meinung auch. Selbstverstädlich muss vor allem anderen das Protokoll als zentraler Projektpunkt stehen. Was ich nur sagen wollte ist bevor im Protokoll das letzte Bit gesetzt wird sollte es zumindest grobstrukturiert sein.Ebenso die anderen Gebiete. Vorher hab ich den Kopf dafür nicht frei.... Weiterhin ist es schade um die viele Arbeit. (Beim Feinschliff fange ich ja auch nicht mit der 250 Körnung an.. Und jetzt lese ich erstmal über die J1939 ....
Übrigends habe ich was nettes gefunden über das CAN Protokoll... http://vvl.fh-reutlingen.de/cocoon/my/vvl/vvl?lang=de&goto_page=P_DEMO_JRCC&open=1 lohnt sich
Kenn mich nicht so gut aus , aber warum nicht canopen als protokoll?
Wenn Du die Sourcen für CANOpen auf einem AVR hast sofort ! Leider sind die käuflich erwerbbaren Sourcen schweineteuer :( Bei Verwendung von CANOpen könnte man die Steuerung auch Später mal z.B. mit Möller Winblockmodulen oder anderen "professionellen" Baugruppen nachrüsten. MfG Uwe
Erstmal geht es doch nur um das Protokoll (die Form der Datenpackete , Handshakemechanismus , spezifizierung der zur Verfügung stehenden Daten) da wir nur eine kleine Teilnmenge der möglichen Funktionalität benötigen kann ich mir eine Entwicklung nicht als so schwierig vorstellen? Und ich gehe mal davonn aus das bei der Entwicklung des CANOpen Protokolls viel auch schlechte Erfahrungen eingeflossen sind die wir nicht wiederholen müssen. Allerdings frage ich mich wie hoch die Wahrscheinlichkeit ist das in einem Amateurhausbus ein industrieelles CANopengerät verwendet wird? Dann wohl eher ein Sensor aus der Fahrzeugssteuerung. Leider finde ich keine brauchbaren Unterlagen über das S1939 Fahrzeugprotokoll. Weiterhin frage ich mich inwieweit die unterschiedlichen CAN Protokolle kompatibel sind bzw inwieweit sie parallell auf einem Bus angewendet werden können?
Da gibts noch ein paar Infos zu J1939: http://www.elektroniknet.de/topics/kommunikation/fachthemen/2005/0030/index.htm Und hier noch welche in Englisch: http://www.sae.org/products/j1939.htm
Also ich versuche mal ein wenig zusammenzufassen und zu spezifizieren, damit wir langsam richtung Ergebnis kommen. Mein Vorschlag: Wie in CanOpen/SNMP/etc. gibt es eine strukturierte Objektdatenbank. Die Eigenschaften werden für jeden Knoten als XML erstellt und auf einem zentralen Server (mit Mirrors) gespeichert. In dieser Beschreibung steht drin, was ein Gerät kann, und welche Variablen gelesen/geschrieben werden könnten und von welchem Typ (Int, String, ...) die sind. Damit hätten wir schon mal die Eigenschaften der Knoten beschrieben, dann fehlt noch die Kommunikation zwischen den Geräten. Um CANOpen-konform zu bleiben könnte man die verwendeten IDs bei unseren Erweiterungen aussparen bzw. erweitern. Normalerweise kann man bei CANOpen nur 127 Nodes ansprechen, das finde ich etwas wenig... Da IP als Protokollvorschlag schon gekommen ist und ich die Idee nicht schlecht finde, sollte man überlegen, wie man beides unter einen Hut bekommt. Theoretisch könnte man bei IP-Netzen einfach die CAN-Pakete in UDP-Pakete einpacken und die versenden, allerdings hat man dann natürlich einen gewissen Overhead, eine Redundanz, die man nicht unbedingt nutzen kann. Aber man könnte die ungewünschten Daten einfach weg-UNDen (z.B. Checksumme), wenn diese nicht gebraucht werden. Die CAN-ID beispielsweise müsste man dann halt extra behandeln, aber das sollte auch im Bereich des Möglichen liegen... Ich bitte um Eure Meinungen, damit wieder ein wenig Schwung in die Diskussion kommt!
> Ich bitte um Eure Meinungen Mach mal ganz konkret 3 oder 4 Beispiele, was zu übertragen wäre (auf CAN), wenn du was Bestimmtes machen willst (Rolladen fahren; Temperatur abfragen; irgendeinen Parameter verstellen...) - und, wie ggf. die Antwort darauf aussieht. Vermeide die Worte "noch offen", "noch unklar", "man könnte", "vielleicht"... Mit konkret meine ich, dass du CAN-Telegramme hier aufschreibst - mit CAN-ID, Nutzdaten und kurzer Erklärung. Dann erkläre bitte anhand deiner Beispiele, was daran CANOpen-konform ist und wie sich das mit SNMP verträgt. Gelingt dir das, dann kannst du abschätzen bis wann du die ersten Prototypen (imlementiert wie beschrieben) vor dir stehen haben möchtest. Gelingt das nicht, dann musst du deine Anforderungen überdenken und vielleicht Kompromisse aufgrund von (falsch verstandener) Kompatibilität eingehen. > Also ich versuche mal ein wenig zusammenzufassen und zu > spezifizieren, damit wir langsam richtung Ergebnis kommen. guter Ansatz, jetzt noch den Weg festlegen UND losmarschieren. Die Leute werden einsteigen und mitentwickeln, wenn der erste Prototyp fertig ist und die grundlegenden Dinge geklärt sind. Also dann wenn man was "sieht".
Also ich versteh dich einerseits, dass du konkrete Daten haben möchtest, aber die gibt es einfach nicht in diesem Stadium. Momentan ist es wichtig, die Anforderungen, die jeder mit einbringen soll, denn jeder hat eine andere Umgebung, die er steuern möchte, mit einzubringen. Bei mir zum Beispiel gibt es keine Rollläden, deswegen interessiert mich das jetzt eher weniger. Aber darum gehts auch gar nicht. Was ich in meinem vorigen Beitrag festlegen wollte, sind die Eigenschaften, die Beschreibungen der einzelnen Knoten. Und sowohl bei SNMP als auch bei CANopen gibt es Tabellen, in denen die Variablen drinstehen und die Fähigkeiten und den Zustand eines Knotens beschreiben. Okay, bei SNMP ist der Variablen-Baum ein wenig größer als bei CANopen, aber es geht lediglich ums Prinzip, dass ich z.B. für jeden Knoten einen Namen vergeben kann und diesen auch abrufen kann. Wie die Knoten untereinander kommunizieren ist ein anderes Thema, aber das kann ich erst beschreiben, wenn ich weiss welche Daten übertragen werden müssen. Denn sinds mehr als die 8 Byte Nutzdaten von CAN, muss ich mir eine Möglichkeit einfallen lassen, die Daten zu splitten, etc. Leider gehts halt nicht einfach so, dass ich erst das eine festlege, dann kommt das nächste, usw. Da alles so eng miteinander vermascht ist, muss ich mich Stück für Stück an die optimale Lösung rantasten...
>Wie in CanOpen/SNMP/etc. gibt es eine strukturierte Objektdatenbank. >Die Eigenschaften werden für jeden Knoten als XML erstellt und auf >einem zentralen Server (mit Mirrors) gespeichert. In dieser >Beschreibung steht drin, was ein Gerät kann, und welche Variablen >gelesen/geschrieben werden könnten und von welchem Typ (Int, String, >...) die sind. So weit sehe ich es auch, allerdings möchte ich noch mal betonen das diese Datenbank optional ist für den Fall dass eine übergeordnete Leitebene (sprich PC) vorhanden ist - funktionieren sollte es allerdings auch ohne ! Die Übermittlung der Xml Knotenobjektbeschreibungstabelle sollte auf Anforderung gestarted werden oder - bei Neuanschluss, sozusagen Plug and Play, wie die Traps bei SNMP vom Knoten selber gepusht werden. Unklar ist mir noch inwieweit bei heterogenen Netzen (Ethernet und CAN) das Protokoll aufeinander abgestimmt wird bzw ein extra EthernetProtokoll entwickelt wird welches zwar CAN Telegramme weitertransportieren und lesen kann ansonsten aber seine eigene Sprache spricht. Ich denke (wie ich bereits im Ethernetthread schrieb) das eine Duales Protokoll das sinnvollste wäre. Also ein Binäres festframe Protokoll auf CAN Basis (für die kleineren Controler mit eher einfachen Schaltfunktionen) und ein Xml basierendes , freiskalierbares Protokoll für komplexere Aufgaben. Beide Protokolle sollten aber über CAN und Ethernet laufen können. Ich denke das CAN Protokoll sollte für das Ethernet am Header modifiziert werden, nicht um Redundanz zu vermeiden (das Ethernet hat hier genügend Kapizität) sondern um die reine Ethernet Kommunikation nicht zu verunstalten. Das bedeutet das am Gateway die CAN Ident in eine IP Adresse und eine FunktionsID gesplittet/konvertiert werden muss und in die andere Richtung muss aus IP Adresse und Funktionsnummer wieder die CAN Ident erzeugt werden. Genauso könnte für komplexe Xml Protokolle verfahren werden. Diese könnten am Gateway in diese CANopen SDO Packetserien umgepackt werden. Wichtig wäre noch die Frage wie ein Ethernet Gateway die CAN Telegramme routen soll?. Hier könnten(wie bei den Telefonvorwahlen ) spezifizierte Adressbereiche vorgesehen werden. Oder alle nicht auf den CANBus-Strang vorhandenen Adressen werden automatisch ins LAN gehievt . Eine dritte Methode wäre eine Routingliste wo die zu routenden Adressen eingetragen werden? reinhard
Ich halte den Einwand von Richard das ganze mal zu konkretisieren für angebracht und möchte mich dem anschließen. Es ist sinnvoll erst die Problematik zu erfassen bevor die letzten Protokollbits spezifiziert werden. Es muss ja ncht gleich das bis ins letzte Detail ausgetüftelte Protokoll sein .... Also halte ich es mal mit den guten Albert und wage mch mal an ein Gedankenexperiment. Scenarium I: 2 Controler verbunden über 1 CAN-Strang Austausch von einfachen Nachrichten PDO µC1: Flur.Wandschalter.DI.1, CAN Adresse 14 µC2: Garten.Leuchte.DO.5, CAN Adresse 23 Funktionsbeschreibung: Wenn im Flur der Taster S1 betätigt Soll im Garten das Relais K5 anziehen damit die Lampe H5 brennt oder auch if Flur.Wandschalter.DI(1) := True Then Garten.Leuchte.DO(5) := True Ablauf: (IMHO) 1. Taster S1 wir betätigt 2. Controler empfängt positive FlankenSignal an PortIO1 3. Controler wertet aus und hat Order daraufhin eine Message auf Bus zu Senden (sagen wir mal zBsp.??Nachrichtengruppe 7=Lichtschaltung??) 4. Controller baut sich den Frame auf 4a.Aus CANadresse 14 und Nachrichtengruppe 7 wird der CAN Object identifier "zusammengematscht" (????????) und der Header gebildet 4b. 1 DataByte IOPortnummer=1(0000 0001) 4c. 2 DataByte Zustand=Tru (1111 1111) 4d restlichen 6 DataByte bleiben leer 5. Die CAN Message wird auf den Bus gesendet und der Controler 14 wartet auf eine Quitierung, erfolgt diese nicht nach einer bestimmten zeitspanne so wiederholt er die Sendung. 6. Unter anderem empfängt auch der Garten Controler 23 die Nachricht. 7. Anhand der ObjectIdentifier hält der Controler23 diese Nachricht für sich als relevant und liest sie ein. 8. Der Controller 23 wertet die Nachricht aus und beschließt auf Grund seines Programmes seinen IOPort5 auf True zu setzen. 9.Der Controler 23 möchte den Empfang quitieren und baut die Nachricht auf. 9a der ObjektIdentifier wird übernommen und das ACK-Slot wird gesetzt. 10 Controller sendet die Quitierungsnachricht auf den Bus. 11. Controller 14 empfängt diese, wertet sie aus und beendet den Vorgang. ich bitte um Korrekturen......... folgende noch zu betrachtende Scenarien: II Anforderung von Daten RTR(Remote Transmission Request) III Packete mit SonderNachrichten (Objektbeschreibungstabellen,SDO, bzw XML über CAN) IV Einfache Packete PDO über Ethernet V RTR über Ethernet VI SonderNachrichten SDO über Ethernet VII CAN nachrichten über Ethernet Brücken. macht euch mal gedanken darüber reinhard
Lang hats gedauert, aber jetzt haben wir schon mal einen Vorschlag über das Grundgerüst des Protokolls erarbeitet. Der Rest folgt noch, aber erstmal wollten wir mit Euch darüber diskutieren und Eure Meinung dazu hören. Den Thread dazu könnt Ihr hier nachlesen: http://devel.antimon.de/hausbus/forum/viewtopic.php?t=12&postdays=0&postorder=asc&start=15 Wer an einer Entwicklung interessiert ist, möge sich doch den Thread (hauptsächlich den letzten Beitrag) durchlesen und dort seine Meinung posten, damit die ganzen Informationen nicht überall verstreut liegen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.