Modbus hay MODBUS là một giao thức truyền thông ở tầng Application theo mô hình OSI, hỗ trợ giao tiếp theo mô hình client/server giữa các thiết bị kết nối trong nhiều loại bus hoặc mạng khác nhau.[1] Modbus được Modicon (nay là Schneider Electric) xuất bản vào năm 1979 để sử dụng với các bộ PLC của chính hãng này.[2] Modbus sau đó đã trở thành một giao thức truyền thông tiêu chuẩn de facto và là một phương tiện phổ biến để kết nối các thiết bị điện tử công nghiệp.[3]
Modbus phổ biến trong môi trường công nghiệp vì nó được xuất bản công khai và miễn phí bản quyền. Nó được phát triển cho các ứng dụng công nghiệp, tương đối dễ triển khai và bảo trì so với các tiêu chuẩn khác và có ít hạn chế, ngoài kích thước gói dữ liệu, và định dạng dữ liệu được truyền.
Giao thức Modbus sử dụng các cổng truyền thông nối tiếp, Ethernet hoặc bộ giao thức Internet làm lớp truyền tải (transport layer) để hỗ trợ giao tiếp truyền và nhận từ nhiều loại bus hoặc mạng khác nhau.[1] Ví dụ, có thể có một thiết bị đo nhiệt độ và một thiết bị khác đo độ ẩm cùng được kết nối với cùng một cáp, cả hai đều có thể truyền dữ liệu đo được đến cùng một máy tính, thông qua Modbus.
Modbus thường được sử dụng để kết nối máy tính sử dụng trong quá trình giám sát nhà máy/hệ thống với một thiết bị đầu cuối từ xa (RTU) trong hệ thống Kiểm soát Giám sát và Thu thập Dữ liệu (SCADA) trong ngành điện lực. Trong Modbus, nhiều kiểu dữ liệu được đặt tên từ các khái niệm điều khiển công nghiệp của các thiết bị nhà máy như một ngõ ra vật lý đơn được gọi là coil và một ngõ vào vật lý đơn được gọi là discrete input hoặc contact.
Việc phát triển và cập nhật các giao thức Modbus do Modbus Organization quản lý kể từ tháng 4 năm 2004, khi Schneider Electric chuyển giao quyền cho tổ chức này.[4] Modbus Organization là một hiệp hội của những người dùng và nhà cung cấp các thiết bị Modbus thúc đẩy việc sử dụng bộ giao thức truyền thông này, cũng như việc giải quyết vấn đề kiến trúc cho các hệ thống tự động hóa phân tán trên nhiều phân khúc thị trường.[5]
Các chuẩn truyền hoặc mạng hiện tại đã được triển khai với Modbus bao gồm:[1]
Để hỗ trợ cho việc truyền thông dữ liệu trên mạng Modbus, có nhiều modem và gateway được thiết kế riêng để hỗ trợ giao thức Modbus (xem hình: Kiến trúc của một hệ thống mạng với Modbus).
Modbus định nghĩa protocol data unit, viết tắt PDU, (tạm dịch: đơn vị dữ liệu của giao thức) độc lập với các giao thức hoạt động ở tầng dưới (xem hình: Mô hình triển khai của các giao thức với Modbus). Việc ánh xạ giao thức Modbus với các loại bus hoặc mạng cụ thể sẽ sinh thêm các trường tương ứng, từ đó hình thành các application data unit, viết tắt: ADU (tạm dịch: đơn vị dữ liệu của ứng dụng). ADU sẽ được hình thành bởi một client trong mạng Modbus khi client này khởi tạo một transaction (tạm dịch: kết nối). Cụ thể, thành phần của PDU và ADU sẽ bao gồm:[6]
ADU còn được gọi một cách thông dụng là Modbus frame như trong tài liệu chính thức của Modbus[6] và ở các ứng dụng triển khai thực tế, dù frame là từ để chỉ đơn vị dữ liệu ở tầng Data-link trong mô hình OSI và TCP/IP (trong khi Modbus là giao thức ở tầng Application).
Kích thước tối đa của PDU là 253 byte. Kích thước tối đa của ADU với RS232/RS485 là 256 byte, với TCP là 260 byte.[7]
Modbus sử dụng ‘big-Endian’ để đại diện cho trường address và data. Khi đó, với giá trị 16 bit thì byte MSB sẽ được truyền đi trước. Ví dụ: Với giá trị 0x1234 trong thanh ghi 16 bit, byte 0x12 sẽ được truyền đi trước rồi mới đến 0x34.[7]
Trường function code có kích thước 1 byte, có nhiệm vụ cho server biết phải thực thi hành động gì. Giá trị function code từ 1 đến 255 (giá trị thập phân), với khoảng giá trị từ 128 - 255 dùng cho các exception response (tạm dịch: phản hồi ngoại lệ).
Mỗi trường data trong PDU sẽ có địa chỉ từ 0 đến 65535 (không nhầm lẫn với địa chỉ trong trường Additional address của ADU).[8] Trường data có thể không có, khi đó sẽ có kích thước là 0, trong trường hợp này server sẽ không yêu cầu thông tin gì cả và function code khi đó sẽ định rõ hành động cần thực thi. Nếu không có lỗi xảy ra trong quá trình giao tiếp, trường data của ADU trong phản hồi từ server cho client sẽ bao gồm các data được yêu cầu. Nếu xảy ra lỗi, trường bao gồm mã lỗi ngoại lệ (exception code) sẽ được ứng dụng từ phía server (server application) dùng để xác định sẽ làm gì tiếp theo.[9]
Một Modbus transaction giữa client và server sẽ hoạt động như sau:[9][10]
Từ hoạt động trên, Modbus định nghĩa 3 loại PDU:[7]
mb_req_pdu = Function code (1 byte) + request data (n byte)
Trường request data sẽ có kích thước cụ thể phụ thuộc vào loại function code và thường gồm các thông tin như giá trị biến, data offset, sub-function codes,...
mb_rsp_pdu = Function code (1 byte) + response data (n byte)
Trường response data sẽ có kích thước cụ thể phụ thuộc vào loại function code và thường gồm các thông tin như giá trị biến, data offset, sub-function codes,...
mb_excep_rsp_pdu = Exception Function code (1 byte) + request data (n byte)
Exception Function code = Function code (1 byte) + 0x80
Khi đó Exception Function code sẽ có bit MSB bằng 1, các bit còn lại giống với Function code.
Exception code (1 byte) của mb_excep_rsp_pdu sẽ được định nghĩa trong bảng "MODBUS Exception Codes".
Modbus xây dựng mô hình dữ liệu dựa trên các table (tạm dịch: bảng) có thuộc tính khác nhau, với 4 primary table (tạm dịch: bảng cơ sở) là:[11]
Primary table | Quyền | Kích thước | Chú thích |
---|---|---|---|
Discretes input | Chỉ đọc | 1 bit | Kiểu dữ liệu này có thể được cung cấp bởi một hệ thống I/O |
Coils | Đọc/Ghi | 1 bit | Kiểu dữ liệu này có thể được thay đổi bởi phần mềm ứng dụng |
Input registers | Chỉ đọc | 16 bit word | Kiểu dữ liệu này có thể được cung cấp bởi một hệ thống I/O |
Holding registers | Đọc/Ghi | 16 bit word | Kiểu dữ liệu này có thể được thay đổi bởi phần mềm ứng dụng |
Có 3 loại Modbus Function code là Public, User-Defined và Reserved.[12]
Public Function Codes là loại function code được Modbus Organization định nghĩa và mang giá trị duy nhất với các tài liệu liên quan được công bố rõ ràng.
Bảng Public Function Code:[13]
Loại chức năng | Tên chức năng | Function code (giá trị thập phân) | Ghi chú | ||
---|---|---|---|---|---|
Data Access | Truy cập 1 bit | Ngõ đầu vào vật lý rời rạc | Đọc Discrete Inputs | 02 | |
Bits nội hoặc coil vật lý | Đọc coil | 01 | |||
Ghi một coil | 05 | ||||
Ghi nhiều coil | 15 | ||||
Truy cập 16 bit | Thanh ghi vật lý đầu vào | Đọc input register | 04 | ||
Thanh ghi nội bộ hoặc thanh ghi đầu ra vật lý | Đọc nhiều holding register | 03 | |||
Ghi một thanh ghi | 06 | ||||
Ghi nhiều thanh ghi | 16 | ||||
Đọc/ghi nhiều thanh ghi | 23 | ||||
Ghi thanh ghi Mask | 22 | ||||
Đọc hàng đợi FIFO | 24 | ||||
Truy cập File record | Đọc file record | 20 | |||
Ghi file record | 21 | ||||
Chuẩn đoán lỗi | Đọc lỗi trạng thái ngoại lệ | 07 | chỉ nối tiếp | ||
Chẩn đoán lỗi | 08 | chỉ nối tiếp | |||
Get Com event counter | 11 | chỉ nối tiếp | |||
Get Com Event Log | 12 | chỉ nối tiếp | |||
Báo Server ID | 17 | chỉ nối tiếp | |||
Đọc ID thiết bị | 43 | ||||
Khác | Đóng gói Interface Transport | 43 | |||
CANopen General Reference | 43 |
Lưu ý: Một số tài liệu sử dụng thuật ngữ Force thay cho Write, ví dụ như Force Single Coil thay cho Write Single Coil (Ghi một coil).[14]
Function code này cho phép đọc trạng thái của từ 1 đến 2000 coil của một thiết bị từ xa. mb_req_pdu (request PDU) khi đó sẽ có 2 byte cho biết địa chỉ của coil đầu tiên cần đọc (từ 0x0000 đến 0xFFFF) và 2 byte để cho biết số lượng coil cần đọc. mb_req_pdu sẽ định địa chỉ coil từ 0, tức là coil thứ 1 sẽ có địa chỉ 0. mb_rsp_pdu (response PDU) nếu đọc thành công sẽ có 1 byte mang giá trị cho biết số byte tương ứng số lượng coil cần đọc và số byte mang giá trị trạng thái của các coil cần đọc. Cụ thể, mb_rsp_pdu và mb_rsp_pdu sẽ có cấu trúc sau:[13]
mb_req_pdu
mb_rsp_pdu
Ví dụ của một mb_req_pdu và mb_rsp_pdu để đọc trạng thái coil thứ tự từ 20-38 sẽ bao gồm:[15]
mb_req_pdu:
Starting Address (2 byte) sẽ có giá trị 0x0013, hay 19 trong hệ thập phân tương ứng với coil thứ tự 20.
Quantity of Outputs (2 byte) sẽ có giá trị 0x0013, hay 19 trong hệ thập phân tương ứng với 19 giá trị trạng thái coil cần đọc (từ coil 20-38).
mb_rsp_pdu:
Do cần đọc 19 giá trị (20-38) nên cần 3 byte để biểu diễn các giá trị trạng thái coil. Do đó Byte Count mang giá trị 0x03. Trạng thái coil 20 đến 27 có giá trị 0xCD hex, dạng nhị phân sẽ là 1100 1101. Khi đó giá trị của coil 27 sẽ là MSB, còn coil 20 sẽ là LSB. Với coil 28 đến 35 cũng tương tự. Với coil từ 36 - 38, trạng thái sẽ là 0x05, dạng nhị phân sẽ là 0000 0101. Khi đó giá trị trạng thái của coil 38 sẽ là bit thứ 3 tính từ phải sang, tức là 1, còn giá trị trạng thái của coil thứ 36 sẽ là bit LSB. 5 bit còn lại sẽ đều được ghi giá trị 0.
User-Defined Function Codes là Function code do người dùng tự định nghĩa. Có 2 dãy giá trị cho user-defined function codes là từ 65 đến 72 và từ 100 đến 110 (giá trị thập phân). Việc sử dụng User-Defined Function Codes sẽ không đảm giá trị là duy nhất.[12]
Reserved Function Codes là các Function code được sử dụng bởi các sản phẩm của một số công ty.[12]
Khi một client gởi request đến server sẽ xảy ra một trong 4 khả năng với request này:[16]
Exception response message bao gồm 2 trường khác với một normal response message:[16]
Các giá trị exception code:[17]
Code | Tên | Ý nghĩa |
---|---|---|
01 | ILLEGAL FUNCTION | Function code nhận được trong truy vấn không được server công nhận hoặc cho phép |
02 | ILLEGAL DATA ADDRESS | Địa chỉ data nhận được trong truy vấn là địa chỉ không được cho phép trên server. |
03 | ILLEGAL DATA VALUE | Giá trị trong trường data của query là giá trị không được server chấp nhận. |
04 | SERVER DEVICE FAILURE | Đã xảy ra lỗi không thể khôi phục trong khi server đang cố gắng thực hiện hành động được yêu cầu |
05 | ACKNOWLEDGE | Server đã nhận được request yêu cầu và nhưng cần một khoảng thời gian dài để xử lý request này. Response này được trả lại để ngăn lỗi timeout xảy ra cho client. |
06 | SERVER DEVICE BUSY | Server đang xử lý một chương trình cần thời gian dài, client cần gởi lại request sau. |
08 | MEMORY PARITY ERROR | Server cố gắng đọc file record và phát hiện lỗi parity trong bộ nhớ. Client có thể thử lại request. |
10 | GATEWAY PATH UNAVAILABLE | Chuyên dùng trong việc nối các gateway. Thường cho biết gateway đã bị cấu hình sai hoặc quá tải |
11 | GATEWAY TARGET DEVICE FAILED TO RESPOND | Chuyên dùng trong việc nối các gateway. Cho biết không có phản hồi nào từ server, thường có nghĩa rằng thiết bị không tồn tại trong mạng. |
Tiêu chuẩn Modbus cũng chuẩn hóa MODBUS over Serial Line, một giao thức trên đường truyền nối tiếp để trao đổi các Modbus request giữa một master và nhiều slave.[18] Giao thức MODBUS over Serial Line là một giao thức dạng Master-Slave, nằm ở tầng Data Link (lớp 2) trong mô hình OSI.[19] Với giao thức truyền thông Modbus ở tầng Application, mô hình client/server được sử dụng giữa các thiết bị kết nối trên mạng hoặc bus. Với giao thức Modbus over Serial line, vai trò của client được thực hiện bởi Master, còn vai trò của server được thực hiện bởi Slave.[19]
Một bus nối tiếp hỗ trợ giao thức Modbus over Serial Line chỉ có một master và tối đa 247 slave, các slave trong mạng Modbus over Serial Line do đó bắt buộc phải có địa chỉ từ 1 đến 247 cho quá trình xác định địa chỉ trong quá trình truyền thông, và địa chỉ này phải là duy nhất.[20] Master sẽ không có địa chỉ cụ thể.[20] Quá trình truyền thông sẽ được khởi tạo bởi master, master chỉ có thể khởi tạo một Modbus transaction tại một thời điểm. Slave sẽ không bao giờ truyền dữ liệu nếu không nhận được request từ master, các slave cũng sẽ không bao giờ giao tiếp với nhau.[21]
Master sẽ khởi tạo request đến slave ở hai chế độ là unicast và broadcast. Trong chế độ unicast, master sẽ gởi request đến slave có địa chỉ cần đến. Sau khi nhận request và xử lý hoàn tất, slave sẽ phản hồi lại message reply cho master. Như vậy trong chế độ này, một Modbus transaction sẽ bao gồm 2 message: một request từ master và một reply từ slave. Trong chế độ broadcast, master sẽ gởi request đến toàn bộ slave, với địa chỉ broadcast sẽ là 0[20] (đây không phải địa chỉ của master vì master không có địa chỉ cụ thể). Các broadcast request được dùng cho quá trình ghi lệnh (command) đến slave. Không có message phản hồi từ slave trả về cho master trong chế độ này và tất cả các slave bắt buộc phải nhận broadcast request từ master.[21]
Việc ánh xạ PDU của Modbus với bus nối tiếp của giao thức Modbus over Serial Line sinh ra Modbus Serial Line PDU.[20]
Modbus over Serial Line PDU = Address + PDU + CRC (hoặc LRC)
Với PDU = Function code + Data
Trên tầng Physical (tầng 1), MODBUS over Serial Line triển khai với RS485 hoặc RS232, với TIA/EIA-485 2 dây (TIA/EIA-485 Two-Wire interface) là phổ biến nhất. RS485 4 dây (RS485 Four-Wire interface) cũng có thể được dùng để triển khai. TIA/EIA-232-E (RS232) cũng có thể được sử dụng nhưng chỉ dùng cho các ứng dụng giao tiếp điểm-điểm tầm ngắn.[19] MODBUS over Serial Line có 2 chế độ truyền là RTU và ASCII tương ứng với 2 loại Modbus RTU và Modbus ASCII.[22]
Mỗi 1 byte (8 bit) data/message của Modbus RTU truyền đi sẽ có định dạng tổng cộng 11 bit bao gồm:[22]
Một frame truyền của Modbus RTU sẽ bao gồm[23]
Địa chỉ slave | Function Code | Data | CRC |
---|---|---|---|
1 byte | 1 byte | 0 đến 252 byte | 2 byte gồm 1 byte CRC thấp (trước) và 1 byte CRC cao (sau) |
Để đảm bảo quá trình truyền thông trọn vẹn, thời gian cách nhau của các frame truyền Modbus RTU nên ít nhất bằng thời gian truyền của 3.5 ký tự và thời gian cách nhau để truyền 2 ký tự liên tiếp tối đa bằng thời gian truyền của 1.5 ký tự.[23]
Ví dụ với baudrate bằng 19200 bps, thời gian truyền 3.5 (t3.5) và 1.5 (t1.5) ký tự sẽ là (lưu ý 1 ký tự được biểu diễn bằng mã ASCII với 8 bit (1 byte) thì sẽ cần 11 bit để truyền):
Modbus RTU khuyến khích sử dụng giá trị 750µs cho thời gian t1.5 và 1.750ms cho t3.5.[23]
Khi giao thức MODBUS Serial Line hoạt động ở chế độ ASCII, mỗi byte sẽ được truyền đi dưới dạng 2 ký tự ASCII.[24]
Thành phần frame dữ liệu của Modbus ASCII bao gồm: 1 bit start, 7 bit dữ liệu với bit LSB được gởi trước, 1 bit để kiểm tra chẵn lẻ, 1 stop bit nếu dùng parity hoặc 2 bit nếu không dùng parity. Bên cạnh frame dữ liệu, Modbus ASCII còn dùng thêm trường kiểm tra lỗi hình thành theo phương pháp Longitudinal Redundancy Check[25] (tạm dịch: Kiểm dư theo chiều dọc). Modbus ASCII message bắt đầu bởi dấu hai chấm (":", với mã ASCII là 0x3A) và kết thúc bởi cặp ký dự dòng mới ở cuối là CR/LF (mã ASCII là 0x0D và 0x0A).
Tên | Chiều dài (byte) | Hàm số |
---|---|---|
Start | 1 | Bắt đầu bằng dấu hai chấm : (Giá trị hex ASCII là 3A )
|
Address | 2 | Địa chỉ station |
Function | 2 | Cho biết các mã chức năng như đọc coil/đầu vào |
Data | n × 2 | Dữ liệu + độ dài sẽ được điền tùy thuộc vào loại message |
LRC | 2 | Checksum (Longitudinal redundancy check) |
End | 2 | Cặp Carriage return + line feed (CR/LF) (các giá trị ASCII 0D , 0A )
|
Định dạng frame của Modbus ASCII này chủ yếu được sử dụng trên các đường nối tiếp không đồng bộ 7 hoặc 8-bit.
Địa chỉ, hàm, dữ liệu và LRC đều là các cặp ký tự có thể đọc được trong hệ thập lục phân viết hoa đại diện cho các giá trị 8 bit (0–255). Ví dụ, 122 (7 × 16 + 10) sẽ được biểu thị là 7A
.
LRC được tính bằng tổng các giá trị 8 bit (không bao gồm ký tự đầu và cuối), phủ định (phần bù của hai) và được mã hóa dưới dạng giá trị 8 bit. Ví dụ: nếu địa chỉ, hàm và dữ liệu mã hóa thành 247, 3, 19, 137, 0 và 10, thì tổng của chúng là 416. Phần bù của hai (−416) được cắt thành 8 bit là 96 (ví dụ: 256 × 2 - 416), sẽ được biểu diễn dưới dạng 60
trong hệ thập lục phân. Do đó khung sau :F7031389000A60<CR><LF>
. Nó chỉ được chỉ định để sử dụng làm tổng kiểm tra: bởi vì nó được tính toán trên dữ liệu được mã hóa chứ không phải các ký tự được truyền, đặc tính 'Dọc' của nó không có sẵn để sử dụng với các bit chẵn lẻ để xác định lỗi một bit.
Trường CRC gồm 2 byte với giá trị được tính toán bởi bên truyền đi rồi thêm giá trị CRC này vào PDU. Đa thức sinh (generating polynomial) quy định cho Modbus tên là CRC-16-IBM: x16 + x15 + x2 + 1.[26]
Modbus TCP/IP hoặc Modbus TCP thực hiện việc truyền thông qua mạng TCP/IP, kết nối qua cổng 502.[27] Modbus TCP/IP không yêu cầu tính toán checksum, vì các lớp thấp hơn đã hỗ trợ checksum.
Tên | Chiều dài (byte) | Tính năng |
---|---|---|
Transaction identifier | 2 | Để đồng bộ hóa giữa các thông báo của máy chủ và máy khách |
Protocol identifier | 2 | 0 cho Modbus / TCP |
Length field | 2 | Số byte còn lại trong khung này |
Unit identifier | 1 | Địa chỉ máy chủ (255 nếu không được sử dụng) |
Function code | 1 | Function code như trong các variant khác |
Data bytes | NS | Dữ liệu dưới dạng phản hồi hoặc lệnh |
Định dạng frame của Modbus TCP này chủ yếu được sử dụng trên mạng Ethernet.
Unit identifier được sử dụng với các thiết bị Modbus/TCP là tổng hợp của một số thiết bị Modbus, ví dụ như trên các cổng Modbus/TCP đến Modbus RTU. Trong trường hợp đó, unit identifier cho biết địa chỉ server của thiết bị sau gateway. Các thiết bị hỗ trợ Modbus/TCP thường bỏ qua Unit Identifier.
Đối với các giao thức sử dụng Ethernet như Modbus TCP, bất kỳ thiết bị nào cũng có thể gửi lệnh Modbus do đó tất cả đều có thể hoạt động như một client, mặc dù thông thường chỉ có một thiết bị hoạt động như một client.
Ngoài ra còn có 2 biến thể tương tự Modbus TCP được triển khai bao gồm:
Các biến thể khác của giao thức Modbus bao gồm:
Mô hình dữ liệu và lời gọi hàm giống hệt nhau đối với 4 biến thể đầu tiên của giao thức; chỉ có sự đóng gói dữ liệu là khác nhau. Tuy nhiên, các biến thể, đặc biệt là các định dạng frame của chúng đều không tương thích với nhau.
Trên Modbus RTU, Modbus ASCII và Modbus Plus (tất cả đều là mạng nhiều dây cáp đơn RS-485), chỉ node chỉ định làm client mới có thể bắt đầu một lệnh. Tất cả các thiết bị khác là server và phản hồi các yêu cầu và lệnh.
Một giao thức thực tế khác có liên quan chặt chẽ đến Modbus xuất hiện sau nó, và được xác định bởi thương hiệu PLC April Automates, kết quả của nỗ lực hợp tác giữa các công ty Pháp Renault Automation và Merlin Gerin et Cie vào năm 1985: JBUS. Sự khác biệt giữa Modbus và JBUS tại thời điểm đó (số lượng thực thể, trạm máy chủ) hiện không còn liên quan vì giao thức này gần như biến mất với dòng PLC tháng 4 mà AEG Schneider Automation mua vào năm 1994 và sau đó đã lỗi thời. Tuy nhiên cái tên JBUS đã tồn tại ở một mức độ nào đó.
JBUS hỗ trợ các mã chức năng 1, 2, 3, 4, 5, 6, 15 và 16 và do đó tất cả các thực thể được mô tả ở trên. Tuy nhiên, cách đánh số khác với JBUS:
Các port Modbus chuẩn của các bộ Modicon controller sử dụng đầu nối tương thích RS-232C với các quy định về chân kết nối, loại cáp, mức tín hiệu, tốc độ baud và parity check. Các bộ controller này có thể kết nối mạng trực tiếp hoặc thông qua modem.[32]
Vào ngày 9 tháng 7 năm 2020, hội đồng Modbus Organization chính thức công bố sử dụng mô hình client/server thay cho mô hình maser/slave đồng thời cũng bỏ việc sử dụng mô hình query và response trước đó khi nói về hoạt động của Modbus.[33] Khác với mô hình client/server hiện tại khi client sẽ khởi tạo ADU, ở mô hình master/slave trước đó, chỉ có một thiết bị làm master là có thể khởi tạo quá trình truy vấn (query).[32] Ở mô hình master/slave này, các thiết bị khác hoạt động như những slave trong hệ thống, sẽ phản hồi lại master bằng cách cung cấp dữ liệu được yêu cầu bởi master hoặc thực hiện một hành động khác tương ứng trong query. Một thiết bị master tiêu biểu ba gồm bộ xử lý trung tâm (host processors) và một bản lập trình (programming panel). Thiết bị slave tiêu biểu là các PLC.[32]
Master có thể định địa chỉ của các slave hoặc phát (broadcast) message (gói tin) tới tất cả slave. Tùy theo địa chỉ tương ứng với slave mà slave đó sẽ phản hồi message trở lại.[34] Message của master sẽ có định dạng bao gồm địa chỉ của slave cần truy vấn, một function code để định thao tác cần slave thực thi, dữ liệu cần gởi đi, và một trường kiểm tra lỗi.[35] Message phản hồi của slave cũng có định dạng tương tự master với trường địa chỉ của slave đó, function code, dữ liệu trả về và một trường kiểm tra lỗi.[35] Nếu không xảy ra lỗi trong quá trình nhận message truy vấn từ master, trường function code của slave sẽ có giá trị như function code từ message của master, trường dữ liệu trả về sẽ là giá trị mà slave thu được như giá trị trạng thái hay giá trị thanh ghi. Nếu xảy ra lỗi, trường function code sẽ có giá trị để master biết được rằng đây là một phản hồi lỗi từ slave, và trường data sẽ có mã code để mô tả lỗi này.[25] Trường kiểm tra lỗi sẽ cho master biết được nội dung message có hợp lệ không.[25]
Tài liệu kĩ thuật