Many of you in the Ignition community have excellent questions about lots of industrial/technology topics, including SCADA, HMI, IIoT, digital transformation, machine learning, and Ignition. Kevin McClusky, Co-Director of Sales Engineering at Inductive Automation, answers attendee questions live!

Webinar Transcript

00:00
Kevin: Well, hello everyone and welcome to this month's Ignition Community Live for this edition of Ignition's Community Live in any case. I'm Kevin McClusky, I'm your host. And this is a unique Ignition Community Live, we've never done one like this before. This is specifically "Ask a Sales Engineer," so I think it could probably also be called "Stump a Sales Engineer." Hopefully not, I should be able to answer most questions. But we're really inviting any questions that you have that you want to submit and leading up to this, we also ask you if you had any questions, and you guys weren't shy. So there's three and a half pages of questions that have come in, they're all really good questions and some of them are somewhat basic, some of them are advanced. And I'm going to do my best to get to all of those questions that came in but I also want this to be interactive, so I also want to be able to provide answers to questions that you send over the course of this next hour.

01:10
Kevin: I'll bounce from some of the pre-submitted questions to the questions that you're asking in real-time here. Before I get started, I wanted to describe that team just a little bit, so we have a Sales Engineering department over here. My name is Kevin McClusky, I'm Co-Director of Sales Engineering at Inductive Automation. Travis Cox is the other Co-Director of Sales Engineering, and between us, we run the Sales Engineering team. We have a team of expert architects on our team to help answer a lot of these types of questions that have been asked here. So if you've never called us, if you've never talked to us from an engineering standpoint, you have a main point of contact here at Inductive Automation. If you do, you can always ask them for a conversation with your sales engineer. If you don't have one, one will be assigned to you and we are happy to have these conversations all day, every day. Every single one of us is an engineer who really loves the technology and loves what it enables and seeing what our customers can do with it.

02:15
Kevin: Alright, I'm going to start out just by hitting the questions, we just had some new questions come in. First question: “Is DNP3 for serial port connection, is it available?” The quick answer is no. So our DNP3 driver is specifically for ethernet or for IP communication, and that is the current plan to keep it that way. We don't have any current plans to add serial. That's not to say that we won't do it in the future. But currently, if you need serial DNP3, our suggestion is normally to pair up Ignition with Kepler. Probably about 50% of our customers have Ignition paired up with an OPC server in some way. So it's super common to be connected to an OPC server, and that's certainly not. There's also... It's worth mentioning, that if you have some newer devices that are speaking other protocols like MQTT, we have the MQTT, the whole IoT infrastructure architecture there. That's available, that you can communicate either over Sparkplug, which is a much better protocol than the basic JSON transmit.

03:23
Kevin: But if you have folks who are doing JSON messages over that, you can normally pull those into Ignition as well over MQTT. Alright, and I promised you I'd bounce back and forth, so I am jumping over to the first submitted question that came in beforehand. “How do companies that use Ignition access their data?” So, very wide open-ended question. There are several different ways and really the sky is the limit. You can do it in a lot of different ways but the question is how do companies that are doing it today, not how can you do it, but how are companies doing it? And I'd say probably the most common ways are either with Ignition itself. So if you have Perspective, you can open the Ignition inside a web browser, you can pull up charts and graphs and visuals, if somebody has designed those and that's really common that you just have an ad hoc chart or the Perspective chart, Power Chart that might be on a screen that people can just use and select tags and drag those out and see what's there.

04:29
Kevin: It's also pretty common that for specific industries, folks are going to be doing things like water reports or they might be doing power reports, power consumption manufacturing reports all of those with either our Reporting Module or just on-screen reports, which doesn't require the Reporting Module, that can just be done with Vision or with Perspective. So that's probably the most common way to do it. However, a lot of folks need to integrate with that data from outside systems and so there are a few common ways to do that. Specifically one of them through transaction groups is pretty easy to put data into database tables that are easily accessible from outside systems that are connecting up to the database. If you're connecting up to Power BI, for example, and you wanna pull in information from Ignition or if you're connecting from a data lake that's running inside Azure in the cloud or one of 100 different areas, querying database tables is normally relatively easy to do from outside systems.

05:33
Kevin: Those transaction groups can put the data into a format that you wanna put it in in the database. We do have some folks who query the Historian, the Tag Historian tables directly. If you're doing that, you need to put it in a format that is going to be easily queriable from the outside, obviously you might not necessarily want compression on those tags, you might wanna bypass our compression algorithm. But it's actually more common these days for folks if they wanna access that historical data, especially from other software systems to do it over web services. So restful web services can easily wrap the functions that do the tag querying, and you can pull back aggregate information, you can pull back a certain number of points, a certain number of items, you can pick your aggregation mode, and so then that's the Web Dev Module, generally that's done with that, or the Sepasoft Web Services Module, either one's fine. And then that wraps the function that we have behind the scenes. We have the system that tag...

