An OPC server gives a program you write read, write and subscribe access to controller data. It has no editor and no download path for the logic, so split the job: OPC for data, the supported programming package for logic. Commission read-only first and get the license-move procedure in writing.
An OPC server answers half of the problem. It exposes the values inside your controllers so a program you write on a PC can read them, write to them and receive their changes. The logic running in the controller stays untouched. Everyday data work, meaning watching values, logging and setpoints, moves to software you own. Logic work, meaning editing and upgrading the program itself, stays on a supported programming path. This page draws that line and shows how to commission the data half.
What an OPC server gives you
OPC is a standard interface between a controller and a client program. The server is off-the-shelf software you install; it connects to the controller and exposes the controller's data. The client is what you write or buy. Classic OPC DA is a Windows-based standard defining how applications request and receive real-time process data: calls to read, write and subscribe, over data points such as analog and digital values, integers, floats and strings. OPC UA is the newer standard; a UA server exposes its data objects to a client such as an HMI application, with no Windows dependency on the client side. If your client must run somewhere other than Windows, UA is the standard built for that.
PC programs have read and written controller data for decades, first through DDE, where an Excel macro reads and writes PLC tags, and now through OPC. If you are weighing OPC against writing a protocol client yourself, write a Modbus client or use an OPC server for a small HMI compares the two on maintenance grounds.
What it never touches
The program never lives in the OPC server. Your flowcharts, ladder or structured text live in the controller and in the project files of the programming package that built them. No OPC service edits a chart, compiles a change or downloads it. A data connection reads values the logic produces and writes values the logic consumes, and that is the whole of it.
So the suggestion 'install an OPC server and program in whatever language you like' solves the interface half only. Writing your own software to replace the controller logic is a different project: your program becomes the controller, and a general-purpose PC operating system promises no scan time it will hold. A controller that turns an output in a 10 ms scan has no promise like that from a desktop operating system. Keep protective interlocks and time-critical sequencing in the controller, and never let a PC client own machine sequencing.
Two jobs, two tools
| The work in front of you | The tool that does it | What to confirm first |
|---|---|---|
| Watch values, log production, show a status screen | OPC server plus a client you write or buy | the tag list, an update rate such as 500 ms, read-only access |
| Send setpoints and commands from your own software | the same OPC link with writes enabled | which tags accept writes, and what each write does on the machine |
| Edit, tune or upgrade the running logic | the supported programming package for those controllers | current version, project files, a known-good backup, the connection to the controller |
| Replace the controllers outright | a migration project | full inventory of I/O, sequences, interlocks and dependencies |
Row 3 is the row people hope OPC will cover. It cannot, and the example below shows the split with numbers.
Example: five controllers and ninety flowcharts
A plant runs five controllers, all programmed as flowcharts, more than 90 charts in total, poorly documented, with a contractor needed for every change and a typical change taking 2 weeks to schedule. Spread evenly that is at least 18 charts per controller (90 ÷ 5 = 18). Nobody holds 90 charts in their head, which is why troubleshooting is slow.
Phase 1, read-only. Install the OPC server on one PC and connect a client with a 500 ms update rate, fast enough to follow setpoint changes without flooding the network. Pick 20 values per controller to start: 5 × 20 = 100 values. Compare all 100, one by one, against the operator display already on the floor. When every one matches, the data path is carrying those tags correctly. Run the link read-only for 14 days while logging or a status screen is built on top of it.
Phase 2, writes. List the setpoints operators actually change; in this plant, 3 per controller: 5 × 3 = 15 writes. Each write is tested once, one machine at a time, in a 30-minute maintenance window, with the process answer confirmed on the existing display and the controller logic still governing the result.
Phase 3, logic. The charts stay on the supported programming path. Document a chart each time phases 1 and 2 force you to open it; charts neither phase touches keep running untouched. Contractor calls now happen only for genuine logic changes.
The arithmetic of the decision: 100 reads plus 15 writes is 115 data points moved in-house, and zero logic migrated.
Prove the link before you trust it
- Back up the controller project before you connect anything new.
- Compare each value against the operator display, then follow a value you can force to move, a counter or a totalizer, and confirm the client tracks it over at least 60 seconds. A matching snapshot is a weak check; a moving value is a strong one.
- Pull the connection and watch the client. Disconnection has to show plainly within a few seconds, so a dead link never reads as a live zero.
- Keep the link read-only until the write tests.
- Classic DA names both a remote server and a server name in its connection string; splitting an OPC DA URL into remote server and server name gets that string right the first time.
The habit is the one you already use when you test a Modbus TCP gateway before you trust the data: compare against something known before the data drives a decision.
When a write is refused
Classic OPC DA defines write calls as part of the standard, so the protocol is never the blocker. A refused write points at the server or at the tag. The server may expose that tag read-only, and tag access is set in the server's configuration. Or the controller logic owns the value and writes over your change every scan, the behavior you see when a PLC overrides an HMI toggle write. One controlled write in a maintenance window tells you which case you are in.
The license and the PC it lives on
An OPC server license typically activates on one PC, and that PC gets replaced eventually. A method exists to move a license to a new machine; the steps and any limits are per product. Ask one question in writing before you buy: what is the documented procedure for moving this license to a replacement PC, and how often can it move? Store the answer, the activation state and the move steps in the commissioning record. The server PC becomes a single point of failure for every client on it, so write the rebuild steps the same week the link goes live. A PC that has already run 3 years is halfway through its service life; plan the license move before the failure, not after.
The decision
Recommendation: Put the data half on OPC and keep the logic half on the supported programming package. Commission read-only: compare a first batch of values against the operator display, run the link read-only through a settling period of about 14 days, then test each writable tag once in a maintenance window. Get the license-move procedure in writing before you pay for the server. Migrate the logic only when a needed change is impossible with the installed programming package, and inventory the I/O, sequences and interlocks before anyone quotes that job.
Questions
Can OPC replace my flowchart program with software I write?
Only the supervisory half. Your program can read values, log them and write setpoints. Machine sequencing and protective interlocks stay in the controller, because a general-purpose PC has no scan cycle it promises to hold; a controller holding a 10 ms scan has no PC equivalent. A full rewrite of the logic is a migration project: inventory the I/O, sequences and interlocks before anyone quotes it.
Should a new application use OPC DA or OPC UA?
Choose by the client PC. Classic DA is Windows-based, and when client and server sit on different machines, its DCOM configuration is the usual setup work. UA is the newer standard with no Windows dependency and its own transport, so a client on another operating system uses UA. A Windows client working against an existing DA server stays on DA.
How many tags should I compare before trusting the link?
Twenty per controller is a workable first batch: five controllers makes 100 compared values, enough to catch a mapping error without stalling the project. Compare each against the operator display, then keep the link read-only for 14 days. Test writable tags separately, one controlled write at a time.
Do I still need the PLC programming software once OPC works?
Yes. Keep the package current, with its project files, the controller configuration and a known-good backup stored off the machine. The OPC link carries data only, and the day a sequence, an interlock or a controller must change, the programming package is the only supported way in.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.