Ok. So after you do that and rescan, check the output of “ethercat cstruct”. This should have changed to reflect the new configuration of the assignment registers (assuming that the slave actually did accept the downloads), and this is the data that you need to include in your application code instead of trying to explicitly write to the assignment registers. (Using the correct sequence in ecrt_domain_reg_pdo_entry_list makes Etherlab do those same downloads internally during configuration.)
From: Derrill Vezina [mailto:dvez...@caroneng.com] Sent: Friday, 6 July 2018 02:03 To: Gavin Lambert <gavin.lamb...@tomra.com>; Derrill Vezina <vezin...@gmail.com>; etherlab-users@etherlab.org Subject: Re: [etherlab-users] Failed to execute SDO download: Protocol not supported Hi Gavin. I fully understand that this is a Beckhoff / integration issue and not anything to do with the master. I have been doing as you instructed and it has worked with different revisions with different PDO structures with a bunch of different cards up until this specific situation. Without getting too in depth with it, Beckhoff allowed setting two PDO’s originally including the period and duty cycle of the PWM wave output on the EL2502 for each channel. They decided on REV25+ that they were going to remove the period as a PDO and use it as an SDO. To fix this, Beckhoff has instructed a sequence of setting some startup SDO configuration registers that would set the PDO assignment back to the “old way” in which I have successfully done using the Etherlab tool using the following commands (only one card on the stack after starting the master): ./ethercat download --position 1 --type uint16 0x1C12 0x00 0x00 ./ethercat download --position 1 --type uint8 0x1C13 0x00 0x00 ./ethercat download --position 1 --type uint16 0x1C12 0x01 0x1602 ./ethercat download --position 1 --type uint16 0x1C12 0x02 0x1603 ./ethercat download --position 1 --type uint16 0x1C12 0x00 0x02 ./ethercat rescan Everything works great after that sequence. I guess my confusion lies in the fact that the tool successfully downloads the PDO’s using the ioctl interface without getting a “Protocol not supported” error. Is there a reason why I would get a “Protocol not supported” error using the application interface library to do this (ecrt_master_sdo_download()) but not using the tool? Is the master state the problem? From: etherlab-users <etherlab-users-boun...@etherlab.org<mailto:etherlab-users-boun...@etherlab.org>> on behalf of Gavin Lambert <gavin.lamb...@tomra.com<mailto:gavin.lamb...@tomra.com>> Date: Thursday, June 28, 2018 at 7:45 PM To: Derrill Vezina <vezin...@gmail.com<mailto:vezin...@gmail.com>>, "etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>" <etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org>> Subject: Re: [etherlab-users] Failed to execute SDO download: Protocol not supported You don’t need to perform explicit downloads of the PDO assignment or configuration registers at all, ever; they are managed internally by the master library. Simply use the combination of ecrt_slave_config_pdos and ecrt_domain_reg_pdo_entry_list as shown in the examples. You can use “ethercat cstruct” to generate the required data structures for these calls. (In some cases or for particular slaves, eg. with overlapping or repeated PDOs, you might need to do something a little more complicated, but that is rare.) If you have slaves with different revisions, note that different structures may be required for each revision, if the PDO layout has been changed. If the slave does not support CoE (which is what the “protocol not supported” error implies) then it is not possible to alter the slave’s PDO assignment – it has a manufacturer-defined fixed setup. You must make sure that the configuration and assignment defined in your application matches this, by using those APIs mentioned above. From: Derrill Vezina Sent: Friday, 29 June 2018 01:40 To: etherlab-users@etherlab.org<mailto:etherlab-users@etherlab.org> Subject: [etherlab-users] Failed to execute SDO download: Protocol not supported Hi, I am currently using a Beckhoff EL2502 PWM output card with the Etherlab 1.5.2 master using the generic ethernet driver. On startup, I am trying to set a PDO assignment SDO register using ecrt_master_sdo_download() and am getting an error back “Failed to execute SDO download: Protocol not supported”. I am not able to set a PDO assignment SDO registers using the ecrt_slave_config_sdoX() calls…which from my reading of other mailing list posts is only used for configuration registers. In turn, I was able to use the Ethercat Etherlab tool and change the PDO mapping so I assumed it is available from the application interface since they use the same calls (ioctl interface) Beckhoff changed the firmware on the card and I’m trying to reassign the PDO’s to the old mappings… this isn’t the first time I’ve run into this problem so I'm looking for a solution for all cards that would have this problem. Ideally, id like to do it through the application interface and avoid running a script on startup that uses the tool. Has anyone has success with doing this type of transaction?
_______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