06:36
Kevin: Query tag history that goes and has all of those options, and so basically that just becomes a point of entry into that, and so there are a lot of systems that support web services that you host that endpoint inside Ignition, and then it makes all of that data accessible from the outside. Now, those are just a few examples of how folks are doing it today, there's... With Ignition, if you know Ignition, you know there's, pretty much the sky is the limit in terms of how you want to actually expose things, to do things to what you wanna integrate with, the libraries that you wanna use, the protocols that you want to use. And so we have a lot of folks who are doing things in different ways than the ones I just described. Some folks are doing stored procedures and database APIs, other folks are integrating with external APIs and sending information back and forth, and that's growing in popularity too, so there are a lot of options there. Alright, bounce back to the next question that was submitted live, real-time here. “When IEC 61850 protocol will be available?” Yes, when are we going to release our 61850 driver for the Ignition platform? Great question. We are working hard on that as we speak. So this is something that we have as a high priority on our development timeline.

08:04
Kevin: What I can tell you is, I can't see a reality where it's not released this year. That's what I can tell you. We can never give specific promises around things, and now there's a really small chance, of course, that something happens that we're not able to actually release this year, but I think that we're currently targeting end of Q1 or Q2, mid-year, somewhere around there. So by the end of 2021, I fully expect that we'll be seeing 61850 driver and hopefully before the end of 2021 as well. Once again, the disclaimer, everything in terms of timelines is subject to change, please do reach out to us if you're trying to do projects or execute on things, and they're going to rely on some of those timelines and we can keep you updated. So just reach out to your sales rep over here at Inductive Automation, whether that's an account executive or technical sales rep, or TSR. Alright, next question that came in, and I'm gonna have to go a little faster I think to get through all of these. Next one that came in from, submitted beforehand. “When will support for Ignition 7.9 end? And what emphasis does Inductive Automation put on integrators to move systems to 8.X?” Good question.

09:28
Kevin: So there are two parts of support. So one part is tech support, the other part is whether or not we continue supporting the release from a development standpoint, and a development standpoint, that means new patches, that means additional features or small feature requests, that means bug fixes, that means security patches, and so Ignition 7.9, just like, it's a long-term support release, and just like every other long-term support release, it's supported for five years from the dot-0, initial dot-0 release. So when Ignition 7.9.0 was released, that's when the timer started for those five years, for the support of that release and that five years expires at the end of 2021. So I believe it's somewhere around December 3rd, it might be December 13th. Okay, I don't remember the exact date, but I believe it's right around the beginning of December. We're actually working on putting together a quick article that we post up to the knowledge space (AKA Knowledge Base) that's going to have all of this information at a glance, just to make it easy for people to find it. We've had the long-term support release policy documented for really long ways back, but it's nice to be able to direct folks to a simple article that answers this question.

10:54
Kevin: So the long-term support release, that 7.9 is out of long-term support at the end of 2021, what that means from a software development standpoint is that we won't be releasing new versions of 7.9. So wherever it is at the end of 2021, that's where it's going to stay, we're not going to release any additional versions, any additional minor releases of 7.9 after that. Our tech support department supports folks who call in all the way back to the very first version of Ignition. So that's kind of a point of pride for me and for the organization that we support people, we try our best to do a really good job in helping folks to work with whatever they currently have. The thing that we don't do for old versions though, is release new bug fixes or release new security patches. And so a lot of folks are running on 7.9, do need to have a good security posture with what they are running on, and so it's required by a lot of organizations to be running on a supported release. If you're one of those organizations, you'll wanna move up to Ignition 8.1 by the end of the year.

12:12
Kevin: If you're not one of those organizations, if it's fine to be running on whatever version that you're running on, and then if you have a reason to upgrade later, you can upgrade later, you've got a little bit more of a window or your policies are a little bit different. You can run on 7.9 as long as you want. We're not going to stop talking to you, our tech support won't stop supporting you, but if you did happen to find a bug in 7.9, then that bug would not actually be fixed in 7.9 going forward after December. That bug would... That fix... As long as there was a fix that we decided to implement, that fix would go into Ignition 8.1, 8.2, 8.3, 8.4, et cetera. So you get the idea there. Alright. A lot of these are really good questions, and they have... There's a lot to talk about with these guys. So jumping over to the next one, that was just sent in real-time, any plans to add commands for injecting alarms into the alarm system, working on a system where the alarming will be initiated from another system and just wanna use Ignition as the HMI to the current SCADA system.

13:28
Kevin: So since you're talking to a sales engineer, I can tell you, candidly, if you're doing really advanced things inside Ignition, if you're going into the SDK, if you're writing a module or you're going against some of our internal items, there's actually a way to do this already, and there's a way to... Even through some of the user interfaces, you can click and say, "Create a new event and test it out." And when you're testing out pipelines, for example, you can do that. That said, in terms of how the alarm system works for acknowledgements for alarm events that are tracked and are in memory inside Ignition, not just things that are being notified out, we don't have any current plans to change the way that that works. So I have worked with some folks who've integrated with external systems and they want to basically feed these alarms in. There are a couple of different ways to do that to tie into the way that the alarming system is written inside Ignition. And one of the ways is to have anything that generates an alarm from those outside systems, had Ignition and have Ignition generate a tag on the fly. So we have functions behind the scenes, there's system tag configure functions that allow you to generate those tags, automatically associate an alarm with them or alarm state, just include that inside the tag generation there and then that can generate a new alarm.

