Hi mophong,
the delay from APPL_OutputMapping to APPL_InputMapping origins from the SW-processing inside Slave#1.
While the EPU is triggering this SW-processing, in parallel it forwards the frame to slave#2 on port#1/out.
While slave is still busy on processing APPL_OutputMapping/APPL_InputMapping the frame arrives on Slave#2. The EPU of slave#2 is than triggering the SW-input/output-processing in parallel.
So the delay of slave#1/OutputMapping to slave#2/OutputMapping is more or less the delay you are looking for and which is introduced by the EPU(s) to forward the packet from slave#1 to slave#2.
There is no need to wait for APPL_InputMapping on slave#1 being finished before the frame is forwarded to slave#2.
Kind Regards
Michael
the delay from APPL_OutputMapping to APPL_InputMapping origins from the SW-processing inside Slave#1.
While the EPU is triggering this SW-processing, in parallel it forwards the frame to slave#2 on port#1/out.
While slave is still busy on processing APPL_OutputMapping/APPL_InputMapping the frame arrives on Slave#2. The EPU of slave#2 is than triggering the SW-input/output-processing in parallel.
So the delay of slave#1/OutputMapping to slave#2/OutputMapping is more or less the delay you are looking for and which is introduced by the EPU(s) to forward the packet from slave#1 to slave#2.
There is no need to wait for APPL_InputMapping on slave#1 being finished before the frame is forwarded to slave#2.
Kind Regards
Michael