Hello,
I'm migrating my Windows platform MN application from old nOpenPowerlink to stack version 2.6.2 of openPOWERLINK. At the moment, I'm trying to support two communication modes with my CN (proprietary devices)
- SDO over UDP
- Datagram Socket over UDP (TFTP service)
My current test case requires a short file transfer from the device followed by an SDO read. This is what I can see:
- file transfer over UDP goes well
- the read fails, apparently because of MN close during the connection phase (see attached readObjeck_KO)
As a further information, the very same sequence completes successfully if I run it in debug mode, with some breaks in code (on read call, sdo callback ...), please see attached readObject_OK
May it be a timing issue? The test case run well with the old nOpenPowerlink and the initialization parameter are the same as before ...
Any suggestions on what I should investigate?
Thanks for support!
Franco
my Master Node is a legacy Windows C# application that encapsulate powerlink stack with a C++/CLI wrapper class, built as dll.
The application must support both cyclic (PDO + SDO) and acyclic communication (SDO only, TFTP for file transfer). I've not built any specific driver (such as NDIS ...)
As for stack initialization, configuration and operation, I followed the demo examples (QT and mn console)
CN is a device FreeRTOS. I think that it runs version 1.x of the stack, but I've to verify
As for cyclic communication, SDO over UDP works fine. As for acyclic, unfortunately not.
Please, let me know if you need some further information, bye!
Franco
Last edit: Franco Delucchi 2018-05-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It might be a timing issue, and you may try to increase the SDO sequence layer timout value on the devices (object 0x1300).
However, the openPOWERLINK stack in Windows with WinPCap does not provide a virtual Ethernet interface that allows to use the asynchronous phase of POWERLINK as a standard Ethernet network. Therefore, general IP traffic would always be routed through the "real" Ethernet card and can influence POWERLINK traffic. This is a not recommended usage!
My suggestion is to do the file transfer also via SDO (you can check out the firmware manager code in the stack as an example of a large block transfer) instead of TFTP.
(Generally speaking, Windows is not a good platform for real-time applications. And in my opinion, a real-time stack such as POWERLINK should be run natively. Using environments such as .NET or Java add delay and are by design not made to allow real-time operations.)
Best regards,
Wolfgang
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Wofgang,
sorry for the delay to make you know, but yes, it was a timing issue: the sdoSeqInstance_l.sdoSeqTimeout
parameter resulted to be not set.
I managed to make it work. In my setup I use a dedicated ethernet connection to my device, so general IP traffic doesn't actually mix into the POWERLINK .
Thank you for your support, best regards.
Franco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I'm migrating my Windows platform MN application from old nOpenPowerlink to stack version 2.6.2 of openPOWERLINK. At the moment, I'm trying to support two communication modes with my CN (proprietary devices)
- SDO over UDP
- Datagram Socket over UDP (TFTP service)
My current test case requires a short file transfer from the device followed by an SDO read. This is what I can see:
- file transfer over UDP goes well
- the read fails, apparently because of MN close during the connection phase (see attached readObjeck_KO)
As a further information, the very same sequence completes successfully if I run it in debug mode, with some breaks in code (on read call, sdo callback ...), please see attached readObject_OK
May it be a timing issue? The test case run well with the old nOpenPowerlink and the initialization parameter are the same as before ...
Any suggestions on what I should investigate?
Thanks for support!
Franco
Last edit: Franco Delucchi 2018-05-09
Hi Franco,
We understand that you want to perform two operations with a single CN (SDO over UDP and file transfer via TFTP protocol).
Could you please share us detailed information on the following:
1. Type of Windows MN platform (Link-to-application/NDIS/QT demo)
2. Type of CN
Also let us know if normal SDO read/write via UDP is working fine without TFTP ?
Thanks,
Powerlink-Team-Kalycito
Hi, I try to better clarify:
my Master Node is a legacy Windows C# application that encapsulate powerlink stack with a C++/CLI wrapper class, built as dll.
The application must support both cyclic (PDO + SDO) and acyclic communication (SDO only, TFTP for file transfer). I've not built any specific driver (such as NDIS ...)
As for stack initialization, configuration and operation, I followed the demo examples (QT and mn console)
CN is a device FreeRTOS. I think that it runs version 1.x of the stack, but I've to verify
As for cyclic communication, SDO over UDP works fine. As for acyclic, unfortunately not.
Please, let me know if you need some further information, bye!
Franco
Last edit: Franco Delucchi 2018-05-11
Hello Franco,
It might be a timing issue, and you may try to increase the SDO sequence layer timout value on the devices (object 0x1300).
However, the openPOWERLINK stack in Windows with WinPCap does not provide a virtual Ethernet interface that allows to use the asynchronous phase of POWERLINK as a standard Ethernet network. Therefore, general IP traffic would always be routed through the "real" Ethernet card and can influence POWERLINK traffic. This is a not recommended usage!
My suggestion is to do the file transfer also via SDO (you can check out the firmware manager code in the stack as an example of a large block transfer) instead of TFTP.
(Generally speaking, Windows is not a good platform for real-time applications. And in my opinion, a real-time stack such as POWERLINK should be run natively. Using environments such as .NET or Java add delay and are by design not made to allow real-time operations.)
Best regards,
Wolfgang
Hello Wofgang,
sorry for the delay to make you know, but yes, it was a timing issue: the sdoSeqInstance_l.sdoSeqTimeout
parameter resulted to be not set.
I managed to make it work. In my setup I use a dedicated ethernet connection to my device, so general IP traffic doesn't actually mix into the POWERLINK .
Thank you for your support, best regards.
Franco