Hello,
I have a label in which there is an expression. I want to write the value of this into a tag on a fixed rate. How do I do these practically?
Thanks
idk if its the best methode, but this works:
add it in a struct expression, which has a time expression (
now(5000) is every 5 sec )in it aswell.and then add in a transform script which writes it to the tag and returns your expression again
edit: tho i guess it will also trigger if the expressionvalue changes, you’ll have to add in some more scripting for that then i guess if thats not what you want
Generally, if you need something like this, you don’t do it in the user interface. In the UI, it will run for each client looking at that view, and not run at all if no-one is looking at that view.
If it needs to run all the time, use an expression tag instead of a memory tag, and place your expression in the tag itself. Set the tag to be a member of a tag group that has the rate you desire.
1 Like
Hello
I would use the expression on the tag itself but the problem is this expression getting some values from other components. As far as I know tag expression dont read component values. I think I need a script that run on gateway on a fixed rate without anybody opening or pressing something. But how do I reach to a scpecific view and specific component in that view inside gateway event script? Have never done gateway scripting before.
Thanks
Thanks, tried it now it worked on value changedexactly what I want
1 Like
The solution to use a script and tag write isn’t great imo, definitely with phil on this one. It sounds like you’re going about this the wrong way.
Back up a bit, what is the expression on your label?
Where are the values coming from on the components you’re using in your label binding? And how do they get their values?
What is the end goal?
1 Like
Correct, they don't. But if they are input components, bind their values to memory tags. The expression tag can use those in its calculation instead. And the memory tags will hold those values for use when no client has that view open.
If those components have computed values, then make them expression tags, too.
If extra expression tags makes it too convoluted, you could use a gateway timer script to collect all necessary raw values, run all exotic calculations in jython form, and write the result to a memory tag.
So the expression is a calculation and it uses other component values in this calculation. Some of those used component values also have expression in them. Basically the structure I made for this one is mostly component values and expressions. That is why I could not put this expression on the expression tag because there are other component values inside. The result of the calculation I need to send it to PLC that is why I need it on tag level now. Yeah thinking now I would have make those expressions on tag level not on components but could not predict this.
Right now I made a transform script on the component it writes the value on a tag like victordcq suggested. Why do you think it is a bad way what could go wrong?
Thanks for the inputs
Because you're putting gateway-side functionality into the client-side, and to re-emphasise what Phil said, it won't run unless a client is open, and will run multiple times if multiple clients are running. I would definitely move the expressions in memory expression tags. You will get very strange looks from other integrators if they see it as is 
It's the same idea as moving the OPC-UA functionality into a client page. If the client page isn't open, tags stop updating (and you lose them altogether). If you have multiple clients with the page open, multiple connections are made to PLCs congesting the network.
Hello @pturmel
I need to open this topic again as I run into the exact problem you and @nminchin said before 
I write a script to reset the component values they are reset so the expression result is also recalculated but the result is not send to my tag as I used expression structure to write it to the tag. It only sends it when the view is open. How can I write this component value to a tag without changing logic I made earlier.
So I want to keep everything same but only to change how I write the component value to the tag. It needs to write the value even the client or view is not open like you said. You said gateway script can work, never used it before how can I make it?
Thanks for help
If you have a working expression, then cut and paste into a gateway expression tag. Then, if necessary, use a tag event to write it wherever else it might be needed when it changes.
Note, for this to work, everything in the working expression must be available in the gateway–no references to other component properties. If this isn’t true, you’ll have to move other items to gateway tags, too.
Well moving everything to tags is the thing I want to avoid. Because I did all the structure based on component expressions so like you said I have to move everything to tags. Is there no other way to just write the single component value to a tag? I would really appreciate if there is another way or be sure there is no other way before I start to move everything to tags.
Regards
Components are in the client. No client, no execution. Multiple clients, multiple executions. You should carefully consider what parts of your setup need to run all of the time, and ensure those parts are in the gateway. Use a gateway event script if you don’t want to use expression tags. However, tags are where the client decisions need to end up, so they are available to gateway scripts or expression tags when the client is closed or on a different project.
I’m sorry you went down a bad path. Ignition is so flexible that you can shoot yourself in the foot like that. You’ll have to redo part of your project in gateway scope. You simply cannot do what you ask.
The answer to that particular question is "yes", but with the limitations that Phil mentioned:
There are certainly valid circumstances for when components should write to tags, but these are only in response to operator actions such as button clicks.
Ok well thanks at least lessson learned;