Giải thích
Vì Sao PLC Không Đọc Được Dữ Liệu Qua Modbus RTU? 5 Nguyên Nhân Thường Gặp
PLC báo lỗi timeout hoặc đọc sai giá trị thanh ghi qua Modbus RTU gần như luôn xuất phát từ một trong năm nguyên nhân dưới đây — và phần lớn không nằm ở chỗ nhiều kỹ sư nghi ngờ đầu tiên là đấu sai chân A/B. Nếu đã kiểm tra dây kỹ mà lỗi vẫn còn, khả năng cao nguyên nhân nằm ở cấu hình truyền thông hoặc đặc tính điện của bus, không phải phần cứng đấu nối.
Bài này liệt kê đúng 5 nguyên nhân phổ biến nhất theo thứ tự nên kiểm tra — từ dễ xác minh bằng mắt/multimeter đến những nguyên nhân cần phần mềm debug — để tránh dò lan man mất thời gian.
1. Sai baudrate, parity hoặc stop bit giữa master và slave
Đây là nguyên nhân phổ biến nhất và cũng dễ bỏ sót nhất, vì bản thân kết nối vật lý vẫn hoàn toàn bình thường. Modbus RTU truyền dữ liệu dạng khung bit nối tiếp — nếu PLC (master) và thiết bị slave không thống nhất tốc độ truyền (baudrate) hoặc cách đóng khung bit (parity, stop bit), byte nhận về ở phía nhận sẽ bị lệch vị trí so với byte thực sự được gửi. Kết quả là checksum CRC của khung tính ra sai, PLC coi đó là dữ liệu lỗi và bỏ qua — dù dây tín hiệu truyền tải hoàn toàn chính xác. Đây là lý do vì sao một sợi dây đã kiểm tra kỹ bằng mắt vẫn có thể gây lỗi truyền thông liên tục: vấn đề nằm ở tầng cấu hình phần mềm, không phải tầng vật lý.
2. Thiếu điện trở termination ở hai đầu bus
Trên đường truyền RS485 dài hoặc có nhiều thiết bị đấu nối tiếp, tín hiệu điện truyền đi có thể phản xạ ngược lại tại điểm cuối dây nếu không có điện trở termination (thường 120Ω) đóng vai trò ‘hấp thụ’ tín hiệu tại hai đầu bus. Tín hiệu phản xạ này chồng lên tín hiệu gốc đang truyền, gây méo dạng sóng và khiến bộ thu đọc sai bit — đặc biệt rõ rệt khi dây dài hoặc có nhiều thiết bị trên cùng bus, vì mỗi điểm rẽ nhánh cũng là một điểm có thể gây phản xạ phụ. Lỗi loại này thường không xuất hiện liên tục mà chỉ xảy ra ngẫu nhiên hoặc tăng theo tải truyền thông, nên dễ bị nhầm là lỗi phần mềm.
3. Trùng địa chỉ Slave ID trên cùng bus
Nếu hai thiết bị trên cùng một bus RS485 được cấu hình cùng một Slave ID, cả hai sẽ cùng phản hồi khi PLC gửi request đến địa chỉ đó, gây xung đột tín hiệu trên đường truyền. Vì xung đột chỉ xảy ra khi cả hai thiết bị cùng lúc có dữ liệu để phản hồi, lỗi dạng này thường không xuất hiện đều đặn mà ngẫu nhiên — có lúc đọc được, có lúc không — khiến việc xác định nguyên nhân khó hơn nhiều so với lỗi cấu hình cố định. Đây là lỗi đáng kiểm tra sớm trong dự án có nhiều thiết bị slave, đặc biệt khi thiết bị được cấu hình sẵn từ nhà sản xuất với địa chỉ mặc định giống nhau.
4. Đấu ngược cực A/B hoặc thiếu dây GND chung
RS485 truyền tín hiệu dạng differential — dựa vào chênh lệch điện áp giữa hai dây A và B thay vì so với đất, nên về lý thuyết khá chống nhiễu. Nhưng chênh lệch điện áp này vẫn cần một điểm tham chiếu GND chung giữa các thiết bị để bộ thu xác định đúng ngưỡng logic 0/1. Nếu thiếu dây GND chung, điện áp tham chiếu giữa các thiết bị có thể trôi dần theo thời gian hoặc theo nhiễu nền, khiến bộ thu đọc sai mức tín hiệu dù cực A/B vẫn đấu đúng chiều. Đấu ngược cực A/B thì lỗi thường rõ ràng và liên tục ngay từ đầu; còn thiếu GND chung thì lỗi có thể chỉ xuất hiện không liên tục, tuỳ điều kiện nhiễu môi trường tại thời điểm đó.
5. Thời gian timeout cấu hình quá ngắn so với thời gian phản hồi thực tế của slave
Một số thiết bị slave — đặc biệt cảm biến có xử lý nội bộ trước khi trả dữ liệu (tính toán, lọc nhiễu, chuyển đổi ADC) — cần thời gian phản hồi lâu hơn giá trị timeout mặc định mà PLC đang cấu hình. Khi PLC gửi request và không nhận được phản hồi trong thời gian timeout đã đặt, nó coi như slave không phản hồi và báo lỗi timeout, dù thiết bị slave thực ra chỉ đang xử lý chậm hơn bình thường một chút chứ không hỏng. Đây là nguyên nhân dễ bị bỏ qua vì mọi thứ về dây và cấu hình baudrate đều đúng — chỉ riêng thời gian chờ là chưa đủ.
Nên kiểm tra theo thứ tự nào
- Đối chiếu baudrate/parity/stop bit giữa PLC và slave — kiểm tra nhanh bằng cách xem lại cấu hình phần mềm của cả hai bên, không cần công cụ đo.
- Kiểm tra điện trở termination ở hai đầu bus bằng multimeter (đo điện trở giữa A-B khi ngắt nguồn, nên gần giá trị 120Ω nếu bus có termination đúng).
- Rà soát địa chỉ Slave ID của từng thiết bị trên bus, đặc biệt với thiết bị mới lắp hoặc dùng địa chỉ mặc định từ nhà sản xuất.
- Kiểm tra dây GND chung giữa các thiết bị, không chỉ riêng cực A/B.
- Nếu 4 bước trên đều ổn mà vẫn lỗi, thử tăng giá trị timeout trên PLC và theo dõi xem lỗi có giảm không.
Kết luận
Phần lớn lỗi Modbus RTU không nằm ở chỗ dây đấu sai hoàn toàn, mà ở những chi tiết cấu hình hoặc đặc tính điện dễ bị bỏ qua khi thiết kế vội. Trước khi kết luận nguyên nhân, nên ghi lại log lỗi cụ thể — mã lỗi, tần suất xuất hiện, có xuất hiện đều đặn hay ngẫu nhiên — vì đặc điểm của lỗi thường gợi ý đúng nhóm nguyên nhân trong 5 nhóm trên, giúp tránh đoán mò và kiểm tra đúng trọng tâm ngay từ đầu.
