BK1120 BusCoupler with K-Bus terminals

[Bit2Bi]

Hello,

I' am experimenting with the SOEM code since a while. I still have no success in get the thing running. It always throws an exception saying: 'SdoWrite failed <0x0000>: The working counter is 0 '
The exception is thrown when trying ' master.Configure(rootSlave); '
It seems, that the type of dataset does not match. The WireShark log shows a value of 500 but should be 5.

Is there any workaround for this problem?
`

            if (slave.ProductCode == 0x04602c22)
            {
                var dataset = new List<object>();

                dataset.Add((byte) 0x5);
                 
                var requests = new List<SdoWriteRequest>()
                {
                    // Index 0x8000 sub index 6: Filter on
                    //new SdoWriteRequest(0x7040, 0x1, dataset),
                    new SdoWriteRequest(0x427f, 0x0, dataset),                       
                };
                slave.Extensions.Add(new InitialSettingsExtension(requests));
            }

`

WireShark response.

`No. Time Source Destination Protocol Length Info
157042 0.000258 03:01:01:01:01:01 Broadcast ECAT 164 'FPWR': Len: 136, Adp 0x1001, Ado 0x1c00, Wc 1 Mbx(CoE SDO Req : 'Initiate Download' (1) Idx=0x427f Sub=0)

Frame 157042: 164 bytes on wire (1312 bits), 164 bytes captured (1312 bits)
Ethernet II, Src: 03:01:01:01:01:01 (03:01:01:01:01:01), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
EtherCAT frame header
EtherCAT datagram(s): 'FPWR': Len: 136, Adp 0x1001, Ado 0x1c00, Wc 1
EtherCAT datagram: Cmd: 'FPWR' (5), Len: 136, Adp 0x1001, Ado 0x1c00, Cnt 1
Header
EtherCAT Mailbox Protocol:CoE SDO Req : 'Initiate Download' (1) Idx=0x427f Sub=0
Header
CoE
Number: 0
Type: SDO Req (2)
SDO Req : 'Initiate Download' (1) Idx=0x427f Sub=0
Index: 0x427f
SubIndex: 0x00
Length: 0x00000002
Data: 0500
Data: 000000000000000000000000000000000000000000000000000000000000000000000000…
Data: 000000000000000000000000000000000000000000000000000000000000000000000000…
Working Cnt: 1
Working Cnt: 1
WireShark.txt
`

[Apollo3zehn]

I am not sure if that is the problem. According to the spec, if SDO Upload happens with "Complete Access" mode, and sub index 0 is requested, it will be padded to 16 bits. Can you see from within Wireshark if the the "Complete Access"-bit is set? From your log I cannot check it.

EtherCAT.NET/native/SOEM_wrapper/soem_wrapper.c

Lines 1013 to 1027 in 51f59a8

	// Clause 12.2 of the ETG.1020 specification, sub-point 1 "SDO Complete Access" -> Subindex 0 is padded to 16 bits
	if (sdoSubIndex == 0)
	{
	uint8* datasetPadded = calloc(totalByteCount + 1, 1);
	datasetPadded[0] = dataset[0];
	for (int i = 1; i < totalByteCount; i++)
	{
	datasetPadded[i + 1] = dataset[i];
	}
	returnValue += ecx_SDOwrite(context, slaveIndex, sdoIndex, sdoSubIndex, TRUE, totalByteCount + 1, datasetPadded, timeout);
	free(datasetPadded);
	}

Does it work with pure SOEM code? What helped me often is to compare the TwinCAT Wireshark log to the SOEM/EtherCAT.NET Wireshark log. It is helpful then to reduce the number of connected slaves to a minimum because TwinCAT executes multiple commands per frame which makes searching the Wireshark log more difficult.

[Bit2Bi]

Ok, said bit is set. What is the consequence for the format of the 'dataset' variable. Does it depend on the byte order HighByte/LowByte (Endian)?

EtherCAT Mailbox Protocol:CoE SDO Req : 'Initiate Download' (1) Idx=0x427f Sub=0
Header
CoE
Number: 0
Type: SDO Req (2)
SDO Req : 'Initiate Download' (1) Idx=0x427f Sub=0
Initiate Download: 0x31
.... ...1 = Size Ind.: Set
.... ..0. = Expedited: Not set
.... .0.. = Bytes: Not set
.... 0... = Bytes: Not set
...1 .... = Access: Complete
Index: 0x427f
SubIndex: 0x00
Length: 0x00000002
Data: 0500
Data: 000000000000000000000000000000000000000000000000000000000000000000000000…
Data: 000000000000000000000000000000000000000000000000000000000000000000000000…
Working Cnt: 0
Working Cnt: 0

[Apollo3zehn]

The dataset variable should not be changed. The padding is an implementation detail. But the set "complete access" bit is a hint that the data is transmitted correctly. What I would do now is to compare TwinCAT and SOEM/EtherCAT.NET Wireshark logs.

[Bit2Bi]

I had no TwinCAT setup on my machine on hand. But I tested the unit with the "Simple_Test"-code which worked fine. When than compared with the WireShark-log below I found that there are some added bytes in the CoE-section. The field 'length' does not appear in the 'Simple_Test' log. The consequence is, that after the subIndex byte (00) a sequence of 4 bytes follows were only 2 bytes are expected. Since I have no idea how to control this value it remains random and therefor a undefined address is used. The data in the said field is the order of the connected terminals.
It can explain exception thrown.

EtherCAT Mailbox Protocol:CoE SDO Req : 'Initiate Download' (1) Idx=0x427f Sub=0
Header
Length: 12
Address: 0x0000
.... ..00 = Priority: 0
Type: CoE (CANopen over EtherCAT) (3)
Counter: 1
CoE
Number: 0
Type: SDO Req (2)
SDO Req : 'Initiate Download' (1) Idx=0x427f Sub=0
Initiate Download: 0x31
.... ...1 = Size Ind.: Set
.... ..0. = Expedited: Not set
.... .0.. = Bytes: Not set
.... 0... = Bytes: Not set
...1 .... = Access: Complete
Index: 0x427f
SubIndex: 0x00
Length: 0x00000002
Data: 0500
Data: 000000000000000000000000000000000000000000000000000000000000000000000000…
Data: 000000000000000000000000000000000000000000000000000000000000000000000000…
Working Cnt: 1
Working Cnt: 1

0000 ff ff ff ff ff ff 03 01 01 01 01 01 88 a4 94 10 ................
0010 05 07 01 10 00 1c 88 00 04 00 0c 00 00 00 00 13 ................
0020 00 20 31 7f 42 00 02 00 00 00 05 00 00 00 00 00 . 1.B...........
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00a0 00 00 01 00 ....

[Bit2Bi]

may be I misunderstood the protocol. It seems do be right. However, I don't see that the load data are more than 4 Byte which according to the specs should result in an additional field of the protocol. Actually they are only 2 Bytes long: 0x0005.
So any other circumstance causes the present exception.