I have 2 separate drive applications at an OEM customer in the UK that have seen diagnostic F8304 be generated by the SMO safety system.

The first occurrence was at a HMS01.1N-W0210-A-07-NNNN running a MBS202D motor and using Heidenhain Incremental encoder. Firmware would be MPB20V32 with SRV extension.

This issue occurred in standard production with the drive at Ab status

The second occurrence was at a HMD01.1N-W0036-A-07-NNNN running 2 off MS2N06 motors with CM encoders. Firmware would be MPM20V32 with SRV extension.

This issue occurred in standard production with the drive at PA status

In both cases rebooting the drive cleared the issue.

Which steps can be checked around both systems to determine the cause of the issues?

If I'm using a ctrlX Core PLC (M5) and I need two HMI's running on the line with the same application (1 in front and 1 in back of the machine) I need 2 of WebIq (SWL-W-XC*-WIQ**RUD*001K**-NNNN)? or is enough only one and I can run from 2 hmi devices?

Could you please let me know if there is an explosion-proof gearbox available for the MS2E motor?
We need a gearbox suitable for Zone 2 / Zone 22 hazardous areas.

If available, could you please recommend a suitable model?

Kirikiman

see system report.

1. Intro

2. Prerequisite

3. Sign parameter file with ctrlX DRIVE Engineering (Offline signing)

4. Download of a signed parameter file

5. Good to know

Intro

With AXS-V-0702 and "Drive level" as mitigation strategy, it is only possible to load signed parameter files as end user (user role 4) per default. The file must be signed using the same "Admin" password as present in the drive it is intended to be load to.

Using this functionality ensures that only unmanipulated parameter files signed with the administrator password can be loaded to a drive. Unsigned parameter files will be ignored by the drive.

To sign a parameter file, you can:

• use the signing tool within ctrlX DRIVE Engineering to sign an unsigned parameter file (offline signing)

Prerequisite

• ctrlX DRIVE Engineering 01V44 (recommended)

• Runtime >= AXS-V-0702

Configure the drive correctly to enable security control "signed parameter files":

Select mitigation strategy „Drive level“!

Activate password protection and change "Admin" password

Allow „Load and activate parameter file via TFTP” for end user (user role 4). This enables the end user to load signed parameter files via TFTP (file based). Also other user level can have this permission.

Sign parameter file with ctrlX DRIVE Engineering (Offline signing)

To download a parameter file via TFTP to a drive with active security (with selected "Drive level" mitigation), one needs to sign the file in advance.

Open "Sign file..." dialog

Select the parameter file you want to sign!

Enter "Admin" password to sign the file!

Signed file (with name extension *_signed.par) will be stored in the same directory as the original file.

Download of a signed parameter file

When downloading a signed file via TFTP, the drive will check the signature before activating the file.

ctrlX DRIVE Engineering 01V44 and later will use the file based parameter download per default

If the file is not signed or signed with wrong signature, the drive will ignore the file with an error message.

Good to know

If you are unable to use TFTP in your environment or there are other reasons why you can not use file based parameter download, you can deactivate the file based parameter download.

The parameter file will then be downloaded using individual parameter write access, as in previous versions of ctrlX DRIVE Engineering.

Setting can be changed in menu Tools>Options:

We found that the cable configuration from our Configurator is different from the description in our Cable Manual. could you help to check which one is the right one? thank you!

https://ctrlx-configurator-platform.boschrexroth.com/#/solution/load/CTRLX346631/9540f999-860a-45e6-894b-e9f1a727458d

I am currently investigating an issue related to RAM usage when using the ctrlX Data Layer from a Python application.

The main problem is that the RAM consumption of the application continuously increases over time while Data Layer communication is active. The memory does not appear to return to its initial level during normal operation, so after running the application for a long period, the RAM usage becomes significantly higher than at startup.

Initially, I suspected that the problem could be caused by my own implementation, particularly by continuously reading values from the Data Layer using polling.

However, during troubleshooting I performed several tests:

• I reduced the polling frequency.

• I tested a subscription-based approach instead of continuously reading the values.

