Fixing CX-ConfiguratorFDT "Upload Not Supported" Error When Capturing PROFIBUS Topology

When an Omron PROFIBUS master is already in service and the engineering workstation still holds a partial or empty CX-ConfiguratorFDT project, the most common recovery attempt is the Upload from device action on the master DTMs (Device Type Managers). On Omron CPU + PRM (Profibus Master) combinations this action is often reported as "Upload not supported". This article documents the root cause, the FDT/DTM constraints that drive the message, and a sequence of field-proven workarounds that recover a complete PROFIBUS network topology from an Omron master without having to re-engineer the line from GSD files.

1. Problem Description

The field symptom is consistent across multiple sites:

1. The engineering PC contains a CX-ConfiguratorFDT project (file *.cpr or *.cpx) but the DTM tree for the PROFIBUS master has no slave children configured.
2. The PLC and PROFIBUS master are powered and online; the master reports RUN / OPERATE on its front-panel indicators.
3. The user opens the DTM context menu for the master and selects Upload from device (or Read from device depending on the localized build).
4. The container displays the dialog: "Upload not supported" (German: Hochladen nicht unterstützt, Italian: Caricamento non supportato), and no parameters are read back.

Side effects include the I/O table on the master being preserved (so the running process is not affected), but no offline replica of the live configuration can be regenerated. The project remains in a "headless" state: the master exists, but no slaves can be edited or replaced without GSD files.

1.1 Observable Indicator Pattern

2. PROFIBUS Topology Capture - Why It Is Harder Than It Looks

Capturing a complete PROFIBUS DP topology from a running master is a fundamentally different operation from reading, for example, the program of a Siemens S7 CPU. Three architectural reasons explain why:

1. PROFIBUS masters store the bus parameter set, not the slave catalogue. The master stores timing (TSL, TSET, TTR, min TSDR, max TSDR, GAP factor, retry), HSA (Highest Station Address), and the watchdog. It does not store a GSD-derived parameter image of each slave. The slave GSD is parsed by the engineering tool, not by the master firmware.
2. FDT is a configuration framework, not a parameter mirror. The FDT (IEC 62453) specification defines a container application that hosts DTMs. The DTM for a master exposes the master's online parameters, but it is not required to expose the slave DTMs that were originally configured. A "slave list" in the offline project is a project artefact, not a master artefact.
3. Auto-discovery is not a FDT mandatory function. Active station discovery (live scan of PROFIBUS addresses 0..HSA) is the domain of diagnostic repeaters (e.g. PROFIBUS Nutzerorganisation certified tools) and master class-2 diagnostic tools, not a standard DTM read.

The Siemens STEP 7 / TIA Portal "Upload station to PG" appears to perform automatic topology capture because the S7-300/400/1200/1500 DP master/CM modules carry an internal project signature (the system data block SDB container, types 0/1/2/3/5/6/7) that the engineering tool can rehydrate into GSD-typed slot objects. The Omron PRM21 does not implement this SDB mirror in the same form, so the equivalent reverse path is not present in the DTM.

3. Root Cause Analysis

The "Upload not supported" message is generated inside the DTM of the Omron master and surfaced by the FDT container. Three independent triggers can produce the same error text; the diagnostic path is therefore split into three branches.

3.1 Branch A - DTM Does Not Implement an Upload Channel

Most master DTMs shipped with CX-ConfiguratorFDT expose the following online channels:

• Connect / Disconnect
• Download to device (writes bus parameters and slave list)
• Online parameters (reads/changes a small set of live values)
• Diagnostic scan (when implemented by the slave DTM, not the master)

The Upload from device IPC channel is optional in FDT 1.2 / 2.0. When the master DTM does not implement FDT_LoadFromDevice for the configuration object, the container displays the localized "Upload not supported" string. This is the most common cause on PRM21 masters running DTM revision < 2.4.

3.2 Branch B - Upload Channel Present but Blocked by Signature

Some DTM revisions implement the IPC channel but require the offline configuration signature (the FDT version 2 "Configuration ID") to match the value stored in the master before they will return data. If the offline project was created on a different workstation, has been edited, or has never been downloaded, the signature check fails and the DTM returns the same generic message.

3.3 Branch C - Routing Failure Disguised as "Not Supported"

When the master is accessed through a CJ1/CJ2 CPU using the FINS gateway and the routing table is missing, the DTM receive times out. The DTM reports the timeout as a failure of the upload IPC channel, which the container may render as "Upload not supported" in localized builds. The actual fault is at the routing layer.

3.4 Diagnostic Flow

4. CX-ConfiguratorFDT and FDT/DTM Architecture

CX-ConfiguratorFDT is the Omron implementation of an FDT (Field Device Tool) container, embedded in the CX-One suite. Per the CX-Profibus Operation Manual (W05E-EN-02), an FDT container "facilitates configuration of network devices and parameterizing and/or manipulating their operational" data by hosting DTM plug-ins. Each slave is represented by a DTM (Device Type Manager); the master is itself represented by a DTM that owns the communication channel to the field device.

