Writing XML Files from S7-1200/1500 PLCs to a Network Server

Overview: The XML-on-PLC Problem

Siemens SIMATIC S7-1200 and S7-1500 controllers do not provide a native file-system service that maps a UNC path such as \\server\EDV\machine_no\part_xyz.xml as a logical drive to which the user program can stream an XML document. The S7-1200/1500 user program operates on bit memory, data blocks, I/O areas, and on the controller's own load memory; it has no Windows-style file API. The WinCC Runtime Professional PC-based HMI/scada layer, in contrast, can read and write Windows file paths directly through VBScript or C-script, which is why most published solutions show WinCC RT as the file producer.

For a PLC-only architecture, the engineer must therefore select from one of the following transport mechanisms, each of which has its own hardware, firmware, and licensing profile:

• OPC UA XML server interface on the S7-1500 (firmware V2.6 or later for the basic server, V2.9 or later for the FileType object and Companion Specifications). The S7-1200 supports an OPC UA server from firmware V4.4.
• FTP client push from a CP 1543-1 communications processor (6GK7543-1AX00-0XE0 for S7-1500) or CP 1243-1 (6GK7243-1BX30-0XE0 for S7-1200) to a remote FTP/FTPS server.
• Programmatic XML generation as a character buffer in a DB, transmitted via the Open User Communication (OUC) instructions TCON/TSEND/TRCV, TFTP, or OPC UA method call.
• Industrial Edge S7 Connector XML export on an Edge runtime IPC, which reads PLC tags and writes XML to a local file system share.

The trade-off is consistent: OPC UA is the cleanest fit for standardised machine-to-machine data exchange, FTP via the CP 1543-1 is the most direct fit for depositing files to a server path, and programmatic generation is the cheapest in hardware terms but the most maintenance-heavy in engineering time. The Siemens Online Support entry 81367009 documents the FTP route, and entry 103550797 documents the TCON/TSEND route. Both are valid starting points.

Native XML Handling in the S7-1200/1500 Runtime

The TIA Portal V20 documentation makes the rule explicit: SIMATIC S7 controllers do not provide a runtime XML parser or generator. The XML files that can be consumed by a TIA Portal project are limited to:

• OPC UA server interface definitions (Nodeset2 XML).
• GSD/GSDML files for PROFINET device descriptions.
• TIA Portal project export/import bundles (the .tiaz archive that contains XML manifests).

Within the runtime of the controller, however, the user program can treat a sequence of characters in a DB as an XML payload. There is no built-in BuildXml instruction. The engineer constructs the string in SCL or STL using CONCAT, MID, LEFT, RIGHT, and character-by-character assignment, then writes the string to a transport (FTP STORE, TCP send, OPC UA write, or PG/PC route).

The TIA Portal V20 documentation on OPC UA explicitly states the rules for OPC UA XML files: the namespace http://www.siemens.com/simatic-s7-opcua is reserved for Siemens-specific extensions, and the namespace http://opcfoundation.org/UA/ is the OPC Foundation base. When the controller exposes variables as an OPC UA server, the TIA Portal generates the Nodeset2 XML automatically from the configured server interface; the runtime does not store or read user-defined XML, and the OPC UA client must consume the published variables or call the published methods. See the TIA Portal V20 - Rules for OPC UA XML files (S7-1500, S7-1500T) for the complete namespace table.

Method 1 - OPC UA XML Server Interface (S7-1500)

The S7-1500 OPC UA server exposes data block tags, PLC tags, and method calls to an OPC UA client. The server interface is configured in TIA Portal under Properties > OPC UA > Server. The server generates an XML Nodeset2 file at compile time, but the runtime behaviour is variable publication: a client reads the variable's value over the wire, not an XML file.

For a "write an XML file to a server" requirement, the OPC UA route is therefore indirect. The supported patterns are:

