Expertise · Industrial mechanisms

We design custom machines and mechanisms, up to the file a workshop can use to give you a price. Manufacturing is done by someone else.

The work is design: measured requirements, the three-dimensional model generated from a programme, the bill of materials with release status for each item, the electrical and safety architecture, the verification plan and the requests for quotation. We do not have a workshop, we do not weld, we do not assemble and we do not put machines on the market. We have taken only one own dossier all the way through, and the machine in it is not built — and the page says that from the start.

Discuss a project

An offer, with conditionsI have a single in-house work of this kind on disk, checked today with commands, not with memories: a complete dossier for a mortar printing cell — 226 positions in the bill of materials, 226 rows in the verification plan, 64 input-output points, of which 24 on a separate safety controller, 26 cable routes, six written RFQs, and 44 automated tests that pass in half a second. And, in the same measurement: zero positions released for procurement out of 226, zero checks executed out of 226, zero RFQs sent, zero units built, zero work done for a beneficiary. Our rule requires at least two in-house implementations for “we did”. Here there is one, and it is unbuilt. So the page is written as an offer with conditions, and the dossier is the work evidence you can open, not a client reference.

What we sell is design and documentation, up to the point where a workshop can answer a request for quotation with a price, not with questions. What we do not sell, so there is no misunderstanding at the second meeting: we do not have a workshop, we do not cut, we do not weld, we do not assemble, we do not commission, and we do not put machines on the market under our name. The physical part is done by a mechanical workshop or an integrator, and responsibility for the compliance of the machine put on the market remains with the one who puts it there. We give them the file they can work with and stay beside them during checks.

Our file looks like this, measured on our own work. The three-dimensional model is not drawn manually, but generated by a parametric program in Python: a single command rebuilds the assembly in exchange formats, 38 candidate parts with individual models, 12 flat profiles for cutting, 12 subassemblies, the PDF sheets and the reports. The practical consequence is that nothing in the package can lag behind the model — if a dimension changes, everything that depends on it changes too, or a test fails.

What makes the difference between a useful file and a stack of drawings is the release status on each item. In our list of 226 items: 108 are “to request quotation”, because the final number depends on options, lengths or sizing; 49 are awaiting analysis; 39 are own parts that require drawing, tolerances and calculation; 30 have the family chosen from the manufacturer’s catalogue — which does not mean confirmed compatibility. Released for procurement: zero. No item becomes orderable until the field with what blocks it is cleared. Those figures are the real status of the work, not a shameful stage to hide.

One thing must be said twice, because it is often misunderstood: the manufacturers and component codes that appear in such a dossier are design choices, not partnerships and not confirmed suppliers. A guide, a servo-drive or a safety controller chosen from the catalogue means that we have read the public datasheet and that the family fits our calculation. It does not mean that we have a relationship with the manufacturer, a negotiated price or a compatibility confirmation. Confirmation comes from the request for quotation and from the test bench, and both are still ahead.

What it covers

The work, by component

We start from measured constraints, not from a nice shape

What electrical supply exists in the real workshop, with grounding and short-circuit current; what material is being processed, with its technical datasheet; what the overall dimensions of the space are; what must come out at the end. Our own work states its first two blockers exactly like this: measuring the supply in the real hall and choosing the material. Until then, the electrical task list remains marked preliminary and the cutting range remains an estimate — written in the file, not implied.

The model is a programme, not a drawing

The geometry is written parametrically in Python, and a single command regenerates the assembly, subassemblies, individual parts in exchange formats, flat profiles for cutting, PDF drawings and reports. The advantage is not speed, but consistency: there cannot be a drawing that contradicts the model, because the drawing is generated from the model every time. And the drawings carry the marking that they are not for manufacture as long as they are not released, and there is an automated test that fails if the marking is missing.

Each position has a release status and a written blocker

226 positions, each with parent assembly, quantity, specification, candidate manufacturer, verification identifier and status. The in-house parts additionally have a candidate drawing, estimated mass, proposed manufacturing route, tolerance and candidate finish — and a separate field that says what exactly is missing for it to be orderable: the welded assembly drawing, the weld plan, the finite element calculation, the machining reference plan. A position without an empty blocker is not purchased.

We test engineering rules, not just code

44 automated tests, which pass in half a second and check statements about the machine: that the active domain is exactly the declared volume, that the guarding mesh matches the declared cell, that no item in the bill of materials remains without a row in the verification plan, that the state machine never extrudes at rest, that each defect taken separately blocks both movement and extrusion, that the lack of calibration blocks movement, and that the maximum layer from the first phase remains within the qualified flow range. A failing test stops a mistake before it reaches the workshop.

Safety on a separate circuit from motion control

The input and output map has 64 points: 16 digital inputs and 16 digital outputs, 4 analogue inputs and 4 analogue outputs on the process side, plus 20 inputs and 4 outputs on a safety controller independent of the process computer. The safety outputs act directly on safe torque off for all drives, on brakes and on pump inhibition, with de-energised fault state. Contactor monitoring loops and brake feedback are own points, not assumptions.

