Writing to client tags without system.tag.writeBlocking

[mpoulsen921]

Hi,

So I am not sure if this is intended or a bug or otherwise just an effect of the client tags.
However, I just had a scenario where I read a dataset from a client tag with the function system.tag.readBlocking and return the value in a parameter called result.
I manipulate the value and save the value in the result variable again:

result = system.tag.readBlocking(['[client]myTag'])
result[0].value = result[0].value + 1

All of this is done in a script in scripting library and called from button.

I have a label component bound to the client tag to show the value.

In the running client I test this and when the button is clicked the script is called but the label does not update. Just as expected.

However, if the I then save the project again and update the client (clicking on the banner in the top without closing the client) then the label component is updated.

How can this happen? I have not written back to the client tag itself so I would assume that this value was just saved in the local variable result and that’s it.

Is it because the memory between the client tag and the variable is shared in the scope of the client. So when I write back to that memory and the client is updated, then the client tag updates to that new value? I can see how that can be the intended functionality?

@PGriffith or @Kevin.Herron can you share some light on this? I might be wrong here and everything is as it is supposed to be, I just don’t get how the value will update on a client update when I have never written to the tag in the first place.

Thanks!

[Kevin.Herron]

Sounds like a client tag bug. I bet a copy isn’t being returned and you’re mutating the underlying value. No updates seen until restart because no events fire to notify listeners.

[pturmel]

Ignition defines the Dataset type to be immutable, but implementations are actually mutable. Reading a dataset from a client tag (or from any tag in gateway scope) delivers the dataset object that is actually stored in the tag. You are not supposed to alter it, as any changes within do not change the object’s identity–yielding no change events. This is also true of dataset properties throughout Ignition’s object models.

(Causing the APIs to return copies would have undesirable negative performance effects. Just follow the rule. That is, not a bug.)

Use the scripting functions that alter and return a copy, or construct a new dataset after looping through the original.

[Kevin.Herron]

Yeah, I know this has come up in Gateway scope before too, and I think the answer was the same there - "don't do that".

Anything that is a "container" type is coincidentally mutable but you'd be best to forget you know that.

[QUESTION] read Document propertie return PyDocumentObjectAdapter, why not Python dicionnary?

No, you shouldn’t. Like Datasets, if you want to make an edit you should mutate a copy and write that copy back. It’s not safe to mutate the values of a “container” object you get from reading a tag. I think this applies to Document, Dataset, and array types. This is probably why that PyDocumentObjectAdapter class doesn’t have any methods that let you mutate it.

Dataset Parallel writing Collision

While there’s nothing in place to stop you from mutating a String array it’s not really supported and may have unintended consequences, like tag change scripts not seeing the mutation. Using String arrays correctly you would suffer the same problem as Dataset.

[mpoulsen921]

Thank you both for the answers!

It makes sense and I am happy to hear it is not a bug just the nature of things in this case.