8 Working Mode ของเกตเวย์ Hi-Flying MT200 เลือกโหมดไหนให้เหมาะกับงาน
เกตเวย์อนุกรมตัวเดียวกัน ตั้งคนละโหมดก็ได้ผลลัพธ์คนละเรื่อง หลายโครงการเลือกโหมดผิดตั้งแต่ต้น แล้วไปแก้ด้วยการเขียนโปรแกรมเพิ่มทีหลัง ทั้งที่เปลี่ยนค่าคอนฟิกช่องเดียวก็จบ บทความนี้แจกแจงโหมดการทำงานทั้ง 8 แบบของผลิตภัณฑ์ตระกูล Mortise and Tenon (MT200) จาก Hi-Flying พร้อมเงื่อนไขการใช้งานจริง อ้างอิงเอกสาร Mortise and tenon series product software functions ฉบับ 20250312
ภาพรวมโหมดทั้งหมด
| โหมด | หลักการทำงาน | เหมาะกับงาน |
|---|---|---|
| Transparent Transmission | ส่งผ่านข้อมูลอนุกรมแบบโปร่งใส ตั้งค่าพารามิเตอร์เครือข่ายแล้วเชื่อมต่อเซิร์ฟเวอร์อัตโนมัติหลังจ่ายไฟ | ยกอุปกรณ์อนุกรมเดิมขึ้นเครือข่ายโดยไม่แก้โปรแกรมเดิม |
| TCP Server | เปิดพอร์ตรอ รองรับไคลเอนต์เชื่อมพร้อมกันได้สูงสุด 5 ราย | ให้ SCADA หรือหลายเครื่องเข้ามาดึงข้อมูลจากอุปกรณ์เดียว |
| TCP / UDP Client, UDP Server | อุปกรณ์เป็นฝ่ายวิ่งไปหาเซิร์ฟเวอร์ | ส่งข้อมูลขึ้นเซิร์ฟเวอร์ส่วนกลางหรือคลาวด์ |
| Multi-Socket | สร้างได้สูงสุด 5 Socket แต่ละช่องทำงานอิสระ | ส่งข้อมูลชุดเดียวไปหลายปลายทางพร้อมกัน |
| HTTP Mode | เติม/ถอดหัว HTTP ให้อัตโนมัติ รองรับทั้ง GET และ POST | ยิงข้อมูลเข้า REST API ที่มีอยู่แล้ว |
| Telnetd Mode | ต่อพอร์ตอนุกรมเข้าคอนโซลของอุปกรณ์ปลายทาง แล้วคอนฟิกผ่าน Telnet | รีโมตเข้าไปตั้งค่าอุปกรณ์เครือข่ายที่มีพอร์ตคอนโซล |
| WebSocket Mode | ห่อ/ถอดหัวโปรโตคอล WebSocket ให้อัตโนมัติ | แดชบอร์ดเว็บที่ต้องการข้อมูลแบบเรียลไทม์ |
| MQTT / Ali IoT | ส่งข้อมูลด้วยโปรโตคอล MQTT หรือเชื่อมแพลตฟอร์ม Alibaba Cloud IoT | ระบบ IoT ที่ใช้สถาปัตยกรรม publish/subscribe |
ที่มา: หัวข้อ 1.3 Working Mode — Mortise and tenon series product software functions_20250312
เจาะลึกโหมดที่ใช้บ่อยที่สุด
Transparent Transmission — จุดเริ่มต้นของทุกโครงการ
โหมดนี้คือค่าเริ่มต้นและเป็นทางลัดที่ดีที่สุดสำหรับการยกระบบเดิมขึ้นเครือข่าย ผู้ใช้เพียงตั้งพารามิเตอร์เครือข่ายที่จำเป็น อุปกรณ์จะเชื่อมต่อเครือข่ายและเซิร์ฟเวอร์ที่กำหนดไว้ให้อัตโนมัติทันทีหลังจ่ายไฟ โดยไม่ต้องแก้โปรแกรมฝั่งอุปกรณ์อนุกรมเดิมแม้แต่บรรทัดเดียว
TCP Server — ข้อจำกัด 5 การเชื่อมต่อที่ต้องรู้
เมื่อตั้ง Socket เป็น TCP server อุปกรณ์รองรับไคลเอนต์เชื่อมต่อพร้อมกันได้ สูงสุด 5 ราย โดยมีรูปแบบการไหลของข้อมูลที่ต้องเข้าใจให้ดี
- Upload data stream — ข้อมูลจากทุกการเชื่อมต่อ TCP จะถูกส่งต่อไปยังพอร์ตอนุกรมอย่างต่อเนื่อง
- Download data stream — ข้อมูลจากพอร์ตอนุกรมจะถูกคัดลอกและกระจาย (broadcast) ไปยังไคลเอนต์ TCP ทุกราย
Multi-Socket — ส่งข้อมูลชุดเดียวไปหลายปลายทาง
ผลิตภัณฑ์รองรับการสร้าง Socket ได้สูงสุด 5 ช่อง แต่ละช่องทำงานอิสระในโหมด TCP/UDP ของตัวเอง เพิ่ม Socket ได้ทั้งผ่านซอฟต์แวร์คอนฟิกและผ่านหน้าเว็บ (ชื่อผู้ใช้และรหัสผ่านเริ่มต้นของหน้าเว็บคือ admin/admin) ประโยชน์ชัดเจนคือส่งข้อมูลชุดเดียวกันขึ้นทั้งเซิร์ฟเวอร์ผลิตและเซิร์ฟเวอร์สำรองพร้อมกันได้ โดยไม่ต้องเพิ่มฮาร์ดแวร์
HTTP Mode — GET กับ POST วางข้อมูลคนละที่
เอกสารอธิบายพฤติกรรมของทั้งสองเมธอดไว้ละเอียด สำหรับคำขอแบบ GET ข้อมูลที่รับจากพอร์ตอนุกรมจะถูกวางต่อท้าย path โดยระบบเติมเครื่องหมาย “?” ให้เอง ส่วน POST ข้อมูลจะถูกวางในส่วน content พร้อมเติมฟิลด์ Content-Length ให้อัตโนมัติ ตัวอย่างจากเอกสาร เมื่อพอร์ตอนุกรมรับข้อมูล “pppp” ระบบจะส่ง
GET /1111?pppp HTTP/1.1 Host: 192.168.83.107
และเมื่อเซิร์ฟเวอร์ตอบกลับพร้อม Content-Length พอร์ตอนุกรมก็จะพ่นเฉพาะเนื้อข้อมูลออกมา โดยหัว HTTP ถูกถอดทิ้งให้อัตโนมัติ
Telnetd Mode — โหมดที่คนมองข้าม
เมื่อทำงานในโหมด Telnetd พอร์ตอนุกรมสามารถต่อเข้ากับพอร์ตคอนโซลของอุปกรณ์ระดับล่างได้ แล้วคอนฟิกอุปกรณ์นั้นผ่านโปรโตคอล Telnet เอกสารยกตัวอย่างการต่อเข้าคอนโซลของผลิตภัณฑ์ NC916 เพื่อตั้งค่าจากระยะไกล โหมดนี้มีประโยชน์มากสำหรับสวิตช์หรือเราเตอร์อุตสาหกรรมที่มีเฉพาะพอร์ตคอนโซล ทำให้ไม่ต้องเดินไปที่ตู้ทุกครั้งที่ต้องแก้คอนฟิก
เลือกโหมดอย่างไรให้ถูกตั้งแต่แรก
- ระบบเดิมมีซอฟต์แวร์ที่คุยผ่าน COM port อยู่แล้ว → Transparent Transmission ร่วมกับ virtual COM
- ต้องการให้ระบบส่วนกลางมาดึงข้อมูล → TCP Server (ระวังข้อจำกัด 5 การเชื่อมต่อ)
- อุปกรณ์อยู่หลัง NAT หรือใช้ 4G → TCP Client เพราะฝั่งอุปกรณ์ต้องเป็นผู้เริ่มการเชื่อมต่อ
- ต้องส่งเข้าหลายระบบพร้อมกัน → Multi-Socket
- ปลายทางเป็น REST API → HTTP Mode
- ปลายทางเป็นแพลตฟอร์ม IoT → MQTT Mode
ดูรุ่นเกตเวย์และตัวแปลงสัญญาณที่มีจำหน่ายได้ที่หมวด อุปกรณ์เครือข่ายอุตสาหกรรม ของ VR Automation

