Creating Predictive Maintenance Alert using Ignition + Canary DB

Speakers

Alec Gordon

Lead Controls Engineer

Shamrock Foods

This session provides an in depth walkthrough of how Shamrock Foods Company is able to collect motor data and use it to alert maintenance personnel of a potentially failing asset.  This tutorial will walk you through the steps from PLC amp data to Ignition, Ignition data sent to Canary DB, Canary DB calculations of average + Standard Deviation of data, and back to Ignition to generate alarms.

Transcript:

00:00
Kathy Applebaum: Hello, everyone. I'm Kathy Applebaum, I'm the Software Engineering Department Manager at Inductive Automation. Welcome to today's session, "Creating Predictive Maintenance Alerts Using Ignition + Canary DB." I'll be your moderator for today. To start things off, I'd like to introduce our speaker for today. Alec Gordon is the Lead Controls Engineer at Shamrock Foods Company. Alec Gordon began working at Shamrock Foods Company in 2021 as a Controls Engineer to help commission a new one-million-square-foot distribution facility. To assist in troubleshooting on-site problems, he developed user interfaces for Shamrock Foods Company's maintenance team, including VFD monitoring screen, the force motor screen to assist with PMs, and the scanner diagnostics screen. Alec's first introduction to Ignition was when he worked at a contract manufacturer of pharmaceuticals. Currently, he uses Ignition to monitor a large number of assets and uses automated alerts to notify maintenance of mechanical issues. He has a degree in Chemical Engineering from the University of Arizona. Please help me give a warm welcome to Alec.

01:09
Alec Gordon: Awesome. Thank you.

01:15
Alec Gordon: Alright, thanks for the introduction. As we just talked about, we're gonna be talking about utilizing Ignition and Canary Historian for preventative maintenance. That's me, Alec Gordon, Lead Controls Engineer. Today, we'll just do a brief introduction about Shamrock Foods Company and a little bit of an introduction about what VFDs are since we're gonna be talking a lot about them. Then we will talk about how we define predictive maintenance for our facility, how we arrived at our solution, and then we'll eventually get into the nuts and bolts of our PLC structure, Ignition UDT creation, Canary Historian structure, and finally setting up your alarm configuration. Alright, so the introduction of Shamrock Foods Company. We are the largest independent distributor of food in the West and number fifth in the US. We have eight distribution centers across the West. Two of them are automated. You can see the "A" there in Phoenix and "A" in Denver. We also have two dairy manufacturing facilities and an oil manufacturing facility that aren't on this slide. And we have about 3.4 million square feet of capacity to ship food and constantly growing. The facility I'm gonna talk about specifically is our new facility in Aurora, Colorado.

02:32
Alec Gordon: That's about a million square feet. This was taken probably from a satellite. We have about ten and a half miles of conveyor, and we service restaurants in Colorado, Kansas, Nebraska, Wyoming, all over the West. Just quickly on what a VFD is. A VFD will just control the speed of a motor. It's as simple as that. It can go faster, slower, control the speed of a motor. It can display and report motor amperages, which we will be focusing on a lot in this presentation. And finally, it can communicate that information to a PLC. So, on our site, we have about 383 out of 1,063 conveyor assets spanning that ten and a half miles that I mentioned earlier. And that means that 383 assets in our facility can currently be tracked for predictive maintenance. All of those are critical assets, or all of our critical assets, I would define that as if it breaks, we can't ship a single box of green beans out of our facility. If any of those break, we'd be screwed, so we were able to monitor their mechanical health on all of those assets. What is predictive maintenance? Just gonna do a quick question for the audience, for my manufacturing and distribution folks.

