Trước tiên, hãy khắc phục lỗi máy chủ nối tiếp theo ba lớp: công cụ quản lý có phát hiện được thiết bị hay không, có thiết lập được kết nối mạng hay không và dữ liệu nối tiếp có truyền chính xác theo cả hai chiều hay không. Kết nối TCP thành công chỉ có nghĩa là phiên mạng đã được thiết lập; điều đó không có nghĩa là đấu dây nối tiếp, các tham số và giao thức ứng dụng đều chính xác. Kiểm tra từng lớp dọc theo đường truyền dữ liệu hiệu quả hơn việc liên tục khởi động lại và thay đổi tất cả tham số.
1. Trước tiên, hãy hiểu thiết bị đảm nhiệm đoạn nào
Máy chủ nối tiếp truyền trong suốt thông thường lưu tạm các byte nhận từ cổng nối tiếp, sau đó gửi chúng qua mạng đến chương trình phía bên kia; các byte nhận từ mạng được gửi ra qua cổng nối tiếp. Thiết bị không tự động chuyển đổi Modbus RTU sang Modbus TCP. Khi cần chuyển đổi giao thức, bạn phải xác nhận model và chế độ hoạt động có hỗ trợ hay không, và không được coi “nối tiếp sang mạng” là khả năng tự động liên thông mọi giao thức.
Trước khi bắt đầu, hãy ghi lại model thiết bị, firmware, loại giao diện điện nối tiếp, định nghĩa các đầu nối, địa chỉ mạng, cổng TCP và chế độ hoạt động. Vẽ chuỗi “máy tính chủ -> mạng -> máy chủ nối tiếp -> thiết bị nối tiếp”, đồng thời đánh dấu bên gửi yêu cầu và bên trả phản hồi. Tại hiện trường công nghiệp, không ngắt kết nối tất cả thiết bị ngay từ đầu; trong môi trường thử nghiệm được phép, hãy dùng một thiết bị đầu cuối, một cáp ngắn và một yêu cầu đã biết để xây dựng hệ thống tối giản.
2. Phần mềm quản lý không tìm thấy thiết bị
Trước tiên, hãy xác nhận nguồn điện, liên kết cổng mạng và bộ điều hợp mạng mà máy tính thực sự đang sử dụng. Công cụ phát hiện có thể dùng quảng bá LAN hoặc các thông điệp UDP được chỉ định, và các thông điệp này không nhất thiết được chuyển tiếp qua bộ định tuyến. Máy tính truy cập được internet và phát hiện được thiết bị là hai việc khác nhau; môi trường liên VLAN, cách ly không dây, nhiều bộ điều hợp mạng hoặc VPN cũng có thể ảnh hưởng đến đường đi của quá trình phát hiện.
Kiểm tra địa chỉ mặc định xuất xưởng hoặc địa chỉ đã lưu và xem có xung đột với thiết bị khác hay không. Thử nghiệm trong cùng một mạng con được kiểm soát theo hướng dẫn của nhà sản xuất; không tùy tiện thay đổi địa chỉ máy tính hoặc đưa thiết bị có địa chỉ chưa rõ vào mạng sản xuất. Quản trị viên có thể kiểm tra việc học địa chỉ MAC của switch, thông tin cấp phát địa chỉ và chính sách truy cập để xác định yêu cầu có đến phía thiết bị hay không.
Tường lửa có thể chặn công cụ, nhưng không nên làm theo lời khuyên cũ là “tắt tất cả tường lửa”. Hãy xác nhận nguồn gốc công cụ quản lý, các cổng và tiến trình cần thiết, chỉ mở các quy tắc cần thiết và giới hạn phạm vi nguồn truy cập. Không thể áp dụng cổng phát hiện của một hãng cho các hãng khác; sau khi cho phép giao tiếp, hãy lưu lại các quy tắc và không để giao diện quản lý truy cập trực tiếp từ internet công cộng.
3. Đã tìm thấy thiết bị nhưng không thiết lập được kết nối TCP
Làm rõ vai trò TCP Server và TCP Client. Server chờ kết nối và phải có một bên kết nối đến địa chỉ cùng cổng lắng nghe của nó; Client chủ động kết nối đến đầu bên kia được chỉ định. Nếu cả hai bên đều chờ hoặc đều kết nối sai địa chỉ, kết quả là “thiết bị trực tuyến nhưng không có phiên kết nối”. Cổng web quản lý và cổng dịch vụ TCP thường cũng không có cùng mục đích.
Trước tiên, hãy kiểm tra IP, mặt nạ mạng, gateway và cổng dịch vụ, sau đó kiểm tra khả năng truy cập cổng đích trong môi trường được phép. Ping thành công không chứng minh cổng TCP đang mở, và Ping thất bại cũng không nhất thiết chứng minh thiết bị ngoại tuyến, vì ICMP có thể bị lọc theo chính sách. Khi sử dụng qua mạng con khác hoặc mạng công cộng, cũng cần kiểm tra định tuyến, NAT và tường lửa; ưu tiên sử dụng mạng được kiểm soát hoặc VPN và không mở trực tiếp các cổng dịch vụ nối tiếp không cần thiết.
Kiểm tra xem kết nối có đang bị chiếm dụng, số lượng kết nối có đạt giới hạn, thời gian chờ không hoạt động có bị vượt quá hoặc máy chủ có từ chối nguồn không được phép hay không. Mỗi thiết bị hỗ trợ các cơ chế đa kết nối, kết nối lại và keepalive khác nhau; không thể thay thế hướng dẫn sử dụng bằng nhận định “việc thăm dò sẽ tự động hoàn tất”. Lưu trạng thái kết nối và nhật ký ngắt kết nối có ý nghĩa hơn việc chỉ nhìn thấy một biểu tượng màu xanh.
4. TCP đã kết nối nhưng cổng nối tiếp không phản hồi
Kiểm tra xem RS232, RS422 và RS485 có phù hợp với thiết bị đầu cuối hay không, và các đầu nối có được đấu theo ký hiệu trên thiết bị này hay không. Các nhà sản xuất có thể đặt tên A/B khác nhau, vì vậy hãy kiểm tra định nghĩa điện trước rồi mới thử nghiệm, không suy đoán cực tính theo màu sắc. RS485 cần được thiết kế đồng bộ với cấu trúc liên kết bus, điện trở kết thúc và nối đất tham chiếu; không được tùy tiện mở rộng nhiều nhánh rẽ ngắn thành mạng hình sao.
Tốc độ baud, số bit dữ liệu, tính chẵn lẻ, số bit dừng và điều khiển luồng ở hai bên phải khớp nhau. Chỉ cùng tốc độ là chưa đủ; lỗi chẵn lẻ cũng có thể khiến bên nhận loại bỏ dữ liệu. Khi thiết bị RS232 cần điều khiển luồng phần cứng, thiếu dây điều khiển có thể khiến quá trình truyền dừng lại; không vô hiệu hóa ngay điều khiển luồng hoặc nối tắt các đầu nối khi chưa xác minh.
Sử dụng một yêu cầu đã được xác nhận là đúng để kiểm tra bộ đếm truyền nối tiếp, sau đó kiểm tra bộ đếm phản hồi. Nếu đã gửi byte nhưng không có gì trả về, hãy tập trung vào đấu dây, nguồn điện thiết bị đầu cuối, số trạm và định dạng yêu cầu; nếu nhận được phản hồi nhưng máy tính chủ báo lỗi, hãy tập trung vào phân tích giao thức, thời gian chờ và các tham số nối tiếp. Chỉ thực hiện kiểm tra vòng lặp trên những giao diện và cách đấu dây được hướng dẫn sử dụng cho phép rõ ràng, và không thể áp dụng cách kiểm tra vòng lặp của RS232 cho RS485.
5. Tại sao độ trễ, tách gói và gộp gói ảnh hưởng đến việc thăm dò
Truyền nối tiếp cần thời gian thực tế; quá trình xử lý của thiết bị, truyền qua mạng và đóng gói của máy chủ nối tiếp cũng cần thời gian. Điều kiện đóng gói có thể bao gồm số byte, khoảng thời gian hoặc ký tự phân cách. Chờ thêm byte có thể giảm số gói nhỏ, nhưng cũng làm chậm phản hồi; nếu máy tính chủ chờ quá ngắn, nó có thể coi một phản hồi đúng vẫn đang trên đường truyền là đã hết thời gian chờ.
Các bài viết cũ coi việc đặt cả khoảng thời gian gửi và số byte về 0 là giải pháp chung, nhưng điều này không áp dụng cho mọi model. Trước tiên, hãy đọc ý nghĩa các tham số, đo thời gian phản hồi trên một liên kết ngắn, sau đó điều chỉnh từng mục theo ranh giới giao thức và tải. TCP trong suốt cung cấp một luồng byte có thứ tự, và một lần đọc có thể chứa nửa khung hoặc nhiều khung; máy tính chủ cần tích lũy, phân tách và kiểm tra theo giao thức ứng dụng, không nên dựa vào giả định rằng một lần đọc TCP tương ứng với một phản hồi hoàn chỉnh.
6. Cổng nối tiếp ảo, mất dữ liệu tệp và nhiều máy khách
Trình điều khiển cổng nối tiếp ảo cho phép ứng dụng truy cập thiết bị mạng như một cổng COM cục bộ, nhưng model, phiên bản trình điều khiển, chế độ và quyền truy cập phải phù hợp. Một số thiết bị có chế độ giao thức chuyên dụng, trong khi các thiết bị khác truyền trực tiếp các byte trong suốt, vì vậy không thể khẳng định chung rằng “nếu dùng Socket thì phải tắt một tùy chọn nhất định”. Hãy kiểm tra cấu hình trình điều khiển và thiết bị theo hướng dẫn sử dụng, đồng thời tránh để nhiều chương trình chiếm dụng cổng COM cùng lúc.
Dữ liệu từ mạng có thể đi vào bộ đệm nhanh hơn tốc độ xuất của cổng nối tiếp. Ghi liên tục mà không có điều khiển luồng, bộ đệm và xác nhận ở cấp ứng dụng phù hợp có thể làm mất dữ liệu. Điều chỉnh tùy chọn “tốc độ baud mô phỏng” không phải là cách khắc phục chung cho mọi hoạt động truyền tệp; trước tiên, hãy làm rõ ứng dụng có hỗ trợ điều khiển luồng, ranh giới dữ liệu và truyền lại hay không, đồng thời kiểm tra đầy đủ độ dài và nội dung.
Khi nhiều máy tính truy cập đồng thời một thiết bị nối tiếp, còn có vấn đề xung đột yêu cầu và xác định phản hồi thuộc về bên nào. Hỗ trợ nhiều kết nối TCP không đồng nghĩa với việc hỗ trợ nhiều thiết bị chủ điều khiển an toàn các thiết bị tớ RS485 cùng lúc. Các yêu cầu cần được quản lý bằng cơ chế phối hợp ở cấp ứng dụng, proxy hoặc chế độ được hỗ trợ rõ ràng; không được để các máy khách khác nhau tùy ý ghi xen kẽ lẫn nhau.
7. Kiểm tra lại và xác minh sản phẩm
Sau khi sửa lỗi, hãy kiểm tra khởi động, thăm dò liên tục, ngắt mạng và khôi phục, đồng thời theo dõi tính chính xác của phản hồi, thời gian kết nối lại và hoạt động của bộ đệm. Thành công một lần không có nghĩa là ổn định dưới tải cao. Ghi lại các tham số cuối cùng và cấu hình dự phòng, sau đó kết nối lại dần các nút tại hiện trường, tránh thay đổi quá nhiều điều kiện cùng lúc.
Thông tin chi tiết về dòng Feichang FCT-1500 cung cấp hướng dẫn cấu hình cho RS232/422/485, cổng nối tiếp ảo và các chế độ mạng liên quan; chức năng chẩn đoán DDM dành cho cấu hình cổng quang tương ứng có thể giúp kiểm tra trạng thái mô-đun quang. Khi khắc phục sự cố, trước tiên hãy kiểm tra model thực tế, cấu hình cổng và chế độ đang bật, sau đó dùng các chức năng này để phân biệt vấn đề mạng, đường truyền quang và nối tiếp; không thể khái quát điều này cho mọi máy chủ nối tiếp.
Tài liệu tham khảo:Hướng dẫn kết nối mạng nối tiếp và đóng gói của Moxa;Thông tin chi tiết sản phẩm Feichang 2855. Tích hợp nội dung về ba loại bất thường, cổng nối tiếp ảo và nhiều máy khách từ 2295, 2084 và 2115. Các hình chỉ là minh họa chung, không đại diện cho sản phẩm thực tế hoặc thời gian đo được.
Được dịch từ bài viết kỹ thuật tiếng Trung. Nguồn xuất bản lần đầu: 2022-12-20. Nguồn sửa đổi lần cuối: 2026-10-13T19:15:07+08:00. Đọc nguồn tiếng Trung