Architecturally:

• Container = CX-ConfiguratorFDT.exe (FDT 1.2 / 2.0 framework, depending on build)
• Master DTM = Omron-supplied DTM, registered under HKLM\SOFTWARE\OMRON\CX-Server\FDT (Windows) - ships with CX-One
• Slave DTMs = vendor-specific (e.g. Siemens, ABB, Phoenix Contact, Wago, SEW-Eurodrive, Beckhoff) installed per manufacturer
• GSD files = *.gsd and *.gsg (image/bitmaps) imported into the device catalogue

The container is responsible for the project tree on disk. The master DTM is responsible for the online channel. The two responsibilities are independent: a DTM that implements the FDT_LoadFromDevice service is not required to expose any slave data; the absence of the service is what the user perceives as "Upload not supported".

Reference the official CX-Configurator FDT product page for the FDT/DTM compatibility matrix and supported device list.

5. Step-by-Step Recovery Procedure

The recovery order is critical. Skipping the signature check or the routing check is the most common reason that engineers conclude the master is not uploadable and rebuild the project by hand.

5.1 Prerequisites

• CX-One version that matches (or is newer than) the version that originally programmed the master. Mixing older CX-One with newer firmware (or vice versa) is a leading cause of Branch B signature mismatches.
• Local administrator rights on the engineering PC (DTMs are registered COM servers).
• USB or serial cable (or Ethernet for CJ2 / CS1 with ETN21) that connects to the CPU.
• CX-ConfiguratorFDT project file *.cpr that contains at least the master DTM as a node.
• Original GSD library of all slaves on the bus (typically stored in C:\Program Files\OMRON\CX-One\CX-ConfiguratorFDT\DeviceLibrary or the slave vendor's installation directory).

5.2 Step 1 - Verify Container and DTM Versions

1. Open CX-ConfiguratorFDT.
2. Open the project containing the master DTM.
3. Right-click the master DTM node and select Device information (or DTM properties in localized builds).
4. Record the DTM Vendor, Device, and Version fields.
5. Compare with the version installed in the registry under HKLM\SOFTWARE\OMRON\CX-Server\FDT\Master\<device id>. If versions differ between the project and the registry, update the project (right-click project root > Update DTM).

5.3 Step 2 - Verify the Communication Channel

1. Right-click the master DTM and select Connect.
2. Confirm the icon turns "online" (typically green).
3. Open the master's Online parameters tab and read at least one parameter (e.g. Highest Station Address (HSA)).
4. If Connect or the parameter read fails, jump to Section 5.4 (routing). If it succeeds, continue to Section 5.5 (signature check).

5.4 Step 3 - Branch C Routing Repair (CJ/CS Series)

For CJ1/CJ2/CS1 CPUs the PROFIBUS master is reached through the CPU's routing table. To verify and rebuild the table:

1. Open CX-Integrator (part of CX-One).
2. Go online to the CPU.
3. Select Tools > Routing Table.
4. Compare the table with the known topology. Typical CJ1W-PRM21 routing entries are:

5. If entries are missing, click Insert, populate the rows, and Transfer to PLC.
6. Cycle the PRM21 (power-down/power-up) so it re-reads the routing table from the CPU.
7. Return to CX-ConfiguratorFDT and re-attempt Connect.

5.5 Step 4 - Branch B Signature Realignment

If the channel is healthy but the upload still fails:

1. Perform a Download from the offline project to the master. This re-stamps the configuration signature in the master with the signature of the offline project. The download can be done with the live process running, as long as the bus parameters are identical to those currently in service.
2. After the download completes, perform the Upload from device action again. The DTM will see a matching signature and may now return the configuration.
3. If the offline bus parameters do not match the live ones, the download will refuse to proceed. In that case use the Compare function to identify the bus parameter delta; the typical cause is a different TSL calculation between project and live.

5.6 Step 5 - Branch A Manual Rebuild From GSD

If Branch A applies (DTM does not implement upload), the topology must be rebuilt from the GSD files. The procedure is deterministic:

1. Enumerate the live PROFIBUS addresses by performing a Live scan with a class-2 diagnostic tool. If none is available, walk the bus and read the address switches on each slave's front panel.
2. For each live address, identify the slave vendor and order code. Cross-check the order code against the vendor part number on the device label. The order code is the only reliable key to the GSD file (revision-aware: e.g. ET200S 6ES7153-1AA03-0XB0 uses a different GSD than 6ES7153-1AA00-0XB0).
3. Import the matching GSD into CX-ConfiguratorFDT via Device Catalogue > Update / Add.
4. Insert a slave DTM under the master DTM in the project tree.
5. Assign the address and slot/channels as observed in the live system. If a class-2 diagnostic capture is available, use the slot assignment recorded there.
6. Repeat for every address. Verify the total number of configured slaves matches the master's Number of configured slaves counter (read from the master's Diagnostic tab while online).

