Re: [etherlab-users] No CoE communication

[Graeme Foot]

Hi,

I don't know for sure, but I suspect you are having issues with your network.  
I don't know Xenomi so can't comment on what might be wrong, but I don't think 
you should be getting any datagram timeouts on startup while the EtherCAT 
system is idle (i.e. before you start your app).

For comparison I have attached my startup log.

You could also try monitoring your EtherCAT network with wireshark to see what 
packets are going through.

Graeme.


-Original Message-
From: Rahul Deshpande [mailto:rahulg...@gmail.com] 
Sent: Thursday, 24 August 2017 5:26 a.m.
To: Graeme Foot <graeme.f...@touchcut.com>
Cc: etherlab-users@etherlab.org
Subject: Re: No CoE communication

Hi Graeme,

Thanks for the application. I tried implementing your master without the 
patches and with my application.

It does not reach the application stage and throws this error prior to login.
I get the following errors (PFA). It throws a reception of CoE dictionary 
request failed'

Regards,
Rahul



On 8/23/17, Graeme Foot <graeme.f...@touchcut.com> wrote:
> Hi,
>
> I have attached a test app to have a look at.  It is a (very) cut down 
> version of how my app works.  Of course I use RTAI, so it won't be 
> compatible with your Xenomi environment.
>
>
> In main.c at the top of runECat() I have a list of EtherCAT devices 
> and their addresses.  It is hard coded here but can of course be 
> loaded from a config file.  The device names match devices in the 
> etherCATSlaves.c file.
>
> etherCATMaster.c contains the code to configure and run the master.
> etherCATSlaves.c contains each slave's code.
>
> yaskawaSGDV_create()
> - configures the device and gets the PDO command offsets
>
> yaskawaSGDV_prepareToRun()
> - calculates each commands address (after the domains are populated 
> and
> allocated)
> - sets cyclic synchronous position mode (optional, the mode can be set 
> at any time while running)
> - sets the control word to zero, just in case
>
> yaskawaSGDV_run()
> - is called once each scan.  add code here to control the axis
>
> yaskawaSGDV_prepareToStop()
> - is called when the app is closing.  add any code here to clean up 
> your axis
>
>
> Note: In this app the prepareToStop() functions are called once and 
> then the app is shut down immediately.  In reality you should continue 
> your realtime cycle until all of the devices are stopped, disabled and safe 
> to turn off.
> The app also relies on some of my patches.
>
>
> I hope this helps
>
> Regards,
> Graeme.
>
>
>
> -Original Message-
> From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On 
> Behalf Of Graeme Foot
> Sent: Wednesday, 16 August 2017 10:42 a.m.
> To: Rahul Deshpande <rahulg...@gmail.com>; etherlab-users@etherlab.org
> Subject: Re: [etherlab-users] No CoE communication
>
> Hi,
>
> I've been asked to let you know what master version and patches I'm using.
> I'm still running an old version (2526 from the stable-1.5 branch, 
> 12/02/2013).  The script I use to download it is attached 
> (004-etherlab_master).
>
> I use buildroot to create my linux system, so the script  tar's the 
> master folder and puts it in the buildroot downloads folder.  Note: I 
> also use a really old buildroot from 2012 with a few modifications, 
> but I have attached the mk file that it uses.
>
> The patches that I apply are also attached.
>
> The build options I use are:
> --with-linux-dir=""
> --enable-cycles
> --enable-rtdm
> --enable-e100
> --enable-e1000
> --enable-e1000e
> --enable-cx2100
>
>
> I use RTAI, but that shouldn't make any difference.
>
>
> Regards,
> Graeme.
>
>
> -----Original Message-
> From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On 
> Behalf Of Graeme Foot
> Sent: Tuesday, 15 August 2017 12:39 p.m.
> To: Rahul Deshpande <rahulg...@gmail.com>; etherlab-users@etherlab.org
> Subject: Re: [etherlab-users] No CoE communication
>
> Remember to reply-all to mail the forum as well.
>
> Line 85 has: #define Yaskawa_Sigma7  0x0539, 0x02200301 This is 
> different to my drive, so it may still be the Sigma 7 id causing a 
> mismatch, but it is the id being returned from the ethercat struct command.
>
> Other than that, I've got no idea.
>
> Graeme.
>
>
> -Original Message-
> From: Rahul Deshpande [mailto:rahulg...@gmail.com]
> Sent: Tuesday, 15 August 2017 3:57 a.m.
> To: Graeme Foot <graeme.f...@touchcut.com>
> Subject: No CoE communication
>
> Hi Graeme,
>
> I understand I have been mailing a lot, my questions may seem repetitive.
>
> The positive now is I was able to get to OP state by forcefully 
> setting 1c12 and 1c13 

