Gavin, That did indeed work. Thank you for your support. The “ethercat debug 1” helped my quite a bit. I’m still not sure about the protocol not supported, but it’s not needed.
Thank you!! > On Jul 8, 2018, at 7:59 PM, Gavin Lambert <gavin.lamb...@tomra.com> wrote: > > No, you should never need to run downloads via a script. > > As I said, you do the downloads once manually and then get the cstruct > output, and put that into your application code. After this, simply starting > your application and activating the master should automatically do the same > configuration just prior to switching to SAFEOP – you don’t need to have any > explicit SDO download code in your app; you only have the > ecrt_domain_reg_pdo_entry_list(). > > You can use “ethercat debug 1”, start up your application, and then observe > the syslog to see that it will automatically configure the 0x1C12 and 0x1C13 > registers with just that. If things still aren’t working then this might > also give you some additional hints. > > As for “protocol not supported”, I’m not really sure. What’s the output of > “ethercat slaves -v” on that specific slave? > > From: Derrill Vezina [mailto:vezin...@gmail.com] > Sent: Saturday, 7 July 2018 06:34 > To: Gavin Lambert <gavin.lamb...@tomra.com> > Cc: Derrill Vezina <dvez...@caroneng.com>; etherlab-users@etherlab.org > Subject: Re: [etherlab-users] Failed to execute SDO download: Protocol not > supported > > 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.lamb...@tomra.com > <mailto:gavin.lamb...@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:dvez...@caroneng.com > <mailto:dvez...@caroneng.com>] > Sent: Friday, 6 July 2018 02:03 > To: Gavin Lambert <gavin.lamb...@tomra.com <mailto:gavin.lamb...@tomra.com>>; > Derrill Vezina <vezin...@gmail.com <mailto:vezin...@gmail.com>>; > etherlab-users@etherlab.org <mailto: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 <mailto:etherlab-users@etherlab.org> > http://lists.etherlab.org/mailman/listinfo/etherlab-users > <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.etherlab.org%2Fmailman%2Flistinfo%2Fetherlab-users&data=02%7C01%7Cgavin.lambert%40tomra.com%7C941b8c1cacc944700e1c08d5e36f1275%7C4308d118edd143008a37cfeba8ad5898%7C0%7C0%7C636664988557935341&sdata=R15pFMQz%2Fvo2wO%2FjzEvYvdKCXooKiRQ2QWVJ4FCqIqk%3D&reserved=0>
_______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
