Reading Unlocated Variables from Modicon Concept PLCs via Modbus

Overview

Modicon Concept programming software (legacy Schneider Electric / Groupe Schneider tool used on Quantum, Compact, and TSX Micro PLC families) supports two distinct categories of variables: located and unlocated. Located variables are mapped to one of the four Modbus logical address spaces (0x coils, 1x discrete inputs, 3x input registers, 4x holding registers) and can be read by any standard Modbus master, HMI, or SCADA driver using function codes 01/02/03/04/05/06/15/16.

Unlocated variables exist only in the PLC's internal variable database; they have no Modbus address and are not exposed through the standard Modbus transaction layer. This article documents why that limitation exists, the only supported workaround (the OFS OPC Factory Server, part number TLXCDOFS25M), and the practical alternative of converting unlocated variables to located variables using Concept's online/offline address assignment.

Modbus Logical Address Space Recap

Standard Modbus masters can address only variables mapped to one of the following logical address families. Any variable that does not have a binding in one of these families is invisible to a generic Modbus driver.

Every Concept variable that should be reachable via a plain Modbus TCP/IP, Modbus RTU, or Modbus Plus transaction must have an address prefix from the table above. Variables declared without a prefix are unlocated and remain confined to the PLC's runtime variable database.

What Are Unlocated Variables?

In Concept, an unlocated variable is declared by name and data type (BOOL, INT, DINT, REAL, STRING, ARRAY, user-defined structure) without binding it to a %MW, %M, %IW, or %I address. Concept stores these variables in an internal symbol table that is referenced only by the project binary uploaded by the programmer's terminal.

The design intent of unlocated variables is performance and project hygiene:

• PLC scan efficiency. Unlocated variables are processed by the Quantum/Compact CPU without being copied to the located-memory map. In tight loops, this reduces the scan overhead of register mirroring.
• Memory conservation. Large internal scratchpads (recipe staging buffers, intermediate calculations, multi-byte arrays) can be declared without consuming 4x register space that would be wasted on external clients.
• Encapsulation. Internal-only logic can be written against symbolic names without leaking implementation addresses into HMI tag databases.

Why Standard Modbus Cannot Read Unlocated Variables

A Modbus master reads registers by issuing function code 03 (Read Holding Registers) or 04 (Read Input Registers) with a 16-bit starting address and a 16-bit quantity. The slave firmware interprets the address as an offset into the 4x or 3x memory image. Unlocated variables never populate that image; they exist only inside the Concept project's symbol table.

Concept stores the variable name, type, and value inside the PLC application's internal database, accessible only through the Concept programmer's online debug session (via Modbus Plus, Ethernet TCP, or serial) using the proprietary Concept/CC2CAT project-linking protocol. The standard Modbus server inside the CPU has no knowledge of the symbol table — it sees only the located register image. Attempting to read an unlocated variable through FC03/FC04 simply returns the value at the requested 4x/3x address (typically 0 if unused).

This is why every third-party OPC/MQTT/Modbus gateway that wraps the standard Modbus PDU cannot expose unlocated variables, regardless of how thoroughly it scans the address range.

Supported Workaround: OPC Factory Server (OFS)

Schneider Electric's OPC Factory Server (OFS), historically branded TLX CD OFS, is the only OPC DA server that resolves the Concept project symbol table and exposes both located and unlocated variables to any OPC client.

OFS Product Identification

OFS Architecture and Data Path

OFS combines three internal components to resolve unlocated symbols:

1. CC2CAT linker. Parses the Concept project (.PRJ / .STA) export, builds an internal symbol→memory map, and pairs it with the runtime variable database on the PLC.
2. Modbus/Modbus Plus/Modbus TCP channel. Communicates with the PLC using the same physical layer as a generic driver, but uses the Concept project-linking PDUs to fetch the symbol table and current values.
3. OPC DA server interface. Exposes each symbol as an OPC item with full browse, read, and write (subject to PLC write privileges) capabilities.

Any OPC client (Citect, iFIX, WinCC, FactoryTalk, custom .NET/Excel OPC DA consumer) can then subscribe to unlocated tags by browsing the OFS namespace or by typing the symbolic path.

Installing and Commissioning OFS

1. Install OFS V2.5 on a Windows host with the Schneider TLXCDOFS25M license key. The installer places the OFS Configuration console and the OPC DA service.
2. Export the Concept project (File → Export → Project). The exported bundle includes the .STA application and the symbol database.
3. Run CC2CAT to translate the Concept export into an OFS-readable symbol file. CC2CAT is bundled under the OFS program group and is invoked as CC2CAT.exe -i concept_export.sta -o ofs_symbols.xml.
4. Launch the OFS Configuration console and define a new Symbol Server connection. Choose the device type that matches the PLC (e.g., Quantum or Compact) and the transport (Modbus TCP, Modbus Plus, or Modbus RTU).
5. Import the CC2CAT output and confirm the symbol browser lists both located and unlocated tags.
6. Validate the runtime channel by performing an OPC DA Read on an unlocated tag from an OPC client (e.g., Matrikon OPC Explorer). The tag should return the live PLC value.

