Basic Integer Expression Tag producing Error_ExpressionEval error

Ignition
,
1

Hi All,

Wondered if anyone could offer us some advice regarding an issue we're seeing with multiple expression tags.

It appears that SOME (not all) of our expression tags result in an Error_EspressionEval error.

They're all based on a UDT and are quite simple 'If' logic in the main.

One of our tags named P_Target_Count is itself is returning an Integer with the following expression:

if (isNull({[.]P_Target_Count}), 0,
if({[.]Timers/P_Timer} = {[.]Set_Line_Speed}, {[.]P_Target_Count}+1, {[.]P_Target_Count}))

P_Timer is an Integer producing Expression tag
Set_Line_Speed is a Float which has been set to a constant value of 300.0 via the UDT

Thing is, it will continue to update the tag's value regardless of whether the Error_ExpressionEval has been triggered or not.

It seems to be fine for most of the tags using this UDT, however, occasionally, it seems as if some of the tags go into this error state.

To clear it, we simply cut, apply, and then paste back in, the expression within the tag and it clears the error....for a while.

Thing is, the exact same code has been utilised and is running in the 7.9 instance this project has been upgraded from without such errors occurring.

We also see the same error occurring in a similar fashion with the P_Timer tag along with a number of other tags throughout the same UDT tag group, as mentioned, for a number of tags utilising it.

We're stumped as where it's been working without issue, it continues to do so...without issue.

Is there some quirk about how we should be interacting with the tags which differs between 7.9 and 8.1.[latest version] that we're not aware of?

Many thanks for any pointers anyone may have.

Kind Regards
Rob

2

Are you recursively referencing the P_Target_Count tag?

3

Thanks for the reply, only, apologies, not sure what you mean...can you expand on this?

4

Sure,

You say that P_Target_Count is returning an Integer with the expression. That expression is referencing the Tag {[.]P_Target_Count}.

5

Ah, sorry, yes, it is 'self referential'...is that a bad thing to do?

This is code we've been passed to support, and, as mentioned, seems to work fine when used in Ignition 7.9...it seems however no longer to be the case within the 8.1 test system we've been asked to migrate it over to though

6

In other words, expression tags are not really designed to handle X = X + 1 or anything like it. If it worked in v7.9, it was by accident.

1 Like
7

Magic!

I mean, even in 8.1, it works for a while :smiley:

how could we get around this issue then...is the answer going to be...scripts, many, many scripts?

8

Yeah, definitely not a great practice. One I'm surprised works at all.

Is this really something that needs to be Gateway Global? I wouldn't say many scripts. What is the actual goal you're trying to achieve?

9

Looks like you are trying to integrate over time? Use timestamps and value change events to control the action, a "prior accumulation" for rate changes, and an expression tag to yield current value from time.

10

have to be honest, it uses the words 'time' only, it seems to be a 'counter' based on the the tag update rate...ticking up +1 for every cycle through the tags.

Not entirely sure it's time based...i mean, you're right, it could be as we'd just need to look at the cycle time and work backwards from there.

hmm, something to dive into tomorrow now methinks

Thanks for your feedback, along with anything anyone else may have

11

That means it is integrating over time. Change the update rate (which isn't very precise anyways) and you change the result. Using timestamps as the basis for the calculation makes it independent of the tag update rate.

1 Like
12

Problem is, coming at it from a 'support' perspective, who's to say that that wasn't what was required in the first place?

Under the ITIL standard, unless we have the original design specification available, we'd basically be second guessing the original intent at this point by implementing a 'change' in design.

:-/

Probably quite safe to say it is though.

13

Just a quick clarification...using the 'recursive referencing is bad' perspective, am I to also assume it would be bad to use an expression to understand whether the tag you are creating the expression for currently has a 'null' value and then use the expression to set itself to zero upon finding it is?

Also, if i'm using an if statement to work out what to do if true or false, and upon returning a result false I wanted the value of the tag to remain as per the value it currently has, then, how would I do this without 'self referencing' the tag i'm creating the expression against?

Could just pump in the keyword 'pass' or something like that?

14

Yes.

The result of the expression is the value of the tag, in "theory" it wont be null unless you make it null.

I'm not even quite sure how to imagine this scenario, how would an expression which results in a 'Null' value ever not result in a 'Null' value?

15

You cannot. Don't use an expression for this.

16

Basically, I was asking if I wanted to understand whether the current value of 'my tag' is null, and, if it is, I wanted to set 'my tag' to '0', and, I was using an expression configured against 'my tag' to do this, then, doing so would also be bad?

17

so in that case, I would be using an if within the expression and would have no action to perform upon a false being detected.

If that was the case, what is the expression method for simply continuing without doing anything?

18

There is none. You must return a value, and it cannot reference itself.

Don't use an expression like this. Use scripting on a timer to perform counting/integration.

1 Like
19

Thanks, for your response.

Think there may now need to be a conversation with someone about this historical code.

20

6 posts were split to a new topic: Locating Broken Bindings