[Etherlab-users] User mode "Register" access methods

Richard Hacker ha at igh.de
Fri May 22 10:57:37 CEST 2026


Unfortunately this feature is not implemented in our master. And
neither do you have access to this ID-Request bit in AL Control (0x120)
using direct register access because the master assumes exclusive
control over this register and will either negate your effoerts or be
confused by it.

You have 2 options:
* implement this feature yourself and send us a pull request
* request this feature from us ;)

- Richard

On Thu, 2026-04-30 at 14:50 +0000, Moebius, Volker wrote:
> > 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.
> 
> .

-- 
Mit freundlichem Gruß / Best regards,
Richard Hacker
--  
-----------------------------------------------------------------------
Richard Hacker, M.Sc.
Entwicklungsingenieur / Development Engineer
ha at igh.de

Tel.: +49 201 / 36014-16

Ingenieurgemeinschaft IgH Gesellschaft für Ingenieurleistungen mbH
Nordsternstraße 66
D-45329 Essen

https://igh.de | https://etherlab.org

Amtsgericht Essen HRB 11500 | USt-Id.-Nr.: DE 174 626 722
Geschäftsführung:
Frederik Becker, Dr.-Ing. Siegfried Rotthäuser, Jost Braukmann
-----------------------------------------------------------------------


More information about the Etherlab-users mailing list