Kinematics are checked before the robot is bought, not after

For the articulated-arm version I wrote a custom screening module: forward kinematics, analytical Jacobian, numerical inverse kinematics with four starting positions and a mandatory 10° margin from each axis limit. The results: 1,331 grid positions checked for placement, then a trial path with 8,400 points, all solved, with maximum axis speed at 7.86% of the catalogue limit and with a minimum margin to limits of 19.9°. The report states its own status: it is an offline discrete screening, not a robot programme, and it does not generate output to hardware.

We read primary sources and keep them with a fingerprint

Manufacturer datasheets, catalogues, comparable commercial systems and seven public patent documents, downloaded as PDF and recorded with a checksum, so that it can later be proven exactly what we read and in which version. A patent drawing is not copied; it is read for the architectural solutions already public and for the traps that someone else solved before us.

Requests for quotation are written with procurement gates, not open questions

Six prepared requests, for guides and screws, servo-drives, the material system, brakes, mixer, plus one for a robotic arm in the alternative version. The one for the robot explicitly contains the gates that must be passed before ordering: model and series, the 3D model from the manufacturer, the workspace diagram, the coverage result for the required volume, the controller and licences, the status report, the cables and documentation, the commissioning offer and the lifting and anchoring plan. An automated test checks that the gates are there.

What we do not do

We do not manufacture, do not assemble, do not commission and do not issue declarations of conformity. We do not confirm the compatibility of a component on the basis of the catalogue. We do not give performance figures as results until they are measured on the bench — the repeatability in our dossier is a target and a measurement plan, not a result. And we do not release any position for procurement while it has a blocker written against it.

What it looks like

The path, step by step.

Measured requirements and core architecture

We measure what exists: the actual power supply and earthing, the space, the material, what has to come out. We write the architecture — kinematics, material flow, division into subassemblies — and, if worthwhile, an alternative assessed in parallel. We deliver the architecture document with its declared limits. The stage can stop here and remain useful.

Parametric model, bill of materials, verification plan

Geometry as code, the bill of materials with status for each item, a verification line for each item, the electrical and safety architecture, cable runs. We deliver the manufacturing package marked as unreleased, plus the automated tests that keep it coherent. From this point, any change propagates on its own or fails a test.

Requests for quotation and release of items

We write the requests by component families, with procurement gates where the component is expensive or hard to reverse. From the responses, the blockers are closed and the items move, one by one, towards the status that authorises purchase. Here the work becomes money spent, so here the threshold is crossed from project to commitment.

Test rigs, dry run, material run

Three physical gates, in order: the single-axis and material test rigs, which turn the flow domain from estimate into measurement; the guarded assembly and the dry run, with measurements of repeatability, play, vibration and noise at several speeds, plus fault injection; and only then the run with real material. These stages are carried out by the workshop or the integrator, with us alongside. In our own work, all three are still ahead.

Five layers, from bottom to top, and the threshold that separates them. The measured constraints — power supply, material, size — are the foundation; above them the parametric model, which is a programme, not a drawing; above it the bill of materials and the verification plan, with a status and a blocker on each line item; then the requests for quotation, with gates where the component is expensive. Above all of them, with a dashed line, the three physical gates — benches, dry run, material run — which are executed in the workshop, not by us. The dashed line is the service boundary: everything below it we deliver, everything above it we accompany.

The data

What we touch, where it lives, and how long it stays

The questions anyone with a data protection officer would ask — asked here before they do.

What data a mechanical job touches: Your requirements, measurements from the real space — power supply, earthing, overall size, access paths —, the technical data sheets for the material you process, the offers received from suppliers, and the resulting drawings. Supplier offers and prices are the sensitive information in the whole package and are kept separate from the part of the file that can be made public.
Where the model is kept and how the version is proved: In a repository with history, where the model is code, and the outputs — exchange formats, flat profiles, drawings, lists — are regenerated from it. Downloaded external sources are kept with a checksum, so it can later be shown exactly which document underpinned a decision. Verification reports carry the fingerprint of the input files.
What you receive and what remains yours: The parametric model and the programme that generates it, the assembly and parts in exchange formats, the flat profiles for cutting, the drawings, the bill of materials with statuses, the verification plan, the input-output map, the electrical task list, the cable runs and the requests for quotation. All in files that another engineer can open, not in a format tied to us.
What is never published: The offers received, the negotiated prices and any process detail that belongs to you. If an output of the work becomes public material — a page, a presentation, an article — it is agreed in writing what may be shown, before it is shown.

A case

A procurement decision deliberately deferred until the calculation supports it

The situation

For the same task — depositing mortar within a volume of one cubic metre — a second possible architecture appeared: instead of a Cartesian gantry, a six-axis articulated arm on a fixed pedestal, with the same fixed bed and the same material path. The arm is the expensive and hard-to-return component in the whole assembly. The real question was not whether it looks better, but whether it covers the required volume without approaching the axis limits.

What we built

