| (2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | Hier sollen die PC-seitigen Vereinbarungen, die sich doch einigermaßen von der µC Seite unterscheiden, gesondert besprochen werden | + | Hier sollen die PC-seitigen Vereinbarungen, die sich doch einigermaßen von der µC Seite unterscheiden, gesondert besprochen werden. |
| − | |||
| − | |||
| + | =Layer-0= | ||
<center>[[Bild:Rncomformatip.png]]</center> | <center>[[Bild:Rncomformatip.png]]</center> | ||
| − | Die Länge ist "host-order" d.h. low-Byte zuerst, immer exklusive Länge, d.h. für 4 Bytes Layer-1 Daten werden insgesamt 6 Byte übertragen. | + | Die Länge ist "host-order" d.h. low-Byte zuerst, immer exklusive Länge, d.h. für 4 Bytes Layer-1 Daten werden insgesamt 6 Byte übertragen. |
| − | + | =Layer-1= | |
| − | + | ||
| − | + | ||
| − | =Layer- | + | |
<center>[[Bild:Rncomlay1pc.png]]</center> | <center>[[Bild:Rncomlay1pc.png]]</center> | ||
| + | *Targ (target) ist die 16-Bit Zieladdresse (network order) | ||
| + | *Srce (source) ist die 16-Bit Absenderaddresse (network order) | ||
| + | *Daten ist der eigentlich Nachrichten-Inhalt | ||
| − | + | Target und Source sind systemweit eindeutige IDs. Also zum Beispiel ein ganz bestimmter AD-Converter auf einem Kontroller im Netzwerk. Oder die Steuerung für einen bestimmten Schrittmotor o.Ä. | |
| − | + | ||
| + | Wenn auf eine Message eine Antwort erfolgt, tauschen Target und Source die Plätze | ||
| − | == | + | ==Reservierte ID== |
| − | + | *'''0000''' Broadcast. diese Message wird an alle Teilnehmer verteilt. | |
| − | + | *'''0001 - 00FF''' diese Ziele sind für Funktionen des RN-SERVER reserviert. | |
| − | + | Diese werden wohl im Zuge des Projekts immer mehr erweitert werden. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | = | + | =Layer-2 (Daten)= |
| − | + | ||
| − | Um nicht ein eigenes Feld Messagetyp zu benötigen, ist es zweckmäßig, das erste Byte der Nutzdaten immer als "Daten-Kontrollbyte" festzulegen. Dadurch ist ohne generelle Erweiterung auch eine "ACK/NACK" Benachrichtigung möglich. Denn solche Nachrichten müssen oft an Stellen generiert werden, die von den Dateninhalten eigentlich keine Ahnung haben. | + | Um nicht ein eigenes Feld "Messagetyp" zu benötigen, ist es zweckmäßig, das erste Byte der Nutzdaten immer als "Daten-Kontrollbyte" festzulegen. Dadurch ist ohne generelle Erweiterung auch eine "ACK/NACK" Benachrichtigung möglich. Denn solche Nachrichten müssen oft an Stellen generiert werden, die von den Dateninhalten eigentlich keine Ahnung haben. |
Wenn wir also die beiden Werte ACK/NACK reservieren, können die anderen 254 Werte von den Applikationen frei verwendet werden (z.B. als Command-Byte), was in unserer dzt. Version wohl genügen sollte. | Wenn wir also die beiden Werte ACK/NACK reservieren, können die anderen 254 Werte von den Applikationen frei verwendet werden (z.B. als Command-Byte), was in unserer dzt. Version wohl genügen sollte. | ||
| − | *'''& | + | *'''&H01''' |
| − | + | Das folgende Datenbereich beinhaltet KEY=VALUE Angaben, wie bei "logon" beschrieben | |
| + | *'''&H02 - &HFD''' | ||
| + | dzt. fur freien Verwendung | ||
*'''&HFE''' ACK | *'''&HFE''' ACK | ||
Dieser Wert wird ausschließlich von End-Geräten als "ok" verwendet oder von I2C Agents, wenn die Übertragung technisch gklappt hat. Zusätzlich Daten sind möglich. | Dieser Wert wird ausschließlich von End-Geräten als "ok" verwendet oder von I2C Agents, wenn die Übertragung technisch gklappt hat. Zusätzlich Daten sind möglich. | ||
*'''&HFF''' (NACK/END) | *'''&HFF''' (NACK/END) | ||
Kann sowohl von Endgeräten als auch von Zwischenstationen erzeugt werden. Hier können zusätzlich noch für einen "Statuscode" Vereinbarungen zweckmäßig sein. | Kann sowohl von Endgeräten als auch von Zwischenstationen erzeugt werden. Hier können zusätzlich noch für einen "Statuscode" Vereinbarungen zweckmäßig sein. | ||
| + | |||
| + | =Protokoll= | ||
| + | ==Logon== | ||
| + | Der Client setzt einen "connect request" an IpAddr/PortNr ab. Danach sendet er eine "Logon" Nachricht im Format Layer-0, der Datenteil beinhaltet die Identifikation des Client. | ||
| + | ID=nnnnn,NAME=name,DESCRIPT=aaaaaaaa | ||
| + | alternativ, wenn ID-Klasse und. Identifier gesondert angegeben werden sollen | ||
| + | IDC=nnn,IDI=nnn,NAME=name,DESCRIPT=aaaaaaaa | ||
| + | ==Messages== | ||
| + | *Nach dem Logon gilt das Layer-1 Format (Target, Source, Daten). | ||
| + | *Der Client muß jederzeit (asynchron) Messages empfangen können. | ||
| + | *Das Verhältnis Message/Response ist unbestimmt | ||
| + | |||
| + | |||
| Zeile 44: | Zeile 55: | ||
=Siehe auch= | =Siehe auch= | ||
*[[Network Controller/PC]] | *[[Network Controller/PC]] | ||
| + | *[[Network Controller/PC Spezifikationen]] | ||
*[[Network Controller/PC Praxis]] | *[[Network Controller/PC Praxis]] | ||
Aktuelle Version vom 13. November 2006, 12:17 Uhr
Hier sollen die PC-seitigen Vereinbarungen, die sich doch einigermaßen von der µC Seite unterscheiden, gesondert besprochen werden.
Inhaltsverzeichnis
Layer-0
Die Länge ist "host-order" d.h. low-Byte zuerst, immer exklusive Länge, d.h. für 4 Bytes Layer-1 Daten werden insgesamt 6 Byte übertragen.
Layer-1
- Targ (target) ist die 16-Bit Zieladdresse (network order)
- Srce (source) ist die 16-Bit Absenderaddresse (network order)
- Daten ist der eigentlich Nachrichten-Inhalt
Target und Source sind systemweit eindeutige IDs. Also zum Beispiel ein ganz bestimmter AD-Converter auf einem Kontroller im Netzwerk. Oder die Steuerung für einen bestimmten Schrittmotor o.Ä.
Wenn auf eine Message eine Antwort erfolgt, tauschen Target und Source die Plätze
Reservierte ID
- 0000 Broadcast. diese Message wird an alle Teilnehmer verteilt.
- 0001 - 00FF diese Ziele sind für Funktionen des RN-SERVER reserviert.
Diese werden wohl im Zuge des Projekts immer mehr erweitert werden.
Layer-2 (Daten)
Um nicht ein eigenes Feld "Messagetyp" zu benötigen, ist es zweckmäßig, das erste Byte der Nutzdaten immer als "Daten-Kontrollbyte" festzulegen. Dadurch ist ohne generelle Erweiterung auch eine "ACK/NACK" Benachrichtigung möglich. Denn solche Nachrichten müssen oft an Stellen generiert werden, die von den Dateninhalten eigentlich keine Ahnung haben.
Wenn wir also die beiden Werte ACK/NACK reservieren, können die anderen 254 Werte von den Applikationen frei verwendet werden (z.B. als Command-Byte), was in unserer dzt. Version wohl genügen sollte.
- &H01
Das folgende Datenbereich beinhaltet KEY=VALUE Angaben, wie bei "logon" beschrieben
- &H02 - &HFD
dzt. fur freien Verwendung
- &HFE ACK
Dieser Wert wird ausschließlich von End-Geräten als "ok" verwendet oder von I2C Agents, wenn die Übertragung technisch gklappt hat. Zusätzlich Daten sind möglich.
- &HFF (NACK/END)
Kann sowohl von Endgeräten als auch von Zwischenstationen erzeugt werden. Hier können zusätzlich noch für einen "Statuscode" Vereinbarungen zweckmäßig sein.
Protokoll
Logon
Der Client setzt einen "connect request" an IpAddr/PortNr ab. Danach sendet er eine "Logon" Nachricht im Format Layer-0, der Datenteil beinhaltet die Identifikation des Client.
ID=nnnnn,NAME=name,DESCRIPT=aaaaaaaa
alternativ, wenn ID-Klasse und. Identifier gesondert angegeben werden sollen
IDC=nnn,IDI=nnn,NAME=name,DESCRIPT=aaaaaaaa
Messages
- Nach dem Logon gilt das Layer-1 Format (Target, Source, Daten).
- Der Client muß jederzeit (asynchron) Messages empfangen können.
- Das Verhältnis Message/Response ist unbestimmt
Autor
Siehe auch
