Wolfgang Seiss

Hi, It's a pull request in GitHub, so you can directly access it anyways :-) See here. There, you can directly clone it via git or download a zip file. BR, Wolfgang

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...

Hello Xiaokang, In order to shorten the POWERLINK cycle time, your platform needs to be fast enough in handling the incoming/outgoing frames and the state machine. If you need to reduce the delay between receiving a frame and sending out the next one, you could consider using an FPGA platform with the openMAC IP-Core (given in the Open Source stack). Best regards, Wolfgang

Hi Simon, It should be working with the latest openPOWERLINK stack. So, did you try it out with V2.6.2 or V2.7.0? Best regards, Wolfgang

Hi Simon, I think, this depends on your application and the requirements whether porting the stack or porting the application will be the right approach. Some years back (in the old stack), a port for VxWorks was created and compared to Linux/RTPREEMPT. Back then, VxWorks performed better regarding minimum cycle time and jitter behaviour on standard PC hardware. However, since then RTPREEMPT has also evolved. Best regards, Wolfgang

Hi Simon, Generally, this would be possible when implementing the extension "Multiple ASnd" (EPSG 302-B). The openPOWERLINK stack is able to make use of "Multiple ASnd" when run as a CN, but not as an MN. It would require a change of the implementation of the asynchronous scheduler of the MN that is not on the roadmap. Best regards, Wolfgang

Hi Simon, There used to be an implementation for VxWorks in the old branch of openPOWERLINK (openPOWERLINK 1.x series). During the move to version 2.x it was decided to drop VxWorks support and purely focus on Linux as the main target operating system. You may, however, take a look into the current sources and even find some VxWorks code parts ported to 2.x. But they have never been tested and most likely need some "polishing". Out of curiosity: Can you describe your application that you are about...

Hi Simon, In order to implement this object, you'd first of all need to gather all error events that are happening in the stack at a central position. This could be done by posting error events that are cought by a single error handling module which then keeps the error events in a FIFO-style buffer. The buffer is then exposed to the world via the object 1300h in which each sub-object is representing the events (sub-object 1 represents the most recent error, sub-object 2 the previous error...) Object...