[Etherlab-users] strange behaviour with sdo configuration

Graeme Foot Graeme.Foot at touchcut.com
Mon Oct 18 23:30:07 CEST 2021


Hi Vincent,

Using ecrt_slave_config_sdo8() is fine for a boolean value.  The log you sent was trying to set a value of 0x90, but for a Boolean it would need to be either 0x00 or 0x01.  The error could have been due to trying to set an out of range value (though it should have been a different error code).

The only reference on google I can find for 0x08000021 (except for error number listings) is https://github.com/OpenEtherCATsociety/SOEM/issues/311, but that doesn't look relevant.  This is related to how the PDO configuration is set up.

Being a new module it may be a firmware bug.  It's probably time to talk to the Beckhoff office that supplied the module for support.

Let us know if you find anything further, I may want to use the module in the future.

Regards,
Graeme


From: BUSSIERES Vincent <vincent.bussieres at hemeria-group.com>
Sent: Monday, 18 October 2021 21:01
To: Graeme Foot <Graeme.Foot at touchcut.com>; etherlab-users at etherlab.org
Subject: RE: strange behaviour with sdo configuration


Hi Graeme,



Thanks for your reply. I noticed that "Enable C reset" is a boolean, but I use "ecrt_slave_config_sdo8" function to set its value. I don't find another function to write only in a boolean.



It seems that there is a problem with EL5102 because at the first start, I can read its state (PREOP) with ethercat tool. I try to download sdo using download command and I get the same error message. I do the same with 8001:1b (uint32) and get the same error.


hemeriadm at CT:/opt/etherlab/bin$ ./ethercat slaves
0  0:0  PREOP  +  EK1100 EtherCAT-Koppler (2A E-Bus)
1  0:1  PREOP  +  EL5102 2K. Inc. Encoder 5V (RS422,TTL)
2  0:2  PREOP  +  EL5101-0010 1K. Inc. Encoder 5V (20 Mio. Inkremente/s)
3  0:3  PREOP  +  0x0000009a:0x00030924
4  0:4  PREOP  +  0x0000009a:0x00030924

./ethercat download -a0 -p1 -tint32 0x8001 0x1b 0
SDO transfer aborted with code 0x08000021: Data cannot be transferred or stored to the application because of local control

[ 1161.448299] EtherCAT DEBUG 0: ecrt_master_sdo_download(master = 0x00000000820ec9de, slave_position = 1, index = 0x8000, subindex = 0x01, data = 0x00000000ce5642c8, data_size = 1, abort_code = 0x000000009602e91e)
[ 1161.448303] EtherCAT DEBUG 0-main-1: Scheduling SDO download request.
[ 1161.455021] EtherCAT DEBUG 0-main-1: Processing SDO request...
[ 1161.455027] EtherCAT DEBUG 0-main-1: Downloading SDO 0x8000:01.
[ 1161.455029] EtherCAT DEBUG: 01
[ 1161.455033] EtherCAT DEBUG 0-main-1: Expedited download request:
[ 1161.455034] EtherCAT DEBUG: 00 20 2F 00 80 01 01 00 00 00
[ 1161.479016] EtherCAT DEBUG 0-main-1: Download response:
[ 1161.479018] EtherCAT DEBUG: 00 20 80 00 80 01 21 00 00 08
[ 1161.479029] EtherCAT ERROR 0-main-1: SDO download 0x8000:01 (1 bytes) aborted.
[ 1161.479038] EtherCAT ERROR 0-main-1: SDO abort message 0x08000021: "Data cannot be transferred or stored to the application because of local control".
[ 1161.479042] EtherCAT ERROR 0-main-1: Failed to process SDO request.
Regards








________________________________
De : Graeme Foot <Graeme.Foot at touchcut.com<mailto:Graeme.Foot at touchcut.com>>
Envoyé : dimanche 17 octobre 2021 21:34
À : BUSSIERES Vincent; etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Objet : RE: strange behaviour with sdo configuration


Hi Vincent,



Looking at the EL5102 documentation 0x8000:01 is "Enable C reset" and is Boolean.  It looks like are trying to set a value of 0x90.  It should be set to a value of either 0x00 to disable (default) or 0x01 to enable.



Regards,

Graeme.



