[etherlab-users] Failed to execute SDO download: Protocol not supported

Fri Jul 6 20:34:10 CEST 2018

The problem is that the downloads are not persistent and the PDO / Sync registers do not hold on power cycle…so the downloads need to happen every time on boot. Is it common practice to run the SDO downloads using the tool using a script on startup?

Going back to my original question, what is the difference is between running the etherlab tool to download SDO’s in which im not getting the “Protocol not supported” error (which I have done and it re-assigns the PDO entries correctly which changes the output of the cstruct to match the Rev25 and below), and trying to do it from my software using the application library using  ecrt_master_sdo_download() (pre-cyclic task / ecrt_domain_reg_pdo_entry_list()) which essentially uses the same code using the ioctl interface which is where I'm getting the “Protocol not supported” error?

> On Jul 5, 2018, at 7:30 PM, Gavin Lambert <gavin.lambert at tomra.com> wrote:
> 
> 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:dvezina at caroneng.com] 
> Sent: Friday, 6 July 2018 02:03
> To: Gavin Lambert <gavin.lambert at tomra.com>; Derrill Vezina <vezinadj at gmail.com>; etherlab-users at 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-bounces at etherlab.org <mailto:etherlab-users-bounces at etherlab.org>> on behalf of Gavin Lambert <gavin.lambert at tomra.com <mailto:gavin.lambert at tomra.com>>
> Date: Thursday, June 28, 2018 at 7:45 PM
> To: Derrill Vezina <vezinadj at gmail.com <mailto:vezinadj at gmail.com>>, "etherlab-users at etherlab.org <mailto:etherlab-users at etherlab.org>" <etherlab-users at etherlab.org <mailto:etherlab-users at 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 at etherlab.org <mailto:etherlab-users at 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 at etherlab.org <mailto:etherlab-users at etherlab.org>
> http://lists.etherlab.org/mailman/listinfo/etherlab-users <http://lists.etherlab.org/mailman/listinfo/etherlab-users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20180706/04909d15/attachment-0003.htm>