For AI agents: the Markdown edition of this page is why.md; the site index for agents is llms.txt.

Why .NET + Direct Motion is the easier way

Most machines are built from three systems that have to be made to agree: a PLC programmed in a ladder or structured-text dialect, servo drives each configured with its maker's tool and talking over a fieldbus, and an HMI with its own runtime. Three tools, three languages, three places a bug can hide.

A Direct Motion machine is one Windows PC and one .NET program. The program is the machine.

What you get

A real language, and the one you already use. DMSerialMotion is a .NET library, so the machine program can be C#, VB.NET, F# or any other .NET language, with a debugger, unit tests, package management, async, LINQ, databases, networking, web servers and every UI toolkit on Windows. A machine written this way can log to a database, serve a web page to a phone, call a vision library and run the motion, all in the same program, with no gateway between them.

The real-time part is already done. The servo loop (current, velocity and position for every axis) runs 20,000 times a second inside DM's kernel driver, on a CPU core set aside for it. A look-ahead planner in the library fills a buffer ahead of the driver. Your code calls JogToLocation, builds a program of lines and arcs, or sets a speed. It never has to meet a deadline itself.

One vendor for the amplifiers, the IO and the software. The people who designed the boards wrote the library. When a question spans hardware and software, there is one place to ask.

Motors set themselves up. One-touch setup takes the motor from a catalog of 1,180 or from the nameplate, finds the commutation, measures the electrical values the catalog lacks and tunes the servo loop. Field-oriented control and, for induction spindles, field weakening above base speed are built in.

A flight recorder on every axis. A 20 kHz record of commanded and actual position, following error, phase currents, bus voltage, temperatures and fault bits. DM's tools read it; so can your code.

Your AI assistant is already an expert. Large language models have been trained on an enormous amount of C# and .NET, and on almost no PLC code. Ask one to write a ladder program and it guesses. Ask it to write a .NET program against a documented library and it works. This site gives it the documentation.

What you do not get

We would rather lose a sale than a customer. A DM system is not:

• A PLC. There is no IEC 61131 programming. If the plant standard is a PLC brand, DM is a poor fit.
• A fieldbus master. DM amplifiers talk to DM's own link card over DM's serial link. The system does not drive EtherCAT, PROFINET or CANopen servo drives from other makers.
• A safety controller. DM publishes no SIL or PL rating. E-stop handling, limits, following-error and fault stops are built in, but a machine that needs a rated safety function must get it from rated safety parts (safety relays, safe-torque-off contactors, light curtains) around the DM system.
• Motor-agnostic. The motors must be 3-phase AC servo or induction motors, with incremental, sin/cos, BiSS or BiSS-C encoders. Motors with a proprietary serial encoder cannot be used. There is no stepper support.
• Analog. There is no general analog IO. The power board reports its own voltages and temperatures.
• PC-less. The machine runs while the Windows PC runs.

How the pieces compare