Crawling Logix I/O Trees?

JeremyM

Lifetime Supporting Member
Join Date
May 2014
Location
Dallas, Texas
Posts
1,233
Hi all,

I've come up with a reasonable enough way to parse the identities of the local modules on a 5380 CompactLogix.

Is there a way to do this for children in the I/O tree of either of the EtherNet ports? Could there be a handy CIP object on the processor that indicates the number of nodes present and their paths?

Thanks!

Tree.PNG
 
I'm hitting a wall on this one.

I know module instance numbers can be retrieved by GSV, but can they be used in a reverse lookup fashion against a CIP class for instances of it?
 
I'm not entirely sure what you're trying to do, but here's two things that come to mind that might help you figure it out:

In RSLinx, RSWho, you can drill down through the backplane and back out another Ethernet module. Expand as far as it goes, right-click and configure. Normally you would only enable whatever you want to interact with, but to look for anything, add all addresses to the expected list. Wireshark if you want to see the traffic.

Check out the Stratix AOI & faceplate for Factorytalk View. It's been a while, but I think that AOI does some of what it sounds like you might want.

Edit: There's also an EIP AOI and faceplate that might include functions you want. Probably better than the Stratix one.
 
Last edited:
Not sure if this is what you want, but Rockwell has a service called the system ferret tool(Free but erased from AB's downloads), or more recently the AssetInventory addon in Assetcentre. They can crawl your CIP network and create a list.
 
What I'm *attempting* to achieve is making an onboard discovery tool that runs on a Logix processor and populates some pre-allocated arrays with "objects" that enumerate the resources attached to the system, locally or remotely (the total I/O tree).

For example, kickstarting a DEVICEWHO message with the "THIS" or "Local" keywords in the path and incrementing that path by 1 and re-sending upon completion results in an array being populated with the identities of each local module present.

What I'm scouring for is either a) such a 'keyword' for the base address of each of any network tree with offsets being instance numbers of the child nodes or b) some CIP object on the system that tracks the modules and parent/child relationships outright.

***

I just found a copy of Ferret and it reports the devices locally but stops short of probing what the A1 and A2 interfaces "own" on my 5380 CompactLogix.
 
Last edited:
What I'm *attempting* to achieve is making an onboard discovery tool that runs on a Logix processor and populates some pre-allocated arrays with "objects" that enumerate the resources attached to the system, locally or remotely (the total I/O tree).

For example, kickstarting a DEVICEWHO message with the "THIS" or "Local" keywords in the path and incrementing that path by 1 and re-sending upon completion results in an array being populated with the identities of each local module present.

What I'm scouring for is either a) such a 'keyword' for the base address of each of any network tree with offsets being instance numbers of the child nodes or b) some CIP object on the system that tracks the modules and parent/child relationships outright.

***

I just found a copy of Ferret and it reports the devices locally but stops short of probing what the A1 and A2 interfaces "own" on my 5380 CompactLogix.

I remember being able to set up a depth in system ferret, or am I imagining stuff from AssetCentre only?
 
Why onboard the processor? This seems better served outside of the PLC.

It’s self-contained and would provide the necessary tag access for outside polling without the need to know anything else about the device its hardware. Otherwise, the same problem remains for external polling: figuring out just how to enumerate the resources in the first place.
 
Getting warmer!

Would anyone be willing to shed some light on which CIP objects implement what I'm seeing in the screenshot? It would solve my problem 100% knowing where and how to look for this programmatically.

I suspect they are derived directly, or by some combination of, instances and attributes found within these objects:
  • Connection Object 0x05
  • Connection Manager 0x06
  • Originator Connection List Class 0x45
  • Connection Configuration Object 0xF3
  • Port Object 0xF4

Connections.PNG
 
Fully deciphered the available Port Object instance attributes on a CompactLogix and finished a working AOI that probes the CPU by default, but can also be pointed at communication cards in an I/O rack.

In a clean UDT instance there's the Port Type, Number, Link Object Path* (this one's really curious), Port Name, and Node Address (CIP path).