สรุป
โหมดการทำงานทั้ง 8 แบบไม่ได้แข่งกัน แต่ตอบโจทย์คนละสถานการณ์ กุญแจสำคัญคือถามตัวเองสองข้อ คือ “ใครเป็นฝ่ายเริ่มการเชื่อมต่อ” และ “ปลายทางพูดโปรโตคอลอะไร” ตอบสองข้อนี้ได้ก็เลือกโหมดถูกทันที และอย่าลืมว่า TCP Server จำกัดไว้ที่ 5 การเชื่อมต่อ ส่วน Multi-Socket ก็จำกัดที่ 5 ช่องเช่นกัน ตัวเลขสองตัวนี้คือขอบเขตที่ต้องออกแบบระบบให้อยู่ภายใน
คำถามที่พบบ่อย (FAQ)
TCP Server ของ MT200 รองรับกี่การเชื่อมต่อพร้อมกัน?
เอกสารระบุว่าเมื่อตั้ง Socket เป็น TCP server จะรองรับไคลเอนต์ TCP เชื่อมต่อพร้อมกันได้สูงสุด 5 ราย โดยข้อมูลจากพอร์ตอนุกรมจะถูกกระจายไปยังไคลเอนต์ทุกตัว
สร้าง Socket ได้สูงสุดกี่ช่อง และตั้งค่าที่ไหน?
สร้างได้สูงสุด 5 Socket แต่ละช่องทำงานอิสระในโหมด TCP/UDP ของตัวเอง ตั้งค่าได้ทั้งผ่านซอฟต์แวร์คอนฟิกและผ่านหน้าเว็บของอุปกรณ์ ซึ่งใช้ชื่อผู้ใช้และรหัสผ่านเริ่มต้น admin/admin
โหมด HTTP ต่างจาก MQTT อย่างไรในทางปฏิบัติ?
HTTP เหมาะกับการยิงข้อมูลเข้า REST API ที่มีอยู่แล้ว เป็นการสื่อสารแบบร้องขอ-ตอบกลับทีละครั้ง ส่วน MQTT เป็นสถาปัตยกรรม publish/subscribe ที่คงการเชื่อมต่อไว้ตลอด จึงเหมาะกับงานที่ต้องส่งข้อมูลถี่และต้องการให้เซิร์ฟเวอร์สั่งงานย้อนกลับมาได้ทันที

