Fixing arOPC Greyed-Out Menus and Modbus Errors Guide

A dead Settings menu in arOPC is an arbitration result, not a licensing result. The number that matters is the count of live arOPC processes on the machine: one. When a second instance — a service, or an OPC client that auto-started the server — already owns the configuration, the window you are looking at is a viewer, and every control that writes to the configuration file is disabled. Activating the license changes nothing, because the license was never the gate.

The same one-owner rule explains the second common complaint on this server: the SCADA editor reports "no OPC servers found" even though arOPC is visibly polling tags. That one is a registration and bitness problem in the COM layer, not a mode problem. Both are cheap to separate once you know which quantity to read.

Quantities, Limits and Where to Read Them

Quantity	Value / limit	Where to read it
Concurrent arOPC instances that may hold the configuration	1	Task Manager; arOPC diagnostics log header
Service autostart, factory state	Disabled (server runs as a windowed application)	Windows Services, entry arOPC
Settings file that pins the current mode	settings.xml	C:\ProgramData\arOPC
License/state side files	*.el	C:\ProgramData\arOPC
Server bitness	32-bit	Determines OPC Core Components build: x86
Demo tag ceiling	32 tags	License dialog
Modbus TCP port	502	Channel properties
CODESYS gateway port	1200 — never usable for Modbus data	PLC project / channel properties
Float footprint in the Modbus map	2 registers	PLC Modbus slave submodule config
Configuration file extension	.cfx	Log line "configuration loaded from file"

Windowed Application Versus Windows Service

arOPC ships as a windowed application with service autostart turned off. Chapter 23 of the manual describes both modes, and clause 23.3 covers running it as a system service. The trap is that clause 23.3 is often the only item still clickable in a locked UI, so it gets used by elimination — which installs the service, and the mixed state gets worse: the server now runs as a service while the SCADA client keeps trying to attach to the windowed instance.

Criterion	Windowed application	Windows service
SCADA runtime on the same PC	Correct choice	Works, but adds a session boundary for no benefit
SCADA client and server split across machines	Requires an interactive session to stay logged in	Correct choice — survives logoff
Configuration editing	Full menu access	Editing UI locked while the service holds the config
Startup control	Start menu shortcut; SCADA editor can launch it on demand	Service Control Manager, autostart
Failure mode when both are active	Menus grey out; client binds to the wrong instance; tags may never update

For a single-PC SCADA + OPC stack — the common case for a TM3COM → OPC → SCADA chain on one box — run windowed. Reserve the service for a genuinely split architecture where the operator station logs off and the server has to keep polling.

Restoring Windowed Mode and Unlocking the Configuration

Order matters here. Deleting settings.xml while the service still owns it just recreates the same file on shutdown.

1. Close every OPC client first — the SCADA runtime, the SCADA editor, any tag browser. A running client is the most frequent reason the Settings item stays grey after the service is already stopped, because the client launched its own server instance through COM.
2. Stop the arOPC service if it is running, and set its start type to Manual so it cannot re-acquire the configuration on reboot.
3. Delete C:\ProgramData\arOPC\settings.xml. This drops the pinned mode; the server regenerates defaults on next start.
4. Start arOPC from the Start menu and confirm windowed mode is selected in Settings.
5. Activate the license. Do the activation in the mode you intend to run, not before the mode is settled.

Verification: the diagnostics log at startup should show exactly one process banner, the OS build line, and the .cfx configuration load. If a second banner appears seconds later without you launching anything, a client is auto-starting a competing instance — go back to step 1.

Why the SCADA Editor Reports "No OPC Servers Found"

This is COM registration, and it is heat-free logic: either the CLSID is in the registry under the right bitness, or the enumerator returns an empty list. Three independent conditions have to hold.

1. Run arOPC once with "Run as administrator" from the icon's context menu. That single elevated launch writes the COM registration. Afterwards, normal launches are fine — and permanent elevation is the wrong habit, because it breaks condition 3.
2. Install the x86 OPC Core Components. arOPC is a 32-bit server; the x64 redistributable registers the wrong-bitness proxy/stub and the browse list comes back empty. Where an x64 build was installed first, remove it and install x86, then reboot. The reboot is not optional — the proxy DLLs are loaded into running processes.
3. Match privilege levels between client and server. A server started elevated and an editor started normally sit in different COM security contexts and will not see each other. Being logged in as an account named Administrator is not the same as launching with the administrator token; on Windows 7 through Server 2019, UAC filters the token unless you explicitly elevate.

The cleanest import procedure is to leave arOPC closed and let the SCADA editor start it through COM. If the server appears in the list but the connection fails when reading tags, check antivirus, Windows Firewall and third-party endpoint agents — DCOM activation and the callback channel are both blockable, and the failure surfaces as a connect error rather than an empty list.

Decoding the Modbus TCP Exchange Log

Turn on device exchange logging before you guess: Settings → Logs → save device exchange to log. Then read Diagnostics → Communication channels. "Connection established" and "device poll thread started" only prove TCP came up; they say nothing about the register map.

SEND (12): 12 00 00 00 00 06 01 03 00 00 00 01
REC  (9):  12 00 00 00 00 03 01 83 02