*The Link Object Path makes available the relationship between EtherNet/IP-enabled CIP ports and their corresponding TCP/IP Interface objects (0xF5), so some of the next steps would be to a) construct a generic 'Node' type (some minimal subset of Port Object and TCPIP Object attributes) that acts as the root of b) a constructed tree hierarchy with slots that can be populated with 'child' TCPIP Objects.

On a similar path, a Local Hardware (backplane) tree/bus can be established that maintains relationships between a) the CPU and its owned hardware and b) EtherNet/IP cards, their ports, and finally the tree of children they own.
 
I'm impressed, but still somewhat confused as to why...

Now that you have an array of tags with some info about devices your PLC can communicate with, how are you using that information? I'm assuming, given the amount of effort that you've put in, that there's a better reason than "to see if it could be done" or "because it looks really cool"?

Just curious.
 
One goal is that the front-end effort here will reduce the manual labor required for individual GSV/module statuses and the effort to produce diagnostics across varying types of control devices. I can auto-populate a generalized "EtherNet" tree (realized as simple contiguous arrays) per node (5069 or 1756-EN2T EtherNet port, or otherwise) and dynamically list the modules attached to the system on an HMI. If you add another 525 for example, the array and its member count increases by one, an HMI visibility control shows a new item, and so on.

No need to recompile the HMI or remember to attach status AOIs to new node modules.

Another perk is that one can use the EPATH provided at the port level + module IP to dynamically probe the list of modules for their Identity, TCPIPInterface, and EtherNetLink objects.

One annoyance I run into all the time is figuring out (and remembering!) that Rockwell picks and chooses which CIP services are implemented for like objects on different devices. For example, TCPIPInterface (0xF5) responds to Get_Attribute_All on a CompactLogix, but only responds to Get_Attribute_Single on a PowerFlex 525. With that in mind, I can simply have a pair of global messages (GetAttrAll & GetAttrSingle) crawl my list of modules continuously without a concern in the world for what device implements what service. If one message fails, no big deal, just move on and let the other have a try. Then you have Moxa, who seems to hate Get_Attribute_All; no problem, just give GetAttrSingle the path!
 
Last edited:
In my continuing journey down this rabbit hole, the Symbol Class (0x6B) might be useful.

I found one of my VFD objects described across a few contiguous instances of the class. Each instance embeds among other unknown attributes the name of the object as found in the I/O tree and controller tags. It seemingly enumerates the distinction between standard and safety tag here as well:

  • 7: "Map:E2_VFD1005"
  • 8: "E2_VFD1005:I"
  • 9: "Cxn:Standard:db00a0b2"
  • 10: "E2_VFD1005:O"
  • 11: "E2_VFD1005:C"

The "db00a0b2" reads like an instance ID, but it doesn't match up with the returned Module Instance of a GSV.

Instance 1 and 3 have embedded symbols "Map:Local" and "__CONTAINER", respectively. Not sure what those represent, but that's probably okay.
 
Last edited:
Anything prefixed with "Map:" is interesting - they're the keywords you can use for setting up a message path more quickly by hand.
 
Ah, OK. So you could add a new VSD to your machine, and it would show up with the relevant icon and diagnostic information on you HMI, without any edits to the HMI. That's neat!
 

Similar Topics

I have been doing logic programming and troubleshooting for about 25 years. I started working for a new company as PLC Application Engineer and I...
Replies
5
Views
116
We are trying to poll data coming from a PLC for remote monitoring we have the IP address of the PLC and the default port number and the path is...
Replies
25
Views
414
I am currently backing a Micro Logix 1100 and no-one seems to have the file for me to upload from. Is there a way for me to upload the project off...
Replies
15
Views
348
Hi everyone i have a customer, who wants to show an alarm on the machine, if the I/O forces are enabled and set, on at ControlLogix L81E with...
Replies
3
Views
138
Does anyone know how to set the background colors of instuction blocks (TON, MOV, etc)?
Replies
1
Views
86
Back
Top Bottom