Functional testing is when you power up an electronic device for the first time and then perform voltage rail checks and programming of processors, and more. And this is exactly what FixturFab offers their customer.
In this episode, Zach is talking with the co-founders of FixturFab, Duncan Lowder and Joe Selvik. They will have a chat about automated test fixtures and turnkey systems that aid low to medium electronic production to deliver successful devices.
Listen to Podcast:
Download this episode (right-click and save)
Watch the Video:
Show Highlights:
Links and Resources:
Connect with Joe Selvik on LinkedIn
Connect with
Duncan Lowder on LinkedIn
Visit FixturFab website
Read: Generating an Altium Test Point Report
Watch related episodes:
Electronics Manufacturability and Reliability with QA Guru Cheryl Tulkoff
Mitigating Risk Factors for PCB Manufacturing Lead Times
Get Your First Month of Altium Designer® for FREE
Duncan Lowder:
Yeah, so it kind of covers all three tiers of mechanical, electrical, and software engineering to kind of build these fairly complicated fixtures that are used on the line.
Jow Selvik:
The word fixtures actually really interesting is because I come from a software background and when writing unit tests or an integration test, you'll commonly also have a test fixture, but in software that's like the right interface to your test database or whatever interfaces you're using to kind of probe it for the right functionality. But for testing hardware, we're developing a fixture also, but in this case, it's a physical device.
Zach Peterson:
Hello everyone and welcome to the Altium On Track podcast. I'm your host Zach Peterson. Today we are talking with Duncan Lowder and Joe Selvik, co-founders of FixturFab. FixturFab is a very interesting platform that I stumbled upon while on LinkedIn and they do automated PCBA test fixtures. It's a very interesting concept and I'm very excited to talk to them both Duncan and Joe, thank you so much for joining us today.
Duncan Lowder:
Thanks for having us.
Jow Selvik:
Yeah, thank you.
Zach Peterson:
Absolutely. So I guess before we get started, maybe if you could give our audience a bit better idea of your background and how you guys came to start FixturFab. I think that would be very helpful.
Duncan Lowder:
Yeah, so I originally graduated from the University of Colorado at Boulder with a degree in electrical engineering and kind of immediately went into the field of test engineering at a couple different consumer electronics startups. And during that entire time I was just always getting annoyed with the process of designing these bed of nails test fixtures. It's just always tedious and you're kind of doing the same thing, just placing a bunch of holes in flat plates and I wanted to find a better way to go about it. So I started writing a little bit of software, came up with a MVP and was able to prove out the concept of making a automated test fixture design. And that's when I kind of showed it to Joe, who I'd met at a college, at my first job out of college
Jow Selvik:
I went to the University of Minnesota for computer engineering and I moved to Boulder eventually for a job at Seagate. And that's where I bet Duncan, we always kind of bonded over wanting to run our own company someday. So I think it was Thanksgiving 2018, Duncan kind of was telling me about the idea and I started officially poking around the GitLab repositories and that's pretty much where my involvement started about four years ago.
Zach Peterson:
Interesting stuff always comes out of a GitHub or GitLab repository, doesn't it?
Duncan Lowder:
Yep.
Zach Peterson:
So Duncan, when you say test engineer, I think for some folks who work at OEMs or they work at larger companies or maybe even some engineering consultancies, test engineering can mean a lot of things. And when you talk about a test fixture, what specifically is this for? Is this just for in circuit testing? Can it be for anything? Give us maybe a broader sense of what can be done with your guys' project.
Duncan Lowder:
Yeah, so what we focus on in particular at FixturFab are functional test fixtures. So these are bed of nails style fixtures that are on the manufacturing line and they typically perform the test of a PCB. It's the first powered up test of that circuit board. So like ICT testing and circuit testing will typically occur right before this step. And then functional testing is kind of the first time you'll actually apply power to the device and have it turn on and then do any kind of voltage rail checks and programming of processors, et cetera. So it's kind of like the first time the board has actually been powered up and given life.
Zach Peterson:
And so when you build this text fixture, what is it you're interfacing with? Maybe make this a little more tangible for us. Is it interfacing with whatever test equipment you have in the lab? Is this meant to go into something on the line?
Duncan Lowder:
So these are typically meant to go on the manufacturing line and we like these fixtures will have a bunch of spring loaded pens called pogo pens to meet with test points that are designed onto the circuit board. And so these will give access to the nets that you want to take measurements on or provide input to. And then to take those measurements, we'll integrate or connect those test points to various instrumentations. So this could be kind of DMMs like multimeters or to power supplies, programmers, et cetera, kind of any piece of instrumentation that you need to take a measurement or perform an action on the device that you're testing.
Zach Peterson:
So maybe as an example, if I had a board and it needed a bit more in depth functional testing than just power on and maybe check a data stream, maybe there's an analog sensor on it or something and I need to check that the analog sensor is reading out with maybe a spec that I require for that particular device. Can I take the output, maybe bring it over to an oscilloscope or maybe to a data logger or something like this?
Duncan Lowder:
Yep, exactly. So you can take this panini press looking device, which is the bed of nails test fixture and connect that to your oscilloscope or multimeter or dak and then you can write some software that can automate those measurements and kind of upload that data to a database to provide insights into your manufacturing kind of yield. We like to divide the mini or these functional test fixtures into three different kind of columns of engineering work. There's the mechanical design of the fixtures, so this is the physical bed of nails or panini press. There's the electronics and instrumentation integration, so this is selecting the multimeters a oscilloscopes, power supplies, et cetera. And then there's the automated test software side where these are the test scripts that will go through and turn on the power supply me voltages and then collect all of the pass fail data from that device that you're testing. So it kind of covers all three tiers of mechanical, electrical and software engineering to build these fairly complicated fixtures that are use on the line.
Jow Selvik:
The word fixtures actually really interesting this because I come from a software background and when writing unit tests or integration test, you'll commonly also have a test fixture, but in software that's like the right interface to your test database or whatever interfaces you're using to probe it for the right functionality. But for testing hardware, we're developing a fixture also, but in this case it's a physical device. So we're in software, there's all sorts of fantastic tools for testing software because it's software is a little bit easier to write these test fixtures in. For hardware itself, you still need a test fixture a lot of times to implement the tests that are efficient. But in this case we also have to design and manufacture almost a custom product itself to test the physical product.
Zach Peterson:
When you bring up the fixture, I think everyone focuses on the physical part of it, which most people are going to be familiar with, like you said, bed of nails and then they'll see the pins flying around and especially if it's an automated system that's in a production facility, but the software side of it that automates and collects the data and then maybe does some processing and has to do some math or whatever, I think people maybe find that a bit more esoteric because you can't see it, feel it, touch it's all code.
Jow Selvik:
And that's where as two engineers who built a company here gets really exciting because we're integrating software that's running this physical test instrumentation, it's interacting with the devices and controlling them, powering on the device and taking measurements on it. And you're kind of orchestrating that all on the test software. So you need to know are you physically contacting everything the right way and then you need to know what is the interface to each of these physical test devices that you're using to test the hardware. And then the software has to pay attention to all of that at once and tie it together in a complete kind of turnkey system.
Zach Peterson:
You actually have on your website an option for turnkey systems or turnkey test systems as you guys call it. So you've described as a modular functional test system. So I mean can you break that down a little bit more? What that looks like for somebody who's considering or know that knows that they needs this kind of test fixture and then automated testing system to either work with a complex board or to then get into volume production.
Duncan Lowder:
So let's use just a simple internet of things like sensor, say it's a wifi connected thermometer or something like that. So if you were to go to manufacture this device, you'd want to test the circuit board that goes into that sensor prior to it actually being assembled into its kind of enclosure. So to do that you'd need to build a mechanical fixture that can kind of hold the circuit board in the right spot so that all the pogo pins can connect to it and take those measurements. For measuring voltage rail program processor, we need to connect a power supply a programmer and then we need to write all of the tests software to actually do that work. And so for a full turnkey system from us, we would dive into detail with how exactly have you designed your circuit board, take a look at the schematic, help you develop a test specification for exactly what test cases need to be covered.
And this is just a lot of data gathering. We basically have to become experts on every single circuit board that we're implementing these turnkey systems for. So it's a lot of kind of work and in-depth engineering knowledge that needs to come together to be able to design a turnkey system. And so what we've started doing is instead of doing these complete complicated turnkey systems where we're figuring out all of these custom features for everyone's circuit board, we can now kind of do a partial turnkey system where if we're doing a basic implementation and then help teach our customers how to actually finish writing that test software because as you mentioned it is kind of this hidden magic that makes these automated systems work. And so we're trying to help give design engineers the tools needed to build their manufacturing kind of pipeline, manufacturing test pipeline versus having to create everything from scratch.
When I was working at Spiro, that was kind of my first job that I really got into really deep into the manufacturing test world as far as circuit boards go. And there it's like we ended up writing our own custom test framework. Typically I see LabVIEW and Test Stand a lot out on the line and then if it's not LabVIEW or Test Stand, it's some custom test suite. So whether that's written in C Sharp or Python, everyone has their own approach to doing it. And so I love Python personally, so I'm a Python guy, so that's kind of how I've gone about implementing all my test software and that's kind of how we've built out our systems. So we have a proven way to approach these test software and these turnkey systems. Now we're trying to take our internal tools and get them to a state where we can help other engineers kind of build test systems for their products.
And when we say modular, the way we actually structure our test suites for these hardware products is we actually very closely follow PIE test and Python. It's actually a PIE test plugin that's writing unit tests, but instead of writing unit tests for just a piece of software, you now have a interface that you know how to communicate with an actual physical device that is mounting that circuit board, that device under test. And for our hardware test suites, we just write unit tests sort of that are actually functionally testing the hardware itself. So a lot of times when you're testing hardware you have to test 80% of the same kind of things, can you power it on test for shorts? And then you see a pretty good example on how are you actually sending these signals to the device and measuring them in the right way. We're hoping that you can just build off of that for the more complicated edge cases that you're trying to test then for each specific device.
Zach Peterson:
When you say modular and you were talking about the software before you even said it, my mind went to LabVIEW. So my first experience with View was with environmental systems and having to basically synchronize measurements from a bunch of sensors, but it certainly wasn't in the area of test and measurement, but I would see LabVIEW as being something that is modular has been described, but also it's graphical. You don't have to be a polyglot programmer to be able to drag some wires between different things in the program. So where do you guys offer an advantage over something like LabVIEW?
Duncan Lowder:
It's mostly just a different approach to test. As we've been talking with a bunch of different companies and in particular kind of newer startups like hardware startups, a lot of their electrical engineering talent and stuff wasn't really brought up using LabVIEW and test stand and they're more familiar with programming tools such as Python and they're not as afraid of using Linux and the command command line, et cetera. And so it's just kind of trying to provide additional tools. So it's like, "Hey, if you don't want to use LabVIEW and have to buy a license, what is there to help develop these tests?" And there are some other kind of hardware centric test frameworks out there, but currently I think it's open HTF. It's a Python based hardware test framework that some Google engineers published a while ago. And so that's another approach. But we currently like the PIE test.
Zach Peterson:
That's a good point. You're actually hitting the target market directly with what they know rather than forcing them to buy a license to something that they might only ever use just for testing something coming off the line and that's it.
Duncan Lowder:
And there is no perfect one size fits all approach to hardware test and it's like if you know how to use LabVIEW, it's a great tool and you can move pretty quickly with it. In my experience, I only had to use it once, but I've never was taught how to use LabVIEW, so it ended up just being a miserable, complicated rats' nest, which I put on myself. I definitely didn't know the right approach to actually implement it correctly, but that was like I grew up or learned how to program and just embrace Python and so far a lot of the people we've been talking to as far and have sold systems who have had a similar approach.
Zach Peterson:
Do you guys give out the source code too? So if somebody needed to, they could take this and implement something else on top of some other feature on top of what the test system already does?
Duncan Lowder:
Yeah, exactly. And it's like we want our customers to be able to take what we give them initially and then be able to either update it when new firmer images coming come out or say they have to roll the board and change some parts due to all the supply chain issues we currently see. We want them to be fully enabled to actually make those changes. And then another thing we've been doing is using kind of IIOT device deployment engine called Bolina. And so this allows us to actually manage our test fixtures remotely as long as we can get network access for them so we can roll out updates to an entire fleet of testers versus just having to have someone manually run around the factory floor with the USB key and update systems here and there. And yeah,
Zach Peterson:
That's really cool. I wouldn't have even thought about having the need to do that, but yeah, that's really interesting
Duncan Lowder:
And it's one of the more interesting areas with manufacturing tests, at least to me currently, network access on a factory floor is typically a no-go, very much a scary thing as specifically access outwards, to the internet from inside the factory. A couple of the hardware companies I worked at, we were able to get VPNs set up, but that was typically after just dragging the CM kicking and screening, screaming across the floor. It was always a very hard process to actually get implemented. So that kind of is an issue with this kind of remote update approach. So depending on the factory that these fixtures are deployed at, it's either easy or very difficult to actually perform those updates, but at least there's a traceable kind of commit inversion and you know what fixture's running what software.
Zach Peterson:
That's almost a little surprising that network access is not as ubiquitous as the four letter word IIOT or I guess acronym would imply because the second I in IIOT is internet and it implies that, "Oh, your factory can be connected to the internet and maybe there's a remote command center somewhere and it's taking in all the factory data and handling all the updates and things like this for your entire facility." And it's kind of that next push towards automation. And it sounds like this can fall within that, but I guess I would've just expected that somebody somewhere can just push a button and the update gets pushed to all those devices and the same would apply to your fixtures.
Duncan Lowder:
And I'm surprised as well and it kind of puts it at the point I'm kind of wondering if there's just something I don't know or if we're haven't been talking with the right people at these manufacturers because all of their machines are definitely talking with each other, data is getting stored in a central database, it's just access to that from a customer standpoint. So it's like they have a customer who's manufacturing one device at that factory and then they have another customer and guarantee both of those customers have completely different requirements for how they want to handle where their data goes. So I can definitely see it being super complicated, but it's been a pretty common occurrence with dealing with our own customers who are the customers of the CM, kind of getting, how do you get data in and out of a factory via the internet and what does opening up their kind of intranet look like? So I don't know if anyone knows more info about this, we would love to talk. I definitely want to learn more about how it works.
Zach Peterson:
Well then how about we throw your LinkedIn profile into the show notes?
Duncan Lowder:
That would be awesome.
Zach Peterson:
Cool, cool. Well yeah, hopefully someone's out there listening can provide some more insight. That's always cool that we can connect people through the podcast.
Duncan Lowder:
Yep.
Zach Peterson:
So you brought up a couple things which I think relates to another question that I had. It seems like just a moment ago you said that a CM had to implement one of these fixtures, but then you had mentioned that it was a customer of a CM that actually comes to you guys. So what does that journey look like for someone who is a customer and I guess really who is the customer that is actually going to engage with your company and then get these test fixtures built and then deployed in the factory or in the production line?
Jow Selvik:
So our customers are pretty much anyone who designs their own hardware or manufactures their hardware. And our ideal customer is someone who comes to us still in the initial or close not, they haven't finalized their board layout yet because there's a lot of simple design for test changes we can recommend to them upfront that makes writing a physical functional test fixture a lot easier, single-sided probing, making sure you have enough space and clearance with all your test points, making sure you have a test point at every single net that you'll need access to if you want to automate the testing of it. And then to kind of help with this problem, we actually designed what's called our development fixtures, and these are just, they're quick, they're laser cut and we want to get these to the customers really quickly in one to two weeks so they can use these to start testing their low volumes and prototype runs because the board layout is going to change, and if you're changing this on the manufacturing floor after you have a physical system, a production fixture that's meant to test millions of units, it's a lot more expensive to change the board layout because they need to change the test system itself.
So a lot of our customers who we really like to work with will come to us in this prototyping phase and we'll work with them and if the board layout changes as they define their functional test or the product requirements changes on their end, we can quickly adapt the development fixtures for them. So that way when they're going to manufacturing, they kind of already have started developing the test system alongside of their product itself. And that kind of has led to a pretty interesting pattern is a lot of times they're buying several replicas of the same physical system, one for their lab on site that they can use to continue testing and developing their hardware, but then also they're bringing their own test systems to the manufacturing floor that they're already familiar with too.
Zach Peterson:
That's interesting that you bring this collaboration up between the test fixture and the layout engineer because modern engineering has gotten desiloed. There's all these collaboration tools out there between different domains and certainly I think the firmware and the embedded guys have been left behind a little bit, but that's catching up pretty quick. And then one area that I think has definitely gotten left behind is designing the board for a test fixture you guys are talking about, it's one thing to design for test, which would be doing things like you mentioned exposing test points and things like that, but now to actually automate that testing is kind of the next level of that collaboration between layout engineer and test engineer.
Duncan Lowder:
Yeah, exactly. And as we see it's like it's more of a partnership versus customer supplier relationship when it comes to getting a test fix. We have to work closely together to make sure that we're going to provide the PCB designer with a fixture that will actually work with their board and it is a back and forth road because it's little design decisions can make it much, much easier to make a very robust fixture. Whereas if someone just designs a board and goes like, "Oh, Altium lets us choose everything as a test point," click.
Zach Peterson:
I will admit I have been guilty of hitting control A and then setting everything to an assembly test point. So my bad.
Duncan Lowder:
I did it too. It's kind of funny when all of a sudden we're like, "Wait, that's a tiny little pad." So yeah.
Zach Peterson:
So it sounds like you guys are actually getting into the layout files somewhere maybe halfway to three quarters of the way through during maybe the routing phase of the design.
Duncan Lowder:
So we'll typically, as Joe mentioned, we want to try and be engaged with them as they're getting close to their first kind of EVT build, so engineering validation testing build. So it's like there's still time to make changes to the layout prior to their EVT build and their initial production run. So when we ask for files, we'll typically ask for kind of a test point report, so that can be exported directly from Altium or manually created from other tools. And then we typically want Gerber's ODB plus plus or IPC 2581 files and this allows us to actually view where all the test points are on it, check where component locations, courtyards, et cetera, just to make sure we aren't going to have any interference from the fixturing side as far as locating the board using tooling holes, pushing down on the board using pressure pins and making sure we won't kind of apply any stress that'll pop off BGA components or passes.
And then we'll also ask for a step model just to try and do some component or at least fit checks to make sure there aren't any mechanical interferences. And the step model actually brings up a funny thing. It's like if you can have detailed 3D models in your circuit board designs, please please make them detailed. We still get a bunch of 3D models where it's just blocks for each IC or component versus having an actual detailed step.
Zach Peterson:
That's fair, that's fair. So I guess that would allow you guys to really ensure that let's say a probe can get in at the right angle and actually access a lead instead of maybe, let's say it's like a QFN package. So it's basically a leadless package. You have to come in at the right angle, there has to be enough of the pad exposed in order for a probe to come in and then make contact with that particular test point. Is that one reasoning for doing all that?
Duncan Lowder:
So for art fixtures where it's just kind of static pogo pins that are just pointing straight up, since we've done a lot of the automation from the design aspect, getting these standardized files allow us to run it through our automated checks to kind of validate fit and just make sure that we can actually physically build the picture and it there's no issues. So if we have all of those files, it's super straightforward for us to run it through, identify any issues and bring them up with a designer. We don't need all those files, but it's definitely much faster and much easier if we have those three main things available. So 3D model, Gerbers or other manufacturing files, and then test point list.
Zach Peterson:
I see, I see. Okay. So you've also brought up, I guess two maybe types of customer two use cases. There's the prototyping engineering validation test and then there's production. And to me it sounds like these are really going to be two different types of fixtures, or at least the prototyping one is more likely to be modular, whereas the production fixture is maybe more custom. Is that a fair assessment or is there something?
Jow Selvik:
The main difference there is kind of lead time to actually manufacture the fixture itself. And then of course the cost. So using a laser cutter, it's actually very simple to just laser cut in holes in a plate. And the way we design them is they're pretty quick to assemble, but when you do something that's more robust for mass production, we're usually machining these and fiberglass or G 10 plates and that's a little bit more expensive to make sure that those test probes are not moving after several tens of thousands or millions of cycles. But there's an interesting pattern there that whether it's a quick laser cut development fixture or a machine production fixture, in the end it's just primarily a plate with a bunch of 2D holes drilled inside of it. So we can actually leverage the design that we already did for the development fixture and we know if the board layout's the same, whether that device under test is in a development fixture or a production fixture, the actual manufacturing is, there's a lot of similarities there that we can leverage basically streamline that testing process.
Zach Peterson:
I see, okay. So you can reuse part of the fixture design when you transition to production?
Jow Selvik:
Yeah, the requirements-
Duncan Lowder:
Go ahead.
Jow Selvik:
Yeah, it all comes gathering the right requirements up front knowing the coordinates of the test points that are available and how do we manufacture that depending on what kind of fixture best fits the requirements of the customer for when they need to test this. So if we have a solid golden set of test requirements for our customer, we can offer the right services at the right price point and lead time that we need to provide them that actual physical system, that custom product itself that is testing their circuit board.
Zach Peterson:
And then Duncan, did you have something to add to this?
Duncan Lowder:
No, nope. That's good.
Zach Peterson:
He hit all the points. Okay. Now the next question I have here is even though there's always been a drive for greater automation and the PCB industry is one that has, at least here in the US or North America more broadly, has lagged a little bit in automation, and I see what you guys doing as being part of that trend towards greater automation. And I think if we start to see more onshoring going to be more of a move to implement these automated systems, whether it's fab assembly or in this case test. So how do you guys interface or how do you see yourself interfacing in a factory where there is greater automation and you are probably not going to have someone picking out every single board loading it into a fixture by hand. Is there a possibility for you guys to integrate with higher levels of automation on an SMT line?
Duncan Lowder:
Yeah, so there's always the kind of ability to do that and eventually we would like to get there. We're still early enough in our journey as a business that we're not ready to approach those fully automated inline test systems. And again, which is our main supplier for the production level test fixtures, we purchase their base components and then customize them for our customer's devices, but they make inline fixtures that can kind of run along the conveyor belt, that circuit boards travel down or panels travel down during the assembly process.
Where we kind of provide the most value right now, at least to US based suppliers, is in that kind of low to medium volume production area. So think up to a hundred thousand devices a year, something like that, where it's enough quantity that you definitely want a production level test fixture, something that is capable of testing those hundreds of thousands of units that will go through over the course of the products lifetime, but you're not building enough that the amount of engineering required to do the fully automated line quite makes sense. So eventually we want to get there, but we don't have the experience right now to kind of do the fully automated test systems.
Zach Peterson:
Well then it also sounds like there's a little bit of an economics limitation because I'm sure the fully automated system carries of course greater cost and so it's only going to start to make sense maybe when someone is doing let's say a hundred thousand units a quarter. I'm just throwing out a number here.
Duncan Lowder:
Yeah, exactly. It's always, there's economics to this. If you're only building a thousand units and you need a million dollar test fixture, that doesn't make any sense at all. And what I find really kind of interesting and exciting about the onshoring of all the kind of electronics manufacturing again is over in China, there's this whole mom and pop test fixture industry and you know, go to any of the markets and you can find all of these little bake light PCB test fixtures. And I remember one of the companies I worked at, their approach to testing at that comp or at that factory was to literally just have a couple hundred test fixtures and when one broke, you just went on to the next one. That was their approach because they were just so cheap and easily replicated that they're just cool, whatever, just throw it out.
In the US we definitely have a different approach and my experience getting quotes as when I was working for companies was like, "Oh, it's 100 grand, $250,000 for these systems" and you have to have a strong business case to be able to spend that much money, especially on these lower volume kind of production runs. And so what we're trying to do is provide the tools so that if you're building 10,000 units in a year, like okay, you can't afford that a hundred thousand dollars system. Well maybe you can get a 10 or $15,000 system and then implement some of the software yourself and still get the same quality of test experience or at least help detect these failures that would leave the RMAs down the line or something like that without having to outlay all of this kind of cost. There is the whole completely automated level, but that's above where we're currently targeting as a customers or as a customer base.
Jow Selvik:
Quite specifically, we're focusing our design and our own automation efforts on designing the physical product itself to make that as effective and basically as fast as possible because a lot of times you need these right away to start testing those boards when they come into your facilities. And then if we do a good job designing these systems in an intelligent way, there's a lot of future features we can integrate inside of them, but we have found, at least with our customers, a lot of times they'll come to us as like, oh, thank God designing just the mechanical part has wasted hundreds of our hours. We just don't know the intricacies of that. So that's where we're really trying to focus right now is providing these physical test systems for our customers to use.
Zach Peterson:
Sounds like that's where the big value add for the modularity is in the mechanical side of it because if you have a mechanical platform that you can very easily machine and move things around, it's going to be much easier to get something out to the customer quickly so that they can cycle through whatever testing they need to do.
Jow Selvik:
Yes, exactly. And then going back to, I know we talked a lot about the modular components of our software and test system side, but the physical device itself, Ingen has a really smart approach that we really like where they have this fixture base plus cartridge system. So if we do a good job integrating the instrumentation inside of a fixture base, we could design it in a way that if the board layout changes, you don't need to throw out the full fixture itself. We could just quickly design a new cartridge itself that slots on end to the base that we already understand what its interface is, and then it's a lot quicker and cheaper to replace just the cartridge inside of the system itself.
Zach Peterson:
So when you say the cartridge, this is something that basically holds all the test probes in the right locations?
Jow Selvik:
Exactly. It's the actual plates that we're drilling those holes into that were placing those receptacles that hold the test probe inside of it because once you drill that hole, the hole's not moving. You need to get a new plate then if you messed that location up.
Zach Peterson:
I see. It's really the business end and it's not like you can just have kind of a 2D grid, almost like a perf board and then toss all these little probes on because there's no way they're going to be in the right spot. You really have to find some piece of it that is disposable if needed.
Jow Selvik:
Yes, you need to understand what you're trying to probe on that device under test itself and what are the coordinates of that test point? Is it like an S&D pad or a through hole? And that kind of dictates what kind of probe do you need to interface with it for a secure and sound and reliable electrical connection. And then you need to place that inside of the physical fixture itself too.
Zach Peterson:
Okay, now, yeah, very cool. Very cool. Yeah, I see a lot of value being created for folks here that need test fixtures, but dread getting into all of the mechanical and electrical portions of it that are going to be needed to do this successfully. I can even imagine the research that's going to be involved just to find what are all the components in one of these systems to be able to build it or instead they can just come to you guys.
Jow Selvik:
And that's a pattern that we've started to realize, especially now that we've been at this for four years, is a lot of testing requirements that we see we've handled and dealt with before. We have components and parts that we know will fit that solution well. And that's where we can really provide our expertise where a lot of times an engineer who comes to us was like, I've actually, the last time I designed a test fixture was five years ago and I just don't even know what parts I need to source for this. Oh, here's kind of our supported library of solutions. We think these ones are kind of best for your use case because we've seen this before.
Zach Peterson:
I see, I see. Okay, very cool. So I guess before we get closer to wrapping up, I would love to know what do you guys see happening in this space in the future and with FixturFab in the future?
Duncan Lowder:
Yeah, so our main driver this year is we want to get to what we've been calling a test system in a box or the minimum viable test system where it's my goal's less than 40 hours of engineering time, so less than 40 hours of NRE for designing the entire system. And what you get is a mechanical fixture that can hold your device that you're testing. The instrumentation is integrated and connected to all the test points, and then a kind of minimum functioning test suite where we'll do continuity bolted trail checks and program a processor. And our idea with that is that gives our customers a starting point to go on and or add all of their custom feature tests or device specific tests. So in the case of the temperature sensor going and talking to that temperature and sensor or calibrating it or whatever needs to be done for that. And so it's like we just want to get this kind of basic working functioning system to our customers as quickly as possible. And that's kind of like our driving vision for this year.
Zach Peterson:
The thought that just popped into my head was Ikea for test fixtures almost someone could get the box, they can put it together on their own wherever they need to put the probes, they can install it into the cartridge on their own, however it looks. And all they got to do is add in their test code into the code base. You guys can have a comment, insert your code here, and then they're up and running.
Duncan Lowder:
Yeah, exactly. It's like it's a mixture of a fix ... The vision is kind of like protolab for test fixtures, so it's like, okay, we want to make it as easy and quick as possible to get a mechanical fixture that'll work with your device. And we're very good at doing that mechanical part right now. And now we're working on building out kind of the instrumentation and the tech software side as well.
Zach Peterson:
That's very cool. That's very cool. Well, as it all develops, I'm going to be excited to see what that looks like. And with all of course, love the guy. Have you guys come back on in the future to discuss all this as time goes on?
Jow Selvik:
Yeah, we would love to.
Zach Peterson:
Yeah. Okay, great. Well, thank you so much both of you for joining us today on the podcast. For everyone that's out there listening, we've been talking with Duncan Lowder and Joe Selvik of FixturFab, both of them are founders of the company. You can learn more about FixturFab in the show notes and we'll have some links there. And of course you can connect with these guys on LinkedIn May. If you're watching on YouTube, make sure to hit that subscribe button, make sure to leave comment, and of course last but not least, don't stop learning, stay on track and we'll see you next time.