A Wago PLC cannot infer remaining storage from the sizes of its log files alone. Free space belongs to the filesystem volume that contains the log directory. Query that volume through an interface supported by the installed controller runtime, then drive retention from the returned available-byte value and status.
Storage-volume identification
The term free disk space here means the number of bytes currently available for new file allocation on the filesystem volume containing the logs. The volume may be internal storage, removable media, or another mounted filesystem. A query against the wrong volume can succeed while reporting a value unrelated to the log destination.
- Read the configured log directory from the application.
- Determine which storage volume owns that directory using the controller configuration and runtime documentation.
- Use the directory or its owning volume as the input to the capacity query, according to the interface definition.
- Record whether the path can change because of removable-media replacement or configuration changes.
Check 1: Expect the queried path or volume to be the same storage location on which a newly created log file appears. Do not continue with a controller-wide capacity value when the logs reside on a separate volume.
Runtime-interface selection
For the installed Wago target, inspect the available filesystem or storage libraries and the matching runtime documentation. The required interface must return available capacity for a path or volume and provide a result status.
| Interface property | Required behavior | Reason |
|---|---|---|
| Storage selection | Accepts a path, mount, device, or documented equivalent | Associates the result with the log volume |
| Capacity result | Returns available space with a defined unit | Supports a dimensionally valid threshold comparison |
| Status result | Distinguishes success from an unavailable path or failed query | Prevents stale data from authorizing more writes |
| Numeric range | Can represent the full capacity of the selected storage | A narrow integer can wrap and report a false value |
| Execution model | Documents synchronous or asynchronous completion | Prevents reading an output before it is valid |
If the controller runtime exposes an underlying operating system, use an operating-system method only when Wago documents that access path for the target. An operating-system call is not automatically portable into PLC logic, and its output still requires unit, status, and volume validation.
Check 2: Expect a successful status, a defined capacity unit, and a stable value on repeated calls while no files are being written. A changing or invalid value requires correction before retention logic is enabled.
Capacity-value integration
Convert the returned capacity once into the unit used by the retention thresholds. Compare bytes with bytes or another explicitly converted unit; never compare an unlabelled library value directly with a file-size setting. Store the result in a numeric type wide enough for the documented maximum storage capacity.
Call the query at controlled events such as before opening a new log, after closing a log, and after a retention action. A capacity query in every fast PLC scan adds unnecessary filesystem traffic. If the interface is asynchronous, trigger one request, wait for completion, consume the result once, and then release the request before starting another.
- Initialize the capacity result as invalid at startup.
- Request available space for the verified log volume.
- Accept the value only when the operation reports successful completion.
- Convert the documented unit without truncating significant range.
- Publish both the converted value and a validity flag to the logging state machine.
Check 3: Expect available capacity to fall after writing and closing a test log. The change may differ from the file's logical size because filesystems allocate storage in blocks and maintain metadata, but the direction must be downward.
Retention-policy boundaries
Use separate low and recovery thresholds. The low threshold starts deletion; the higher recovery threshold stops it. This hysteresis prevents the controller from alternating between one deletion and one write near a single boundary. Select both values from the maximum expected log growth, temporary-file use, and storage required by other applications sharing the volume.
Delete only closed files. Removing the pathname of an open file may not immediately release its allocated space on an operating-system-backed filesystem, and the logger may continue writing through the open handle. Exclude the active log and any temporary file used for an incomplete write.
Define “oldest” with an ordering that remains valid after controller restarts. File timestamps work only when the controller clock is valid and timestamp behavior is documented. A monotonic sequence embedded by the application avoids clock reversals, but its persistence and rollover behavior must be designed explicitly.
- Stop opening new log files when valid available capacity crosses the low threshold.
- Close and flush the active file according to the logging design.
- Select the oldest eligible closed file.
- Delete one file and confirm the delete operation succeeded.
- Query capacity again and repeat until it crosses the recovery threshold.
- Resume logging only after the capacity result remains valid.
Check 4: Expect the active file to remain present, files to disappear in the defined oldest-first order, and the reported available capacity to rise before logging resumes.
Failure-state behavior
A failed capacity query is not equivalent to zero free space, and it is not permission to keep writing. Treat it as a separate state. Preserve the last valid reading for diagnostics, mark it stale, inhibit retention decisions based on that reading, and apply the application's defined safe logging behavior.
| Observed condition | Likely class of cause | Required response |
|---|---|---|
| Path-not-available status | Removed media, changed mount, or wrong directory | Stop new log creation and revalidate the storage path |
| Successful query but no decrease after a write | Wrong volume queried or buffered data not closed | Close the file and confirm volume mapping |
| Successful delete but no capacity recovery | File remains open or allocation reporting has not refreshed | Close all handles and repeat the documented query cycle |
| Implausibly small or wrapped value | Unit mismatch or numeric overflow | Correct conversion and result data type |
| Repeated deletion around one boundary | No hysteresis or insufficient recovery margin | Separate low and recovery thresholds |
Deletion also creates write activity on flash-based filesystems. Retention should operate in bounded batches rather than repeatedly creating and deleting tiny files at scan rate.
Check 5: Expect removal or loss of the configured storage to produce an explicit invalid state without an uncontrolled sequence of create, query, or delete requests.
End-to-end commissioning verification
- Volume check: Create a test log in the configured directory. Expect it on the same volume used by the capacity query.
- Write check: Record available capacity, write and close a test file, then query again. Expect a lower valid reading.
- Threshold check: Use a controlled test threshold that crosses the current reading without filling the production volume. Expect the logger to enter retention mode.
- Ordering check: Provide several closed test logs with a known application-defined order. Expect the oldest eligible file to be selected first and the active file to remain untouched.
- Recovery check: Query after deletion. Expect available capacity to rise and logging to resume only after the recovery boundary is crossed.
- Fault check: Make the test path unavailable by an approved commissioning method. Expect an invalid-capacity state, no decision based on stale space, and a diagnostic visible to the application.
- Restart check: Restart the logging application under controlled conditions. Expect file ordering, threshold configuration, and storage-path selection to remain valid.
Check 6: Expect one complete cycle of write, low-space detection, oldest-file deletion, capacity recovery, and resumed logging without deleting the active log.
FAQ
Can I use a standard PLC library to read Wago free disk space?
There is no universally portable PLC filesystem-capacity call. Select a filesystem or storage interface documented for the installed Wago controller target and verify that it returns capacity, units, and operation status.
Does the free-space query need the log directory?
It must identify the filesystem volume containing that directory. A controller-wide or different-volume reading cannot safely control retention for the log destination.
Can I delete the oldest log as soon as space is low?
Delete only a closed, eligible file and protect the active log. Start deletion at a low threshold and stop only after crossing a higher recovery threshold.
Does deleting a file always release space immediately?
No. An open file handle can retain allocated storage after its pathname is removed, and capacity reporting may require another documented query cycle. Close the file, confirm deletion status, and query again.
Can I verify the retention logic without filling the PLC storage?
Use a controlled test threshold around the current valid reading. Write and close a test log, verify that reported space falls, trigger deletion of the oldest closed test file, and finish by verifying that reported space rises and logging resumes only beyond the recovery threshold.