03:44
Alec Gordon: Who dislikes unplanned downtime? Got a couple hands, great. Actually, sorry, for the video streamers, everyone raised their hand. Huge success. At our facility, unplanned downtime is typically caused by a mechanical breakdown in our facility. And we thought, how can we use all of the data we're generating through Ignition to mitigate the amount of mechanical breakdowns we're gonna have? So, in the next slide, we have just a general trend of amps on a specific motor. And over here on the left side of the screen, this is the motor running normal operating conditions, about 2.6 amps. And then all of a sudden we see a large, scary spike, 3.3 amps, and it's sustaining. So that tells us that the asset is under duress and needs to be looked at by our maintenance team. So, that is exactly what we did. After the start of the amp spike, our system will email an alert to our maintenance team. When they arrive on scene, they will make a mechanical assessment, and then corrective actions are taken to bring the asset back to steady state and reduce the stress. What our maintenance team found in this particular asset was the belt was tracking very far to the left-hand side of the conveyor, so it was rubbing against a bracket and rubbing against the side of the conveyor.

05:07
Alec Gordon: This was a photo provided by our maintenance team. It's not the clearest in the world, but you can kind of see the belt rubbing against this metal bracket, causing a lot of stress. And left untreated, this could have torn the lacing on the belt, caused a huge mechanical issue that would have been downtime for an hour, hour and a half, while the maintenance team replaced everything. Instead, they got the email alert and were able to just fix it without stopping production at all. And just briefly, we're gonna get into it a lot more, how we determine an alert for a motor asset. We'll get into this a lot more later, but the red is your amp draw, your blue is your average amps, the yellow line is your standard deviation above your average, and our gray is two standard deviations above the average, and that will be used for our high alarm set point. Just a couple more examples of amp spikes that were trended and the maintenance teams finding after going to assess the alarm. So in this first one, there's just a bunch of junk in there. Looks terrible. They removed all of this trash from the conveyor belt and cleaned everything up, and the asset returned to normal.

06:18
Alec Gordon: This one, unfortunately, was still a downtime event because there was no recovering this belt after that huge tear. This, we're not quite sure how a rag got put in the conveyor belt, but there it is, unfortunately. So, they were just able to remove that, and the asset returned to normal. And finally, another breakdown here. They were able to just trim this section of belt that had torn, and it was able to run for the rest of production, and once we had some downtime, they fixed it permanently.

06:47
Alec Gordon: Alright, so how we arrived at our predictive maintenance solution. In the words of my manager, do whatever you can to prevent a late-night phone call from work. The ways to prevent a late-night phone call from work are train your maintenance team to solve electrical and mechanical problems, provide them with diagnostic tools, and have a well-maintained system. Our building runs 16 to 20 hours a day, 6 days a week. I was the only engineer there for a while, so I would be fielding a lot of fun 2:00 a.m. phone calls, helping them troubleshoot an issue. We wanna prevent that. So, we will be focusing on providing our maintenance team with more in-depth diagnostic information on our systems. The first one we'll talk about that I mentioned earlier are VFD-related issues. Our maintenance team was having a lot of trouble diagnosing VFD faults. It was more of a training issue, but we also wanted to provide them with a lot of VFD diagnostic information wherever they ran. So excuse me, so they can just punch in their asset number, and they can get anything from the frequency of your motor, the amp draw, if the network connection's okay, and any fault codes you might have, as well as the PowerFlex 525 fault list.

08:02
Alec Gordon: They can click a little pop-up, figure out what their faults were, and it also has potential remedies to help them fix their issue without calling your friend Alec. Next, we got a little bit fancier and started trending the amp draw on our motors to paint a picture of a struggling asset to maintenance, so they could type in something they're working on if it was called out, look at the amp draw, see if any of their corrective actions reduced the stress on the asset, and it empowered our maintenance team to fix a lot of their own problems on their own. Oh, I went too quick to the slide. But anyway, after we had all of this amp data here, the next question was, can we utilize this to identify an asset in trouble and fix it before it broke? So, once we had all of our data in our Canary Historian, we started pulling out data for a few assets that had broke that were on VFDs that we were trending, and we noticed a statistical trend where when you trended over 14 days, we started to see the amp draw creep up, indicating that the asset was starting to become more and more stressed before eventually failing, which was very sad.