14:52
Kevin: And I've worked with a number of folks who do this, and so they end up with tags that are associated with each one of these alarms. Normally, it's based on some unique identifier that's coming from the outside system, and then you end up with just basically in your tag database, a set of these different alarms that could be generated. And the generation of those alarms, most of the time, these are booleans, and they'll just be turned on and off in order to generate those. That's the most common way that I've seen it. I've seen folks do it a couple of different ways to where they might use an individual tag and have an un-change on that tag, and so you can set up alarms so that they're going to generate alarm events every time that a tag changes. And if you do that, you could have a string tag, have that string change every time that a new alarm event comes in from the outside, and then that'll generate a new alarm event inside Ignition that it shows up everywhere inside the Ignition system as you might expect it to.

15:48
Kevin: Alright, what is your favorite Monty Python sketch or POV? Fun question here. Monty Python Holy Grail, it has to be the Holy Grail. Probably, and if I were to talk about scenes inside there, the Frenchman on the wall, or the scene with the fight with the knight. [inaudible] ... I think those are probably my favorite too. Thanks to whoever sent that. That's fun. Alright— “Do you ever see Ignition naturally supporting MQTT?” I think we see it that way right now, and I see the follow-up that says, Without additional modules that is. So Ignition, if you install Ignition and it doesn't have any modules inside Ignition, you're just getting the Ignition platform, it doesn't really do anything by itself. So if you're buying Ignition and you have a visualization, you do have a module already. You have the Perspective Module. If you have... Or the Vision Module. If you have Ignition and it's doing transaction groups, then you have the SQL Bridge Module.

17:06
Kevin: So there's no such thing really as a standard Ignition install. We have a few packages that we put together that have a set of modules pre-configured inside them, but that's just for convenience, so people can pick those out of the list and say, "Hey, just give into this stuff." I think that for a good portion of our drivers, or pretty much all of our drivers, they're individual modules. MQTT's no different. MQTT does happen to be produced by Cirrus Link and not Inductive Automation in terms of the development team. But in terms of using it inside Ignition, that should probably be seen the same way as any other module, any driver, any additional communication module. And so I wouldn't really see it as, this is outside of Ignition, it's just another module that you can purchase and buy an install and use inside Ignition, just like any other module that we have there, at least that's how we see it internally at Inductive Automation.

18:06
Kevin: “What are some methods used for development costing for applications, sales of applications, installations to clients and models used to make sure development cost is returned during cost analysis and pricing?” Good question, and I'll expand on that a little bit. I actually used to run the Design Services department at Inductive Automation. For a little while we had a team of... Somewhere around... Somewhere between six and eight design services engineers at Inductive Automation who would engage with customers who came to us specifically and asked us, "Hey, can you help us with this project? Hey, we've got an engineering team that we'd like you to do the first version of this." Things like that. We never competed with integrators, we're never going to compete with integrators. But at that time, we wouldn't work with anyone who was already working with an integrator. This was only folks who came directly to us and said, "We want Inductive Automation to do these types of projects for us," and we said, "Are you really sure? We have great integrators," and they said, "We really, really need it for some reason."

19:16
Kevin: Since then, we've actually spun that department down, and so we don't have a Design Services department anymore. If integrators come to us and ask for some additional help from engineers who used to be design services engineers at Inductive Automation, we do have some paid services to do project reviews, provide feedback on best practices, or sit down with you for a couple of days to walk through things or help you architect things. But that's more of a consulting type of thing than project work. All of that said, back when I was Director of Design Services, this is the type of thing that we ran across quite a bit. That honestly, is Ignition experience. So the more you do inside Ignition, the more that you're going to get a sense how long things can take to actually accomplish. Those things are going to be things like designing screens, designing user interfaces, designing data flows, designing how things are going to connect, understanding the different types of devices that you're going to be connecting to and how long it takes to actually connect to those.

20:20
Kevin: Anything Ignition has a driver for, most of the time, that's a really quick connection. But there could be a couple of considerations if the customer that you're talking to, if you're an integrator and your customer doesn't have proper documentation or the network isn't properly set up or there's no routing between Ignition server and the actual devices, that might not be something that takes you engineering time or at least your engineering skills, but it could take some of your engineering time to coordinate and to test things out as their network engineering changes things to make that available.

20:52
Kevin: So the way that we did it was basically, if you take a look at the number of user interfaces that need to be designed and to understand the complexity of those, come up with a number that makes sense for the number of hours for each one of those things. So some really simple screens might be as little as 30 minutes or 1 hour, some really complicated ones might be as much as 8 hours, and so... Or it could be even more, if they have an overall dashboard that's filling in aggregate information from 100 different locations. That's probably not something that will be completed in a day, that might take a little bit longer. Unless that data is readily available, and then maybe it'll take you 2 hours to throw that together.

21:43
Kevin: If you're getting started on your first project, it's a little bit hard to really get a good sense of how long it's going to take to accomplish those things. We would encourage you to just give us a call, talk to your sales rep over here, pull a sales engineer into the conversation. We can at least try to point you in the right direction, we can get an understanding of what your skill level is in terms of engineering and to try to give you a sense of maybe how long this might take, or give you a sense of, "Try this thing out, do this, see how long this piece takes, and then you can extrapolate a little bit in these ways." So we're happy to try to point you in the right direction, but certainly there are a lot of variables, and those variables are as much based on the end-user that you're working with as it is on the details that are listed out in the job and so... Our most successful integrators already do this on a regular basis, and they're very good at it, and they have a lot of experience in Ignition. And if you're just getting started out, we can try to help point you in the right direction as best as we can.

