Common Project Mistakes (And How to Avoid Them)

Speakers

Kent Melville

Director of Sales Engineering

Inductive Automation

Mara Pillott

Senior Applications Engineer

Inductive Automation

When first designing industrial automation projects, it’s easy to make some common mistakes that can make integrating harder than it needs to be and cause headaches down the road. The best way to set yourself up for success is to recognize best practices as soon as possible. Not only does this save time on rework and future development, but it also allows for more predictability, better organization, and increased functionality.

In this webinar, two experienced engineers will point you in the right direction, offering tips and tricks while highlighting some of the most unique and powerful Ignition features. You’ll learn how to:

• Optimize tag allocation, data collection, and system structure
• Create better-looking, easy-to-navigate HMIs with the Ignition Perspective Module
• Dynamically connect screens and components
• Understand when to use scripting

Episode Transcription

00:00
Kent: Hello, welcome to our webinar, “Common Project Mistakes (And How to Avoid Them): Expert Tips for Collecting and Logging data, HMI Design and Scripting.” We're glad you joined us today. My name is Kent Melville, I'm the Sales Engineering Manager at Inductive Automation, and I will be moderating our webinar today, but joining me is Mara Pillott, who is a Senior Applications Engineer here at Inductive Automation, and I'm lucky enough to work with her on a regular basis. And so, Mara, can you please tell the audience a little bit more about yourself and what you do here? 

00:37
Mara: Sure, I've been working with Ignition for about a decade, first as an integrator and later for IA's applications engineering team. I've spent lots of time with customers onsite and also assisted them with project design on web meetings. Sometimes being involved really early in the implementation with architecture discussion and proof of concept, we can assess with the best practices and guide customers through the early design stages. Other times, we're contacted later in the process when those pain points are encountered. Good planning early can avoid these pain points, and I hope today's webinar will give you some good strategies.

01:12
Kent: Yeah, thanks, Mara. I also wanna introduce everyone to our software platform Ignition. In case you don't know, Ignition is a universal industrial applications platform for HMI, SCADA, MES and IIoT, and really, we've been able to make a splash in the industry because of our unlimited licensing model. Also, we have cross-platform compatibility, IT standard technologies, scalable server-client architecture, it's web-based, web-managed and web-deployed for designers and clients. There's modular configurability, you just pay for what you want, and it comes with built-in rapid development and deployment tools. So what's on the agenda for today? Well, first, we're gonna talk about why it's important to understand best practices early on and recognize common mistakes, then we'll spend most of the webinar discussing solutions for common mistakes and data collection and logging, HMI design and scripting, and we'll answer as many questions as we can at the end.

02:08
Kent: I wanna start us off with an interesting quote from Dan Stauft. Dan is the OT director at a food manufacturer called SugarCreek, and he's also a very active member of the Ignition community, and Dan was a guest on one of our Inductive Conversations podcasts, and he said, "Ignition's so easy that you can throw a screen together that's fully functional and you can do it in a very inefficient manner. Knowing now what I wish I knew then, I probably would have gone through the whole Inductive University, the whole course scheme, to really understand the best way to do things." And so it really shows that Ignition is a double-edged sword, and that's because it's so intuitive and easy to use that sometimes developers find ways to accomplish tasks that are inefficient or unnecessarily complex, and on a small scale, that isn't really a big problem, but when you get to an enterprise level, it can become a headache that makes large-scale deployments time-consuming and makes fixing potential problems overly complicated.

03:09
Kent: So Ignition is designed for building assets and then repeatedly using them or modifying them, but you can't do that if there are underlying issues that cause problems when an asset is moved to a different context. So today we're gonna be going over some of these common mistakes, some of these things that people do is they're building screens when they're not familiar with Ignition platform, and we're gonna have Mara offer some better alternatives and better ways that you can build these things. And so with that Mara, over to you.

03:38
Mara: Thanks, Kent. The first area we're gonna look at is our data collection and logging, that is the foundation of every project. Now, I know screen design is the funnest part and you are excited to jump in, but it's really important to think about tag structure and data collection before you finalize your screen design. Keep in mind that reusability is the key to good screen design, a consistent and efficient tag structure is crucial to both screen design and data collection and logging. The first mistake we'll look at is inconsistent tag structure. Remember, consistency is crucial for reusability, inconsistent tag structure slows development time and prevents you from using templates or reusable views.

04:21
Mara: I see this most often when someone has built a screen for one device, then they realize, well, I need a screen for a similar device, but maybe with an additional setpoint. It's really easy to just start a new tag folder, add the tags, set the tag addresses directly, and then you could just copy-paste a new view or window and set a few tag addresses, but this is not scalable and it's not maintainable. Another common mistake is to drag in all the tags from the PLC. This allows the PLC to dictate the tag structure. Each PLC could have a different tag structure, leading to inconsistencies. Excessive network traffic could be created by polling unnecessary tags. Consistency leads to reusability and inconsistent tag structure will increase development time and be impossible to maintain.