09:14
Alec Gordon: We also noticed that if you took an average of all your data points, not including zeros, 'cause we don't care when the asset's not running, and calculated their standard deviation as well, you will notice that your high set point value, high set point value, was breached multiple times towards these last three days before the asset eventually did break, and so that got us on the idea of, okay, here's our new high set point that we'll use as a baseline and see if it works for more of our assets as they break down in the field. This is basically just covering what I just said, and we just had a basic bell curve that if you've taken a statistics class, this is your average, and anything two standard deviations on either side of your asset, of your average, is about 95% of your optimal data points that you would expect, and we just said anything in this last 5% above our average is going to be our high alarm set point. And then we're back to the beginning. All righty. Next we will actually get into the nuts and bolts of the PLC structure.

10:20
Alec Gordon: I know this is an Ignition conference and not a PLC conference, but we'll just try to breeze through this, and we can show how we set up a lot of naming conventions in our PLC that then make your UDT generation super easy, but it all starts here. In our facility, we run ControlLogix, PLCs. We have about 16 of them in 16 different control panels, and most of our drives are PowerFlex 525s. Like I said, we have about 382 of them controlling motors in our facility. So, naming convention doesn't sound super exciting, but it is very nice to have when you are setting up your Ignition UDTs. So, in the PLC, we have all of our Ethernet devices that are connected, and you'll notice a very uniform naming structure. After you create your asset, you will see... I'm getting ahead of myself, actually. For our VFDs, we defined a naming convention where DR would denote a drive. Your control panel, in this case, we would use control panel 21, is denoted by CP21, and your unique asset number for every asset in the field has its own numerical combination.

11:37
Alec Gordon: So when you combine all that, you would get DR21101, 21102, 21103, and so on and so forth. Now we have a nice, organized VFD naming convention in our PLC. The next step is we will need to pull whatever useful information you want out of the VFD, and there's a ton of parameters you can pull. We're gonna be focusing on output current, but you can pull all of your fault codes if you wanna see repetitive codes. You can output power, elapsed kilowatt hours to know how much power you're consuming out of your drive. Anything you wanna trend on this chart, you can pull it out of the VFD and trend it. So, we will go to our... Adding amps as a tag. We're gonna go through this quick 'cause this isn't a PLC conference. We have our PowerFlex 525 right here. We'll select it. You go to device definition and you will then enter the next page where you'll click "Connection Format," and then any parameter you want to be in tag form, you can select and add it to your connection format, and this will generate it as a tag. So, once you select this, hit "Okay," and download to your PLC, you will have all of your drives, 21101, 21102, 21103, and their output current as a tag.

13:02
Alec Gordon: And that is just the initial setup to do in your PLC before you can move on to the next step, which will be our Ignition UDT creation. So the steps for a uniform Ignition setup, I think, if anything I talk about here today, this might just be the most important. Naming convention is huge. There was a presentation by Lisa earlier on this stage talking about standardized naming conventions, so if you take anything else away from this presentation, let it be naming. It'll save you a lot in the long run. So when we are defining our uniform Ignition setup, we will talk about the naming convention for your OPC PLC connections, defining your UDT, using the multi-instance wizard to define everything uniformly, and then historizing everything, and you'll see why that's important later. So, for our naming convention, we use something pretty simple. Just CP denotes your control panel that the PLC lives in, and then your numbers indicate the control panel number. Pretty simple. Have a few examples right here. Next, setting up your VFD drive UDT.

14:15
Alec Gordon: I know you guys are probably more of an expert in Ignition than I am, so we'll also try to get through this kind of quickly. The two parameters I mentioned earlier would be your control panel and your unique asset number, so we will define those parameters on the next screen. We have our control panel for all 16 of our control panels, and then asset number for every single asset number. Easy enough. Next, we will pull in all of our desired VFD tags into our UDT. You can do anything you want. I just did a couple examples of output current, output frequency, if the VFD is faulted, you might wanna see that, and this is our sample UDT. The next step, as I'm sure you guys know, is you'll want to edit your OPC path to an indirect tag, and this will ensure that your UDT is dynamic. So, we have our control panel, we insert our control panel parameter, we have our drive, and we insert our asset parameter. That way you can use this for any control panel and any drive you've defined, as long as it's organized in the PLC in the same structure. That's why that first part was pretty important, and I thought I'd cover it.

