PROFINET Forum

SHC-E31 wrote: ↑15 Jul 2024, 13:26 Hi Forum,

My task:
I am supposed to filter incoming/outgoing Profinet and Profisafe messages from a safety PLC (probably SIEMENS 15xx series) in a so-called "APL module" and incorporate them into a new frame. The black channel comes to the APL module via Ethernet APL and should now be forwarded to the safety module in a new frame via a UART.
In principle, only the payloads from RT-Data or SPDU have to be "cut out" and inserted into a new frame and forwarded to the safety module.
The payloads must of course not be changed so that the CRCs remain unchanged and are valid for the safety module.
This is therefore a special architecture with safety PLC <-> APL module (broker) <-> safety module.

Summary:
The messages from/to the PLC/Safety PLC must now be differentiated with regard to Profinet and Profisafe and evaluated (unchanged) and forwarded/received in a new frame via UART and to/from the safety module. A distinction must also be made between Profinet and Profisafe in a byte "Message Type" so that the safety module can also evaluate this (iParameter vs F messages)
I hope it is clear what we are planning

Now to the actual question:
With which indicator (be it in the Profinet-Profisafe area, possibly also PN header within the 40 bytes) can one now CLEARLY distinguish F-messages from "normal" Profinet messages programmatically (e.g. with C++ code)?
Unfortunately I don't have any equipment yet (Safety PLC, Eval board of the safety module) otherwise I could check the telegrams for differences with the Wire Shark.

Thank you for any help, advice or tips.

Kind Regards,
SHC

DanielS wrote: ↑18 Jul 2024, 14:49

SHC-E31 wrote: ↑15 Jul 2024, 13:26 Hi Forum,

My task:
I am supposed to filter incoming/outgoing Profinet and Profisafe messages from a safety PLC (probably SIEMENS 15xx series) in a so-called "APL module" and incorporate them into a new frame. The black channel comes to the APL module via Ethernet APL and should now be forwarded to the safety module in a new frame via a UART.
In principle, only the payloads from RT-Data or SPDU have to be "cut out" and inserted into a new frame and forwarded to the safety module.
The payloads must of course not be changed so that the CRCs remain unchanged and are valid for the safety module.
This is therefore a special architecture with safety PLC <-> APL module (broker) <-> safety module.

Summary:
The messages from/to the PLC/Safety PLC must now be differentiated with regard to Profinet and Profisafe and evaluated (unchanged) and forwarded/received in a new frame via UART and to/from the safety module. A distinction must also be made between Profinet and Profisafe in a byte "Message Type" so that the safety module can also evaluate this (iParameter vs F messages)
I hope it is clear what we are planning

Now to the actual question:
With which indicator (be it in the Profinet-Profisafe area, possibly also PN header within the 40 bytes) can one now CLEARLY distinguish F-messages from "normal" Profinet messages programmatically (e.g. with C++ code)?
Unfortunately I don't have any equipment yet (Safety PLC, Eval board of the safety module) otherwise I could check the telegrams for differences with the Wire Shark.

Thank you for any help, advice or tips.

Kind Regards,
SHC

Dear SHC,

in general there is no difference between a "normal" PROFINET message compared to a PROFIsafe telegram. During the establishment of the Application Realation between the PLC and a device the device is configured from the PLC with all its modules. Each module got it´s own offset where the data in the cyclic communication is located.
If you want to filter the PROFIsafe part of the cyclic communication telegram you need to know this offset and the data length of the module (this data length includes the PROFIsafe data, the status / control byte and the CRC2). With this information you should be able to "cut out" the PROFIsafe part of the cyclic communication telegrams.
Please be aware that the offset value counting starts after the header of the cyclic communication telegram.

BR
Daniel