05:10
Mara: The solution is User Defined Type. Use UDTs to ensure a consistent structure. Reusable views or templates can easily be built from a UDT, tag addresses can be parameterized and multiple UDT instances can be created with just a few clicks. Modifications to a structure on a UDT can be made right on the definition. The changes will apply to all instances automatically. No more repetitive copy-paste. The next mistake we'll look at is improper polling frequencies. One mistake we see often is using the default tag group for all tags. The default polling rate is once per second, this means PLC tags poll once per second, expressions are recalculated every second, and query tags are hitting the database for data that may not have changed.

06:02
Mara: Polling too often can slow down your system and waste server space, now not polling enough runs the risk of not collecting important data and therefore misrepresenting the efficiency of operations. It's important to understand the scope of your project early on to determine which information needs to be gathered and how frequently... The solution is tag groups. Let's talk real quick about: What are tag groups? The name “tag groups” is new in Ignition 8, but the concept comes from scan classes in previous Ignition versions. Tag groups give you a place to define settings for how you should poll a device, so just poll mode and frequency. When you create tags in Ignition, you assign them to a tag group so they know how often to poll the PLC.

06:47
Mara: Consider the ideal poll rate for your data points, create additional tag groups as needed for slower or faster rates, assign tags to a slower tag group for reduced network traffic, assign tags to a faster tag group when needed. Avoid fast polling SQL query tags just to check if values have changed, only query the database when needed, poll rate for expression tag scripts should not be faster than the execution time for the expression. If you have a complex, long-running expression, other tags in the group could be delayed while the expression executes. If all tags are set to default tag group, one long-running expression tag could slow down all tags on the gateway. The next mistake is using the default and historical configuration for all tags. By default, a tag with history enabled will record on change, if the value changes by 0.01. Now, this gets a little more complicated in analog mode, but when thinking about capturing value changes, just start by considering the significant digits for your data points. A floating point tag may not be accurate to two decimal places, and the log can have many extra records with insignificant digits. Other floating point tags may have more significant digits, and value changes could be missed.

08:10
Mara: In some cases, you may require values reported at set intervals instead of logging every change. The solution here is tailoring your historical configuration. It's important to determine the best sample mode for your needs: On-change, periodic, or by tag group. On-change mode will record values only when the tag changes by the deadband amount. Periodic and tag group mode will record values at set intervals. You may choose to record a tag value every five minutes or only once per hour. Set deadbands to the appropriate number of significant digits for that tag to reduce unnecessary records in the database. You can also change your deadband mode to percentage rather than absolute mode. Next, we're gonna talk a little bit about architecture. Do you need a hub and  spoke architecture? Does your system need a scale-out or enterprise structure? Will standard set-up be enough? Finding the best architecture for your project allows you to optimize the number of tags your system can handle. Standard architecture is valid for the majority of use cases, but the most common architecture mistake is overloading a single gateway. As your system grows, it can be tempting to try to over-leverage a gateway by adding more and more devices and tags.

09:35
Mara: At a certain point, you'll see performance degradation on the gateway, such as stale tags, high memory and CPU usage or clock drift log warnings. The solution: Consider distributed architecture. Consider this before a system gets too big, rather than overloading a single server; you can split the load between the front-end tasks and the back-end tasks; back-end gateway handles back-end communications, dealing with all the PLC and device communications. The front-end gateway handles all of the clients serving up data polled from the back-end gateway; this is all made possible through the gateway network, connecting gateways to each other and allowing tags to be shared through remote tag providers. The right time to move to a scale architecture will be different for each system, but it's common to evaluate this architecture when you have about 250,000 tags.

10:34
Kent: Thank you, Mara. Before we move on, let's do a quick recap, the common data collection and logging mistakes that we covered are improper or inefficient polling frequencies, as well as poor tag structure and organization. Now, the solution for that is that you need to go in at that appropriate poll rates and tag groups, this means that if you are connecting up to a PLC and you just say it's an Allen Bradley device and you see all the tags and you just drag them in, it'd be easy to leave them at the default, which is once every second when that's not necessarily appropriate for all of your tags, and we had a couple of questions come in around this where people said, well, isn't this determined by engineers and things like that? The tag rates, isn’t that part of the PID revisions, all that kind of stuff?

11:19
Kent: And the answer is, you think it would be, but so many people just drag in tags and let all the defaults apply there, and so really coming in and making sure you set those appropriate and also by defining UDTs for that structure is really what makes the difference here, so you can make UDTs in Ignition match the UDTs that you may already have existing inside your PLCs, so use those UDTs, use a consistent folder structure, and the naming conventions, you can set an Ignition and those may be once again, different than the naming that you use in the PLC, 'cause you can standardize it in Ignition by using aliases, and so that is our first section, and with that, I'll pass it back to you, Mara, for HMI design.