15:28
Alec Gordon: Alright, and finally, for our amperage tag, you can enable your Canary Historian provider. Now you're logging data into your Canary Historian, and that's when the fun part starts on the next couple slides. Oh, I guess finally we have to do the multi-instance wizard, which I'm sure you're all familiar with. You will set up your base tag name. We say everything in our facility that's a VFD is gonna be denoted by a DR. Here's all those assets we looked at earlier. Here's them in your pattern, and our control panel for this example is gonna be control panel 21. This is your preview of your instance creation wizard, and we are done creating tags using our UDT. They're now all nice and organized in our tag browser, and we are starting to generate data in Canary. The next step will be the Canary Historian structure. This is actually where we're going to calculate our average and our standard deviation for all of the data we're sending to Canary, so this is kind of the fun part. What is Canary? There's a booth upstairs that you guys can probably chat with, and they'll give you a lot more information than I can, but Canary is a SQL-less database that links up really nicely to Ignition.

16:52
Alec Gordon: You're able to perform calculations on data sets that you send to it, and you can transfer that data back into Ignition publishing via MQTT. We're really just gonna focus on the view tile, which has our Ignition data set and also something called virtual data sets, which we'll talk a bit about, I think, in a few slides. We'll also focus on the calculations tile, which is where you'll actually calculate all of your data for your average and standard deviations, and finally publishing all that data back to Ignition. I'm gonna put my email at the end, but here's some helpful YouTube videos for setting up Canary and performing your calculations. I thought these were really useful, just thought I'd post them here, plus I have a huge appendix section of this PowerPoint, so if anybody wants a way more in-depth step-by-step, it'll all be in the appendix. Cool. Next, we will get into the Canary views.

17:49
Alec Gordon: If you drill into this tile, this is our server name for Canary, and this is our Ignition data set. You can see all of our control panels are nice and organized in this data set. Next, if you drill into control panel 20, for example, you will see all of your assets really cleanly defined right here, and if you drill in even further, you will see your output current scaled, and you will see your data points right here. Unfortunately, this is what I mentioned virtual views earlier for Canary. Our regular Ignition data set has everything organized, but it won't recognize it as an asset type, so in order to perform calculations on all of your VFD assets, you have to define what's called a virtual view, where it's basically a carbon copy of your Ignition data set, but with RegEx rules defining what your assets are. That way, when you're performing a calculation, it will recognize all of your asset types right here, and that way, you can perform all of your calculations at once. And you might notice that's found 330 conveyor assets that are our VFDs, but I said earlier there was 382 of them.

19:08
Alec Gordon: That is because I misnamed two of my PLCs in my OPC connection, so I caused my own problem. That's why naming is so important. I'm missing 52 VFDs in here. That's my boss. I'm sorry. He didn't know that yet. Cool. Next we'll move on to the Canary calculation section now that we see that it can dynamically perform a calculation on all 330, not 382 assets. Alrighty. So in the calculation equation section, this is where we're calculating our average. The data that you're gonna be calculating an average for is my test view that you saw me set up earlier.

19:56
Alec Gordon: Percent asset will be all 330 of your assets and output current scale is the tag you wanna evaluate your average for. I'm doing it over a 45-day period because I figured that'd be a good enough snapshot of an asset's average. If it started to fail for three days, let's say you might see some spikes and it could throw off your average, but doing a trend over a 45-day period should be enough to filter that out and give you a pretty accurate amp.

20:22
Alec Gordon: You'll put that back in your test view as your average amps, do the same thing for standard deviation, and we are done with our calculations. So, the next step, all of our calculations are now in the virtual view as you can see, our calculated average, our calculated standard deviation, here's values for your average. It's doing a rolling calculation every 45 days in case there are any changes to your system.

20:54
Alec Gordon: And we can go on and publish everything to Ignition. So I have a lot of slides on this later on, or not later on, but in my appendix and I'll post my email at the end. But if you wanna see how the publisher works or how we set it up to get data back into Ignition, I will send them to you. Over here, this is our Ignition tag browser after data has been published via MQTT, we have our MQTT Engine up top and we have all of our data neatly organized in our control panels with the same naming and everything's coming back into Ignition. So that leads us, oh, actually this part. The why do it this way? With Canary doing a calculation over all of your data from all of your conveyors. One: huge time saver. I pulled that amp data over a 14-day period on Excel and the file was massive 'cause it was so much data and I ran the calculations myself and Excel crashed four or five times before I actually got it to work.

