[etherlab-dev] Explicit Device ID

[Matthieu Bec]

All,

I have an application that requires uniquely identifying all our slaves (~180 that are essentially one same model) in the fieldbus.
Using "configured station alias" seems it could work, since it means updating all the SII individually.
Those are custom built slave built around micro-processor and we have a way to expose unique id (from a location eeprom dongle)
I was looking at "Explicit Device Identification" from ETG1020 protocol enhancement.

Has anyone experience with that? I don't see it being currently supported in etherlab master.

Thank you,
Matthieu

[Gavin Lambert]

Post by Matthieu Bec
I have an application that requires uniquely identifying all our slaves

(~180

Post by Matthieu Bec
that are essentially one same model) in the fieldbus.
Using "configured station alias" seems it could work, since it means

updating

Post by Matthieu Bec
all the SII individually.
Those are custom built slave built around micro-processor and we have a

way

Post by Matthieu Bec
to expose unique id (from a location eeprom dongle) I was looking at

"Explicit

Post by Matthieu Bec
Device Identification" from ETG1020 protocol enhancement.
Has anyone experience with that? I don't see it being currently supported

in

Post by Matthieu Bec
etherlab master.

The method I use is to program the EEPROM with a unique serial/alias address
during production, so in the field they're preprogrammed with an appropriate
station alias.

The alias can alternatively be set during commissioning using the "ethercat
alias" command, or other means.

These are probably the simplest thing that just works.


The explicit device id method is mostly intended for things like hardware
dipswitches. There's a procedure outlined in ETG1020 to let the slave
configure the alias on its own on bootup (the short version is to use the
value in the SII EEPROM if nonzero, then the id selector if nonzero, or
signal an error if both are nonzero). This process is invisible to the
master and again would just work, given a slave that supports it.

ETG1020 also specifies a command the master can send to request the slave
provide a hardware address as a one-off request. This is not directly
supported by the Etherlab master (although you can use register requests to
do it yourself in the application or a commissioning tool). This is
independent of the station alias but that also makes it less useful --
especially in a network where devices could be connected in alternate orders
(which is usually the reason why you want individual addressing) you should
be using the alias addresses to define your slave_configs, so that things
will Just WorkT when the network is reconfigured.

[Matthieu Bec]

I didn't properly explain it earlier:
in my use case the devices are all the same and serviceable. We'd like to avoid reprogramming IDs if a device fails and gets swapped by another, so we intend to use an ID from an EEPROM dongle (that will be permanently mounted) rather than SII (that will change with the new device).
Basically, what you describe in your last paragraph poking the AL Ctrl/Status Code Registers. Can you explain why this is less useful than station alias?
It looks like one way around it would be to write the dongle ID to the alias register when the micro starts up?

Thank you,

ps: sorry dev-list I should have sent this to etherlab-users

Post by Matthieu Bec
I have an application that requires uniquely identifying all our slaves

(~180

Post by Matthieu Bec
that are essentially one same model) in the fieldbus.
Using "configured station alias" seems it could work, since it means

updating

Post by Matthieu Bec
all the SII individually.
Those are custom built slave built around micro-processor and we have a

way

Post by Matthieu Bec
to expose unique id (from a location eeprom dongle) I was looking at

"Explicit

Post by Matthieu Bec
Device Identification" from ETG1020 protocol enhancement.
Has anyone experience with that? I don't see it being currently supported

in

Post by Matthieu Bec
etherlab master.

The method I use is to program the EEPROM with a unique serial/alias address
during production, so in the field they're preprogrammed with an appropriate
station alias.

The alias can alternatively be set during commissioning using the "ethercat
alias" command, or other means.

These are probably the simplest thing that just works.


The explicit device id method is mostly intended for things like hardware
dipswitches. There's a procedure outlined in ETG1020 to let the slave
configure the alias on its own on bootup (the short version is to use the
value in the SII EEPROM if nonzero, then the id selector if nonzero, or
signal an error if both are nonzero). This process is invisible to the
master and again would just work, given a slave that supports it.

ETG1020 also specifies a command the master can send to request the slave
provide a hardware address as a one-off request. This is not directly
supported by the Etherlab master (although you can use register requests to
do it yourself in the application or a commissioning tool). This is
independent of the station alias but that also makes it less useful --
especially in a network where devices could be connected in alternate orders
(which is usually the reason why you want individual addressing) you should
be using the alias addresses to define your slave_configs, so that things
will Just WorkT when the network is reconfigured.

[Gavin Lambert]

Post by Matthieu Bec
in my use case the devices are all the same and serviceable. We'd like to
avoid reprogramming IDs if a device fails and gets swapped by another, so
we intend to use an ID from an EEPROM dongle (that will be permanently
mounted) rather than SII (that will change with the new device).

The replacement-of-identical-devices case is what the default positional addressing is designed for -- you take a device away and put a replacement device at the same relative position in the network so that it assumes the same duties. As long as your network is mostly designed as a chain and you only remove and replace devices when the master application is not running (or the master application can detect that devices are in an abnormal state and waits for the network to be corrected before resuming operation), this goes a long way.

Explicit device addressing is more for the case where you have a tree-structure network where people might plug things in with a different order, or with groups of devices that can appear or disappear at different times.


What I do is to hold the ESC in reset on boot briefly so that I can access the SII EEPROM before the ESC can (I have it wired as dual-master for exactly this reason); during this time it checks the stored station alias against the external ID and if it's zero or otherwise unprogrammed then it replaces it with the external id. (It can also recover from blank or outdated SII contents, making one less thing to reprogram for a firmware update.)

In your case you could do something similar, but always overwrite the station alias with the external ID. Or allow the ESC to boot and update the alias register in memory only -- I don't really recommend that approach though as it produces a race condition with being visible on the EtherCAT network. You could possibly also write it back to the SII (if the master has been configured with --enable-sii-assign) so that it will already be correct on next boot.

(If you do update the SII EEPROM, then don't forget that the alias participates in the checksum, so you have to recalculate that too.)

Post by Matthieu Bec
Basically, what you describe in your last paragraph poking the AL Ctrl/Status
Code Registers. Can you explain why this is less useful than station alias?

Mostly just the lack of present support in the master itself. With station aliases, you can use alias-based addressing (such that all your ecrt_slave_configs are addressed as (alias, 0)), which means that the master application can remain at realtime and the library will automatically recognise network changes and reconfigure the slaves correctly even if they get reordered. If you set up your domains correctly or otherwise adapt to devices going missing, you can keep talking to the other devices this way.

(Station aliases can also optionally be used directly as station ids in the low-level EtherCAT datagrams, but I don't think Etherlab makes use of this.)

With explicit ids, you can poke the registers to discover the "real" locations of devices but if you discover that something has changed you'll have to bring the whole master out of realtime and generate new configurations based on their current positions before you can resume operation.

Unless you want to try adding support for it to the master.

The basic functionality is simple enough (just looking up a different value and pretending it was the alias), but the complication is knowing whether a slave supports it or not. ETG1020 specifies some SII XML parameters (IdentificationAdo and IdentificationReg134) to specify this, but AFAIK they are not encoded in the SII EEPROM, which is all that Etherlab has access to.