Discrepancy in Data Frame Length from PLC-2 Unprotected Read Command

[Barbue]

Hello everyone,

I'm working with an old ACM3710 device and I'm encountering an issue with the data frames I'm sending over an RS232 connection over my 1785-KE module. I'm using an oscilloscope to monitor the data frames and I've noticed a discrepancy with the expected data.

According to the device's protocol documentation (Protocol: 3710 ACM / Allen-Bradley), when I send the "Read 3710 ACM Long Real-Time Data" command, the 1785-KE should send a 14-byte data frame. However, I'm consistently receiving a 22-byte data frame instead. The extra 8 bytes are puzzling and not accounted for in the documentation.

Here's an example of a data frame I've received:
10 02 9C 00 00 01 00 00 00 00 00 00 01 00 C1 00 9C 04 B4 10 03 4D.

Here is what the documentation is saying for the packed issued to the ACM 3710:
This packet is issued to a model 3710 ACM Power Meter to retrieve a
detailed account of the real-time data measured by the 3710 ACM
meter.
Byte 1 = 10H = Data Link Escape (DLE) control byte.
Byte 2 = 02H = Start of Text (STX) delimiter byte.
Byte 3 = (DST) - destination address byte of message packet.
Byte 4 = (SRC) - source address byte of message packet.
Byte 5 = 01H - "Unprotected Read" command byte (CMD) issued by
the Allen-Bradley PLC.
Byte 6 = (STS) - byte to indicate message transmission status.
Byte 7 = (TNS) - low order byte of transaction identifier used by
the Allen-Bradley communication interface.
Byte 8 = (TNS) - high order byte of transaction identifier used by
the Allen-Bradley communication interface.
Byte 9 = XXH - low order message type address byte (ADDR), used to
address destination 3710 ACM (unit id).
Byte 10 = 04H - high order message type address byte (ADDR), used
to request 3710 data.
Byte 11 = B4H = size byte (SIZE) indicating the number of fixed
bytes to be read.
Byte 12 = 10H = Data Link Escape (DLE) control byte.
Byte 13 = 03H = End of Text (ETX) delimiter byte.
Byte 14 = BCC ERROR CHECK

In addition to this, I've noticed something peculiar when I use the PLC-2 Unprotected Read command. The documentation suggests a certain size in bytes for the data frame, but the actual size I observe seems to differ.

I'm seeking advice on the following:

1. 
   Any insights into why I might be receiving 22 bytes instead of 14 for the "Read 3710 ACM Long Real-Time Data" command?

• Any thoughts on why the data frame size from the PLC-2 Unprotected Read command might differ from the expected size as per the documentation?

Any help or guidance would be greatly appreciated. Thank you !

 

[Ken Roach]

Wow, that's some moderately old gear. And isn't it amazing that modern oscilloscopes can give you a serial data stream out of the bit pulses !?

Is this a new installation or modification of old equipment ? Did it work correctly in the past and has stopped doing so, or are you adding features or modifying the installation ?

If you're doing serial comms analysis, a fantastic value for your money is the EZ-Tap from Stratus Engineering. It also works with Frontline Test Equipment's serial analyzers, but I've used their quick serial capture and Docklight serial analyzer to do this sort of work as well.

I haven't used a 3710 ACM, but Google tells me it's an old Power Measurement Ltd. power meter, and delivers a user manual titled "AB_Integer_Ranging_3710.pdf". I presume you're sending commands from an A-B controller over DH+ through the 1785-KE module, which is a DF1/RS232 to DH+ bridge.

What model of A-B controller is sending the command ? Can you describe the details of the MSG instruction configuration ?

The description of the command you posted comes right from that manual on page, and shows a 14-byte request frame from the 1785-KE. That is consistent with the 1770-6.5.16 DF1 Command Reference manual, page 7-31.

The "Unprotected Read" is a 9-byte command, plus 2 bytes at the start and 2 bytes at the stop of the frame, plus a 1-byte BCC error check = 14 bytes.

 

[Ken Roach]

10 02 9C 00 00 01 00 00 00 00 00 00 01 00 C1 00 9C 04 B4 10 03 4D

Does the 3710 ACM reply to this command ?

The [10 02] at the start and the [10 03] at the end make sense as the DLE STX and DLE ETX. There are no DLE DLE's in the frame to discard.

BCC in the A-B world is the 2's complement of the 8-bit sum of the bytes that aren't DLE-escaped, so 0x4D is correct for the checksum byte.

The first thing that jumps out is the STN Station address. 9C hex = 156 decimal = 234 octal is outside the range of DH+ addresses (00-77 octal) but is addressable in DF1 (0-254 decimal). Maybe "two three four" was just a default convention for PML.

There's also apparently an extra 00 before the CMD byte 0x01. I'm not sure what to make of that.

 

[Ken Roach]

Can you capture several of these messages in a row ?

The TNS "transaction sequence word" should increment every time the 1785-KE sends a command to another station using DF1 protocol. If the "C1 00" is actually the TNSW that would make sense, because it comes before the Address and Size bytes.

It seems as though there are a bunch of null bytes getting inserted into the frame. That's one thing that BCC error checking can't detect.

Interesting challenge !

 

[Ken Roach]

Let me clarify: the TNSW does not increment on an automatic "retry" that is configured in a single MSG instruction.

But it does increment every time a new message is sent (typically a re-trigger of the MSG instruction block) to the same destination device, or a message sent to a different destination device. The TNSW in the Response will always be equal to the TNSW in the Request.

If you have a stream of DF1 protocol data, looking for the values that increment by 1 can be a handy way of figuring out where the TNSW is in the frame.

 

[Barbue]

Hello, and thank you for taking the time to delve into this complex issue with me. Your expertise and detailed analysis are incredibly valuable as I work to understand and resolve this challenge with the old ACM3710 device. Here are my responses to your insightful questions:

First Message Response:
Thank you for your insights! Yes, the ability of the oscilloscope to decode the pulses is quite fascinating. This is indeed old equipment that the company wants to utilize, and I've been tasked with making it work as part of my final internship as an engineering student in electromechanics at university.

You're correct in your understanding of the setup. I'm sending MSG instructions through a PLC5/40 DH+ port to the 1785-KE. I've attached the information of the MSG command as per the "AB_Integer_Ranging_3710.pdf" manual (see picture below). I'll also take a look at the 1770-6.5.16 DF1 Command Reference Manual as you suggested.

Second Message Response:
Interestingly, the 3710 ACM doesn't reply to the command. I was able to potentially decipher some of the frame and correspond them to the manual. Regarding the dip switch settings on the 1785-KE, they are set for full duplex, BCC, no parity, and no embedded message. What's intriguing is that a month ago, when I tried communicating directly with the RS-232 port of my PLC 5/40, the data frame was 14 bytes long. So, it seems like the 1785-KE might be adding those extra null bytes. Any thoughts on why this might be happening?

Fourth Message Response:
Your idea about the TNSW incrementing is intriguing! I'll try adding timers and comparing them to make the MSG trigger multiple times to see if there's an increment in the TNSW bytes. I'll keep you posted on the results.

Thank you again for your detailed analysis and suggestions. Your expertise is greatly appreciated, and I'm looking forward to resolving this interesting challenge!