Khi chọn chế độ mạng cho bộ chuyển đổi nối tiếp sang mạng, trước tiên hãy xác định bên nào khởi tạo kết nối, sau đó xác định ứng dụng cần luồng byte có thứ tự hay các datagram độc lập, rồi mới điều chỉnh thời gian và độ dài đóng gói. TCP Server, TCP Client, UDP và chuyển đổi giao thức không nằm ở cùng một cấp độ lựa chọn; việc các mục được đặt cạnh nhau trong menu không có nghĩa là chúng chỉ khác nhau về tốc độ.
1. Lựa chọn chế độ bắt đầu từ vai trò của phần mềm
Bộ chuyển đổi nối tiếp sang mạng chuyển các byte giữa mạng và cổng nối tiếp, còn ứng dụng trên máy tính chủ chịu trách nhiệm diễn giải dữ liệu ứng dụng. Nếu chương trình máy tính chủ động kết nối tới thiết bị hiện trường, phía hiện trường thường được cấu hình là TCP Server; nếu chương trình trung tâm chờ thiết bị hiện trường kết nối vào, phía hiện trường thường được cấu hình là TCP Client. Nếu cả hai bên đều chờ, kết nối sẽ không tự hình thành ngay cả khi mạng thông suốt.
Vai trò kết nối không giới hạn chiều truyền dữ liệu. Sau khi kết nối TCP được thiết lập, cả hai đầu thường đều có thể gửi và nhận byte, vì vậy phía máy chủ không chỉ có thể nhận và phía máy khách không chỉ có thể gửi. Cổng trong ví dụ phải được thiết lập nhất quán ở cả hai đầu; cổng trang web quản trị và cổng ứng dụng của thiết bị đo có mục đích khác nhau, nên không thể kết luận ứng dụng hoạt động bình thường chỉ vì mở được trang web.
2. Máy chủ và máy khách TCP khác nhau như thế nào?
Máy chủ lắng nghe trên địa chỉ và cổng được chỉ định, còn máy khách chủ động yêu cầu kết nối. Chỉ sau khi máy khách khởi tạo và máy chủ chấp nhận, ứng dụng mới có thể truyền dữ liệu qua kết nối đó. Khi cấu hình máy khách, bạn còn cần điền địa chỉ đích và cổng đích; khi cấu hình máy chủ, bạn cần xác nhận phạm vi lắng nghe, cổng ứng dụng và các nguồn kết nối được phép.
Thời điểm thiết bị khởi tạo kết nối, việc thiết bị có duy trì kết nối lâu dài hay không và khoảng thời gian thử lại sau khi ngắt kết nối đều phụ thuộc vào firmware và cấu hình. Một số thiết bị kết nối khi bật nguồn, một số hỗ trợ kích hoạt bằng dữ liệu nối tiếp; không thể áp dụng hành vi của một menu cho mọi model. Tên chế độ mô tả vai trò cơ bản và không thể chứng minh rằng chắc chắn có gói đăng ký, mã hóa hoặc bộ đệm khi mất kết nối.
3. Vì sao không thể chỉ coi UDP là TCP nhanh hơn
UDP gửi datagram, không thiết lập kết nối kiểu TCP và bản thân nó không bảo đảm dữ liệu đến đúng thứ tự, được chuyển tin cậy hoặc được bảo vệ khỏi trùng lặp. Nó giữ nguyên ranh giới datagram, nhưng ranh giới này không nhất thiết trùng với ranh giới thông điệp của giao thức nối tiếp, vì bộ chuyển đổi nối tiếp sang mạng có thể tạo datagram theo các điều kiện đóng gói.
Nếu ứng dụng sử dụng UDP, ứng dụng phải xem xét tình trạng mất gói, dữ liệu đến sai thứ tự, trùng lặp và bộ đệm nhận không đủ, đồng thời quy định số thứ tự, xác nhận hoặc các quy tắc khôi phục khác tùy theo ứng dụng. Mức độ rủi ro của việc lấy mẫu định kỳ chỉ đọc và lệnh điều khiển là khác nhau: không thể bỏ qua việc xác minh trạng thái thực thi của lệnh khởi động/dừng chỉ vì UDP không có quá trình bắt tay.
UDP Server và UDP Client trong menu thường được dùng để biểu thị cách lắng nghe, địa chỉ đích hoặc chiến lược phản hồi; chúng không tương ứng hoàn toàn với các vai trò kết nối TCP. Một số thiết bị gửi trả về một đích cố định, một số gửi trả theo nguồn; cần kiểm tra trong tài liệu hướng dẫn xem có thể nhận từ nhiều nguồn hay không và phản hồi được phân bổ như thế nào. Địa chỉ và cổng quảng bá không có giá trị mặc định thống nhất trong toàn ngành, và không nên dùng trực tiếp các con số trong bài viết cũ cho sản phẩm khác.
4. Vì sao đóng gói dữ liệu nối tiếp làm tăng thời gian chờ
Các byte nối tiếp đến lần lượt và thiết bị cần quyết định khi nào chuyển chúng sang mạng để gửi. Các điều kiện phổ biến gồm số byte tích lũy, khoảng thời gian hoặc ký tự phân cách. Đạt điều kiện về độ dài có thể kích hoạt gửi, và chờ đến hết khoảng thời gian chỉ định cũng có thể kích hoạt gửi; cách kết hợp các điều kiện và ý nghĩa của giá trị bằng không khác nhau giữa các nhà sản xuất.
Giả sử một phản hồi ngắn chỉ có vài byte nhưng độ dài đóng gói được đặt rất lớn, thiết bị có thể tiếp tục chờ điều kiện thời gian. Nếu thời gian chờ của máy tính chủ quá ngắn, máy tính sẽ coi phản hồi vẫn nằm trong bộ đệm là một lần trao đổi thất bại. Ngược lại, đóng gói quá thường xuyên tạo ra nhiều khối dữ liệu nhỏ và làm tăng chi phí xử lý. Bạn nên kiểm tra dựa trên độ dài phản hồi, tốc độ nối tiếp và chu kỳ ứng dụng.
Khi TCP truyền dữ liệu bình thường, nó cung cấp một luồng byte có thứ tự và một lần đọc của chương trình có thể nhận được nửa khung hoặc nhiều khung. Điều chỉnh tham số đóng gói không thể thay thế việc phân định khung ở tầng ứng dụng. Ứng dụng vẫn cần xác định thông điệp hoàn chỉnh dựa trên độ dài, ký tự phân cách, tổng kiểm tra hoặc trạng thái giao thức, rồi mới diễn giải nội dung; coi trực tiếp mỗi lần đọc là một phản hồi dễ gây ra lỗi không thường xuyên.
5. Cần phân biệt keepalive, thời gian chờ không hoạt động và thời gian chờ ứng dụng
Keepalive được dùng để kiểm tra xem kết nối có thể còn hiệu lực hay không; thời gian chờ không hoạt động được dùng để đóng phiên không có hoạt động trong thời gian dài theo cấu hình; còn thời gian chờ ứng dụng là giới hạn thời gian ứng dụng chờ thiết bị phản hồi. Ba cơ chế này giải quyết các vấn đề khác nhau, nên không thể dùng một khoảng thời gian keepalive để suy ra thiết bị đo cần bao lâu để phản hồi.
Các gói keepalive và số lần thăm dò do cách triển khai của hệ thống và thiết bị quyết định; không nên sao chép quy tắc ‘đóng sau ba lần không có phản hồi’ thành một tiêu chuẩn thống nhất. Kết nối được khôi phục cũng không có nghĩa là lệnh điều khiển trước đó chưa được thực thi. Trước khi thử lại sau khi hết thời gian chờ, hãy xem xét liệu lệnh có thể được lặp lại an toàn hay không; nếu cần, hãy truy vấn trạng thái trước hoặc sử dụng cơ chế giao dịch mà giao thức hỗ trợ.
6. Nhiều kết nối và chuyển đổi Modbus không phải cùng một khả năng
Việc cho phép nhiều phiên TCP chỉ thể hiện khả năng truy cập mạng. Nếu nhiều thiết bị chủ ghi đồng thời lên cùng một bus RS485, có thể xảy ra xung đột yêu cầu và phản hồi có thể bị gán nhầm. Bạn cần kiểm tra xem thiết bị có cung cấp cơ chế phân xử, xếp hàng, truy cập chỉ đọc hoặc chế độ gateway rõ ràng hay không, đồng thời phối hợp các cơ chế này trong giải pháp tổng thể.
Chuyển đổi Modbus RTU sang TCP đòi hỏi xử lý đúng hai loại cấu trúc thông điệp và sự tương ứng giữa các giao dịch; không thể hoàn tất chỉ bằng cách gửi các byte RTU qua TCP. Việc xuất hiện tùy chọn ‘Modbus’ trong chế độ TCP cũng không chứng minh rằng mọi thiết bị đều hỗ trợ tùy chọn đó. Số phiên tối đa, quy tắc chiếm quyền và phạm vi menu trong các bài viết cũ không có căn cứ theo model cụ thể không được giữ lại ở đây như thông số chung.
7. Hoàn tất cấu hình và nghiệm thu tại hiện trường theo trình tự
Trước tiên, ghi lại vai trò của máy tính chủ, giao diện thiết bị đầu cuối và định dạng truyền nối tiếp, sau đó lập kế hoạch cho địa chỉ mạng, cổng và phạm vi truy cập. Trong môi trường thử nghiệm cô lập, sử dụng một thiết bị đầu cuối đã biết để hoàn tất trao đổi ứng dụng hai chiều, đồng thời quan sát trạng thái kết nối, bộ đếm dữ liệu nối tiếp và phản hồi thô. Sau đó điều chỉnh tham số đóng gói, mỗi lần chỉ thay đổi một mục, và lưu cấu hình có thể khôi phục về sau.
Sau khi kết nối lại vào hệ thống hiện trường, hãy kiểm tra việc thăm dò liên tục, tải đồng thời và khôi phục sau ngắt kết nối, đồng thời kiểm tra thời gian chờ, nội dung phản hồi và lệnh trùng lặp. TCP không đồng nghĩa với mã hóa; truy cập từ xa phải sử dụng kênh bảo mật và kiểm soát truy cập đã được hoạch định, không được trực tiếp đưa trang web quản trị hoặc cổng điều khiển ra Internet công cộng. UDP cũng không được bỏ qua việc giới hạn nguồn và phân quyền.
8. Cách kiểm chứng các sản phẩm cụ thể
Thông tin chi tiết về dòng FCT-1500 của Feichang Technology liệt kê TCP Server/Client, UDP, cổng nối tiếp ảo và các chế độ liên quan đến Modbus, có thể được lựa chọn và cấu hình theo phần mềm máy tính chủ và giao thức thiết bị đầu cuối. Khi lựa chọn, trước tiên hãy xác nhận giao diện thực tế được đặt hàng, các chế độ hoạt động mà firmware hỗ trợ và chức năng chuyển đổi, sau đó kiểm tra số lượng kết nối, tham số đóng gói và kết nối lại; không coi tài liệu quảng bá dòng sản phẩm là hướng dẫn đầy đủ cho mọi cấu hình.
Nếu chỉ cần đánh giá các chế độ hoạt động chung, hãy tham khảo 1197; để xem ví dụ cấu hình nhất quán cho máy chủ TCP, hãy tham khảo 2271. Bài viết này giải thích riêng về UDP và cơ chế đóng gói nhằm giúp người đọc hiểu vì sao ‘chuyển sang UDP’ và ‘đặt thời gian về không’ không phải là giải pháp áp dụng cho mọi trường hợp.
Tài liệu tham khảo: Thông số kỹ thuật TCP ; Đặc tả UDP ; Thông tin chi tiết về dòng FCT-1500 của Feichang Technology . Các hình minh họa là sơ đồ cơ chế chung, không thể hiện kết quả đo thực tế hoặc menu của model cụ thể.
Cách kiểm tra từng mục trong các bài viết cũ về cấu hình máy khách và UDP
Khi thiết bị hoạt động ở chế độ TCP Client, trước tiên hãy bật chức năng lắng nghe trong chương trình trung tâm, điền địa chỉ trung tâm có thể truy cập và cổng lắng nghe của ứng dụng, sau đó xác nhận định dạng ký tự, kênh và khả năng gửi nhận hai chiều; địa chỉ trang web quản trị không thể thay thế đích kết nối của ứng dụng. Lưu cấu hình và kiểm tra hành vi sau khi tắt/bật nguồn và ngắt kết nối. Nếu hỗ trợ kết nối ngắn hạn hoặc nhiều đích, hãy xác nhận theo model tương ứng, không suy ra giới hạn tối đa từ tên Client.
Khi kiểm tra UDP, hãy ghi riêng địa chỉ và cổng gắn kết cục bộ, cùng địa chỉ và cổng đích. Gửi đến một đích cố định và phản hồi theo nguồn là hai chiến lược khác nhau; hành vi cụ thể mà menu UDP Server hoặc Client sử dụng phụ thuộc vào tài liệu hướng dẫn. Không điền các cổng mâu thuẫn nhau vào cùng một trường tham số ở hai đầu, và không dùng quá trình bắt tay TCP để xác định rằng UDP đang trực tuyến. Trước tiên, dùng một lượng nhỏ dữ liệu thử nghiệm dễ nhận biết để kiểm tra đường truyền hai chiều, sau đó xác minh cách ứng dụng xử lý mất dữ liệu, trùng lặp và dữ liệu đến sai thứ tự.
Bài viết này kế thừa nội dung còn phù hợp của bài viết cũ tương ứng; các sơ đồ nguyên lý là hình minh họa nguyên lý chung; cơ chế chung và khả năng của model cụ thể được kiểm chứng riêng.
Đượ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-09. Nguồn sửa đổi lần cuối: 2026-10-13T11:01:30+08:00. Đọc nguồn tiếng Trung
