DNP 3.0 protocol

B

Thread Starter

Bob Lockert

I am awaiting delivery of the documentaion for this protocol but need some interim info/direction to keep a project on schedule.

In my test environment, I have a PC based master polling a slave RTU for the status of one binary point (BIN0) through a direct connect serial cable. The master application and the slave RTU are supplied from different vendors. Both are prepared to remedy any deficiencies in their products. At this point I cannot determine which vendor (in any) is at fault.

The master application never receives a valid response to its polls, yet the RTU responds with Xmit data. I've logged the data at the PC side and can see poll/reply pairs that have an incrementing sequence number. I suspect the PC
application, but without the official documentation, cannot prove it.

Would anyone care to comment on the following sequence?

TX: 05 64 0F C4 05 00 02 00 2C 0F C1 C1 01 01 01 01 00 00 00 00 CE
RX: 05 64 0A 44 02 00 05 00 DA C7 C0 C1 81 90 02 CF 82

TX: 05 64 0F C4 05 00 02 00 2C 0F C2 C2 01 01 01 01 00 00 00 00 2B
RX: 05 64 0A 44 02 00 05 00 DA C7 C0 C2 81 90 02 8E 88

TX: 05 64 0F C4 05 00 02 00 2C 0F C3 C3 01 01 01 01 00 00 00 00 88
RX: 05 64 0A 44 02 00 05 00 DA C7 C0 C3 81 90 02 66 4A

Note: The logging program identifies the TX string length as 22, but only the 21 bytes shown are logged. I'm assuming that the poll is parity/checksum correct in that the RTU replies. When the addressing is incorrect, it does not.

Thanks in advance for any insight.

Regards,

Bob Lockert
Blocke Communications
Calgary, Canada

 
Top