21:58
Alec Gordon: So this is just gonna be a huge time saver to run all of your calculations. You're not gonna have to do it manually. And the other reason we really like this is it's very scalable. I'm not a Canary salesman, but this is very scalable if you want to add future devices. So, if we want to add VFDs to another line, we can do that and Canary will take all that data and perform our calculations automatically for us. Or we are planning to add vibration sensors to our system on a few critical motors, I think we're doing 45 of them. And you can also put that data into Canary. We now have a nice structure to define all of your vibration sensors that we can replicate and add more devices that way if we wanna do extra predictive maintenance.

22:45
Alec Gordon: Alrighty. And that leads us to our final section, setting up your alarm, which I'm sure many of you have done many, many times. But you will first go back into that original UDT we set up, and you'll define a new reference tag, which can be your standard deviation. Sorry if it's not super clear on that screenshot. And all you have to do is find your tag path for your MQTT Engine and then change the exact same things we changed, which were your control panel. Put your parameter in here and your asset number, put in your asset number parameter, and that is how you will define your standard deviation and your average on your UDT.

23:29
Alec Gordon: And it will dynamically push that to all of the assets you've already defined in your tag browser. Super cool. Everything's in there. Amazing. Now what we need to do is define our high amp alarm, which in our case is this equation we talked about briefly earlier, which is our, if our current amps is greater than our average amps plus two times the standard deviation, set this expression tag equal to a one.

23:57
Alec Gordon: If everything's running fine, you can set it to a zero and ignore it. So this is how we defined, I would say, a good majority of our motors, although we did have some instances where this equation didn't work and we had to dive into the data to see why we were getting so many false alarms. And we came up with different statistical analysis for a few key assets. But we can talk about that later if anybody has any questions. Finally, you will configure your alarm for your high amp alarm tag. If the high amp alarm tag is equal to one, you can have an active time delay. I noticed that when motors start right off the bat, they might have some inrush. So you wouldn't want to alarm immediately after you start your motor for every single time it starts. I had a lot of fun with my inbox when I set it up without a time delay.

24:52
Alec Gordon: I'm sure that was a lot of fun to filter out. Here's our notification pipeline where we've set up our emails and you can even tell it, you can even have a custom message. Oh, custom message, laser pointer, asset, and then you put your parameter in the email as well. High amp alarm. If this goes out to your maintenance team, it will tell them exactly which asset alarmed and they can go take a look at it. Highly recommend really going through your data and maybe not sending an email alert right away because you will flood people's inboxes until you really dial in your delay timers and maybe certain assets need a different, equation for your alarm.

25:35
Alec Gordon: Instead of this, you might need something else. It'll all just, you can play around with your alarm journal, enable the alarm, but only send it to yourself just so you don't bog other people down in test mode. And now your predictive maintenance setup is complete. So, what have we done? We've programmed our VFD output current as a tag in our PLC. We've built VFD UDTs in Ignition, we've historized the amperage into Canary. We've calculated our average and our standard deviation. Sent that data back to Ignition via MQTT, completed our Ignition UDT and configured our email alarms. So we've done it all. Are there any questions?

26:22
Audience Member 1: One quick question, which is...

26:23
Alec Gordon: Yes.

26:24
Audience Member 1: I can't help but notice that a lot of this, especially when it comes to setting up the UDTs and setting up the alarming tags, requires some, it seems like a fair amount of work for each motor that you add into this. Obviously there's the multi-instance wizard for tag imports but to what extent is this particularly the setup of the additional alarming tags, doable programmatically or doable by some kind of like template and then a modification?

26:52
Alec Gordon: Sorry, can you repeat the question?

26:53
Audience Member 1: Sure.

26:53
Alec Gordon: Sorry.