1. Publish the XML as a STRING variable. The user program builds the XML in a DB of type STRING[nnnnn] and exposes that tag through the OPC UA server. A client (e.g. a Python or C# script on the server PC) subscribes to the variable and writes the file to the local disk. This pattern works on S7-1500 firmware V2.6+ and S7-1200 firmware V4.4+.
2. Expose a method that returns the XML. The OPC UA client calls a method on the server, the server's SCL function builds and returns the XML, and the client writes the file. This pattern requires an OPC UA method implementation in the user program and is supported on S7-1500 firmware V2.9+.
3. Use the OPC UA FileType object (Part 20 of the OPC UA specification). The S7-1500 firmware V2.9+ exposes the controller's web server directory as a file system. A client can Create/Write/Read/Delete files in that directory. The user program must move the file to the network share using a separate FTP or UNC path mechanism; the FileType object alone does not push to a remote share.

None of the three patterns place a file on a remote Windows share from the controller alone. The OPC UA server on the S7-1500 is, in the strict sense, a data publisher, not a file depositor.

OPC UA Server Configuration Parameters

Method 2 - FTP Client on CP 1543-1 (S7-1500) and CP 1243-1 (S7-1200)

The CP 1543-1 (6GK7543-1AX00-0XE0) for S7-1500 and CP 1243-1 (6GK7243-1BX30-0XE0) for S7-1200 provide an integrated FTP/FTPS client that can be triggered from the user program. The CP maintains the TCP connection, the FTP protocol state machine, and the SSL/TLS handshake; the user program calls a function block and supplies the file source (a DB buffer on the controller's load memory) and the remote path.

Hardware and Firmware Prerequisites

TIA Portal FTP Configuration

1. Insert the CP in the device view of the S7-1500 rack or S7-1200 left-side slot.
2. Open Properties > FTP.
3. Enable the FTP client role and assign the user program to a connection ID (1..16).
4. Enter the FTP server address, port (default TCP 21, implicit FTPS 990), user name, password, and transfer mode (active or passive). For NAT/firewall traversal, passive mode is almost always required.
5. Select the security profile: None (plain FTP), Explicit FTPS (FTPES) (AUTH TLS on port 21), or Implicit FTPS (TLS on port 990).
6. Compile the project and download the configuration to the CP. The CP retains the FTP connection parameters in non-volatile memory; the user program supplies only the file name and trigger.

User Program: FTP_STORE Block

The TIA Portal provides the FTP_CMD function block in the "Communication" library, and Siemens Online Support entry 81367009 documents a reusable FTP_STORE pattern. The block parameters are:

SCL Example: FTP Upload Triggered by Cycle Counter

// Build the XML string in the DB
"DB_XML_Buffer".xml_data := '';
"DB_XML_Buffer".xml_data := CONCAT(IN1 := '',
                                    IN2 :='<PartData timestamp="',
                                    IN3 := DWORD_TO_STRING(TIME()) );
"DB_XML_Buffer".xml_data := CONCAT(IN1 := "DB_XML_Buffer".xml_data,
                                    IN2 := '">');
"DB_XML_Buffer".xml_data := CONCAT(IN1 := "DB_XML_Buffer".xml_data,
                                    IN2 := '<PartNo>',
                                    IN3 := "DB_Part".part_no);
"DB_XML_Buffer".xml_data := CONCAT(IN1 := "DB_XML_Buffer".xml_data,
                                    IN2 := '</PartNo><Cycle>',
                                    IN3 := INT_TO_STRING("DB_Part".cycle_count));
"DB_XML_Buffer".xml_data := CONCAT(IN1 := "DB_XML_Buffer".xml_data,
                                    IN2 := '</Cycle></PartData>');

// Save the buffer to the memory card first
"FileWrite".REQ  := TRUE;
"FileWrite".FILE := '/xml/buffer.xml';
"FileWrite".DATA := "DB_XML_Buffer".xml_data;

// Trigger FTP upload once the file is committed
IF "FileWrite".DONE THEN
    "FileWrite".REQ := FALSE;
    "FTP_CMD".REQ        := TRUE;
    "FTP_CMD".ID         := 1;
    "FTP_CMD".CMD        := 5;        // STORE
    "FTP_CMD".LOCAL_FILE := '/xml/buffer.xml';
    "FTP_CMD".REMOTE_FILE:= '/EDV/machine_no/part_xyz.xml';
END_IF;

IF "FTP_CMD".DONE OR "FTP_CMD".ERROR THEN
    "FTP_CMD".REQ := FALSE;
END_IF;

Method 3 - Programmatic XML Generation in a DB

The cheapest method in hardware terms (no CP module, no Industrial Edge, no PC) is to build the XML character-by-character in a DB and transmit it through the standard Open User Communication instructions. The trade-off is engineering effort: every field added to the XML schema requires a CONCAT line in SCL and a corresponding entry in the documentation. For static reports with a fixed schema, this is manageable; for dynamic or user-defined schemas, the cost of building and maintaining the generator quickly exceeds the cost of a CP 1543-1.

DB Layout for the XML Buffer

DATA_BLOCK "DB_XML_Buffer"
{ S7_Optimized_Access := 'TRUE' }
AUTHOR : eng
FAMILY : xml
VERSION : 1.0
  STRUCT
    xml_data : STRING[50000];   // 50002 bytes
    xml_len  : DINT;            // current length in chars
    template_id : INT;          // 0=full, 1=delta, 2=alarm
    error_code : WORD;
    busy : BOOL;
    done : BOOL;
  END_STRUCT;
END_DATA_BLOCK

For buffers larger than 50000 characters, use ARRAY[0..n] OF BYTE with manual length tracking; STRING in TIA Portal is limited to 254 bytes for the classic non-optimised type and 65534 characters in the optimised STRING[n] type. For larger payloads, switch to the BYTE array approach with a MID/LEFT/RIGHT sequence on a STRING wrapper.

SCL String Builder Patterns

// Pattern 1: numeric to string
"DB_XML_Buffer".xml_data := CONCAT(IN1 := "DB_XML_Buffer".xml_data,
                                    IN2 := '<Temp>',
                                    IN3 := REAL_TO_STRING("DB_Process".temperature),
                                    IN4 := '</Temp>');

// Pattern 2: escape special characters
"DB_XML_Buffer".xml_data := CONCAT(IN1 := "DB_XML_Buffer".xml_data,
                                    IN2 := '<Name>',
                                    IN3 := "DB_Process".part_name_escaped, // pre-escaped
                                    IN4 := '</Name>');

// Pattern 3: nested element with attribute
"DB_XML_Buffer".xml_data := CONCAT(IN1 := "DB_XML_Buffer".xml_data,
                                    IN2 := '<Measure id="M1" unit="mm">',
                                    IN3 := REAL_TO_STRING("DB_Process".dim1),
                                    IN4 := '</Measure>');

Transmitting the Buffer over OUC

For TCP-based transmission to a custom server, the user program uses the TCON/TSEND/TRCV instruction set from the standard TIA Portal library. The XML buffer is the DATA pointer of TSEND. Siemens Online Support entry 103550797 provides a complete TCON/TSEND sample for the S7-1500 with active connection establishment, LEN, and DONE/ERROR handling.

"TSEND_DB".REQ   := TRUE;
"TSEND_DB".ID    := 1;
"TSEND_DB".LEN   := "DB_XML_Buffer".xml_len;
"TSEND_DB".DATA  := "DB_XML_Buffer".xml_data;
"TSEND_DB".DONE  := ... ;   // user program checks
"TSEND_DB".ERROR := ... ;
"TSEND_DB".STATUS:= ... ;

Method 4 - Industrial Edge S7 Connector XML Export

The Industrial Edge S7 Connector runs on an Industrial Edge runtime (IPC with the IE runtime installed) and pulls tag values from the S7-1500/S7-1200 over S7 communication or OPC UA. The Common Configurator exports the tag list as an XML file, which the connector can then forward to a local file system, an MQTT broker, or an OPC UA client. The XML file export - SIMATIC S7 Connector - Industrial Edge documentation describes the workflow: compile the TIA Portal project, navigate to the desired PLC's tag list, right-click and select Export file, save as XML, import the XML into the S7 Connector Common Configurator, map the tags, and configure the export target.

This method requires an Industrial Edge IPC in the architecture, which re-introduces the PC the original question sought to avoid. It is the right answer when the customer already has Industrial Edge infrastructure (data lake, containerised apps, Edge apps for analytics), but it is not a PLC-only solution.

Network Architecture - Subnets, Routers, Static IPs

The source question places the PLC and the server in different subnets, with a programmable router (e.g. SCALANCE M876-4, MUM-800, SC646-2C) in between. The relevant design rules for each transport are:

Memory and Performance Considerations

The figures are rough wall-clock measurements of a single 50 KB string build with ten CONCAT calls on a warm controller. A 50 KB XML payload transferred over 100 Mbit/s Ethernet takes approximately 4 ms wire-time (excluding TCP handshake and FTP protocol overhead). An OPC UA publish of a 50 KB STRING variable with the Basic256Sha256 security profile on a S7-1515 takes 50-200 ms per call. For cycle-by-cycle XML generation, prefer to assemble the buffer in a low-priority OB (e.g. OB1 in a slow task) and trigger the FTP/TCP push on a part-completion event, not in the fast OB.

Step-by-Step: FTP Upload with CP 1543-1

1. Add the CP 1543-1 to the S7-1500 rack and connect its PROFINET port X1 to the PLC subnet switch.
2. Configure the CP's IP address (e.g. 192.168.1.10/24) and the default gateway to the SCALANCE router (e.g. 192.168.1.1).
3. Open Properties > FTP on the CP, enable the FTP client, and enter the FTP server address (e.g. 192.168.10.5), port 21, user name, password, and transfer mode (passive recommended).
4. Compile and download the hardware configuration to the CPU and CP.
5. Create DB DB_XML_Buffer with a STRING[50000] field and a DINT length field.
6. Create a user FC that builds the XML in DB_XML_Buffer using CONCAT, with character escaping for any user-supplied text.
7. Create the FTP upload instance: drag FTP_CMD from the Communication library, assign the connection ID configured in step 3, and wire REQ/CMD/LOCAL_FILE/REMOTE_FILE.
8. Save the buffer to the memory card with the FileWrite FB (path /xml/buffer.xml).
9. On the FTP server (e.g. FileZilla Server, IIS FTP, vsftpd), create the destination directory /EDV/machine_no/ and set write permissions for the configured user.
10. Download the user program and test with a trigger from the watch table.
11. Verify on the FTP server that the file appears with the expected size and content.

Step-by-Step: Programmatic XML Build in SCL

1. Create DB DB_XML_Buffer as above (STRING[50000], DINT length, INT template id).
2. Create an FC XML_Reset that sets xml_data := '' and xml_len := 0.
3. Create an FC XML_Append with inputs tag_in : VARIANT and tag_format : INT (0=raw, 1=escape) that calls CONCAT to append the converted tag to the buffer and updates xml_len.
4. Create an FC XML_Escape that scans an input STRING and replaces < with <, > with >, & with &, " with ", and ' with '.
5. Create an FC XML_Build that calls XML_Reset, then a sequence of XML_Append calls for each schema element, then closes the root element.
6. Trigger XML_Build from a part-completion event in the user program.
7. Save the buffer to a file on the Memory Card with FileWrite, then trigger the FTP push (Method 2) or a TCP push (Method 3 transport) to the server.

Commissioning and Verification

1. CP-to-server reachability. Open the CP's web interface (https://192.168.1.10) and run the diagnostic ping to the FTP server address. A successful ping confirms the IP route and the ACL.
2. FTP authentication. Use a Windows FileZilla client with the same user credentials and confirm login from a PC on the PLC subnet. If FileZilla fails, the credentials or the server are wrong; the CP will report the same failure as STATUS 8 (auth) or 10 (connection refused).
3. First upload. Trigger the FTP upload from the watch table and confirm DONE=TRUE. On the FTP server, check the file modification time and size.
4. Well-formed XML check. Download the file and open it in a browser or in xmllint --noout file.xml. The browser must render the file as a structured document, not a raw text view.
5. Variable value check. Cross-check the part number, cycle count, and timestamp in the XML against the corresponding PLC tags in the watch table.
6. Time synchronisation. Verify the controller's time (CPU Properties > Time of Day) is synchronised via NTP. The CP 1543-1 supports NTP client from firmware V2.0+; configure the NTP server under Properties > Time.
7. Security policy check. If FTPS is in use, confirm the certificate chain on the server is valid and that the CP's trust store contains the CA. A self-signed server certificate must be imported into the CP's trust store, or the handshake fails with STATUS 0x8A (TLS alert).
8. Throughput and load. Trigger 100 uploads in a loop and observe the OB1 cycle time. If the cycle time increases by more than 5 ms, consider moving the XML build to a cyclic OB (e.g. OB30 at 1 s) instead of OB1.

Troubleshooting Matrix

Selecting the Right Method for the Application

For a static XML schema (e.g. one record per part, fixed fields), the FTP route with the CP 1543-1 is the lowest-risk, most maintainable choice. For a dynamic schema (e.g. user-defined data points per machine), the programmatic OUC route gives the most flexibility but requires the most engineering discipline. The OPC UA route is the best fit when a downstream SCADA/MES system is already in place to consume the published variable or call the published method. The Industrial Edge route is the right answer when the customer has already invested in the IE ecosystem.