From: BUSSIERES Vincent <vincent.bussieres at hemeria-group.com<mailto:vincent.bussieres at hemeria-group.com>>
Sent: Friday, 15 October 2021 20:02
To: Graeme Foot <Graeme.Foot at touchcut.com<mailto:Graeme.Foot at touchcut.com>>; etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Subject: RE: strange behaviour with sdo configuration



Dear All,



When I configure sdos I get the following error:



SDO abort message 0x08000021: "Data cannot be transferred or stored to the application because of local control".



Could you tell what is local control and why I get this error when I configure sdo only?



Regards



......

[ 1484.880041] EtherCAT 0:   Datagram domain0-0-main: Logical offset 0x00000000, 44 byte, type LRW at 000000001bb3a22b.
[ 1484.880041] EtherCAT DEBUG 0: Stopping master thread.
[ 1484.880045] EtherCAT DEBUG 0: Master IDLE thread exiting...
[ 1484.880048] EtherCAT 0: Master thread exited.
[ 1484.880049] EtherCAT DEBUG 0: FSM datagram is 00000000f8a4fd2a.
[ 1484.880050] EtherCAT 0: Starting EtherCAT-OP thread.
[ 1484.880165] EtherCAT DEBUG 0: mmap()
[ 1484.880166] EtherCAT DEBUG 0: Operation thread running with fsm interval = 4000 us, max data size=45000
[ 1484.880167] EtherCAT WARNING 0: 1 datagram UNMATCHED!
[ 1484.880168] EtherCAT DEBUG 0: Vma fault, virtual_address = 00000000ab9367f9, offset = 0, page = 00000000d5c21541
[ 1484.887120] EtherCAT DEBUG 0-main-1: Processing internal SDO request...
[ 1484.887121] EtherCAT DEBUG 0-main-1: Downloading SDO 0x8000:01.
[ 1484.887122] EtherCAT DEBUG: 90
[ 1484.887123] EtherCAT DEBUG 0-main-1: Expedited download request:
[ 1484.887123] EtherCAT DEBUG: 00 20 2F 00 80 01 90 00 00 00
[ 1484.895117] EtherCAT DEBUG 0: Configuration changed (aborting state check).
[ 1484.895119] EtherCAT DEBUG 0-main-0: Checking system time offset.
[ 1484.911104] EtherCAT WARNING 0: No app_time received up to now, abort DC time offset calculation.
[ 1484.911105] EtherCAT DEBUG 0: Requesting OP...
[ 1484.947171] EtherCAT DEBUG 0-main-1: Download response:
[ 1484.947172] EtherCAT DEBUG: 00 20 80 00 80 01 21 00 00 08

[ 1484.947174] EtherCAT ERROR 0-main-1: SDO download 0x8000:01 (1 bytes) aborted.
[ 1484.947176] EtherCAT ERROR 0-main-1: SDO abort message 0x08000021: "Data cannot be transferred or stored to the application because of local control".
[ 1484.947177] EtherCAT ERROR 0-main-1: Failed to process SDO request.





________________________________

De : Graeme Foot <Graeme.Foot at touchcut.com<mailto:Graeme.Foot at touchcut.com>>
Envoyé : vendredi 15 octobre 2021 01:45
À : BUSSIERES Vincent; etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Objet : RE: strange behaviour with sdo configuration



Hi Vincent,



1) I think 4339:05 relates to CoE object 0x10F3:05.  Set the value to 0.



Try setting it manually via the ethercat command line before starting your app to start with.  If that helps, set it via your app before going active.





2) Some slave modules support diagnostic messages.  These are on the slave itself, under the 0x10F3 CoE index.  The EtherLab master doesn't have a framework to automatically read them and It's a reasonably big topic to get your head around.  Here's a starting point:

https://infosys.beckhoff.com/english.php?content=../content/1033/el34x3/1859331211.html&id=210180382886825810



Note: a lot of diagnostic ID's are module specific.  They can be found in the modules esi file (Beckhoff EL5xxx.xml) under the <DiagMessages> node.  There's only around 11 for this module, but the page above lists common diag messages.





3) I have found that for Beckhoff modules that only support fixed PDO entries, if you get the PDO configuration wrong (e.g. your cstruct was generated for an older revision of the module) you will get errors the first time you apply the config (listed in dmesg).  The modules PDO settings are however updated with the new, but incorrect information.  Internally the module will ignore these mistakes and use its fixed PDO config.  Note: this is why you should only use the cstruct command after a clean boot of a slave.



If you restart your app, without repowering the slave, then no errors will be reported this second time because the PDO configuration you are applying now matches what the slave is reporting, even though it's wrong.



