i assume there’s a perhaps over-optimistic check to prevent use of tags() in an iteration function (because attempting that gives the same results)
Not a check, but simply not possible. tags() needs access to the context, and that has to be stripped for iteration.
1 Like
should/does this implicitly apply to the transformExpr arg of transform()? (not technically “iteration”)
No, it doesn't.
should this return null? (the equivalent nested transform binding doesn’t)
transform(
'',
forEach( // <<< this breaks tags()
asList(''),
tags(asList(value()))[0][1]
)
)
this works fine
transform(
'',
// forEach(
// asList(''),
tags(asList(value()))[0][1]
// )
)
as does this:
Yes, you have tag() in an iterator expression. No can do, as mentioned above.
1 Like
Hey @pturmel, would you consider adding an expression function to this module to return a UUID string?
Hmm. That's a good idea. I've put it on my to-do list.
2 Likes
I added one to @paul-griffith’s ignition-extensions a while ago, but it hasn’t been published since it was added 
1 Like
This is awesome Phil, thanks! I had setting up a long lived queue on my to do list, I'm glad I procrastinated!
One feature request if it's not too much to ask - additional parameters similar to the initialChange and previousValue on a normal tag change script. The thing I'm fighting now is a gateway restart or OPC connection restored being processed as a value change. Being able to filter out entries that are initialChange or have a Not-Good previous value would be great.
It is too much to ask. Those don't exist in the tag actor pipeline. If you need this, your bulk script must maintain a cache of tag paths & values it is told to handle, and treat cache misses as the "initial change" indicator.
I figured it might be something that's a ton of work. I'll work out a way to track things myself.
Thanks Phil!
Hey Phil,
Have you considered adding a slice() expression that would allow for slicing a list similar to the python slicing operations?
I ask, because I think that:
slice({path.to.list},startIndex,endIndex)
would perhaps be a bit cleaner than:
where( {path.to.list}, idx() >= startIndex, idx() < endIndex)
I don't know. One function call versus one function call. 
Not going to be a high priority. I'm hoping Paul includes it in the [] operator....
Slicing might be an issue with our parser, but I'm not against it in principle. No time soon.
3 Likes
This went public today:
Wednesday before lunch. 
8 Likes
Ha! That might produce a heck of a horde of glazed-eyed zombies after this advanced topic....
1 Like
Hi Phil,
Regarding your tag actor features, I have two questions :
-
Is it possible to bind the value of the Item Path? We would like to use this in a UDT for instance but not being able to perform binding on this is a bit of a problem as we would have to specify the address manually everytime.
-
Is it possible to target a tag created within Ignition when using the Republish Action rather than having to specify the device and the address of the tag within the device?
We did try to fiddle with it but it seems those two features are not available (or we just completely misunderstood everything).
To give a bit more context, we need to republish the value of a tag to another device’s tag. Unfortunately we have quite a big amount of republishing to do, and leveraging the possibilities of the UDTs would help us tremendously (parameters, InstanceName, etc).
Also being able to target a tag created in Ignition rather than directly targeting a tag in a device would add a layer of abstraction that could be great in a number of instances (let’s say you’re using Modbus and for some reason the company programming the PLC decides to offset all the addresses). We would only change the addresses of the tags in Ignition without having to change the address of the republishToItem. Or it could also be useful to forward the value to another tag provider for instance.
Apologies, perhaps those examples make no sense to you as this is something you would maybe never do, but it never hurts to ask!
Thanks in advance and as always thanks for your amazing work!
Binding in UDTs should work just like it does for OPC Item Path... Use only UDT parameters and built-in parameters.
You cannot target a tag with the Republish Actor. I have no plans to add that. (I'd be concerned with checking circular definition corner cases... sounds too dangerous for me.)
Your examples sound useful, but it won't be me. Perhaps you should attend my ICC presentation where I will be showing how these work.