DEV Community: Mridul Krishna

Talking to a PLC from C#, Part 3: Safe Writes and a Clean Abstraction Layer

Mridul Krishna — Tue, 29 Sep 2026 07:18:59 +0000

We've come a long way. In Part 1 we connected a C# app to a Beckhoff PLC and did our first read and write. In Part 2 we stopped polling, subscribed to notifications, and learned to read a whole struct in one shot.

So far, though, we've mostly been reading. This post is about the other direction — writing back — and it's where the stakes change. Reading is passive. Writing changes what a physical machine does. Get it wrong and you don't get a stack trace; you get a scrapped part, a crashed axis, or worse.

And then we'll do the thing that separates a script from a product: hide all of this behind a clean interface, so the rest of your application never touches ADS at all.

Writing a struct back

Mechanically, writing is the mirror of the read from Part 2. Same layout rules, same one-call efficiency:

var setpoints = new JobSetpoints
{
    LaserPower  = 1500,   // watts
    CuttingSpeed = 3.5f,  // m/min
    GasPressure  = 2.0f   // bar
};

client.WriteValue("GVL.JobSetpoints", setpoints);

One call, and the entire setpoint block lands in the PLC. Which raises the obvious question: why write the whole struct instead of just the field that changed?

Two reasons, and the second one matters more than it looks.

Consistency. If you write field-by-field across several calls, the PLC's scan can run between your writes — and act on a state that's half-old, half-new. New power, old speed, for one cycle. Writing the block in a single call keeps your values together.

Consequences. These aren't database rows. LaserPower = 15000 because someone fat-fingered a form is a physical event. So the write path is the right place to be paranoid — validate before the value ever leaves your app.

public void SetSetpoints(JobSetpoints s)
{
    if (s.LaserPower is < 0 or > 4000)
        throw new ArgumentOutOfRangeException(nameof(s.LaserPower));
    if (s.CuttingSpeed is < 0 or > 20f)
        throw new ArgumentOutOfRangeException(nameof(s.CuttingSpeed));

    client.WriteValue("GVL.JobSetpoints", s);
}

And the rule that ties back to everything in this series: write on change, not on a clock. Push a setpoint when the user actually changes it. Don't loop.

Commands need a handshake, not a fire-and-forget

Setting a value is one thing. Telling the machine to do something — start cutting, home an axis, run a job — is another. For those, a bare write is not enough, because a write tells you the value arrived, not that the machine acted on it, finished, or failed.

The pattern every automation engineer will recognise is a handshake: you write the data, raise an Execute request, and wait for the PLC to raise Done (or Error) back. The PLC owns the state machine; your app just requests and waits. It's the same shape as a PLCopen function block.

Here's that handshake in C#, using a notification (from Part 2) so we wait on the Done bit instead of polling it:

public async Task<bool> ExecuteJobAsync(CancellationToken ct = default)
{
    var done = new TaskCompletionSource<bool>();

    uint handle = client.AddDeviceNotificationEx(
        "GVL.stJob.bDone",
        new NotificationSettings(AdsTransMode.OnChange, cycleTime: 50, maxDelay: 0),
        userData: null,
        typeof(bool));

    void OnNotify(object sender, AdsNotificationExEventArgs e)
    {
        if (e.Handle == handle && (bool)e.Value)
            done.TrySetResult(true);
    }
    client.AdsNotificationEx += OnNotify;

    try
    {
        await client.WriteValueAsync("GVL.stJob.bExecute", true, ct);
        using (ct.Register(() => done.TrySetCanceled()))
            return await done.Task;          // resolves when the PLC sets bDone
    }
    finally
    {
        await client.WriteValueAsync("GVL.stJob.bExecute", false, ct);  // reset the request
        client.AdsNotificationEx -= OnNotify;
        client.DeleteDeviceNotification(handle);
    }
}

Notice what this buys you: the caller gets a clean await ExecuteJobAsync() that completes when the machine is actually done — no polling loop, no timer, no guessing. The finally resets the request bit and releases the notification even if something throws or the operation is cancelled.

Now hide all of it

Here's the part I'd argue matters most for anyone building a real HMI.