Field by field, the request is MBAP transaction ID , protocol ID , remaining length , unit ID , function (read holding registers), start address , quantity . The reply carries the same transaction ID, length , unit , function — with the exception bit set — and exception code , illegal data address.

The timing in that log is worth reading too. The connection is fine, the addressing is not.

The Two Causes Behind Exception 02 on This Link

Exception means the slave has no object of that type at that address. On CODESYS-based ОВЕН controllers there are two distinct ways to earn it.

The register does not exist yet. Adding the Modbus slave module to the PLC project and accepting defaults creates a slave with an empty map. arOPC asks for holding register 0; nothing is mapped there; the PLC answers 83 02 forever. The OPC-side tag definition and the PLC-side submodule channel must describe the same object: same address, same width. Section 7.4.2.2 of the ПЛК110/ПЛК160 CODESYS programming manual (page 90) covers submodule input/output configuration.

The object class is wrong. Reading bit-addressable cells with function produces the same exception. Coils and discrete inputs live in a separate address space and need /; a bit tag configured as a register read will never resolve. ОВЕН controllers are unforgiving about frame composition, so the object type in the tag definition has to match the slave map exactly rather than approximately.

Port Selection and the RTU-over-TCP Checkbox

Two configuration mistakes stop the poll before any exception is generated.

Port 1200 belongs to the CODESYS gateway. TCP will connect on it and the channel will report success, which is exactly what makes it convincing, but no Modbus PDU is ever serviced. Use 502, and add the Modbus slave module to the PLC project so something is listening at the protocol level.

The RTU over TCP option changes the framing: it wraps RTU frames with CRC inside a TCP stream instead of using the MBAP header. Over a plain Ethernet link to a Modbus TCP slave, leave it clear. With it set, the slave receives a malformed frame and the server reports no communication with the device. Clearing that single checkbox is what turns "no link" into "device online" on an Ethernet channel.

Computing Slave Register Addresses by Hand

CODESYS does not display the resulting Modbus address for each submodule channel; you derive it from declaration order and data width. Addresses run sequentially, and each channel consumes as many 16-bit registers as its type requires.

• A 2 byte channel (Word, 16-bit) declared first occupies address 0.
• A Float declared second occupies addresses 1 and 2 — two registers.
• The next channel therefore starts at address 3.

Where the CODESYS target does not expose a Word type by that name, use the channel width: 2 byte is the Word equivalent. Commission the map one variable at a time. Declare a single 16-bit channel, write a known constant into it from the PLC program, and define one tag at address 0 in arOPC. When that value appears in the server and a write from the server appears in the PLC, the address arithmetic is proven and you can extend the map. Keep a written register map alongside the project — nothing in either tool regenerates it for you, and there is no address calculator utility to lean on.

Protocol Reach and Configuration Import Limits

Scope the integration before building tags, because arOPC is a Modbus-family server with an MQTT path, and that boundary decides whether a migration is possible at all.

• Siemens controllers: the native Siemens protocol is not supported. If a KEPServerEx installation is currently reading those PLCs over Ethernet, it is almost certainly using the native protocol, and arOPC cannot substitute for it. The link only works if Modbus is configured — or can be configured — in the controller itself. Confirm which protocol the channel actually carries before committing; Profibus/native S7 traffic to I/O and partner devices is not Modbus.
• KEPServerEx configuration import: there is no direct import. arOPC has CSV tag import/export, but the internal structures differ, so any CSV extracted from a KEPServerEx configuration needs manual rework. Budget the re-entry effort rather than assuming a converter exists.
• MQTT: supported, including in the 32-tag demo. To create MQTT tags, select the Simulation device type — that is the container used when the only transport is MQTT.
• Transducers and meters: Е849ЭЛ and ЭП8555 converters are readable over Modbus. Энергомера meters are on the equipment wish list without a committed schedule; treat them as unsupported for planning purposes.

Tag Editing Pitfalls and Version Regressions

Cut and paste a tag back into the same group and the pasted tag can inherit a duplicate name. The server and the SCADA runtime keep working, so the defect stays invisible until the next tag import into the SCADA project, which then fails with an error that does not name the duplicate. This is a known server-side defect and has been corrected in later builds; if you are on an older build, rename immediately after any cut/paste, or avoid the operation entirely.

The reason people cut and paste is reordering. Use the keyboard instead: Ctrl + Up and Ctrl + Down move the selected tag within the group, matching the "move up"/"move down" context-menu items.

Upgrades deserve the same discipline as PLC firmware. A build that changed device handling once stopped all СПТ and СПГ heat computers from being polled; the recovery was a rollback to the archived 1.70.153.1672 installer, and the defect was fixed in a subsequent release. Keep the previous installer, keep a copy of the .cfx configuration, and after any upgrade confirm poll activity per device in Diagnostics → Communication channels before releasing the station.

When to Stop and Escalate

Escalate to the vendor once you have a diagnostics log with device exchange enabled, the .cfx configuration, settings.xml and any *.el files from C:\ProgramData\arOPC, plus the exact build string from the log banner — that package is what makes a protocol-level defect reproducible instead of debatable. If the exchange log shows a valid request and a device answer that still contradicts the documented register map, the remaining question belongs to the controller vendor's support channel, not the OPC server's. Do not keep cycling installs on a live station; freeze the configuration, capture the evidence, and hand it over.

FAQ