I wrote a proprietary kinematics module on top of the robot’s public description: forward kinematics, analytical Jacobian, numerical inverse kinematics with four start positions and an imposed 10° reserve from each axis limit, with convergence to 0.05 mm per position. With it I checked 1,331 grid placements, then ran a helical test path through the entire volume, with 8,400 points. Separately, a collision check on real geometry, explicitly stated as screening on discrete samples, not as certified swept-volume analysis. And the request for quotation for the robot was written with the procurement gates inside it.

What came out

All 8,400 points were solved, with no failures. The maximum speed per axis remained at 7.86% of the catalogue limit, and the minimum margin from the axis limits was 19.9° — meaning the path not only fits, but fits with reserve. The report writes its own status: discrete offline screening, with no output to hardware, and it is not a robot program. The robot remains unpurchased until the gates in the request for quotation receive an answer.

What the case does not say

The screening covers kinematics and geometry, nothing more. It does not cover the material growing under the nozzle, the flexible hose, pump delay and pressure — all of these are listed explicitly under limitations in the report. The rates calculated by finite differences do not include start-stop ramps and the controller’s trajectory blending. In other words: enough not to buy the wrong thing, not enough to print.

Questions

What people ask us before they call

Do you build the machine or just draw it?

We design it and write the documentation with which it is built. We do not build it. We have no workshop, we do not cut, weld, assemble or put machines on the market under our name. What we do is take the work to the point where a mechanical workshop can give a price without asking anything essential, and stay with it during checks. If you need someone to deliver a turnkey machine, we are not that party, and it is better to find out from the first sentence than from the third meeting.

Have you ever built a machine designed by you?

No. We have one proprietary file, taken to the level where prices can be requested, and the machine in it has no built example: zero ordered parts, zero physical checks carried out from 226 planned, zero positions released for procurement from 226, zero requests for quotation sent from six written. That is the real status and we publish it as such. What we can show is the file, the tests that run in front of you, and the written reason for each blockage.

Then why would an unbuilt project be of value to me?

Because the part you buy from a designer is not the machine, but the ability to ask correctly. A file in which every position has a status, a written blockage and a verification line is exactly what saves you from buying the wrong guide, an undersized drive or a robot that does not cover the volume. And, just as important, it is the kind of file in which you can see from the start who told you the truth about the stage.

Are the components in the list confirmed with the manufacturers?

No, and that is the key clarification on this page. A component marked as chosen from the catalogue means that we have read the public data sheet and that the family matches our calculation. It does not mean final compatibility, it does not mean price and it does not mean partnership. Confirmation comes from the reply to the request for quotation and, for critical parts, from the test bench. Any supplier named in one of our files is a design choice, nothing more.

Who is responsible for safety and compliance documents?

Responsibility for the machine placed on the market lies with the party that places it on the market — the manufacturer or integrator who assembles it and hands it over. We design the safety architecture: separate circuit from motion control, independent safety controller, safe torque off, brakes with feedback, contactor monitoring, fault states that fail safe. We also deliver the related documentation. Conformity assessment and marking are not our service and we do not pretend that they are.

Can you design something other than the machine in the example?

The method transfers; domain knowledge does not transfer automatically, and that must be said. What moves from one project to another is the way of working: constraints measured first, parametric model generated from the programme, release status for each position, verification plan with one line per position, safety on a separate circuit, requests for quotation with gates. What does not move are the specifics of your material and process, and those are learned at the start, with you, or brought in from a domain specialist. If the correct answer is that we lack the domain, we say so.

How long does it take?

We do not set deadlines on this page because they do not depend on us alone. The pace is set by three physical gates, in order: the material and axis benches, the dry trial of the protected assembly, and the trial with real material. Each depends on decisions that are not ours — measuring the feed in your hall, choosing the material, sending requests for quotation and the suppliers’ replies. What we can estimate honestly is the first stage, the requirements and architecture.

What happens if, halfway through, it turns out the chosen architecture is wrong?

A second architecture is written and compared, instead of continuing with the first because it has already started. In our own work that is exactly what happened: alongside the Cartesian portal variant there is a second one, with an articulated arm on a fixed pedestal, assessed in parallel, with its own list of mandatory simulations before any order and with the flange load budget capped, with an imposed reserve. It is documented as an unissued alternative, not as a second product.

Why does it say “offer” and not “delivered service”?

Because we have only one work of this kind and it is not built, and the rule we apply to ourselves requires at least two in-house implementations before we can write “we did”. We prefer a page that stands up to an engineer’s questions rather than one that sounds good until the second question. When we have a dossier made for a beneficiary and a machine built from it, the page will change — and it will be clear why it changed.

What the statements above rest on (14 sources)

14 of them are code and files from our repositories. We don't publish their name or line: together, on a single page, they would describe too precisely how systems that aren't only ours are built. We go through them with you, in the repository, on request — verification stays possible, it just happens in a conversation.

How we work All services

What would you want to work better?

Tell us about your process. Together we decide what is worth building, what we can connect, and how we check the result.

Let's talk