22:53
Kevin: Next question here: “Is Ignition sold as a service currently? That is one server in the cloud for multiple separate customers. Any recommendation for selling this type of service?” Yeah, so we don't sell a service. Inductive Automation doesn't sell Ignition service. There's no software as a service that you can grab from Inductive Automation, that would be buy a month of Ignition access and then you get access to a server. We do have a lot of folks who are posting Ignition in the cloud, and we have partnerships with AWS and Azure, and we have a lot of contacts in these organizations. And we're happy to support folks who are doing that type of thing. The Inductive Automation license agreement, the way that is written, and I don't know if anyone here has actually read through the entire thing, maybe if you needed to work with a legal liaison or something or for your company's legal. But that agreement, actually inside part of it, talks a little bit about cloud hosting and specifically multi-tenant hosting.

24:00
Kevin: So if you're doing cloud hosting for a single tenant, for a single customer, that's covered in the license agreement. If you're doing it for multiple customers or multi-tenant hosting, that's actually a violation of the license agreement. So that's something that you're not allowed to do based on the standard license agreement, but it's also something that we encourage you to talk to us about because we have the ability to offer basically an addendum to the license agreement that allows you to do multi-tenant hosting. And so we have probably 50, 100 or maybe more customers who are doing this multi-tenant hosting and offering services that are built on Ignition. So they spin up a VM or an instance inside the cloud, they spin up Ignition on it, and then they provide this available to their customers. And so we have people in oil and gas, water, wastewater, a lot of things that have geographically-separated assets whether they wanna do centralized monitoring, they wanna sell that monitoring as a service.

25:04
Kevin: And I would say, yeah, absolutely. Go ahead. Go that route. It's a great route if you want to build a business model around that type of thing, or if you already have one and you wanna use Ignition as that central monitoring platform. It's a great way to do things, especially since the Perspective module is out, it makes it so that any of your customers can just pull up Ignition inside a web browser, take a look and be able to pull up any graphs that you created, or charts or information to do data exploits or whatever the features are that you're providing them. And we have some folks who are doing this cloud-based hosting, hosting Ignition as a service, hosting services built on Ignition where they have multiple price levels as well, where basically, you can have the base monitoring at X number of dollars per month, and then you can have something that has more reports and some more automated things at additional X dollars per month or the premium offering that might have some machine learning built-in, and you could be using Ignition's machine learning algorithms there in doing some predictive failures or predictive analysis or optimizations, that type of thing for folks, and then you can basically sell that at a higher level, and then just do that monthly.

26:28
Kevin: So yeah, there are definitely options there. We are along those lines, it's also worth mentioning that the support that we have for running in the cloud right now, that is either run on a Docker image that's going to be running on the same host all the time, or run on a VM and run on an instance. We are essentially working on expanding those things out. So I'm not sure if you're familiar with AWS, Amazon Web Services and their AMIs or the Amazon Machine Instances, but we are, in process, taking a look at what we might be able to do to bring Ignition to the AWS marketplace where you could basically spin up Ignition for a short period of time, and you could just pay a few bucks, whatever the hourly rate is for this, in order to be running Ignition for that time period, and just be charged for what you actually use there. So more information on that to come, that's something that we wanted to do for quite a while, and we're moving toward. It's not in the next few months here, but it's certainly something that we're keeping our eye on in terms of what we can do for those things. So we'll certainly keep you posted as soon as something materializes on that science. So if that would be something that's useful for you, just know that we are taking a look at that.

28:00
Kevin: And I'm going to give some very quick answers to some of these things, so I can rattle this off. I'm gonna get through, probably, I'm gonna try to go through 10 or 20 of the questions that were submitted beforehand, and very quickly, to try to get to as many as I can. If you need more details on these, if these are your questions, feel free to follow up with us afterwards, and say, "No, I'm not going to be able to give a full answer to everything," so I gotta do the lightning round here. Alright, so, next one here:“When do you make the decision to use SQL Bridge for data logging versus using scripting functions?” Follow up:“At what project scale, if any, would you choose SQL Bridge over Tag Historian from logging process data? Bonus points, if you don't say the real answer, “‘it depends.’” Well, you took my answer from me, I'll try for the bonus points. So there's not really a specific scale that I would choose SQL Bridge over Tag Historian. For me, it's not really about scale, and when you're taking a look at it from an engineering standpoint, it's more about, how are you going to use that data? How do you want to display it? Do you want to report on it? Do you want discrete reports? Versus, are you looking for trending and charting? And of course, it's easiest if you just get everything, get all the tools, and then you've got those available and you can mix and match as much as you want.

29:38
Kevin: Of course there's a price associated with that, and I certainly understand that not every project is going to have the budget for getting both SQL Bridge and Tag Historian. But if you do, I'd say get both of them. It makes sense to use both of them together in most circumstances. So any time you've got discrete manufacturing or you've got any discrete processes that are happening event-based logging, I'll normally do those over SQL Bridge, and then anything that's real-time, I've got a tag value that's changing and trending, then I'll do those over Tag Historian on that, and then inside, your reports, you can mix and match the data. So if you've gotta run history, let's say, or a history of every time something kicks on and kicks off, but then you wanna see how it is running over that period of time, the transaction groups can give you a nice clean log of those things, and then you can join that over to the Tag Historian data that you might have to join those things together.