Re: [etherlab-users] No CoE communication

[Rahul Deshpande]

Hi Graeme,

Thanks for the application. I tried implementing your master without
the patches and with my application.

It does not reach the application stage and throws this error prior to login.
I get the following errors (PFA). It throws a reception of CoE
dictionary request failed'

Regards,
Rahul



On 8/23/17, Graeme Foot <graeme.f...@touchcut.com> wrote:
> Hi,
>
> I have attached a test app to have a look at.  It is a (very) cut down
> version of how my app works.  Of course I use RTAI, so it won't be
> compatible with your Xenomi environment.
>
>
> In main.c at the top of runECat() I have a list of EtherCAT devices and
> their addresses.  It is hard coded here but can of course be loaded from a
> config file.  The device names match devices in the etherCATSlaves.c file.
>
> etherCATMaster.c contains the code to configure and run the master.
> etherCATSlaves.c contains each slave's code.
>
> yaskawaSGDV_create()
> - configures the device and gets the PDO command offsets
>
> yaskawaSGDV_prepareToRun()
> - calculates each commands address (after the domains are populated and
> allocated)
> - sets cyclic synchronous position mode (optional, the mode can be set at
> any time while running)
> - sets the control word to zero, just in case
>
> yaskawaSGDV_run()
> - is called once each scan.  add code here to control the axis
>
> yaskawaSGDV_prepareToStop()
> - is called when the app is closing.  add any code here to clean up your
> axis
>
>
> Note: In this app the prepareToStop() functions are called once and then the
> app is shut down immediately.  In reality you should continue your realtime
> cycle until all of the devices are stopped, disabled and safe to turn off.
> The app also relies on some of my patches.
>
>
> I hope this helps
>
> Regards,
> Graeme.
>
>
>
> -Original Message-
> From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf
> Of Graeme Foot
> Sent: Wednesday, 16 August 2017 10:42 a.m.
> To: Rahul Deshpande <rahulg...@gmail.com>; etherlab-users@etherlab.org
> Subject: Re: [etherlab-users] No CoE communication
>
> Hi,
>
> I've been asked to let you know what master version and patches I'm using.
> I'm still running an old version (2526 from the stable-1.5 branch,
> 12/02/2013).  The script I use to download it is attached
> (004-etherlab_master).
>
> I use buildroot to create my linux system, so the script  tar's the master
> folder and puts it in the buildroot downloads folder.  Note: I also use a
> really old buildroot from 2012 with a few modifications, but I have attached
> the mk file that it uses.
>
> The patches that I apply are also attached.
>
> The build options I use are:
> --with-linux-dir=""
> --enable-cycles
> --enable-rtdm
> --enable-e100
> --enable-e1000
> --enable-e1000e
> --enable-cx2100
>
>
> I use RTAI, but that shouldn't make any difference.
>
>
> Regards,
> Graeme.
>
>
> -----Original Message-
> From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf
> Of Graeme Foot
> Sent: Tuesday, 15 August 2017 12:39 p.m.
> To: Rahul Deshpande <rahulg...@gmail.com>; etherlab-users@etherlab.org
> Subject: Re: [etherlab-users] No CoE communication
>
> Remember to reply-all to mail the forum as well.
>
> Line 85 has: #define Yaskawa_Sigma7  0x0539, 0x02200301 This is
> different to my drive, so it may still be the Sigma 7 id causing a mismatch,
> but it is the id being returned from the ethercat struct command.
>
> Other than that, I've got no idea.
>
> Graeme.
>
>
> -Original Message-
> From: Rahul Deshpande [mailto:rahulg...@gmail.com]
> Sent: Tuesday, 15 August 2017 3:57 a.m.
> To: Graeme Foot <graeme.f...@touchcut.com>
> Subject: No CoE communication
>
> Hi Graeme,
>
> I understand I have been mailing a lot, my questions may seem repetitive.
>
> The positive now is I was able to get to OP state by forcefully setting 1c12
> and 1c13 to 0 (PDO assignment fro SM2 and SM3).
>
> I am still not able to configure the PDOs though. What I have narrowed down
> to is, somehow CoE communication just does not happen. I was going through
> the etherlab forum and came across a post where they mentioned some sdo's
> had to be set prior to configuring the PDOs. Is it that ?
>
> Also, It would be great if I could just reach out to you on your phone if
> thats not an issue. Could sort out my problems faster and not disturb you
> with constant emails. Do let me know if thats an option.
> Thank you so much.
>
> Regards,
> Rahul
>
)
 
AT91 NAND: 8-b

Re: [etherlab-users] No CoE communication

[Graeme Foot]

Remember to reply-all to mail the forum as well.

