• IO-link master is OK

• IO-link slave is OK

• Gripper status LED is green

• Gripper Power is OK

After Cold reset there is an error from NexeedSchunkEgpGripper object there is an error General Fault: Error during IO-Link parameter access.

During use there is an error Timeout fault: Timeout during error clear.

Received Status is 3 (Error).

\\bosch.com\dfsrb\DfsDE\STC\NXA\Release

How to get access:
Go to the IT Service Portal and select Security Groups.
https://rb-servicecatalog.apps.intranet.bosch.com/RequestCenter/website/Grunt/application/offer.html?id=4420

Select Option Manage memberships in the drop down menu

Now you need to search for the managed group "Fe_BMG_Nexeed_Automation_Cust"

Click the button "Change Membership", select "Add User", enter your user ID in the search box and click "Search&Apply":

Your user name (Identity and Displayname) should appear in the member list

Click "Request"

• You must select a Remote Manager 3.1.4026 version, not any older version like 3.1.4024.60.

  

• You must select the local real-time runtime (<Local>) not the usermode runtime (UmRT_Default). If the real-time runtime is missing you can add it in the TwinCAT Package Manager settings.

  

There is no need to activate configuration on the local real-time runtime. You can activate or prolong the demo license with the "7 Days Trial License" button:

If you do not consider it, activating the demo license runs through without error, but it does not activate or prolong the demo license. The current status will show "expired" like in the screenshot above and OPC UA clients like UA Expert will show the error "BadLicenseExpired".

Beckhoff TwinCAT OPC UA server does not start because of these errors after activate configuration:

TcOpcUaServer (10236): OpcServer :: start failed with 0xffffffff
TcOpcUaServer (10236): UA Security :: ApplyNSLevelSecurityConfig failed

Source of the errors

Another software is already using the default OPC UA port 4840, for example the OPC UA Local Discovery Server (LDS) by OPC Foundation which could be installed in combination with Siemens TIA Portal or another software.

Solution

Open the Windows services and stop or disable the service opcualds.exe:

If there is no such service download TCPView for Windows (Sysinternals) directly from Microsoft. Open tcpview64.exe and sort the entries by port number. Probably there is a process or service like opcualds.exe which is already using port 4840. Stop this process or service.

The DataSetManager is quite heavy, with station data, tpedata and others...

Any idea how to solve?

Check screenshot in the attachments

We are experiencing an issue with the secondary HMIs installed on our machines, and we would appreciate your insights.

These secondary panels are typically paired with low-performance PLCs (e.g., C6017) or use integrated controllers within the panel itself (such as mPad Active). In most cases, they are configured without a UPS.

When the system is correctly configured (write filter enabled and no UPS), we have observed that after several days of continuous operation, the write filter eventually fills up the available RAM. This leads to a gradual degradation of system performance until the panel becomes unresponsive.

Our understanding is that the write filter is accumulating changes in RAM, but without a proper mechanism to release or manage this memory over time, it creates a system stability issue.

Question:
Is there any way to periodically clear or manage the RAM usage of the write filter to prevent this situation from occurring?

Any recommendations or best practices would be greatly appreciated.

Thank you in advance.