[etherlab-dev] Bandwidth optimizations

Daniel Bechter daniel.bechter at omicron.at
Thu Nov 5 14:04:47 CET 2009


Hey guys!

I performed a test with the EtherLab EtherCAT-Master (devel-r1770) and created a Slave EEPROM with the following SM configuration:

SM0: PhysAddr 0x1100, DefaultSize    0, ControlRegister 0x64, Enable 1
  RxPDO 0x1a00 "Output"
    PDO entry 0x7000:01, 16 bit, " Channel 1"
SM1: PhysAddr 0x1200, DefaultSize    0, ControlRegister 0x20, Enable 1
  TxPDO 0x1600 "Input"
    PDO entry 0x6000:01, 16 bit, "Sample 1"

I realized that the EtherCAT-Master allocated 4 Bytes within the frame for the data. Isn't 2 Bytes enough? The ESC puts the output data from the LRW datagram with logical address 0x0 from Bit 0 to Bit 15 into the physical memory at 0x1100 and puts the input data from the physical memory at 0x1200 into the same area within the frame, effectively overwriting the output data with the input data. FMMU configuration should look as follows:

Logical Start Address: 0x00000000
Length (Bytes): 2
Logical Start bit: 0
Logical Stop bit: 15
Physical Start Address: 0x1100
Physical Start bit: 0
Type: write

Logical Start Address: 0x00000000
Length (Bytes): 2
Logical Start bit: 0
Logical Stop bit: 15
Physical Start Address: 0x1200
Physical Start bit: 0
Type: read

So you would not have to allocate memory for the sum of inputs and outputs but for max(inputs, outputs). EtherLab EtherCAT-Master seems to be configuring the FMMU the following way:

Logical Start Address: 0x00000000
Length (Bytes): 2
Logical Start bit: 0
Logical Stop bit: 15
Physical Start Address: 0x1100
Physical Start bit: 0
Type: write

Logical Start Address: 0x00000000
Length (Bytes): 2
Logical Start bit: 16
Logical Stop bit: 31
Physical Start Address: 0x1200
Physical Start bit: 0
Type: read


Is there anything I did not think about? Thought this was a huge EtherCAT concept to save bandwidth?

Greets,
Daniel



More information about the etherlab-dev mailing list