30:35
Kevin: Now, that said, if you do have a limited budget and you can't afford to put both of those things inside a project, normally, if you need report, SQL Bridge might be a better way to go than Tag Historian, because you can technically store that real-time data. It's not quite as efficient, it doesn't have the compression, it doesn't have some of the other nice features inside the Tag Historian, but if it's not a big system, you can normally accomplish both of those things with SQL Bridge as long as you're properly indexing things, you're properly meeting the database, and you are careful in terms of pruning the data or archiving it or whatever you need to do, so it doesn't get too big and slow the customer system down over time. There are a lot of good Python, Jython references. The next question here: “A lot of good Python/Jython references, but I couldn't... Which explains the mixed mode program [inaudible] just Python, Jython, and Java. How does it work under the hood? Can you give me some pointers?” So this is the first time that I'm actually pulling in the designer. I've got a designer. I've got Ignition 8.1.2 here, and I was expecting to show a lot of things, but given the volume of questions and how interested everyone is, I thought that it made more sense to answer things, as many as I can, but for this one, I'll actually show it off.

32:00
Kevin: There's not really specific tutorials on this, because it's not complicated. It's really, really easy actually. So let's say you have a method or you have a class, you have something inside Java that you wanna use inside Python. So this is just a standard Python console and I can type in my list of items is gonna be whatever items I have here, and then I can loop through these for example, and I say for item and list. This is all Python, as I said, print item. If I want to pull Java into this, I just import it. So let's say I wanna use Java math library, I just say from Java.lang import math, that's it, now I can use math. So I'll do print math dot square root of whatever I want right there, and that's going to drop it right there, you can see there, or I can use that wherever I want inside my script, right? So I'll just do that based on these items and I'll say, "Give me my math square root of my item right there, and that's going to run it on one, two, three, four, five." So if you wanna use Java inside Ignition, just import it, just pick your Java class, you can use any of the functions that are inside there. If I come down here, you can see I have access and it gives me some documentation around these things as well. This is all pulled straight from the Java classes here, you've got absolute value, arc sign, arc tangent, sign tangent, all those things, right?

33:42
Kevin: So yeah, there was special tutorials, nothing like that, it's simple as that. If you wanna instantiate classes, it's also just the exact same way, so I don't think you can instantiate math, but if you wanted... If you add something like that, it would just be as simple as that, and that gives you a new instance of whatever the class is and you can name your variable whatever you want there's nothing special with that. If you wanted to find your own classes that inherit from Java classes, you can do that as well, just by using standard Python inheritance. So say my class, whatever my class is, and I'm going to inherit from math. And there you go, and then you can define all your functions and do whatever you want there.

34:29
Kevin: If you're looking for the exact syntax behind this, just look up Jython, Java integration, there's a couple of quick cheat sheets that tell you exactly what this syntax looks like, but everything that I'm showing you here should work fine. If you have Java classes that you wanna import that are from external Java libraries outside of Ignition, what you would do first is you create a module for Ignition that imports those and you can do things that include dependency management like Maven and have those automatically pull things in and then you can use those inside your scripts, so that's the general way to do all of that. And I was promising to go a little faster here. I love talking about this stuff, so I have a hard time not answering these questions, and well, I'm gonna keep going though. “What's the status of the drawing tools for Perspective coming?”

35:20
Kevin: So we don't have that done yet, we've gone through some design, internal design reviews for the overall visual and the overall features and Sales Engineering has been involved in those. I've sat in some of those meetings myself, and we've had a fair number of stakeholders who've been part of those. I really like the direction that it's going, I think that it's going to be really valuable and really a nice feature, the way that we have it, it's gonna be a little bit different than we have at inside Vision. We don't have a specific timeline on it yet, unfortunately. Right now, we're working on a lot of things that folks need, and so that's one of the big features that we have in the pipeline before too long, but we don't have a specific release date for it, unfortunately.

36:14
Kevin: “In Ignition 8, with tags that are generated by MQTT engine, can you still set up trends and alarming and follow up to that? What happens to these tags if the remote client that is publishing the data goes offline?” Yeah, so MQTT Engine tags or the tags that aren't from... The tags that anyway, that aren't living on the Edge, but the engine tags that are representation of those tags living on the Edge. Yes, you can absolutely set up. And I don't know if that's your specific question. I'm answering your specific question, which is for the Engine tags themselves, can you set up history? And the answer is yes. Can you set up alarming? The answer is yes. And for those Engine tags, if you set up those things on the engine tags, that engine is running on whatever Ignition Gateway that you are running Engine on, and so if there's a disconnect and a reconnect, then those... It doesn't have the information there for the meantime for those things.

37:15
Kevin: And so you can have replay on those values and you can have those basically kind of catch up. Basically, if you're running from the engine tags, the central testing, you're not going to get any data during the time that there's a disconnect and a reconnect. If you want that, you wanna do things on the transmission side, you wanna do things on the tags that are coming from the device. And you can set up history there as well, and then alarming as well, and if you do alarming from that side, you wanna do alarming over the Gateway network, so that alarming would be set up so that it was... You have the MQTT path for real-time values and for historical values, and then you have the Gateway network for doing the mode alarm pipelines and the mode alarm type of things. So normally you'd have those two things in parallel if you need both alarms and real-time data transfer over MQTT and historical, and then if you set that up on the Edge, if you're using Ignition Edge, it'll have all that stored for built in for the alarming, all of that will go over and then for the history as well.

