[Etherlab-users] strange behaviour with sdo configuration

Sun Oct 17 21:34:26 CEST 2021

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>
Sent: Friday, 15 October 2021 20:02
To: Graeme Foot <Graeme.Foot at touchcut.com>; 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/20211017/365a48ba/attachment-0001.htm>