12:02
Mara: Alright, thanks Kent. So we're gonna move on to some common HMI design mistakes. This mistake is very Ignition-specific, before you jump into building, you need to think about the requirements of your project and choose the right visualization module accordingly. The Vision Module is our classic workhorse, it's what many of our customers use, and it's incredibly powerful. Choose Vision when you need operating system resources, local file access, serial port access or custom Java code running directly in the client; however, if you know that your project requires web/mobile-responsiveness, and this is more and more in demand all the time, you'll need Perspective. This was built mobile-first for iPads, iPhones, Android devices, and can fit on just about any screen. By choosing the wrong designer, you run the risk of building half a project, only to realize now you need to rebuild it in a different module. So maybe you're lucky and you've never seen a cluttered or hard-to-read screen.

13:08
Mara: Sometimes the underlying cause of a cluttered screen is an incorrect container type, it's really tempting for new Vision users to use the coordinate container because it's the most familiar... But it's not always the best container for your use case and other container types should be considered, we're gonna take a look at some examples for each Perspective container type and some other HMI design pitfalls.

13:35
Mara: Our first mistake is not considering mobile-responsive design, so let's look at this example. We have a coordinate container, it fits very nicely on a desktop, but it's not resizable, and on a mobile screen it's cut off. Clearly, mobile-responsiveness was not considered at design time. The solution is using a mobile-responsive designer. This Perspective view uses a flex container and it's gonna resize nicely on a desktop or mobile. So let's take a quick look at our Perspective container types. First, we have the flex container. Think of this as your go-to container, the flex container is best suited for most mobile-responsive screens, it can alter components' width and height to fill the best available space to accommodate all types of devices and screen sizes. Components can be expanded to fill available free space or they can shrink and wrap to prevent overflow.

14:35
Mara: Next is the coordinate container. Coordinate containers are best for HMI screens or building diagrams, when you don't want components to resize and shift positions, you can also use a coordinate container when you want components to overlap, for example, you may want labels on top of a motor display or a sparkline centered inside a tank, component size and location are relative to the parent container size and location, the components can be fixed sized or optionally, they can grow and shrink when the view is stretched. Next is the breakpoint container, use the break point when you want totally different components on a mobile or desktop, there is a single breakpoint in exactly two views, one for small and one for large, the smaller view will be displayed when the screen size is less than the break point, and of course, the larger view will be displayed when the screen size goes over the break point. Now, what if you want the same components on all of your screen sizes, but you want them in different positions with different sizes, so now it's time for the column container.The column container has three break points: Small, medium and large.

15:51
Mara: Each breakpoint has 12 columns and as many rows as you want. On a smaller screen, each component may take up all 12 columns, but each component may have its own row. On a wider display, the components may share a row. Next is the tab container. Use this when you want classic tab strip navigation. This is often useful for a complex device or process; for example, maybe one tab will have set points for a device and the other tabs will have charts or history or real-time status for that device, there is only one component per tab, but this component could be an embedded view, so that would also include other components. Now let's have a look at a cluttered and hard-to-read screen. Screens are difficult to read if there's too much information, so you should consider grouping your data into tabs or grids. In this example, the components are not aligned, the motors and tanks and valves do not stand out from each other, the font is not consistent, we don't know which highlighted component is important, because almost everything is highlighted. One trick that goes a long way is to use grids and rulers, not that everything needs to be rigid and priceless, but making sure things are lined up correctly and appropriately sized will greatly improve legibility.

17:20
Mara: Now, screens have numbers and words, but remember, you're working with a visual medium, it saves time and improves clarity to convey information visually by using symbols. Here, it's really easy to pick out what is a motor, tank, and valve component. Your goal is to have a common look and feel that extends to your entire project with consistent headers, fonts, button designs.This can be accomplished with the use of styles and themes. To once again hit on that point of repeatability, styles and themes allow you to create a custom look for views and components, which can then be reused as you design more screens.

18:02
Kent: So Mara, what is the advantage of using the style classes versus the inline styles that you would select directly on a component? 

18:09
Mara: Good question. Say you decide that you wanna update all of the links to have a different color when you hover over them. Rather than having to search for each instance of a link, if you have them all assigned to a style class, updating the class will automatically update each one. It's a huge timesaver and ensures that your project has that consistent look and feel.

18:32

Kent: Awesome, thank you. 

18:34

Mara: So when a user first sees a screen, the last thing they want is to be looking around searching for important information, so if you're using color, size, position, isolation and contrast, you can emphasize what's important, quickly alleviating any confusion. In this example, only the faulted pump is highlighted and this immediately draws your eye. Another solution for hard-to-read screens is the High-Performance HMI. Here's a comparison of a traditional HMI versus a High-Performance HMI. The goal is to help the viewer make the best decision in the shortest amount of time after interacting with the HMI, this design typically uses gray-scale colors rather than the traditional graphics and bright colors for their displays, the critical states should stand out.

