Network Controller/PC PC-Programme - Versionsgeschichte

PicNick am 13. November 2006 um 11:17 Uhr

2006-11-13T11:17:00Z

PicNick: /* Reservierte ID */

2006-10-30T09:48:40Z

‎Reservierte ID

PicNick am 30. Oktober 2006 um 09:48 Uhr

2006-10-30T09:48:10Z

PicNick am 29. Oktober 2006 um 14:15 Uhr

2006-10-29T14:15:40Z

Neue Seite

Hier sollen die PC-seitigen Vereinbarungen, die sich doch einigermaßen von der µC Seite unterscheiden, gesondert besprochen werden

=Layer-0=
Für die unterste Schicht, Layer-0, gibt es drei Versionen:

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

Da wir für unser Projekt keine Messages verwenden wollen, die länger als 255 Byte sind, genügt es in der Praxis, erstmal nur ein Byte als Länge zu lesen, und den nächsten receive - request dann mit diesem Wert + 1 als LÄnge zu verwenden.

=Layer-1 Version 0.1=
<center>[[Bild:Rncomlay1pc.png]]</center>

===ID (Identifier)===
Die ID sollte eine systemweit eindeutige Adresse für ein Gerät sein. Also zum Beispiel ein ganz bestimmter AD-Converter auf einem Kontroller im Netzwerk. Oder die Steuerung für einen bestimmten Schrittmotor o.Ä.

====HBT Heartbeat====
====IAM "I am"====
2 (&H09) Information über ein Gerät Daten: 8-Bit Device-Index, 16-Bit ID
Eine Meldung über ein Gerät, mit Index und ID. NACH dem letzen Gerät wird der Index "FF" gesendet und kEINE ID
====ASK Suchen ID====
3 (&H0D) (Broadcast) Daten: 8-Bit NULL, 16-Bit ID
Eine Frage an alle Rechner, ob ihnen die ID bekannt ist. wenn ja, wird eine "IAM" Message von dort zurückgesendet

=Datenaufbau=
==Kontroll-Byte==
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.

*'''&H00 - &HFD'''
Zur 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.

=Autor=
* [[Benutzer:PicNick|PicNick]]

=Siehe auch=
*[[Network Controller/PC]]
*[[Network Controller/PC Praxis]]

[[Kategorie:Kommunikation]]
[[Kategorie:Software]]
[[Kategorie:Projekte]]

@@ 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>
-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. Eine der Möglichkeiten, sowas zu lesen (VB2005):
+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.
-<pre>
-     If netStream.DataAvailable Then
-          bytesRead = netStream.Read(buffer, 0, 2) ' 2 Bytes lesen (d.i. das Längen-UShort)
-          Required = buffer(0)              ' Für max. 255 Bytes reicht das low-order Byte des UShort
-          bytesRead = netStream.Read(buffer, 0, Required) ' Jetzt die Message-Daten
-' in "buffer" stehen nun nurmehr die Layer-1 Daten
-' "bytesRead" beinhaltet die Länge davon
-     End If
-</pre>
 =Layer-1=
@@ Zeile 35: / Zeile 27: @@
 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.
-*'''&H00 - &HFD'''
+*'''&H01'''
-Zur freien Verwendung
+Das folgende Datenbereich beinhaltet KEY=VALUE Angaben, wie bei "logon" beschrieben
 *'''&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.

@@ Zeile 25: / Zeile 25: @@
 ==Reservierte ID==
-*0000 Broadcast. diese Message wird an alle Teilnehmer verteilt.
+*'''0000''' Broadcast. diese Message wird an alle Teilnehmer verteilt.
-*0001 - 00FF diese Ziele sind für Funktionen des RN-SERVER reserviert.
+*'''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)=

@@ Zeile 2: / Zeile 2: @@
 =Layer-0=
 <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. Eine der Möglichkeiten, sowas zu lesen (VB2005):
-Da wir für unser Projekt keine Messages verwenden wollen, die länger als 255 Byte sind, genügt es in der Praxis, erstmal nur ein Byte als Länge zu lesen, und den nächsten receive - request dann mit diesem Wert + 1 als LÄnge zu verwenden.
+=Layer-1=
-=Layer-1 Version 0.1=
+Wenn auf eine Message eine Antwort erfolgt, tauschen Target und Source die Plätze
-<center>[[Bild:Rncomlay1pc.png]]</center>
-===ID (Identifier)===
+==Reservierte ID==
-Die ID sollte eine systemweit eindeutige Adresse für ein Gerät sein. Also zum Beispiel ein ganz bestimmter AD-Converter auf einem Kontroller im Netzwerk. Oder die Steuerung für einen bestimmten Schrittmotor o.Ä.
+*0000 Broadcast. diese Message wird an alle Teilnehmer verteilt.
-====HBT Heartbeat====
+=Layer-2 (Daten)=
-====IAM "I am"====
-(&H09) Information über ein Gerät Daten: 8-Bit Device-Index, 16-Bit ID
-Eine Meldung über ein Gerät, mit Index und ID. NACH dem letzen Gerät wird der Index "FF" gesendet und kEINE ID
-====ASK Suchen ID====
-(&H0D) (Broadcast) Daten: 8-Bit NULL, 16-Bit ID
-Eine Frage an alle Rechner, ob ihnen die ID bekannt ist. wenn ja, wird eine "IAM" Message von dort zurückgesendet
-=Datenaufbau=
+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.
-==Kontroll-Byte==
 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.
@@ Zeile 37: / Zeile 42: @@
 *'''&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.
@@ Zeile 44: / Zeile 62: @@
 =Siehe auch=
 *[[Network Controller/PC]]
 *[[Network Controller/PC Praxis]]