5.7 Step 6 - Verify Bus Parameters Against Live

With the topology rebuilt, compare the offline bus parameters to those observed live. The critical parameters are:

Where T_BIT is one bit time at the configured baud rate. The bit time in microseconds is:

T_BIT [µs] = 1 000 000 / (baud rate [bit/s])

For 1.5 Mbit/s, T_BIT = 0.667 µs. For 500 kbit/s, T_BIT = 2 µs. For 187.5 kbit/s, T_BIT = 5.333 µs.

6. PROFIBUS Standards Reference

PROFIBUS DP (IEC 61158 / IEC 61784) defines the line configuration constraints that the rebuilt project must respect. According to the Siemens TIA Portal V20 PROFIBUS line configuration documentation:

A maximum of HSA-1 nodes may be connected to the PROFIBUS network. With an HSA of 126, addresses 126 and 125 must not be used. A maximum of 125 nodes are usable on a single segment when the master itself occupies address 0..(HSA-1).

These limits apply to the rebuilt project as well; the DTM tree must show only addresses 1..(HSA-1), and the master DTM must be configured with an HSA that bounds the highest assigned slave address.

7. Comparison With Siemens S7 Upload Behaviour

Engineers familiar with Siemens STEP 7 or TIA Portal expect "Upload station to PG" to recover the complete DP topology. The following table summarises where the platforms differ.

The architectural difference is the SDB container in the S7-CPU/CP. PROFIBUS SDBs are typed data blocks (types 0, 1, 2, 3, 5, 6, 7) that store the bus parameter set, the slave list, and the GSD-derived slot configuration. The Omron PRM21 stores bus parameters but does not store a typed SDB container that an FDT DTM can rehydrate, so the upload path is by design not a full project mirror.

8. Verification Procedure

After the offline project is rebuilt (either via successful upload or via manual GSD rebuild), verify the result end-to-end:

1. Compile the project in CX-ConfiguratorFDT. A successful compile confirms that all slave DTMs have valid parameters, no GSDs are missing, and no address conflicts exist.
2. Connect to the master and open the Compare function. The result must show 0 differences between offline and online for the bus parameters.
3. Check the slave list count. The master's Diagnostic tab reports the number of slaves currently in data exchange. This must equal the number of slave DTMs in the offline project tree.
4. Check the cyclic IO. From CX-Programmer or a class-2 diagnostic, force a bit on a slave and verify it appears in the input area assigned by the slave DTM. This confirms the slot/channel mapping of the rebuilt project matches the live configuration.
5. Save and archive the project (*.cpr and any slave vendor GSDs) in version control with a tag note that includes the master serial number and CPU serial number for traceability.

8.1 Quick Verification Checklist

9. Field-Commissioning Notes and Edge Cases

9.1 Mixed Vendor Slaves

When a line mixes vendors (e.g. Siemens ET200S, Wago 750-3xx, Phoenix Contact Inline, SEW Movimot, ABB ACS880 via RPBA-01), the GSD collection must include every vendor's GSD. The recommended practice is to maintain a gsd_library\ folder per project and import the entire folder, not individual files, so that slave DTM updates from a vendor do not silently break the project.

9.2 Spare Slave Hot-Swap

Most PROFIBUS DP slaves are not hot-swappable without a topology rebuild. The proper procedure is:

1. Document the new slave's order code and DIP address.
2. Insert a new DTM in the offline project and assign the address.
3. Download the new slave's parameters to the master (this does not disturb existing slaves' data exchange).
4. Power up the new slave; the master will register it on the next bus cycle.

9.3 Old Project From Different CX-One Version

Projects saved with CX-One version V3 (CX-ConfiguratorFDT 1.x) are opened in newer V4 (CX-ConfiguratorFDT 2.x) with a conversion prompt. After the conversion, slave DTMs may have updated to a newer major version, and the Update DTM action is required before any online action. Failure to update is the most common cause of the "Upload not supported" message after a CX-One upgrade.

9.4 Long Cable Runs and TSL Recalculation

If the live system includes repeaters and long cables, the master auto-recalculates T_SL from the bus parameters. When the offline project is rebuilt with default T_SL, the first download will replace the live value and may cause intermittent slave timeouts. Always read the live T_SL from the master before saving the rebuilt project.

9.5 When All Else Fails - Documented Phone Path

For projects where the rebuild is high-risk (validated process, regulated industry, large line with 50+ slaves), the documented escalation path is Omron technical support via the regional Omron industrial automation office. Reference the FDT/DTM revision number and the Upload not supported error verbatim. CX-ConfiguratorFDT technical support is a paid engagement through regional Omron offices; on-site rebuild assistance is typically available on a time-and-materials basis.

10. Summary of Error-to-Cause Mapping

11. Frequently Asked Questions