[Etherlab-users] User mode "Register" access methods
Moebius, Volker
Volker.Moebius at baader.com
Thu Apr 30 16:50:44 CEST 2026
> 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.
.
More information about the Etherlab-users
mailing list