p90 protokoll kieback&peter ddc3200

konnte man halt an deiner ursprünglichen frage, nicht wirklich 
erkennen..

der Hersteller bietet so was nicht an?

Suche mal nach ModBusPoll

Ich ringe derzeit auch mit einem LRP 4 von Kieback&Peter.

Zumindest konnte ich die Kommunikation zwischen der LRP-Software und dem 
Kontroller schon mal abhören und etwas auseinanderdividieren.

Ich bin schon mehrmals beim Googlen über diesen Thread gestolpert, 
vielleicht gibt es da draußen noch ein paar einsame Kämpfer mit den 
selben Problemen...

Hier das (vorläufige) Ergebnis:

1

Steuerzeichen:

2

--------------

3

STX = Start Text, 0x02 Hex

4

ETX = End of Text, 0x03 Hex

5

CR = Carriage Return, 0x0d Hex

6

SUB = Substitute, 0x1a Hex

7

DC2 = Device Control 2, 0x12 Hex

8

ACK = Acknowledge, 0x06 Hex

9

NACK = No Acknowledge, 0x15 Hex

10

SYN = Synchronous idle, 0x16 Hex

11

12

Befehlsaufbau:

13

--------------

14

<STX><Befehl><CR><ETX><Checksumme?><SUB>

15

z.B. "\x02T1 2 81 10 00\r\x03AD37\xa1" (in Bash Notation)

16

17

Abgehörte Befehle:

18

------------------

19

G0 0000 Terminalprog.__ 128 0 1.04 A 0.0.0 2 KPT001 (Checksumme: D240)

20

G0 0000 Ich_bin_ein_LRP 81 10 3.63 0 21 LRP001 (Checksumme: BFD3)

21

 - Hiermit scheint sich der LPR oder das Terminal vorzustellen

22

 - Geeignete Antwort der Gegenstelle scheint ein SYN, ACK zu sein

23

24

T0 * (CS: 2A4E)

25

 - Anwort: SYN, DC2, SYN, ACK

26

27

T1 2 81 10 00 (CS: AD37)

28

 - 2 dürfte hier die Kontrolleradresse sein

29

 - Antwort: SYN, ACK

30

31

Z6 0 T0 * (CS: 0E60)

32

 - Antwort: SYN, ACK

33

34

G8 2 (CS: 16C5)

35

 - Antwort: SYN, ACK

36

37

Z2 0 G8 2 (CS: 9FDE)

38

 - Antwort: SYN, ACK

39

40

Z2 64 G0 0000 Terminalprog.__ 128 0 1.04 A 0.0.0 2 KPT001 (CS: A8F3)

41

 - Antwort: SYN, ACK

42

43

p0 2 * (CS: 62F5)

44

 - Antwort: SYN, ACK

45

 - Darauf folgt eine Parameterliste:

46

 p1 2 5100 28.0 108 08 00 XS Raumtemp. (CS: 25E9)

47

 p1 2 5120 10.0 109 08 00 XPY1 (CS: 5c9e)

48

 ...

49

 usw.

50

 - Jede Zeile muss mit einem SYN, ACK bestätigt werden, dann folgt die nächste.

Ich konnte die Ausgabe der Parameterliste mit ein paar von Hand 
zusammengefrickelten Befehlen anstoßen. Um die Parameter gezielt 
auslesen zu können müßte man evtl. so was wie Expect verwenden.

Hallo StreetPiet,
habe aktuell das gleiche Issue - allerdings mit einer DDC3200.

Das mit der Prüfsumme ist korrekt erkannt.

Die Prüfsumme wird nach CRC-CCITT (XModem) berechnet.

Bsp.

<STX>p0 2 *<CR><ETX>
02 70 30 20 32 20 2A 0D 03

ergibt die Prüfsumme 62F5

und somit folgende Anfrage:
<STX>p0 2 *<CR><ETX>0x62 0xF5 <SUB>
02 70 30 20 32 20 2A 0D 03 62 F5 1A

Zum Testen der Prüfsumme eignet sich z.B. 
http://www.lammertbies.nl/comm/info/crc-calculation.html

Wieder etwas weiter - Danke.

Grüße
Ralph

An alle Mitleser,

1) Diese Beispiel war falsch:
<STX>p0 2 *<CR><ETX> 0x62 0xF5 <SUB>
02 70 30 20 32 20 2A 0D 03 62 F5 1A

