Logix Read Ethernet device name

[Ibuprophen]

ControlLogix L8. Has anyone tried or had luck reading the device name of an ethernet module in the I/O tree? I don't know if its possible however I see you can get the model, firmware revision with an GSV so thought maybe or perhaps through a message instruction.
Thanks

 

[tlf30]

When you say device name, do you mean the hostname of the ethernet modules, the product name, or the name of the module in the IO tree?

 

[Ibuprophen]

Name of the module in the IO tree.
I dont' think a message instruction would work at least to the module, this doesn't exist in the module...
I think this is essentially reading another tags name and I'm guessing that is not possible

 

[tlf30]

Hmm, I would have to do some digging.
You probably are going to be required to message the controller using class 0x69, which is an undocumented class that contains IO tree information. I'll have to dig, but there is a 'Module ID' attribute and if I recall correctly it is a string. I'll do some tests and see if it contains the module name.

You will need to know the module instance ID in advance, which you can get via a GSV. If you cannot use a GSV to discover the module instance ID, then there are messages that you can use to brute force find it.

Are you going to be sending these messages from the controller that contains the module in the IO tree? This matters since the messages to the 0x69 class will be different depending on if you can use the GSV to get the instance id, or if you do not have access to put a GSV in the logic and need to query the controller itself, or if you are querying from an external device such as another controller or from software on a computer.

 

[Operaghost]

The name you give to a module is your controller's name for that module. It is unique to your controller only. The module itself does not have a name. So your PLC and my PLC could be talking to the same module, but each have different names for that same module.

OG

 

[Ibuprophen]

GSVs are available, using them now to get the IP address of each module
Modules directly accessible from the PLC

 

[JeremyM]

Hmm, I would have to do some digging.
You probably are going to be required to message the controller using class 0x69, which is an undocumented class that contains IO tree information. I'll have to dig, but there is a 'Module ID' attribute and if I recall correctly it is a string. I'll do some tests and see if it contains the module name.

You will need to know the module instance ID in advance, which you can get via a GSV. If you cannot use a GSV to discover the module instance ID, then there are messages that you can use to brute force find it.

Are you going to be sending these messages from the controller that contains the module in the IO tree? This matters since the messages to the 0x69 class will be different depending on if you can use the GSV to get the instance id, or if you do not have access to put a GSV in the logic and need to query the controller itself, or if you are querying from an external device such as another controller or from software on a computer.

IO (0x69) + Symbol (0x6B) classes.

OP can GSV for 'MODULE' Instance and use it to correlate to a certain Symbol attribute via iterative messaging and string work to remove the 'Map:' prefix from the symbol found or import this program into a 5380/5580 project and the work is done for all IO instances in the system.

 

[Ibuprophen]

Thank you I will check it out

 

[Ibuprophen]

I have tested with your library code and it works perfectly. Trying to understand more now and the question I have now is how or can you correlate the instance values between what a GSV returns vs the instance number the message requires to reach the same device.
For example GSV(Module, xx_module, Instance, xx_val ) = 60900, the instance used by the message instruction = 9.

 

[JeremyM]

Each IOMap (Module) instance contains a "MapAddress" attribute that correlates with an "Address" attribute of the related Symbol instance.

Strictly speaking, GSV/Msg to Module doesn't reach the device. It's just a connection configuration and state.

The path returned by a Module instance is used by other services to solicit info from a device (Identity in the library AOI).

So the overall process goes...
a) get all Module instances
b) get some attributes from each Module instance
c) get all Symbol instances referencing a particular type (IOMap)
d) associate Symbol instance attribute Address to Module instance MapAddress
e) get this Symbol instance name and store in the Node instance
f) parse the Identity of any connected Module instances to get the actual hardware info
g) repeat to accomodate IO additions/deletions

 

[Ibuprophen]

I was just editing my post. It finally clicked when I went through your logic again. 16#69 and 16#6b and correlating between them. You are using '.MapAddress' as that correlation value.

Now to get it to work with what we currently use...

Thanks again JeremyM!