Reading from SLC5/04 DH+ using EQ7000 bridge

I have a need to read data from an existing SLC5/04 connected to a DH+ network using a Mitsubishi RJ71EIP91 E/IP module.

I have an Equustek EQ7000 which in principle will bridge E/IP to DH+ but I cannot figure out the UCMM message format from the Mitsubishi to make it work. Done this previously with SLC5/05 directly via E/IP so optimistic there's a solution.

I can get comms with KepwareEX and the SLC via the EQ7000 so the config is all good (EQ= node 2, SLC = node 1 on DH+). Wireshark captures on this are no help

Also using Molex EIP tool for easier debug in place of the Mitsubishi.

Having read all the apps guides from Equustek, I figure I need to use service 0x4C (CIP with SourceID), class 0x67, Inst 0x1.

I try this and get some kind of response from the EQ7000 but I have no idea what it is, assuming it's an exception code. It is not relayed from the SLC, as disconnecting the DH+ gives the same result.

Trying to read N7:0 to :9 (10 integers) at dst node 1 (SLC) from src node 2 (EQ) using "protected logical read with 3 address fields" CMD=0F / FNC = A2

TX = 4C 02 20 67 24 01 09 00 00 01 00 00 00 02 00 0F 00 01 00 A2 14 07 89 00 00

where
4C 02 - service
20 67 - class
24 01 - inst
09 - length
00 00 - dest link
01 00 - dest node
00 00 - source link
02 00 - source node
0F - FNC
00 - STS
01 00 - TNS
A2 - FNC
14 - bytes (20 dec)
07 - file no
89 - type (integer)
00 - element
00 - sub element

RX = CC 00 00 00 00 00 00 02 09 00 00 01 40 02 00 01


Any help or guidance to help me determine the correct frame settings appreciated

This is an interesting challenge !

EquusTek infringed on RA's patents for years, and even after the dispute was mooted by expiration, they have stubbornly refused to join ODVA or do conformance testing. The reputation and behavior of the company's principals locks them out of cooperation with any Rockwell experts for documentation and testing.

But you've got what you've got, and that's not my dispute anymore.

Are you sure that Service 0x4C, CIP_Read, is the correct one for an SLC-500 data table ? I think that 0x4C and 0x4D are for reading ControlLogix tags.

Have you tried using Service 0x4B, Execute PCCC Service ?

There's an old but useful document that addresses CIP and PCCC that applies to the PLC-5E and SLC-5/05, which is hard to find except on 3rd party sites:

Communicating with RA Products Using EtherNet/IP Explicit Messaging (Rev 1.2)

Why don't you think that the Wireshark captures from your KEPWare configuration are useful ? If you can zip and post some, I would be interested in looking at them.

Thanks Ken for your reply.

I have used Service 0x4B / Class 0x67 (PCCC) previously to get the Mitsubishi reading/writing to SLC5/05 via its ethernet port directly, and tried it with the 5/04 but got an error from the Equustek.

I figured the message routing wasn't happening by the EQ7000, and the message wasn't being relayed to the DH+ interface.

I found this page http://www.iatips.com/pccc_tips.html and tried to apply the advice on using 0x4C instead. (scroll down to "Question? How can I send the DST byte with PCCC in Ethernet/IP?")

It seems feasible as one of the EQ7000 apps guides shows using "CIP with Source ID" as it exposes DST/SRC fields



Ref the Kepware, it seems to make a connection to the SLC5/04 using implicit data class 0xA6

Solved!!

I was adding the 09 for length unnecessarily, adding an unexpected extra byte!

Source node assumption also not wrong, but 00 or 02 works fine.

(I had assumed length byte was needed, as I needed to include length byte with SLC5/05 using 0x4B PCCC)

So the CORRECT frame to read 20 words from N7:0 using UCMM is

TX = 4C 02 20 67 24 01 00 00 01 00 00 00 00 00 0F 00 01 00 A2 14 07 89 00 00

where
4C 02 - service
20 67 - class
24 01 - inst
00 00 - dest link
01 00 - dest node
00 00 - source link
00 00 - source node
0F - FNC
00 - STS
01 00 - TNS
A2 - CMD
14 - bytes (20 dec)
07 - file no
89 - type (integer)
00 - element
00 - sub element