38:17
Kevin: So the alarm should be able to see the full alarm history and journal of what happened when there was a disconnect and reconnect, that'll happen over the Gateway network. And then for the history of the tags, that'll happen over MQTT's history backfill, and it'll essentially replay that history at the central Ignition Gateway or whichever Gateway is running MQTT Engine. Does Inductive plan to introduce their own modern time series data storage solution or continue to simply integrate with others? So as of right now. We have the ability, as the question implies, to integrate with others, so if you want to use something that is just with Ignition's modules, modules created by Inductive Automation or our partners that we actually sell, you can use Postgres with Timescale. That is one good solution for doing time series. There are a couple of other time series databases that you can connect through a JDBC driver for, but Timescale is probably the easiest one to get set up. And that'll support somewhere around 30,000 tag changes per second, and relatively quick querying back and consistent performance over time. So we have a number of folks who've gone the Timescale route at this point, 'cause it doesn't require anything else outside of that.

39:36
Kevin: We do have a number of folks who we've helped with writing some of their own modules, and we have allowed them to tie into Ignition's Historian, so they basically have storage engines for Ignition's Historian. And those storage engines go to all sorts of time series databases as well, so there's... If you take a look at our module showcase, you'll notice a number on there. And those are certainly options. Do we have plans to introduce our own modern time series data storage solutions inside Ignition? Nothing I can talk about right now. We certainly have... So that's circling back to the original question. We certainly have... We've got considerations around where we wanna go with Historian, what we might want to add to it going into the future, what that might look like in terms of the next major features that we have, connectors to additional things, things like that. But there's no solid plans that our development schedule around them as of right now. So, that's the quick answer to that. Maybe I should have started there, but I wanted to give you guys a little more context.

40:57
Kevin: What Ignition innovations are you most looking forward to in the next 6 to 24 months? Oh, that's a good question. Whatever you folks, the listeners here, and our customers ask for, that's probably what I'm most excited about. We have some things that are certainly coming down the pipe. We have additional Docker support that's coming, that's going to be really nice, because it'll be able to be used with illustration engines and it will be able to be, essentially make it so it's easier to run inside Kubernetes or Docker Swarm or AWS' Docker engines, or a number of other ones, and that's nice for deployment. We have some, I mentioned it earlier, but the idea of Ignition running from AWS marketplace. Those things are exciting to me, because Ignition has so many good features and that just allows it to get in the hands of people to be able to spin it up and spin it down and do a lot. Use it in a way that's a lot more extensive, and now, at this point, IT friendly than using some of these modern technologies.

42:14
Kevin: I don't know of anybody else who can run their full servers, platform SCADA, IoT all of that inside a Docker image in a way that fully scales and is backed by storage in a way that's going to be nice for spending these up in a way, and so that really gets me excited too. But where I started off answering this question is, a lot of our development is based on future requests that come from customers, and we have such a strong focus on trying to do things that are going to be good for the community that I get excited about the things that are submitted by folks who are using Ignition every day, folks that are just discovering Ignition for the first time, and they have specific ideas about additional features that would be nice. So much of our development comes from user feedback and is driven by it, because we're such a user feedback-driven company, but I don't know what we're going to have in 24 months from now. We've got a sense of some of the things we'll have 6 months from now, but if you're going 2 years out, we really try to be responsive, and I'm really looking forward to see what you provide back to us.

43:34
Kevin: Any plans for logic objects in Ignition? We need a way to perform simple function block, ladder logic or structured text programs to manipulate tag values instead of difficult scripting. So this sounds like it was written by someone who is on the engineering side. We work with a lot of control systems and integrators who are mostly engineers as opposed to folks who might have a lot of experience in scripting. I certainly don't think our scripting is difficult. I should throw that out there. However, that said, if you didn't grow up with scripting, if you've never written scripting in the past, if your company has a skill set that is heavily on the ladder logic side and not on the scripting side at all, it can certainly be daunting to get started with any kind of scripting. I think our scripting is a bit more accessible than most of the other packages out there. But still, your question is a good one. We have a logic engine inside Ignition. It's called Sequential Function Charts. So SFCs, we have an SFC Module.

44:41
Kevin: Basically what it does is, and actually this is another good chance to pull this up, since I can just give you a visual aid as I'm going along. You can have different items that are transitions. You can have conditional items that are inside here, where basically you're selecting tag values. And I can say, if a certain tag value is over a certain point, maybe ramp zero, and we're gonna check if ramp zero is greater than 50, then it's going to go down this path right here. And then it might have some sort of action that happens after this, so it goes into that action block right there. If it's not over 50, then we could have another condition that's running in parallel that runs to a different action block that's happening right here. All of these blocks can come back together at the end, and this could just run through directly in a single moment, or this could run through... You could actually have it loop through, so you could have it so it never actually ended, it just went back up to the beginning, over and over again. You can have different jump points and have it jump from the top to the bottom for example.