• Using subscriptions significantly reduced the rate at which the RAM increases, but it did not completely eliminate the behavior.

• I also tested the official Bosch ctrlX Python Data Layer provider example, without my application logic, and I was able to observe the same RAM growth behavior.

Because the issue can also be reproduced with the official example, I am trying to understand whether this behavior is expected from the Data Layer / Python SDK or whether there could be a memory management issue.

The architecture in my original application consists mainly of:

Provider → ctrlX Data Layer → Client/Reader

The provider publishes the data to the Data Layer, while another Python application reads the values. The RAM usage increases progressively while the communication is running.

At this point, my main questions are:

1. Is a continuous increase in RAM usage expected when using the Python Data Layer SDK?

2. Are there known memory-related issues with Data Layer reads, subscriptions, or providers?

3. Is there a recommended way to perform continuous/cyclic Data Layer communication without memory usage continuously increasing?

4. Are there specific SDK/Data Layer versions where memory management improvements or fixes were introduced?

5. Is there any recommended method to explicitly release Data Layer resources during long-running applications?

The application is intended to run continuously, so even a relatively slow memory increase becomes relevant over long periods.

I would appreciate any information regarding similar reported behavior, recommended configurations, or known issues in the Python Data Layer SDK.

In WebIQ versions up to 2.18.x, Local Scripts were loaded and executed by the system as Classic Scripts. This made it possible to declare global variables, constants and functions, making them accessible across all scripts.

I am developing HMIs locally on a Windows PC with WebIQ Designer and WebIQ Server. Today I updated from 2.18.0 to 2.20.2. After the update, WebIQ Launcher showed the local host 127.0.0.1:10123 as Not reachable (red).

The Windows service WebIQ Server (connect.exe) was often reported as Running, but the Launcher still could not connect.

What I found:

• The Launcher connects with a plain WebSocket, ws://127.0.0.1:10123. In launcher.json this host has no useSSL.

• After the upgrade, C:\ProgramData\WebIQ\connect.json had the listener on port 10123 with "tls": { "enabled": true }.

• A WebSocket handshake on that port then received HTTP/1.1 307 Temporary Redirect to https://127.0.0.1:10123/. The Launcher does not follow that redirect, so it shows Not reachable even though the port is open.

• connect.json also had to be configuration "version": 2. With the old "version": 1, the server could start and then stop during initialization (Exception while attempting to initialize system modules / Unknown exception in C:\ProgramData\WebIQ\connect.log), while the service stayed Running and nothing listened on 10123.

What fixed the connection:

1. In C:\ProgramData\WebIQ\connect.json, set the port 10123 listener to "tls": { "enabled": false } and keep "version": 2.

2. Restart the service from an elevated PowerShell:

Restart-Service -Name "WebIQ Server" -Force

If the service does not stop because connect.exe is hung:

taskkill /F /IM connect.exe

Start-Service -Name "WebIQ Server"

3. A plain WebSocket handshake must return HTTP/1.1 101 Switching Protocols, not a 307 to HTTPS. After that, the Launcher shows the server version instead of Not reachable.

The host is reachable again, but two things are still wrong:

1. Local Designer license. I have a one-year license to develop on this PC. This is the license:

WebIQ Designer license for activation on an industrial PC. This license can be used to create HMI projects for the ctrlX HMI target systems ctrlX CORE, ctrlX CORE Virtual and PC-HMI. The licence includes an HMI server licence for validating the HMI project in a web browser.

After the update to 2.20.2 I no longer seem to have it. Designer does not behave as a licensed local development seat anymore. Is this license supposed to stay activated on the engineering PC for the whole year, and how do I check or restore it after a WebIQ upgrade? The license agent is on localhost:10121.

2. Projects are not visible in Designer. The project folders are still on disk under C:\ProgramData\WebIQ\WebIQ Projects, and they were updated today. Designer does not show them. How do I get these existing projects back into Designer 2.20.2 without creating them again?
   

   

   
   

   

Also, the license files that were previously in C:\ProgramData\WebIQ\licenses are no longer there after the upgrade. The project directories are still present, but Designer does not list them.

Please, help me!
Thank you