An Ignition OPC tag stores an address, not a value. A read starts at the tag provider and goes through the gateway's OPC connection. It then reaches either Ignition's own OPC UA server and a device driver, or a remote OPC server. Only after that does it go out on the wire to the controller. If the controller is not there, the request stops at the first hop that cannot resolve the address. When you build a project before the PLC is available, every new OPC tag shows Bad_ConfigError. The sections below walk through the data path, choose which hop should answer in place of the PLC, and set up tags so the cutover needs no path edits.
Where does the tag read stop when the PLC is missing?
Follow the packet. Each hop validates part of the tag configuration, and each can fail on its own.
| Hop | What it resolves | Typical state with no PLC |
|---|---|---|
| Tag provider | Tag definition, OPC server name | Present, configured by you |
| OPC connection (Ignition OPC UA or remote server) | Server reachable, session up | Usually fine for the internal server; a remote server may also be absent |
| Device / connection named in the item path | Device exists and is enabled | Often not created yet, or created but cannot connect |
| Driver address parsing | Item path is valid for that driver | Some drivers cannot validate addresses until they have a live connection |
| Controller | Physical link, IP reachability | Absent |
Check layer one first, even here. A missing controller and a misconfigured device produce different symptoms on the gateway status pages. A device that is defined but cannot reach its IP reports a connection problem. A tag whose item path points at a device that is not defined in the server produces a configuration fault. Check: open the tag's diagnostics and record the quality code. Also confirm on the gateway which devices and OPC connections exist and what state they are in. If the result is Bad_ConfigError across the board and there is no controller to connect to, go to the next section.
Which hop should answer in place of the PLC?
There are four places to put a stand-in. Pick one based on where the tag's OPC server lives and how much work you want at cutover.
| Stand-in | Hop that answers | Ignition device drivers | OPC UA connection / third-party OPC server | Cutover action | Quality while standing in |
|---|---|---|---|---|---|
| Offline property on OPC tags (proposed Inductive Automation feature) | Tag layer | Yes | Yes. It works above the connection, so the server type does not matter | Clear the Offline flag per tag | Uncertain_SimulatedValue |
| Dummy device driver that accepts any OPC item path and creates a node for it | Device layer inside the Ignition OPC UA server | Yes | No. It only covers devices hosted in Ignition's server | Delete the dummy device, create the real driver device with the same name | Whatever the dummy driver reports |
| Dummy OPC connection that pretends any node it is asked for exists | OPC connection layer | n/a | Yes | Delete the dummy connection, create the real one with the same name | Whatever the dummy connection reports |
| Memory tags, converted later | Tag layer | Yes | Yes | Change each tag's value source from Memory to OPC and enter server and item path | Good. The data is not flagged |
The dummy driver and dummy connection are design patterns, not shipped products. Either one is a custom module. Their advantage is that the swap happens once, at the device or connection level, and the tags never change. The tag-layer Offline approach needs no module. It also covers the case the dummy driver cannot: tags that come from an OPC UA connection or from another vendor's OPC server. Check: for each tag folder, write down which OPC server and device or connection it will use in production. That list decides which stand-in is valid for that folder.
How do you lock the addressing before the controller exists?
The item path is the contract between the tag and the device. Every stand-in except the memory-tag method depends on the final item path being in the tag from day one.
- Fix the production OPC server name and the device or connection names now. Use the exact names the gateway will have on site.
- Enter each tag's full item path in the syntax of the target driver or server, taken from the PLC program's tag list or address map.
- In UDTs, pass the device name and base address in as parameters. Instance counts can then grow without hand-editing paths.
- If you use a dummy device or dummy connection, create it under the exact production name. The cutover is then a delete-and-recreate with no tag edits.
Check: export the tag folder and list the distinct device or connection names referenced in item paths. Every name must match the planned production gateway configuration character for character.
What does an Offline OPC tag actually do?
The Offline property, as specified by Inductive Automation, turns an OPC tag into a simple ephemeral memory tag without removing its OPC configuration. Before relying on it, confirm that the property appears in the tag editor of your gateway version. If it does not, use one of the other stand-ins from the table above.
| Event | Behavior |
|---|---|
| Read / write while offline | Both allowed; the value lives only in the tag |
| Persistence | None. Values are not persisted |
| Quality | Always QualityCode.Uncertain_SimulatedValue
|
| Gateway starts with tags already offline | Each tag starts at the initial value for its datatype |
| Live OPC tag switched to offline | Its current value carries over as the starting offline value |
| Offline disabled | The offline value is not carried to the OPC side; the tag resumes reading from its item path |
There are two intended workflows. First, you can set existing OPC tags offline when you know you will lose access to the PLC, for example when you take a project off site. Second, you can create new OPC tags and switch them offline immediately, until the PLC is available. Neither one replaces a process simulation. The goal is narrower: create OPC tags without every one of them showing Bad_ConfigError.
Check: set one tag offline, write a value, and read it back. Then restart the gateway. The tag should come back at its datatype's initial value with Uncertain_SimulatedValue quality. That confirms the tag is not persisting anything you will later mistake for plant data.
Which quality should placeholder data carry?
QualityCode.Uncertain_SimulatedValue maps directly from the OPC UA StatusCode.Uncertain_SimulatedValue. It is the standard way to say "this value did not come from the field." There are two competing requirements behind the choice of this code.
| Requirement | Argument | Consequence |
|---|---|---|
| Uncertain by default | Stand-in data must never be historized as Good, and must never let an HMI screen suggest the process is healthy | Quality overlays show on bound components; the historian records the uncertain quality |
| Good by default, with writable qualities | Development systems need normal history to test charts and trends, and a way to write qualified values carrying other qualities | Faster UI testing, at the cost of stand-in data that looks like field data |
The Uncertain default is the safer design. It keeps stand-in values visible as stand-ins in every downstream consumer, including the historian, alarms, displays, and anything reading through Ignition's OPC UA server. If overlays get in the way while you lay out screens, disable quality overlays on the development gateway only, and turn them back on before commissioning. The memory-tag method gives Good quality with no flag at all. That is the main reason to prefer the Offline property or a stand-in that reports an honest quality.
Check: bind one stand-in tag to a display component and confirm the quality overlay appears. On the development gateway, query that tag's history and confirm the stored quality is not Good.
Can a timer script stand in for the process?
Yes. A gateway timer script that writes changing values into offline tags will animate screens and generate trend data. That is a separate use case from the Offline property, though. A proper simulation capability would look different and cover more, likely as a platform-level feature rather than a per-tag switch. Treat script-driven values as a development aid.
The hazard shows up at cutover. The script writes to a tag path, not to an offline flag. Once the tag goes back online, the same write goes out through the OPC connection to the real controller. A script that ramps a "level" tag between limits becomes a script that writes to a live PLC register.
- Put every simulation script in a clearly named project or script library that is not deployed to production.
- Gate each script on a single development flag tag, so one write stops all of them.
- Before any tag leaves offline mode, search the gateway timer, tag-change, and scheduled scripts for writes to that tag's path.
Check: with the development flag cleared, watch a script-driven tag for at least two script periods. The value must not change.
How do you cut over to the real controller?
Work outward from layer one. Connect the controller, then the device, then flip the tags.
- Confirm physical link and IP reachability to the PLC from the gateway host.
- Dummy device or connection: delete it and create the real driver device or OPC connection under the identical name. Do not rename anything.
- Confirm the device or connection shows connected on the gateway status page before touching any tags.
- Offline tags: clear the Offline property, one folder at a time. The offline value is discarded and the tag reads from the PLC. Nothing written during development goes down to the controller.
- Setpoints and recipe values you entered on offline tags during development are therefore gone. Write the required values to the controller deliberately, through your normal commissioning procedure.
- Memory tags: change the value source to OPC and enter the OPC server and item path. Expect errors in this step, because the path is typed now rather than validated earlier.
- Disable or remove all simulation scripts from step 3 of the previous section.
Check: after each folder is switched, filter the tag browser for any quality other than Good. Every remaining non-Good tag points to a specific item path or device to fix before you move on.
How do you verify the path end to end?
- Layer one: the gateway reaches the PLC, and the device or connection status is connected with no reconnect cycling.
- Configuration: no tag in production folders still has the Offline property set, and no
Uncertain_SimulatedValuequality remains anywhere in the provider. - Reads: compare a sample of tags from each UDT type against the same addresses in the PLC programming software, online.
- Writes: write to a non-hazardous test tag from Ignition and confirm the change in the PLC.
- History: confirm new records are stored with Good quality. Keep development-era stand-in history separate from production data, or purge it.
- Restart: restart the gateway and confirm every tag returns with Good quality from the PLC, with no datatype-default values anywhere. This proves no tag is still ephemeral and no stand-in layer is still answering in place of the controller.
FAQ
Does disabling the Offline property write the offline value to the PLC?
No. When Offline is disabled, the offline value is discarded and the tag resumes reading from its OPC item path. Any setpoints entered during development must be written to the controller deliberately.
Do offline tag values survive a gateway restart?
No. Offline values are not persisted. A tag that is offline when the gateway starts comes up at the initial value for its datatype, with Uncertain_SimulatedValue quality.
Can I use the Offline property with an OPC UA connection or a third-party OPC server?
Yes. It works at the tag layer, above the OPC connection, so the server type does not matter. A dummy device driver only covers devices hosted inside Ignition's own OPC UA server.
Can I historize simulated tag values for trend testing?
On a development gateway, yes. The records carry Uncertain_SimulatedValue quality, not Good. Keep that history out of production, and turn quality overlays back on before commissioning if you disabled them for screen layout.