Templates in Ignition Perspective

What is a Template in Perspective?

You can reuse templates in Ignition across a project—or multiple projects when using global and inherited projects. In this context, a “template” can be as simple as building a button with specific scripting to start/stop equipment, display data, or otherwise interact with your system. Or, a template could be a fully featured screen with many components, trends, alarms, etc.

Normally when we use the word "template" in Ignition, we associate that with the Vision module. That said, the concept of templating also exists in Perspective with some key differences. First of all, there's no separate menu tree item in the Designer for templates in Perspective. In Vision, you have windows and templates, and they exist in separate spots on the menu tree. While you can embed Vision templates in windows, you cannot embed windows in templates.

In Perspective, you are only working with Views and there is no differentiation between "normal" views and "template" views. You're given the concept of containers and you can embed containers in views. Perspective has the choice of flex containers, flex repeaters, coordinate containers, etc. To make templates in Perspective, you build a view then embed it into another view. Then, assign the view you want to display and the properties it requires.

To populate the embedded views, create a view that acts as your template, configure various parameters much in the same way that you would for a template in Vision, and map all of the functionality to the components in the view. Instead of being a separate class of object, like a template in Vision, it's just a different view that’s embedding into a higher level View to build up a page.

Why You Should Use Templates in Perspective

In a large scale system, we’ll have multiple pumps, multiple valves, many large pieces of equipment, multiple production lines, and items with very similar data structures. We will want to use templates as a concept along with user defined data types or UDTs to streamline the development process. We can build the templates and the UDTs to act as the backbone for various items in our overall project. Then we can instantiate instances of those views, templates, and UDTs to access all of the equipment on the floor (or devices in the field) without having to copy and paste components or review and update every single graphic on the screen if we are making a change.

If we're using Perspective Views as a template, we can modify the template view and that will update everything in the project. We don't have to modify ten different pump graphics to individually add a tag to each one. Instead, if we modify the pump template, we can easily manage and develop our system with a scalable mindset. We only need to make changes in one place to impact the entire project.

When Not to Use Templates in Perspective

If a project doesn’t have a lot of shared components—for example a facility only has one pump of a particular type—it probably doesn't make sense to go through the additional effort of building a template.

If you have only two or three pumps and your process will never change, you might just build it all quickly as a set of one-off graphics. But, if your facility may scale to one hundred pumps, or you have five or six different types of pumps that may have different tags associated with them, it would make sense to use templates. The only times we don't typically use templates are for very small systems that have a very low likelihood of growth. If you're copying and pasting once, you might not need a template, but if you need to paste something more than once, you may as well use a template.

Perspective Vs. Vision

Another benefit of Ignition’s Perspective Module is that when we want to make a template of one of our views, it's pretty easy to templatize the view—instead of having to create a new template from scratch in Vision. In Perspective, we don't have to copy and paste the individual components from a window into a template. The process of moving from a one-off view to a templatized view is relatively straightforward. While it isn't difficult in Vision, there are some additional steps beyond configuring properties on the window.

Perspective Template Examples and Use Cases

Large Scale SCADA

A large scale SCADA system is one of the most obvious examples of when you should use templates. You may have multiple PLCs, many buildings, or even SCADA spread across an entire enterprise.

Using templates on large scale systems speeds up development time—and most importantly, reduces the overall effort required for testing and deployment.

If you have 50 valves in a system and 50 sets of components, you will need to validate every single graphic component across the project. Then, if you find a bug you will need to go through all 50 sets and make individual changes. However if you are using a template, you only need to make that change in one place, then it will automatically deploy to all 50 instances at once. You will still need to validate the valves in the field, and verify that the graphics line up, but you can trust the templates after the first few valves more than 50 different sets of components.

Automated Deployments

VERY large scale systems or highly normalized operations may have lists of equipment in Excel sheets, Smartsheets, or even CAD systems. By using templates and some clever scripting, you can easily build out an entire SCADA system without having to manually build the screens yourself.

Using this approach, you can build out a plant hierarchy in a database or Excel document along with equipment types, production model, etc. Then, you can run a script that matches up the production model, what equipment goes where, the datatypes it requires, and which templates are required to build out a full project including navigation to the various screens. This script could generate all of the tags automatically, including history and alarms, and the navigation engine will pull up the correct templates and data mappings when using the client.

This automated approach can save you an immense amount of time when developing a system. You will only need to develop the templates and UDTs for each type of equipment you are using as well as your navigation structure.

Remote Map and Location Based Systems

Another step beyond automated deployments, templating is useful for projects where you might deploy equipment all over the country—or the world. For example, by using the MQTT Engine in Ignition along with scripting to generate tags, you can automatically populate your SCADA interface as systems come online in the field. Once the MQTT Birth Certificates are generated, Ignition can do all of the heavy lifting and automatically create instances of your UDTs along with records in the database to populate your map at the correct location. From here you can use templates to display relevant data, dashboards, etc.

Search Functionality in SCADA Applications

Another problem templates can easily solve is enabling search functionality in your applications. When you build out faceplates for various devices (such as valves, pumps, and motors), you can also build out a type mapping table, or pull data directly from UDT instances and let users search for a particular instrument or device number in your system. When they search, results can be filtered and the operator can open up any template they want in the system with only a click of the mouse. This saves time trying to hunt down a particular instrument on the screens.

Toolbox Development

Another way templates can provide a huge return on investment is by building up a tried and true toolbox you can re-use on projects. Some companies have standardized PLC logic for pumps, motors, valves, etc. Why not build out standardized templates and UDTs to go along with the PLC standards?

What to Watch Out for When Designing Templates in Perspective

UDT Property Mapping

One common gotcha when working with templates and UDTs it to not map a UDT type as a custom property on a template. This is true in Perspective as well as Vision. The best approach is to pass in a parameter allowing you to “navigate down” to the UDT’s tagpath and then build up your bindings either as indirect or expression bindings.

This will improve system performance as you will only need to resolve individual tags and not an entire UDT when a user opens a Perspective Page. If your UDT only has a few tags you might not notice a difference, but if you are using something like the PlantPAX libraries on an Allen Bradley PLC you might see long load times.

Versioning

Using templates adds one layer of complexity to the overall development stack in Ignition, so you will want to make sure your templates are a well defined and documented part of your version control strategy. It can be easy to forget to grab the templates when exporting a view. The easiest approach to fixing this is to create your own hierarchy in the tree with a “Templates” folder under Perspective Views for example. Grab this folder any time you change the version control system, and you will avoid headaches down the line.

Global Projects

Along with version control, templates can also be a little finicky if you are storing them in global projects because you will need to have two Designers open if you are making changes.

Best practices will vary based on the company and the project, however understanding where templates live, then defining and documenting the desired approach is a good step to take during architecture development.

Usually, once templates are tested and ready to be deployed it will make sense to move them to a global project as they won’t need to be adjusted as often. But it can be a hassle if you are actively developing them for use in a separate project before testing. To remedy this, we will sometimes use non-global projects for development, then move the templates up to a global project as part of the deployment to production.

UI Considerations

When using templates, you might find issues with some users opening the screens on a touchscreen monitor instead of on a desktop computer for example. One common hurdle is using a “mouseClicked” action instead of a “mousePressed” action. Clicked works fine on a desktop computer, but can be problematic on a touchscreen, so we advise using mousePressed whenever possible.

There are some other issues which come up more rarely, but if you notice any weird behavior on a touchscreen compared to a desktop, it is worth digging into your scripting a little deeper.