45:50
Kevin: So this is the logic engine behind the scenes that we suggest using for that type of thing. We do a lot of our simulations for a demo project, for example, inside here, PLC simulations are really that you need some sort of feedback from, are really good to do inside here. This is... Each one of these blocks is driven by scripts, and so these scripts right here, basically, generally speaking, if you're doing this, this is going to be super simple scripts. So you might do a system tag, read here and then you pass that in a tag path, and then you send a result or you do it right. That's a result of that. So you do have some scripting that's involved here, excuse me, but generally speaking, you're going to be much... It's gonna be much easier to see what's going on in terms of execution, and then also to copy and paste these blocks in different places if you want them to do certain things. So you could do an XIC right here, basically. Or you could do that type of thing, examining it close, examining it open, and do that type of thing, translate it into simple script inside here, conditionals inside these, and scripts inside here. But as I said, these would be simple scripts as opposed to writing an overall script that would do all of this in one big script block.

47:14
Kevin: So I think SFCs are one of the great features that we have. They're also safe for redundancy. So if one of these stops part way through, if a redundant server fails and it switches over to the other redundancy, it's going to take over right where this stopped, right where it failed, basically, whereas the script is going to just stop running wherever it was. And then if the triggering happens on that redundant server, then it'll be triggered again from the beginning. So this is a nice way to do long running tasks as well. Batch processes are often run through here inside Ignition full type of batching systems in order to run things, maybe in parallel, that need to happen at the same time. You can have multiple blocks that are going down, if a certain condition is true, then you can come through and run these specific parallel operations here, and then have this right now, it sets some sort of an in-block there, or jump to somewhere else. And yeah, these are parallel, they're all going to be happening at the same time, we got multiple actions, multiple transitions directly inside these blocks as well.

48:25
Kevin: Alright, and the next few, in order to keep my answers as quick as possible, I'm going to make single sentence answers, so I'll go even faster here. Where can I get a QR code to scan my Perspective app... Scan from my Perspective app. Except QR code in the browser. Are there any options to get a QR code via the Gateway web page or designer in 8.1? Yeah. Yeah, so two different ways. Excuse me. And probably the easiest thing to do is just create another project and drop a QR code right here. In Ignition 8.1.2, we added these little drop-downs that give you some pre-configured...

49:32
Kevin: And you don't have to actually display that value down below it, right? And so if you just save this off as a project, you can tap there on the Ignition Gateway web pages and say, QR code, tap app, I'm gonna just pop this up and you can scan it, so that's a really easy way to do it. There are a couple of other ways, but I'm keeping my answers short. So next one: “What can be the break point, total number of gateways where the Enterprise Module could be of any benefit and should data export control be considered in using module to control gateways located in many different countries?” So, good question for that overall. The data export is not going to be done by the Enterprise Administration Module. The Enterprise Administration Module, or EAM, that actually doesn't do much in terms of data transfer, it'll transfer and do project backups, but it's not doing real-time data transfer, it's not doing database data transfer over that. If you're doing any of that, you're doing it over the Gateway network most likely. So that enterprise administration module, at what point does it make sense to implement it, it's... Generally, if you've got more than a couple of Ignition Gateways, it's nice to have a central point to manage licenses and manage backups and be able to send out project resources and things like that, create a project, use it once, write it once and use it everywhere.

50:53
Kevin: So pretty early on for the Enterprise Administration Module, if you have over 14 gateways, I think that it ends up... You can get the unlimited version for free, and then... Or not for free, you can get that, you can buy the unlimited version, and then every new version of Ignition that every new gateway that you spend up for that organization doesn't have a cost for the Enterprise Administration Module, so it's free for those going forward, if you purchase that full version or the enterprise version, enterprise license as we like to call it. “How to integrate with Power BI?” So I mentioned that a little bit earlier, I would put data into flat tables, that's probably the easiest way to do it, and as I mentioned, if my answers here aren't throwing up, just follow up later“What's the best way to incorporate Edge historical data with the existing gateway history?” If you have history turned on on Edge, it should go into the same Historian centrally as long as you have it configured appropriately, so I would suggest doing that and then that data should be available, just dragging tags out onto the screen, you would be able to see it.

52:01
Kevin: There are also a couple of options for the historical data so that it queries from the central database instead of querying over the database, over the Gateway network, if you have the data in both places. So that's a worthwhile setting to investigate. “Any software as a service, I can practice with?” So you can use Ignition for free in a two-hour trial mode, reset that as many times as you want, so you can play with Ignition as much as you want, and then... Yeah, if you spin up your own server, you can either just install it on your own local system or if you spin up your own server in the cloud, you can install Ignition on that. We don't have something that's a specific software as a service offering, but we do provide the Ignition platform, 100% free to try with all of the features to make sure that anybody who's purchasing Ignition knows what they're getting. They are fully aware of it. We want you to be able to try before you buy, so nobody's trying to trick you into things.

53:00
Kevin: “At what point is a device considered IIoT? What level of saturation of IIoT devices do you need to say that you have an IIoT SCADA?” Good question. So most SCADAs aren't considered IIoT. SCADA is generally a different category. The Ignition platform can act as an IIoT platform or a SCADA platform or both. And so the exact number of devices that you're connected to before you would consider the Ignition platform to be an IIoT platform versus a SCADA platform, I don't think that there's a number. Generally speaking, most folks define that as the way that things are being connected. If they're connected over MQTT, if you have lots of devices that are publishing data themselves, that can be considered an IIoT architecture. If there are hundreds of thousands of devices that are out there, if you're doing a pull response type of architecture where Ignition is pulling your PLCs, so Modbus or Allen-Bradley, Siemens or a bunch of these other protocols. That's generally not considered an IIoT architecture in terms of the data communication.

