[Etherlab-users] strange behaviour with sdo configuration

[Graeme Foot]

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>
Sent: Friday, 15 October 2021 12:00
To: Graeme Foot <Graeme.Foot at touchcut.com>; 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/20211014/8e1efeff/attachment.htm>