Everything above — AdsClient, AmsNetId, symbol strings like "GVL.stJob.bExecute", notification handles — is plumbing. If it leaks into your ViewModels, your forms, and your business logic, you've welded your entire application to Beckhoff. Your UI can't be tested without a live PLC. Swapping to a simulator means touching a hundred files. Every symbol-name typo is a landmine scattered across the codebase.

So don't let it leak. Put a wall between "the app" and "the PLC," and let only a thin gateway cross it.

Start with an interface that speaks the language of the machine, not of ADS:

public interface IMachineGateway : IDisposable
{
    bool IsConnected { get; }

    event EventHandler<bool> ConnectionChanged;
    event EventHandler<MachineStatus> StatusChanged;

    Task ConnectAsync();
    Task SetSetpointsAsync(JobSetpoints setpoints);
    Task<bool> ExecuteJobAsync(CancellationToken ct = default);
}

Nothing in there mentions ADS. No AmsNetId, no symbol paths, no AdsClient. Just machine concepts.

The TwinCAT implementation is the only place that knows the truth:

public sealed class TwinCatMachineGateway : IMachineGateway
{
    private readonly AdsClient _client = new();
    private uint _statusHandle;

    public bool IsConnected => _client.IsConnected;
    public event EventHandler<bool> ConnectionChanged;
    public event EventHandler<MachineStatus> StatusChanged;

    public Task ConnectAsync()
    {
        _client.Connect(AmsNetId.Local, 851);

        // Live machine status -> a plain .NET event the app understands
        _statusHandle = _client.AddDeviceNotificationEx(
            "GVL.MachineStatus",
            new NotificationSettings(AdsTransMode.OnChange, 100, 0),
            null, typeof(MachineStatus));

        _client.AdsNotificationEx += (s, e) =>
        {
            if (e.Handle == _statusHandle)
                StatusChanged?.Invoke(this, (MachineStatus)e.Value);
        };

        ConnectionChanged?.Invoke(this, true);
        return Task.CompletedTask;
    }

    public Task SetSetpointsAsync(JobSetpoints s)
    {
        Validate(s);                                   // paranoia lives here
        return _client.WriteValueAsync("GVL.JobSetpoints", s).AsTask();
    }

    public Task<bool> ExecuteJobAsync(CancellationToken ct = default)
        => /* the handshake from above */;

    public void Dispose()
    {
        if (_statusHandle != 0) _client.DeleteDeviceNotification(_statusHandle);
        _client.Dispose();
    }

    private static void Validate(JobSetpoints s) { /* range checks */ }
}

Now look at what your WPF ViewModel becomes:

_gateway.StatusChanged += (s, status) =>
    Dispatcher.Invoke(() => SpindleTemp = status.SpindleTemp);

// user clicks "Run"
await _gateway.ExecuteJobAsync();

It has no idea a Beckhoff PLC is on the other end. And that's the whole point:

You can test the UI with no hardware. Write a FakeMachineGateway : IMachineGateway that returns canned status and pretends to run jobs. Your whole front end becomes developable and testable on a laptop with no machine in sight — which, for an HMI team, is the difference between "we can work" and "we're all queuing for the one test rig."
Symbol strings live in exactly one file. Rename a PLC variable, fix it once.
Connection handling is centralised. Reconnection, error translation, lifecycle — one place, driven by the client's connection-state events rather than a heartbeat timer.
ADS failures become domain results. Catch AdsErrorException at the boundary and translate it into something your app understands, so an AdsErrorCode never surfaces in a button-click handler.

