Once again, for 0x8000 use the ecrt_slave_config_sdo*() set and not the _complete()! Yes, subindex 0 does have a special meaning and I don't recall ever having the need to set subindex 0.

Then, try to reduce your SDO's to a bare minimum, leaving default values alone. There is a special startup tab in TwinCAT where you can see how and in which order TwinCAT configures the slave. Try to copy those commands -- only those for 0x8000 and 0xf800, especially leaving out 0x1C12 & 0x1C13 (which the master does for you).

Maybe try to start the slave without any SDO. Check the defaults and configure the DeviceNet Bus so that it fits the default values (128k baud, node 63, etc).

On 09/15/2014 04:12 PM, Carlos Herkt wrote:
Hi,
the documentation seems inconsistent. f800:10 and f800:11 are shown in
TwinCATs CoE tab (see attachment) but not in the documentation.
Anyway, we tried not to set f800:0,11,12: the result is another error
message while writing 8000:0 :

SDO download 0x8000 (110 bytes) aborted.
SDO abort message 0x08000021: "Data cannot be transferred or stored to
the application beaucse of local control".
SDO configuration failed.

and the green MNS led is not starting to blink. (When writing 0x0b to
f800:0 the led starts blinking, but we are getting the timeout message)

If we set the 8000:XY fields manually and not setting 8000:0, we're not
getting the "cannot be transferred..." error but later the pdo
assignment fails.

It seems the subindex 0 has a "special" meaning for both of them.

Even, when downloading values to 0x8000 with the ethercat tool, the
device seems to not keep the values. See an example:

[etherlab@EtherLab ~]$ sudo ./ethercat-tool -p5 --type uint16 download
0x8000 1 0x3f
[etherlab@EtherLab ~]$ sudo ./ethercat-tool -p5 --type uint16 upload
0x8000 1
0x0000 0


Kind regards


Codesnippet:
/**************************************************************************
//ecrt_slave_config_sdo8(sc, 0xf800,  0, 0x0b);
     ecrt_slave_config_sdo16(sc, 0xf800, 1, 0x003f);
     ecrt_slave_config_sdo16(sc, 0xf800, 2, 0x0003);
     ecrt_slave_config_sdo16(sc, 0xf800, 3, 0x006c);
     ecrt_slave_config_sdo16(sc, 0xf800, 4, 0x000c);
     ecrt_slave_config_sdo16(sc, 0xf800, 5, 0x0060);
     ecrt_slave_config_sdo16(sc, 0xf800, 6, 0x1a01);
     ecrt_slave_config_sdo32(sc, 0xf800, 7, 0x01785634);
     //ecrt_slave_config_sdo8(sc, 0xf800, 8, 0x0b); //octet_string
BECKHOFF EL6752-0000
     ecrt_slave_config_sdo16(sc, 0xf800, 9, 0x0000);
     //ecrt_slave_config_sdo8(sc, 0xf800, 10, 0x00);
     //ecrt_slave_config_sdo8(sc, 0xf800, 11, 0x00);


     //ecrt_slave_config_complete_sdo(sc, 0xf800, sdo_config_0xf800,
sizeof(sdo_config_0xf800));
     ecrt_slave_config_complete_sdo(sc, 0x8000, sdo_config_0x8000,
sizeof(sdo_config_0x8000));

     // ecrt_slave_config_sdo16(sc, 0x8000, 1, 0x003f);
     // ecrt_slave_config_sdo16(sc, 0x8000, 0x0D, 2);
     // ecrt_slave_config_sdo16(sc, 0x8000, 0x0E, 0x0064);
     // ecrt_slave_config_sdo16(sc, 0x8000, 0x10, 0x0064);
     // ecrt_slave_config_sdo16(sc, 0x8000, 0x11, 0x0014);
     // ecrt_slave_config_sdo16(sc, 0x8000, 0x17, 0x0014);
     // ecrt_slave_config_sdo16(sc, 0x8000, 0x1E, 0x0010);
     // ecrt_slave_config_sdo16(sc, 0x8000, 0x1F, 0x0001);
     // ecrt_slave_config_sdo8(sc, 0x8000, 0, 0x36);
*************************************************************************/



