[etherlab-users] PDO mapping without 0x1c12 0x 1c13 method
Thomas Bitsky Jr
tbj at automateddesign.com
Wed Jan 13 16:43:19 CET 2016
Are you using separate domains for read and write to the servo drive? While I can’t be sure this relates to your drive, I’m having similar problems with a Yaskawa servo and it turns out it’s because I only had one domain. Here’s a note from the mailing list:
>> if you do a “ethercat slave –v” command, each module has an “Enable notLRW” status. If it is “yes” then the slave needs separate domains for the read and write pdo’s.
More regarding servo drives that don’t support LRW:
[snip]
You definitely need to use two domains. One for the inputs, one for the outputs. In my app I use three. One for servo inputs, one for servo outputs and one for all other modules (that can have inputs and outputs in one domain).
For two domains you need to have two domain pointers:
ec_domain_t *domRead;
ec_domain_t *domWrite;
When making the ecrt_slave_config_reg_pdo_entry calls you pass the appropriate domain as required.
Then any time you would do something with a domain in your app, just call the function multiple times, one for each domain.
Eg:
ecrt_master_receive(master);
ecrt_domain_process(domRead);
ecrt_domain_process(domWrite);
...
ecrt_domain_queue(domRead);
ecrt_domain_queue(domWrite);
ecrt_master_send(master);
[/snip]
Good luck!
Thomas C. Bitsky Jr. | Lead Developer
ADC | automateddesign.com <http://automateddesign.com/>
Follow ADC news and media:
Facebook <https://facebook.com/automateddesigncorp> | Twitter <https://twitter.com/ADCSportsLogic> | YouTube <https://www.youtube.com/user/ADCSportsLogic>
On 1/13/16, 8:55 AM, "etherlab-users on behalf of Tillman, Scott" <etherlab-users-bounces at etherlab.org on behalf of Scott.Tillman at bhemail.com> wrote:
>We have begun testing the Parker P-Series drives as a replacement for the drives we currently use. I don't know all of the details, but I was told we "had to get custom firmware to map some of the PDOs". Also, some of the configuration was still odd to my eyes. It is possible we aren't using the drive in the same mode you want, but these were the settings we extracted from the TwinCAT config:
>
> ec_pdo_entry_info_t PSeries_pdoEntryInfo[] = {
> // PDO: 0x1A00
> { 0x6041, 0, 16 }, // Statusword
> { 0x6064, 0, 32 }, // Position Actual Value
> { 0x60B9, 0, 16 }, // Touch probe status
> { 0x60FD, 0, 32 }, // Digital Inputs
> { 0x60BA, 0, 32 }, // Touch probe 1 positive edge
> { 0x60F4, 0, 32 }, // Following Error Actual Value
> // PDO: 0x1600
> { 0x6040, 0, 16 }, // Controlword
> { 0x607A, 0, 32 }, // Target Position
> { 0x60B8, 0, 16 }, // Touch probe function
> { 0x6081, 0, 32 }, // Profile Velocity
> { 0x6083, 0, 32 }, // Profile Acceleration
> { 0x6084, 0, 32 }, // Profile Deceleration
> };
> ec_pdo_info_t PSeries_pdoInfo[] = {
> { 0x1A00, 6, &PSeries_pdoEntryInfo[0] },
> { 0x1600, 6, &PSeries_pdoEntryInfo[6] },
> };
> ec_sync_info_t PSeries_syncInfo[] = {
> {0, EC_DIR_OUTPUT, 0, NULL, EC_WD_DISABLE},
> {1, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},
> {2, EC_DIR_OUTPUT, 1, &PSeries_pdoInfo[1], EC_WD_DEFAULT},
> {3, EC_DIR_INPUT, 1, &PSeries_pdoInfo[0], EC_WD_DEFAULT},
> { 0xff }
> };
> ec_sdo_info_t PSeries_sdoInfo[] = { // NOTE: data must be in little endien format
> { 0x1A00, 0, 26, { 0x06, 0x00, 0x10, 0x00, 0x41, 0x60, 0x20, 0x00, 0x64, 0x60, 0x10, 0x00, 0xB9, 0x60, 0x20, 0x00, 0xFD, 0x60, 0x20, 0x00, 0xBA, 0x60, 0x20, 0x00, 0xF4, 0x60 } },
> { 0x1A01, 0, 2, { 0x00, 0x00 } },
> { 0x1A02, 0, 2, { 0x00, 0x00 } },
> { 0x1A03, 0, 2, { 0x00, 0x00 } },
> { 0x1600, 0, 26, { 0x06, 0x00, 0x10, 0x00, 0x40, 0x60, 0x20, 0x00, 0x7A, 0x60, 0x10, 0x00, 0xB8, 0x60, 0x20, 0x00, 0x81, 0x60, 0x20, 0x00, 0x83, 0x60, 0x20, 0x00, 0x84, 0x60 } },
> { 0x1601, 0, 2, { 0x00, 0x00 } },
> { 0x1602, 0, 2, { 0x00, 0x00 } },
> { 0x1603, 0, 2, { 0x00, 0x00 } },
> { 0x1C12, 0, 4, { 0x01, 0x00, 0x00, 0x16 } },
> { 0x1C13, 0, 4, { 0x01, 0x00, 0x00, 0x1A } },
> { 0x6060, 0, 1, { 0x01 } }, // Send OpMode SDO ( 1 = Profile Position Mode)
> { 0 }
> }; //data for calls to ecrt_slave_config_sdo()
>
>So, it's likely you'll need to contact Parker and ask about how to map the standard PDOs you are expecting (and get the right firmware). The SDOs for 0x1A000:00 and 0x16000:00 look *very* unusual to me with 26 bytes of data. It looks like instead of using the 0x1A00 subindexes they are just concatenating all of the data into one SDO. In any case, this is working for us in our life-test rig at the moment.
>
>-Scott Tillman
>Advisory Software Engineer
>Bell + Howell
>(919) 767-6745
>
>-----Original Message-----
>From: etherlab-users [mailto:etherlab-users-bounces at etherlab.org] On Behalf Of Thomas Paoloni
>Sent: Wednesday, January 13, 2016 6:12 AM
>To: etherlab-users at etherlab.org
>Subject: [etherlab-users] PDO mapping without 0x1c12 0x 1c13 method
>
>Hi,
>
>I'm trying to insert a Parker PSD servo drive in my ethercat network, but this item doesn't support the PDO mapping through the usual writing of the registers 0x1c12 and 0x1c13.
>In short, the mechanism of mapping the PDO by writing the usual C++ cstruct ec_pdo_entry_info_t and claiming the objects in to the PDO ec_pdo_entry_reg_t is not implemented.
>Anyway, I can have this slave working with Twincat and theoretically there should be an equivalent way to bring it in OP state even under etherlab master.
>What can I try ?
>
>
>Thanks in advance,
>
>Thomas Paoloni
>
>_______________________________________________
>etherlab-users mailing list
>etherlab-users at etherlab.org
>http://lists.etherlab.org/mailman/listinfo/etherlab-users
>_______________________________________________
>etherlab-users mailing list
>etherlab-users at etherlab.org
>http://lists.etherlab.org/mailman/listinfo/etherlab-users
More information about the Etherlab-users
mailing list