Skip to content

1. BIG PICTURE — WHY COMMUNICATION EXISTS IN MACHINES

Image

Image

Image

Image

Image

Image

Image

An industrial machine is not a single program running in one place — it is a distributed system (hệ thống phân tán). You have a PLC (bộ điều khiển lập trình), sensors (cảm biến), actuators (cơ cấu chấp hành), drives, and often an industrial PC running a .NET application, all working together but physically separated.

Một máy công nghiệp không phải là một chương trình chạy ở một nơi — nó là một hệ thống phân tán (distributed system). Bạn có PLC (bộ điều khiển lập trình), cảm biến (sensor), cơ cấu chấp hành (actuator), driver, và thường là một PC công nghiệp chạy ứng dụng .NET, tất cả phối hợp nhưng nằm ở các vị trí khác nhau.

These components must communicate (truyền thông) continuously. The PLC reads sensors, controls actuators, and exchanges data with the .NET application for UI, monitoring, and high-level logic. Without communication, the machine literally cannot function.

Các thành phần này phải truyền thông (communication) liên tục. PLC đọc dữ liệu từ cảm biến, điều khiển cơ cấu chấp hành, và trao đổi dữ liệu với ứng dụng .NET để hiển thị UI, giám sát, và logic cấp cao. Nếu không có truyền thông, hệ thống không thể hoạt động.


2. WHAT A PROTOCOL REALLY IS

Image

Image

Image

Image

Image

Image

A protocol (giao thức) is simply a set of rules that define how devices communicate (truyền thông). It tells both sides how to format messages, when to send them, and how to handle errors.

Giao thức (protocol) là tập hợp các quy tắc định nghĩa cách các thiết bị truyền thông (communication). Nó quy định cách định dạng dữ liệu, thời điểm gửi, và cách xử lý lỗi.

In industrial systems, protocols must be predictable. Unlike web APIs, you cannot tolerate random delays or inconsistent behavior. Timing, ordering, and reliability are critical because they directly affect physical movement and safety.

Trong hệ thống công nghiệp, giao thức phải có tính dự đoán cao. Không giống API web, bạn không thể chấp nhận độ trễ ngẫu nhiên hoặc hành vi không ổn định. Thời gian, thứ tự, và độ tin cậy ảnh hưởng trực tiếp đến chuyển động vật lý và an toàn.


3. COMMON INDUSTRIAL PROTOCOLS

Image

Image

Image

Image

Image

Image

Modbus (giao thức Modbus) is one of the simplest and oldest protocols. It works like reading and writing registers (thanh ghi). You ask: “give me register 100,” and the device responds. It’s widely used because it is easy to implement and debug.

Modbus là một trong những giao thức đơn giản và lâu đời nhất. Nó hoạt động giống như đọc/ghi các thanh ghi (register). Bạn yêu cầu “đọc thanh ghi 100,” và thiết bị trả về giá trị. Nó phổ biến vì dễ triển khai và debug.

The downside is that Modbus is not very efficient or expressive. It has no strong data model, limited structure, and weak built-in security. In modern systems, it is often used for simple devices, not complex coordination.

Nhược điểm là Modbus không hiệu quả và thiếu cấu trúc. Nó không có mô hình dữ liệu mạnh, ít linh hoạt, và bảo mật yếu. Trong hệ thống hiện đại, nó thường chỉ dùng cho thiết bị đơn giản.

OPC UA (OPC Unified Architecture) is a modern protocol designed for flexibility and interoperability. It provides a rich data model (mô hình dữ liệu), security, and supports both polling and event-driven communication.

OPC UA là giao thức hiện đại, linh hoạt và có khả năng tương thích cao. Nó cung cấp mô hình dữ liệu phong phú, bảo mật tốt, và hỗ trợ cả polling lẫn event-driven.

In real systems, OPC UA is often used between PLC and PC (.NET app). It allows you to expose structured data like “Machine.Status.Running” instead of raw memory addresses.