Am 15.09.2014 08:30, schrieb Richard Hacker:
The first thing is to try to get the slave into OP somehow: do not set
0xf800:0, as well as subindices 10,11!! I do not see the latter in the
documentation!

Then:
Have you tried to get the device running without using 0xF800? As far
as I can read from the documentation, it may be possible - the slave
address can also be set in 0x8000:there. Maybe that works (although I
am not a specialist in DeviceNet)



On 09/12/2014 01:23 PM, Carlos Herkt wrote:
Ok, we set the SDO's with the ecrt_slave_config_sdo8/16/32()
functions...:

//**************************************************************************

//ecrt_slave_config_sdo16(sc, 0xf800,  1, 0x003c);//
//ecrt_slave_config_sdo16(sc, 0xf800,  2, 0x0003);//
//ecrt_slave_config_sdo16(sc, 0xf800,  3, 0x006c);//
//ecrt_slave_config_sdo16(sc, 0xf800,  4, 0x000c);//
//ecrt_slave_config_sdo16(sc, 0xf800,  5, 0x0060);//
//ecrt_slave_config_sdo16(sc, 0xf800,  6, 0x1a01);//
//ecrt_slave_config_sdo32(sc, 0xf800,  7, 0x01785634);//
////ecrt_slave_config_sdo8(sc, 0xf800,  8, 0x0b); //octet_string
BECKHOFF EL6752-0000//
//ecrt_slave_config_sdo16(sc, 0xf800,  9, 0x0000);//
//ecrt_slave_config_sdo8(sc, 0xf800,  10, 0x00);//
//ecrt_slave_config_sdo8(sc, 0xf800,  11, 0x00);
///ecrt_slave_config_sdo8(sc, 0xf800,  0, 0x0b);//
/***************************************************************************/

/
...but still get the timeout error.

Try to set SDO's explicitly using Index:SubIndex by using the
ecrt_slave_config_sdo8/16/32() family of functions instead of complete
access. In fact this the preferred method of setting SDO's.

On 09/11/2014 05:25 PM, Carlos Herkt wrote:
Hello,

referring to
http://lists.etherlab.org/pipermail/etherlab-users/2014/002613.html we
managed to set up our devices properly.
We can communicate with our slaves on both devices (EL6631 &&
EL66731)!

Now we're trying to initialize the Beckhoff EL6752 the same way we
did.
But another error arose:
/
dmesg: "Timeout after 1000 ms while  waiting for SDO 0xf800:0 download
response." /

We doublechecked our configuration and everything seems alright.

What does cause this failure?

Is there a way to change that timeout?

Any help is greatly appreciated.

Best regards




_______________________________________________
etherlab-users mailing list
[email protected]
http://lists.etherlab.org/mailman/listinfo/etherlab-users


Mit freundlichem Gruß

Richard Hacker



Mit freundlichem Gruß

Richard Hacker



Mit freundlichem Gruß

Richard Hacker

--
------------------------------------------------------------------------

Richard Hacker M.Sc.
[email protected]
Tel.: +49 201 / 36014-16

Ingenieurgemeinschaft IgH
Gesellschaft für Ingenieurleistungen mbH
Heinz-Bäcker-Str. 34
D-45356 Essen

Amtsgericht Essen HRB 11500
USt-Id.-Nr.: DE 174 626 722
Geschäftsführung:
- Dr.-Ing. T. Finke,
- Dr.-Ing. W. Hagemeister
Tel.: +49 201 / 360-14-0
http://www.igh-essen.com

------------------------------------------------------------------------
_______________________________________________
etherlab-users mailing list
[email protected]
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Reply via email to