19:29
Mara: A similar mistake to hard-to-read screens is the hard-to-use screen. What good is a beautiful HMI if you can't use it properly? Probably the most important thing to keep in mind is that you can make actions more efficient by picking the best component for the task at hand. Ignition has a massive component library and each one has its own functions and features. If you're having trouble accomplishing something, the solution might be as simple as choosing a different component. And if you can't find the exact component you need, be sure to check the Ignition Exchange. The Exchange is a platform to share and discover free Ignition resources developed by members of the Ignition community, as well as the Inductive Automation team. There's a lot of great stuff on there, from a configurable dashboard to a froggy game that teaches you how to use flex containers. It's consistently updated, and everything available on the Exchange has been tested and approved by our engineers.

20:31
Mara: Here's another tip for making screens easier to use. Establish a consistent hierarchy within and between views. So this is gonna start with choosing a navigation strategy. Ignition allows you to display consistent docked views on every screen. This way your users know that, no matter where they are in the system, they're always gonna see the same menus. You can choose the menus dock on the side of the screen, or the top or the bottom, and you can use any combination of these menus. By using the shared settings, the same menu will appear in the same position on every screen.

21:12
Mara: So here's a screenshot from our demo project. We have a menu tree and it's docked on the left side of every screen. Now, these menu tree items can have as many sub-items as you like, you can categorize your navigation. But, remember, just avoid nesting sub-items too deeply, 'cause you wanna avoid having excessive clicks. Now, let's move on from menu navigation and talk about buttons, or navigation on views. Users will interact with the HMI primarily by clicking. So make it clear what is clickable, avoid custom buttons that don't look like buttons or clickable components. In this example, we have a clickable label for batch history in the lower right corner, but it's not very obvious that you might wanna click that label. Here are two better examples of showing the user where to click. In the first example, batch history is highlighted and underlined like a clickable... Like a classic HTML link. In the second example, the batch history is obviously a clickable button and consistent with the stop button. Now, even if all your buttons and labels are looking distinct and obviously clickable, something else to keep in mind is separating your categories from utilities. So say you have a row of identical tabs at the top of a view, you don't want one that's gonna, say, activate a sidebar right next to one that logs you out of the system. You also wanna avoid making users click too much.

22:48
Mara: Constantly drilling down into menus wastes time, creates confusion and increases the chance of errors. Ultimately, HMI design boils down to quickly and correctly connecting people to the content they're looking for. For our last HMI design mistake, we're gonna take a look at incorrect bindings. This ties back in with the previous topic of data collection and tag allocation. Recognizing when to use direct versus indirect bindings improves data collection efficiency and helps to create a more dynamic system. So how do you know when to use indirect binding? Well, whenever you find yourself tempted to copy/paste a component and then change your direct bindings, that's time to consider an indirect binding. And again, back to the theme of reusability, similar to the UDTs that we talked about earlier, understand when to use templates and embedded views. You've already put in the work of designing views and components, why build them again? If you find yourself tempted to copy and paste a group of components, consider creating a reusable view or template. Keep in mind, though, one thing to avoid when embedding views is deeply nesting. Be sure to stick to only a few levels of embedded views. You also need to know when to use parameters and transforms instead of bindings to further increase functionality.

24:23
Mara: In this example, there are five instances of the blend tank view on a Flex Repeater. Each view has a device number parameter. The same components are on each view, but they're linked to a different device. We could have manually added each instance to the Flex Repeater, but it's often faster to use a transform. Linking a transform to a source such as a query will allow your content to be dynamic. In this example, we used a loop to add five instances. Now, a list of views could have been generated from a database query containing equipment information, then if a newer equipment was added, it would appear on the screen automatically.

25:05
Kent: Alright, well, thank you, Mara. And so we had a lot of good information for you guys there on HMI design, and so we're gonna finish off this section with a recap as well. Some common mistakes are choosing the wrong visualization module, choosing between Vision or Perspective, having cluttered or hard-to-read screens, and so make sure you're thinking about that at the beginning before you start building your project. You also need to choose the right container type. You can use symbols, grids and rulers, emphasize important information with color, position size, isolation, contrast, and incorporate a High-Performance HMI philosophy.

25:42
Kent: Also, some more common HMI design mistakes are hard-to-use screens and incorrect bindings. The fix for these mistakes are choosing the best component type, maintaining a consistent hierarchy, a common look and feel, and using styles and themes. And remember to think in terms of clicks. Consider affordance, separating categories from utilities and to avoid too many clicks there. For bindings, think about whether you need direct or indirect, use parameters and transforms when you can, as well as templates and embedded views. Mara, back to you to jump to scripting.

