Skip to Content

Register Login

Default Header

(header konnte nicht geladen werden)

Navigation

Usage of LPNDR_ReadGlobalInfo for port link status from LPNDR library

Created by: @AutoGen_995257 at: 5/9/2025 3:59 PM (4 Replies)

Rating (0)

Thanks 0

5 Entries

5/9/2025 3:59 PM	Rate (0)
@AutoGen_995257 Joined: 12/19/2024 Last visit: 8/21/2025 Posts: 8 Rating: (0)	Hello, I found the following library from Siemens: Library for PROFINET data records - ID: 109753067 - Industry Support Siemens The library seems to contain what i need but i am uncertain about the correct usage and some of the values for certain variables. The SCADA has a visualisation of the PLC and the I/O islands with the Profinet connections between them. The idea is to display the status of the connections with a color. For example a Profinet connection that is ok would be green and when a connection is broken it would turn red. The FB i think i need to use is "LPNDR_ReadGlobalInfo". It outputs an array [1..52] of the datatype "LPNDR_typePortLinkState" which contains the byte "portLinkState". The first question i have is about the array. is that the amount of ports for 1 device it can read the information of? So for example when using the block for a PLC with 2 ports, the first index [1] would contain info about port 1 and the second index [2] would contain info about port 2 while the others [3..52] would not contain info? The next question i have is about the "portLinkState" byte. In the documentation for the block is shows 7 states. I put an image below: I know state 1 is OK but i am not certain about state 3 and state 5. (3) Testing mode doesn't seem like a fault state to me and i am uncertain what (5) Demand mode is. The others i am pretty certain can be considered as fault states. The last question i have is what device ID i need to attach to the input. I assume i just need to use Hw_Device but there also is a Profinet interface ID Hw_Interface for the profinet ports and the interface itself with all the ports. I have put a photo below so the Local-Device Id seems to be plausible but also the Local-PROFINET_interface_1. Thanks in advance for your help and response!
	Last edited by: Moderator_Lan at: 05/12/2025 08:14:16 link optimized
Suggestion To thank Quote Answer

5/11/2025 3:42 PM	Rate (0)
Hati Platinum Member Joined: 9/21/2012 Last visit: 9/10/2025 Posts: 4708 Rating: (510)	I would use DeviceStates for that task.

Suggestion To thank Quote Answer

5/12/2025 6:41 AM	Rate (0)
@AutoGen_995257 Joined: 12/19/2024 Last visit: 8/21/2025 Posts: 8 Rating: (0)	I have tried it before, now i see why it probably didn't work. I think that's an option but i am not sure if DeviceStates is detailed enough so that you know which port of a device is not receiving. The network would be in a ring so if one cable is broken it would still be able to reach everything through the other side but we do need to display a fault.

Suggestion To thank Quote Answer

5/12/2025 1:16 PM	Rate (0)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 9/12/2025 Posts: 16094 Rating: (2515)	If the network topology is configured (correctly), you will receive a Hardware Error Interrupt OB call (OB82 I think is the #). From there, you can compare the hardware address with the system constants for each device / port. If it's an incoming event on one of your device ports, you know it is not communicating through that connection - until an outgoing event with the same hardware ID is set. You will need some reliable way for end-users (with elevated permissions perhaps) to reset these latched states as there are situations where there may not be a matching outgoing event (that the PLC logic can detect). Sometimes the outgoing events happen before the PLC is fully in run mode and cannot be detected by the PLC logic in OB82. @AutoGen_995257 I have tried it before, now i see why it probably didn't work. I think that's an option but i am not sure if DeviceStates is detailed enough so that you know which port of a device is not receiving. The network would be in a ring so if one cable is broken it would still be able to reach everything through the other side but we do need to display a fault.
	science guy
Suggestion To thank Quote Answer

5/14/2025 11:26 AM	Rate (0)
@AutoGen_995257 Joined: 12/19/2024 Last visit: 8/21/2025 Posts: 8 Rating: (0)	Thanks, i will try that but is there for sure no option to use RDREC per port? The function block from the library internally uses RDREC to but for the whole interface from what i understand. I have tested how it outputs the information and i think it would be more reliable and not require a manual reset which saves some work on other aspects. With the library when i tested it, when it is connected it had a 1 as output and when nothing was connected a 2 i think it also outputs other states in different situations but these were what i got when connecting or disconnecting a cable.

Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on