Uniquely Identifying Devices/Nodes

todd_mm · April 7, 2021, 4:03pm

Device Identifier(s)

Is there a reliable strategy for uniquely identifying devices on the network? I’d like to be able to survive a superficial change in network topology (e.g. changing node order).

A “solution” here would probably be something that would work for “a lot” of devices, but perhaps not all, though if there were a way to guarantee that I could uniquely identify any given device, that would be wonderful.

Model & Serial Number

It has been my experience that device support for whatever underlies RapidCodeNetworkNode::SerialNumberGet() is spotty at best, and I have never noticed that any device I’ve worked with returns anything but 0 for this request.

Is there a Good Way™ to get a serial number? Is it totally dependent on whether the device (manufacturer) makes it available via some object that I can query?

Station Alias

This is a very “soft” identifier that would at least work for a specific set of physical devices. It does require the installer to configure it correctly and cannot be managed at all in the software. Also, some devices don’t support this and always return 0.

MAC Address

Is it possible to get the MAC address of a node? This sounds like data that is kind of none-of-my-business as an EtherCAT consumer, but I only want it as identifying information.
Is there a way that I could get it via RapidCode? What if I were willing to cheat and look at raw firmware addresses?

Other Ideas?

I don’t require a specific implementation, but I do need to be able to identify a physical device on the network regardless of where it is in the topology. I’m open to whatever other clever ideas you may have.

The DSP 402 standard lists a number of objects (e.g. 0x6400-0x64FF) that, perhaps, could be used to identify devices. Are any of these reliably supported (in your experience) among manufacturers?

jp · April 7, 2021, 5:40pm

Device Identifier(s)

If I understand your question correctly, you could use:

RapidCodeNetworkNode.TypeGet() to check if the node type is still the same.
RapidCodeNetworkNode.VendorIdGet() to check if node is still the same vendor identifier.
RapidCodeNetworkNode.SerialNumberGet() to check unique identifier of the node.

You can also use the tooltip feature in the Node page in RapidSetup to see some of the function calls we use to get node information (make sure tooltips are enabled under Menu > View):

Model & Serial Number

The serial number gets read from the node’s EEPROM and its accessible after node discovery via RapidCodeNetwork.SerialNumberGet()

You might be able to access node-specific data using SDO read to index 0x6510, which according to the DSP402 manual refers to Drive data. Take a look at your specific node’s 0x6510 index and see what is available.

From DSP402 manual:

MAC Address

MAC Addresses aren’t available.

Other Ideas?

I think (0x6400-0x64FF) refers to manufacturer-specific data, but not node-specific.

I’ll forward this to other engineers and see if they have any other ideas.

I also found this on a conversation between you and one of our engineers back in 2017, and here is a snippet of what he suggested back then:

Serial Number get is the best method to uniquely identify a drive form all other instances rather than all over types (UserBuffer). Most customers validate a network using NetworkNodeCountGet and RSINodeType NetworkNode->TypeGet() or use drive specific identifies such as Kollmorgen AKD’s Rotary Switches. If you had multiple nodes of the same type that were wired/configured differently you could get into trouble. Of course even with a physical rotary switch they might set that incorrectly too. I understand that you want to cover for predictable mistakes of others. Trying to find the right process which will ensure behavior can be complex when you consider just how good people can be at messing things up (smiles).

Hope this helps!

todd_mm · April 7, 2021, 5:47pm

I have yet to see a device we use that reports a non-zero serial number: Yaskawa, Delta, CTB.
I’m not saying it’s not available anywhere, but my experience is that it’s not available anywhere that I’m likely to need it. (-8

jp · April 7, 2021, 6:37pm

Okay I will talk to other engineers to see if anyone has any idea on why we can’t read the serial number, and/or see if we can investigate the issue.

Best!

jp · April 8, 2021, 4:24pm

So after further discussing with other engineers we concluded that any given useful information an EtherCAT Slave Vendor decides to populate is ultimately based on their implementation. We don’t have control over it. Some may allow a Read/Writable location where you could create your own identifiers. Many nodes will have switches which allow you to number their nodes. Where you can pull up that info will be drive specific.

The Identify Object exists for each of the 3 nodes you mentioned. This is a good place to get some information but not help you with your problem.

As a strategy for ensuring things/nodes are out of order, we can assume you have a static master ENI file for each build. If the node types are out of order, you will not get operational. If nodes which have been configured for different purposes are out of order, then you’ll need to use things like switches (1s for TypeA, 2s for TypeB, Ns for TypeN) or manage a database of Serial Number to Role relations which seems undesirable. If you have blocks of IO, you can get different versions of the base module which have an ID switch to help ensure the blocks aren’t reversed.

If non of this is helpful, then would you mind describing to us what are the problem cases that you are having in more detail and maybe tell us why changing the node order is a desirable mechanism.

Hope this helps!

todd_mm · April 8, 2021, 4:40pm

Use Case

Our application allows configuration of the EtherCAT slaves that exists outside of RMP/device that have to be applied every time we (re)create RMP objects, like axes. If the only means I have for identifying a device on the network is its node number, then my app won’t know which device to apply those settings to if the network topology changes. My application needs to be able to recognize that a device has “moved” in the network node order, and I currently do not have any good way to identify a device that works on all/most of the devices we have.

I don’t expect to have things frequently rewired, but it is common enough to need to add an I/O slice to a block of slices, which would change the node numbers for everything after it on the network. Often, by the time that happens, the system is at least halfway configured, and changing the node numbers would mean that we lose some/all of the configuration for any devices whose node number changed. Because of wiring constraints, we do not always have the option of putting drives “aways at the front” or other things. Our solutions have to be adaptable to the needs of the environment (as well as minimizing cost of cables, etc.).

Vendors

It is my experience that each vendor does what it wants and implements whichever part(s) of the standard they desire, and so I am not surprised that 0x1018/4 is always zero for the particular devices that I’m using. (e.g. Yaskawa Sigma-V docs say that the serial number is not implemented—and I have experimental evidence to support that claim!)

Unused Parameters

I could, perhaps, find some unused drive parameters that are stored in non-volatile memory and cleverly use those (if I can find them for a device) to write my own identifiers. Am I likely to find such parameters? (This is entirely an opinion-based question.)

Options?

The device info block seems like The Right Way™ to solve this problem, but in my case, the vendors have chosen not to make that available to me.

I’m hunting for creative ways that I could uniquely identify a device on the network that is likely to work for all or nearly all devices.

The MAC address (if it were obtainable) would be one way to be certain of device identity, because all the slaves on the same segment must have a unique MAC address. IDK if it’s possible for you guys to know the MAC address, since EtherCAT is more of a ring topology and not a bus/star. You are the only ones that could answer that question.

Can you think of other ways that a device could be uniquely identified?

jp · April 12, 2021, 4:40pm

IO

Another engineer has recommended that for your IO you could use the EK1101 (EtherCAT Coupler with ID switch) rather than the EK1100 (EtherCAT Coupler) IO node.

But this does not resolve your issue of:

“I’m hunting for creative ways that I could uniquely identify a device on the network that is likely to work for all or nearly all devices.”

Nodes

Another option is to look at other nodes which feature unique IDs as a part of their advantage.

Unused Parameters

You could indeed try to find a drive parameter that is stored in non-volatile memory. I would look at your drive manual or speak to the support team from your drive manufacturer.

MAC Address

We are discussing if reading the MAC address would be a possibility. I’ll have to get back to you on this one.