26:18
Mara: Alright. So we're gonna switch gears a little. We're gonna talk about scripting mistakes, like creating overly complex solutions. Now, the go-to move for some developers, especially those who come from a computer engineering background, is to get in the designer and just start scripting away. And while that can work, understanding when to create a script versus using a binding, or simply the built-in function of a component that accomplishes the exact same thing, will help you to build faster and avoid any strange issues down the road. So ask yourself, ‘Am I using a script to set the value of a component and I can use a binding instead? Is there some built-in functionality that meets my project needs?’ So Ignition comes with all these great components, you have the Ignition Exchange, so before you start with a lot of complex scripting, just have a look at what's available. Now, here's a common mistake. A user is not familiar with binding, so they're gonna add a parameter to a view or a window, and then if that parameter changes they're gonna have a script, and that script is gonna go around and it's gonna find all the components that use that parameter, and it's gonna reset all the values. So this is overly complex and it's difficult to troubleshoot. If you have a consistent tag structure in place, indirect binding is gonna work hand-in-hand with the parameters.

27:43
Mara: The tag address will automatically be updated when a parameter value changes. Scripting functions are a great tool and they can be incredibly useful, but having too many in a single view and linking them all together can leave you chasing down a problem if one were to occur. So before you open that script editor, check that Ignition doesn't already have that feature or functionality built in, because most of the time it does. Be cautious if one script is calling another script and then calling yet another script, this is a sign that something should be simplified. Having unorganized scripts is another simple mistake that can become a mess really quickly. Refining your scripting functions allows you to use them repeatedly. If you find yourself tempted to copy and paste several lines of code, it's very likely time for a function. Beyond that, categorize your scripts into libraries with standard locations and naming conventions. You're trying to make finding the script you're looking for as easy as possible. Be consistent with structure and naming. Group scripts into packages. Another thing to keep in mind is to use comments in your code. Do you know what that script does and why? If you come back to a script months later and there's no comment on it, you might have no idea what it does. This has happened to me.

29:06
Mara: No matter how great of a scripter I think I am, I'm gonna forget, I need to put those comments in there. So we keep hitting on the idea of repeatability again and again. You don't know what your scripts do, you're not gonna be able to reuse them. The final mistake we'll cover today is misunderstanding the scope of a project. There's a difference between how scripts act based on whether they cause a gateway event or a client event. Furthermore, depending on screen size and resolution, scripts can act and look different in the designer versus in the client versus the gateway. For example, a script that is interacting with the Vision client tags cannot be called from a gateway timer script. Navigation will not look the same in the designer versus the gateway. Similarly, when adding properties, understand when to add custom properties versus using session properties to store the data within the session itself. A custom property is only visible to that parent view. Now, a session property is shared between all the pages and views in the session, so use a session property if you want all the views on a page to refer to one parameter, or if you need to switch between views using the same parameters. You can then bind the view to the session property and set it once.

30:26
Mara: This is gonna avoid saying, well, I know this parameter, and now every time I open up another view I'm gonna pass it over there, or I'm gonna make sure that everything on this, on this same page, gets this parameter set via a script. Bind it to a session property one time and it's gonna change for you automatically. Now, message handlers are also a great way to pass data between components and views. A message handler can take action on the data that was passed to it, and it could refresh a table, populate a Flex Repeater, or add a new pin to a chart. The possibilities are endless. Now, before incorporating message handlers into your project, consider whether the scope should be limited to the session, page, or specific view. For example, if you've opened a pop-up to pass the value back to a view, the message handler scope should be set to page. If your message will only interact with components on the same view, you can use the view scope, no other views will respond. Now, if your message handler doesn't seem to be responding, check the scope, that's almost always the source of the issue.

31:36
Kent: Perfect. Thank you, Mara. And so, one last recap to sum up scripting here. Common scripting mistakes include creating overly complex solutions, having unorganized scripts, and misunderstanding the scope of the project. The solutions are understanding when to use scripting versus when to use bindings, not overdoing it with scripts, and defining the scripting functions and categorizing them into libraries with standard locations and naming conventions. You should also remember to use commenting code so you can reuse these scripts you've already written. You don't know how many times I've come back a week later after writing something that I thought was really simple and really clear, only having to reverse-engineer the whole thing 'cause I didn't comment it. So please comment your code. And lastly, please consider the scope — gateway versus client versus designer — so that you can also know if you want to have custom properties, session properties, and when to incorporate message handling.

32:27
Kent: In conclusion, it's easy to make mistakes. We've all done it. Fortunately with Ignition, it's just as easy to fix these mistakes then avoid making them in the future. And using best practices we've gone over today, you can use Ignition's repeatability and reusability to start building solutions quickly and efficiently, all while keeping your projects organized, efficient, stylish and user-friendly.

