I have been trying to communicate with B&R X20 PLC (MN) using openPowerlink with a Zynq Emacps (CN) but have had limited success. I have followed the following guide: http://openpowerlink.sourceforge.net/doc/2.6/2.6.2/db/dd2/page_zynq_emacps.html
and the communication actually worked when sending and receiving 32 bytes of data. However, when I increase this to 64 bytes (sending and receiving), the CN kept restarting and I noticed that there is always an extra Pres in the cycle (SoC -> Preq -> Pres -> SoA -> Pres) just before the communication failure. I have attached the wireshark trace and this can be seen in line 222, 731, 1223. Does anyone have any idea what might be the problem here? I have tried a maximum of 50ms cycle time and 10ms PresTimeout but the problem still persists. I have also tried the same application code using B&R APC2100 with i210 driver interface and the communication worked so I am pretty sure this is not a problem with the application code. Has anyone encountered the same problem before?
We looked through the network trace. If you are using Windows to capture frames, the frame timestamps can be out of order. If feasible, please use a Linux tcpdump or wireshark to capture frames for better accuracy.
For narrowing the problem down, please also test the EMacPs CN with APC2100 master. If this is unstable, we can take it from there. This is because the Linux CNs have a slower rx/tx response cycle which can create problems in network behavior. Since you already have a working setuip with a Linux master, you can configure different parameters easily such as WaitSoCPreq to get a stable system working with EMacPs. Later you can update the same settings in your automation studio for the PLC. Thanks.
Hi,
I have been trying to communicate with B&R X20 PLC (MN) using openPowerlink with a Zynq Emacps (CN) but have had limited success. I have followed the following guide: http://openpowerlink.sourceforge.net/doc/2.6/2.6.2/db/dd2/page_zynq_emacps.html
and the communication actually worked when sending and receiving 32 bytes of data. However, when I increase this to 64 bytes (sending and receiving), the CN kept restarting and I noticed that there is always an extra Pres in the cycle (SoC -> Preq -> Pres -> SoA -> Pres) just before the communication failure. I have attached the wireshark trace and this can be seen in line 222, 731, 1223. Does anyone have any idea what might be the problem here? I have tried a maximum of 50ms cycle time and 10ms PresTimeout but the problem still persists. I have also tried the same application code using B&R APC2100 with i210 driver interface and the communication worked so I am pretty sure this is not a problem with the application code. Has anyone encountered the same problem before?
Hi Selina,
We looked through the network trace. If you are using Windows to capture frames, the frame timestamps can be out of order. If feasible, please use a Linux tcpdump or wireshark to capture frames for better accuracy.
For narrowing the problem down, please also test the EMacPs CN with APC2100 master. If this is unstable, we can take it from there. This is because the Linux CNs have a slower rx/tx response cycle which can create problems in network behavior. Since you already have a working setuip with a Linux master, you can configure different parameters easily such as WaitSoCPreq to get a stable system working with EMacPs. Later you can update the same settings in your automation studio for the PLC. Thanks.
Best Regards,
aeicoriiotteam