Line 85 has: #define Yaskawa_Sigma7  0x0539, 0x02200301
This is different to my drive, so it may still be the Sigma 7 id causing a 
mismatch, but it is the id being returned from the ethercat struct command.

Other than that, I've got no idea.

Graeme.


-Original Message-
From: Rahul Deshpande [mailto:rahulg...@gmail.com] 
Sent: Tuesday, 15 August 2017 3:57 a.m.
To: Graeme Foot 
Subject: No CoE communication

Hi Graeme,

I understand I have been mailing a lot, my questions may seem repetitive.

The positive now is I was able to get to OP state by forcefully setting 1c12 
and 1c13 to 0 (PDO assignment fro SM2 and SM3).

I am still not able to configure the PDOs though. What I have narrowed down to 
is, somehow CoE communication just does not happen. I was going through the 
etherlab forum and came across a post where they mentioned some sdo's had to be 
set prior to configuring the PDOs. Is it that ?

Also, It would be great if I could just reach out to you on your phone if thats 
not an issue. Could sort out my problems faster and not disturb you with 
constant emails. Do let me know if thats an option.
Thank you so much.

Regards,
Rahul
--- Begin Message ---
Hi Graeme,

Sorry for the confusion, The sigma 5 was there with me only for a
month. They replaced it and gave me a sigma 7. So I had to change the
product code and vendor id.

I followed your instructions and upon running ethercat struct I got
the following values.


/* Master 0, Slave 0

 * Vendor ID:   0x0539

 * Product code:0x02200301

 * Revision number: 0x00080003

 */



ec_sync_info_t slave_0_syncs[] = {

{0, EC_DIR_OUTPUT, 0, NULL, EC_WD_DISABLE},

{1, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},

{2, EC_DIR_OUTPUT, 0, NULL, EC_WD_ENABLE},

{3, EC_DIR_INPUT, 0, NULL, EC_WD_DISABLE},

{0xff}





I didnt get any other value with respect to pdos. I replaced these
values in the sync of my application. Still I get the same errors of
pdo not assigned properly. I have attached the dmesg logs.

Do we really need to configure PDOs to get the drive into OP state ?.
Or is it absolutely necessary and that just configuring the PDOs will
get me to OP state ?.

In the previous mail, I had sent the application. Just wanted to
confirm if I have defined the domains in the correct way.

Also is the domain like a pipe in IPC ?. Does it just help in
establishing a link and then the PDOs are transferred between master
and slave ?

Thank you,
Rahul

On 8/10/17, Graeme Foot  wrote:
> You don't need any patches to get running.
>
> The patches I use are a CX2100 driver, some RTAI fixes (your using Xenomi),
> some patches to increase the performance of the SDO's and some distributed
> clock fixes.
> It's only the distributed clock fixes which you will need at some stage,
> best to get them from Gavin's patchset as he keeps them up to date with the
> latest release.  Mine are a few years old now.
>
> Looking at your log it looks like it is completely failing to configure the
> PDO's.  You also have a different drive to mine (Yours: 0x0539,
> 0x02200301;  mine: 0x0539, 0x0221) so the PDO configuration may not
> be the same.  To get the PDO's for your drive, repower your system
> (including the drive) to reset it, then use the "ethercat struct" command.
> This will output the default PDO's required by the drive.
>
>
> What is the results for the following commands:
>
> ethercat struct   (after repowering the system, before running your app)
>
> ethercat debug 1
> 
> dmesg
>
>
>
> Regards,
> Graeme.
>
>
>
> -Original Message-
> From: Rahul Deshpande [mailto:rahulg...@gmail.com]
> Sent: Friday, 11 August 2017 3:20 a.m.
> To: Graeme Foot 
> Subject: Re: Yaskawa sigma 5 application
>
> Hi Graeme,
>
> Ignore the previous main.c. The one attached in this mail is what I am using
> to communicate with the drive.
>
> On 8/10/17, Rahul Deshpande  wrote:
>> Hi Graeme,
>>
>> I noticed you mentioned that I could be needing patches in order to
>> get yaskawa work with the master. Do we need all the patches on your
>> name or just a selective few ?.
>>
>> At this point I am trying to get to OP state but even after changing
>> the application I cannot surpass it. I have attached the new
>> application that I wrote and also the logs. These logs are obtained
>> after running the 'ethercat debug 1' command before running the
>> application. It is throwing an error for each domain that I have
>> defined.
>>
>> Looking forward to your reply.
>>
>> Thank you,
>> Rahul
>>
>


Debug1
Description: Debug1
--- End Message ---
--- Begin Message ---
Hi Graeme,

I checked the PDO mappings for sigma 7 and sigma 5. They are exactly
the same. The problem may not be with the pdo mappings.

Also we got an error of 'No default mapping