Richtig ist:
<STX>p0 2 *<CR><ETX>62F5<SUB>
02 70 30 20 32 20 2A 0D 03 36 32 46 35 1A

Die berechnete Prüfsumme im Beispiel ist [62][F5]
und muss als ASCII-String [62F5] eingesetzt werden!

2) Hier ein beispielhafte Kommunikation mit einer DDC3200
12.03.2014 09:35:33.098 [TX] - <STX>G0 0000 Terminalprog.__ 128 0 1.04 A 
0.0.0 2 KPT001<CR><ETX>D270<SUB>
12.03.2014 09:35:33.165 [RX] - <SYN><ACK><STX>G1 0000 000000000000000 32 
96 6.300 A 1 2 DDC001<CR><ETX>E4C1<SUB>
12.03.2014 09:35:35.555 [TX] - <SYN><ACK>
12.03.2014 09:35:40.432 [TX] - <STX>p0 1.0.0 *<CR><ETX>E2DA<SUB>
12.03.2014 09:35:40.456 [RX] - <SYN><ACK><STX>p1 1.0.0 899/1 6.300 0 0F 
00 <CR>
12.03.2014 09:35:44.942 [TX] - <SYN><ACK>
12.03.2014 09:35:45.005 [RX] - <STX>p1 1.0.0 2039/1 573 13 0F 00 
<CR><ETX>632D<SUB>
12.03.2014 09:35:46.935 [TX] - <SYN><ACK>
12.03.2014 09:35:46.956 [RX] - <STX>p1 1.0.0 i919/1 1 0F 00 
<CR><ETX>45BF<SUB>

>Terminalprogramm meldet sich an.
>DDC acknowledged + zeigt sich
>Terminal acknowledged
>Terminal schiebt den Befehl p0 1.0.0 *
>DDC acknowledged und gibt die 1. Antwort
>Terminal acknowledged
>DDC acknowledged und gibt die 2. Antwort
.....


Viel Spass

Ralph

Hallo Ralph,

danke für den Tipp mit der Checksummenerzeugung!

Inzwischen kann ich mit Python korrekte Befehle an den LRP4 senden und 
mittels der pycrc16-Library ( http://code.google.com/p/pycrc16/ ) auch 
korrekte Checksummen erzeugen.

Anscheinend ist es dem LRP4 egal ob er die Checksumme in Groß- oder 
Kleinbuchstaben geliefert bekommt, jedoch müssen es zwingend vier 
Zeichen sein (also auch führende Null, z.B. "0AE6")

Es scheint auch einige Unterschiede bei der Befehlsschreibweise zu 
geben. So habe ich den "p0" Befehl schon in verschiedenen Variationen 
gesehen:

p0 1.0.0 * (in Deinem Beispiel)
p0 2 *  (Bei meinem LRP4. 2 ist hier warscheinlich die 
Controlleradresse...)
p0 2 *.*

Ich werde mal Deine Schreibweise testen.

Gruß,
Peter

Hallo Peter,
hallo Mitleser,

Die Datenpunktadresse setzt sich wie folgt zusammen:

<GLT-AdressTEIL>:<Geräte-AdressTEIL>
(Anmerk. beide Teile werden durch einen DOPPELPUNKT ":" getrennt, der 
auch anzugeben ist)

Der <GLT-AdressTEIL> besteht aus
[<Netzwerk>.<Knoten>.]<Zentrale>
(Anmerk: [] ist optional und der PUNKT "." ist mit aufzuführen)

Für das P90-Protokoll reicht der <Geräte-AdressTEIL> aus und besteht aus
<Bus>.<Gerät> <ParameterNr>
(Anmerk: PUNKT "." und LEERZEICHEN " " sind anzugeben)

Der Bus und Gerät kann bei der DDC3200 am Display abgelesen werden, wenn 
man zum Beispiel einen DP abruft:
001.000 --> Bus 1 und Gerät 0
Deshalb sollten bei mir funktionieren
(a) "p0 1.0.0 *"
(b) "p0 1:1.0.0 *"
(c) "p0 1:1.0 *"

In o.a. P90-Doku steht zumindest, das die Unterstationsnummer BBB für 
eine DDC3000 nicht definiert ist. Vielleicht funktioniert deshalb ev. 
auch (b), weil es schlichweg ignoriert wird.


Weitere Beispiele wären aus der "GLT-Tools"-Doku (ggf. mal danach 
googlen:
1.1.5:2.1 7901/1 oder 5:2.1 7901 oder 5 2 1 7901

Grüße

Ralph