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