I encountered a problem during PDO exchange with an heavy powerlink configuration (3Cn)
I have attached xap.h and xap.xml which describe the powerlink bus.
On CN3, modules beyond a certain PIOffset are no longer reachable if I use directly PI_OUT/PI_IN struct.
If I change padding PADDING_VAR_27:24 to PADDING_VAR_27:8 in xap.h, the X20DIF371 start to works properly, but I'm unable to read AbsPos01ActVal and motors status...
It seems to have a conflict with the module offset.
If I use a specific cdc with only CN3, all works fine.
Something is wrong when the PIOffset goes beyond 0x00fc...
Have you encountered this kind of problem ?
Thanks,
Romain Naour
PS: I use an Epl stack based on v1.8.2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had a look into your xap.h and xap.xml and It looks like you are using xap.h. Am I right?
The xap.h looks fine and could you provide me some more details like mnobd.txt or the openCONF project.
1) Have you cross checked in the wireshark PRes packets for the CN 3 ?
2) Is the status of the motor/ the PI variable is present in its specific offset in the wireshark packet ?
I use both xap.h for testing/debug and xap.xml with Straton runtime for Linux [1]
The problem was reported to me by a coworker this Friday and reproduced with Straton and a C program.
I'm agree with you, the xap.h seems to be Ok, I don't think it's an openConfigurator's problem. (tested with 1.2.2 and 1.3.0)
I need to continue investigations on powerlink stack side with wireshark.
So, I'll send you the mnodb.txt and traces as soon as possible.
Note: I use the powerlink kernel stack with powerlink82573 driver and linux kernel 3.2.38-rt.
It seems to be Ok.
I get 37 06 for CN3_M01_X20SM1436_MpGenStatus01 and CN3_M02_X20SM1436_MpGenStatus01
and 03 80 for CN3_M03_X20DIF371_DigitalInputxx (Input 1,2,16 are ON)
I also checked the files and I see that the TPDO definition of CN 3 is correctly describing 64 bits. On the MN side now the process image should be 32 bit aligned, thus leading to the 24 bit offset in the xap.h / xap.xml.
But the RPDO definition is incorrect. The Rx mapping in line 226 is okay, but the lines 227 and 228 should not be there. In line 229 a 32 bit value is correctly mapped to the next 32 bit-aligned field which is described by subindex 0x40 of 0xA640. Only the value from the PDO must be taken from offset 0x0008 bit and not from 0x0018 bit:
I made a wrong calculation when checking the CDC file. The file and its mapping should be correct, BUT...
Your finding that the trouble starts at offset 0x00fc gave a hint: This number (252) corresponds exactly to the number of available sub-indexes for the PI objects defined in the openPOWERLINK stack!
And here comes the problem:
The mapping entry of CN3_M01_X20SM1436_NetworkStatus is on 0xA4C0/F9, thus PI offset 248 (0xF9 - 1, because we start at sub-index 1). The next entry is an UNSIGNED32 and therefore 32 bit aligned (starting at PI offset 252 and not offset 249). This is followed by an UNSIGNED16 value starting at PI offset 256. So far, so good.
Now, the next mapping entry is an UNSIGNED8. Therefore, it will be placed at PI offset 258. But here, openCONFIGURATOR makes a mistake:
It calculates internally as if all theoretically available sub-indexes of object 0xA4C0 can be used. That means it calculates (258 % 254) + 1 which gives sub-index 5. But in the openPOWERLINK stack it is defined that only sub-indexes up to 252 shall be used, thus leading to (258 % 252) + 1 which gives sub-index 7.
I did a test using your changes, but it seems to have another problem.
I noticed strange behavior durring test, all output are turned ON durring cdc loading.
There are two extra bytes (00) between CN3_M01_X20SM1436_NetworkStatus and CN3_M01_X20SM1436_AbsPos01ActVal
since the sub-index changes.
To avoid errors during manual changes to the mnobd.txt,
I compiled openConfigurator under Linux in order to modify the calculation of sub-indexes.
I changed 254 by 252 for the calculation of sub-indexes (PIOperations.cpp and ProcessImage.cpp)
It looks correct for me!
The explanation is the alignment of 16 bit variables to 16 bit boundaries and 32 bit variables to 32 bit boundaries in the process image. Therefore, the process image is larger than the data transmitted on the wire.
Using your given readings from above and taking in account the process image alignment, CN3 modules start at the offset 0x00F6 in the process image which is located at a 16 bit, but not at a 32 bit boundary. This will give the following picture in memory:
Unfortunately, this problem is not completely solved...
I noticed that the problem came back just after loading the cdc in each CN and effective application (straton) startup.
For a brief instant some output are turned ON after cdc loading and get back to normal state when Straton start to write to B&R modules.
The Straton's application seems to work fine though.
To find the problem, I simplified the demo program demo_mn_console.
It performs only the initialization of the powerlink stack with loading the cdc and starts a sync thread that does nothing.
tEplKernel PUBLIC AppCbSync(void)
{
tEplKernel EplRet;
EplRet = EplApiProcessImageExchange(&AppProcessImageCopyJob_g);
if (EplRet != kEplSuccessful)
{
return EplRet;
}
return EplRet;
}
So, whith the cdc produced by openconfigurator 1.3.0 + my previous patch some outpout are ON by default after initialization.
I probably missed something in openconfigurator, but I do not know what.
Best regards,
Romain
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe the reason for this issue is that the process images are dynamically allocated by the stack in memory, but not zeroed out at the beginning. So unless you overwrite the PIs, they'll contain any uninitialized data.
You could try to add a memset() in the EplApiProcessImageAlloc().
Best regards,
Wolfgang
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Indeed, it may be a good idea to initialize the PIs data.
But may coworker has probably found the problem...
Since my patch in openconfigurator, all projects need to reimport all xdc files.
To be safe, It seems to be necessary to create a new project.
Until now, we were doing "clean" and "build" after replacing the openconfigurator's dll.
I need to do some tests to confirm that.
Thank you for your support.
Romain
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have checked the mnobd.txt file and I did not find any errors.
Note that the configuration of node 3 has changed (two additional X20SM1437 modules)
I recorded communications with wireshark, and I found when the problem occurs...
For simplicity I only use the CN1, others are offline.
see EPL-PDO-START-CN1.pcapng
At frame n°129, the CN1 state change from NMT_CS_PRE_OPERATIONAL_2 to NMT_CS_READY_TO_OPERATE
The CN1 start to reply to the PReq with an no empty PRes payload.
At frame N° 160, The MN start the CN1 with NMTStartNode command
Then the CN1 state change from NMT_CS_READY_TO_OPERATE to NMT_CS_OPERATIONAL (frame 163).
Then problems arise because the MN send an no empty Preq payload to CN1 wich may turn on randomly some output.
The same problem arise with several CN:
see EPL-PDO-START-CN3.pcapng
The Preq for CN1 and CN2 seems to be corrupted after CN3 start while they are still in the state NMT_CS_PRE_OPERATIONAL_2
PS: what's wrong with sourceforge today... can't add several files to this post... Sorry
PPS (Wolfgang): I've re-ordered the post with all three attachments.
To be sure on the issue:
I see the change in the PReq payload between frames 162 and 166 (EPL-PDO-START-CN1.pcapng). And there is nothing from the application side setting this data?
Best regards,
Wolfgang
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) In the post if 2014-02-20 I said:
"problems arise when I don't use PDOs at all,
for example when I use only SDO for upgrade modules's B&R firmware"
In my program that update B&R firmware, the sync thread wasn't started since only SDO was used.
I think it's the problem because the Mn and Cn are operational and PDOs are exchanged.
But in this case it's wrong because PIs data aren't initialized.
It worked with small Epl config but not anymore.
(and nothing was plugged durring test)
So, I modified this program to stop booting Mn and Cn at stage PreOperational1.
Only SDO are exchanged between Mn ans Cn.
(I need to add this info for Ole in the B&R firmware update thread)
2) The symplified demo_mn_console works correctly now,
no output are ON and PDOs content remains to zero.
I added 2 memset in EplApiProcessImageAlloc() to be safe.
3) It remains for me to know why some output are briefly on durring Straton startup but
it does not seem to be a openpowerlink issue since demo_mn_console works with the same cdc.
So, I'll stop polluting this thread since Openconfigurator is fixed ;-)
Thanks for your help.
Best regards,
Romain
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I encountered a problem during PDO exchange with an heavy powerlink configuration (3Cn)
I have attached xap.h and xap.xml which describe the powerlink bus.
On CN3, modules beyond a certain PIOffset are no longer reachable if I use directly PI_OUT/PI_IN struct.
If I change padding PADDING_VAR_27:24 to PADDING_VAR_27:8 in xap.h, the X20DIF371 start to works properly, but I'm unable to read AbsPos01ActVal and motors status...
It seems to have a conflict with the module offset.
If I use a specific cdc with only CN3, all works fine.
Something is wrong when the PIOffset goes beyond 0x00fc...
Have you encountered this kind of problem ?
Thanks,
Romain Naour
PS: I use an Epl stack based on v1.8.2
Here are xap.h and xap.xml
Romain
Hello Romain,
I had a look into your xap.h and xap.xml and It looks like you are using xap.h. Am I right?
The xap.h looks fine and could you provide me some more details like mnobd.txt or the openCONF project.
1) Have you cross checked in the wireshark PRes packets for the CN 3 ?
2) Is the status of the motor/ the PI variable is present in its specific offset in the wireshark packet ?
Regards,
Powerlink-Team
Kalycito
Hi Ramakrishnan,
I use both xap.h for testing/debug and xap.xml with Straton runtime for Linux [1]
The problem was reported to me by a coworker this Friday and reproduced with Straton and a C program.
I'm agree with you, the xap.h seems to be Ok, I don't think it's an openConfigurator's problem. (tested with 1.2.2 and 1.3.0)
I need to continue investigations on powerlink stack side with wireshark.
So, I'll send you the mnodb.txt and traces as soon as possible.
Note: I use the powerlink kernel stack with powerlink82573 driver and linux kernel 3.2.38-rt.
Best regards,
Romain Naour
[1] http://www.copalp.com/en/products/runtime/index.html
Hi Ramakrishnan,
here is mnodb.txt
Romain
Here is the wireshark PRes packets for the CN 3
It seems to be Ok.
I get 37 06 for CN3_M01_X20SM1436_MpGenStatus01 and CN3_M02_X20SM1436_MpGenStatus01
and 03 80 for CN3_M03_X20DIF371_DigitalInputxx (Input 1,2,16 are ON)
But I have this when I dump from application.
I hope this can help you on your side
Best regards,
Romain
Hi,
I also checked the files and I see that the TPDO definition of CN 3 is correctly describing 64 bits. On the MN side now the process image should be 32 bit aligned, thus leading to the 24 bit offset in the xap.h / xap.xml.
But the RPDO definition is incorrect. The Rx mapping in line 226 is okay, but the lines 227 and 228 should not be there. In line 229 a 32 bit value is correctly mapped to the next 32 bit-aligned field which is described by subindex 0x40 of 0xA640. Only the value from the PDO must be taken from offset 0x0008 bit and not from 0x0018 bit:
@Romain: Which version of openCONFIGURATOR are you using?
@Ramakrishnan: Can you confirm my findings and check for the bug?
Best regards,
Wolfgang
Hi Wolfgang,
I'm using openCONFIGURATOR-1.2.2 with default openPOWERLINK_MN.xdd for MN.
I have tested OpenConfigurator 1.2.2 and 1.3.0 and there is no différences in this part of the mnobd.txt
Best regards,
Romain
Hi Wolfgang, Ramakrishnan
I am trying to generate the cdc by hand following Wolfgang's feedback.
But it didn't work.
Here is what I understand from original cdc:
Note: CN3_M04_X20DOF322_StatusDigitalOutputxx has been removed in fieldbusdesigner.
So, you think that the CN3_M00_X20PS9400a_StatusInputxx and CN3_M01_X20SM1436_NetworkStatus
are in the wrong place.
Here is what there was in the cdc when there is only CN3
It is pretty identical and I have no problem with it.
I really need a functional cdc binary in a few days/weeks (tests + demo)
Can you give me some clue to fix the cdc by hand ?
Thank you,
Romain
Hi Romain,
I made a wrong calculation when checking the CDC file. The file and its mapping should be correct, BUT...
Your finding that the trouble starts at offset 0x00fc gave a hint: This number (252) corresponds exactly to the number of available sub-indexes for the PI objects defined in the openPOWERLINK stack!
And here comes the problem:
The mapping entry of CN3_M01_X20SM1436_NetworkStatus is on 0xA4C0/F9, thus PI offset 248 (0xF9 - 1, because we start at sub-index 1). The next entry is an UNSIGNED32 and therefore 32 bit aligned (starting at PI offset 252 and not offset 249). This is followed by an UNSIGNED16 value starting at PI offset 256. So far, so good.
Now, the next mapping entry is an UNSIGNED8. Therefore, it will be placed at PI offset 258. But here, openCONFIGURATOR makes a mistake:
It calculates internally as if all theoretically available sub-indexes of object 0xA4C0 can be used. That means it calculates (258 % 254) + 1 which gives sub-index 5. But in the openPOWERLINK stack it is defined that only sub-indexes up to 252 shall be used, thus leading to (258 % 252) + 1 which gives sub-index 7.
Therefore, the correct mapping entries should be:
Best regards,
Wolfgang
Hi Wolfgang,
Thank you very much for your help !
I did a test using your changes, but it seems to have another problem.
I noticed strange behavior durring test, all output are turned ON durring cdc loading.
Also, here is what I get when I read Cn3 datas:
There are two extra bytes (00) between CN3_M01_X20SM1436_NetworkStatus and CN3_M01_X20SM1436_AbsPos01ActVal
since the sub-index changes.
To avoid errors during manual changes to the mnobd.txt,
I compiled openConfigurator under Linux in order to modify the calculation of sub-indexes.
I changed 254 by 252 for the calculation of sub-indexes (PIOperations.cpp and ProcessImage.cpp)
Here are generated files
Best regards,
Romain
Hi Wolfgang,
I made a mistake durring tests...
All goes well after applying your changes. :)
I'll send a patch for openConfigurator.
Best regards,
Romain
Hi Romain,
It looks correct for me!
The explanation is the alignment of 16 bit variables to 16 bit boundaries and 32 bit variables to 32 bit boundaries in the process image. Therefore, the process image is larger than the data transmitted on the wire.
Using your given readings from above and taking in account the process image alignment, CN3 modules start at the offset 0x00F6 in the process image which is located at a 16 bit, but not at a 32 bit boundary. This will give the following picture in memory:
As you can see, the three padding bytes are inserted in order to align the CN3_M01_X20SM1436_AbsPos01ActVal to the 32 bit boundary.
Hope that gives a better understanding,
Wolfgang
Yes indeed, I can confirm that after a second test with our system.
Thanks alot for your help.
Romain
Hi Wolfgang, Ramakrishnan
You can find the patch I used:
https://sourceforge.net/u/kubu/openconf/ci/openconf-1.3.0-bug-fix/tree/
I do not have write a commit log very meaningful... sorry :-/
Best regards,
Romain
Hi Romain,
Thanks for your contribution!
Best regards,
Wolfgang
Hi Wolfgang, Ramakrishnan
Unfortunately, this problem is not completely solved...
I noticed that the problem came back just after loading the cdc in each CN and effective application (straton) startup.
For a brief instant some output are turned ON after cdc loading and get back to normal state when Straton start to write to B&R modules.
The Straton's application seems to work fine though.
But problems arise when I don't use PDOs at all, for example when I use only SDO for upgrade modules's B&R firmware.
see: https://sourceforge.net/p/openpowerlink/discussion/technology/thread/35d281db/
To find the problem, I simplified the demo program demo_mn_console.
It performs only the initialization of the powerlink stack with loading the cdc and starts a sync thread that does nothing.
So, whith the cdc produced by openconfigurator 1.3.0 + my previous patch some outpout are ON by default after initialization.
I probably missed something in openconfigurator, but I do not know what.
Best regards,
Romain
Hi Romain,
Maybe the reason for this issue is that the process images are dynamically allocated by the stack in memory, but not zeroed out at the beginning. So unless you overwrite the PIs, they'll contain any uninitialized data.
You could try to add a memset() in the EplApiProcessImageAlloc().
Best regards,
Wolfgang
Hi Wolfgang,
Indeed, it may be a good idea to initialize the PIs data.
But may coworker has probably found the problem...
Since my patch in openconfigurator, all projects need to reimport all xdc files.
To be safe, It seems to be necessary to create a new project.
Until now, we were doing "clean" and "build" after replacing the openconfigurator's dll.
I need to do some tests to confirm that.
Thank you for your support.
Romain
Hi Wolfgang,
Forget what I said in my last reply.
I have checked the mnobd.txt file and I did not find any errors.
Note that the configuration of node 3 has changed (two additional X20SM1437 modules)
I recorded communications with wireshark, and I found when the problem occurs...
For simplicity I only use the CN1, others are offline.
see EPL-PDO-START-CN1.pcapng
At frame n°129, the CN1 state change from NMT_CS_PRE_OPERATIONAL_2 to NMT_CS_READY_TO_OPERATE
The CN1 start to reply to the PReq with an no empty PRes payload.
At frame N° 160, The MN start the CN1 with NMTStartNode command
Then the CN1 state change from NMT_CS_READY_TO_OPERATE to NMT_CS_OPERATIONAL (frame 163).
Then problems arise because the MN send an no empty Preq payload to CN1 wich may turn on randomly some output.
The same problem arise with several CN:
see EPL-PDO-START-CN3.pcapng
The Preq for CN1 and CN2 seems to be corrupted after CN3 start while they are still in the state NMT_CS_PRE_OPERATIONAL_2
PS: what's wrong with sourceforge today... can't add several files to this post... Sorry
PPS (Wolfgang): I've re-ordered the post with all three attachments.
Last edit: Wolfgang Seiss 2014-03-03
Hi Romain,
To be sure on the issue:
I see the change in the PReq payload between frames 162 and 166 (EPL-PDO-START-CN1.pcapng). And there is nothing from the application side setting this data?
Best regards,
Wolfgang
Hi Wolfgang,
Ok, I'll try to clarify the situation.
1) In the post if 2014-02-20 I said:
"problems arise when I don't use PDOs at all,
for example when I use only SDO for upgrade modules's B&R firmware"
In my program that update B&R firmware, the sync thread wasn't started since only SDO was used.
I think it's the problem because the Mn and Cn are operational and PDOs are exchanged.
But in this case it's wrong because PIs data aren't initialized.
It worked with small Epl config but not anymore.
(and nothing was plugged durring test)
So, I modified this program to stop booting Mn and Cn at stage PreOperational1.
Only SDO are exchanged between Mn ans Cn.
(I need to add this info for Ole in the B&R firmware update thread)
2) The symplified demo_mn_console works correctly now,
no output are ON and PDOs content remains to zero.
I added 2 memset in EplApiProcessImageAlloc() to be safe.
3) It remains for me to know why some output are briefly on durring Straton startup but
it does not seem to be a openpowerlink issue since demo_mn_console works with the same cdc.
So, I'll stop polluting this thread since Openconfigurator is fixed ;-)
Thanks for your help.
Best regards,
Romain