CompactLogix ReadTag/WriteTag access (protocol level)

Hi,

does someone know if up-to-date 'CompactLogix' controllers support ReadTag/WriteTag services via unconnected, explicit messaging (SendRRData encapsulation) as indicated in the "Logix 5000 Data Access Programming Manual"?
I'm having trouble receiving a service status code of 0x4 (wrong EPATH) in response to my requests, although any addressed tag is visible and settable within the 'RSLogix5000' configuration software.

Thanks

Sounds like the PATH specification (communications route) is incorrect...

The current revision of RSLogix 5000 software (v19) does allow some tags to be protected from being read from outside the controller. You can easily test to see if that's the issue by creating a dummy tag in the Controller Scope database, but I think that's unlikely.

Be sure that the tags your are reading are either Controller Scope or are identified by the correct Program database name !

CompactLogix routing is identical to ControlLogix routing with the CPU in Slot 0 of the backplane; after the IP address of the Ethernet interface, the path is "1, 0" for Port 1, Slot 0.

What software are you using to read the tags ?

Thanks for your replies!
I'm using a home-brewn protocol adapter for simple explicit messaging. Set/GetAttributeSingle works perfectly but tag-acces so far not.

Where exactly does the port/slot part of addressing come into play?
The data-access programming manual doesn't mention it at all in the context of ReadTag/WriteTag.
All tags I wanted to test are at top-level controller scope and not protected.
By the way, the 'RSLogix500' software itself doesn't use tag-addressing but accesses the data through (vendor-specific) CIP-objects.

CIP path specifications always come in pairs.....

Port,Destination,Port,Destination,Port,Destination &c. Any part of this can be a named entity in your driver or comms package.

But talking to the Ethernet port on your Compactlogix doesn't get you to the controller itself, the path needs to be extended to say "Go Onto the CompactLogix Bus, then go to Slot 0"

Like ControlLogix, where the BackPlane is Port 1, in CompactLogix, the CompactBus is port 1 from the Ethernet bridge.

In ControlLogix, the Destination can be any slot number, 0 to 16, but in CompactLogix, the "slot number" for the controller is always slot 0.

Hence, as Ken rightly says, the last part of your CIP path specification needs to read ",1,0"

This seems to be a valuable hint, so do I have to

- either encapsulate ReadTag/WriteTag services into an 'unconnected send' (0x52) connection-manager request
- or simply append 01 00 (port, slot) to the (0x91) tag-name path-segment?

You're on the right track. For an ordinary unconnected message you use the Connection Manager to process an Unconnected Send (0x52) of a Read Data Table service (0x4C).

Attached is a Wireshark capture that might be of assistance as an example. It captures two messages sent from an RSEmulate 5000 instance (v18) to a 1756-L61 controller (v17) through a 1756-ENBT module.

The first message in the capture (frame 7) is a Get Attribute Single directed to the 1756-ENBT itself (to read Class 0x01, Instance 0x01, Attribute 0x03, the Product Code). It's a nice short request because it's directed to a very simple object in the Ethernet module itself.

The second message in the capture (frame 12) is a Read Data Table request to read a tag called "Readable Tag".

You'll see that the Route Path is at the very end of the request; the target controller is in Slot 0, so the Route path is "01 00".

If you want to compare your message to a functioning one, post a Wireshark *.PCAP file (you will need to ZIP it first) and describe what you're trying to do with the message.

Thanks a lot! This is a very insightful piece of information.
I will be able to test this approach next week.
Does the device always respond directly to the routed (innermost) service request if successful and to the 'unconnected send' service only if routing fails?

What is still interesting is
- whether routing via 'unconnected send' and port/slot semantics is just Rockwell-specific or also necessary especially for assembly object accesses in devices of other vendors,
- whether there might be surprises concerning the timeout fields,
- what to pay, at least, for a commercial source code stack of this minimal functionality with proper error handling?