Craig: Hey, everyone. This is Craig Baldwin of Losant. I'm the VP of sales and partnerships. I want to welcome everyone for joining us today at our Take a Deeper Dive Webinar Series here at Losant where we’re going to be discussing how to connect your PLC to the Losant IOT platform. Speaking today of course is myself [Laughs] but we also have a few other really important guests. Maria Language is a solutions architect with Losant. She’s going to be covering the majority of today’s session and we’ll also have Kevin Niemiller at the end for Q&A. Both of these solution architects are incredibly experienced with working with PLCs both in the actual day to day environment before they started up Losant but now also at Losant and they have a ton of really great work on connecting PLCs and many other different type of industrial machinery and protocols that come with those PLCs to the Losant platform. Before we get started, I want to talk about a couple housekeeping items. So first and foremost, we are recording today’s session. You will receive a replay of this presentation in one to two days. It will also be available on YouTube and on our website. So, for whatever reason you need to jump off early or unfortunately you can't meet us on here today live, this will be available for you to access at a later date. In terms of questions, we welcome them. We hope you ask as many as possible. Like I said, Kevin’s going to be joining us for that Q&A session later on. We have a couple options available to you in order to ask questions via Zoom. You can use the chat tool. I’ll capture them there. You can also use the Q&A tool. So, at any point please go ahead and ask. We’re going to cue all of those questions and then I will tackle those at the end of the session. For what it’s worth, these sessions typically last anywhere from 45 minutes to an hour. So, stick with us if you can. We’d love to have you throughout the entire thing. So, for those of you who are not familiar with the Losant platform, we just want to cover real quickly at a high level the components that we provide each and every day for our customers and partners to use when building IOT applications and some of these will be covered more depth today. First one is end user experiences. It’s sort of the frontend piece of the Losant tooling, visual workflow engine where you can build all of your data logic or application logic, data visualization which is very much a dashboarding layer, very easy to use and doesn't require code. Devices and data sources is really about setting up the architecture of your overall solution, how you want to structure the data as it’s coming in, thus making it much easier to work with on an ongoing basis. And then Edge Compute which can be very important to these types of solutions when connecting PLCS. This is essentially an open runtime or a piece of software that will run on a gateway and allows the workflow capability to run locally. This is really great for talking to local networks or industrial environments that have protocols which may not be able to interface directly with the Internet. Again, if you're not familiar with us, we are prevalent in the enterprise. So, what you see here are a couple of our customers and partners, Verizon, Hewlett Parkard Enterprise, Procter & Gamble, Weg. If any of you folks are in those companies on the day we appreciate your anticipation. We also appreciate you being a customer. These tools are really meant to provide value or organizations who will be seeing great scale and across many different teams and departments. And so, we hope you see that as you learn more and more about the platform but especially as you learn about how to connect PLCs today in the content. A little bit about the Losant partner ecosystem. So, we do have an ecosystem of partners that can help to fill a solution or a need that you may have if you're struggling to get things off the ground. As you all know for a while software or cloud is just one small piece of the IOT stack. You also need devices or sensors or gateways and connectivity. And so, we do not provide those later two components but we have many partners who do. We also have what we call solution partners. These are essentially professional service organizations who can help you with an implementation if you don't have those resources yourself. And then we also have strategic partners who are essentially providing unique distribution points for the Losant platform, whether that's in a specific industry or geography, all Losant partners that we have overseas. Another thing to cover, if you're not aware of it or if you're coming into Losant for the first time and may feel a little overwhelmed, we do have application templates. So, for example industrial equipment monitor would be a great template to use in today’s webinar but we try to really make it as easy as possible for you as you're starting on your building journey. The whole goal of Losant is to reduce the barrier to entry to building IOT applications and enterprise. And so, these templates are a great foundation to get started or whatever application you're trying to build or I’ve also found them very useful for seeing a great example of how to build and sort of reverse engineering how a particular application was built and applying that to your own build which may be unique in nature. So, with that, I'm actually going to kick it off to the host who’s going to talk about really meaningful stuff today, railings on here. Maria, do you mind introducing yourself and taking over from here?
Maria: Yeah. Thanks, Craig. So, let me go ahead and share my screen really quick. Right. Are you able to see that?
Craig: Looks good.
Maria: All right. Great. So, like Craig said earlier on, I come to Losant from manufacturing. So, I've got around eight years’ experience feet on the floor in the shop and working on and around manufacturing and industrial equipment. I am now a solutions architect here at Losant and I work to help others build their connected IOT solutions. So, let’s go ahead and dive in to today’s content. So, what you see in front of you is an architecture, diagram of an architecture for an industrial solution. So, we have up in our left hand corner the PLCs. And they are connected using… they're using the protocol OPC UA or EtherNet or Allen-Bradley EtherNet/IP. And then they're connected to a gateway. So, this gateway is really important. It could be something like a Raspberry Pi or an Advantech UNO and one gateway can actually work for all of the PLCs in your facility. So, on the gateway itself is Docker and the Losant Edge Agent is installed in that Docker container. And like Craig mentioned earlier, you can deploy workflows into that Edge Agent which runs locally on your shop floor. So, this is a really important part of the PLC connection for security reasons. So, once you have the gateway set up and you have your Losant Edge Agent installed and you're connecting to your PLC, the data can then go securely through an MQTT connection to the Losant platform in the cloud. And then once you have that data in the cloud, you can start building your dashboards and exposing all this data to your frontend user experience. So, let’s go and jump over to just a quick example of what that could look like or feel like so, why are you even grabbing this data. So, this could be a unit opp on your shop floor. So, this is a bottle loading station. And what you see in front of you is we do have state over the last 12 hours. We also have fault occurrences over the last seven days and then the number of times each fault has occurred. So, this is information that we are pulling from the PLC of a bottle loading station into Losant and then utilizing it. When I scroll down a little bit I'm even able to take that data, run it in a Jupiter Notebook, which then drops into this Pareto Chart. So, this Pareto Chart, I was able to do analytics on the data to build the Pareto Chart to drop in here so that you can see it. And you can say, okay, here's my lowest hanging fruit. This is what I should have my team tackle to eliminate downtime, to increase uptime, to increase OEE. So, that's just kind of the overview architecture. That's really the power of bringing that data into the cloud so that you can utilize it with whatever makes sense for your solution. So, let’s talk a little bit more about the security part of connecting your PLC to the cloud because we don't want to expose your PLC to the local Internet. So, that's why we have that gateway. That's why the gateway is in the middle and it’s running the Losant Edge Agent to provide that level of security. And then like I mentioned before, you have your MQTT client built directly into the Losant Edge Agent, which can then send the data securely up to the platform. So, in the demo today there are several PLCs that are being used. One is a Siemens Smimatic S7-1200 and it has an OPC UA server built directly into it. And then the other is a CompactLogis 5380 which is an Allen-Bradley PLC and it uses the EtherNet/IP protocol. So, I have these two PLCs. So, what I did in Losant, the first step I did was I created some devices in my application. So, you can see there's three devices here and that's really I'm because again, we have our Edge Compute device, we have our gateway. And this gateway is then tied to the Allen-Bradley and the OPC US peripheral device. So, the Allen-Bradley and the OPC UA devices are actually representing our PLCs in the Losant cloud. So, these are digital twins of those PLCs. If I click into one, you can see that yes, it is a peripheral device but it is tied to a specific gateway and that gateway is the Edge Compute Gateway. So, a peripheral device needs a gateway to send the data to the cloud. It is not able to connect to the cloud on its own. So, it’s passing that data through the gateway up to the cloud. I went ahead and I put several different device tags on my two devices here that we’re talking about, the OPC UA and the Allen-Bradley one. I have protocol which this is OPC UA. I have serial number. So, this is the serial number of that PLC and then I have the IP address for the PLC. So, I just want to call these out because when we get into our workflow engine we’re going to utilize several of these tags to make a more robust system for long term solutions. Now, the attributes that we’re going to be talking about throughout this demo are RPM, machine state, fault code, fault description and temperature. And all five of these will be pulled in from both the Siemens PLC and the Compact PLC. So, we’re going to start out talking about OPC UA and what is OPC UA. So, it is a machine to machine communication protocol for industrial automation and it’s actually one of the most commonly used protocols in industry today. And part of the reason behind that is it comes with a secure authentication and authorization which I will point out inside the Losant platform how you can utilize that security level. Now, in order to read or write to tags in the OPC UA server you're going to need several pieces of information. You're going to need the name space which the node is located or the tag is located, the identifier which is the unique identifier of the node within the namespace and then the identifier type. So, there are several types of nodes that are used in OPC UA. There's string which is identified with lowercase S, there's Global Unique Identifier or GUID identified with lowercase G and then byte string which is lower case B and numeric which is identified with an I representing integer. So, a really quick pro tip, to get that information, that namespace and identifier and identifier type really quickly if you don't already have it on hand is this Unified Automation UaExpert tool which you can download online and you can connect to your IP. And then you can see here I have highlighted already RPMs which is one of the tags that we’re interested in and then over on the right all that information that I need, that namespace, the index, the identifier, that's all right here. I don't have to look very hard. It is present and I can take that information and run with it. Now, if you don't have access to this tool or if you want to browse within Losant, that is totally an option. It’s a tool that we have built into our Edge workflow. So, if I come into my OPC UA programing screen, what I need to do first before I'm able to find those tags inside of Losant or even read/write to them is I need to bring them into the sever interface. So, you can see over here on the right I have my tags that I’m interested in. And what I need to do is I'm going to drag them or what I did is I drug them over here into the OPC UA sever interface and that can be found if you just select inside of your sever tree. Right here we have sever interfaces. So, now I have my tags inside my sever interface. If I use my pro tip and I was able to find all the information I needed I can jump right into my workflow. If I didn’t have that tool available and I wanted to browse within Losant, let’s talk about how you would go about doing that. So, what you see in front of you is actually an Edge workflow that I've already built and deployed to the device. So, there's a series of OPC UA browse nodes that are used. So, these are a bunch of different workflows that are triggered off of a virtual button and each workflow just has an OPC UA browse node in it and we’re browsing for different things. So, the first one here that I've selected, I'm browsing the entire sever. So, this is going to expose all the information on the sever and the way I went about doing that is the first thing I did was put in my IP and I hard codded the IP because I am just browsing. This isn’t something I'm using inside of a workflow engine that I'm going to make decisions off of or anything like that. This is a tool I'm using to find that namespace, that identifier so that I can build a workflow that is going to read/write to OPC UA. Here I have the security option that I mentioned before. So, OPC UA has its own security built into. So, we had to take that into consideration when building all of our OPC UA nodes. So, if you're utilizing a security setting in your OPC UA PLC protocol, this is where you would input that information. I am not. So, I have to selected as none. And then let me jump back to my deployed version. I am not browsing anything in this node. You can see my browse instructions are empty and that's because like I said, I want to browse the entire server. I need to see what I'm working with before I can move forward. So, I'm going to go ahead and trigger this workflow. You can see it came up over here in my debug panel on the right. And if I scroll down into my working .browse folder where I deposited the results from that OPC UA browse, I can see the several different featured sections of the sever. I've got objects, types and views. What I'm interested in are objects. So, these tags are objects within the server. So, now the next step is to browse again. So, now I have browse instructions because I just found out what the identifier type and identifier number are or I'm sorry, the namespace and the identifier are, I can then click into this objects OPC UA browse node. Again, I have my IP, node security but what we’re interested in this node is the browse instructions. So, namespace index is right here. And identifier type is numeric. So, all of that information then comes into my browse instructions. Now, another pro tip utilizing the OPC UA browse node, rather than trying to figure out what letter you're supposed to use for your identifier type, you can actually just look here at this node ID that pops up and it’s going to tell you exactly what you need to input into your browse instructions. So, I have my namespace zero and then for my identifier i=85 which matches exactly what this node ID is telling me. So, if I go ahead and I run this workflow with the browse instructions we just put in I can see several different elements pop up for the browse that we just performed. So, for our objects we have server, device set, server interfaces and then the PLC_1. So, when we set this up though we put all of our tags inside of our server interfaces. So, this is the area now that we’re concerned about. So, we need to do another browse using server interface information. So, that's what I'm doing here in this OPC UA browse node and again, rather than guessing what is the correct identifier type to use, I just went ahead and I grab the information here from the node ID and I dropped it right into my browse instructions. So, now we’re browsing inside of our server interfaces. So, I'm going to trigger this. And here's my OPC UA server. So, this is where I was trying to go. So, I'm going to do one more browse and I'm going to browse inside that OPC UA server so that I can find the tags that I'm looking for. So again, I have my node ID with my namespace and my identifier. I drop that into my browse and I fired off this workflow. Now, this is interesting because I have an array of lots and lots of tags. Now, the last five that I added are the ones that I'm interested in and those are at the very bottom of this list. So, I'm just going to kind of scroll through my debug panel quickly. Now you can see I have my machine state, my fault code, fault description, temperature and RPM. And those are the five attributes that I'm concerned with and that I am going to be tracking inside of my platform. So, now that I have that information I can build a workflow that's able to read/write to the server itself and get that information from the tags or send information back to the tags themselves. So, as I get going what I did first was I used a peripheral get node. Now, this peripheral get node can only be found in your Edge workflow node library and it is going to be able to… it’s going to search for peripherals that are tied to the Edge device that we are using. So, in this case we have Edge Compute is our device and then we have two peripherals that are tied to it. So, it’s only going to query between those two peripherals. And I'm going to query by the serial number. So, by using the serial number, something that's not going to change, if I update the IP for the PLC or something along those lines I'm still going to be able to find this peripheral information and then if I update that IP I can update the tag associated to this device. So, I could update this tag here and I can still find the PLC. So, this is what I was talking about before. By putting the IP here I'm making a more robust system because now when I go into my OPC UA read node, rather than hard coding that IP, I'm pulling it from the tag on the device that I just got with my peripheral get node. So, my peripheral get is going to drop this device right onto my payload path. I'm going to use the tag to put in my IP. I have node security. So, this is my OPC UA read node. I'm sorry. Forgot to mention that. So, now I'm going to be reading the tags that I just found through my browse or through the much faster external tool. So, now here are my read instructions. I'm just going to talk about one. This is the same for all. So, I've got my namespace index, my identifier and my result key. So, I'm looking at machine state which is right here. Again, I can just use the information from this little node ID and you can see I've got my namespace indexes four, my identifier is i=50 and then the result key. So, the OPC UA read node is going to create an array on your payload and it’s going to drop this value into that. So, I'm going to call it machine state so it matches. So, I have continuity between my PLC and my digital twin inside the platform. So, I'm going to keep the name the same. So, machine_state to match exactly what I have on my PLC tag. Once this node is executed, once I do my read of my OPC UA I can then take that information and I can tie it to the digital twin inside the platform using the device state node here. So, I was able to get the correct device ID from the payload path from my peripheral get earlier and then I tied all of my attributes, my five attributes that I'm interested in to the values on my OPC UA read payload path, the correct value associated with it. So, let’s go ahead and fire off this workflow and just make sure everything works correctly. So, I'm going to execute it using my virtual button and it make it all the way through my debug. So, now I'm looking at my debug path over here in the panel and I can see my OPC UA read is here. All the values that I searched for in my read instructions on the OPC UA read node have been deposited under the payload path and then I'm grabbing those values and I'm able to write them to the attributes here in the device state node. Now, it’s not very effective to have a workflow like this that you have to actually push the button to execute. So, in real life we would do one of two things. We would set up a timer, which I have here, let me go back to develop, which I can connect to my payload or to my workflow path. And this timer node executes once every minute. So, it’s going to get the peripheral read, the five tags called out on my OPC UA read instructions and then it’s going to report those values back to Losant using the device state node. And that's going to happen every minute. Now, another option when dealing with OPC UA is if I come into my node library, I have an OPC UA trigger node. So, this could trigger this workflow for me anytime an OPC UA event occurs or something, a value changes inside of my OPC UA PLC connection. So, that's one way to trigger it. And then the other nodes that we could have used in this workflow are the OPC UA call node and what it is going to do is actually call a method on an object within your OPC UA server and it can be utilized, the information be utilized inside of your workflow. And then the last one that I didn’t use in my workflow engine but that is available is the OPC UA write node. And it’s going to be the exact same instructions as our OPC UA read. So, we’re going to need our IP template, security if there is some and then again we’re going to need the namespace and next the identifier but then here is where you would put the value you're writing to your PLC. But I'm going to go ahead and just deploy this timer. So, this would be something you could do for your use case. So, I'm going to save it, deploy it to my Edge Compute device and now if I wanted to, I can see that that version is running here. And if we were to stay on this screen, the timer did just run. So, you can see on my payload path the timer executed and it ran my workflow. So, that's how you would connect your PLC using OPC UA protocol to the Losant cloud and then utilizing the Losant Edge Agent in the workflow engine. So, now we’re going to actually talk about Allen-Bradley EtherNet/IP and this is an interesting… I just want to clarify this for everyone. So, when we talk about Allen-Bradley EtherNet/IP, the underlying protocol is actually just EtherNet/IP but what Allen-Bradley has done is taken EtherNet/IP protocol and built it into their PLCs which allows for simplified programing of the Allen-Bradley PLC. So, throughout this I’ll probably refer to it as Allen-Bradley EtherNet/IP just all one phrase but just note that the actual protocol is EtherNet/IP. And this is an industrial network protocol. It is the other leading industrial protocol with OPC UA and it enables real time control and allows for information to go between drives, motor starters, PLCs and other components in your facility. So, this is my Allen-Bradley EtherNet/IP. This is where I set it up. So, this is a screenshot of my computer and over here I have highlighted the parameters and local tags. So, this is where I'm working from today. So, I'm using the main program. These are the names of my tags and these are the data types. And that's really all you need going into setting up your Allen-Bradley connection in Losant. So, here is the workflow I already built for the Allen-Bradley PLC. We have a virtual button and a timer. So, the timer is already connected and it’s running every minute. And then I have my peripheral get. Works the exact same way as the OPC UA peripheral get node that we covered before, only I'm looking at the serial number for Allen-Bradley device instead of the OPC UA one. Now I'm able to do my Allen-Bradley read. So, I grad the IP address, the same way I did for my OPC UA read. I've got it from my Allen-Bradley peripheral tag and it’s tag IP. So, that value drops in here. The slot for the example that I'm using for my controller that I'm using today is just zero. And then you jump into your read instruction. So, what Allen-Bradley has done is just made it very simple to get this information from EtherNet/IP. So, what I need is the controller or program tag template. So, that's what it’s called here. So, that's my name. And then my program template, which in this case I'm working out of the main program, I need the data type and there's two options here. If I click this dropdown you would see atomic which is showing or string. Those are the only two options available and then the result key. And again, I'm going to use the same name that I'm using in my PLC tag so they match. I’m just build some continuity between the two systems. Okay. So, once I have that information I can then… it read the information from the Allen-Bradley PLC. I can grab that and drop it through a device state node onto the digital twin. I can save that to the attributes that I have already set up here for my Allen-Bradley device itself. Now, a little pro tip with Allen-Bradley read/write is in this instance I have a program. So, I needed to put that into my read instructions but if you're actually just working off of your controller tags, not a program tags, so here’s you… if you're working off your controller tags here rather than the program tags, when you are instead of Losant you would just leave this program template blank and then it will just read. It will go straight to the controller tags versus a program tag folder. So, if I go ahead and fire off this, Edge Compute, well, I will save this, deploy it and then I can hit the virtual button here for my Edge Compute device and you can see that information coming up here in my debug panel. So, actually the timer just fired. I have my peripheral device. It dropped right in here and then my PLC reads from the Allen-Bradley EtherNet/IP connection that I built into this. And I mentioned before. So, with OPC UA we had lots of different nodes. With Allen-Bradley we actually only have two. So, we have the read and the write. And write is set up the exact same way as read. Just like before though you would put in here the value you would like to write to that tag. And that's pretty much it for your Allen-Bradley. It’s much simpler and that's because like I said before, Allen-Bradley did a lot of the work for us to simplify the use of the EtherNet/IP protocol. So, at this point I'm going to toss it back over to Craig so we can start our questions.
Craig: Thanks, Maria. Hey, everybody. So, before we dive into questions I want to cover something, at least a couple things pretty quickly. One is please mark down on your calendars for a June 15th Executive Briefing Webinar with the BH IoT. This is an organization who is a bit of a thought leader in the IoT space especially on the Telko and BNO side. Myself, Charlie Key our CEO and Adam Daniel our VP of solutions will be joining BH IoT for a sort of best and brief conversation around taking ideas, putting them into place from a technology perspective and then how to achieve business success from those particular IoT strategies. Some other resources for you in case you don't already know or if you have questions after this, we have some really wonderful content at our website. So, docs.losant.com is a extremely robust set of developer documentation covering the entire platform. Losant University is video based content that you can leverage to really learn the ins and outs and the concepts which the Losant platform bring about. It’s a great place to start if you've never used the Losant tools before. You can also check out our Deeper Dive series at losant.com/deeper-dive. Here you can see a history of YouTube videos which are for prior Deeper Dives covering a very wide range of topics. You also have hands on tutorials and our forums community. So, the forums community is a wonderful spot to ask sort of those how do I questions. You may find that some of the own or some of your own questions you may have as you're developing have already been answered within those forums. So, we definitely encourage you to use all of these resources. And of course if for whatever reason you don't see an answer in any of these resources you can always reach out to one of us directly. My email is craig@losant.com. So, please use me as a resource for whatever you may need. So, with that, I'm actually going to take us to the questions. So, don't leave us just yet. We’re got a little bit of time left. One of the first questions that we had come in was is it correct that the Losant platform cannot initiate communications with the Edge device? Do all coms or should all coms be initiated by the Edge device itself? Kevin, I think you joined us. Can you answer that or at least clarify sort of how you can initiate communications whether that's from the Edge device, from the end sensor or even from the platform itself?
Kevin: Yeah, absolutely, Craig. So, Edge devices can communicate directly to the Losant cloud platform if it can speak MQTT or HTTP for instance and have access to the Internet. So, a lot of PLCs these days are coming out with a MQTT client built directly into it. In that case we can give it credentials so that it can connect directly to the Losant cloud platform and send its data to the platform without connecting to the Edge Agent first. With the Losant Edge Agent the Allen-Bradley read nodes and write notes at Maria was showing, we basically kick off that connection and tell the PLC that we want to read this tag and we want to write to this tag and then that data is sent back into the Losant Edge Agent so we can get that data up into the cloud. The other node that Maria briefly talked about was the OPC UA trigger node. In that case, what we can do is say hey, we want to motor a specific tag in the OPC UA server and we want to sample it at a certain frequency. And what it will do is it will go out and read that tag and any time that value changes it will kick off that specific workflow and run that workflow within the Losant Edge Agent. So then, we can then transform that data whenever we need to do and then ultimately send it up to the Losant platform.
Craig: And Kevin, just to clarify, so I can communicate by directionally? I can send commands down or obviously sent data back up. Is that correct?
Kevin: Yes, that is correct.
Craig: Okay. Wonderful. So, Kevin, one particular protocol that did not come up on today’s conversation but I actually see pretty often is Modbus. I'm assuming the process to utilize Modbus would be pretty similar to what we saw with OPC UA and Allen-Bradley’s. Is that correct or maybe go into little bit more depth about how Modbus may differ.
Kevin: Yeah, that's correct. So, within the Losant Edge Agent we already have first class integration for Modbus, which means we have a node built for Modbus just like you saw with EtherNet/IP to connect to the Allen-Bradley PLCs and the OPC UA nodes. So, with the Modbus nodes we have a read and a write node. They work very similar to what we saw today with the other read and write nodes and the Modbus nodes will basically allow us to connect over a RS45 serial connection or over the EtherNet connection as well in order to read data from those Modbus devices as well as write data back to those devices.
Craig: Perfect. Thank you. So, another thing that probably happens pretty commonly if I had to guess is that a read may fail for whatever reason. Maria, do you know… can I find an error in the resulting payload or workflow if a read fails and what might that look like, excuse me?
Maria: Yeah, sure. So, the read nodes should put the error onto the payload at the result paths. So, they don't error the entire workflow. They’ll just drop an error onto your payload path. So, you'll get an errors array on your payload path. So, it’s not going to stop the rest of your Edge workflow from executing which is really important. It’s just going to let you know, “Hey, I failed here but I continued forward. Something’s not right.”
Craig: Awesome. No, that's really helpful. Thanks, Maria. Another question that I actually get pretty often that I saw in the Q&A is is there a limit to the number of PLCs a workflow can read on each time or interval? Kevin, you want to address that one?
Kevin: Yeah, absolutely. So, each workflow run is limited by default to 60 seconds. So, it just depends on how many you're reading and if you can get them all done within 60 seconds. And the better gateway you have, the more horsepower you have. All of that kind of stuff can help as long as the PLCs can read that fast as well. The one note that I will say is that within the Losant Edge Agent, I mentioned that that 60 seconds is by default. There is actually an environment variable that you can change that will allow you to change that 60 seconds to a high number if you do need to do that.
Craig: Perfect. That's really useful. Thank you, Kevin. All right. Well, that's all the questions I had for today. This has been a wonderful session. Everybody who’s joined us today, we really appreciate your time. No more excuses. Go out, connect the PLCs. You should be able to do it at least if it’s using the Allen-Bradley or OPC UA, maybe even Modbus. If you have any questions, by all means please use the resources that you see in front of you on the screen. As I said earlier, this particular session will be made available to everyone here today and also publically on that Deeper Dive website at some point probably before the end of the week if I had to guess. So, thank you again everyone. We hope you have a wonderful day. Please join us for that June 15th session. Otherwise, have a good one. Thank you. Bye-bye.