Perspective Numeric Entry, InvalidStyle is being used even though value is within limits

[Brian_Stilson]

I have a numeric entry template view in my project where I'm using an invalid style class to turn the background red when the values are not in the valid entry range. This was initially developed in Ignition Edge, but we've copied to Ignition Cloud Edition, and the tag provider is now MQTT instead of OPC. Not sure if that matters or not, but that's what's different.

On the Cloud, the Invalid Style is being used on several of the embedded views even though the values are actually in range. But it doesn't happen on all of them. Also, some of them switch to where they should be after a few second delay. And finally, if I refresh the page, it fixes everything. But obviously, having to refresh the page every time someone clicks on a tab is not acceptable.

On some numeric entries, I have a UDT where separate PLC tags control the upper and lower entry limits. My template view has parameters for min and max entry, and most of the time when I call them, I use a binding to pass those in. I have confirmed that if I disable the bindings, the behavior stops.

Here's an example of one of my entry elements:

Here are the parameters:

Right now, with the maxEntry and minEntry bindings disabled, it's working as it should:

However, when I enable the bindings to the min and max:

Even though 70 is within the 0-100 range, it still loads and shows as red, but I can change the value to 100, and then back to 70, and it's fine.

Again, this isn't happening in the Edge application at all. I'd rather not have to go through my entire application and disable all bindings, as I use this template dozens if not hundreds of times.

I'm not sure what I could try here.

[Transistor]

Before I dig into trying to replicate, are you feeding the value 70 into a percentage variable somewhere and that is converting it to 7000%?

[Brian_Stilson]

No. There's no scaling associated with that tag. It's just feeding the PLC a 0-100 number and it's scaling it to an analog output.

[Brian_Stilson]

I figured out the problem. The numeric entry template view has a min and max value parameter associated with it. When that template is called via an embedded view, and the binding is an expression binding using the tag() expression, it causing some sort of timing issue because the bindings can take several seconds to update. I've been going through and making them tag bindings of the expression type instead. This has greatly sped up performance and the problem no longer occurs on the Cloud for those objects.

Here's an example of an inappropriate binding:

And here is the proper method:

All I had to do was take what was inside the parentheses in the tag() expression and put it in the tag binding expression window.

[pturmel]

Make a note to your future self: If you use the tag() expression function anywhere other than in an actual expression tag, you are screwing up.

[Brian_Stilson]

It's a big adjustment coming from a world where this stuff doesn't typically matter all that much. Most of my career, I've used software where there's only one way to do something. You do it that way, it works, and you move on. Going from that to where seemingly little things like that can shave dozens of seconds off your screen load time is definitely a "culture shock." I know this is par for the course in software/web development world, but HMI programming is not web development, and it's why I tell my potential customers that Perspective is a tool for building web pages, not HMIs.

At this point, my policy is never use tag() unless absolutely necessary.