While simoultaneously trying to solve the problem presented in the topic (https://sourceforge.net/p/openpowerlink/discussion/newbie/thread/1d6013f8/) I have also tried to implement the Cross Traffic communication network using the openCONFIGURATOR project that Christoph Ruecker had uploaded in the mentioned topic.
The steps that I have followed in order to check if the communication between CN1 and CN32 is working are the following:
I have changed the ID's of the nodes (1→1 and 2 → 32) of the openCONFIGURATOR project in order to being able to use the code that is already writen in the demo_xx_console apps.
Replaced the new xap.h in the folder demo_mn_console/src and the new mnobd.cdc in the folder demo_mn_console/build/linux.
In both common nodes src, in the app.c files, I have added the following lines of code, with a view to have a visual interface through the console:
tOplkError processSync(void)
{
tOplkError ret = kErrorOk;
if (oplk_waitSyncEvent(100000) != kErrorOk)
return ret;
ret = oplk_exchangeProcessImageOut();
if (ret != kErrorOk)
return ret;
/ read input image - digital outputs /
digitalOut_g = pProcessImageOut_l->digitalOut; printf("PDO received from the slave: %i\n",pProcessImageOut_l->digitalOut);
/ setup output image - digital inputs /
pProcessImageIn_l->digitalIn = digitalIn_g;
printf("PDO sent to the slave: %i\n",pProcessImageIn_l->digitalIn);
ret = oplk_exchangeProcessImageIn();
return ret;
}
4. I have rebuilt the app of all my nodes.
The programs seem to run correctly, but unfortunately I am not being able to watch one the receiving nodes what supposedly was sent by the sending nodes. I attach an image of what I am looking on my VM's in order to be more clear.
I guess the reason is because for Linux CN libraries the cross traffic is not enabled by default, thus the cross traffic (PRes frame) gets dropped in the kernel layer and never reaches your application.
I assume that you are using the liboplkcn Linux library for your CNs, so you need to set the PRes filter count in stack/proj/linux/liboplkcn/oplkcfg.h. If for example you want to receive cross traffic from 3 different nodes, the following line needs to be added to oplkcfg.h:
#define CONFIG_DLL_PRES_FILTER_COUNT 3
Hope that solves the issue...
Best regards,
Joerg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to what I have understood, the following steps were followed:
Of course that in my MN I have replaced the new xap.h in the folder demo_mn_console/src and the new mnobd.cdc in the folder demo_mn_console/build/linux – please find attached the openCONFIGURATOR project that is being used.
Only in my two CN's, I have modified the file stack/proj/linux/liboplkcn/oplkcfg.h by adding to it the line “#define CONFIG_DLL_PRES_FILTER_COUNT 2”.
Afterwards, I have rebuilt the stacks libraries and the app again.
The obtained results are still undesired owing to the fact that I am not managing to receive data on my CN's.
Please find also attached the EPL traffic obtain in Wireshark. Evindently, now asynchronous data now in being inyected into the network, which (please, correct me if I am wrong) indicate that somehow some cross traffic communication if being held.
there might be a misunderstanding of cross traffic... With cross traffic it is ment that a node sends a PRes frame to the network and every other node interested can read the data. Please refer to the following link: http://openpowerlink.sourceforge.net/web/POWERLINK/PDO.html
In the Wireshark trace the PRes frames from CN1 and CN32 have no process data (note that Size = 0 and Ready = 0), because configuration is not completed.
Comment to 2) If you use the "Linux Userspace Daemon", you need to set CONFIG_DLL_PRES_FILTER_COUNT in the kernel and user layer library's oplkcfg.h. Kernel: stack/proj/linux/liboplkcndrv-pcap/oplkcfg.h User: stack/proj/linux/liboplkcnapp-userintf/oplkcfg.h
Another point: I would suggest that you move the printfs you added to to printOutputs(), instead of processSync(). The printOutputs() function is called if you press 'p', instead of filling the console with printfs called in processSync().
You're welcome!
Best regadrs,
Joerg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, as I'm using the "Linux Userspace Daemon", I have done what you suggested in #2: instead of setting CONFIG_DLL_PRES_FILTER_COUNT in stack/proj/linux/liboplkcn/oplkcfg.h, I set it in the kernel and user layer library's oplkcfg.h. Then, I have rebuilt the stacks, drivers and apps.
However I still can't manage to realise what am I doing wrong in the configuration. As there as almost no examples of how to configure CrossTraffic with openCONFIGURATOR I have used an example which was provided in other discussion.
The changes that were done to this project have been:
I have changed the ID's of then second common nodes (2 → 32) of the openCONFIGURATOR project in order to being able to use the code that is already writen in the demo_xx_console apps.
In Node 1, the RPDO#0 now is received from Node 32
-I have increased the response timeouts for your CNs so that they can responde to the used platform.
Of course that afterwards I have rebuilt the app.
I attach the project from were I started I the one that I am using currently just to show that there seem to be everything okay and the undesired traffic captures.
Another question, is there any function that shall be called in order to send a PollRes from a CN? Or the processSync() function makes so if the configuration is done properly?
in the Wireshark trace you can see an SDO abort because the Object 0x1F81 does not exist on the CN, therefore configuration can never complete. Which openPOWERLINK version do you use?
The function processSync() is where you read the input process data, do some PLC stuff and write the output process data. The kernel layer (dllk, ...) does the magic so that the PRes frame hits the network with the process data (depending on NMT states), but only if the configuration completes!
Best regards,
Joerg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the object exists in the xdd, but it does not exist on the CN(s). There is no guarantee if the object exists in the xdd that it also exists on the node. You need to ensure that the object is compiled into the CN. For example the 0x1F81 object is guarded with #if NMT_MAX_NODE_ID > 0 refer to objdict.h!
So, it seems to me that the changes done in oplkcfg.h did not propagate to the compiled library, which is linked to the application. It could be that you only recompiled the debug library, but your application is compiled in release and thus links against the release library - which hasn't been recompiled... Or any other combination, that refuses to compile the needed objects into the library.
The meaning of 0x1F81 can be found in the POWERLINK specification EPSG DS 301.
Best regards,
Joerg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please, I'd like to be sure that I am exporting correctly the output of the openCONFIGURATOR to the MN's app.
What I always do is copying the xap.h in apps/demo_mn_console/src and the mnobd.cdc in apps/demo_mn_console/build/linux, and the I rebuild the app.
May there be a problem in the way I import the output of the openCONFIGURATOR?
If this is being done correctly (please, confirm so) let's focus in the CN's.
When I made those changes in oplkcfg.h, I made a new openPOWERLINK stack I recompiled release and debug library, drivers and application entirely from the begining.
I wonder if you explain me a little deeper how can I ensure that the object is compiled into the CN.
In which file should be written that condicional compilation " #if NMT_MAX_NODE_ID > 0 ... refer to objdict.h "?
Once again, lots of thanks for your help :)
Kind regards,
Juan Ignacio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the mnobd.cdc is copied from the selected openCONFIGURATOR project (apps/common/openCONFIGURATOR_projects/Demo_3CN/output/mnobd.cdc) when you rebuild the app, so copying to the build directory is not necessary. However, shouldn't be an issue there.
I asked the POWERLINK Team from Kalycito to help you with this issue. They will reply in a couple of days..
Best regards,
Joerg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So there might be a problem, isn't it? Because I thought that copying the xap.h in apps/demo_mn_console/src and the mnobd.cdc in apps/demo_mn_console/build/linux was enough for reasinging a new openCONFIGURATOR project.
I have tried by adding a new openCONFIGURATOR project to the folder apps/common/openCONFIGURATOR_projects. Nevertheless, when I try to compile the app, the new project doesn't appear in the cmake. It is as if the compiler doesn't manage to recognise the new openCONFIGURATOR project.
Kind regards,
Juan Ignacio
Last edit: Juan Ignacio Troisi 2016-11-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We tried with linux PCs as MNs and CNs, still the cross traffic is not working, across the CNs, with the CDC given by you.
We will check against 2.4.1 some standard CDCs to validate the environment first and then migrate to the CDC mentioned by Juan. This will help us in isolating the problem.
Regards,
Powerlink-Team-Kalycito.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What I need is a MN and two CN's, and cross traffic communication should be possible between this two common nodes. Do you have any openCONFIGURATOR project where this communication is accomplished correctly? If so, would you mind send it to me so that I don't keep stacked in my development?
Kind regards,
Juan Ignacio
Last edit: Juan Ignacio Troisi 2016-11-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you very much for your help, that would help me a lot. Please, take into consideration that not only the cross traffic communication should be accomplished, but also the communication between MN and CN's should still be possible. You can call de CN's CN1 and CN32, so that I keep on using the common nodes that have used in former implementations.
Kind regards,
Juan Ignacio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to what I can see in Wireshark, the attached sequences are being sent and the powerlink sequence is respected.
My next step would be checking if I am able to implement the cross traffic communication.
Is there any function that shall be called in order to send a PollRes from a CN? I mean, so that the PRes frame hits the network with the process data. Where shall this function be called?
I have managed to prove cross traffic communication and I could communicate CN32 directly with CN1 with the project that you gave me.
What I have tried to do afterwards was just to modifiy the openCONFIGURATOR project so that CN1 could also send information to CN32. Then, the only modification that was done consisted of, in CN1 making RPDO#1 pointing to CN32. However, the same error appears again: the PRes of CN32 seem to have no size.
Is there a bug with the openCONFIGURATOR? How did you manage to solve these problems?
Attached: the slightly modified openCONGIFURATOR project and the wireshark trace.
This is no issue within openCONFIGURATOR. Within your trace you can see that Node 32 does not reach an operational state because the during configuration the write on object 0x1F81 / 0x01 fails. In the post from 21.11.2016 Jörg explained that you have to enable this object in the OD of the CNs. Probably you have missed that on the CN 32 in your second VM. Please check the trace afterwards if both CNs are reaching the operational state (NMT_Status within PRes is "NMT_CS_OPERATIONAL").
br
Christoph
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In fact, was Joerg mentioned on the 16.11.2016 days ago was done in both common nodes: setting "CONFIG_DLL_PRES_FILTER_COUNT 2" in the kernel and user layer library's oplkcfg.h.
To sum up,
Kernel: stack/proj/linux/liboplkcndrv-pcap/oplkcfg.h
User: stack/proj/linux/liboplkcnapp-userintf/oplkcfg.h
I didn't understand what he meant on the post of the 21.11.2016 and when I asked him again he redirected me to Kalycito. I would really appreaciate it if you can give me some more information about how to accomplish was Joerg mentioned that day.
BTW, I have managed to prove cross traffic communication and I could communicate CN32 directly with CN1 with the project that Kalycito gave me on 30.11.2016. This problems appear when I try to enable CT communication in the other direction, from CN1 -> CN32.
Thank you very much for your time.
Kind regards,
Juan Ignacio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have already realized that there was a problem with the libraries that I was compiling, their names are quite similar. Now the cross traffic communication seems to work well.
Thank you very much to everyone for your help!
Kind regards,
Juan Ignacio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello community,
While simoultaneously trying to solve the problem presented in the topic (https://sourceforge.net/p/openpowerlink/discussion/newbie/thread/1d6013f8/) I have also tried to implement the Cross Traffic communication network using the openCONFIGURATOR project that Christoph Ruecker had uploaded in the mentioned topic.
The steps that I have followed in order to check if the communication between CN1 and CN32 is working are the following:
tOplkError processSync(void)
{
tOplkError ret = kErrorOk;
if (oplk_waitSyncEvent(100000) != kErrorOk)
return ret;
ret = oplk_exchangeProcessImageOut();
if (ret != kErrorOk)
return ret;
/ read input image - digital outputs /
digitalOut_g = pProcessImageOut_l->digitalOut;
printf("PDO received from the slave: %i\n",pProcessImageOut_l->digitalOut);
/ setup output image - digital inputs /
pProcessImageIn_l->digitalIn = digitalIn_g;
printf("PDO sent to the slave: %i\n",pProcessImageIn_l->digitalIn);
ret = oplk_exchangeProcessImageIn();
return ret;
}
4. I have rebuilt the app of all my nodes.
The programs seem to run correctly, but unfortunately I am not being able to watch one the receiving nodes what supposedly was sent by the sending nodes. I attach an image of what I am looking on my VM's in order to be more clear.
Does any know what may I be doing wrong?
Thank you very much for your help,
Juan Ignacio
Last edit: Juan Ignacio Troisi 2016-11-10
Can please someone help me with this problem?
Hello Juan,
I guess the reason is because for Linux CN libraries the cross traffic is not enabled by default, thus the cross traffic (PRes frame) gets dropped in the kernel layer and never reaches your application.
I assume that you are using the liboplkcn Linux library for your CNs, so you need to set the PRes filter count in stack/proj/linux/liboplkcn/oplkcfg.h. If for example you want to receive cross traffic from 3 different nodes, the following line needs to be added to oplkcfg.h:
Hope that solves the issue...
Best regards,
Joerg
Hello Joerg,
I really appreciate your answer.
According to what I have understood, the following steps were followed:
The obtained results are still undesired owing to the fact that I am not managing to receive data on my CN's.
Please find also attached the EPL traffic obtain in Wireshark. Evindently, now asynchronous data now in being inyected into the network, which (please, correct me if I am wrong) indicate that somehow some cross traffic communication if being held.
Once again, thank you very much for your help.
Kind regards,
Juan Ignacio
Last edit: Juan Ignacio Troisi 2016-11-16
Hello Juan,
there might be a misunderstanding of cross traffic... With cross traffic it is ment that a node sends a PRes frame to the network and every other node interested can read the data. Please refer to the following link: http://openpowerlink.sourceforge.net/web/POWERLINK/PDO.html
In the Wireshark trace the PRes frames from CN1 and CN32 have no process data (note that Size = 0 and Ready = 0), because configuration is not completed.
Comment to 2) If you use the "Linux Userspace Daemon", you need to set CONFIG_DLL_PRES_FILTER_COUNT in the kernel and user layer library's oplkcfg.h.
Kernel: stack/proj/linux/liboplkcndrv-pcap/oplkcfg.h
User: stack/proj/linux/liboplkcnapp-userintf/oplkcfg.h
Another point: I would suggest that you move the printfs you added to to printOutputs(), instead of processSync(). The printOutputs() function is called if you press 'p', instead of filling the console with printfs called in processSync().
You're welcome!
Best regadrs,
Joerg
Dear Joerg,
So, as I'm using the "Linux Userspace Daemon", I have done what you suggested in #2: instead of setting CONFIG_DLL_PRES_FILTER_COUNT in stack/proj/linux/liboplkcn/oplkcfg.h, I set it in the kernel and user layer library's oplkcfg.h. Then, I have rebuilt the stacks, drivers and apps.
However I still can't manage to realise what am I doing wrong in the configuration. As there as almost no examples of how to configure CrossTraffic with openCONFIGURATOR I have used an example which was provided in other discussion.
The changes that were done to this project have been:
-I have increased the response timeouts for your CNs so that they can responde to the used platform.
Of course that afterwards I have rebuilt the app.
I attach the project from were I started I the one that I am using currently just to show that there seem to be everything okay and the undesired traffic captures.
Another question, is there any function that shall be called in order to send a PollRes from a CN? Or the processSync() function makes so if the configuration is done properly?
thank you very much for your help.
Kind regards,
Juan Ignacio
Last edit: Juan Ignacio Troisi 2016-11-17
Hello Juan,
in the Wireshark trace you can see an SDO abort because the Object 0x1F81 does not exist on the CN, therefore configuration can never complete. Which openPOWERLINK version do you use?
The function processSync() is where you read the input process data, do some PLC stuff and write the output process data. The kernel layer (dllk, ...) does the magic so that the PRes frame hits the network with the process data (depending on NMT states), but only if the configuration completes!
Best regards,
Joerg
Dear Joerg,
I am using the 2.4.1 vesion of openPOWERLINK.
I am not managing to understand what am I doing wrong in the configuration.
In my openCONFIGURATOR project, when I go the the NMT_NodeAssignment_AU32 on each of my CN's, the following configuration is set up:
CN (1) -> NMT_NodeAssignment_AU32 -> NodeAssignment (0x01) -> empty actual value
CN (1) -> NMT_NodeAssignment_AU32 -> NodeAssignment (0x20) -> actual value: 0x80000007
CN (32) -> NMT_NodeAssignment_AU32 -> NodeAssignment (0x01) -> actual value: 0x80000007
CN (32) -> NMT_NodeAssignment_AU32 -> NodeAssignment (0x20) -> empty actual value
So, aparently the Object 0x1F81 exists in any CN.
Why then in the Wireshark trace appears as if there is no Object 0x1F81?
What is a typical value for CN NMT_NodeAssignment_AU32 -> NodeAssignment (0x01) -> actual value?
Maybe it is a very newbie question, but why the value 0x80000007 was assigned in the example?
Kind regards,
Juan Ignacio
Hello Juan,
the object exists in the xdd, but it does not exist on the CN(s). There is no guarantee if the object exists in the xdd that it also exists on the node. You need to ensure that the object is compiled into the CN. For example the 0x1F81 object is guarded with
#if NMT_MAX_NODE_ID > 0refer to objdict.h!So, it seems to me that the changes done in oplkcfg.h did not propagate to the compiled library, which is linked to the application. It could be that you only recompiled the debug library, but your application is compiled in release and thus links against the release library - which hasn't been recompiled... Or any other combination, that refuses to compile the needed objects into the library.
The meaning of 0x1F81 can be found in the POWERLINK specification EPSG DS 301.
Best regards,
Joerg
Dear Joerg,
Thank you very much for your answer.
Please, I'd like to be sure that I am exporting correctly the output of the openCONFIGURATOR to the MN's app.
What I always do is copying the xap.h in apps/demo_mn_console/src and the mnobd.cdc in apps/demo_mn_console/build/linux, and the I rebuild the app.
May there be a problem in the way I import the output of the openCONFIGURATOR?
If this is being done correctly (please, confirm so) let's focus in the CN's.
When I made those changes in oplkcfg.h, I made a new openPOWERLINK stack I recompiled release and debug library, drivers and application entirely from the begining.
I wonder if you explain me a little deeper how can I ensure that the object is compiled into the CN.
In which file should be written that condicional compilation " #if NMT_MAX_NODE_ID > 0 ... refer to objdict.h "?
Once again, lots of thanks for your help :)
Kind regards,
Juan Ignacio
Hello Juan,
the mnobd.cdc is copied from the selected openCONFIGURATOR project (apps/common/openCONFIGURATOR_projects/Demo_3CN/output/mnobd.cdc) when you rebuild the app, so copying to the build directory is not necessary. However, shouldn't be an issue there.
I asked the POWERLINK Team from Kalycito to help you with this issue. They will reply in a couple of days..
Best regards,
Joerg
Dear Joerg,
So there might be a problem, isn't it? Because I thought that copying the xap.h in apps/demo_mn_console/src and the mnobd.cdc in apps/demo_mn_console/build/linux was enough for reasinging a new openCONFIGURATOR project.
I have tried by adding a new openCONFIGURATOR project to the folder apps/common/openCONFIGURATOR_projects. Nevertheless, when I try to compile the app, the new project doesn't appear in the cmake. It is as if the compiler doesn't manage to recognise the new openCONFIGURATOR project.
Kind regards,
Juan Ignacio
Last edit: Juan Ignacio Troisi 2016-11-28
Hello Juan,
We tried with linux PCs as MNs and CNs, still the cross traffic is not working, across the CNs, with the CDC given by you.
We will check against 2.4.1 some standard CDCs to validate the environment first and then migrate to the CDC mentioned by Juan. This will help us in isolating the problem.
Regards,
Powerlink-Team-Kalycito.
Hello Powerlink-team Kalycito,
What I need is a MN and two CN's, and cross traffic communication should be possible between this two common nodes. Do you have any openCONFIGURATOR project where this communication is accomplished correctly? If so, would you mind send it to me so that I don't keep stacked in my development?
Kind regards,
Juan Ignacio
Last edit: Juan Ignacio Troisi 2016-11-28
The issue you faced is reproducible. We will give a openCONFIGURATOR project to you, where the cross traffic communication is accomplished.
Hello Powerlink-team Kalycito,
Thank you very much for your help, that would help me a lot. Please, take into consideration that not only the cross traffic communication should be accomplished, but also the communication between MN and CN's should still be possible. You can call de CN's CN1 and CN32, so that I keep on using the common nodes that have used in former implementations.
Kind regards,
Juan Ignacio
Please don't forget to send me the project.
Kind regards,
Juan Ignacio
Hello Juan,
We made some modifications, to get it working for you.
The changed files are attached for your use/reference.
Best Regards,
Powerlink-team Kalycito
Attachments again.
Hello Powerlink-team Kalycito,
Thank you very much for the project, I will try to make it work now.
Regarding point number 4, the CONFIG_DLL_PRES_FILTER_COUNT should only be set on the CN's, isn't it?
Kind regards,
Juan Ignacio
Hello Powerlink-team Kalycito,
apparently the communication works correctly.
According to what I can see in Wireshark, the attached sequences are being sent and the powerlink sequence is respected.
My next step would be checking if I am able to implement the cross traffic communication.
Is there any function that shall be called in order to send a PollRes from a CN? I mean, so that the PRes frame hits the network with the process data. Where shall this function be called?
Kind regards,
Juan Ignacio
Last edit: Juan Ignacio Troisi 2016-11-30
Hello Powerlink-team Kalycito,
I have managed to prove cross traffic communication and I could communicate CN32 directly with CN1 with the project that you gave me.
What I have tried to do afterwards was just to modifiy the openCONFIGURATOR project so that CN1 could also send information to CN32. Then, the only modification that was done consisted of, in CN1 making RPDO#1 pointing to CN32. However, the same error appears again: the PRes of CN32 seem to have no size.
Is there a bug with the openCONFIGURATOR? How did you manage to solve these problems?
Attached: the slightly modified openCONGIFURATOR project and the wireshark trace.
Kind regards,
Juan Ignacio
Last edit: Juan Ignacio Troisi 2016-12-01
Hello Juan,
This is no issue within openCONFIGURATOR. Within your trace you can see that Node 32 does not reach an operational state because the during configuration the write on object 0x1F81 / 0x01 fails. In the post from 21.11.2016 Jörg explained that you have to enable this object in the OD of the CNs. Probably you have missed that on the CN 32 in your second VM. Please check the trace afterwards if both CNs are reaching the operational state (NMT_Status within PRes is "NMT_CS_OPERATIONAL").
br
Christoph
Hello Christoph,
In fact, was Joerg mentioned on the 16.11.2016 days ago was done in both common nodes: setting "CONFIG_DLL_PRES_FILTER_COUNT 2" in the kernel and user layer library's oplkcfg.h.
To sum up,
Kernel: stack/proj/linux/liboplkcndrv-pcap/oplkcfg.h
User: stack/proj/linux/liboplkcnapp-userintf/oplkcfg.h
I didn't understand what he meant on the post of the 21.11.2016 and when I asked him again he redirected me to Kalycito. I would really appreaciate it if you can give me some more information about how to accomplish was Joerg mentioned that day.
BTW, I have managed to prove cross traffic communication and I could communicate CN32 directly with CN1 with the project that Kalycito gave me on 30.11.2016. This problems appear when I try to enable CT communication in the other direction, from CN1 -> CN32.
Thank you very much for your time.
Kind regards,
Juan Ignacio
Hello,
I have already realized that there was a problem with the libraries that I was compiling, their names are quite similar. Now the cross traffic communication seems to work well.
Thank you very much to everyone for your help!
Kind regards,
Juan Ignacio