System.tag.read

In Ignition 8 system.tag.read and write are not listed in the documentation but still work.
Are these going away?

It’s unlikely to completely go away because it would break backwards compatibility. However, for new / refactored scripts you should use the readAsync/readBlocking versions, if only because those will take advantage of improvements in efficiency and get more features over time.

what would this script look like using the other functions?

thistag = system.tag.read(’[Outbox]Fan1Ack’)
system.tag.write(’[Outbox]Fan1Ena’, not thistag.value)

There’s good examples in the docs for system.tag.readAsync and system.tag.readBlocking

Just follow the template there.

“It’s unlikely to completely go away …”

Just my two cents worth here on this topic, but please consider rewording the “unlikely” term from this stance regarding system.tag.read / write. Some of us (maybe just me for all I know) are using these heavily in Gateway Timer and Tag Change scripts to perform lots of logic, timing and counting functions and to re-write these to have to use callbacks for every instance will be a nightmare. I’m willing to suffer a little efficiency in order to avoid my least favorite feature of the JavaScript language.

I think you’re reading too much into the word “unlikely” :slight_smile:

1 Like

They won’t go away, and if you rewrite them using the readBlocking variant there’s no need to deal with callbacks.

1 Like

state = system.tag.readBlocking([’[Outbox]Fan1Ack’])
system.tag.writeBlocking([’[Outbox]Fan1Ena’], [not state[0].value])

1 Like

Would that potentially slow the execution of your scripts since the legacy system.tag.write() was asynchronous?

Potentially, but most people just get themselves into trouble using async when it’s often not necessary.

1 Like

Would using the Blocking variant of both functions cause UI to become unresponsive?

If your invoking the tag read from the client side then yes, it could be the reason for a lockup until the read is complete.

In Vision, yes. If the gateway is lightly loaded on a local LAN, it can be tolerated. But expect the occasional complaint.

Any suggestions to avoid this?

If part of a button’s actionPerformed, it probably isn’t a problem. Users expect a brief delay when telling a computer to execute a task. If the event is going to run often, you should bring the tag into a custom property using a tag binding or indirect tag binding. So the value is already there when the event script needs it. (Accessing the custom property’s value in the event script doesn’t cause a gateway round trip.)

Thanks! In your explanation, is it mostly regarding reading? Would it be fine to use the WriteAsync for Vision then?

I didn’t get why earlier in the thread Kevin said people get themselves in trouble using Async when it’s often not necessary.

No, it is any function that makes a call out to the gateway where your GUI thread is waiting for the response. If the gateway connection glitches at that moment, your gui is frozen.

The async functions are fine in the GUI thread as long as you understand that they don't give you an answer in that thread. The answer comes in the callback, which is just a function object you supply. The same kind of function object you might use with system.util.invokeLater or .invokeAsynchronous, except that the callback must accept the answer as its one argument.