> Uff, you are using a pooly documented feature where AL Control bit 6 > (0x120.5) is used to request an id from the slave, with the slave responding > in AL > Status bit 6 (0x130.5) and putting some value in AL Status Code (0x134). This > is > very crooked in my opinion.
I asked the developers of our slave device about the implementation of the slave ID. It's according to the document "ETG. 1020 Protocol Enhancements", Section 21.4.1. "Requesting ID - Complex SubDevice with application microcontroller and ID-Selector", where the procedure of querying the SubDevice ID by the AL Control register 0x0120 is defined. (Unfortunately, I haven't been aware of this document so far. I'm not familiar with the EtherCAT protocol.) > This feature is currently not supported by our master, although it is not > impossible > to implement such an `id_request` feature. > > The reason: AL Control (0x120) is entirely under master control. You cannot > meddle with this register from behind the scenes to manipulate bit 6. Hence > your > observation that it function is "time critical". You had to be fast so the > master > does not screw your work ;) When is the master using this AL Control register? - I assume that an implementation of an `id_request` feature would require to synchronize the necessary register accesses (0x120, 0x130, 0x134) with those executed by the master for other reasons, wouldn't it? Could you give me a hint in which source code module the AL Control register is possibly managed? Is there a mechanism to "lock" the accesses to the AL Control register by the public API of the EC master? > The standard way of implementing this "ID" feature would be either to set this > value in 0x012 (Configured station alias) or better, put it in a PDO -- then > it > supports on-the-fly DIP switch changes, which, in fact, it really is. You > could also > implement it with a read-only SDO, but SDO's are typically master to slave > communication channel, used to configure a slave once-off before entering OP. I think that changing the slave device is unfortunately no option, especially because there are already devices installed in the field. . -- Etherlab-users mailing list [email protected] https://lists.etherlab.org/mailman/listinfo/etherlab-users