26:54
Audience Member 1: Like I guess as an example, like taking the final alarm configuration where you have a tag for each motor set up, tag for each motor which is based on whether the system falls outside the standard deviation. I can imagine worlds where that's more complicated. Is there any way to perform that programmatically using the same like multi-instance wizard type system that you could do for tag imports from the more general motor system?

27:21
Alec Gordon: Are you asking if we can set up the UDT to define our alarm for us?

27:26
Audience Member 1: Yes. Or at least for base cases of the alarm.

27:31
Alec Gordon: I am not sure would be my answer. We found that statistically the equation we have a couple slides up worked for the vast majority of our alarms and the ones that it didn't work for, if they false alarmed or if they never alarmed and we had a breakdown like while we were testing this feature, we would need to go back and tweak our alarms for those specific assets. And I will say in our facility, there's not too many differences between our motors. We have pick mod zones where there's about 90 VFDs there, they're all the same motor type, the same, I guess the same use is being performed by all of those motors. Someone's just throwing a box on that conveyor belt.

28:14
Alec Gordon: So they all behave pretty similarly and their alarms will be similar. Same thing for, we have a consolidation zone that moves big slugs of boxes down our line. Those all behave similarly so we can build a specific alarm tailored to consolidation. And then finally our merge motors where product releases onto a final belt, those all behave similarly. We didn't have to change this too much to fit the different applications.

28:44
Audience Member 1: Thanks.

28:44
Alec Gordon: Did that answer it?

28:51
Audience Member 2: Okay. Your presentation launched quickly into kind of the solution. I was curious, you know, how were you gathering data and analyzing it before the VFDs and you know, what kind of history did you have trying to solve these problems or headaches prior to the solution you implemented?

29:10
Alec Gordon: Like I said, our building was built in 2022, so we already had all of our VFDs in place that we could then, once we started trending amperage off those VFDs, oh, he's got another question. We could just put, we started noticing that we could use that amperage data to give us predictive maintenance indicators.

29:30
Audience Member 2: Okay. Well then if it, I'm trying to, I guess we had to be hindsight is if the facility had existed 10 years ago.

29:38
Alec Gordon: Oh sure.

29:39
Audience Member 2: What would you likely have had in place and what would the potential headaches have been that you've now solved?

29:45
Alec Gordon: Right. Well we...

29:46
Audience Member 2: Never had that you solved.

29:47
Alec Gordon: Yeah. Well we do have a Phoenix facility that is ancient, and so they don't have a bunch of PowerFlex 525s communicating via Ethernet. And I'd say we have a pretty good proof of concept here at our site that it works. So, we can upgrade equipment at our Phoenix facility. You could install amp clamps on their motors that are just on a contactor starting on and off. We're also gonna test out the vibration sensors at our site. There's plenty of different use cases to define your predictive maintenance, even at an older facility, you just have to invest in those upgrades. So, I think us demoing this for our other sister site is a good use case. And they can decide whatever upgrades they would like to do to be able to pull similar data in and then make informed decisions based on that data. Does that, get it? Cool. Anybody? Yeah.

30:39
Audience Member 3: Quick question.

30:40
Alec Gordon: Oh, you've got the mic.

30:42
Audience Member 3: Let's talk about statistics on top of statistics.

30:44
Alec Gordon: Oh man.

30:44
Audience Member 3: So this equation.

30:45
Alec Gordon: Sure.

30:46
Audience Member 3: How successful, after you say you reached steady state and you're happy with what you're able to do, I know there were differences in your sample, how confident were you that this was correct? And then at any point did you guys consider applying machine learning or any other applications to maybe make it more predictive?

31:05
Alec Gordon: As far as the machine learning goes, I am kind of just playing with the cards I'm dealt. So, I'm utilizing Canary because I was given Canary and this is about as far as I could go with it. I couldn't really figure out a way to do any machine learning. And as for the equations, like I said, our facility is pretty standardized as it is 'cause it's a new build. So, setting this up, worked in probably 80% of the use cases and the ones that it didn't, we tweaked to make work for some... Maybe, I guess a good example is our consolidation zone.

