The observed failure is specific: DLOG_FILE_CSV_FTP_DEMO creates the first CSV file on the FTP server, but no subsequent file appears. The evidence does not establish whether the block should create a new file periodically, overwrite an existing file, or require a manual transfer trigger. Diagnose the communication path and the unchanged demo before changing logging or transfer logic.
Separate FTP Failure from a TCP/IP Failure
First determine whether only the FTP client fails or all TCP communication fails. If other TCP functions also fail, investigate the PLC network configuration rather than treating the data-logging block as the root cause. Confirm that the PLC uses the router address as its gateway.
| Observation | Diagnostic direction |
|---|---|
| All TCP communication fails | Check the PLC gateway and the optional IP_CONTROL parameters in the global variables. |
| Other TCP communication works | Focus on the FTP client, its status outputs, and the conditions that request another transfer. |
| Unchanged demo works | Compare every application modification with the original demo. |
| Unchanged demo also fails | Capture diagnostics and verify the PLC, software, and library versions. |
Validate the Demo Network Configuration
The demo configuration includes optional IP_CONTROL parameters in global variables and uses 8.8.8.8 as its DNS address. Keep that DNS value unchanged while reproducing the original demo so that configuration changes do not add another variable. DNS correctness alone does not prove FTP connectivity; the gateway and the broader TCP path must also work.
Do not assume that creation of the first CSV proves the recurring transfer sequence is configured correctly. It confirms only that one file reached the server. The supplied evidence contains no transfer interval, trigger definition, filename-generation rule, or block error code.
Run a Controlled Isolation Procedure
- Run the original demo without application changes and record whether it creates more than one file. The original demo was reported to create files successfully in another test.
- Check whether any other TCP communication from the same PLC works. If none works, verify the router gateway and the optional
IP_CONTROLsettings. - Record the exact PLC model, engineering software, OSCAT Basic library version, and OSCAT Network library version. The available evidence does not identify them, so compatibility cannot yet be assessed.
- Inspect and record all status and error indications exposed by the involved blocks when the second transfer should occur.
- Capture the network traffic with Wireshark. Determine whether the PLC opens another connection, issues another FTP exchange, receives an error response, or sends no follow-up traffic.
Interpret the Verification Results
If no follow-up network traffic leaves the PLC, inspect the application-side transfer request and any scheduling or manual-trigger condition. If a new connection attempt appears but fails, use the captured exchange and block diagnostics to distinguish routing, name-resolution, server, or FTP-client failure. If the unchanged demo repeatedly transfers files but the modified project does not, compare the changes affecting triggers, configuration, and file handling.
Declare the issue resolved only after the intended trigger produces another observable FTP exchange and the expected additional server-side file behavior. Because the evidence does not define whether the expected behavior is a new filename or an updated file, verify that requirement against the actual demo logic before using file count as the sole acceptance criterion.
FAQ
Why does DLOG_FILE_CSV_FTP_DEMO upload only one CSV file?
The evidence does not identify one confirmed cause. Test the unchanged demo, determine whether another transfer is requested, and correlate block diagnostics with a Wireshark capture.
What network settings should I check for the OSCAT FTP demo?
Verify that the PLC uses the router as its gateway and review the optional IP_CONTROL parameters in the global variables. The demonstrated DNS address is 8.8.8.8.
What information is needed to diagnose an OSCAT FTP failure?
Record the PLC model, engineering software, OSCAT Basic and Network library versions, all block errors or status indications, whether other TCP communication works, and the relevant Wireshark trace.