32:52
Kent: So before we jump into the Q&A, now that you know how to avoid common mistakes, we wanna invite you to try out Ignition for yourself. You can go to our website and simply download the full version for free, and use that for as long as you want. Also, we had a couple of people ask about, “Is there training for this as well?” Yes, we have free online training at inductiveuniversity.com. There's hundreds of free training videos, and also our online user manual at docs.inductiveautomation.com can be very helpful. Also in 2021, our Ignition Community Conference here is only three weeks away. It's our biggest event of the year, featuring a keynote address, the Developer Panel, the Discover Gallery which is filled with innovative Ignition projects, and of course, the Build-A-Thon Competition, and lots of community sessions. If you haven't attended ICC before, this is a great opportunity to do it while it's virtual and free. Normally it's a live conference here in Folsom, California, and you learn a lot about the Ignition platform, but also it's a lot of fun, especially the Build-A-Thon, which is something I'm able to participate in, where you get to see people in the community go head-to-head building Ignition projects on the fly.

34:06
Kent: Also for this year of ICC, we've got a new and improved platform for virtual networking, and all this happens September 21st and 22nd. It's all free, so register at the link shown on the screen, icc.inductiveautomation.com. So with that, if you'd like us to give you a personal demo of Ignition some time, you can give us a call at 1-800-266-7798 to speak with one of our account executives. And now let's jump to questions. And so there have been a variety of questions that have come in. Mara, we had some people ask if you have any more specific recommendations on how to organize your views and your tag structure, so you're in the designer and you're starting to build out your views, what folder structure do you like to put in for your projects for your customers? And same thing with tags, what kind of folder structure do you like to put into place and are there any pitfalls there? 

35:00
Mara: Sure, so I love categorizing and organization, so I try to separate things out by maybe area of the project, area of the building, perhaps I'm gonna have a folder for all of my admin set-up, things like user management tools and a folder for navigation, and then I'm gonna have a folder for say, tank management or batch management. And then within those folders, I might separate that out by functional areas. I like everything to go by some sort of function. Same thing with the tags. Maybe I'm gonna say that these are in the brew hall, or these are in the bottling line, I want those folders out by the area of the plant or the function, and then drilling down into each motor or each room, each area, and then sometimes, like I said, by... by things that are specific to navigation or admin versus things that are specific to plant functionality.

36:04
Kent: Perfect. And then also, we have some questions about Maker Edition, and I'll go ahead and talk about this one a little bit. So for those who may not be aware, in addition to the commercial product Ignition, we also have a product of Ignition, an edition of Ignition, just 'cause we like rhymes, an edition of Ignition called Maker. Maker Edition is a free version of Ignition that allows you to use it for home and personal use. So I use Maker Edition in my house to control some lights and other things connected to Alexa and things like that. The question was, how much can you do with it? So the Perspective Module is what's included. And so you can create visualization screens, it just has a little note that when you launch a client, that says like, “Hey, you're using the Maker edition version of Ignition.” But after you click Okay, then it allows you to just use the visualization client, and you can connect up to third-party APIs. It does have some limitations on the number of tags, I think it's like 10,000 or something, so you should be okay for most home-use projects, and you can read and write the SQL databases, so you can do a lot with it.

37:16
Kent: So yeah, I have a lot of fun with Maker Edition, but certainly it's not intended for any projects for commercial use or paid services or things like that, and it would just be for at home playing around, tinkering, setting up your own stuff. Let's see. Other questions that have come in. Mara, a question for you. Somebody asked about error messages and how you can in Ignition try to figure out what's going wrong? And do you have any comments about strategies you have of when you get an error message, what kind of information you look for, what are some of the locations within Ignition that you go and look for details about those error messages? 

37:57
Mara: Sure, so I usually start by, you're gonna have this pop-up or you're gonna have something in your console and it's gonna give you some clue as to maybe the line number for your code or some error message, sometimes it's gonna be a very helpful message, sometimes it's gonna seem a little vague, so I'm gonna start there with my console. Sometimes I notice in Perspective early on that if I were testing a client, I would click a button and nothing would happen, I wouldn't get a message... Just nothing would happen. So the next place to go is always your console log on the gateway, you can even filter down by errors or warnings, and that's gonna give you some really good information about why didn't something behave the way that I expected in the client. And finally, what I'm going to do, if I look at that line number in my code or I look at the error message for the component maybe I really don't know.

38:57
Mara: Next thing I'm gonna do is go to the Ignition forums. I can usually just find the information that I need in there, and then finally, if it's a script, now I start thinking about, you can't really step through a script in Ignition, but you can get some output along the way, so I can do things like using system.perspective.print or the print statement in the Vision Module, and I can ask myself things like, "Am I making assumptions about what data I'm reading my script? Do I think I've given it the right parameters, but really I haven't?" And usually that's gonna help solve my problem, and of course, you can always call support, but always feels great when you can get through those things yourself and figure out what you've done.

