Why Does system.tag.configure Return Null in Ignition 8.3?

system.tag.configure reports [Good], but the configured DataSet memory tag contains null after an upgrade from Ignition 8.1.45 to 8.3.4. The same script works on 8.1.45, and changing execution from Designer scope to gateway scope does not correct the result. Treat this as a configuration-path regression, not as a dataset-construction or network fault.

Where does the dataset request stop?

Follow the packet even when no physical packet leaves the gateway. The script constructs a dataset, passes it inside a tag-definition object, and submits that object to the tag provider through system.tag.configure. The provider accepts the configuration and returns [Good], but the runtime value reaches the memory tag as null.

The tag is a memory tag, so no PLC address, device port, cable, or fieldbus exchange participates in the failing operation shown. Layer-one troubleshooting is complete once the tag is identified as memory-backed. Move directly to the scripting, configuration, and tag-value boundary.

Which Ignition versions reproduce the failure?

A change to object serialization was considered during testing because 8.3.5 changed that subsystem. Reproduction on 8.3.5-rc1 and the tested 8.3.6-SNAPSHOT means those builds do not provide the required behavioral fix. The internal serialization stage responsible for the defect is not identified; the controlled version comparison already isolates the operational fault to the 8.3 configuration path.

Which approach should you use?

Use the direct-write approach on affected 8.3 gateways. It bypasses the defective path in which a dataset is carried as an initial value inside the configuration object. Separating schema configuration from runtime data also creates two independently testable results: one for tag creation or modification and one for the data write.

How do you separate configuration from the value write?

Start with the minimal reproducer so unrelated tag properties do not hide the fault:

header = ['myColumn']
rows = [[1], [2]]
dataset = system.dataset.toDataSet(header, rows)

results = system.tag.configure(
    "[default]Test",
    [{
        "valueSource": "memory",
        "name": "Test",
        "tagType": "AtomicTag",
        "value": dataset,
        "dataType": "DataSet"
    }]
)

On an affected build, this is the failing pattern because value is transported inside the configuration request. Apply the workaround as two operations:

1. Construct the dataset with the required column names and row values.
2. Create or update the memory-tag definition with system.tag.configure. Keep dataType set to DataSet, but do not depend on the embedded dataset value to populate the tag.
3. Record and inspect every configuration quality returned by the call. Stop if the tag definition itself is not accepted.
4. Resolve the actual configured tag path in the Tag Browser. The argument [default]Test is the base path, while Test is the supplied tag name; pass the resulting tag path, not merely the base path, to the write operation.
5. Write the dataset directly with the applicable system.tag.write* function for the project’s execution pattern.
6. Inspect the write result independently from the earlier configuration result.

Use the installed version’s scripting documentation to select the specific member of the system.tag.write* family. The workaround identifies the API family but does not specify a particular synchronous or asynchronous variant.

How do you verify the workaround?

Verification must test structure, content, and quality. A non-null object alone can hide an empty dataset, an incorrect schema, or a stale value.

Run the same readback after moving the script to its production scope. The failure was observed in gateway scope and reproduced from the Designer, so a Designer-only success does not replace a gateway-scope test. Restart or scheduled-event testing belongs in the acceptance check when the dataset acts as cached master data.

What pitfalls recur in this failure mode?

• Treating [Good] as value confirmation: the result describes the configuration request. Read the tag value separately.
• Changing script scope as the primary fix: Designer and gateway execution showed the same behavior. Scope remains important for permissions and scheduling, but it does not remove this regression.
• Upgrading to an unverified candidate: 8.3.5-rc1 and the tested 8.3.6-SNAPSHOT still reproduced the null value.
• Writing to the base path: distinguish the configuration base path from the final tag path created from the supplied name.
• Testing only for non-null: compare data type, quality, column name, row count, and row values.
• Combining recovery and diagnosis: keep configuration results, write results, and readback results separate so logs show which boundary failed.

FAQ