Tag value source does not support writing

I’ve migrated a 7.9.13 gateway into 8.0.7. It was originally migrated with everything disabled, but everything has been enabled AFAIK. I see an error in the logs “Bad_ReadOnly(“Tag value source does not support writing.”)” when I try to write a value to an expression tag via scripting. This was a global shared script in v7 and now it’s a project script under the global project FWIW. The Ignition OPCUA server is enabled and not set to read-only, the realtime tag provider is enabled, the tag itself is not set to read-only. Any ideas?

Writing to expression tags has never been supported - I’m pretty confident it also didn’t work in 7.9.

Expression tags aren’t supposed to be written. Anything you’d write to them would be replaced by the expression result on the next evaluation. Looks like a loophole closed.

It worked fine in v7

In this particular case it was just set to count itself up along with the scanclass and I reset via script.

toInteger({[.]Tag},0) + 1

*UPDATE - Pro tip - avoid using this expression in combination with the new “Event Driven” expression tag default execution mode to avoid pegging your Ignition server CPU at 100%.

That use makes sense. I’m guessing this isn’t a case where you’d want it to reset at a certain value every time (adding modulus operator would accomplish that). For a callable reset that makes it behave a lot like it used to:

  1. Add a Reset property to the tag.
  2. Add a value change event script:
if not currentValue.value:
	system.tag.writeAll(["[.]Tag.Reset"], [False])
  1. Modify expression:
if({[.]Tag.Reset},
	0,
	toInteger({[.]Tag},0) + 1
)
  1. Reset via script:
system.tag.writeAll(['[provider]_test/Tag.Reset'], [True])

I also found that the error shows in the log from source “LegacyScripting[system_util_tag]” when using system.tag.write. When using current scripting functions system.tag.writeAsync or system.tag.writeBlocking it fails silently.

Thanks. I will have to reevaluate how I do this. It’s something I replicate hundreds of times and even create these tags dynamically via scripting in some cases.

I found one work around for this particular case with the least amount of reworking is to disable/enable the tag by writing to “[.]Tag.Enabled”

This also uncovered a small bug in 8.0.7 with the disabled tag icon in the tag browser. This icon does not disappear when a tag is re-enabled (either manually or via the script) until the tag browser is refreshed.

1 Like