Resolving Bad_AccessDenied Writes to Ignition Edge Tags

Where does the write actually stop?

The setup: a central Ignition gateway on 8.1.45 calls system.tag.write() against a PLC tag on an Ignition Edge IIoT gateway, also on 8.1.45. The write returns Bad_AccessDenied. Reads work, the tags browse in the central Designer and in Perspective sessions, and a write from the Edge gateway's own Designer succeeds. No log entry explains the refusal.

Follow the packet. A write from the central gateway crosses more hops than a local write:

The local Edge Designer write succeeds because it never passes hop 4. Service security applies only to requests that arrive over the Gateway Network, so the Edge gateway refuses the remote write before its tag provider sees it. The tag provider never runs, so it logs nothing. That is why the write fails silently while the tag itself is healthy.

Check: write the same tag from the Edge Designer. If it succeeds, hops 5 and 6 accept writes, and the fault sits in hops 3–4.

Is the Gateway Network link up in both directions?

Layer one first. Confirm the transport before you touch security. On both gateways, open the Gateway Network connections status page and read the connection state.

It does not matter which side opened the connection. Edge gateways often dial out to the central server. Service security is still evaluated on the gateway that hosts the service, which here is the Edge gateway serving tags.

Check: live values from the Edge PLC update in the central Designer's Tag Browser through the remote provider. If reads are live, the link is good.

Which security zone does the Edge place the central gateway in?

Edge applies service security per security zone. A zone matches incoming connections by criteria such as IP address, hostname, or Gateway Network gateway name. A request that matches no defined zone falls into the Default zone. If you never built zones, the central gateway lands in Default. On many installations the Default policy grants tag access at read-only level. That produces exactly this symptom: browse and read work, and every write returns Bad_AccessDenied.

1. On the Edge gateway web interface, open Config > Security > Security Zones.
2. Create a zone for the central server. Identify it by its Gateway Network gateway name, or by its IP address if the connection comes through a fixed address.
3. Save the zone. If several zones exist, confirm the zone order so the central server matches the zone you intend.

Scope the zone narrowly. Granting write in the Default zone opens writes to every gateway that can reach this Edge node.

Check: the zone's criteria match the gateway name or address shown for the central server on the Edge gateway's Gateway Network connection page, character for character.

What does service security grant that zone?

1. On the Edge gateway, open Config > Security > Service Security.
2. Edit the policy for the zone you created. If you chose to stay with the Default zone, edit that policy instead.
3. Set the Tag Access service from read-only to the read/write level. Choose the edit level only if the central server must also create or modify tag configuration on the Edge.
4. Leave the other services (alarms, history, and so on) at the levels your architecture needs.
5. Save.

Check: from the central Designer, write a value to a non-critical tag in the remote provider through the Tag Browser. The value should land and read back from the Edge. If it still returns Bad_AccessDenied, the central server is matching a different zone than the one you edited. Return to the zone criteria.

Are provider or tag permissions blocking the write?

When service security is correct, the request reaches the Edge tag provider. Two more gates apply there.

A gateway-scoped script does not carry a user's security levels. If you populate the provider permission boxes with role-based levels, a gateway-scoped remote write can still fail even with service security open. Leave those boxes empty, or include the levels the remote request actually carries.

Check: the tag's Access Rights read as read/write in the Edge Designer. The local Edge Designer write from the first section already proved the device path.

Is the script using a supported write call, and does the full path verify?

system.tag.write is deprecated in 8.1. Replace it with system.tag.writeBlocking when the script must know the outcome. Use system.tag.writeAsync when it must not block, for example in a UI event. writeBlocking takes lists of paths and values and returns one quality code per path. The quality code carries the same Bad_AccessDenied you saw, so the script can report per-tag failures instead of failing silently.

# Gateway or Perspective scope, central gateway
# [EdgeRemote] = name of the remote tag provider on the central gateway (placeholder)
paths  = ["[EdgeRemote]Line1/Motor/SpeedSP"]
values = [42]

results = system.tag.writeBlocking(paths, values)
for p, q in zip(paths, results):
    if q.isGood():
        system.util.getLogger("EdgeWrite").info("OK %s" % p)
    else:
        system.util.getLogger("EdgeWrite").warn("FAIL %s -> %s" % (p, q))

Use the remote provider name defined on the central gateway in the path. Do not use the provider name on the Edge. A mismatched provider name produces a bad-path quality, not an access error.

Run the end-to-end verification in this order:

1. Gateway Network connection shows running on both gateways.
2. Reads through the remote provider are live on the central gateway.
3. The Edge Designer write to the target tag succeeds (proves device path).
4. The central Designer Tag Browser write succeeds (proves zone and service security).
5. The script above logs OK for each path and returns a good quality code.
6. Read the value back at the PLC through the Edge OPC connection, or with the controller programming software, and confirm the controller holds the written value.

FAQ