mikrocontroller.net

Forum: Haus & Smart Home [OS-HB] Steuerungsprotokoll


Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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! :)

Autor: peter (pebu66@gmx.at) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> * 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.

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: Peter Mahler (mahlerp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
- minimal mögliche Buslänge: ca. 500m (reicht das?)

meinst Du nicht maximal 500m ?
Was machst Du denn unter 500m ;-)

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hr. Vorragend (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man Can auch Sternförmig verteilen? Also ohne Rueckleiter so das es
kein Bus in Sternform ist.

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja mit niedrieger geschwindigkeit s.h wiki!

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: MNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: MNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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???

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?).

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: MNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: MNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: MNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Koopi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: MNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: MNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: MNR (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=/articl...




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

>>>>>>>>>>>

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: and_ref (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> inwieweit sieht CAN eigentlich Subnetze vor?
gar nicht.

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: reloni (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 ....

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Übrigends habe ich  was nettes gefunden über das CAN Protokoll...

http://vvl.fh-reutlingen.de/cocoon/my/vvl/vvl?lang...


lohnt sich

Autor: hanes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kenn mich nicht so gut aus , aber warum nicht canopen als protokoll?

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da gibts noch ein paar Infos zu J1939:

http://www.elektroniknet.de/topics/kommunikation/f...

Und hier noch welche in Englisch:

http://www.sae.org/products/j1939.htm

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Richard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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".

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: reloni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ithamar Garbe (antimon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.ph...

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.