[etherlab-users] EL6751 SDO-Configuration

Matze Thias matze.thiasm at gmail.com
Wed Jan 20 13:13:07 CET 2016


Thank you for your response, Gavin. I'm pretty sure that the device
supports complete access. It is stated in the documentation, that either I
can use complete access or "consistency nesting" for configuration
purposes. I derived the object layout directly from the Twincat SDO-Startup
tab for that particular device.
Essentially I'm doing this right now:

* Extract the SDO-Startup information from TwinCAT. Specifically for the
EL6751 one has to upload 0xF800 first and then 0x800 with appropriate
values. According to the online documentation, EL6751 should then start the
CAN-Controller (Which it does not :D). I extracted the following
information:

    - Complete Access on 0xF800 (with 0-Index):
       11 00 7F 02 80 00 A0 86 01 00 00 00 00 00 00 1E 64 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
       00 00 00 00 00 00 00 00 00 00 00 00 00 00
    - Complete Access on 0x8000 (with 0-Index)
       2E 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
       00 00 01 00 64 00 03 00 00 00 D0 07 05 00 0A 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
       00 00 00 00 00 00 00 00 00 00 00 00
    - For 1C12 and 1C13 there are also startup SDOs. I use the values
provided there to configure pdo-mapping via
      ecrt_slave_config_pdos. TwinCAT provides:

              01 00 00 16                             for 1C12. Therefore
one entry, selecting mapping object 0x1600
              03 00 82 1A 83 1A 84 1A        for 1C13. Therefore three
entries, selecting mapping objects 0x1A84, 0x1A83,
                                                              0x1A82


* I use the extracted values to create uint8_t buffer, which are holding
these information:
      uint8_t el6751_f800 [] = { 0x11, 0x00, 0x7F, ..., 0x00};
      uint8_t el6761_8000[] = { 0x2E, 0x00, 0x01, ..., 0x00};

* I register the pdos via ecrt_slave_config_pdos and use only the
mapping-objects, which where provided in the twincat startup sequence (the
entries in 0x1C12 and 0x1C13):

       ec_pdo_info_t rx_pdos[] = {
           { 0x1600, 0, NULL },
       };

       ec_pdo_info_t tx_pdos[] = {
          { 0x1A82, 0, NULL },
          { 0x1A83, 0, NULL },
          { 0x1A84, 0, NULL }
       };

       ec_sync_info_t syncs[] = {
           { 0, EC_DIR_OUTPUT, 0, NULL},
           { 1, EC_DIR_INPUT, 0, NULL},
           { 2, EC_DIR_OUTPUT, 1, rx_pdos},
           { 3, EC_DIR_INPUT, 3, tx_pdos},
           {0xff}
        }

        ecrt_slave_config_pdos(slave, EC_END, syncs);

   I provided NULL arguments in the mapping-configuration, because I'm
currently not sure, which objects are selected. I don't have access to the
machine with the master right now. I hope that's okay.

* I use ecrt_slave_config_complete_sdo with the buffers explained above.
Roughly like this:

     ecrt_slave_config_complete_sdo(slave, 0xF800, el6751_f800,
 sdo_f800_size);
     ecrt_slave_config_complete_sdo(slave, 0x8000, el6751_8000,
sdo_8000_size);

  I am sure that the sizes given ecrt_slave_config_complete_sdo are correct.


Is there something conceptually wrong with this?

@Gavin: You stated, that in case of  downloading the complete sdo object
including subindex 0, one has to provide two bytes for that. When I got
involved with ethercat and the master the first time, I included just one
byte for subindex 0, because all of the documentations I read were stating,
that subindex 0 is of uint8. It nearly drove me crazy, because the slave
always responded with something like "Error writing sdo xxxx: Value written
is too low/high". It was another post on this mailing list, where I saw
that actually two bytes have to be provided. I read the official
EtherCAT-Spec and didn't found something referring to this. So where can I
find this circumstance documented? ;D



2016-01-19 23:51 GMT+01:00 Gavin Lambert <gavinl at compacsort.com>:

> It’s hard to say without seeing what specific commands you’re trying to
> run.
>
>
>
> ecrt_master_sdo_download* is intended for one-off synchronous transfers
> before starting the realtime loop, eg. for cases where you’re trying to
> interrogate the device or otherwise do out-of-band exchanges.  (You can
> also use it on a separate thread after starting the realtime loop, but this
> can add latency due to lock contention, so it may not be a good idea if
> your period is short.)
>
>
>
> ecrt_slave_config_sdo* is intended for configuration required during the
> PREOP->SAFEOP transition.  You should always use these for such
> configuration (everything except the PDO Assign registers 0x1C1x, as those
> are automatically set from the PDO mappings you’ve made).  In particular if
> the device goes offline then these will automatically be re-sent when it
> reappears, while the above won’t.
>
>
>
> “Complete” SDOs are the most efficient way of downloading an entire object
> to the device, but they come with some caveats:
>
> ·         Not all devices support them (although most do) – you may need
> to check the device manual or the output of “ethercat slaves –v”
>
> ·         Some objects might be too large to fit in the mailbox – while
> there are some segmenting protocols to deal with this, not all slaves
> support those.  (Fortunately it’s rare for config objects to be large.)
>
> ·         You have to know the internal byte-for-byte layout of the
> object, including padding bytes in some cases.  This is usually similar to
> the layout of the subindexes but occasionally there can be surprises.
> Again, check the manual.  If you have access to something that can do SDO
> complete uploads, then try uploading the object first to see its current
> layout.  (Etherlab stable 1.5.2 doesn’t support this but I’ve previously
> posted some patches to add the feature.)
>
> ·         TwinCAT supports downloads both starting from subindex 0 (which
> requires including the number of subindexes as a two-byte field) or from
> subindex 1 (which omits this and only includes the “real” data of the
> object).  Etherlab only supports downloads starting from subindex 0.
>
>
>
> If complete access isn’t suitable for some reason, then you can fall back
> on downloading the subindexes individually.
>
>
>
> *From:* etherlab-users [mailto:etherlab-users-bounces at etherlab.org] *On
> Behalf Of *Matze Thias
> *Sent:* Wednesday, 20 January 2016 04:06
> *To:* etherlab-users at etherlab.org
> *Subject:* [etherlab-users] EL6751 SDO-Configuration
>
>
>
> Hello,
>
> I am trying to configure the EL6751 at the moment, so that I am able to
> send raw CAN messages over ethercat(
> http://infosys.beckhoff.com/content/1033/el6751/html/el6751_layer2_statemachine.htm?id=10857
> ).
> I took the configuration, which is done in terms of sdo-startup-downloads,
> from one of the twincat dialogs. Which method for sdo configuration is the
> right to choose?
>
> If I use ecrt_master_sdo_download_complete for the different SDO-Objects
> to upload, nothing happens. When using ecrt_slave_config_complete_sdo the
> device error-led starts blinking(indicating, that some configuration is in
> progress) but at the same time I get this:
>
> Jan 19 15:50:06 e-node8 kernel: [611927.053364] EtherCAT ERROR 0-1: Failed
> to set SAFEOP state, slave refused state change (PREOP + ERROR).
> Jan 19 15:50:06 e-node8 kernel: [611927.059801] EtherCAT ERROR 0-1:
> Unknown AL status code 0xF101.
>
> Can anyone explain the error and has a solution for this? Maybe someone
> has experience in getting the el6751 configured and work-ready for this
> scenario and can share his insights :) ?
>
> Greetings,
>
> Matze Thias
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20160120/fe21d24c/attachment-0004.htm>


More information about the Etherlab-users mailing list