39:40
Kent: Perfect, somebody asked a question about, what's a good reference for high-performance displays? In general, our high-performance displays, we like to look at the ISA-101 standard for HMIs. And if you review that standard, it has a lot of good information there to go deeper than that, it really gets to industry-specific things, and so if you Google ISA-101 for your industry, you'll often find articles or even books that walk through implementations of that for your industry, but I don't have a specific general recommendation of what to look at, but I would definitely start with the ISA-101 standard. Another question we had was, you mentioned not to have too many nested views, what is the limit, and does the same concept apply with Vision templates? So I'll hit on that a little bit and then Mara if you have any comments you can add to it, but with Perspective especially, it's set up to be extremely dynamic, and so you can have nested views based on nested views, based on nested views and all of those can be parameterized, so what is actually rendered inside of those nested views could be determined by an expression that evaluates on its parent view or so forth.

40:58
Kent: And so what that ends up meaning is that when we actually go to render Perspective, you load the first view, those expressions or those bindings evaluate, and then that determines what to load next, and so then it goes and starts loading that next tier, and we have to wait for those expressions or bindings to evaluate before we can load the next tier and same thing for the next tier, and next tier, and because it can't load all of them all at one time, if you have too many nested views, that can really slow down the loading time of your screens. And so it's this two-edged sword of saying, "Alright, I like the dynamic nature where everything can be changed dynamically on the fly based on changing one parameter, but at the same time, that change that parameter has to cascade through all of the different nested views then in order to render properly." And so we say normally don't do more than two or three, you can certainly do more than that, you're just gonna start to see a performance hit, that's also gonna depend on how complex the views are, how much needs to load all of that. So it really is hard to give a concrete answer, but in general I don't like to go more than two or three nested views. Vision can have some of those same problems, but it does a little bit more of compiling ahead of time, and so it doesn't tend to have as many of the same limitations as loading, but it certainly can run into the same problems, but Mara any comments about that? 

42:25
Mara: Yeah, I would also recommend no more than two or three, and sometimes I'll think about rather than maybe nesting one view inside of a view, could I use some parameters to just help me maybe reconfigure that view a little bit in different cases? Just yesterday, I had a project where I had a chart and I wanted to reuse that trend on a different view but the customer on that view, they wanted to have a heading on the chart, and in the view where we were first using it, it's just part of the view. Now, I could have said, well, I'm gonna have one view that has a heading, I'll embed this trend view, or I could... What I wanna do instead of one view it's gonna have a heading, and it's gonna have a parameter that tells me whether or not I wanna show that heading, and the header was just attached to the label.

43:17
Mara: So sometimes rather than nesting the views as long as you're not getting really complicated as far as a lot of calculations, you can just show or hide a few things or change the position a little bit to help you reuse that view.

43:33
Kent: Awesome. We had a question here of, “How can we determine the computer power needed for a specific project?” Just a few months ago, we released a new article on our website called the Ignition Server Sizing and Architecture Guide that's available in the Resources section of our articles. And you can also just do a search for “server sizing” and then it'll come up, but it goes through and talks about general use cases for Ignition, it talks about how many tags you're gonna have, how many screens you're gonna have, historical values are going right to the database and then it gives you recommendations. So I would definitely check out the Ignition Server Sizing and Architecture Guide.

44:13
Kent: Another thing that somebody mentioned was what is the best way to switch, to handle switching multiple polling paths to the same PLC or RTU? Mark, I'm gonna guess you're talking about if you've got redundant network paths or something like that. Within UDTs, it's really easy to set up parameters with your tag paths, and so you can just have a script or something that's trying to access it via the first IP address and then if it can't talk to it, then it swaps out that parameter and tries to hit a different IP address, things like that. We actually have an example of that on the Ignition Exchange, Travis Cox made a resource that you could go and look for there, I can't remember off the top of my head what it's called, but it definitely would give you a good example of having multiple polling paths to the same PLC or RTU. We have a question about what's the difference between transaction groups and a tag historian? Both are connected to the database but presented differently in Ignition. Yeah, Mara, you wanna talk a little bit about the difference between transaction groups from our SQL Bridge Module versus our Tag Historian? 

45:16
Mara: Sure, so Tag Historian is pretty specific and incredibly powerful. Once you have that tag history configured, all of these tags are going into the Tag Historian database for you, they're gonna be partitioned out by your gateway settings, maybe a table per month or per week. You get into an Easy Chart, or now in Perspective, this Power Chart, it's gonna be really easy for you to take that tag data and put it on any sort of a timeline, right. Now, what's gonna be more difficult is maybe customizing that data or querying that data. We don't generally encourage direct querying on the Tag Historian, even though using the tools or having that on a table or chart makes those really easy to use. With the transaction groups, you can do things like copy a value from one PLC to another on certain conditions, and that's not something that you could do with Tag Historian. You may be able to run some scripting or do some custom calculations that you couldn't do on the historian, and more specifically, if you are just talking about recording tag history, it allows you to have a flat file structure.

