On 29 November 2017 12:33, quoth 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.) > 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. _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
