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-boun...@etherlab.org on behalf of scott.till...@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-boun...@etherlab.org] On Behalf Of >Thomas Paoloni >Sent: Wednesday, January 13, 2016 6:12 AM >To: etherlab-users@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@etherlab.org >http://lists.etherlab.org/mailman/listinfo/etherlab-users >_______________________________________________ >etherlab-users mailing list >etherlab-users@etherlab.org >http://lists.etherlab.org/mailman/listinfo/etherlab-users _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