A few rules that keep the wall standing: make the gateway a single long-lived instance (don't spin up an AdsClient per view); never let an ADS type appear in the interface's signatures; and let the gateway own the full ADS lifecycle so Dispose actually cleans up notifications and the client.

The whole series, in one breath

Part 1 — connect, and do a single read and write.
Part 2 — stop polling; subscribe to notifications, and read a whole struct in one call.
Part 3 — write back with validation, use a handshake for commands, and hide ADS behind an interface the rest of your app can actually live with.

Put those together and you've got the real backbone of an HMI: live machine state flowing in, validated commands going out, and an application architecture that doesn't know — or care — that there's a PLC behind the curtain. Which, not coincidentally, is exactly the foundation you'd want if you ever wanted to put something smarter on top of that gateway later.

That wraps the series — thank you to everyone who followed along and commented; it genuinely made writing it worthwhile.

If you're building HMIs or industrial apps in .NET, I'd love to know how you structure the boundary between your UI and the control layer. And if there's a topic you'd want me to go deeper on next — WPF data binding to live PLC values, simulators, testing strategies — tell me in the comments. 👋

Talking to a PLC from C#, Part 2: Notifications and Whole-Struct Reads

Mridul Krishna — Mon, 21 Sep 2026 06:51:33 +0000

In Part 1 we got a C# app talking to a PLC over ADS: connect, read one variable, write one back. Right at the end I made a promise and then walked away from it — I told you not to poll your values on a timer, and that reading whole structured types into C# was where things get good.

Time to make good on both.

This post covers the two techniques that turn "I can read a variable" into "I can build a real HMI on top of this": device notifications (the PLC tells you when something changes) and struct reads (grab an entire block of machine state in one shot instead of a dozen round trips).

Stop polling. Let the PLC push.

The tempting pattern after Part 1 is a loop on a timer: every 200 ms, read the temperature, update the screen. It works in a demo and quietly rots in production — stale data, needless traffic, and a mess that gets worse with every variable you add.

ADS has a proper answer: device notifications. You register interest in a symbol once, hand ADS a callback, and it pushes updates to you. No client-side clock, no busy loop.

using TwinCAT.Ads;

using var client = new AdsClient();
client.Connect(AmsNetId.Local, 851);

// "Tell me when rSpindleTemp changes." The sampling happens on the
// ADS server side — this is not a timer in your app.
uint handle = client.AddDeviceNotificationEx(
    "GVL.rSpindleTemp",
    new NotificationSettings(AdsTransMode.OnChange, cycleTime: 100, maxDelay: 0),
    userData: null,
    typeof(float));

client.AdsNotificationEx += (sender, e) =>
{
    float temp = (float)e.Value;   // decoded for you because we passed typeof(float)
    Console.WriteLine($"Spindle temp: {temp}");
};

A few things worth understanding rather than copy-pasting:

OnChange vs Cyclic. AdsTransMode.OnChange fires only when the value actually changes. AdsTransMode.Cyclic fires on every interval regardless. For an HMI you almost always want OnChange.
cycleTime is how often the server samples the variable to decide whether it changed — think of it as the resolution of "change," not a timer in your process. 100 ms is plenty for a temperature readout; a fast-moving axis position might want less.
maxDelay lets the server batch several changes together before sending, to cut chatter. 0 means "send as soon as you notice."

Times are milliseconds here, but the NotificationSettings overloads have shifted across TwinCAT.Ads releases (some take a TimeSpan) — glance at the signature your version exposes.

The gotcha that will bite you in WinForms/WPF

Your notification handler does not run on the UI thread. ADS raises it on a background thread. Touch a WinForms control or a WPF element directly from there and you'll earn a cross-thread exception — or worse, an intermittent one that only shows up on a customer's machine.

Marshal back to the UI thread:

client.AdsNotificationEx += (sender, e) =>
{
    float temp = (float)e.Value;
    // WinForms:
    lblTemp.BeginInvoke(() => lblTemp.Text = $"{temp:F1} °C");
    // WPF:
    // Dispatcher.Invoke(() => TempText.Text = $"{temp:F1} °C");
};

(The client can also be handed a synchronization context so it marshals events for you — convenient, but the default is a background thread, so assume that unless you've set it up otherwise.)

Clean up after yourself

Notifications are a server-side resource, and the server has a finite number of them. Register them in a loop without releasing, and you'll eventually hit a wall that looks nothing like the actual cause. When you're done — and on disconnect — delete them:

client.DeleteDeviceNotification(handle);

Reading a whole struct in one round trip

Real machine state isn't one variable — it's twenty. Reading them one call at a time is both slow (every read is a network round trip) and race-prone (your twenty values are each from a slightly different moment). The fix: read the whole block at once.

Say the PLC has this:

TYPE ST_MachineStatus :
STRUCT
    bRunning     : BOOL;
    iState       : INT;
    rSpindleTemp : REAL;
    sJobName     : STRING(80);
END_STRUCT
END_TYPE

You mirror it with a C# type whose memory layout matches exactly, then read it in a single call:

using System.Runtime.InteropServices;

[StructLayout(LayoutKind.Sequential, Pack = 1)]
public struct MachineStatus
{
    [MarshalAs(UnmanagedType.I1)]
    public bool Running;        // PLC BOOL  -> 1 byte

    public short State;         // PLC INT   -> 2 bytes (INT is 16-bit!)

    public float SpindleTemp;   // PLC REAL  -> 4 bytes

    [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 81)]
    public string JobName;      // PLC STRING(80) -> 80 chars + null
}

MachineStatus status = client.ReadValue<MachineStatus>("GVL.MachineStatus");
Console.WriteLine($"{status.JobName}: state={status.State}, temp={status.SpindleTemp:F1}");

One call, one consistent snapshot of the machine. And you can wire it straight into a notification — pass typeof(MachineStatus) to AddDeviceNotificationEx and cast e.Value — so the whole status block pushes to you on change.

Making the layouts actually match

This is where the afternoons disappear, so it's worth slowing down:

Alignment/packing must match. By default TwinCAT and .NET don't pad structures the same way. The clean fix is to force byte packing on both sides: put {attribute 'pack_mode' := '1'} above the PLC STRUCT, and use Pack = 1 in the C# [StructLayout]. Keep those two numbers equal, forever.
BOOL is one byte — C# bool isn't. Marshaled, a C# bool defaults to 4 bytes and shoves everything after it out of alignment. [MarshalAs(UnmanagedType.I1)] pins it to one byte to match the PLC BOOL.
STRING is ASCII and fixed-width. STRING(80) is 81 bytes (the null terminator counts). ByValTStr with SizeConst = 81 handles it. Note this is not WSTRING — that one is Unicode and needs different handling.
Field order is the contract. LayoutKind.Sequential maps fields in declaration order, so the C# order must match the PLC declaration order one-for-one. Reorder one and everything downstream reads as garbage.
The two definitions are coupled. Change the PLC struct and the C# struct has to change with it. Keep them side by side, comment the pairing, and if you do this a lot, consider generating the C# side from the PLC symbols.

If hand-mapping layouts makes you nervous, TwinCAT.Ads also exposes a symbol loader that can read values by symbol without you declaring the layout at all — worth a look for one-off reads. But for the hot path in an HMI, the explicit struct is fast, predictable, and easy to reason about.

The short version

Don't poll on a timer — register a device notification and let the PLC push changes.
Use OnChange for HMI values; understand cycleTime and maxDelay.
Your notification callback is on a background thread — marshal to the UI before touching controls.
Delete notifications when you're done; they're a limited server resource.
Read a whole struct in one round trip for a consistent snapshot — but the C# layout has to match the PLC exactly: packing, BOOL as I1, fixed-width strings, field order.

Get these two patterns solid and you've got the real backbone of an HMI: live values flowing in without polling, and full machine state readable in a single call.

Next in the series: writing structs back safely, and wrapping all of this in a small abstraction so the rest of your app never has to know ADS exists.

If you're doing .NET on the industrial side, I'd genuinely like to hear how you handle PLC-to-C# type mapping — hand-rolled structs like this, code generation, or something smarter? 👋

Talking to a PLC from C#: A .NET Developer's Intro to Beckhoff ADS

Mridul Krishna — Wed, 16 Sep 2026 13:44:10 +0000

You know your way around C#. You've built WinForms tools, maybe some WPF, wired up APIs and databases. Then one day you land on an industrial project, someone points at a laser-cutting machine humming in the corner, and says:

"The controller's already running. We just need your app to read the temperature off it and flip a couple of outputs."

And you realise every tutorial you've ever read assumed the thing on the other end was a web server or a database — not a physical machine.

I've spent most of the last 15 years in exactly this corner of software, and the honest truth is the first connection to a PLC is the hardest part. Not because it's complicated, but because nobody writes about it. So this is the post I wish I'd had on day one.

What we're actually talking to

On a Beckhoff system, two things matter:

TwinCAT is the runtime that runs the PLC logic on the controller. Your control program — the ladder logic, the structured text, the state machines — lives here.
ADS (Automation Device Specification) is the messaging protocol you use to talk to it. Reading a variable, writing a variable, subscribing to changes — all of it rides on ADS.

Think of ADS as the PLC's API. Your C# app is just another client making calls.

There are three concepts that trip up every newcomer, so let's name them up front:

AmsNetId — the address of the target, like an IP but with six octets: 192.168.1.10.1.1. Very often it's literally your controller's IP with .1.1 tacked on. This is not the same as the IP address, and mixing them up is a rite of passage.
ADS port — identifies which service on the target you want. The first PLC runtime on TwinCAT 3 lives on port 851 (it was 801 on TwinCAT 2). You'll memorise 851 whether you want to or not.
The AMS router — a background service that actually routes your messages. It ships with TwinCAT. If it isn't running, nothing works, and the error won't be obvious. On a dev machine without full TwinCAT, install Beckhoff's standalone ADS setup so you get the router.

The setup

Before a single line of code:

TwinCAT (or the standalone ADS runtime) installed, so the AMS router is running.
The NuGet package: Beckhoff.TwinCAT.Ads. The modern 6.x version targets .NET Standard, so it works from .NET Framework and .NET Core / .NET 6+ alike.
If you're connecting to a remote controller, an ADS route between the two machines — both sides have to know and trust each other. You set this up once in the TwinCAT router tool. Locally, you can skip this.

The first connection

Here's the whole thing — connect, read one value, write one back:

using TwinCAT.Ads;

using var client = new AdsClient();

// Connect to the local PLC runtime on port 851.
// For a remote target, swap in its AmsNetId: new AmsNetId("192.168.1.10.1.1")
client.Connect(AmsNetId.Local, 851);

// Read a variable by its symbolic path in the PLC
short temperature = client.ReadValue<short>("GVL.iTemperature");
Console.WriteLine($"Temperature: {temperature}");

// Write a variable back
client.WriteValue("MAIN.bStartHeater", true);

That's it. No sockets, no byte packing — you address PLC variables by name (GVL.iTemperature, MAIN.bStartHeater), and the library resolves the rest. The first time you see a real value come back from a real machine, it genuinely feels like magic.

The mistake everyone makes next

Once reading works, the instinct is obvious: you need the temperature to stay current, so you drop the read into a loop on a timer. Tick every 200 ms, read the value, update the UI. Done.

Don't.

Polling on a timer is the thing I'd most warn my past self away from. It hammers the PLC with requests it didn't ask for, it scales terribly the moment you're watching more than a handful of variables, and it makes your app's data always slightly stale — you find out about a change up to one timer-tick late, every time.

ADS already solves this. It's event-driven: you tell the PLC "notify me when this value changes," and it pushes the update to you. You register a device notification on a symbol, hand it a callback, and your code reacts only when something actually happens:

// Notify me whenever iTemperature changes (on-change, not on a clock)
client.AddDeviceNotification(
    "GVL.iTemperature",
    new NotificationSettings(AdsTransMode.OnChange, cycleTime: 100, maxDelay: 0),
    userData: null);

client.AdsNotification += (sender, e) =>
{
    // fires only when the value changes — no polling loop in sight
    Console.WriteLine("Temperature changed");
};

Same idea for keeping a connection healthy — lean on the library's connection state events rather than a heartbeat timer you babysit yourself. Let the protocol do the work it was designed to do.

A few gotchas that'll cost you an afternoon

PLC types are not C# types. A PLC INT is 16-bit — that's a C# short / Int16, not int. Read a PLC INT into a C# int and you'll get garbage or an outright error. The map you'll want: BOOL → bool, INT → short, DINT → int, REAL → float, LREAL → double.
AmsNetId ≠ IP address. Six octets, not four. When a connection silently fails, this is the first thing to check.
The router is the usual culprit. "Target machine not found" almost always means a missing route or a stopped router — not your code.
Connections drop. Machines get power-cycled, cables get kicked. Assume the link will die and handle reconnection deliberately, instead of assuming a happy path that only exists in the demo.

Where to go from here

Once connect / read / write / notify click into place, the rest opens up fast: reading whole structured types straight into C# classes, batching many reads into a single request, and building a proper abstraction so the rest of your app never touches ADS directly.

But that first working read is the milestone. If you get a value back from a real machine today, you're past the hardest part.

Is anyone else here doing .NET on the industrial / automation side? I'd love to hear what tripped you up early — the factory-floor corner of software is quiet on here, and it'd be great to find the others. 👋