.png)
Automation Ladies
The podcast where girls talk industrial automation!
We interview people from all walks of life in the Industrial Automation industry. Through a personal narrative/conversational framework we talk about PLCs, SCADA, IIoT, Machine Vision, Industrial Robots, Pneumatics, Control Systems, Process Automation, Factory Automation, Systems Integration, Entrepreneurship, Career Stories, Personal Journeys, Company Culture, and any other interesting and timely topic we want to discuss.
Co-Hosted by Nikki Gonzales, Ali G & Courtney Fernandez - find them on LinkedIn!
Automation Ladies
Collaborative Innovation, AI, & Cultural Dynamics w/ Dylan DuFresne
How can the collaboration between AI and cultural understanding create optimal performance in projects?
Join us with Solutions Architect, Dylan DuFresne, as we navigate the complex landscape of digital transformation, shedding light on the often-overlooked human elements that can make or break technology implementations.
We reflect on the evolving intersection of electrical engineering and software, and how the collaboration of AI and cultural understanding are keys to unlocking the full potential of technology in today’s rapidly changing world.
__________________________________________________________________
Co-Hosts are Alicia Gilpin Director of Engineering at Process and Controls Engineering LLC, Nikki Gonzales Director of Business Development at Weintek USA, and Courtney Fernandez Robot Master at FAST One Solutions.
Follow us on Linkedin and YouTube for live videos, demos, and other content!
Subscribe to our weekly newsletter for episode updates, job announcements, and more!
Get in touch with us at automationladies.io!
P.S. - Help our podcast grow with a 5-star podcast review if you love us!
Cool. Okay, it is the day before Thanksgiving, wednesday, november 27th. This is a pre-recorded episode and I actually, dylan, I'm not sure if it's going to go out in this season or if we're going to have to wait to publish it next season, but I'm really glad we caught you before a barrage of end of year on-site projects and stuff. I know that your schedule was pretty full for the rest of the year, yeah, so I guess I should back up and say welcome to another episode of Automation. Ladies Folks, thank you for listening.
Speaker 1:And we have, myself and Allie, today with our guest, dylan Dufresne, which we have tried a couple of times to get on and we ended up having to reschedule because Allie couldn't make it last time and Dylan and I ended up talking for the whole hour anyway without recording anything. So to officially get this conversation out in front of our audience and to get them to let you know, get to know you a little bit better, dylan, I guess I'll go ahead and ask our first question, and that is can you tell us a little bit about yourself and how you got to be doing what you're doing right now in the automation space?
Speaker 2:Yeah, I guess I could talk for hours on that part, so we'll keep it short on that. But a lot of it happened just kind of by accident and where I ended up Started off in a tech school, relatively local, kind of an easy option and good place.
Speaker 3:I was I was stalking you. How did you find a mechatronics program? And then I know now that you're just like really like software heavy. How did you like were you maybe a computer guy before that? Like, how did you get so deep into the software when you started in a mechatronics program? And how did you find the mechatronics program, Start with that and then go to the other one?
Speaker 2:Yeah, so the funny thing with the robotics program is the school that I went to is a pretty well-known regional one, not like a big name in the country, but well-known with a lot of the local companies, and I fell into it because my grandparents lived in town and I didn't have to pay rent for the first year they had a robot program and robots sounded cool.
Speaker 2:I was on the robotics team in high school, did a little bit of CAD and stuff like that, but nothing like real industry type stuff. And one thing led to another. We went through the program and when is this? This is in.
Speaker 3:Minnesota.
Speaker 2:Yeah, this is in Minnesota. Yeah, yeah, One thing led to another got the first job there working as a service tech, started out with an internship and got a job there for a OEM making packaging machines. While I was there we did a lot of everything. They kind of bounced me around department to department so I worked with the mechanical assembly guys, the electrical assembly panel shop. I worked with the controls engineers, the electrical designers, startups and troubleshooting calls, things like that for about a year, Ended up getting laid off from that job. That's always fun, oh yeah, especially right out of school, and I did the dumb thing and just bought my first real car and it was a fun time. It didn't last long, Turns out it was an in-demand skill set. So about a month after I got laid off I think I had like six or seven job offers. In that time it wasn't like uh that's a sell.
Speaker 2:That's a sell for us, yeah and ended up getting a job as an electrical drafter with a electrical contractor so still not really software. Um, ended up going and started to do, just because that came up, started doing some controls projects with them, got into one really, really big one way in over my head, sweet um. It was probably 50 or 60 different pieces of equipment we were controlling I think it was 15 and a whole grain elevator into feed mill situation pl PLC, scada project and that was a good start for your project.
Speaker 3:A bunch of cabinets.
Speaker 2:All MCC, yep, nice. So we had one panel and a bunch of MCC sections, a bunch of VFDs and feeder screws. We had a 400-horse VFD control and hammer mill so that we could ramp it up and take care of the inrush current a little bit and then rotate the direction every time you started it up. It was a lot for the first project. We'll put it that way To this point I had only troubleshot ladder logic, I had never done anything real in a PLC. Yet, baller, that's how you learn.
Speaker 3:By fire.
Speaker 2:Oh yeah, that project also, ironically, was the first time I had heard of Ignition. It was a Rockwell PLC at Ignition and that was my introduction to the industry, early days of Ignition. And then from there the controls team that did exist all ended up quitting or getting fired. So then for a while there it was just me and I was taking care of all the service calls and everything across the pretty much across the Midwest. So one day I'd be in pretty much South Dakota and the next day I'd be on the other side of Wisconsin and the next day after that I'd be somewhere in Iowa doing a service call, or Nebraska and just bouncing around driving all over the Midwest.
Speaker 3:Would you notice that when we would like? When you go out to dinner, right, you see, like other people that are completely by themselves and you're just like I don't know, you like nod at them because you're like, you're here in business and you don't know anyone, do you? It's really easy to spot those people because you are them oh, yeah, definitely and yeah.
Speaker 2:So through that troubleshooting I definitely learned a lot, but that was again still mostly PLCs, HMIs, some SCADA stuff and a lot of instrumentation and working very closely with electricians. So a lot of focus on the install side as well, but learning everything I mean. There was one project we did. It was a pretty small project, adding a bin to a grain site, and the owner said, hey, we got this job, Go do it, Figure it out. And my first question was all right, what's Profibus? And his response was you'll figure it out, Gave me the keys to the truck and sent me on my way. Fantastic.
Speaker 3:And you did, didn't you? Oh yeah, I did.
Speaker 2:I don't know how I did it at the time, but I always figured it out one way or another.
Speaker 3:That's what I love about this job and then, yeah, that company.
Speaker 2:It grew from that where I think I could be wrong on my numbers, but when I started there there was less than 30 employees for sure, and then when I left that company about eight years later, there was almost 300. So then I got through the entire phase of that integrator. About eight years later there was almost 300. So then I got through the entire phase of that integrator. That was. Their primary business was electrical services, power services, things like that, some solar work and all that. And then we had the integrator within that and, yeah, so I learned a lot watching that company grow from the inside, seeing how things worked. I mean, I went from the drafter who got thrown on a PLC project to, by the time I was done, I was the manager of the entire engineering team and saw that along the way, made my own mistakes along the way and learned a lot on that side. And over the time there, the different projects we were on, we got more and more into SCADA.
Speaker 2:I accidentally fell into MES just because that was customer request. I didn't know the word for it until we were already done with the project, but they just asked, hey, can we track this. Can we log that? Let's put a database in for this and we need to be able to track this stuff and schedule work orders and all that. And then, a few months after that project, I learned what MES was and I'm like, oh, I've already done this, that's hilarious.
Speaker 2:All at MES in their industry Yep, um, that's hilarious. All at mes in their industry yep, um. And yeah, so through all that, I mean I pretty much got everything from hands in panels installing sensors and troubleshooting the installation all the way through all the starting to get into the software and the mes side of things and pretty much every layer of the stack through there, integrating with the erp systems and as the company grew. Those are the jobs we got. So I just kind of went where the work did and learned what I needed to to keep up and then managing the team and all that was a whole different story, a whole other skill set to learn. And yeah, but along the way, the big one for me was where I really enjoyed it was the software side. That's where I was interacting more with people and not just sitting by myself in a control room, and for me personally that was kind of what I enjoyed more than anything.
Speaker 3:The police.
Speaker 2:They'll pass, you'll be able to hear me again, yeah. So through all those different types of projects I kind of learned what I enjoyed, more I got I'm still probably I'm still really good with and I just can't seem to get away from the plc side of stuff. But I really enjoy the software and the people aspect of it really more so than any of that, and being on the software side and almost even to a point of more like consulting work and things like that. That's where I really kind of found my enjoyment. So the last couple of years has been spent really trying to find that niche and figure out what I want to do going forward.
Speaker 3:Very cool very cool.
Speaker 2:So, yeah, I mean I could go round and round at a lot of this, but I don't know if you've got more questions or ali, I'm gonna give you the opportunity to ask follow-up questions, otherwise I'll dive in.
Speaker 1:But I I like tried to take a screenshot just now and I did something funny with my computer, where everything is dark relatively dark I can still see it, except for your face. Dylan is nice and bright, but, like when I change my screens, that that little rectangle stays. So I'm in this stage of my life right now where I'm seem to be in between being good at anything, including this, um, but aside from from those distractions, uh, I'm I'm curious. Well, ali, what do you? Do you have any follow-ups to that, or do you want me?
Speaker 3:to um, yeah, like how how did covid go?
Speaker 2:for us it was probably our busiest season. Interesting, um, it might have been the phase of growth in the company. It might have been more work coming in because things were kind of shut down otherwise. But I mean again, our primary business was electrical contractors were you traveling during that time? Oh yeah, I spent pretty much the entire winter of I believe it was 2020 in arizona, back and forth, and I think I flew more during covid than I have before or since interesting like reverse oh yeah, are you tired of traveling?
Speaker 2:uh, sometimes it comes in waves. If I don't travel too long, I want to travel again. If I travel too long, I want to be home.
Speaker 1:It's hard to find that balance, but do you think it has something to do with the nature of the work, the fact that a lot of us, I think that are drawn to it like need that variety somehow?
Speaker 2:I think so the people, people, um.
Speaker 3:So so when did you first like get into anything with erp? So it looks like mes.
Speaker 2:It's like you went from skater into mes on accident and then yeah so erp was kind of part of that accidental mes piece where we were interfacing with, like recipe systems and reporting actual run reports and things like that back into the ERP system. So we would have a couple of different side ones, some big, real ERP systems, and at the time most of it was a file transfer, some legacy system where we didn't really have good access to stuff, but some of it was like custom homebrewed Microsoft access systems that they called their ERP functions and various types of them. But it was always kind of feature requests where we want to do this and we'd figure out how to do it.
Speaker 3:Yeah, how to do it. Um, yeah, it's really cool that you, that you like started your career kind of with the electricians. Um, because I was going to ask you, like on the people side, like, have you seen, you know, implementations of you? Know, I guess industry 4.0 or digital transformation go wrong because nobody cares about you, the people that they're pushing it onto, that have to make it successful to go like to move on or to like, yeah, after the implementation.
Speaker 2:Yeah, definitely. I mean it's all, at the end of the day, it's there to make things easier for people. I mean easier for everybody, and if they're not thinking about everybody it doesn't really work very well Most of the time. What I've worked on has begun pretty well, but that's also because I've been embedded on the plant floor from day one. I mean there's projects where I'll be quoting it with the owner of a local company and then I'll be doing the project on the floor with the maintenance team owner of a local company and then I'll be doing the project on the floor with the maintenance team. So it's kind of it's. It's it's kind of skewed. My perspective there Cause that's kind of what I've seen more than not, is the smaller companies and the more integrated approach where the people who are running the business still day-to-day interact with the people, and there's those smaller businesses that really have that luxury afforded to them.
Speaker 3:Yeah, because the ones that are really kicking butt are like the Amazons of the world and Teslas. But you say you've worked with smaller companies Like can you talk to? Like how do you, can you encourage, I guess, small companies to like get into this, get into this connecting all of your systems, and then what are? You know, what are steps you can take so you don't have to like take it all at once, because I think that's what these companies are afraid of and they're just happy to, you know, be at the size that they're at, but you know it will come down to competition eventually.
Speaker 2:Right, and I think the big one there is. The small companies are actually at a luxury there because it's a lot easier to start small when you're already small. Oh, and it's didn't think about that. Everything's dependent on existing systems too. But it's also a lot easier if you have one brownfield site versus 100 or 200 or a thousand, and so there's always the difference between brownfield and greenfield. Most of the stuff's going to be brownfield and you don't want to rip and replace things that are already working more often than not. But if we're talking more theoretical, we're just going to get started and some of the more greenfield type stuff it's easy enough just to throw in a single ignition gateway or something and just get started with that.
Speaker 2:Um, one of the some of the projects we do I mean it's very much you hear a little bit about that land and expand model and one of the projects we're doing recently is we came in to quote a process system mostly just pumps and valves transferring between tanks and fill lines and things like that, and we came in as just the PLC and the HMI of this project.
Speaker 2:We were able to work with the customer and to get the HMI ended up being ignition in this scenario, which opened the door for a lot of other stuff, and then throwing in a little bit of data logging features and event logs and things like that. So they had a very data-centric HMI that was logging events and data that otherwise really wouldn't have been possible with some of the more traditional HMI platforms. Then, through that, I mean at the beginning of the project, they said you can use Ignition but you can't call it a SCADA system. We're not ready for that. And then, by by now closer to the end of the project, they're looking for ms systems, they're looking for some data collection and enterprise wide kpis and things like that. So a lot of it is just showing them what's possible early on, and it doesn't have to be big very cool.
Speaker 1:I like that a lot because, like you said, you know existing companies, like especially the small ones, right, they always like don't have budget right and maybe not always, like some companies in certain niches are, you know, very profitable.
Speaker 1:But I'd say they the average manufacturing operation, right, they don't have, you know, slushy budgets and they have a lot of things to consider ongoing maintenance, just keeping their operation going right.
Speaker 1:So it can be hard to A fit in the time, b find the right partner and then C, like actually overhaul anything. So I think, just from you know my perspective and the things that I've built in the past, it makes a lot of sense to try to or to be able to like start small, like that, right. And so you mentioned that, yeah, you came in and you called it the HMI, but you guys threw in some some data logging and stuff. Was that just on your prerogative, wanting to be like, hey, we want to show this customer that there's more here, and so you kind of add that to the project, or do you try to get them to agree up front that, hey, we should add this, we should like and I know the way that I would do. It would just be like slightly put it in there and be like look, how cool this is, here's something that you can do. But like, how do you approach that conversation?
Speaker 2:Well, part of it is just our base standards, and a lot of that comes down to yes, we want to show them what's possible. Yes, we want to show them what's possible, and that is part of it. That's probably half of it. But you also a project like this, you also can't lose. I mean, as an integrator, you've still got to make your own money too, You've got to keep your doors open and your employees paid, so you can't give away everything for free, especially as a small integrator. Some of the bigger ones they might be able to afford to just do the whole $100,000 project to start with and prove it and then get paid later. The smaller ones, like us, we really can't afford that. So we got to find ways of getting the little bits we can in and then working with the people and the culture to really kind of prove what's possible and shift that and the other piece the other half of that puzzle really is too, though it makes our job that much easier.
Speaker 1:Yeah.
Speaker 2:I mean, one thing I learned very early on in my career is if I start logging who's pressing buttons and if I have trend logs and things like that, I get the call that says, hey, something happened at 2 am, we don't know what, and then we can figure out what.
Speaker 2:We're not sitting there waiting to do it, we're not, and so a lot of it just comes into various practices. We have that keep make troubleshooting easier, make commissioning easier, validation easier, and so, yeah, 50%. We definitely want to show them what's possible. But the project actually gets exponentially more expensive when we don't have these tools, because they also help our efficiencies as an integrator, which definitely helps that balance of how can we afford to give these things away, to show the art of the possible, and all that without having that budget. Because we're a small integrator, we use those same tools to increase our own efficiencies and that makes the projects on our side that much more effective as well, which kind of hits both sides and everybody's happy. And if they don't want it, we can delete the database when we're done commissioning it, but we're still going to use it as our own tool, just like we want a meter or anything else.
Speaker 1:Right, right, yeah, okay, that's really smart.
Speaker 3:Let's talk about the magic of Ignition, because I thought Ignition for the longest time. I just thought it was like a really cool um skater platform. And it is not a skater platform, it is a iiot like mega giant um and it can do so much more than I ever thought. But, um, kind of, maybe, since you like saw it like back when it was, you know, growing, can you talk about, like, how much more it is than a skater system and what, and like uh, how easy it is, and like what, what the other, because I've heard of other platforms, like perspective, and like I'm not even sure you know the difference, uh, but I know there's like a lot more computer programming on that side. But yeah, like, yeah, can you talk on that point of, like the magic disney world of ignition?
Speaker 2:Yeah. So at the risk of sounding like a salesperson here, but it is from my experience I do believe it. So the big thing for ignition for me is if you strip away all the other features, if you strip away every module and function, what you get in that first core module for it's like 1100 bucks or something I have to look at their website again for sure but even headless just that core module and nothing else, gives you the ability to connect to a plc of almost any type and brand. Amazing, uh, use the udts and scripting to do a lot with that. I mean even headless. At that base price you can connect a SQL database, a Rockwell PLC, and start logging data in ways that are kind of hard. Otherwise. You can accomplish a lot of that at that small level with stuff like Node-RED and that too, but then that doesn't scale very well. So then you're ripping out the work you already did rather than building upon it. So when we can start with even just that base headless ignition, it gives us that platform to start collecting that data and then you can add on, like the web dev module. Now we've got an API, we can use something else to visualize it. Still for relatively cheap. You can start adding MQTT. We can publish that to a broker and now we've got these data models published to a broker with the API and we don't have any visualization in Ignition yet. But we're doing all the back end, all the data modeling and connecting to the edge devices. And the big one is there too we can contextualize edge devices. Maybe we've got a bunch of sensors that are all Modbus, tcp that aren't really part of control but they're part of how we're monitoring the environment and we've got a Rockwell PLC in one corner and maybe a Siemens PLC in the next and we can connect all three of those seamlessly, build up UDTs and structure that data and then from there we can share that data with the rest of the world. And we haven't even gotten to anything that's remotely HMI or SCADA yet.
Speaker 2:I mean, once you start adding, in the past you in the early days it was just the vision module, which was a more traditional SCADA. It was all a Java based drag and drop screens. You bind properties and it's very traditional SCADA. It's just a lot easier to work with than most of them and I have worked with most of them here to work with than most of them and I have worked with most of them, um, and so from there, it was just the easiest gator to work with. It was both the cheapest, the easiest and allowed us to deliver the best results. And this was back in 2015, 2016 probably as mature as it is um and then over the years they added more functions, more, more features, things like that. Yeah, there were some bugs to work out. As they grew, their support kind of came and went, sometimes as their company too, and I'm sure they were growing pains on that side. And that's all resolved now, which is awesome.
Speaker 2:And over the years, now we've got the Perspective module. The MQTT stuff's gotten even bigger. The industry is really looking for more of this and Perspective is much more of your web development type side of things. So it's kind of a you could use it for SCADA and I think they would tell you to. But my personal preference to this day is, if I'm doing an HMI and maybe a SCADA system I'm Envision If it's a SCADA system that's more on the MES or IOT side, then I might use Perspective and a lot of your big applications use both for different purposes, maybe even on different gateways, as we keep scaling up and up, and Perspective is more of a web-based interface. It's kind of a drag and drop way to make web pages with those same tags that we built in that first version when we first got started.
Speaker 2:That's not to mention the so more for mes and erp for my personal experience, I would say yes, but that's also changing as that platform is getting more mature as well. So watching this a year or two from now, this could all be different yeah, how do you see um ai helping the systems integrators?
Speaker 3:I think because it's being used for everything, but like yeah, let's start with like, where different pieces it can be used yeah, there's a lot of things we can do with ai.
Speaker 2:I think there's a lot of steps before we should really get to that conversation. As most integrators, um, if you don't have the support and the culture and the attitude and the technology and the data already in place, it's not going to do that much for you. I mean, even before AI was on this train, I went down the AI rabbit hole a little bit and pulled back, but I'm much more a proponent of let's get some better practices and standards, let's make more reusable code, let's write more code generation without AI, let's get things repeatable and reusable, and then we can start talking about how AI is going to help and stuff too. I mean, I really do like it, for I mean, it's really nice to help comment code things like that. I use it almost every day, but I also as much as I think it's a really, really great benefit to the industry, I also think it's pretty overhyped as well.
Speaker 1:Yeah. I will say, my recent experience with Copilot has left me very underwhelmed, has left me very, uh, underwhelmed back where I was about a year ago thinking like, yeah, this sounds kind of cool, but honestly, these like the real value add for me, for me is very low. Um, and unfortunately, I was thinking that a ai tool built into a tool suite would be more effective than something like a generic, like a chat gpt maybe it will be one day, because it's inside the application and should be then tailored to be useful to the use cases of that application.
Speaker 1:Um, but I've kind of found it to be the exact opposite, like it's less capable than a generic tool and the fact that it's tied to the application for a suite that has multiple different tools and they don't talk to each other and there's no like recognition between them. Um, so I can only imagine, like not having touched any of the co-pilots inside any kind of engineering tools, that they would be equally limited at this point to like very, very small use cases, like you say, maybe the note annotating, or for us it's like meeting notes. But even then I can't even tell Copilot in what format I normally like my meeting notes, like in ChatGPT. It can remember, I can say, hey, I like my meeting notes formatted this way, and it will remember that Copilot was like oh, I have no memory there is a.
Speaker 1:We want to do it all. Do you want me to summarize this email for you? I'm like no, the email is already two, two sentences long.
Speaker 2:Like I don't need a summary of this email there is an important distinction too between general ai, just as a conversation and topic, and llms, which is what we're talking about with like copilot and chat gpt. Yeah yeah, there's a whole lot of different specific implementations. Well then, just as a conversation and a topic, and LLMs, which is what we're talking about with like Copilot and ChatGP.
Speaker 1:Yeah, there's a whole lot of different specific implementations.
Speaker 3:Well then, what's machine learning All over this AI umbrella.
Speaker 2:Yeah, and there's I'm not going to repeat one here because I'll probably be wrong because I've seen 20 different versions of definitions of the difference between AI and ML. But there is the AI side and the machine learning side. I mean it doesn't have to be these big chat, gpt, llm type models, it doesn't have to be these big diffusions and things like that. It's just. I mean a simple forecast algorithm can do a lot of good for somebody. A simple search algorithm on a data set can do a lot. I mean you could do before we start talking about all the LLMs and stuff. I see there a lot of benefit with what the software world would consider traditional and old school. But what can we do with graphs and search algorithms and stuff before we even really talk about LLMs and all that?
Speaker 1:And there's a lot of them what's been traditionally called like operations research, that they use a lot of machine learning, um, in, yeah, statistical modeling and things like that, right, uh, and distributions like I think this is my uneducated or or out of date opinion of when I used to like play more in that space.
Speaker 1:But most people that want AI, they really want the functionality that can be accomplished by standard machine learning, statistical modeling using the right data, because that's also going to be a lot more likely to like, because it's working with a specific data set and it's trained on that and it's a computational type model.
Speaker 1:I'm probably saying this all wrong, but like it's actually uh, trying to just give you the right answer, versus, or to be trained to produce a better answer, um, or better prediction, right, whereas, like the loms are kind of they're still a bit of a black box and they all they do is predict, and they predict based on large, based on language, like how it sounds, right.
Speaker 1:So I think that's a big source of confusion for a lot of people is that they're never, they've never been designed to give you anything close to accuracy or you know anything of use other than sounding good, which is why those like use cases. Okay, you can summarize an email right like that's a pretty decent use case and you know that it can be, you know, fairly predictable and do fairly well with that. But you really have to architect a whole host of models if you really want it to do anything that gives you any kind of like output that you can rely on. Right, and then an lln may be the input mechanism for reaching that model if you want to be able to talk to it, yeah, and right now.
Speaker 2:Well, again, I'll say it's overhyped, and even the llm side of things, I mean technology is moving at an incredibly fast pace. So if you're not thinking about it right now, you are probably going to fall behind at some point. But I do caution against just throwing it at everything and considering it's at the best option without looking at others.
Speaker 1:I think right now, everybody should be playing around with it a little bit, even if just to be like me, to be like you know what, yeah, you're, you're absolutely like. My instinct was correct this hype and this marketing does not live up to what I actually expect, but it takes me actually going and trying it out, to be like, yes, I feel comfortable that I know that current capabilities of this technology don't do what I want or it's not the right fit, right, I think if you're not touching it at all, then you're just susceptible to listening to the hype and thinking it's going to solve your problems and then it really won't. I think in most cases it won't at all. Or, yeah, yeah, like me, like I've been kind of following from the sidelines, knowing a lot about the previous models and implementations of AI. Before LLMs came on the scene, I was skeptical but optimistic.
Speaker 1:Right, I'm excited for the potential of this but at the same time, like I know how overhyped the previous, you know version of things was, even back then, um, working on like proof of concepts where people wanted ai to do all these things.
Speaker 1:And then eventually it's like, yeah, we actually, you know, presented and solved the problem with a, you know, random forest, uh model, architected with a couple of other things that really would be considered more like basic machine learning, right, right, um, but what matters is the output, like people want the output that they want. How we get there doesn't really matter, but I think if you're not on that side of the equation, it's way too easy right now to think that current, like hyped technology will just all of a sudden fix all these things that we couldn't do before, or on the other side, you can just be like completely pessimistic and not look into it at all, and then I think you are like things are moving so quickly that you're kind of going to miss the boat because you'll have no clue what's going on when things actually are getting to a point where they are really useful yeah, I mean I remember back.
Speaker 2:Was it two or three years ago? I'd have to look at the exact timeline again. It might be close to three by now. But when Dolly Mini really first came out and I mean it was just we'd around the office we would print out pictures as memes and throw them on each, on people's cubes and on the walls and by the printer, and it was just fun.
Speaker 1:Yeah.
Speaker 2:But it was. We weren't getting anything out of it, it was just office jokes. And then all of a sudden, chat, gpt came out of nowhere and it was kind of cool, but it wasn't. We weren't doing too much crazy stuff with it. And then you started learning oh, we can help you with the code and things like that. And in my experience it's a lot better on the software side of things like if you want to program something in python or something like that than it is on the plc side, just because there's a larger knowledge base out there for it to learn from yeah um, but then it went from that to all what we know now, all overnight.
Speaker 2:I mean watching the different image generators come and go and watching the technology change and I mean, if I remember, back to just those pictures where it couldn't even do a face without making it look like a swirl, that we were laughing and joking about in the office, to what we're doing now, where it is ubiquitous and a lot of people's lives.
Speaker 1:it's crazy how fast it's moving yeah, so I think we will have. Potentially I guess we'll still determining this and, ali, you can speak to this better than I can we're thinking about having an ai section. Uh, at ot skater con right, and that that's prompted by a couple of people in our network that attended last year that are actually working on something in the systems integration realm using ai, and that is like building specific applications to to solve a customer problem that they have, or a um, a process that they see as being a repeatable part of their business that they can offer to their customers. That has some value for.
Speaker 3:AI. Like Wireshark with AI. Huh, like Wireshark with AI.
Speaker 1:Yeah, yeah, okay, I don't know about that one, but that would be something that we'd be interested in. You know, kind of like exploring in the community, but with, like, what are we actually doing? Don't give me the sales pitch. Like, having been to some of the press conferences for the you know, release of these co-pilot things, like I just don't see a whole lot of value in like hearing that it's like, okay, brass tacks, so like, can this actually do my thing? Or, if it can't do my thing, what can it do? What is it actually doing?
Speaker 3:I think it can just do anything that we can do, but way faster than us. I think the idea is that it's not going to build anything magical, but we are the magic and if we fed it to these systems, we can do our magic faster. So really it's just about bringing our magic to market faster. I mean, I think that's really all we're trying to do with the ai right now. Um is speed, um, because I I mean, I don't think, yeah, ai isn't magical enough to just make shit up, but, like we have so many things that we can, just that we do so slow and yeah, it's great job security. But, like, if we want to actually compete with, like large firms bigger than us, cause we're little right, like if we want to compete and all these other small firms, like, how do you leverage? And especially because we are small, we can and we're like startups and we're new, we can bring all this stuff in and force all our people to not force, but you know what I mean? Like bring it, make it part of the culture, whereas these giants can't do that, and so it really can be a means of, uh, competition between the little firms and the giants. Um, so we can take a real market share if we can use this magic. But we have to direct the magic because it absolutely is garbage in, garbage out, um, and so we we have to find the, the magical people to to feed.
Speaker 3:I think I mean nikki was talking about doing this, where it was like people needed to make their own gpts. So it was like courtney could make a courtney gpt and that gpt could like help you size a robot and like I could make you, you could make an alley GPT and that will help you, like I don't know, size a pump or whatever, do some piping, um, just like, take all our individual skills and like make these, you know GPTs. And then I guess, if we could, I I really want to use it to like quote systems, because I hate making custom, you know, custom control panel quotes. It's like there's only so many drawings, there's only so many control narratives and like oem manuals, there's only so many like deliverables, right, like on the integration side, and then the installation side has all of its own and you know, we partner with like electricians and then we just build something that just like makes this so much faster because, like we do, we spend a lot of overhead, uh, creating these freaking proposals, and I think some I mean other people do it better than I do it or we do it, but like, yeah, that's where I'm like I feel like we could really use it.
Speaker 3:Um is, yeah, just sizing, sizing like all the crap that we already know how to size, and yeah, kind of just if we taught it from the you know best people in our organizations. But then how do you implement that? Because that just seems like really hard, like, unless you can take, unless the person's mind is of the type that can like, like regurgitate everything they know into a list or a flow chart, which I feel I can, but, like, I feel like most people can't, um, and they just don't know how to like dump whatever it is they want to happen into a sequence, or into a flow chart or into a whatever lot sequence of logic gates, yeah, um, and so like, maybe, um, are we thinking? Or into a whatever sequence of logic gates, and so, like, maybe are we thinking of, like, maybe we need to start a new business?
Speaker 1:No, I'm just kidding. The inverse of that also is like that is all possible without AI.
Speaker 1:It's just it takes building and I think maybe what the barrier that may be being removed here is somebody that's not technical enough to build this into a standard, like in a standard software type environment, or a plugin like build it drop tool Could do this now potentially right by just dumping all that information into a GPT and like trying to train it. But, dylan, is that something that you guys like that you're already familiar with, kind of building these things?
Speaker 2:I see you nodding like a little bit technology I'm more nodding because this pivots back to an earlier piece. Here there's two points off of that to bring up. Is one just like anything else, whether or not we use ai, what, what tool it is, whether it's ml or just a human process, it goes back to the conversation of what are we trying to accomplish? Then let's find a tool to do it. Ai may or may not be that tool, and it could be a lot of times. But if we start with a conversation with, well, I need AI, you're not going to get the right tool.
Speaker 3:Okay, touche.
Speaker 2:So the big one for me is starting with the problem, starting with the need, and then finding the tools and the technologies that can support that.
Speaker 2:And then, if we follow that logic back to kind of what Ali was saying, I was really nodding along with the point of well, that takes the right type of person, who can document that, who can think that way, who can.
Speaker 2:And even if you take A out of the equation, you need that, that somebody in the organization with that skill to get that knowledge transfer to happen. Because a lot of the engineers are really good at documenting in very technical ways, or some of them are really good at figuring stuff out, but they can't document anything for their life. Some people are really good at documenting but they don't have any of the technical experience and so they're really good at pulling that out of people and then documenting it for them, and those are all good ways of doing it for different people. And that comes back to even before you start talking about the needs and the problems. That's much larger cultural things to think about and that's part of where the further I got in with the technology, starting even with the electricians and wires and terminations in the field, all the way through almost the entire automation stack. The conclusion I came to is none. And AI is included.
Speaker 2:None of these technologies are going to solve your problems until you've identified the problems and identify the need to do something about it. That's where a lot of my current time and thought is spent on the people side and the culture, much more than it is on any specific technology or implementation, because they're always different, but the people are the same, the attitudes are the same, the culture is the same, and it always goes back to that question of whether I want to put a wiki together and put it in a Teams channel as a knowledge base. Well, I got to get my employees to do that. They're not all good writers. Some of them are really good and some of them are good at other things, and we were in that same problem that we just came to when we were talking about documenting GPTs as well. So you have a lot of this overlap, and it all happens way before we start talking about technology.
Speaker 3:People are everything.
Speaker 2:Mm-hmm technology. People are everything. So, just like, if I mean the question comes down to do I need an MQTT broker in my IOT stack? Maybe let's talk about it. What are you trying to accomplish? Do I need AI in my corporate initiative? Maybe let's figure out why.
Speaker 2:But if you start saying I need an MES system or I need a SCADA system or I need AI, it's going to be a problem. And then your digital transformation, your little project, whatever the scope, is going to fail. The one might be successful, the second one or the third one you're eventually going to find yourself in a bottleneck. You're going to have some technical debt. Things are going to fall apart somewhere along the line.
Speaker 2:So if you really want long-term sustainable solutions rather than just a one-off project, that's where these questions come in, where it's not about I need an ERP system. It's not a part. I need MES. It's I want a way to schedule my work orders better, because the people on the floor are losing the papers. And now we start talking about how can we do that? And oh, by the way, now we have an MES system, or maybe we're going to add some more features than eventually we do, or I need to know the state of this machine that's running so that I can calculate this KPI over here. All right, let's throw in some IO link sensors and maybe that master talks MQTT, so we throw a broker in there and then that broker goes to whatever's calculating that kpi and all right, yeah, cool, now we've got some iot going. But that was never the intention.
Speaker 1:The intention should always be to solve a problem yeah, I think we get a lot of on the vendor side of our industry. We get lost in our own buzzwords and marketing and we think that everybody needs our solution.
Speaker 3:Right, they should well, somebody brought up to me recently the difference between engineering, like selling engineering, and selling solutions, and I was like, oh, that was like an epiphany for me. I was like, oh crap, like, because engineering doesn't, you know, is repeatable. Everybody can, a lot of people can do engineering, but like providing a solution, I mean it's like when did when did engineering not become solutions based? Like, I don't know what happened, but it definitely happened Because, you know, I always thought engineering was, you know, we're engineering because we're trying to solve something, but that's not necessarily what's going on. And so you should. I mean, at least in terms of like, when people are looking for solutions, they're not looking for engineering.
Speaker 2:Right, and that's where I'm in. Going back to the project I was talking about, where we start with ignition. As an HMI, I mean projects like that and I get myself in trouble sometimes because it's not always great for the companies I work for usually ends up good in the end, but some, depending on how you're thinking about it, right yeah Is I'll be sitting down with the customer and clients and I will be sitting in this meeting. We'll be talking about the scope and what we need to do and I'll start putting a quote together and I'll see, well, we hard specced a panel view and I'll go back and said, well, you said you want to do all this, but you told me you want to use that. That's not going to work. And so then we start to kind of the conversation and sometimes I have to just quote the panel view and it is what it is and we'll do the job. And most of the time it doesn't work.
Speaker 2:If that was what they were talking about, if it's a standalone little panel on the side, a little skid system or something, there's no problem. But if you're trying to then connect to that later, then the PLC becomes a bottleneck because now you've got the HMI and some other device and your IoT system all pulling tags out of the thing, and now you just run out of memory. The CPU can't keep up, so then okay, well, if we know we're going to do this data initiative no-transcript, the plc like let it go, like, oh yeah and I mean at the same time they're, they're, they're, they're going to argue.
Speaker 3:Well, our people all know how to use, like they know how to do mer files, or they know how to use panel view, and that's why we don't want to do your solution. We want to do what our people know. Um, I mean, how do you really combat that? Or do you just put that gateway in and you're just like fine, we'll use your stuff, but we're going to make it all talk through this and then we all win, even though you're still you're spending more money but you are making your maintenance people happy right and there's a compromise.
Speaker 2:I mean, sometimes there is a very good reason for this is what the people know and we can't spare parts agreements.
Speaker 2:I mean, that's used as a very bad argument a lot of times, but there are times where it's valid and it's identifying those and being able to put together the team. And again that's where I keep falling back to the culture piece much more in the technology, because you can't actually affect any change for what I'm trying to look for and where I'm passionate in with just putting in the panel view. So then it's well, and sometimes the panel view is great. I'm not saying that's always the bad solution, but in the case where you want this big data architecture, you want this other stuff and you're going to put in the panel view, but you won't even at least put in an OPC server or something on the side, then you start having problems with scalability and maintainability.
Speaker 2:Things really don't scale the way that, through the conversation with them, have already identified that they're looking for. And so then you guys start talking about the bigger picture stuff and you start talking about strategies and roadmaps and how are we going to get there? And well, this is part of a bigger thing and you lose a lot of people there. So then you got to start figuring out how to feed the information at the right times and make sure things are successful, and it just becomes a whole dance of how to. I mean, it's all about the culture, more so than anything, and that's a whole different game than the technology it's.
Speaker 1:That's so true, because you can take the same technology stack and implement it in two different companies that have two different cultures, and you'll have very, very, very different outcomes.
Speaker 2:Yep, and I'll recommend a fully different technology stack to those two different cultures yeah I mean you might have a brownfield site that already has plant packs installed on everything and there's no reason to rip it out for data stuff, but you're not getting much of your data out of it. So then maybe we don't even look too much at ignition right away. Maybe we just start with like flow software or high byte or something to pull data out of fact talk historian. Or if we're doing a site where they don't already have this entrenched stuff, or maybe it is a rip and replace type thing where the old system's not working well or it's a legacy thing that needed to go anyway, then we can start with something big like Ignition and build the whole thing from there. But there's always different people involved and as long as there's different people, you're going to have different solutions and different needs and different wants and different perspectives. Everybody's different, every team is unique and what they need to be successful is unique.
Speaker 3:Well, I think the one non-unique thing is that everybody needs to like focus on data, and if you're blind to data, you're kind of like well what, I don't know what's gonna happen to you. I worked with a machine shop that I will not name whose control engineer used panel views often and never, never, used the like alarm historian and like alarm alarming, like you know the table yep um, and so there would just be, you know, like if there was an alarm state, you could see it, but there was no history of it, right.
Speaker 3:so it was like we didn't have time stamped alarms and I was like what in the hell is going on, um, and so it was just like welcome to you know the 21st century.
Speaker 3:No, but, um, uh, that's incredibly important and people don't know they need that. They don't even know what they're missing if they've never seen it, and some of that stuff is just like built into even things like a panel view and yeah. So there's like those standards, you know, if they don't know about it, uh, data, data standards, um, and and like how you get like what is the general information that you need to show to like the operator of a machine, like there's minimums and you can go really deep, um, and you can create all these you know, like compounded kind of situations, um, but at the minimum, you know every sensor you need to know like is, is it in a faulted state, like um, and or you could just not look into that at all and not show those numbers, and and then you don't know what you don't know, I guess, yeah um, and that goes back not just to the customer side too, but also as we're doing commissioning and things like that, or as we get service calls.
Speaker 2:So going back to do we put these things in, at whose cost and how much are we giving away for free? This is part of the efficiencies that we're gaining on our side, too is now we get the service call for this machine that we've warrantied for a year or whatever, and with Ignition as the HMI. One of the things that I do with very minimal effort, now that I've done it enough times is we've got the data log to tell you which operator was logged into which HMI when they pressed the button to put the machine into hand mode and manually jog this thing, at which alarm showed up at that time nice, the general equipment state and all the other stuff. That and the other machines that might also have that right. And once you're on that level of stuff, I mean that's when the doors really start to open. People know what they, people don't know what they don't know. They don't know. This is even possible, let alone that it's easy. And so the big one there is. I mean my favorite story on that is I was at a customer site where they had three shifts and the manager came in.
Speaker 2:Manager and I both came in the morning we were still commissioning it, but they were already running it. It was pretty much that last week where you're kind of babysitting and training right. And we came in in the morning and there had been a big problem, a big pile up of spilt raw materials on the floor on third shift and nobody knew why. Manager just got upset and started yelling at the operator this is what's going on, and all that. And I pulled him back and said, hey, before you start yelling, let's actually figure out what happened. And so I pulled him in toward we were looking at that.
Speaker 2:This is a larger SCADA system, not so much just an HMI. So we pulled them in front of the computer and pulled up the keyboard and threw together some of the ad hoc trending tools we had and let him drag and drop tags and history into a chart and some trends and all that. And we were able to identify that the operator actually did exactly what they were trained to do in that scenario and he realized they probably shouldn't be trained to do that. So I actually don't do that anymore. That's on me. And now nobody was screaming at anybody, nobody was angry, and everybody got better for it, and that's not an, that's more that's.
Speaker 3:That's a life jab at me because I always spiral and really I just need to not do that.
Speaker 2:It's like calm down let's just let's just figure it out, yeah but even I mean I guess I don't know that about you or not, but specifically like if you had the option to come in, you saw something was wrong and you knew the data was there. Now that gives you the chance to go yeah absolutely, even if you were right now you've got that cool down period where you're no longer hotheaded, just jumping into the situation. You've had 20 minutes removed trying to solve it and identify it, but also now you know what happened.
Speaker 3:whether it was what you thought. Absolutely, I've never not regretted it. It's just something that's hard to control. But yeah, no, the data. The data speaks way louder than anything else and that's why you need to have the data.
Speaker 3:And yeah, I've, you know, through my career, have, you know, let others pressure me.
Speaker 3:You know, like project managers and like other people in the project that have a, you know they want to save money on a project.
Speaker 3:So it's like they make decisions and or they push decisions onto the designers that aren't the best decisions, and I've watched, you know, the repercussions of that, and so it's just, you know, nice to see that like, oh crap, Like I've seen we're not going to put limit switches in on our valves.
Speaker 3:So so when we go to, like you know, and we had like temperature control valves and we're like, well, it's sending out, like full open for the cooling valve, and like you go there and you just hear yep, and I'm like, no, it's because air is like not being delivered, like, yes, the solenoids open, uh, but there is, yeah, the air was not connected. Somebody disconnected air. And so, if you don't know that, by having all of the proper feedback, feedback costs more money because it, because it's usually another set of wires or another wire, um, and so that's where people are like, well, let's use you know as much as we can. You know communication or remote ios, so we can do you know less, less wiring or whatever. But yeah, I don't know where I was going with that.
Speaker 2:I'll make an assumption where you're going with that and correct me if I'm wrong. But I mean that data just isn't for the big MES data type, erp, digital transformation things. We need more data for the control systems too. I mean I've been there where you've got the projects, like you just said, where you don't have positions on the valves and the operator's saying, well, the valve's open, why isn't it open? Screen says it is. You're clearly wrong and I'm like, no, did you turn on the air? And yeah, whole thing's avoidable by just putting the switches on.
Speaker 3:Yeah, the screen is it got an orange or a green valve because the signal is on, but that doesn't mean that it's actually turned on. It just means you're trying to turn it on. The command is on.
Speaker 2:Right, Green doesn't. If it's green or white or whatever your color scheme, that doesn't mean that it's on. It means that we're assuming it's on.
Speaker 3:Yeah, it means that we're trying to turn it on.
Speaker 2:And then I mean it goes to the same thing. Do you have auxiliary contacts coming into inputs off your e-stops? Do you have disconnects? Do you know which disconnect is tripped, or is the motor just going to not run? So now we're telling it to run and it's not running. Well, do we assume it's a bad motor because or, as we're troubleshooting, we find the disconnect?
Speaker 3:was off, and how much time was wasted there.
Speaker 2:And even outputs on cards can go out, or inputs, which is crazy. And so it's. The data isn't just for the big picture IoT world and the digital transformation. We need more data to make better control systems too, before we even talk about logging in and doing stuff with it outside of controls. And again that goes back to the culture piece, because if the bottom line says, well, we can save money by pulling, not pulling these two wires, and then a year later they realized how much more time they're spending in maintenance and troubleshooting because they didn't have those wires, and I don't think anybody in the controls world has ever not had this thought of, well, we weren't consulted early enough in the project. But it's true, yeah, because nobody thought about the ramifications of taking out those wires because they didn't know it's not well.
Speaker 1:That's why I think it's so unique and so valuable to have someone like you, with your background, or Allie in the sense of like, where the time that she spent, like with the electricians and in these different types of like, different areas of the business, right, because you start to realize that you should think of things that other people that just haven't had that experience with it, right, and I know we don't have much time left so people that just haven't had that experience with it right, and, uh, I know we don't have much time left, so, um, I'll mention a tangent path that we won't go down but otherwise would be a whole.
Speaker 1:Another episode um, I noticed some chatter in our ot skater con uh group about, uh, I guess vlad from manufacturing hub shared an article or a podcast, I think, think, and this was um, and I know Alicia Lomas uh chimed in but about kind of software engineering and how that's really kind of taken over in a lot of the greenfield and like the startup space in particular.
Speaker 1:And I'm quoting something I haven't listened to, but the discussion seemed to be that, you know, they're kind of finding that, yes, people want to do this with more traditional software approaches and get away from, like the old school, plc stuff, right, so you can have more software engineers instead of, like, lateral logic controls people. But they seem to be missing the boat on this success. I think in large part and this is again just my you know, throwing my opinion at the wall without knowing much that you have software engineers that can program processes all day long, but they don't know whether there should be a limit switch on something or whether there's missing data input from the way that the processes actually work or what cavitation is, or anything.
Speaker 3:Yeah, and this is, I think.
Speaker 1:Ali and correct me if I'm wrong, but one of the reasons why you put together OT Skatecon was exactly for this reason to try to get all of those people together in the same room and to like not so much that everyone has to know all the things, but you should know what you don't know to a degree and like who you need to be thinking of and maybe who to call if you do need that perspective.
Speaker 1:Knowing what you don't know is incredibly powerful today yeah and except that many people like dylan around that, like you know, you started an electrical installation and now you do. You know software programming for these big systems like that. I don't think that, like I don't know any old electricians and then now works in mes.
Speaker 3:Like that's crazy, which is really cool I mean, naomi does too. But like, yeah, like it's very, very, very rare to be able to to speak both of those languages. Like because electricians do speak their own language. And if you do not know how to design motor control circuits, good luck. Uh, actually like arguing with them in a commissioning job, I find that right now, like with my own engineers, I'm like they are going to, they're going to say a lot of things and the only way to prove it isn't us is to prove that it is them. So you have to be able to like, see, like look at their circuits and be like, well, what about this? And once they know that you speak their language, like they do, they stop with the crap.
Speaker 2:And and. Once they know that you speak their language like they do, they stop with the crap. And to touch on a few of the points we just hit there real quick before we run out of time is the first one going backwards in order here as I remember them. But the funny thing for me too is I didn't just start with and know a lot of electricians. I was taught electrical engineering by electricians.
Speaker 3:That's baller.
Speaker 2:And that comes from a whole different perspective than a traditional education would. Yeah, then the other one is too with the software piece, and we could have a whole, another hour or two long conversation on the nuances there. But just to say it a little bit is again, it comes down to the people and the needs. I mean, I know plenty of controls engineers who don't have the process knowledge either, and so it's not a unique thing with the software engineers, it's just a thing with the industry. You need to have both the process and some of the programming knowledge, or at least a team that has all of that.
Speaker 1:Yeah.
Speaker 2:And going back with different needs, different tools, different technologies for different people and cultures and things like that is you get into, it's always going to be you need both. Nowadays, there's never an argument, I'll say, where you don't need software or you don't need control as a traditional engineering. But how much of each is going to depend on the team. And there are applications where a fully software-defined PLC will do the job better than a regular one, and there's times where you need the reliability and the safety of a more traditional one. And as more technology comes out, I'm sure that line is going to get more and more gray as it goes. But it always comes down to, just with any other technology, it's we can use this and that, not this, or yeah.
Speaker 1:So, yeah, my, my life motto seems to apply here, just like it does to everything else, which is why it's still my motto, which is the answer to everything, is it depends. Yep, you're like that's a cop-out, but it's not in the sense well, yeah, no, I mean, it just feels like one, yeah, well, yeah, and. And the lack of a cop-out is clear if you say, well, it depends, and now let's dig into what those things are, versus just using the word it depends as a way to avoid getting any kind of answer I've been accused of that myself.
Speaker 1:I say it depends a little bit too much, especially with technical stuff and especially on forums and stuff where you can't really have the whole story up front yeah it's always it's why it's so hard to have these discussions, and I don't want to venture into other topics like politics or whatever, but it's like when people don't appreciate nuance, then what the heck? Why are you even talking? Now? You're just like you're.
Speaker 1:You're saying one thing and it clearly can't be like correct and you just have childhood trauma at that point like, and that's not our problem, but I think that's one of the things that we struggle with, too, as content creators, if you want to call it that. Right, like we were having these discussions, and in public, and the reason we did was we were, we thought there was value in the discussions we were having in small groups online, and we were like you know what? There's probably people that would love to be part of this small group if they knew that we existed, and vice versa. So let's put this out there and let those people find these discussions or whatever we're talking about, right, but we're so not like focused on the headlines or the clickbaits, or even when people, when they want to have an episode with us and I love the way you put it was like here, an episode with us, um, and I love the way you put it was like here's a bunch of things I can talk about and or anything.
Speaker 1:Um, because that's also how we are because when people want to like, oh, we want to talk about this specific thing and the headline is going to be this, I just feel like it loses meaning for me. Like, if you're trying to predetermine in a can what you're saying, then really what you're doing is messaging you're not discussing anything if all you want to do is, like you know, talk like throw out your buzzwords and not get into the meat of actually how and why, and those things are always messy and complicated and they don't got into some buzzwords when they were playing meeting.
Speaker 1:Um, it just yeah, it's, it's.
Speaker 1:It's tricky to then be like you have confidence in what you know, um, but standing next to someone that has like unlimited confidence in the thing they don't know, they can come off as more than you because you actually care to like really give the the better answer or the more correct answer or the more feasible answer, versus just the thing that I've been taught and like I've been guilty.
Speaker 1:My first job out of college was for a, you know, manufacturer of sensors like kians, and they're very they sell only their own stuff and they they're you know, japanese kind of version of doing things is when they, when they come out with a new version, they want to make sure that they're the best at something right. So every catalog that comes out of key is that I know from at least back in my day was like it's the fastest, the world's smallest, the whatever. Like a very definitive, very flashy statement which has some truth to it, because at the time it was released it probably was the smallest in its class, based on the design considerations and like the application that they're tackling. But you know, when I come out with that brochure two years later and I go to my customer and I'm like it's the smallest in the world and it's like, well, with a lot of asterisks, right, like you start to realize, the more you learn how stupid it is to say something like that.
Speaker 2:Most of the smallest in the world. But if you've got a bunch of empty space now because you didn't need the smallest, it comes back down to yeah, and also it probably won't be the smallest for very long, right?
Speaker 1:So your talking point is immediately outdated as soon as somebody else makes a smaller one. And, yeah, I think you know from a systems integrator point of view too, like, how do you communicate the value of the fact that you know what? We're not going to try to sell you a solution and a can solution that won't actually be the best for your problem. We have, you know, being able to say, like that, something that's like super and I guess this is why I'm not in copywriting or marketing, really but like you have to be able to translate that into something that sounds as flashy as as the people that are super confident in their, in their like major feature that's just going to like be the silver bullet for everything.
Speaker 2:Yeah, and that's as you said. Nuance and intent matters, and one of the scary parts of public conversations like this is intent matters, and somebody listening to this later or with a different background may or may not pick up on that intent. And then you said something that was right for this scenario, but that doesn't mean it's right for every scenario, and you can only say so much in a one-hour conversation, so you can't cover your bases of well, in this scenario, it's this and I like that over there, and maybe this one instead, and there's a lot of nuance that it's hard to convey.
Speaker 1:Absolutely Well, I think, and for those of you that are listening unless you're, like a first time listener to Automation Ladies, hopefully you know our intent and the fact that we appreciate this nuance, and we hope that you do too. Uh, but we would, I guess. Yeah, let's, let's wrap this up, ali. Do you have any last questions, since I kind of hijacked the last few minutes here before I go into my standard closing question? No, I'm good, this was awesome, thank you. Thank you, yeah, so I guess we'll just end with dylan. Can you tell our listeners, um, where, if, if you know you're open to connecting, where people should find you, what they should do, if they like what you have to say today, either from a, you know they want to work with you or they just want to, you know, be in your professional circles. Where do they find you and is there anything that we should be looking forward to seeing from you in the near future?
Speaker 2:So the first one is easiest place to find me is going to be LinkedIn. Other links should be available through there just as easy as anywhere else. Yep, the if you need to get in touch and want to work with us, things like that. Fishbone Technical is a systems integrator, so we're doing a lot of the stuff I talked about here. That's what we're doing and we do everything from machine and process control to data-centric IoT stuff and process implementations and consulting and things like that. And as far as what's coming next, I don't have too many announcements, but 2025 will be a fun year.
Speaker 1:Okay. So I think everybody, everybody, let's follow dylan. Um, we are going to be seeing you at ot skate icon and I think, ali, we are working on, I think we got you to agree, we just now. Now we need to go implement, but to to help us with some sort of discord, uh chat for those that are coming. Um, and, yeah, I think we should make one of the rules for that is that you must appreciate nuance and discussion. If you want to be here, yeah, it might as well be said. You know, to be clear that, and I tried to put this caveat like you know, we're not just going to cancel you if you say something wrong, but you kind of have to be open to the feedback as well, like if you're going to come in and like in any public form or semi you know public thing, because even we all know, like private groups are still not private.
Speaker 1:Somebody can always share what you say or whatever, but it's really important to be able to appreciate people's intent and the nuance in the discussion. And I think in most cases where people end up fighting and you know mudslinging and stuff, like you really don't need to do that. You probably were trying to say the same thing in the beginning but you just, you know, didn't take the time to try to get there, to realize where, where you're at compared to another person, and so many of these like interpersonal and career and like things that we think about there are so reflected on the same side of the technology, because we're always integrating, right, we're integrating different processes with different companies and you know you've got the end user and the systems integrator and all the associated contractors and like it kind of goes hand in hand. Like you, really you just got to understand who you're working with, like try to understand, like where to anchor the conversation, what people know, what they don't know, and then like just proceed with kindness and the intent to get something done of value together.
Speaker 2:Integration is a much, much larger category than just automation, and it's easy to forget that in our field.
Speaker 1:That's true, um, and I guess it's been hard for us to capture the in, in the name of the event, at exactly what it is, because some people just look at skater and they're like, well, I don't do skater, this isn't for me, um, or you know that sort of stuff.
Speaker 1:So we we could change that, we could put a motto and it's just like the yeah, like a little tagline or something that solutions community, that we're a lot more inclusive than just the, the ot and the skater uh terminology. But anyway, we're very happy to have you as part of our community, dylan. Thank you so much for the time. I think our listeners are going to either already know you or be very interested in getting to know you and following you. And yeah, I think that's all. And happy Thanksgiving. I know whoever's listening to this it will not be Thanksgiving, but we are recording this, everybody that listens and supports our community, and from us you should probably expect some more video content as we try to shift a little bit just from the audio side of things to video going into 2025. But this one will come out on the audio podcast either way. So with that I'm going to stop rambling and say goodbye everybody. Thank you, thank you, thank you.