สนใจสั่งซื้อ MT200 / Elfin Series Hi-Flying?
VR Automation จำหน่ายและให้บริการติดตั้ง พร้อมทีมช่างผู้เชี่ยวชาญ
โทรสอบถามราคา: 083-848-8314
อีเมล: [email protected]
Line: @vrautomation
สต๊อกกรุณาสอบถาม | รับประกันสินค้า | บริการหลังการขาย | ออกใบกำกับภาษีได้
แหล่งข้อมูลและมาตรฐานอ้างอิง
- Catalog: Mortise and tenon series product software functions_20250312 — VR Automation (เอกสารเทคนิคจากผู้ผลิต Shanghai High-Flying Electronics)
- PUSR — Work Modes of Serial Device Server — อ้างอิงคำอธิบายเปรียบเทียบโหมด TCP Server, TCP Client, UDP และ HTTPD Client ของเซิร์ฟเวอร์อุปกรณ์อนุกรม
- PUSR — What is Serial Device Server and How it Works — อ้างอิงหลักการทำงานพื้นฐานของ serial device server และการส่งผ่านข้อมูลแบบโปร่งใส
- Hi-Flying — IoT Network Device — หน้ารวมผลิตภัณฑ์เกตเวย์และอุปกรณ์เครือข่ายจากผู้ผลิต

