Uncategorized
แก้ปัญหาเกตเวย์ MT200 หลุดการเชื่อมต่อ: TCP Keepalive, Timeout 300 วินาที และ Routing ข้ามช่อง Socket | VR Automation
ส.ค.
แก้ปัญหาเกตเวย์ MT200 หลุดการเชื่อมต่อ: TCP Keepalive, Timeout 300 วินาที และการตั้ง Routing ข้ามช่อง Socket
อาการ “ข้อมูลหายไปเงียบๆ” บนเกตเวย์ IoT ส่วนใหญ่ไม่ได้เกิดจากอุปกรณ์เสีย แต่เกิดจาก TCP ที่ค้างอยู่ในสถานะครึ่งเปิดโดยไม่มีใครรู้ บทความนี้อธิบายกลไกสามอย่างบน MT200 Hi-Flying ที่ใช้ตัดปัญหานี้ ได้แก่ TCP Keepalive, ค่า Timeout เริ่มต้น 300 วินาที และฟังก์ชัน Routing ที่ส่งข้อมูลข้ามช่อง Socket ได้ พร้อมแนวทางตั้งค่าที่เหมาะกับงานโรงงาน
ปัญหาที่แท้จริงของการเชื่อมต่อ TCP ในโรงงาน
เมื่อเกตเวย์ทำงานเป็น TCP Client และเชื่อมกับเซิร์ฟเวอร์ปลายทาง สิ่งที่วิศวกรมักเข้าใจผิดคือคิดว่า “ถ้าสายยังต่ออยู่ การเชื่อมต่อก็ยังดี” ความจริงคือ TCP ไม่มีกลไกแจ้งเตือนอัตโนมัติเมื่ออีกฝั่งหายไปกลางทาง เช่น เราเตอร์รีบูต ผู้ให้บริการ 4G ตัดเซสชัน หรือไฟร์วอลล์ล้างตาราง NAT ผลคือฝั่งเกตเวย์ยังเชื่อว่าเชื่อมต่ออยู่ ส่งข้อมูลออกไปเรื่อยๆ แต่ไม่มีใครรับ ระบบ SCADA ปลายทางจะเห็นข้อมูลค้างที่ค่าเดิมโดยไม่มีการแจ้งเตือน
MT200 จัดการเรื่องนี้ด้วยสองกลไกที่ทำงานคนละชั้นและควรเปิดใช้ควบคู่กัน
กลไกที่ 1 — TCP Keepalive
คู่มือระบุพฤติกรรมไว้ตรงไปตรงมา: เมื่อการเชื่อมต่อ TCP ระหว่างเกตเวย์กับเซิร์ฟเวอร์ผิดปกติ อุปกรณ์จะตรวจพบสถานะผิดปกตินั้นและเชื่อมต่อกลับไปยังเซิร์ฟเวอร์ใหม่ (ในกรณีทำงานโหมด TCP Client) ส่วนกรณีที่อุปกรณ์ทำงานเป็น TCP Server มันจะปล่อยทรัพยากร TCP คืน เพื่อรองรับการเชื่อมต่อครั้งถัดไป
จุดสำคัญอยู่ตรงคำว่า “ปล่อยทรัพยากรคืน” เพราะอุปกรณ์ฝั่ง Server มีจำนวนการเชื่อมต่อจำกัด ถ้าไม่มี Keepalive แล้วไคลเอนต์หลุดแบบไม่ปิดเซสชัน ช่องเชื่อมต่อจะถูกจองค้างไว้ จนถึงจุดหนึ่งที่ไคลเอนต์ตัวจริงเชื่อมเข้าไม่ได้อีกเลย
กลไกที่ 2 — Timeout ค่าเริ่มต้น 300 วินาที
Timeout ทำงานคนละอย่างกับ Keepalive คู่มืออธิบายว่าเมื่อเกตเวย์เชื่อมกับ TCP Server ในฐานะ TCP Client แล้วไม่ได้รับข้อมูลจากเซิร์ฟเวอร์ ตัวเครื่องจะเริ่มจับเวลาภายใน เมื่อเวลาเกินค่าที่ตั้งไว้ มันจะตัดการเชื่อมต่อและเชื่อมใหม่เอง ค่าเริ่มต้นคือ 300 วินาที และแก้ไขได้
รายละเอียดที่ต้องเข้าใจให้ถูกคือ ข้อมูลที่ไคลเอนต์ส่งออกไปเองจะไม่รีเซ็ตตัวจับเวลา นั่นแปลว่าถ้าเกตเวย์ส่งข้อมูลขึ้นเซิร์ฟเวอร์ทุก 10 วินาทีแต่เซิร์ฟเวอร์ไม่เคยตอบกลับเลย ตัวจับเวลาจะยังเดินหน้าจนครบ 300 วินาทีแล้วรีคอนเนกต์อยู่ดี ซึ่งเป็นพฤติกรรมที่ตั้งใจออกแบบไว้ เพราะการที่เซิร์ฟเวอร์เงียบสนิทถือเป็นสัญญาณว่าเส้นทางอาจขาดแล้ว
| พารามิเตอร์ | ค่าตามคู่มือ | ผลเมื่อทำงาน |
|---|---|---|
| Timeout (TCP Client) | 300 วินาที (ค่าเริ่มต้น แก้ไขได้) | ตัดการเชื่อมต่อและเชื่อมใหม่เมื่อไม่ได้รับข้อมูลจากเซิร์ฟเวอร์ครบเวลา |
| Timeout (TCP Server) | ค่าเดียวกัน | ตัดการเชื่อมต่อของไคลเอนต์ที่เงียบเกินกำหนด |
| Timeout = 0 | ปิดฟังก์ชัน | ไม่ตัดการเชื่อมต่ออัตโนมัติ ต้องพึ่ง Keepalive อย่างเดียว |
| ข้อมูลที่ไคลเอนต์ส่งเอง | ไม่รีเซ็ตตัวจับเวลา | ต้องมีทราฟฟิกขากลับจากเซิร์ฟเวอร์เท่านั้นจึงจะนับว่าเชื่อมต่อยังดี |
กลไกที่ 3 — Routing ระหว่างช่อง Socket
ฟังก์ชัน Routing เป็นความสามารถที่หลายคนไม่รู้ว่ามี คู่มืออธิบายว่าข้อมูลที่รับเข้ามาทางช่อง Socket ใดๆ สามารถตั้งค่าให้ส่งออกไปยังช่องอื่นได้ ค่าเริ่มต้นคือส่งออกทางพอร์ตอนุกรม แต่กำหนดให้ส่งไปยัง Socket อื่นที่สร้างไว้ก็ได้ หรือจะใช้ Socket นั้นเป็นช่องพิมพ์ล็อกก็ได้เช่นกัน
ตัวอย่างที่คู่มือยกไว้: ตั้ง Route ของช่อง Socket ชื่อ netp ให้ไปที่ Socket2 ซึ่งคอนฟิกเป็นโหมด TCP Server ผลคือข้อมูลพอร์ตอนุกรมที่รับเข้ามาผ่านช่อง netp จะถูกส่งออกไปที่ Socket2 และเมื่อตั้ง Route ของ Socket2 กลับไปที่พอร์ตอนุกรม ข้อมูลปลายทางก็จะออกทางพอร์ตอนุกรมด้วย
ประโยชน์ในงานจริงคือการทำ “จุดดักดูข้อมูล” โดยไม่ต้องแตะสายจริง เช่นให้ Socket หนึ่งเป็นช่องพิมพ์ล็อกไว้ให้วิศวกรเปิดดูจากระยะไกลได้ว่าเฟรม Modbus ที่วิ่งจริงหน้าตาเป็นอย่างไร ขณะที่ช่องหลักยังส่งข้อมูลขึ้น SCADA ตามปกติ ซึ่งช่วยลดเวลาไล่ปัญหาหน้างานได้มาก
ตั้งค่าอย่างไรให้เหมาะกับงานแต่ละแบบ
| ลักษณะงาน | Keepalive | Timeout | Routing |
|---|---|---|---|
| เก็บข้อมูลขึ้นคลาวด์ผ่าน 4G | เปิด | ตั้งยาวขึ้นหากเซิร์ฟเวอร์ไม่ตอบกลับ | ไม่จำเป็น |
| SCADA ในโรงงาน LAN | เปิด | ใช้ค่าเริ่มต้น 300 วินาที | ตั้งช่องล็อกไว้ช่วยไล่ปัญหา |
| เกตเวย์เป็น TCP Server ให้หลายไคลเอนต์ | เปิด (จำเป็น) | ใช้ค่าเริ่มต้นหรือสั้นลง | ไม่จำเป็น |
| งานทดสอบ/คอมมิชชัน | เปิด | ตั้งสั้นเพื่อเห็นผลไว | เปิดช่องล็อกทุกช่อง |
สรุป
ทั้งสามกลไกทำงานเสริมกัน ไม่ใช่ทดแทนกัน Keepalive คอยตรวจสุขภาพการเชื่อมต่อในระดับโปรโตคอล Timeout เป็นตาข่ายรองรับกรณีที่ Keepalive ไม่ทันจับ และ Routing เป็นเครื่องมือมองเห็นข้อมูลจริงเวลาต้องหาสาเหตุ เมื่อออกแบบระบบใหม่ ควรตั้งทั้งสามอย่างตั้งแต่ขั้นคอมมิชชัน ไม่ใช่รอให้เกิดปัญหาแล้วค่อยมาไล่
ต้องการเกตเวย์ IoT หรืออุปกรณ์แปลงสัญญาณอุตสาหกรรมสำหรับงานของคุณ ดูรุ่นที่จำหน่ายได้ที่ หมวดอุปกรณ์เครือข่ายอุตสาหกรรม ของ VR Automation
คำถามที่พบบ่อย (FAQ)
Keepalive กับ Timeout ต่างกันอย่างไร
Keepalive ตรวจสอบว่าการเชื่อมต่อ TCP ยังมีชีวิตอยู่ในระดับโปรโตคอลและสั่งเชื่อมใหม่เมื่อพบความผิดปกติ ส่วน Timeout นับเวลาที่ไม่ได้รับข้อมูลจากเซิร์ฟเวอร์ แล้วบังคับตัดและเชื่อมใหม่เมื่อครบกำหนด ทั้งสองควรเปิดพร้อมกัน
ตั้ง Timeout สั้นๆ เช่น 30 วินาที ได้ไหม
ได้ และเหมาะกับช่วงคอมมิชชันเพื่อดูผลไว แต่บนเครือข่ายที่มีความหน่วงสูงหรือสัญญาณ 4G ไม่นิ่ง ค่าสั้นเกินไปจะทำให้อุปกรณ์รีคอนเนกต์บ่อยเกินจำเป็น ควรทดสอบก่อนใช้จริง
ฟังก์ชัน Routing ใช้กับพอร์ตอนุกรมได้ด้วยหรือไม่
ได้ ค่าเริ่มต้นของการ Route ข้อมูลจาก Socket คือส่งออกทางพอร์ตอนุกรม และสามารถตั้งให้ Socket ปลายทางส่งกลับไปยังพอร์ตอนุกรมได้เช่นกัน ตามตัวอย่างที่คู่มือผู้ผลิตยกไว้
สนใจสั่งซื้อ MT200 Hi-Flying?
VR Automation จำหน่ายและให้บริการติดตั้ง พร้อมทีมช่างผู้เชี่ยวชาญ
โทรสอบถามราคา: 083-848-8314
อีเมล: [email protected]
Line: @vrautomation
สต๊อกกรุณาสอบถาม | รับประกันสินค้า | บริการหลังการขาย | ออกใบกำกับภาษีได้
แหล่งข้อมูลและมาตรฐานอ้างอิง
- Catalog: Mortise and tenon series product software functions_20250312.pdf — VR Automation (เอกสารเทคนิคจากผู้ผลิต)
- Preventing Modbus TCP Connection Timeout: Keep-Alive Solutions — อ้างอิงแนวปฏิบัติการตั้ง keep-alive สำหรับงาน Modbus TCP ในอุตสาหกรรม
- TCP keepalive — Gateway Documentation — อธิบายกลไก TCP keepalive ตาม RFC 1122 และพารามิเตอร์ที่เกี่ยวข้อง
- Hi-Flying — Programmable Gateway — หน้าข้อมูลตระกูลเกตเวย์ MT200 จากผู้ผลิต