54:18
Kevin: So there are a few different ways that people define it, and we've been working with Gartner to get on their IIoT platform Magic Quadrant there. They define it in a certain way. Other folks define it differently as well. But yeah, I don't think that there's a magic number of devices in most people's definitions. Alright, so I got through a slew. I still have two and a half pages of questions here. I wanted to answer a couple of other ones, but I know that we're a little bit over time here, and I really wanna respect everybody's time. I'll just pick a couple of the most recent ones here that I'll answer quickly. “Does Ignition integrate with OSI PI well?” So, Ignition integrates with OSI PI. Does it do it well? Depends on the PI integration, the size of things that are available on the PI side, what the options are from that side. So for some folks that works really well. For other folks, it can be trying. Ignition can connect over OPC HDA. Ignition can connect over JDBC, PI is a JDBC connector, and then PI can act as a collector from Ignition over MQTT or over OPC UA.

55:36
Kevin: And then Ignition can also do OPC DA communication to pull latest values from PI. So with that combination of different possibilities with PI, generally speaking, you're able to accomplish what you need to. Frankly, most customers who are using Ignition, use Ignition's Historian because it's as simple as double-clicking a tag, setting store history and then dragging that tag out onto a screen. Whereas PI, you need to go through a few more steps to be able to pull that history. I've never talked to anyone who wants to integrate with PI who hasn't been able to do it, but I certainly have talked to some folks where it took a bit of effort to get it up and running and going. And I've talked to some folks who started going the PI route and then have decided to use Ignition's Historian instead. And I've talked to some folks who are using PI and they're happy with PI. So yeah, it's kind of across the board there.

56:29
Kevin: Then the last question that I see here is:”With the emergence of Perspective, do you see Vision Module ultimately phasing out in the future?” There was another question that was submitted beforehand that was about: “Do you start or do you design projects with Vision or Perspective, which one's better?” And to answer both of those questions, this will be the last question that I answer here, but to answer both of those questions, my personal preference is going to be whatever is best for the customer. So there are a lot of customers when you're starting a new project that wanna be able to see the project overall inside a web browser, and that seems to be the most prevalent case at this point, at this juncture. We have a lot of customers who are starting new projects with Perspective instead of Vision for that reason.

57:23
Kevin: Folks like to not have a separate install, or a lot of folks do anyway, a separate client install, which is what Vision has. They like to have something inside a web browser and they can see in their mobile devices and all of that. So it's mostly based on customer requirements. In terms of feature set, there's a lot of feature parity between them, and Vision is really good at the things that Vision does, and it's always done those things, and we've refined it over a decade, and so actually even longer if you include our legacy products. So Vision, Vision is a great product, and as of right now, we don't have any plans to retire Vision. Vision is something that is inside the Ignition ecosystem and for backwards compatibility, of course, everybody who's upgrading wants to be able to continue to run Vision. We can't look into a crystal ball and tell you exactly what the future holds, and we are a customer-driven organization, and so if everyone's demanding Perspective and nobody's demanding Vision anymore, then I don't know what that future might look like at that point, but that would be... We don't have any plans along those lines as of right now, to move in a certain direction there.

58:46
Kevin: I can tell you that we're giving more development-focus currently to Perspective than Vision because more folks are requesting things from Perspective than Vision. And we're adding more components and we're doing more symbols, and we've got some additional things there that are in the pipeline, but both of them are good options. I don't have any problem with either visualization tool. I do personally like Perspective, I think that it's really cool to be able to pull things up inside a web browser or mobile device, and the responsive design once you get used to it. It takes a while to get used to it. It's a different mindset to design for the web, basically, versus designing something in Vision, and it took me a couple of weeks to really wrap my head around how to think about it differently. But once you get to that point, for me anyway, it's really fun to be able to design things, design things quickly that are going to be responsive and work across different devices and different sizes and work well with mobile devices. And just the response that some customers have to being able to see that and pull it up right away and not have to install anything and just have it super accessible, that can be really rewarding.

1:00:03
Kevin: Alright, with all of that said, I wanted to thank you for joining today. Thank you for being part of this. This is the first of its kind. If you still have questions, if you have things that you didn't have a chance to ask or if the answers that I gave provided more questions, go ahead and join the conversation over at the forum, reach out to us, schedule something with the sales engineer. I like to think of it this way, that your success is our success, and we are very much in the business of being successful, and we want you to be successful. We also... It's not just self-interest.

1:00:44
Kevin: We also want you to be successful just because we want you to be successful. And certainly, if there are things that are going to be a better way of doing things that don't involve Ignition, we're still gonna be open about that, or if it's better to do something with your existing modules then purchase another module, we're not going to tell you to purchase additional modules. We really pride ourselves in being honest and being open and being helpful. And so, all that to say, give us a call, let us know if you have questions. Don't be shy, you don't need to wait for the next one of these. But if you do, feel free to throw whatever questions that you want our way and we're happy to answer. Final thank you to everyone here. I appreciate your time. And it's been good talking to you. Take care, everyone.