Trong thực tế, OPC UA thường được dùng giữa PLC và PC (.NET app). Nó cho phép bạn truy cập dữ liệu có cấu trúc như “Machine.Status.Running” thay vì địa chỉ bộ nhớ thô.

EtherCAT (Ethernet for Control Automation Technology) is designed for real-time (thời gian thực) control. It is extremely fast and deterministic (xác định được), often used in motion control systems like robotics or semiconductor machines.

EtherCAT được thiết kế cho điều khiển thời gian thực. Nó rất nhanh và có tính xác định cao (deterministic), thường dùng trong hệ thống điều khiển chuyển động như robot hoặc máy bán dẫn.

Its trade-off is complexity. Configuration, debugging, and integration are harder. You typically don’t interact with EtherCAT directly in .NET — it is handled by the PLC or motion controller.

Đổi lại, nó phức tạp hơn. Việc cấu hình, debug và tích hợp khó hơn. Thông thường bạn không làm việc trực tiếp với EtherCAT trong .NET — nó do PLC hoặc bộ điều khiển chuyển động xử lý.


4. REAL-TIME VS NON-REAL-TIME COMMUNICATION

Image

Image

Image

Image

Image

Real-time (thời gian thực) communication means deterministic timing. If you send a command, it will arrive within a known time window — not “usually fast,” but guaranteed behavior.

Truyền thông thời gian thực nghĩa là thời gian xác định được. Khi gửi lệnh, bạn biết chắc nó sẽ đến trong một khoảng thời gian xác định — không phải “thường nhanh,” mà là đảm bảo.

Non-real-time communication is more flexible but less predictable. Protocols like OPC UA or Modbus over TCP may have variable latency (độ trễ), depending on network conditions.

Truyền thông không thời gian thực linh hoạt hơn nhưng ít dự đoán. Các giao thức như OPC UA hoặc Modbus TCP có thể có độ trễ thay đổi tùy theo mạng.

Motion control requires real-time communication. If a motor command is delayed, the machine may vibrate, misalign, or damage the product.

Điều khiển chuyển động cần thời gian thực. Nếu lệnh motor bị trễ, máy có thể rung, lệch vị trí hoặc làm hỏng sản phẩm.

Monitoring and UI updates can tolerate delay. A 100ms delay in displaying temperature is acceptable — but not in stopping a moving axis.

Giám sát và UI có thể chấp nhận độ trễ. Trễ 100ms khi hiển thị nhiệt độ là chấp nhận được — nhưng không thể chấp nhận khi dừng trục chuyển động.


5. HOW .NET APPLICATIONS INTERACT

Image

Image

Image

Image

Image

Image

A .NET application typically acts as a client communicating with a PLC. It reads data (sensor values, machine status) and writes commands (start, stop, setpoints).

Ứng dụng .NET thường đóng vai trò client giao tiếp với PLC. Nó đọc dữ liệu (giá trị cảm biến, trạng thái máy) và ghi lệnh (start, stop, setpoint).

There are two main patterns: polling (thăm dò) and event-driven (sự kiện). Polling means repeatedly asking for data. Event-driven means the PLC pushes updates when something changes.

Có hai cách chính: polling (thăm dò) và event-driven (dựa trên sự kiện). Polling là liên tục hỏi dữ liệu. Event-driven là PLC gửi dữ liệu khi có thay đổi.

In real systems, you often combine both. Critical status may be event-driven, while less important data is polled periodically.

Trong thực tế, bạn thường kết hợp cả hai. Dữ liệu quan trọng dùng event-driven, còn dữ liệu ít quan trọng dùng polling theo chu kỳ.


6. DATA MODEL — WHAT IS ACTUALLY SENT

Image

Image

Image

Image

Image

Image

Image

Image

What actually flows over the protocol is not “objects” but tags (biến / tag) or variables. These represent sensor readings, states, or commands.

Thứ thực sự được truyền không phải là “object” mà là các tag (biến). Chúng đại diện cho giá trị cảm biến, trạng thái, hoặc lệnh.

