on bits DIR and PRI in datalink control byte
66 views
Skip to first unread message
Daniel Bastos
Aug 29, 2017, 4:14:24 PM8/29/17
to automatak-dnp3
During a general interrogation between a master and a recloser slave
(see full log at the end of this message), I see master always uses byte
C4 as control byte, while slave always uses 44 as control byte. This
means that master always sets DIR = 1 and PRM = 1, while slave always
sets DIR = 0 and PRM = 1.
From ``Practical Modern SCADA Protocols'', page 88:
--8<---------------cut here---------------start------------->8---
Direction bit. The DIR bit indicates the message direction between
master and non-master stations. If a message is from a designated
master station, this bit is set. Otherwise it is cleared.
Primary bit. The PRM bit is set if the frame is primary (initiating) or
a secondary (responding). This is used directly in interpreting the
function code. There are six valid function codes for primary frames,
and five valid function codes for secondary frames.
--8<---------------cut here---------------end--------------->8---
From this, I expected two things.
(1) To see PRM = 0 when a slave responds to a request made by a
master. I don't see this happening ever.
(2) To see a function code of 3 (not 4) when slave requests an ACK as
receipt. I don't this happening. Slave asks for confirmation by
setting CON = 1 at the application layer, keeping control byte = 44 in
the datalink layer.
Conclusions. I think my devices (master and slaves) don't use much the
datalink layer. Their conversation takes place only at the application
level.
Is this the usual thing? Thank you!
(*) Full log
master: disable unsolicited class 1, 2, 3
05 64 11 c4 04 00 03 00 4e ef
c0 c1 15 3c 02 06 3c 03 06 3c 04 06 94 43
slave: here's my iin
05 64 0a 44 03 00 04 00 7c ae
c1 c1 81 90 00 75 cd
master: turn off device_restart
05 64 0e c4 04 00 03 00 6d d3
c1 c2 02 50 01 00 07 07 00 c9 bb
slave: here's my iin (device_restart off, need_time on)
05 64 0a 44 03 00 04 00 7c ae
c2 c2 81 10 00 11 b9
master: set your time
05 64 12 c4 04 00 03 00 1e 7c
c2 c3 02 32 01 07 01 11 22 33 44 55 66 02 f7
slave: here's my iin (all cleared)
05 64 0a 44 03 00 04 00 7c ae
c3 c3 81 00 00 d7 87
master begins general interrogation: read all classes 1, 2, 3, 0
objeto 60, variação 2, qualifier 0x06 (all points)
objeto 60, variação 3, qualifier 0x06 (all points)
objeto 60, variação 4, qualifier 0x06 (all points)
objeto 60, variação 1, qualifier 0x06 (all points)
05 64 14 c4 04 00 03 00 c7 17
c3 c4 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 62 18
slave: here's all my data, please confirm receiving
objeto 32 (analog change event), variação 1, qualifier 0x17 (8 bit indexed)
objeto 1 (binary input), variação 1, qualifier 0x00 (8 bit start stop)
objeto 10 (binary output), variação 2, qualifier 0x00 (8 bit start stop)
objeto 20 (binary counter), variação 5, qualifier 0x00 (8 bit start stop)
objeto 21 (frozen counter), variação 9, qualifier 0x00 (8 bit start stop)
objeto 30 (analog input), variação 3, qualifier 0x00 (8 bit start stop)
05 64 7c 44 03 00 04 00 9b e2
c4 e4 81 00 00 20 01 17 07 00 01 c9 00 00 00 01 83 19
01 c6 00 00 00 02 01 c7 00 00 00 03 01 fd ff ff 61 d3
ff 04 01 27 1c 00 00 05 01 33 1c 00 00 06 01 2e d8 30
1c 00 00 01 01 00 00 05 00 0a 02 00 00 05 01 01 32 08
01 01 01 01 14 05 00 00 00 00 00 00 00 15 09 00 5f 25
00 00 00 00 00 00 1e 03 00 00 06 c9 00 00 00 c6 fd 8a
00 00 00 c7 00 00 00 fd ff ff ff 27 1c 00 00 33 e8 ef
1c 00 00 2e 1c 00 00 6b f2
master: here's my receipt
05 64 08 c4 04 00 03 00 b4 b8
c4 c4 00 19 c7
slave: unsolicited: here's my iin (all clear), please confirm receiving
05 64 0a 44 03 00 04 00 7c ae
c5 f1 82 00 00 b2 0b
master: here's my receipt
05 64 08 c4 04 00 03 00 b4 b8
c5 d1 00 0d 9d
(see full log at the end of this message), I see master always uses byte
C4 as control byte, while slave always uses 44 as control byte. This
means that master always sets DIR = 1 and PRM = 1, while slave always
sets DIR = 0 and PRM = 1.
From ``Practical Modern SCADA Protocols'', page 88:
--8<---------------cut here---------------start------------->8---
Direction bit. The DIR bit indicates the message direction between
master and non-master stations. If a message is from a designated
master station, this bit is set. Otherwise it is cleared.
Primary bit. The PRM bit is set if the frame is primary (initiating) or
a secondary (responding). This is used directly in interpreting the
function code. There are six valid function codes for primary frames,
and five valid function codes for secondary frames.
--8<---------------cut here---------------end--------------->8---
From this, I expected two things.
(1) To see PRM = 0 when a slave responds to a request made by a
master. I don't see this happening ever.
(2) To see a function code of 3 (not 4) when slave requests an ACK as
receipt. I don't this happening. Slave asks for confirmation by
setting CON = 1 at the application layer, keeping control byte = 44 in
the datalink layer.
Conclusions. I think my devices (master and slaves) don't use much the
datalink layer. Their conversation takes place only at the application
level.
Is this the usual thing? Thank you!
(*) Full log
master: disable unsolicited class 1, 2, 3
05 64 11 c4 04 00 03 00 4e ef
c0 c1 15 3c 02 06 3c 03 06 3c 04 06 94 43
slave: here's my iin
05 64 0a 44 03 00 04 00 7c ae
c1 c1 81 90 00 75 cd
master: turn off device_restart
05 64 0e c4 04 00 03 00 6d d3
c1 c2 02 50 01 00 07 07 00 c9 bb
slave: here's my iin (device_restart off, need_time on)
05 64 0a 44 03 00 04 00 7c ae
c2 c2 81 10 00 11 b9
master: set your time
05 64 12 c4 04 00 03 00 1e 7c
c2 c3 02 32 01 07 01 11 22 33 44 55 66 02 f7
slave: here's my iin (all cleared)
05 64 0a 44 03 00 04 00 7c ae
c3 c3 81 00 00 d7 87
master begins general interrogation: read all classes 1, 2, 3, 0
objeto 60, variação 2, qualifier 0x06 (all points)
objeto 60, variação 3, qualifier 0x06 (all points)
objeto 60, variação 4, qualifier 0x06 (all points)
objeto 60, variação 1, qualifier 0x06 (all points)
05 64 14 c4 04 00 03 00 c7 17
c3 c4 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 62 18
slave: here's all my data, please confirm receiving
objeto 32 (analog change event), variação 1, qualifier 0x17 (8 bit indexed)
objeto 1 (binary input), variação 1, qualifier 0x00 (8 bit start stop)
objeto 10 (binary output), variação 2, qualifier 0x00 (8 bit start stop)
objeto 20 (binary counter), variação 5, qualifier 0x00 (8 bit start stop)
objeto 21 (frozen counter), variação 9, qualifier 0x00 (8 bit start stop)
objeto 30 (analog input), variação 3, qualifier 0x00 (8 bit start stop)
05 64 7c 44 03 00 04 00 9b e2
c4 e4 81 00 00 20 01 17 07 00 01 c9 00 00 00 01 83 19
01 c6 00 00 00 02 01 c7 00 00 00 03 01 fd ff ff 61 d3
ff 04 01 27 1c 00 00 05 01 33 1c 00 00 06 01 2e d8 30
1c 00 00 01 01 00 00 05 00 0a 02 00 00 05 01 01 32 08
01 01 01 01 14 05 00 00 00 00 00 00 00 15 09 00 5f 25
00 00 00 00 00 00 1e 03 00 00 06 c9 00 00 00 c6 fd 8a
00 00 00 c7 00 00 00 fd ff ff ff 27 1c 00 00 33 e8 ef
1c 00 00 2e 1c 00 00 6b f2
master: here's my receipt
05 64 08 c4 04 00 03 00 b4 b8
c4 c4 00 19 c7
slave: unsolicited: here's my iin (all clear), please confirm receiving
05 64 0a 44 03 00 04 00 7c ae
c5 f1 82 00 00 b2 0b
master: here's my receipt
05 64 08 c4 04 00 03 00 b4 b8
c5 d1 00 0d 9d
Adam Crain
Aug 29, 2017, 4:23:48 PM8/29/17
to automatak-dnp3
Hi Daniel,
There is no correlation between confirmation at the application layer, and the use of the data-link functions.
If data-link confirms are enabled, every frame transmitted will use CONFIRMED_USER_DATA and expect an ACK, regardless of what application layer payload it carries.
Data-link confirms are a poor feature of the standard. Confirms only have a 1-bit sequence # (e.g. a single flag), so it's better to decrease the size of transmitted application layer responses for error-prone links.
You're only seeing PRI frames, because when link-layer confirms are disabled, on the UNCONFIRMED_USER_DATA link function code is used.
Opendnp3 can support enabling link-layer confirms for interop with systems that require them:
-Adam
Daniel Bastos
Aug 29, 2017, 4:31:32 PM8/29/17
to Adam Crain, automatak-dnp3
Hi, Adam! I really appreciate your expertise and kindness in this
mail list. Thanks so much for the explanation.
On Tue, Aug 29, 2017 at 5:23 PM, Adam Crain <jadam...@automatak.com> wrote:
> Hi Daniel,
>
> There is no correlation between confirmation at the application layer, and
> the use of the data-link functions.
>
> If data-link confirms are enabled, every frame transmitted will use
> CONFIRMED_USER_DATA and expect an ACK, regardless of what application layer
> payload it carries.
>
> Data-link confirms are a poor feature of the standard. Confirms only have a
> 1-bit sequence # (e.g. a single flag), so it's better to decrease the size
> of transmitted application layer responses for error-prone links.
>
> You're only seeing PRI frames, because when link-layer confirms are
> disabled, [...] the UNCONFIRMED_USER_DATA link function code is used.
mail list. Thanks so much for the explanation.
On Tue, Aug 29, 2017 at 5:23 PM, Adam Crain <jadam...@automatak.com> wrote:
> Hi Daniel,
>
> There is no correlation between confirmation at the application layer, and
> the use of the data-link functions.
>
> If data-link confirms are enabled, every frame transmitted will use
> CONFIRMED_USER_DATA and expect an ACK, regardless of what application layer
> payload it carries.
>
> Data-link confirms are a poor feature of the standard. Confirms only have a
> 1-bit sequence # (e.g. a single flag), so it's better to decrease the size
> of transmitted application layer responses for error-prone links.
>
> You're only seeing PRI frames, because when link-layer confirms are
Reply all
Reply to author
Forward
0 new messages