WAGO 750-881 FTP Client: Fixing DLOG_FILE_TO_FTP Timeouts

Problem Details

A WAGO 750-881 Ethernet controller programmed in CoDeSys 2.3.9.22 is used to push a CSV log file to an in-house NAS running an FTP server. The application writes the log with DLOG_TO_CSV and then attempts to upload it with the FTP client file-transfer block (DLOG_FILE_TO_FTP-style call) taken from the WAGO network library.

Observed symptoms:

• The transfer block returns an error indicating a timeout while establishing the data connection from the PLC to the FTP server. The control connection is accepted; the data channel never completes.
• The ftp_client_demo project shipped in the demo folder of the network library works against the same NAS, from the same controller.
• A conventional FTP client (PC) logs in to the NAS with the same credentials and path without problems.
• A download executed by the controller succeeds when only a bare file name is supplied — the file lands in the controller's /PLC directory.

Parameterization in use:

ftp_url      : STRING := 'ftp://wago:[email protected]/nWAGO/';
ftp_filename : STRING := '..\log\test.txt';

Controller file system (default directories plus one user-created folder):

/
/etc
/LOGS      (created manually via FTP client)
/PLC       (target of DLOG_TO_CSV)
/webserv

Root Cause Analysis

1. Passive-mode data connection timeout

The reported error is a connect timeout on the data socket opened by the PLC toward the server. That direction of connection establishment is characteristic of passive mode: the server answers PASV with an IP address and port, and the client then opens the data connection to that endpoint. A timeout therefore means the IP/port pair returned by the server, or the port the stack actually dialed, is not reachable from the controller.

Typical contributors, in the order worth checking:

2. FTP server (port 21) enabled on the controller

The 750-881 runs its own FTP server on TCP 21 by default. Disabling that service in Web-based Management under Port → Port Settings has resolved comparable cases where a library client function on the same controller failed while equivalent third-party access worked. The same pattern has been observed with Modbus library functions that only started working after the built-in Modbus service was deactivated in the controller. Treat this as a service/port contention test, not a documented behavior.

3. Path syntax on both ends

Two independent path questions are being mixed in the failing parameterization:

• Local (controller) path — '..\log\test.txt' uses a relative parent reference and backslashes. The successful download proved that a bare file name resolves correctly and lands in /PLC. On classic controllers the local file argument is simply 'logfile.csv', because there is effectively one root folder for files. A relative '..\' prefix and access to directories outside /PLC are not confirmed to be supported by the file-transfer block.
• Remote (server) path — ftp://wago:[email protected]/nWAGO/. The directory nWAGO and the password beginning with a period were both verified as correct against a desktop FTP client, and replacing the password with one containing no period did not change the result. So the URL string is not the primary fault, but a leading . in a password inside a URL-form credential string is still worth eliminating during bisection.

4. File name case handling

The controller's file system treats case asymmetrically in practice:

If the transfer block opens the source file by a name whose case does not match what is actually on the media, the local open fails before any useful FTP dialogue takes place — a different failure mode than the data timeout, but one that masks progress during trial-and-error.

Solution: Bisect from the Working Demo

The ftp_client_demo in the demo folder of the network library is the reference implementation. Do not debug the application block in isolation; migrate it toward the demo one parameter at a time.

1. Confirm the baseline. Run ftp_client_demo unchanged against 192.0.6.200 with the production credentials and record the returned status/error codes. This proves credentials, routing, DNS-free addressing, and library version.
2. Flatten the local file argument. Replace '..\log\test.txt' with a bare name, e.g. 'test.txt', and place the file in /PLC. Have DLOG_TO_CSV write directly into that same directory rather than into a separate /LOGS tree.
3. Normalize case. Use one case convention in the source that generates the file and in the transfer parameter. Verify the on-disk name with an FTP client listing of /PLC before blaming the network.
4. Disable the controller's FTP server. In Web-based Management open Port → Port Settings, switch off FTP (TCP 21), save, and retest the block. Re-enable it afterward only if you still need inbound FTP to the controller.
5. Eliminate password/URL edge cases. Test once with a password containing only alphanumerics and no leading period, and once with the remote path written both with and without the trailing slash (/nWAGO/ vs /nWAGO).
6. Force the transfer mode explicitly. If the block exposes a passive/active selector, set it to match the mode the demo uses. If the NAS is on the same subnet, active mode removes the 227-address dependency entirely.
7. Capture the traffic. If steps 1–6 do not resolve it, take an unfiltered Wireshark trace on a mirrored port and record the PLC IP, gateway/router IP, NAS IP, and any DNS server in use. Read the 227 reply and check whether the PLC's subsequent SYN goes to a reachable address and receives a SYN/ACK.

Reference parameterization after flattening

(* Local source file: bare name, resolves to the controller's PLC directory *)
ftp_filename : STRING := 'weather_xx.csv';

(* Remote target: explicit IP, no DNS dependency *)
ftp_url      : STRING := 'ftp://wago:[email protected]/nWAGO/';

(* Verify the source file exists with EXACTLY this case before enabling xExecute *)

Verification

Operating Notes for the 750-881 File System

• /PLC is the working directory for application-generated files; a download initiated by the controller with a bare file name lands there. Treat it as the default root for the file-transfer block.
• /etc and /webserv are system directories. Do not use them as log destinations.
• A user-created folder such as /LOGS is visible to a PC FTP client but is not confirmed to be reachable from the file-transfer block. Prove access with a bare-name test in /PLC first, then extend.
• Uploading a file to the controller from a PC FTP client can force the name to uppercase. Application logic that later opens that file by mixed-case name will fail to find it.
• Log files written by DLOG_TO_CSV retain the case supplied in the program, including any leading directory component in the name string.
• Keep the FTP endpoint on the local network addressed by IP. An internal NAS target removes DNS resolution and any WAN NAT translation from the failure set.

FAQ