I have found some modules do not get to OP when they have these PDO config errors, though usually I find they get to SAFEOP + Error.



I'm just speculating that this particular module may have an issue with applying an incorrect PDO configuration in combination with applying SDO configuration.





4) As a new thought, what SDO configuration calls are you making?  This module supports CoE complete access.  If you are setting multiple subindex entries under one index, try setting it as a complete access call instead.





Note: we also use the EL5101.  For this and most other modules we also call the reset command as our first SDO config item to ensure there are no unexpected configuration options set, e.g.:

ecrt_slave_config_sdo32(dev->slaveConfig, 0x1011, 0x01, 0x64616F6C);



Graeme.





From: BUSSIERES Vincent <vincent.bussieres at hemeria-group.com<mailto:vincent.bussieres at hemeria-group.com>>
Sent: Friday, 15 October 2021 12:00
To: Graeme Foot <Graeme.Foot at touchcut.com<mailto:Graeme.Foot at touchcut.com>>; etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Subject: RE: strange behaviour with sdo configuration



Thank you Graeme for these thoughts.

I used a similar module (EL5101), I hadn't this problem but pdo assignment was different. I used cstruct command to get pdo informations.



1) With which value should I set the value in index 4339:5 ?



2) How can I see diagnostic messages ? with dmesg?



3) Is it possible to encounter PDO error only during sdo configuration? I don't understand why at the second start there is no PDO error ?



Regards



________________________________

De : Graeme Foot <Graeme.Foot at touchcut.com<mailto:Graeme.Foot at touchcut.com>>
Envoyé : jeudi 14 octobre 2021 23:36
À : BUSSIERES Vincent; etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Objet : RE: strange behaviour with sdo configuration



Hi Vincent,



I don't have a module to play with so no real idea.  But here's some thoughts:



1) The Beckhoff esi file "Beckhoff EL5xxx.xml" file shows setting the value in index 4339:5 to 0000 on transition from Init to PreOp:

            <InitCmd>

              <Transition>IP</Transition>

              <Index>4339</Index>

              <SubIndex>5</SubIndex>

              <Data AdaptAutomatically="1">0000</Data>

            </InitCmd>



You could try setting this value before activating your master.  I think 4339 is decimal so relates to 0x10F3:05.



0x10F3:05 is the Diagnostics Flags value.  This is 0x0001 by default which reports the presence of a DiagMessage as an emergency.





2) The module supports diagnostics.  Check the Diagnostic messages for issues during the startup with and without the SDO configs.





3) On first application start from a cold boot, without any of the SDO config calls, check the dmesg log for any errors with assigning the PDO's for the module.  It may be that if PDO errors are encountered along with the SDO config calls the module stays in PREOP + Error.  But without the SDO config calls it may get to OP OK.



On the second start the PDO's will already have been changed so the master / slave won't report any errors (even though the module will ignore the changes internally as they are fixed PDO's).  Due to no PDO errors being reported the second time it may be why the SDO config calls succeed.





Regards,

Graeme.





From: Etherlab-users <etherlab-users-bounces at etherlab.org<mailto:etherlab-users-bounces at etherlab.org>> On Behalf Of BUSSIERES Vincent
Sent: Friday, 15 October 2021 09:11
To: etherlab-users at etherlab.org<mailto:etherlab-users at etherlab.org>
Subject: [Etherlab-users] strange behaviour with sdo configuration



Dear Etherlab users,



I bought a Beckhoff EtherCAT Terminal, 2-channel encoder interface EL5102. This product has just been released.

I encounter problems when I configure sdos with « ecrt_slave_config_sdo8 » or « ecrt_slave_config_create_sdo_request » functions called before « ecrt_master_activate » as for my other slaves.

This slave doesn't switch at the OP State and stay in PRE-OP State with error « E » :



"1 0:1 PREOP E EK5102 2K. Inc. Encoder 5V (RS422, TTL)"



I noticed that when I comment sdo configuration methods and run my application, slave switches to OP State.

After being switched one time to OP, if I uncomment configuration methods and run once again my application, slave behaviour seems to be OK, slave switches to OP State.



I don't understand why after the fisrt boot, there is such a problem ?



Could you help solving this problem ?



Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.etherlab.org/pipermail/etherlab-users/attachments/20211018/94c44738/attachment-0001.htm>


More information about the Etherlab-users mailing list