Last days I was trying to build openPOWERLINK stack and demos. Now everything is up and running and I've created the following test set-up:
openPOWERLINK v.2.7.1
MN - PC, Ubuntu 18.04, Native installation, running demo_mn_console or demo_mn_qt
CN1 - PC, Ubuntu 18.04, Virtual machine, running demo_cn_console
CN32 - iMX6 computer on module, Embedded Linux, running demo_cn_console
All node are running with default openPOWERLINK demo configuration.
All devices are connected in their own separate network segment to avoid external traffic.
If MN is connected to single CN, doesn't matter which one, everything works fine - node is detected and proper information about inputs and outputs is displayed.
Once second CN is connected, all data transfer is corrupted. Both CNs loses connection to MN and negotiation between MN and CNs becomes endless. Successful connection and disconnection looks totally random. Once one of the CNs is shut down, the other one establishes connection immediately and everything backs to normal.
Does anybody faced such issue? I will try to capture logs from all devices and post it here.
Have a great evening!
Best regards,
Ivan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From your description of the problem it might be a cycle time performance problem which can be solved by increasing the PResTimeout and cycle time of the CNs and network, respectively; but console logs and a network trace will help in narrowing it down.
Fyi, the default MN and CN demos use Linux TUN/TAP (PCAP lib) driver for accessing the network which has a higher system latency and thus higher response times. A virtual CN app has even further latency than native applications. Btw, for iMX6, are you using the distro from NXP ?
Thank you very much for your quick response!
Currently I am using default cycle time. It looks like ~50ms, based on Wireshark trace and time between SoA/SoC frames.
For iMX6 - computer on module is based on NXP iMX6, it's running Torizon Linux. I've cross-compiled openPOWERLINK stack and CN console demo for it.
I will capture detailed logs tomorrow morning - network log from MN and console logs from all applications.
Best regards,
Ivan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the info. Yes, the logs would be helpful.
The default cycle time of 50ms should be good enough for 2 CNs.
For the next run, while capturing logs and traces, please try with >10ms Pollsresponse timeout, if feasible.
update: just an fyi, when you build the demo CN applications, you have to change the node id in the main file for each CN.
Looks like there are timing issue with CN1 (Virtual machine). Now it's not able to connect to MN.
CN1 stuck at State:NmtCsPreOperational2. Log from MN is attached.
If I try to connect only CN32 (iMX) everything works fine.
I will find a way to exclude virtual machine from tests.
Thanks for sharing the log. You can check by increasing the PResTimeout for CN1 to a 15ms value (typically this is sufficient for a virtual machine environment). The error you see on the log HistoryEntry: Type=0x3002 Code=0x8243 (0x01 55 00 00 00 00 00 00) indicates loss of Poll Response from CN1 i.e. its response is not reaching MN within the configured time.
Thank you very, very much for the explanation! I really appreciate it!
I'm not familiar with the configuration and configuration tools yet.
Is PResTimeout configuration of MN or both sides? I suppose it's configurable via configuration tool and cdc file.
Best regards,
Ivan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The PResTimeout is part of the network configuration i.e. mnobd.cdc file which is provided as input to the demo_mn_console application (with the -c switch). In case this file is not specified explicitly, the application takes the default mnobd.cdc file in the same directory.
To modify the network configuration parameters, you have to use openConfigurator tool to create a new configuration. There are a couple of default network configuration projects provided along with the openPowerlink_V2 stack, in the apps/commom/openConfigurator_projects directory. From the openConfigurator tool you can import the Demo_3CN project and update network configuration. The latest version of the tool is an Eclipse based plugin, so the workflow is similar to a CDT or JDT.
If you need any help in this, let me know.
For quickly testing out your network, I generated and attached a CDC file with CN1 having 20ms PResTimeout. Please copy this to the demo_mn_console application directory and check if this works for both the CNs, otherwise let me know.
Thank you so much for your help!
Everything works fine with your mnobd.cdc file. Both Console and Qt MN are able to connect and communicate with CNs.
Off topic:
You mentioned that default MN and CN demos use Linux TUN/TAP (PCAP lib) driver for accessing the network which has a higher system latency.
I followed the instructions here: http://openpowerlink.sourceforge.net/doc/2.2/2.2.0/dc/d8f/page_build_drivers.html
I suppose the Linux Edrv Kernel Driver is the "faster" way to access the network.
Is there any information/examples how use it and how to build an application?
Have a great weekend!
Best regards,
Ivan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, you are right, using the Edrv kernel drivers will reduce the latency and you can go for lower cycle time. Since in this mode, the stack uses dedicated network drivers, it needs NIC support. Currently, the driver support is added for the 6 NICs, listed in the guide you have shared; the emacps is for Zynq and the other 5 are NICs from Intel and Realtek. You can use the same guide to build the drivers but first do check that you have the right NIC or MAC.
If you need any help in this, drop me a message.
Good evening everyone,
Last days I was trying to build openPOWERLINK stack and demos. Now everything is up and running and I've created the following test set-up:
openPOWERLINK v.2.7.1
MN - PC, Ubuntu 18.04, Native installation, running demo_mn_console or demo_mn_qt
CN1 - PC, Ubuntu 18.04, Virtual machine, running demo_cn_console
CN32 - iMX6 computer on module, Embedded Linux, running demo_cn_console
All node are running with default openPOWERLINK demo configuration.
All devices are connected in their own separate network segment to avoid external traffic.
If MN is connected to single CN, doesn't matter which one, everything works fine - node is detected and proper information about inputs and outputs is displayed.
Once second CN is connected, all data transfer is corrupted. Both CNs loses connection to MN and negotiation between MN and CNs becomes endless. Successful connection and disconnection looks totally random. Once one of the CNs is shut down, the other one establishes connection immediately and everything backs to normal.
Does anybody faced such issue? I will try to capture logs from all devices and post it here.
Have a great evening!
Best regards,
Ivan
Hi Ivan,
From your description of the problem it might be a cycle time performance problem which can be solved by increasing the PResTimeout and cycle time of the CNs and network, respectively; but console logs and a network trace will help in narrowing it down.
Fyi, the default MN and CN demos use Linux TUN/TAP (PCAP lib) driver for accessing the network which has a higher system latency and thus higher response times. A virtual CN app has even further latency than native applications. Btw, for iMX6, are you using the distro from NXP ?
Best Regards,
#aeicoriiotteam
Last edit: AEICOR IIoT Team 2020-12-10
Hello,
Thank you very much for your quick response!
Currently I am using default cycle time. It looks like ~50ms, based on Wireshark trace and time between SoA/SoC frames.
For iMX6 - computer on module is based on NXP iMX6, it's running Torizon Linux. I've cross-compiled openPOWERLINK stack and CN console demo for it.
I will capture detailed logs tomorrow morning - network log from MN and console logs from all applications.
Best regards,
Ivan
Hi Ivan,
Thanks for the info. Yes, the logs would be helpful.
The default cycle time of 50ms should be good enough for 2 CNs.
For the next run, while capturing logs and traces, please try with >10ms Pollsresponse timeout, if feasible.
update: just an fyi, when you build the demo CN applications, you have to change the node id in the main file for each CN.
Best Regards,
#aeicoriiotteam
Last edit: AEICOR IIoT Team 2020-12-11
Good morning,
Looks like there are timing issue with CN1 (Virtual machine). Now it's not able to connect to MN.
CN1 stuck at State:NmtCsPreOperational2. Log from MN is attached.
If I try to connect only CN32 (iMX) everything works fine.
I will find a way to exclude virtual machine from tests.
Best regards,
Ivan
Hi Ivan,
Thanks for sharing the log. You can check by increasing the PResTimeout for CN1 to a 15ms value (typically this is sufficient for a virtual machine environment). The error you see on the log
HistoryEntry: Type=0x3002 Code=0x8243 (0x01 55 00 00 00 00 00 00)indicates loss of Poll Response from CN1 i.e. its response is not reaching MN within the configured time.Best Regards,
#aeicoriiotteam
Hi,
Thank you very, very much for the explanation! I really appreciate it!
I'm not familiar with the configuration and configuration tools yet.
Is PResTimeout configuration of MN or both sides? I suppose it's configurable via configuration tool and cdc file.
Best regards,
Ivan
Hi Ivan,
The PResTimeout is part of the network configuration i.e. mnobd.cdc file which is provided as input to the demo_mn_console application (with the -c switch). In case this file is not specified explicitly, the application takes the default mnobd.cdc file in the same directory.
To modify the network configuration parameters, you have to use openConfigurator tool to create a new configuration. There are a couple of default network configuration projects provided along with the
openPowerlink_V2stack, in theapps/commom/openConfigurator_projectsdirectory. From the openConfigurator tool you can import theDemo_3CNproject and update network configuration. The latest version of the tool is an Eclipse based plugin, so the workflow is similar to a CDT or JDT.If you need any help in this, let me know.
For quickly testing out your network, I generated and attached a CDC file with CN1 having 20ms PResTimeout. Please copy this to the
demo_mn_consoleapplication directory and check if this works for both the CNs, otherwise let me know.Best Regards,
#aeicoriiotteam
Last edit: AEICOR IIoT Team 2020-12-11
Hi,
Thank you so much for your help!
Everything works fine with your mnobd.cdc file. Both Console and Qt MN are able to connect and communicate with CNs.
Off topic:
You mentioned that default MN and CN demos use Linux TUN/TAP (PCAP lib) driver for accessing the network which has a higher system latency.
I followed the instructions here:
http://openpowerlink.sourceforge.net/doc/2.2/2.2.0/dc/d8f/page_build_drivers.html
I suppose the Linux Edrv Kernel Driver is the "faster" way to access the network.
Is there any information/examples how use it and how to build an application?
Have a great weekend!
Best regards,
Ivan
Hi Ivan,
Glad that it helped.
Yes, you are right, using the Edrv kernel drivers will reduce the latency and you can go for lower cycle time. Since in this mode, the stack uses dedicated network drivers, it needs NIC support. Currently, the driver support is added for the 6 NICs, listed in the guide you have shared; the emacps is for Zynq and the other 5 are NICs from Intel and Realtek. You can use the same guide to build the drivers but first do check that you have the right NIC or MAC.
If you need any help in this, drop me a message.
Best Regards,
#aeicoriiotteam
Hi,
Thank you very much for for your support and the clarification.
I'm pretty new in Linux development and it will be a really good exercise for me to build and set-up application with Edrv kernel drivers.
Best regards,
Ivan
Hi Ivan,
Glad to assist :)
Best Regards,
#aeicoriiotteam