Reliable communication between a C# supervisory application and TwinCAT involves more than reading and writing variables. It requires a data contract, connection lifecycle, subscription strategy, thread separation, write authority, diagnostics and version compatibility.
Define communication responsibility first
Identify which data is read-only, which values may be written, the required update rate, behaviour after disconnection and which system owns the final state. Production status, alarms, recipes, parameters, traceability and maintenance commands have different risk profiles and should not share an unrestricted read-write design.
Select the interface for the system boundary
Within the Beckhoff ecosystem, ADS is commonly used for variable access and notifications between a C# application and a TwinCAT runtime. Systems requiring more general third-party or cross-platform integration may also use OPC UA, databases, messaging or a dedicated application interface.
The choice should consider latency, data volume, network scope, maintainability, licensing, versions and cyber security. A control network should not be exposed to an untrusted network merely for convenient debugging.
Establish a stable data contract
Use a dedicated communication structure between PLC and C#, defining names, types, units, ranges, direction, timestamps, quality and interface version. A supervisory application should not depend on many scattered internal PLC symbol paths that can silently break when the PLC program is refactored.
- Status data is published by the PLC and displayed by C# without writing back to internal state.
- Commands use request, acknowledgement, result and sequence identifiers to prevent repeated execution.
- Recipe and parameter writes are validated for range, authority and machine state before the PLC accepts them.
- An interface version allows both applications to detect incompatible software combinations.
Use notifications and polling deliberately
Change notifications suit states, alarms and selected values and can reduce unnecessary reads. Periodic polling suits low-frequency summaries and connection health checks. Subscription count, deadband and update rate should follow actual needs rather than streaming every PLC symbol at high frequency.
Make the connection lifecycle recoverable
The C# communication layer should independently manage connection, timeout, disconnection detection, reconnection, subscription restoration and resource disposal. Potentially blocking communication should not run directly on the user-interface thread; acquisition, business logic and UI updates should exchange data through a controlled queue or state model.
After reconnection, the application should not assume that pre-disconnection commands remain valid. It should re-confirm the PLC mode, interface version, active batch and command sequence before sending further operations.
Control write authority and audit operations
Writes affecting motion, mode, recipes or critical parameters should be limited by user authority, machine state and business rules. Record the operator, time, previous value, requested value and result. Supervisory permissions do not replace PLC-side state checks or safety protection.
Validate diagnostics and performance
Logs should record connection, disconnection, reconnection, timeout, interface version and key command results without indiscriminately storing high-frequency or sensitive production data. Testing should cover PLC restart, application restart, short network interruption, version mismatch, invalid data, large subscriptions and extended operation.
Handover documentation
Preserve the TwinCAT and C# project versions, runtime environment, communication-library version, AMS or other network configuration, data dictionary, authority model, deployment steps, backups and recovery method. Passwords, keys and production-network details should not be placed in public documentation or source repositories.
This article describes general software-architecture practices and does not replace Beckhoff ADS, TwinCAT or cyber-security documentation. APIs, configuration, licensing and network controls must be verified for the specific software versions, controller, customer standards and security requirements.