Giới thiệu về Modbus sử dụng LabVIEW
Tổng quan
Giao thức công nghiệp Modbus được phát triển vào năm 1979 như một công cụ hỗ trợ giao tiếp giữa các thiết bị tự động hóa. Ban đầu được triển khai như một giao thức cấp ứng dụng (application-level protocol) nhằm truyền dữ liệu qua lớp nối tiếp, giao thức này đã được mở rộng để bao gồm các triển khai qua nối tiếp, TCP/IP và UDP. Ngày nay, Modbus là một giao thức phổ biến được vô số thiết bị sử dụng để liên lạc đơn giản, đáng tin cậy và hiệu quả trên nhiều mạng hiện đại.
Giới thiệu về Modbus
Modbus thường được sử dụng cho giao tiếp mạng kiểu điều khiển giám sát và thu thập dữ liệu (Supervisory Control and Data Acquisition - SCADA) giữa các thiết bị. Ví dụ: một server lớn có thể được sử dụng để điều khiển PLC (Programmable Logic Controller) hoặc PAC (Programmable Automation Controller), và PLC/PAC đó lại có thể lần lượt điều khiển cảm biến, van, động cơ hoặc bất kỳ thiết bị nhúng nào khác.
Để đáp ứng những nhu cầu này, Modbus được thiết kế như một giao thức đáp ứng yêu cầu với mô hình chức năng và dữ liệu linh hoạt - các tính năng là một phần lý do khiến nó vẫn được sử dụng cho đến ngày nay.
Chu kỳ Request - Response
Giao thức Modbus tuân theo kiến trúc Master và Slave trong đó Master truyền yêu cầu đến Slave và chờ phản hồi. Kiến trúc này cung cấp cho tổng thể toàn quyền kiểm soát luồng thông tin, điều này có lợi trên các mạng nối tiếp nhiều tầng cũ hơn. Ngay cả trên các mạng TCP/IP hiện đại, nó mang lại cho Master mức độ kiểm soát cao đối với hành vi của Slave, điều này rất hữu ích trong một số thiết kế.
Trong Modbus, Request (yêu cầu) này là một tập hợp dữ liệu được phân lớp. Lớp đầu tiên là đơn vị dữ liệu ứng dụng (ADU), đây là đoạn thông tin giúp hầu hết mọi người biết được “loại” Modbus được sử dụng. Có ba ADU: ASCII, RTU (Remote Terminal Unit) và TCP/IP.
TCP là một định dạng hiện đại cho phép xử lý hiệu quả các yêu cầu và phản hồi Modbus trong phần mềm, cũng như kết nối mạng hiệu quả hơn thông qua việc sử dụng các kết nối và bộ nhận dạng chuyên dụng cho từng yêu cầu. RTU và ASCII là các định dạng ADU nối tiếp cũ hơn với sự khác biệt là: RTU sử dụng phép biểu diễn nhị phân nhỏ gọn trong khi ASCII gửi tất cả các yêu cầu dưới dạng luồng ký tự ASCII.
Đối với hầu hết các ứng dụng, ADU được ưu tiên phụ thuộc vào mạng vật lý mong muốn (Ethernet, Serial hoặc các kết nối khác), số lượng thiết bị trên mạng và ADU được hỗ trợ bởi thiết bị chính và phụ trên mạng. Từ góc nhìn của ứng dụng sử dụng Modbus, dữ liệu của ADU không cần thiết để hiển thị trên màn hình người dùng.
Trong mỗi ADU, có một khối dữ liệu giao thức (Protocol Data Unit - PDU) là cốt lõi của giao thức Modbus. Mỗi PDU chứa một mã chức năng và dữ liệu liên quan. Mỗi mã chức năng có một phản hồi được xác định rõ và bạn có thể coi mã chức năng này giống như lệnh được gửi đến Slave.
Trong một số trường hợp, lỗi có thể xảy ra. Modbus định nghĩa một PDU cụ thể cho các trường hợp ngoại lệ, cho phép Master biết điều gì đã xảy ra. Hầu hết các driver chuyển đổi điều này thành một loại hình thức có ý nghĩa đối với ngôn ngữ hoặc ứng dụng đang sử dụng.
Mô hình dữ liệu Modbus
Modbus quản lý việc truy cập dữ liệu một cách đơn giản và linh hoạt. Về bản chất, Modbus hỗ trợ hai loại dữ liệu: giá trị Boolean và số nguyên 16 bit không dấu.
Trong các hệ thống SCADA, các thiết bị nhúng thường có các giá trị nhất định được định nghĩa làm ngõ vào, chẳng hạn như cài đặt độ lợi hoặc PID (Proportional Integral Derivative), trong khi các giá trị khác là ngõ ra, như nhiệt độ hiện tại hoặc vị trí của van. Để đáp ứng nhu cầu này, các giá trị dữ liệu Modbus được chia thành bốn phạm vi (xem Bảng 1). Một Slave có thể xác định tới 65.536 phần tử trong mỗi phạm vi.
| Memory Block | Data Type | Master Access | Slave Access |
| Coils | Boolean | Read/Write | Read/Write |
| Discrete Inputs | Boolean | Read-only | Read/Write |
| Holding Registers | Unsigned Word | Read/Write | Read/Write |
| Input Registers | Unsigned Word | Read-only | Read/Write |
Bảng 1. Khối mô hình dữ liệu Modbus
Trong nhiều trường hợp, cảm biến và các thiết bị khác tạo ra dữ liệu khác loại với các kiểu Boolean đơn giản và số nguyên không dấu. Các thiết bị Slave thường chuyển đổi các loại dữ liệu lớn hơn này thành các Register (thanh ghi). Ví dụ: một cảm biến áp suất có thể chia một giá trị floating-point 32 bit thành hai Register 16 bit.
Modbus hiển thị các giá trị này theo cách mang tính khái niệm, nghĩa là chúng có thể không thực sự tồn tại trong bộ nhớ. Ví dụ, một thiết bị Slave có thể được định nghĩa sao cho các Holding Registers và Input Registers thực sự chia sẻ cùng một bộ nhớ nếu hành vi đó có ý nghĩa đối với Slave. Trong hầu hết các trường hợp, Slave lưu trữ từng loại dữ liệu mà nó hỗ trợ trong bộ nhớ riêng biệt và giới hạn số lượng phần tử dữ liệu mà Master có thể truy cập. Tính linh hoạt này là một tùy chọn do cách dữ liệu được hiển thị thông qua hành vi được xác định rõ của các mã chức năng Modbus.
Mã chức năng Modbus
Mã chức năng Modbus xác định cách dữ liệu được truy cập và sửa đổi bởi Master. Không giống như phạm vi dữ liệu mang tính khái niệm, mã chức năng có hành vi được xác định rõ. Khi một Slave được yêu cầu thực hiện một mã hàm, nó sẽ sử dụng các tham số của hàm để thực hiện hành vi được xác định rõ đó. Hình 2 cho thấy liên kết này giữa một Modbus Request và bộ nhớ thực của thiết bị.
Các mã chức năng phổ biến nhất được đặt tên theo phạm vi dữ liệu khái niệm mà chúng sửa đổi hoặc truy cập. Ví dụ: “đọc Holding Registers” thực hiện hành động lấy dữ liệu ra khỏi bộ nhớ được định nghĩa là các Register giữ và trả lại cho bản gốc. Bảng 2 định nghĩa các mã chức năng phổ biến nhất.
Bắt đầu với Modbus trong LabVIEW
NI cung cấp ba cơ chế chính để giao tiếp với các thiết bị Modbus: (1) OPC Server cấp cao, (2) Modbus I/O Server và (3) Modbus API cấp thấp được giới thiệu trong phần mềm NI LabVIEW 2014 thông qua các mô-đun LabVIEW Real-Time hay LabVIEW Datalogging and Supervisory Control (DSC).
LabVIEW Modbus API
Modbus API cấp thấp là tùy chọn ưa thích khi ứng dụng của bạn cần mức độ kiểm soát cao đối với trình tự và thời gian của các yêu cầu Modbus. API cấp thấp thường cũng là lựa chọn ưu tiên khi tính linh hoạt là tối quan trọng. Ngược lại, tính linh hoạt và sức mạnh do LabVIEW Modbus API cung cấp cũng có ý nghĩa là mã ứng dụng của bạn phải phức tạp hơn để quản lý API một cách chính xác. Để giúp bạn hiểu được sự phức tạp này, LabVIEW cung cấp hai ví dụ.
Ví dụ giới thiệu Modbus
Ví dụ đầu tiên, Modbus Library.lvproj, cung cấp tổng quan cơ bản về chức năng của API. Nó cũng cho thấy sự khác biệt giữa việc triển khai trên PC và mục tiêu Real-Time. Hình 3 cho thấy mã liên quan đến ví dụ Modbus Master trong Real-Time.
Hình 3. Master trên RT Target.vi
Ví dụ này minh họa các yêu cầu cốt lõi của ứng dụng Modbus sử dụng LabVIEW API. Đầu tiên, một Modbus instance được tạo. Trong trường hợp này, là một TCP Master. Tuy nhiên, bạn có thể chuyển sang bản Serial Master bằng cách thay đổi như hình sau.
Hình 4. Thay đổi loại Modbus Master
Khi instance được tạo, bạn có thể bắt đầu cho thiết bị Slave lấy dữ liệu. Ví dụ cho thấy việc sử dụng mã chức năng Read Input Registers. Tất cả các mã chức năng Modbus được hỗ trợ bởi API được hiển thị trên bảng màu thích hợp. Do việc triển khai giao thức, Slave API có các chức năng bổ sung mà Master không thể thực hiện. Ví dụ, một Slave có thể ghi vào phạm vi Input Register, trong khi Master chỉ có thể đọc từ phạm vi đó. Hình 5 cho thấy các mã chức năng.
Hình 5. Bảng hiển thị mã chức năng Modbus Master và Slave
Cuối cùng, instance của Modbus được đóng lại, hủy phân bổ bộ nhớ hiện tại được liên kết với instance. Thao tác này cũng đóng mọi tham chiếu, bao gồm cả kết nối TCP hoặc tham chiếu NI-VISA serial mà instance sử dụng.
Mọi ví dụ đều tuân theo cùng một mẫu cơ bản quen thuộc với hầu hết người dùng LabVIEW: Open, Read/Write, và Close.
Cuối cùng, mặc dù API trông giống nhau, nhưng điều quan trọng là người dùng phải hiểu sự khác biệt chính. Nếu thiết bị của bạn là thiết bị Master, thiết bị phải gửi yêu cầu qua mạng đến thiết bị Slave thích hợp để thu thập dữ liệu. Mặt khác, Slave có bộ lưu trữ dữ liệu cục bộ của riêng nó và có thể truy cập nó một cách nhanh chóng.
Ví dụ về Redundant Master
Ví dụ cơ bản có thể đủ cho một số ứng dụng; tuy nhiên, nó có thể không đủ cho các ứng dụng phức tạp mà mục tiêu chính ở đây là giao tiếp với cảm biến hoặc cổng. Để giúp thu hẹp khoảng cách này, một ứng dụng mẫu cho biết cách sử dụng hai Master để giao tiếp với một Slave nhất định. Nếu một trong các hai Master bị lỗi và mất kết nối với Slave hoặc giao diện người-máy (HMI), thì Master khác sẽ tiếp quản.
Hình 6. Thiết kế của ví dụ Redundant Master
Nếu thiết kế này đáp ứng được nhu cầu của ứng dụng của bạn hoặc nếu bạn quan tâm đến một ví dụ phức tạp hơn về giao tiếp Modbus, hãy xem Redundant Modbus Masters.lvproj trong Example Finder.
Modbus I/O Server
Các Modbus I/O server, nằm trong các mô-đun LabVIEW DSC và LabVIEW Real-Time, cung cấp một công cụ cấp cao để giao tiếp qua Modbus. Thay vì chỉ định mã chức năng mà bạn muốn gửi, bạn đăng ký bộ dữ liệu bạn muốn truy cập và I/O server tự động lên lịch cho các yêu cầu theo tốc độ đã chỉ định.
Để sử dụng I/O server, bạn thêm một I/O server mới vào mục tiêu mong muốn trong dự án của bạn. Như với API cấp thấp, bạn có thể chọn giữa Modbus Master hoặc Slave, và những điều này dẫn đến các tham số bổ sung. Ví dụ: Master có Polling Rate xác định - tốc độ mà mọi yêu cầu được gửi đến Slave, trong khi Slave phải đợi các yêu cầu đó và không có thời gian xác định trước.
Sau khi I/O server được tạo, bạn có thể chỉ định các mục trên thiết bị mà bạn muốn đọc. Không giống như API cấp thấp, nơi bạn phải tự tạo và xử lý các yêu cầu, I/O server cho phép bạn chọn từ nhiều định dạng và kiểu dữ liệu khác nhau. Ví dụ: bạn có thể đọc Holding Register tại địa chỉ 0 bằng cách ánh xạ một biến tới item 400001, đọc bit đầu tiên của Register này bằng cách chọn 400001.1 và đọc số float chính xác duy nhất được lưu trong Register 0 và 1 bằng cách chọn F400001.
Sau khi chọn các biến để truy cập, bạn có thể đọc hoặc ghi các biến này bằng cách sử dụng các Shared Variable Node trên sơ đồ khối. Bạn thậm chí có thể đặt bí danh (alias) cho tên biến.
Hình 7. Một ứng dụng I/O Server đơn giản
Việc dễ sử dụng này đi kèm với những hạn chế. Dữ liệu chỉ cập nhật ở tốc độ được xác định trước và không có cách nào để thêm hoặc xóa dữ liệu được yêu cầu trong thời gian chạy. Nếu những hạn chế này có thể chấp nhận được đối với ứng dụng của bạn, thì I/O server là tùy chọn đa nền tảng được đề xuất.
NI OPC Servers với OPC I/O Servers hoặc OPC UA
Đối với các ứng dụng phức tạp liên quan đến nhiều thiết bị Slave giao tiếp qua các giao thức khác nhau, Modbus I/O tiêu chuẩn có thể không đủ. Một giải pháp phổ biến là sử dụng OPC server, hoạt động như một bộ tổng hợp dữ liệu cho tất cả các hệ thống của bạn, sau đó sử dụng OPC I/O server có trong mô-đun LabVIEW DSC để giao tiếp với OPC server đó.
Hình 8 cho thấy một ví dụ về kiến trúc này, với NI OPC server sử dụng Modbus để giao tiếp trực tiếp với các cảm biến và OPC UA để giao tiếp với bộ điều khiển CompactRIO. Sau khi dữ liệu được tổng hợp trong NI OPC server, OPC I/O server có thể truy xuất dữ liệu và chia sẻ dữ liệu đó với ứng dụng LabVIEW.
Hình 8. Một ứng dụng SCADA sử dụng Modbus, NI OPC server và OPC I/O server
Bạn cũng có thể phát triển một kiến trúc tương tự sử dụng OPC UA Toolkit (chức năng OPC UA đã được đưa vào mô-đun LabVIEW DSC trước phiên bản 2017) thay cho các OPC I/O server. Tuy nhiên, OPC UA driver là driver cấp thấp và không cung cấp khả năng sử dụng dễ dàng của các OPC I/O server.
Để phát triển một ứng dụng như thế này, trước tiên bạn phải tạo một cấu hình hợp lệ cho NI OPC server để giao tiếp với các thiết bị phụ của bạn. Điều này được thực hiện bằng cách tạo các kênh - xác định cấu hình driver - và các thiết bị - xác định endpoint riêng lẻ cho trình driver đó. Sau khi bạn đã định cấu hình thiết bị, bạn có thể tạo thẻ.
Hình 9. Cấu hình mẫu trong NI OPC server cho kiến trúc trên
Và sau khi bạn đã định cấu hình NI OPC server, bạn có thể định cấu hình OPC I/O server để giao tiếp với các thẻ này. Trong khi các Modbus I/O server được cấu hình để truy cập các Register, các OPC I/O server được cấu hình để truy cập các thẻ trong OPC server.
Quá trình ràng buộc này tạo ra các biến mà sau đó bạn có thể sử dụng trong ứng dụng của mình.
Hình 11. Một ứng dụng đơn giản sử dụng OPC I/O server
Đáp ứng nhu cầu ứng dụng của bạn
Modbus là một giao thức đơn giản mà bạn có thể sử dụng theo nhiều cách khác nhau để triển khai các ứng dụng mạnh mẽ.
Đối với giao tiếp Modbus, NI cung cấp ba tùy chọn chính, mang đến một loạt các chức năng để đáp ứng nhu cầu của ứng dụng của bạn.
- Đầu tiên, một API cấp thấp cung cấp khả năng kiểm soát tốt đối với giao thức, với hiệu suất cao, với chi phí dễ sử dụng. Mọi thứ phải được thực hiện thủ công khi sử dụng API cấp thấp.
- Đối với các ứng dụng giám sát đơn giản hơn, Modbus I/O server cung cấp API đơn giản và dễ dàng hơn để truy cập hoặc cung cấp dữ liệu Modbus. Để đổi lấy sự dễ sử dụng, các I/O server không có quyền kiểm soát chặt chẽ đối với giao thức có thể được yêu cầu đối với một số ứng dụng.
- Cuối cùng, đối với các hệ thống lớn và phức tạp, một OPC server đầy đủ tính năng có thể là phương án lý tưởng để phục vụ như một bộ tổng hợp dữ liệu. Sau đó, chỉ cần sử dụng một công cụ như LabVIEW OPC UA Toolkit hoặc OPC I/O server để cung cấp cho ứng dụng của bạn quyền truy cập vào dữ liệu này.
Tham khảo các thiết bị hỗ trợ giao tiếp trong công nghiệp đến từ NI: https://www.peritec.vn/product_category/ni-communication-protocol/
Tham khảo các thiết bị hỗ trợ giao tiếp trong công nghiệp đến từ Ixxat: https://www.peritec.vn/ixxat/ixxat-products/products-industrial/