31:36
Alec Gordon: The motor will run for 20 seconds and stop and it's really hard to generate an alarm without flooding your email for those 20-second bursts. So, a separate solution we did was right before production started every day 'cause we have a bit of downtime, we do a run out of those motors for about 10 minutes and we count or we collect just that data from that 10-minute run and use that to determine our average and our historical standard deviation and figure out what the steady state for that asset is.

32:07
Audience Member 3: And you've seen success. Like you've been able to predict this motor was going to fail.

32:11
Alec Gordon: Oh man. Let's go back up to those pictures.

32:14
Audience Member 3: Okay. Oh, those are real examples. Okay. I see.

32:17
Alec Gordon: Oh yeah, yeah. No, this is all, every time I originally was testing it where I would send myself the email and I would just look at the data because I didn't wanna just bother our maintenance team if I wasn't 100% sure something was wrong. And I'd have them look at a couple of the alarm examples over time and then send me pictures of anything they found. And the examples where nothing was wrong, I would tweak how we set up the alarm and until we got to the steady state where just about all of it works, I'm still having a little bit of trouble with that consolidation section I mentioned earlier. But, that's how we would go about testing these alarms and making sure they weren't gonna just send our maintenance team for a loop and drive them nuts.

32:56
Audience Member 3: Thank you very much.

32:57
Alec Gordon: Yeah, yeah, no problem.

32:58
Audience Member 4: So, I have a question here.

33:01
Alec Gordon: Yes.

33:02
Audience Member 4: Congratulations for this first.

33:04
Alec Gordon: Oh. Thanks.

33:07
Audience Member 4: Can you explain again why you use Canary and not the normal historian of Ignition?

33:17
Alec Gordon: Like I said earlier, I was playing with the hand that was dealt, which is using Canary and sending all of our data. But number two, I haven't really figured out how the internal Ignition Historian would work for this application. So I just found it was a lot easier to do on Canary. I didn't try that hard using the Ignition Historian, if that answers your question. I'm sure it can be done. I just, they gave me Canary. I use Canary.

33:44
Audience Member 4: Alright. Thank you.

33:47
Audience Member 5: So in your equation did you consider any such parameters, like your conveyors are gonna run at the same speed all the time? Or does this equation hold true for whatever speed of a conveyor that you'll run? Because you have them running 45 days average. I'm just wondering if that, running 45 days average applies for whatever speed you're running your conveyors with.

34:09
Alec Gordon: Yeah. This does not factor in any conveyor speeds. We're just taking the collective amp draw and you could set it up how you're describing if you wanted to generate your alarm based on full speed, you could, I imagine set up a tag in your initial UDT that says, "If I'm running at 60 hertz, trend the data, if not set my value to zero and ignore it." So, you could get creative with your solution and say, "I wanna know my full speed average" and make a tag, instead of an OPC tag you would probably just do an expression tag. Does that answer your question? Someone in the back?

34:53
Audience Member 5: Yeah.

34:54
Alec Gordon: Oh, there you are.

34:55
Audience Member 6: This is not a question just, I would want to share some information. We have used Ignition Historian and we are getting all the tag information and we used banner vibration sensors for different motors on different equipments. So what we did is, to answer your question, we grouped the similar type of motors and then we did the baseline and then that vibration, we put it as a standard. Although, with admin rights, they can change those limits should there be any change in that. So that basis we give a warning alarm and we are giving it to the, not just the maintenance team, but also to the technicians. Using technician and different equipments have, depending on where you place the vibration sensor has a different...

35:44
Alec Gordon: Feedback?

35:44
Audience Member 6: Temperature and evaluation. So we just need to make sure of that. So it works pretty good.

35:50
Alec Gordon: Awesome. That's great to hear. And we've done, I think I mentioned earlier, something similar grouping assets into I guess what their use case is. So those consolidation motors, we have a different set of alarming, pick mod zones are all run the same. So we have, oh, we're not even on the slide anymore. We'll go back down. This equation I showed earlier is more used for our pick mod zones. I didn't really have time, I figured in this presentation, to really dive into all of our different use cases in our groups. So I just kind of presented on one, but there are plenty of other setups that we have for our alarm. This is my email address and I'll leave it here for the rest of the presentation while you guys are filing out. And thank you so much for listening everybody.