46:26
Mara: So rather than seeing, I've got this table and I've got a timestamp and I've got a tag path and I got value and I've quality and that's all recording in this table. With the transaction groups, you might set up a table that has a feel for a specific value that you want. So you can have batch number of certain temperatures or motor speeds, and they'd all be together in this table, so if you knew that later on, I need to be able to see at a time what was the batch, what was the temperature, what were all these things together in one row of data, you can do that, it's a little more maybe work in development time and it's not going to... You don't even need to take advantage of some of the... Just drag a tag into it... Into a chart or a table to see that history, but if you're looking for specific reporting, that's gonna give you a little more customization.

47:15
Kent: Alright, Mara, I got another question in here for you, he said, speaking of creating a dynamic project, is it possible to create dynamic memory tags? Maybe talk about expression tags, or your thoughts around dynamic memory text? 

47:29
Mara: Sure, you could create a tag on the fly, but I think what we're looking at here more is something a little more dynamic like an expression tag or a query tag. So you could certainly have a tag and you could use an expression, you could refer to PLC tags or other memory tags, you could perform calculation, mathematical calculations, or use some kind of if-then logic. So if I'm above a certain point, I want my tag to read this way or that way, so I hope that answers the question, but I think expression tags are really what we're looking for here in terms of a dynamic memory tag.

48:11
Kent: Yeah. And Neal, if you weren't referencing dynamically creating new tags on the fly and then deleting those when they're no longer in use, I have seen that done. UDTs really make that not too hard. But it generates a lot of overhead, and I generally recommend that you would just use custom properties rather than dynamically generating and deleting tags, or you can use a database to store those kind of values as well. So if that is what you're looking for, it's possible, but not necessarily the best way to approach it. Depending on your use case. So hopefully that's helpful. You guys have lots of questions for Mara, so I appreciate that. It's hard to get through... We won't get to all of them today, but maybe one or two more. Yeah, if you have any thoughts, Mara just on best strategies or practices, practices on passing parameters, just kind of your thoughts there on when you're passing parameters in other views, what that enables you to do and maybe any thoughts on input parameters versus output parameters or any thoughts there? 

49:16
Mara: Sure, so I'm not sure if our question has to do with Vision or Perspective, so I'll try speaking a little bit about both. If I've got a view in Vision, once I open that view, I can very easily just pass some parameters in with my navigation, or maybe I have something that I've selected on a view or a window in Vision, and based on those selections, I'm going... Those are gonna be the parameters for the next view that I open or the next window that I open. So in that case, we really wanna use... We really wanna pass those parameters. So in both Vision and Perspective, when you're using navigation, if you're opening up another viewer window, you can pass parameters as part of your scripts, you can pass parameters in the URL in Perspective. One thing that I ran into with Perspective though, and this is really a case by case, is that sometimes I don't wanna be passing parameters because that starts to get complicated, sometimes I wanna think about having that session variable. So once I've set that, I don't have to worry about passing the parameter to that next view, I don't have to worry that if I switch views, I'm not on the same parameter, I just have it set in that session variable. So I hope that answers the question. If we need more information later, we can certainly take that in an email.

50:39
Kent: Yeah. And I think you're right that if it's just passing parameters into a nested view or something like that, it's pretty straightforward, easy. You can even set it being the outbound parameter, so that when you change something inside that nested view, that can bubble back up to the top parent view, but when you start going down multiple layers or you get to more complex I think that you're right that a session property can be really applicable here, and then also message handling, like you talked about earlier in the presentation, can be really useful because that way, rather than trying to figure out the direct path of passing all these parameters through, you can just directly call, Send Message, and then there will be somewhere listening, they'll be really valuable because also say you put something... You put it a little deeper, like you put something inside another container, you wrap it in a coordinate container or something like that, that can break the layers that you had for passing parameters and so on, so a message handler, you still have that listener in place and so that doesn't get broken. And so that can be really valuable to use message handlers there.

51:49
Mara: Absolutely. I've had that exact problem. I have misplaced my path to a output parameter, but having something bound to a session parameter or making use of those message handlers, now that I've gotten to know message handlers better — great tool. Use them all the time. Session properties, I use them all the time. I think getting to know those two Ignition features is gonna go a long way.

52:15
Kent: And so with that, we are about at the end of the hour, call in, we're happy to set up a meeting to talk with you about your potential development mistakes that have been made or about just some general questions about Ignition. We'll be back for another webinar in October, but until then, please connect with us on social media and subscribe to our weekly newsfeed and our podcast, but thanks for watching and have a great day.

52:42
Mara: Thanks, everyone.