Fabrication of construction materials continues to evolve, becoming more and more efficient, accurate and effective. Pypeserver has developed their own proprietary file formats, processes and software to push the envelope and provide best in class fabrication. David shares his thoughts on fabrication, and introduces the idea of a 'well constructed point solution.'
David Basiji
Hugh Seaton: [00:00:00] Welcome to constructed futures. I'm Hugh Seaton. Today I'm here with David Basiji, CEO of Pypeserver, David, welcome to the podcast.
David Basiji: [00:00:10] Thanks Hugh.
Hugh Seaton: [00:00:12] Tell us what type server is and what you guys do. And we'll go from there.
David Basiji: [00:00:16] Okay. So Pypeserver is software that's used to drive pipe profiling machines in large shops. And these machines, the issue is that when they first came out, they were an incredible productivity booster because they could do the job of multiple people with torches much, much faster and more accurately. In the current age with all the digital design tools upstream of the fab shop, there's a new bottleneck in the workflow.
And so what's happened is these machines don't really talk to the upstream software. You can't go directly from a BIM model to a pipe cutter select a spool and send it out. So what Pypeserver does, is it goes and interfaces with Revit it interfaces with, all the various Revit plugins that are available and interfaces with all the CAD packages that are out there.
And the nature of these interfaces vary some of them are file export, import processes. Others are direct connections, with bi-directional communication, backup for part status and that sort of thing. But the bottom line is that Pypeserver essentially connects the pipe profiling machine to the upstream design tools.
And so that's the idea is that you eliminate that that really cumbersome and time consuming and error prone process of generating a spool sheet from a model solely for the purpose of somebody programming a pipe cutting machine.
Hugh Seaton: [00:01:45] Very cool. And I've heard this problem in the past where you can specify all you want in BIM, but often it can't go into actual fab machines and CNC and so forth. So you guys are bridging that gap in a powerful way.
David Basiji: [00:01:59] That's, yeah, so that's what we're trying to accomplish. And we of course have a plan for world domination, which is to, first not only interface and connect to all the upstream design tools. But we also want to connect to all the wide variety of downstream, pipe cutting machines, whether they be high-end five-axis machines or, or smaller pipe cutters, tube cutters and so on.
And so we have a cross-platform strategy, both above and below Pypeserver in the workflow within the pipe cutting domain. And then we're also in the process in parallel of expanding beyond pipe cutting into cutting other types of materials that are, that are commonly used in the fab shop.
Hugh Seaton: [00:02:45] So it sounds to me like you're making a decision about whether to be a platform or point solution and for the listeners that are wondering how I went from what you just said to that, David and I spoke before we got here. And I think David's got a great opinion about the kind of perennial question of, do you get best in breed point solutions or do you go with a platform that does lots of things well, but none of them best. And I'd love to hear your thoughts on that since it sounds like it's something you really have thought about.
David Basiji: [00:03:16] Yeah. My, my stake in the ground, as you might imagine, is that a point solution is not necessarily better than, or a collection of point solutions is not necessarily better than a platform solution, but if its properly constructed, then i believe it almost always is.
You know, the benefit of a platform solution, is it imposes order on the process, you get a one-stop shopping to take your chaos and turn it into order. The issue there as anybody who ever went through an SAP transition at a large company, or tried to use Salesforce in earlier days, I think it's much more flexible now, but essentially the software forces you to follow their workflow as they've designed it and for a lot of customers, that's great, for others, it can be an adjustment and it, and you may chafe against it for for as long as you're using it. Whereas with point solutions the burden is really on the user to put together a collection of effective solutions and integrate them, and learn them all and deal with their all their individual quirks.
However, the benefit what I call a properly constructed point solution is this ability to adapt both upstream and downstream, to changes in the workflow. So, to use Pypeserver as an example it's very common for somebody to get Pypeserver, to connect their CAD system to their pipe profiler.
And then they want to get into BIM. And so what do they do? They bring in Revit or they bring in another BIM solution. And in that instance, it's very easy for them to connect Pypeserver to this new solution. And in fact, keep it connected to both through the transition period.
We just flip the switch and allow them to use whatever design solution they want upstream of Pypeserver, and they can bounce back and forth at their whim. And then once they've done their full transition, they can cut off the old solution and the same thing goes on the backside of Pypeserver. on the machine side, it's not at all uncommon for somebody to, decide to upgrade a pipe cutting machine or move to a different brand, or what have you. And the challenges associated with that are traditionally that these machines work differently. There's a whole retraining process involved.
But if you have a, in this case, the point solution Pypeserver, That has the ability to adapt upstream and down, you take a lot of friction out of that transition. And I would argue that if all of the point solutions that you are collecting together for your workflow have similar characteristics that is, a high degree of flexibility, upstream and downstream, it takes the burden of integrating and learning and using these these various point solutions, and lowers it tremendously. And gives you the flexibility to evolve your workflow without a lot of friction and difficulty.
Hugh Seaton: [00:06:26] So, what you're saying is some of the very same things that make marketplaces in platforms work, can also be applied from within a point solution. You don't need to connect to a big platform to get some of the same benefits where you're saying, when we're working with APIs, we're working with integrations that don't need to be a massive platform to still do what they do. Is that what I'm hearing is that you built it so that things coming in and things coming out are whether it's your data model, whether it's the way your integrations are architected that you've built, so that you're flexible on the in and the out. As if you were a marketplace.
David Basiji: [00:07:05] That's right. You know if the workflow consists of a series of point solutions, each of which is very flexible in terms of how it connects upstream and down and across, then, you can optimize each step of the workflow with each of those point solutions and get something that's really best in breed or, and/or, designed most closely with how you like to work. And so you don't have to take what amounts to a one size fits all, or a few sizes fit all platform solution. You can craft your own locally optimized workflow where every point solution works the way you want it to do to work and connects up seamlessly, to all the other solutions you're pulling together.
Of course part of the definition of an optimal point solution in that scenario is it has to have that flexibility, that ability to adapt to the changing surroundings.
Hugh Seaton: [00:08:05] And as you think about, without getting too deep into the technology, We kind of have to a little though, is what do you do to make that true?
You know what I mean? Like, if you think about the construction of a software product, what in there did you need to think about to make sure that that's true? Cause you're asking it... so it's one thing to build a connector, but it has to be useful once it gets inside of your system. So you have to also be kind of flexible from, from end-to-end right. All the way down to your data model.
David Basiji: [00:08:37] That's right. So an example here would be sort of how Pypeserver evolved. So the company was founded in 2010 and, BIM was not widespread at that point and everything was pretty much done in CAD. And so the connection methodology between Pypeserver and the upstream design tools was pretty much exclusively file export from CAD and then importing those files into Pypeserver. And so it's, basically a two-step process. There's a manual export, and then a manual import. And that's really not that much of a burden in and of itself, but it does lack a number of things.
For one thing, a lot of the standard file formats,that CAD can export were not information complete for pipe production. So even PCF - PCF stands for piping component file. You would think it would have everything you need in it to cut a piece of pipe, but it doesn't. And so for instance, wall thickness is, is not necessarily in there. The unique part IDs from CAD are not necessarily in there.
So if you look at other formats, all hell breaks loose. I mean, a step file can encapsulate anything you draw in CAD, but how you draw it matters a lot. If you have an inside a wall of a pipe and an outside wall of a pipe, and you connect them with lines in various ways it can become ambiguous as to which is which, and so when you export that as a step file, and then you pull it into a step file importer in any program, not just Pypeserver, it can really choke, and it comes down to the skill of the operator, knowing where the landmines are and so on.
So that actually forced Pypeserver to create our own, currently proprietary file format, that is information complete. And what we do is we provide a data contract that our developer partners at the other software companies that we work with use to essentially create a dedicated Pypeserver export file format.
And at some point in the future, I think it's very likely we will try to turn that into an industry open standard. But for the moment it's not mostly because the file format is still evolving and we don't want to publish it until it's highly stable. But that was how we started out.
And now we've gone all the way with certain partners, like GTP with their Stratos product, Msuite with fab pro. And we're moving this way with others is a full API integration not just to get the information into Pypeserver that we need to cut pipe and other things, but also cut status, cut times, other productivity metrics that we can send back up.
So you have full closed loop feedback control over your workflow. And that's really where we want to be at the end of the day is a seamless, not just a connection from design down to fab. But also from fab back up, so that the workflows can be optimized.
Hugh Seaton: [00:11:53] I want to get back to that cause that's a cool idea, but I want to stick to this, this kind of commitment to being a well-crafted open point solution because you know, earlier on I mentioned, or we talked about how it's about architecture and approach, but there's another piece you just got out and that is you're committed to it at the feature level. Cause you had to go and build extra things and kind of complete the service so that it, it was really allow enable to do what you're describing.
You know what I'm saying is, is that it was. An approach that you took it. Wasn't just, we all, we figured that out early, then we went ahead and executed, but along the way, you were problem solving to make sure that that's true. Is that right?
David Basiji: [00:12:35] Yeah. And still are quite frankly, there's, there's you know, there all the API out there are of different levels of maturity.
They're evolving. And so there's, there's just a lot of pick and shovel maintenance work involved in not just building these things, but keeping them working well and, and having them get better over time. And so you know, this it's, it's a it, I guess I would call it a akin to pouring money into the foundation of the building.
You know, you, you won't see it, but the building's going to be more robust and you know, if there's an earthquake, you may be able to tolerate another point on the Richter scale than you otherwise would have, because you've made that investment, not just one time, but ongoing. And so it does take a lot of work.
We devote a lot of resources to code maintenance and upkeep particularly in, in the area of, of interfacing with, with partner software companies. But it's worth it because ultimately. It's what differentiates us in the marketplace. It's it's what, it's what delivers a much much better customer experience. Now the challenge of course is, is convincing the customer, the value of this but, but I think as soon as somebody gets Pypeserver in their shop and makes a change their workflow down the road you know, if they didn't realize it before that light bulb turns on nice and bright because they they call us up and they say, oh my God, we're, we're going from you know, CAD to BIM and you know, our, our whole world is upside down in this transition.
And and you're you're step 58 of a hundred steps of, of trying to manage this thing. What do we gotta do? And we say, well we just did it. We logged into your machine. We enabled the license for, for this new connection. And you're good to go. And let us know when you want to kill the old one when your transitions complete, and we'll take care of that as literally two phone calls.
And that's when they exhale and say, okay, now I get it. I get what you guys are.
Hugh Seaton: [00:14:35] You've made a friend for life. I love that idea and it it reminds me of when we talk about in the software development process grooming, right. This idea that you're constantly investing time and effort and obviously resources. In, in rounding things out and making sure that they work all the way all the way down. Very, very cool. And again, the reason I harp on that is this, this interesting perspective you're bringing that a lot of the same thinking that goes into constructing a platforms marketplace like Salesforce and Procor does this and Autodesk is doing some of that as well.
You can apply to it to a company that is more focused, whether you call it a point solution or just a focused company, that's really, really owning a process or set of processes. And I've really attracted to this idea that, that you can think from the other angle and say, we're not going to be a marketplace per se, but we're are going to architect and then work to support the idea that we are, are open to a lot of inputs and we are open to as many outputs as are reasonably needed.
And I really liked that idea because I think in today's world of, of APIs and the ability to translate from one standard to another or from one file format to another, to some degree, depending on what it is.
It really opens up the possibility that you can work with lots of different companies and lots of different upstream and downstream point solutions. Really interesting.
Yeah. And
David Basiji: [00:15:58] I think it's, I think it's, it's actually essential at this point in time for the industry we're, we're in this huge state of transition and I'm not talking about the COVID driven changes, although that applies to, but just the, the shift to BIM the, the the shift to collaborative robots, the shift to a cloud connected field force you know, all of these all of these changes in. In workflow and tools that are used to to construct the world around us. All these things are in flux right now, and you, you, you really need to maintain flexibility and, and not lock yourself in it. You know, I would argue to to a given platform. Unless it really, you really do your diligence and you determine upfront with certainty that it's going to do what you need it to do.
Because, because our, our, our context is so dynamic right now in the industry that. As new things come out, new tools come out. You know, the, the user really needs to be able to, to try and and play with things. And if all of these tools are designed to make it easy, to connect to their partners in the workflow then you know, we all work towards a a a much more optimal workflow solution in the end.
And it's probably a collection of solutions there it's natural in any over time in a circumstance like this, that there will be a Fe a few a best of breed tools for any given job or any given task in the workflow that will rise to the surface.
But that takes time and it's, it's not always, in fact, Usually isn't the first one to market. So you have to provide this flexibility to your customers to, to be able to try different things that in the, in the context that surrounds your own product. And if you, if you prevent them from doing that, then you know, I would argue you're you're, you're doing your customer decision.
Hugh Seaton: [00:18:00] And at the end of the day, we're all in the game to, to stick with relationships and have long-term partnerships with, with our customers. So the more, the more you're you're allowing what you're talking about, the more likely they are to, to hang on which I think is absolutely critical.
David Basiji: [00:18:14] Yeah. It's you know, I think people like to work with solutions that. You know, the take their best interests to heart.
Hugh Seaton: [00:18:25] I really liked that. Okay. I want to come back to a point that you mentioned earlier, cause it's really cool. This idea of closed loop workflows. Talk to me a little bit about what you mean by that and how you guys have figured out how to do that, or at least begun to figure out how to do that.
David Basiji: [00:18:39] So you know, I'm an engineer by training and and I, I have never designed a system that, that, that worked for a damn if pardon my, my language, but If it was open-loop meaning that you, you, there's a, whether it's a computer or some upstream component, a good example would be, would be motion control.
So if you have a stepper motor. And that you're trying to use to, to move something. Most stepper motor implementations are what's called open loop. You tell the motor, I want you to move this many steps, which corresponds to a certain distance or a certain angle, or what have you. And you take it on faith that the motor's going to do it.
But if there's some unusual load that exceeds the motor's capacity, or if you made a mistake and you told it to accelerate too fast, it'll do what's called losing steps. It'll it'll think it moves, but it didn't actually move. And so and you have no way of knowing it. All you did was throw the order over the wall and hope it was completed to your satisfaction.
So with, with closed loop Control you, you put an encoder on the back of that stepper motor or servo motor or, or whatever it is that your actuator consists of. And it verifies that, that it did what you wanted it to do. And there's usually enough local control that, that if it didn't accomplish what you told it to do there's a, there's a subsystem that makes sure it keeps going until it's done.
Hugh Seaton: [00:20:08] A thermometer like feedback, when you say a closed loop, just an analogy people might use as you're talking about the way a thermometer might work, but in this case with physical things moving.
David Basiji: [00:20:18] That's right. And so. Closed look feedback control in in an engineering sense is a far more robust solution because you, you can see what's happened and and you can provide subsystems that ensure that it will happen to a much greater degree than, than an open loop system.
And it's exactly the same in, in more abstract situations like a fabrication workflow. You, you can send orders to the shop to say, make this stuff. But if you're not taking into account that a machine is down or that it's over-scheduled, or that you got a couple people on break or on vacation or sick, or you know, the, you don't have the inventory on hand to to make the, the, the product that you want to make the raw materials. You're blind. You don't, you don't know what's going on and your, your process is not going to work unless you are very, very lucky and everything is humming along as you hoped it was. Whereas if you have visibility on, on in, in our case pipe inventory, if you have visibility on the Available unscheduled time for the machine.
If you know that the machine is, is, is currently able to run and not down for maintenance you can account for all that in your scheduling and your, and your you know, your, your dispatch of the work. And so and this is true all the way through the process. So you know, we want to.
You know, at its lowest level, what we want to do is send back upstream the basic status information you told me to, to get this part cut. And we got it cut. Or there was a you know, that part has been nested on a pipe, meaning it's, it's sort of fit virtually with a bunch of other parts that are all going to be cut from that same piece of pipe, but it actually hasn't been loaded on the machine yet, or it was.
But there was something wrong. And and so we scrapped it so that one needs to be needs to be redone or a change order came down. You know, has that part already been cut? You know, or can we catch it in time and yeah. If it has already been cut, maybe the folks upstream office can say, you know what?
Because that part's already been cut. Let's not change that one. Let's change its neighbor, which hasn't been cut yet. That'll be a much less painful change, change order then scrapping what we just made and remaking it. So. Status is, is very, very important. It's sort of the lowest level of feedback, but you know, there's also how much time was spent on this who was operating the machine when this occurred.
If you're cutting a hundred identical parts over the course of a week, And an operator a can get it all done in a in a day and a half. But operator B took three days to do the same amount. Well, maybe you got a training issue that you need to jump on or or something similar.
And so it having. That feedback, that information backup stream gives you the ability to you know, th there's the old saying that which gets measured gets fixed. It gives you the ability to measure what's going on and determine if there's a problem even even a mild one and optimize around it.
And so how are you, one of the things that comes you hear a lot of is that you know, teams don't have the time. Two or crews don't have the time to sit down and reflect on how they're doing. So improvement is often difficult because they're onto the next job. As soon as the last one isn't even finished yet.
How are you, how do you see what you just described helping to, to square that circle, right. Is helping people to, to improve their teams and learn in a, because they're getting information from you or because they're getting it digitally, therefore probably faster and a little easier to, to process That can happen a number of different ways.
And it depends a lot on the culture of the organization you know, in, in in some organizations You know, the it's a, it's a, there's a lot of healthy communication going on. And you know, people have their eye on the, on the, the, the greater goal of, of, Hey, let's, let's get this, this organization or this shop running like a well-oiled machine.
And and if, if somebody taking longer to do a given task than somebody else, who's doing the same task and they have a covalence amount of experience, or even if not, In a, in a, in a. A well-functioning culture people will, will, will not be threatened by that information. And they'll say, Hey you know, can I get better?
And why is my coworker over here so much faster than I am at this, are they, maintaining the same level of quality as I am. Maybe there's a trade off there and maybe speed is not the best figure of merit, for what we're doing, maybe we should also be looking at, at you know, quality, how much, if my cuts are better than my coworkers cuts, even if they take longer that's going to save the welder downstream for me a lot of time in, in grinding and filling and fit up.
And so maybe, maybe you could argue one way or the other as to what's the best way to measure, but in a, in a, in a. A very healthy organization. People are using the information as a means for self-improvement and organizational improvement in, in other situations maybe you know, you don't have that sort of peer to peer collaborative culture and maybe it falls on upstream to sort of monitor these things and then have a conversation if necessary to say I'm seeing this you know, why is this? And again, in a ideally in a non-threatening manner where, where everybody's sort of saying, okay, we're seeing this thing, on its face it looks like a problem. We're not sure it is a problem. Let's, let's dive in and figure out what's going on and explain these differences. It really comes down to how do you explain the differences? And if the explanation is that there's a problem, then you can go fix the problem. But very often the explanation is it's not a problem, what we thought it might be, but it's not actually a problem.
And it exposes a different aspect of the, of the workflow that actually might be a problem that you weren't even thinking of. So that's really the value of the information and how it it's acted upon varies from organization to organization, but without the information it's hopeless, you don't even know what's going on. You're flying blind.
If you've got the information, at least it can be used potentially in a positive way.
Hugh Seaton: [00:26:51] And this I'll kind of bring it home with this observation that as more and more data gets produced on job sites from products like yours, that kind of go into a job site. But, but the, the process of building a building is increasingly producing digital data, not just paper, but things you can do something with.
I think you're going to find that, that reliance on data to make decisions, lends people to what you just described, where people will ask questions, because they know that they're going to find the answer, not with an argument or with an opinion, but with a graph or something that is more or less in arguable that like, okay, I get that this is better than that was because look, we have data to show it. Not because I'm louder than you, or I'm more experienced than you or I own the company.
David Basiji: [00:27:37] Right. Right. And I think actually it's you know, it's interesting. You know, you, you have a lot of expertise on, on AI and, and how AI might be applied is, and might be applied in the future in, in construction.
And I, I'm a firm believer that there's a lot to be gained from that. But it's also true, I think in general, that, that AI and machine learning requires a tremendous amount of data and probably more than most organizations, especially small organizations are in a position to generate themselves.
And what we found is that there really is sort of an 80 20 rule here with, with with information coming back up that, that those first key pieces of status and efficiency data that, that you, that you build in really gets you a huge amount of benefit. You do not need to bring AI on board.
You do not need years and years and hundreds of projects worth of, of background data to, to train a machine learning algorithm to A lot of benefit from that, that feedback control that the just, just getting the first few steps taken, we'll give you a tremendous amount of value. And then the the as, as the amount of data builds up and you bring these, these more sophisticated tools, like, like AI and machine learning to bear, there's going to be a lot more what it's going to do is it's going to lower the fruit, right?
There'll be a lot more gain. There's there. People are often shocked. I think in my experience with, with how much benefit you get with just some basic feedback.
Hugh Seaton: [00:29:13] I love that and this is why statisticians will often tell you, first thing you do is graph the data because to your point. Very often, there is some very low hanging fruit and very often you don't need a ton of data to make a lot of progress.
And I also think your point is, is a good one about AI and machine learning in that most people who you throw those words around a lot, haven't had to go build something and haven't spent the time it takes to massage data so that it'll... you know, I mean, if you need to put a hundred thousand data points through a model to train it, somebody has to make a hundred thousand rows of a spreadsheet, basically work so that they can add up you can do math against them and that's, that's just.
Of course you can do it, but it's a lot harder than people think. And to the point you made, you can get a lot done with, with math and a graph.
David Basiji: [00:30:04] Yep, absolutely. Absolutely.
Hugh Seaton: [00:30:06] David this has been fantastic. I really enjoyed this. Thanks for coming on the podcast.
David Basiji: [00:30:10] Oh my pleasure.