I'm trying to port Powerlink on the Arduino Mega 2560, configuring it as a CN and I got some basic functionalities but I have difficulties to get working the SDO management or the CFM management.
In case of SDO and CFM manually disabled on my MN with CN correctly configured I got the basic functionality of the protocol (run the demo where a pushbutton\led on the Arduino is read\driven).
There are obviously hard limitations on the cycle length.
To get SDO management working Is it correct to set EPL_USE_SHAREDBUFF = FALSE on the CN?
I got trouble on establish the SDO Client-Server connection during the asynchronous phase.
Any help is appreciated.
Thanks for your enthusiasm towards POWERLINK.
The following configuration is not used by the SDO and CFM modules of stack so we will suggest you not to alter this configuration.
EPL_USE_SHAREDBUFF = FALSE
From your post, I assume you are using a NON-OS environment for CN and ported the required hardware drivers such as ethernet, timer etc. for Arduino Mega 2560.
Can you give some more details of your port such as version of openPOWERLINK stack or CNDK?
Also what MN did you use for your test? Did you see any error logs?
Can you share the configuration file used on CN for your setup (Eplcfg.h), also share any logs which you get on MN and CN sides as well as any network traces if it is possible. It will help us to understand the problem more precisely.
Just for clarification: Like mentioned in the previous post, you should leave the EPL_USE_SHAREDBUFF commented like in the original sources, which means it should not be defined as FALSE:
//#define EPL_USE_SHAREDBUFF FALSE
Setting it to FALSE can have a negative influence on the SDO processing.
thanks for the quick reply.
Yes you're right, I'm using NO-OS on my Arduino Board and I had to modify the ethernet driver in order to communicate with MN.
The starting point for me were the sources from openPOWERLINK-V1.08.2.
For what concerning the MN I tried to used both demo_mn_console and demo_mn_qt, compiled on a Ubuntu-box.
In both cases, considering that I was not able to generate a new xdd file with OpenConfigurator for my current configuration, I modified directly the Cycle Time in the hex file (cycle time = 500ms), not an elegant solution, I know.
At first I validated that configuration connecting the MN (with my new xdd configuration) with another Ubuntu_based PC where the demo_cn_console was running. In that case the SDO configuration by MN and the subsequent PDO exchange worked successfully.
In the next step I tried to connect the MN with the Arduino_CN, disabling the SDO\CFM configuration on the MN by modification of the original code.
In that case I was able to drive a led and to read a pushbutton on the Arduino board.
The last step was to enhance the Arduino piece of sw adding the SDO support: in that case I had no luck.
The SDO connection phase doesn't result in success. After the async message sent by the CN with rcon=1 and scon=1 the MN closes the session and requests a CN to reboot.
Regarding the key EPL_USE_SHAREDBUFF on the CN configuration file maybe I didn't explained well: I followed the suggestion in SW Manual pg.83, in case of no FIFO makes direct call.
In fact considering that my CN has no OS and very low performances I thought it was an acceptable solution.
Till this evening I'm not able to repeat some more tests and give you the error traces and also the pcap captured log.
In attach you can find the Eplcfg.h I used to configure my Arduino CN.
I have attacched a zip folder containing .cap log and console error log.
The test consists in booting the CN and then boot up the MN.
I've repeated the test with both MN_console and MN_Qt.
After going through the traces and logs provided by you, we feel that your CN implementation is not able to handle SDO communication along with the stack general tasks.
As a first point we will advice you to remove any debugging traces on CN if they are present to avoid any delays resulting from them. We can see that the stack debug level is low but still make sure that any other unwanted traces a avoided.
Second, whether it is possible to analyze the execution time for certain routines on the your CN using GPIOs? This will help you to understand the affect of enabling SDO communication.
You can refer to the BENCHMARK implementation for Non-OS systems already available in stack to design some similar debugging mechanism for your platform which will help in easy analysis.
Please let us know if you make any progress.