Hello All,
What is the de facto for using templates in Perspective? Logical answer is embedded views, however these degrade HMI performance and create a lot of latency. We have been staying away from embedded views altogether for these reasons. What are the other options if any to accomplish what was so easy to do in Vision?
Embedded views are the answer, however building things the same way you did in Vision will likely lead to performance issues in Perspective.
A common misconception I see people do in Perspective is to take a vision template, and rebuild it the exact same way they did in Vision, without thinking about how data is moved between the gateway and the web client for Perspective.
I find it is typically better for performance to bulk load data and then apply to embedded views/repeaters/accordians/etc. Instead of letting each embedded view get its own data.
There are a ton of different ways to improve performance like that, that you generally wouldn’t do in vision since its a 12 year old product that tries to do a lot of that optimization for you. I would say if you are having performance issues with a specific set of embedded views, to try and post them to see if there are any obvious performance issues that could potentially be addressed
That's interesting. Can you explain how to bulk load data and how to bind it to the controls?
Yes, please elaborate on that statement. I’m especially interested in how that works when the views within the repeater etc. have bi-directional bindings.
Even using embedded views which have no tag bindings creates a laggy experience for the user when calling up a view.
A very simplified example is if you need to show data for 100 tanks
You might create a custom property on the view called tagData with an expression that polls every X seconds, and a script transform that reads all 100 tags in one system.tag.readBlocking([tagPaths]). Provide them each to every instance being repeated, or (say you are using a coordinate container and embedded views instead of a repeater), You just bind each of the embedded view params to the output of the “tag values” binding you created. Since that array of values is provided to the client in bulk from the binding, your client won’t have to make 100 bindings to the gateway for tag data, and instead it would be 100 bindings to data that is provided to the client already. (Removing any network delay)
Then just let the embedded view be “dumb” to where its data comes from, as its just a parameter, and perform any tag writes through scripting instead of bi-directional write backs.
This allows all of your data collection operations to happen in one bulk operation, and then all the views need to worry about is showing up on the screen.
That example is obviously quite simplified as things can become more complex than one tag repeated X times, but the premise works the same even in more complex structures. I use it often If I need to show a large amount of data in any format. (i.e. showing many accordion objects visualizing several hundred work orders each.)
Eventually you start to use scripts that collect data in bulk (i.e. reading the data for 10 tags per UDT type in a folder and then providing that as an array of complex objects to the child views) for most operations and it becomes less cumbersome than it seems at first.
I then will often pair the initial tag loading time with some form of visual loader, so that the page feels like its actually loading faster than it is. 3 seconds of a loading icon feels much faster than 3 seconds of views churning through their initial tag reads.
TLDR: Bulk tag reads through script transform on a polling expression binding, bind the embedded views to the output of that array (Or just pass through with a repeater), and using scripting to write changes instead of bi-directional bindings
How does this method handle tag quality overlays in the views? How does it utilize tag groups?
If you read a tag and it came back with a bad quality, than the basic qualified value returned should include a quality that ends up being passed down to the component of which you are binding the param value. Therefore, qualities should just follow all the way through and provide an overlay
Tag groups are part of the tag definition, and thus are a gateway scoped premise that isn't really relevant of the client in this case. If you define a tag group to scan at 10 seconds, and you tell your client to poll at 1 second, you will still only be reading the tag over ops every 10 seconds. So there isn't really a way to enforce this, but I would try to just scan at the rate that is realistically needed in both the scan class and the polling expression.
Three seconds to load a window is still slower than a corresponding vision screen and for windows that have longer loading times, vision has caching so subsequent window loads are quicker. If anyone from IA is monitoring these forums please take these complaints into account. Vision is a great product but perspective is the future of Ignition from what I understand. Perspective is not ready or a viable replacement for Vision for certain applications. Just look at this thread, and the ridiculous hoops developers have to go through to make a screen “feel” like it is loading faster. Not really loading faster it just feels like it is, and to be quite honest for a 24/7/365 type operation, a control room operator doesn’t care if it feels faster. They are just going to complain about slow response.
If an integrator came into my facility and put that kind of solution in to make things appear faster they would be shown the door.
This cannot be the solution, I fear it will result in a script laden, bloated application. Run a ton of scripts asynchronously to the client actions to try and make the data always available makes little sense.
Kgamble, my frustration is not directed toward you, I appreciate your detailed responses. I guess I’m not understanding how a new product makes it harder to do something that was already efficient in an old product.
I don’t consider Perspective to be a replacement for Vision. There are still way too many applications better suited for Vision in my opinion. I also think Perspective has come a long way in just a short period of time, at least relative to the time it took Vision to mature.
I get frustrated with Perspective as well, but it’s usually because I take the wrong approach, as others stated, trying to port something in Vision directly to Perspective. That’s just not the best approach. I think you have to be well versed in Perspective to be highly successful with it. I don’t feel that way for Vision.
Just my two pennies on the matter.
I don’t consider perspective to be a replacement for vision either but IA is pushing it to their customers and we are starting to see it required over vision in RFQs we get from customers. IA in my mind is making it hard for us integrators to provide a quality product when they are telling peotential customers they should be using perspective. I think perspective is a good reporting or dashboarding tool but a responsive hmi application it is not.
How exactly is IA telling potential customers to use a specific module? I’m just not getting that vibe. I do think they are putting more effort into development for Perspective over Vision, but I don’t think that translates into telling a customer what to do.
Do you have a sandbox gateway backup as an example? We use scripting on custom properties to populate tag paths and then the embedded view uses the tag path for indirect bindings within. Performance has been fine, but I’m curious to see the difference with your method.
What is IAs response to these above comments?