Hello, in this WAGO tutorial we’ll walk you through the diagnostic options in the developer tools of WAGO Load Management. As in our previous tutorials, we’re working with a CC100 running the licensed WAGO Load Management and a PFC200 running a charging‑park simulation as a Codesys 3.5 visualization. From the Configuration menu we open the Developer tools and the first thing you see is a list of hardware inputs; if you apply 24 V to, for example the first two digital inputs on the CC100, their values flip from 0 to 1. You can also create additional variables, set values for use elsewhere, or define your own charging rules with formulas — we’ll cover that in another tutorial. Under Device Tests you can check connections to attached hardware. Besides dedicated tests for TESLA Wall Connectors and meters, there’s a general Modbus test we use to verify the connection to the mains meter. Start by selecting the communication type here Modbus TCP then enter the meter’s IP-address and port. Next you need to pick the register, for example phase L1, which you’ll find in the meter’s manual; enter that and set the data type to a real value which is float. When you start the read operation the display returns −18.8 A, so you can confirm regardless of device type or manufacturer that the Modbus connection is active and what values are being transmitted. The Logs menu lets you capture and display various states and status changes, and you can download the log file via the button at the top for further analysis or to share with the WAGO Support. To capture a specific event, clear the log storage first so you start with an empty log. With Auto‑refresh activ, the browser view updates every few seconds, but even if it’s off the logger keeps running in the background and you can fetch the latest entries with the refresh icon. You’ll see a Modbus log among the entries; since we’ve already checked the Modbus connection here, we only want to capture Modbus error messages. To access advanced options enable the "detailed view of all settings" the extended configuration appears at the bottom. The Modbus log is set to “Information”. In this context, we refer to different log levels: the higher the level, the more data is recorded. For Modbus there are three levels: Error (only errors), Warning (errors plus warnings) and Information (all Modbus communication events). To reduce data in our scenario we set the level to Error. You can also capture a MQTT connection or OCPP data. Note that OCPP is a Web Socket connection, so logging the WebSocket Data is in most cases useful. If you need to investigate charging or control behaviour, it’s sensible to record system information, backend information and load‑management information. In case of Logging, storage and log file size are always considerations, so use the 'Logging duration' field to set the recording duration. When the time has elapsed, the oldest entries are overwritten, thereby limiting the storage requirements. For a CC100 a good guideline is no more than one day of logging duration, as longer recording can fill memory and potentially destabilise the controller; actual volume depends on the system and enabled logging options. Avoid an “unlimited” logging duration, unless you have a very specific reason, because continuous logging fills up the controllers memory and will cause the controller to crash For day‑to‑day operation we recommend setting all log levels to the lowest and keeping retention to one day so only essential error messages are captured and can be analysed. If you see unexpected behaviour, increase logging selectively in the affected area to track down the root cause. There’s also an “Diagnosis logging Activate (5 min)” button which temporarily raises all diagnostic categories to the highest level for five minutes to collect a full dataset; it generates a lot of data, which is why it’s limited to five minutes. But if you experience unwanted behaviour, for example when connecting a vehicle, you can activate the button, connect the vehicle to the charging station and you will receive a complete data set for analysing the behaviour. The final tool in the developer tools is Cycle Time the time the controller needs for one computation cycle which is a quick way to check controller load. A value around 3,000 ms is good and indicates the Load Management is running reliably; values around 30,000 ms would indicate performance issues. In that case review the configured control logic to remove unnecessary computations or consider a controller with higher processing capacity. In short, Device Tests, Logs and Cycle Time are powerful tools to rapidly analyse unexpected behaviour and find the root cause. And that concludes the tutorial on the developer tools’ diagnostic options in WAGO Load Management. Please give us a thumbs up if the video was helpful, subscribe to the channel, and contact the WAGO Support Centre if you have any questions.