Automation projects rarely fail on the code. They fail on assumptions that were never checked and on machines that were never properly commissioned. The way N-Control works is built around avoiding both.
Why the company is called N-Control
Say it out loud and it reads as in control. That is not a pun that turned up after the name was chosen — it is the commitment the company is built on. What has to stay in control is the implementation and everything that follows it: the software above all, from the first specification through every change made to it for the rest of the machine's life.
That means software development is run as a controlled, logical process rather than as a series of good intentions. Requirements are written down before they are built. Design decisions are recorded, so nobody has to remember why something was done. Every requirement can be traced to the test that shows it works. Versions and changes are controlled, so the code running on the machine is always the code that was reviewed and released, and the reason for every change is on record.
In pharmaceutical and other regulated production this is not a matter of taste. GAMP 5 requires exactly this: a documented lifecycle, traceability from requirement through to testing, and change control that holds for as long as the system is in use — and bespoke machine software, which is what N-Control writes, falls in its most demanding category. A good deal of N-Control's work is in regulated industry, so that is the standard I work to.
Nothing is left floating. Not during development, not during commissioning on site, and not through the years of maintenance and modification that follow — which is the part most suppliers stop documenting. A machine kept in control this way can still be understood, changed and re-validated in five years, by me or by somebody else entirely. And the customer is inside that process throughout, rather than being handed the result at the end.
How a project runs
1. Understand the machine
I start with what the machine has to achieve and under what conditions — products, variants, rates, tolerances, the environment and the people who will run it. Where possible I see it in operation. Most of the risk in a project is identified in this step or not at all.
2. Agree the concept
You get a concrete proposal: control platform, axis and drive configuration, robot and vision where relevant, the interfaces to the rest of the plant, and what is deliberately left out. Anything uncertain is named as uncertain rather than buried in an estimate.
3. Prove the hard part early
Every project has one part that decides whether it works — a motion profile, a camera that has to see a feature under bad lighting, a cycle time that leaves no margin. I test that part first, on real parts, before the rest of the system is built around it.
4. Build and test
Structured, documented software written to be read by whoever opens it next. Simulation and dry runs before power goes on the machine, so on-site time is spent tuning rather than debugging.
5. Commission and hand over
On site until the machine runs at rate with your products and your operators. You receive the source code, documentation and drawings, and the people who run the machine are trained on it. No black boxes and no lock-in.
What you can count on
- You own what N-Control delivers. Source code, documentation and passwords are yours, on a standard platform your own staff or another supplier can maintain.
- One person who knows the whole machine. Control, motion and vision from the same engineer, so nothing gets lost in handovers between disciplines.
- A straight answer. If a requirement is unrealistic, or the job is a poor fit for N-Control, you hear it before the order rather than after.
- Availability afterwards. Machines change as products change. I stay reachable for the adjustments that follow.
The engineer behind N-Control
N-Control is Nicolai Hanssing. M.Sc. in engineering from the Technical University of Denmark, specialising in closed-loop control — which is, in the end, what all of this comes down to: a machine that measures what it is doing and corrects itself faster than a person could. Working in industrial automation since 2002, and running N-Control since 2017.
Practically, that means the person you talk to is the person who writes the code. There is no account manager in between, and no quiet handover to a junior once the order is signed. It also means the work taken on is the work that suits one engineer doing it properly — servo control, robot movement, machine vision and the software that ties them together — rather than everything a larger integrator would have to say yes to.
Two decades in this trade teaches you where projects actually break: not in the code, but in an assumption nobody checked, or a machine that was signed off before it ran with real products. So the habits are unglamorous ones — see the machine before quoting on it, prove the hard part before building around it, stay on site until it runs at rate, and pick up the phone afterwards when something changes. Customers tend to come back, and a good deal of the work arrives through machine builders who have used N-Control before.