There comes a point in most device projects where opinions have to give way to measurements. You can model a part, review it and debate whether a clip will hold or a spring will deliver enough force, but eventually you need to put the part in a machine and find out, and in my experience the earlier that happens, the cheaper the answer is. We do quite a bit of this at MDIN, in our workshop near Bristol, so I wanted to write about how bench testing and custom test rigs actually fit into device development, and why I’d say they’re one of the most cost-effective de-risking tools available to a small device company.
What I mean by bench testing
Bench testing, as I use the term, covers the practical measurement work that runs alongside design: pulling on things, pushing on things, cycling them, holding them at load and seeing what gives. Early on it’s fairly informal, you’re asking questions like “does this luer connection stay on when I pull it with a realistic force” or “how much does this housing deflect before the latch releases”, and the answers feed straight back into the CAD. Later in a project the same physical tests get repeated in a much more controlled way, with written protocols and calibrated equipment, and at that point the results become design verification evidence. The kit and the thinking are the same throughout, which is rather the point, because a team that has been measuring since week one rarely gets a nasty surprise when formal verification comes around.
The kit we use
The workhorse in our workshop is a Mecmesin MultiTest 2.5-dV, a motorised force tester that applies tension or compression at a controlled, constant speed, measuring from a couple of newtons up to 2.5 kN. Constant speed matters more than people expect, because pulling something apart by hand tells you almost nothing repeatable, whereas a motorised stand gives you a proper force/displacement curve you can compare between iterations, materials and suppliers.
In practice that one machine covers a surprising range of device questions: pull-off and retention forces on connectors and fittings, activation and trigger forces on spring-driven mechanisms, break-loose and glide forces on syringe-type systems, compression behaviour of cushioning and support materials, peel and joint strength on bonded or welded assemblies. For a mechanical device, which is where MDIN focuses, that list covers most of what you’d want to know before committing to tooling.
Where custom rigs come in
The force tester on its own only gets you so far, because the interesting part is usually how you hold the device and how you represent whatever it interacts with. That’s where bespoke rigs and fixtures earn their keep, and it’s work we particularly enjoy: designing and printing or machining fixtures that present the device to the tester the way it would be loaded in real use, rather than in some convenient but unrepresentative way. The force tester also isn’t the only machine a rig can hang off, as some questions are about repetition rather than peak load, so we build rigs for cycling as well, actuating a mechanism hundreds or thousands of times to see what wears, loosens or drifts, which is the sort of thing you’d much rather learn from a rig running quietly in the corner of the workshop than from a returned device.
Sometimes that means a simple clamp arrangement, sometimes it means something closer to an anatomical form. On our custom wearable support device project, the geometry came from a 3D scan of the wearer, so the natural approach for testing was to build forms derived from that same scan data and load the device against them, which meant the numbers we measured actually related to the person the device was for. A rig like that typically costs a small fraction of what a single failed verification campaign costs, and once built it gets reused across every iteration.
We build rigs as part of our proof-of-concept and prototype builds, and also as standalone pieces of work for clients who have a device but no sensible way to test it.
How this de-risks development
The value shows up in a few practical ways. First, failures move earlier and get cheaper. A latch that releases at half the intended force is a mildly annoying Tuesday afternoon if you catch it on the bench in week three, whereas the same discovery made during formal verification, with tooled parts and a report that now has to say “fail”, tends to be an expensive one. Second, decisions get made on numbers rather than opinion, so when there’s a debate about wall thickness or material grade, you print both, test both, and the curve settles it in an afternoon. Third, you build up a record of how the design’s performance has evolved, which is quietly valuable later, because when a regulator or notified body asks why a specification limit is set where it is, “we measured it across four iterations and here’s the data” is a much stronger answer than a shrug.
There’s also a softer benefit I’ve noticed, which is that clients relax. Handing someone a force/displacement plot of their own device does quite a bit for confidence, theirs and ours, that the project is on solid ground.
From bench data to design verification and the technical file
It’s worth being clear about the boundary here. Informal development testing tells you the design is heading in the right direction, but design verification is a formal activity, run to a pre-approved protocol on calibrated equipment against acceptance criteria that trace back to your design inputs, and it’s the verification reports that go in the technical file to show the relevant safety and performance requirements are met. Whichever route you’re heading down, UKCA or CE marking, that evidence is expected, and the file structure is much the same (I’ve covered what actually goes in a technical file separately).
The way we prefer to work is to have the documentation grow alongside the testing rather than being written afterwards, so early bench results become design inputs and specifications, and the eventual verification protocols are largely refinements of tests we’ve already run many times. On our rugged autoinjector project we built the documentation alongside the design in exactly this way, and it makes the later stages feel like confirmation rather than examination, which is the end goal really.
If you’re weighing this up for your own device
My view is that if your device has a mechanical function of any kind, some form of instrumented bench testing belongs in the plan from the first prototype onwards, and the cost of getting it in early is small compared with what it saves. If you’ve got a device that needs testing, or you’re not sure what a sensible test programme would look like for your stage of development, I’d be happy to have a call, talk through what you’re building and give you an honest view on what I’d test and why. There’s no charge for the initial chat, you can book a free call here.
Frequently asked questions
No, though they use the same kinds of equipment. Bench testing during development is relatively informal and exists to guide the design, whereas design verification is a formal activity run to pre-approved protocols on calibrated equipment, with results that go in the technical file. In my experience, teams that bench test throughout development find verification fairly uneventful, which is what you want.
Our Mecmesin MultiTest 2.5-dV applies tension or compression at controlled speed, from a couple of newtons up to 2.5 kN. That covers connector pull-off and retention, activation and trigger forces, break-loose and glide forces, compression of materials and peel or joint strength, which is most of what a mechanical device needs during development.
Early informal results normally sit in the design history as supporting evidence rather than serving as formal verification data, but they’re far from wasted, because they justify your specifications and acceptance criteria. The formal verification runs, done to protocol on calibrated kit, are what the file relies on, and they go much more smoothly when the informal testing came first.
Yes. Most rigs we build are part of a wider development project, but if you already have a device and just need a repeatable way to test it, designing and building a bespoke fixture or rig is something we take on in its own right. It usually starts with a conversation about what question the test needs to answer.