The mapping between PLC memory and .NET variables is critical. A bad mapping leads to confusion, bugs, and unsafe behavior.

Việc mapping giữa bộ nhớ PLC và biến trong .NET rất quan trọng. Mapping kém sẽ gây lỗi, khó hiểu và có thể nguy hiểm.

Good systems use structured naming like “Axis1.Position” instead of raw addresses. This makes the system maintainable.

Hệ thống tốt sử dụng tên có cấu trúc như “Axis1.Position” thay vì địa chỉ thô. Điều này giúp dễ bảo trì.


7. REAL-WORLD PROBLEMS

Image

Image

Image

Image

Image

Image

Image

Image

In real machines, communication is never perfect. You will face latency (độ trễ), packet loss (mất gói), and disconnections.

Trong thực tế, truyền thông không bao giờ hoàn hảo. Bạn sẽ gặp độ trễ, mất gói, và mất kết nối.

These issues directly affect machine behavior. A delayed stop command can be dangerous. Missing data can lead to incorrect decisions.

Những vấn đề này ảnh hưởng trực tiếp đến hành vi của máy. Lệnh dừng bị trễ có thể nguy hiểm. Dữ liệu thiếu có thể dẫn đến quyết định sai.

A common mistake from software engineers is assuming “eventually consistent” is acceptable. In machines, sometimes you need “immediately correct.”

Sai lầm phổ biến của lập trình viên là nghĩ “eventually consistent” là đủ. Trong máy công nghiệp, nhiều lúc bạn cần “chính xác ngay lập tức.”


8. RELIABILITY & SAFETY

Image

Image

Image

Image

Image

Image

Industrial systems implement retries, heartbeat signals, and watchdog timers to detect failures.

Hệ thống công nghiệp sử dụng retry, heartbeat, và watchdog timer để phát hiện lỗi.

A heartbeat (tín hiệu sống) is a periodic signal that confirms communication is alive. If it stops, the system assumes failure.

Heartbeat là tín hiệu định kỳ xác nhận kết nối còn hoạt động. Nếu mất, hệ thống coi là lỗi.

Safety is always prioritized. If communication fails, the machine should go to a safe state (trạng thái an toàn), not continue blindly.

An toàn luôn được ưu tiên. Nếu mất kết nối, máy phải chuyển về trạng thái an toàn, không tiếp tục chạy.


9. SIMPLE END-TO-END EXAMPLE

Image

Image

Image

Image

Image

Image

A user clicks “Start” on the UI. The .NET app writes a command via the protocol (giao thức) to the PLC.

Người dùng nhấn “Start” trên UI. Ứng dụng .NET gửi lệnh qua giao thức đến PLC.

The PLC receives the command, validates safety conditions, and activates actuators to start the machine.

PLC nhận lệnh, kiểm tra điều kiện an toàn, và kích hoạt cơ cấu chấp hành để chạy máy.

The PLC then sends status updates back (running, error, position), and the UI reflects the real-time state.

PLC gửi trạng thái ngược lại (đang chạy, lỗi, vị trí), và UI hiển thị theo thời gian thực.


10. HOW TO THINK ABOUT INDUSTRIAL COMMUNICATION

Industrial communication is not like calling a web API. It is tightly coupled with physical behavior and timing.

Truyền thông công nghiệp không giống gọi API web. Nó gắn chặt với hành vi vật lý và thời gian.

You must think in terms of determinism (tính xác định), latency (độ trễ), and failure handling — not just “does the request succeed.”

Bạn phải suy nghĩ theo tính xác định, độ trễ, và xử lý lỗi — không chỉ là “request có thành công không.”

In this domain, communication errors are system errors. They are not edge cases — they are part of the design.

Trong domain này, lỗi truyền thông là lỗi hệ thống. Không phải edge case — mà là một phần của thiết kế.

Docs-first project memory for AI-assisted implementation.