Choosing Between OFS and a Generic OPC Server

When unlocated variables must be exposed externally, OFS is the only fully supported path. If the project can be refactored so that every externally required variable carries an explicit address prefix, a generic OPC server is faster to deploy and significantly cheaper.

Alternative: Convert Unlocated Variables to Located

If OFS is not an option, the standard recommendation is to locate any variable that external systems must read. Concept supports this operation in both offline and online modes without breaking program cross-references.

Offline Procedure

1. Open the Concept project and navigate to the variable declaration editor.
2. Right-click the unlocated variable and choose Properties → Address.
3. Assign the desired Modbus address, e.g. 400100 for a 4x holding register at offset 100, or 400201 for a 32-bit REAL stored in registers 201/202.
4. Validate the project. Concept will compile the located binding into the binary and update the cross-reference database automatically.
5. Download the updated program to the PLC during the next scheduled outage (or use online editing for hot-swaps).

Online Procedure (Hot Edit)

1. Connect Concept to the running PLC over Modbus Plus or Ethernet.
2. Open the variable editor and bind the previously unlocated symbol to a free 4x (or 0x) address.
3. Trigger an online change. Concept will modify the in-RAM symbol table and the running application without a full stop, provided the PLC is in Online Edit mode and the controller supports online program modification (Quantum CPU and Compact CPU all do).
4. Verify with a separate Modbus master (HMI, SCADA, or Modbus poll tool) reading at the new address.

Address Planning Tips

• Group externally consumed variables into contiguous 4x ranges (e.g., 400100-400199 for process data, 400200-400299 for recipes). Contiguous reads reduce the number of Modbus transactions and improve HMI scan time.
• Reserve separate ranges per HMI/SCADA client to simplify future migrations.
• For REAL/DINT values, declare both 4x words together (the IEC 61131-3 little-endian convention used by Modicon) so the SCADA decodes them as a single 32-bit tag.
• Avoid assigning unlocated-only tags to 0x/1x unless they are true booleans; reserving 3x for analog inputs keeps the read/write asymmetry clean.

Structured Variables and Server Compatibility

Concept supports user-defined structured variable types (UDT/derived data types) such as VALVE_DERIVED with nested BOOL, INT, and REAL members. A documented caveat applies to OPC servers that flatten UDT members into the symbol namespace: not all servers preserve nested UDT members correctly when the source variable is unlocated.

• OFS with CC2CAT correctly resolves nested UDT members and exposes each leaf as its own OPC tag with a hierarchical browse path.
• Generic Modbus OPC servers cannot traverse the UDT at all, because the unlocated symbol is invisible.
• If a project uses heavy UDT for its internals, the practical path is to locate each UDT instance into a known 4x block and document the byte layout for the SCADA.

Performance Comparison: Located vs. Unlocated

For programs that run hundreds of unlocated intermediates per scan, keeping them unlocated and exposing only the final result variables as located is a defensible optimization. The overhead difference becomes negligible on modern Quantum CPUs and is irrelevant on M340/M580 platforms running EcoStruxure Control Expert (Unity Pro) — but it remains a valid argument for legacy Concept projects.

Troubleshooting Matrix

Migration Considerations: Concept → EcoStruxure Control Expert

Concept projects are migrated to EcoStruxure Control Expert (formerly Unity Pro) using the Concept Application Converter tool. During migration:

• Unlocated variables remain symbolic; the converter assigns new located addresses only if the original variable had a binding.
• The target CPU (M340, M580, or Premium) supports OPC UA natively through the embedded EcoStruxure OPC UA Server, which mirrors the role of OFS for legacy Modicon platforms.
• For plants continuing to use Concept on Quantum hardware while integrating new EcoStruxure tooling, OFS V2.5 remains the supported bridge.

Plan an address-renaming pass during the migration to align Concept's 4x block conventions with the target project's %MW layout; this avoids time-consuming cross-reference rework in the SCADA.

Summary of Field-Proven Recommendations

1. Reserve unlocated variables exclusively for internal logic. Treat them as private to the PLC.
2. If a variable must be visible to anything outside Concept, bind a 4x (or 0x, for booleans) address from the start. Online edits make this safe even after deployment.
3. If refactoring is not feasible, deploy OFS (TLXCDOFS25M) with the CC2CAT utility and route external access through an OPC DA client.
4. Document the variable naming convention, address block allocation, and endianness per 32-bit tag in the project header so SCADA integrators do not invent their own mapping.
5. Use the OFS V2.5 demo (20 tags, 2-hour runtime) on the bench to validate the symbol export before purchasing the production license.

Frequently Asked Questions