เมื่อเลือกโหมดเครือข่ายของซีเรียลเซิร์ฟเวอร์ ให้พิจารณาก่อนว่าใครเป็นผู้เริ่มการเชื่อมต่อ จากนั้นพิจารณาว่าแอปพลิเคชันต้องการสตรีมไบต์ที่เรียงลำดับหรือดาตาแกรมอิสระ แล้วจึงปรับเวลาและความยาวในการรวบรวมข้อมูลเป็นแพ็กเก็ต TCP Server, TCP Client, UDP และการแปลงโปรโตคอลไม่ได้อยู่ในระดับการตัดสินใจเดียวกัน การที่รายการเมนูอยู่ด้วยกันไม่ได้หมายความว่าต่างกันเพียงความเร็ว
1. การเลือกโหมดเริ่มจากบทบาทของซอฟต์แวร์
ซีเรียลเซิร์ฟเวอร์ถ่ายโอนไบต์ระหว่างเครือข่ายกับพอร์ตอนุกรม และแอปพลิเคชันบนโฮสต์มีหน้าที่ตีความข้อมูลระดับแอปพลิเคชัน หากโปรแกรมคอมพิวเตอร์เป็นฝ่ายเริ่มเชื่อมต่อไปยังอุปกรณ์ภาคสนาม โดยทั่วไปจะตั้งค่าฝั่งภาคสนามเป็น TCP Server หากโปรแกรมส่วนกลางรอให้อุปกรณ์ภาคสนามเชื่อมต่อเข้ามา โดยทั่วไปจะตั้งค่าฝั่งภาคสนามเป็น TCP Client หากทั้งสองฝ่ายต่างรอ แม้เครือข่ายจะเข้าถึงกันได้ การเชื่อมต่อก็จะไม่เกิดขึ้นเอง
บทบาทในการเชื่อมต่อไม่ได้จำกัดทิศทางข้อมูล หลังจากสร้างการเชื่อมต่อ TCP แล้ว โดยทั่วไปทั้งสองฝั่งสามารถส่งและรับไบต์ได้ ดังนั้นฝั่งเซิร์ฟเวอร์จึงไม่ได้รับได้อย่างเดียว และฝั่งไคลเอนต์ก็ไม่ได้ส่งได้อย่างเดียว ต้องกำหนดพอร์ตในตัวอย่างให้สอดคล้องกันทั้งสองฝั่ง พอร์ตหน้าเว็บจัดการและพอร์ตแอปพลิเคชันของเครื่องมือวัดมีวัตถุประสงค์ต่างกัน จึงไม่อาจสรุปว่าแอปพลิเคชันทำงานปกติเพียงเพราะเปิดหน้าเว็บได้
2. เซิร์ฟเวอร์กับไคลเอนต์ TCP ต่างกันอย่างไร?
เซิร์ฟเวอร์รอรับการเชื่อมต่อที่แอดเดรสและพอร์ตที่ระบุ ส่วนไคลเอนต์เป็นฝ่ายร้องขอการเชื่อมต่อ แอปพลิเคชันจะส่งข้อมูลผ่านการเชื่อมต่อนั้นได้ก็ต่อเมื่อไคลเอนต์เริ่มเชื่อมต่อและเซิร์ฟเวอร์ยอมรับแล้ว เมื่อตั้งค่าไคลเอนต์ ต้องกรอกแอดเดรสและพอร์ตปลายทางด้วย ส่วนการตั้งค่าเซิร์ฟเวอร์ต้องตรวจสอบขอบเขตการรอรับการเชื่อมต่อ พอร์ตแอปพลิเคชัน และแหล่งที่มาที่อนุญาตให้เชื่อมต่อ
อุปกรณ์จะเริ่มเชื่อมต่อเมื่อใด รักษาการเชื่อมต่อระยะยาวหรือไม่ และลองเชื่อมต่อใหม่หลังขาดการเชื่อมต่อนานเท่าใด ล้วนเป็นพฤติกรรมที่ขึ้นอยู่กับเฟิร์มแวร์และการตั้งค่า อุปกรณ์บางรุ่นเชื่อมต่อเมื่อเปิดเครื่อง และบางรุ่นรองรับการกระตุ้นด้วยข้อมูลอนุกรม ไม่สามารถนำพฤติกรรมของเมนูหนึ่งไปใช้กับทุกรุ่นได้ ชื่อโหมดบอกเพียงบทบาทพื้นฐาน ไม่ได้พิสูจน์ว่ามีแพ็กเก็ตลงทะเบียน การเข้ารหัส หรือการพักข้อมูลเมื่อขาดการเชื่อมต่ออย่างแน่นอน
3. เหตุใดจึงไม่ควรมอง UDP ว่าเป็นเพียง TCP ที่เร็วกว่า
UDP ส่งดาตาแกรม โดยไม่สร้างการเชื่อมต่อแบบ TCP และไม่ได้รับประกันด้วยตัวเองว่าข้อมูลจะมาถึงตามลำดับ ส่งถึงอย่างเชื่อถือได้ หรือมีการป้องกันข้อมูลซ้ำ แม้จะรักษาขอบเขตดาตาแกรม แต่ขอบเขตนี้ไม่จำเป็นต้องตรงกับขอบเขตข้อความของโปรโตคอลอนุกรม เพราะซีเรียลเซิร์ฟเวอร์อาจสร้างดาตาแกรมตามเงื่อนไขการรวบรวมข้อมูลเป็นแพ็กเก็ต
หากแอปพลิเคชันใช้ UDP ต้องคำนึงถึงแพ็กเก็ตสูญหาย การส่งถึงผิดลำดับ ข้อมูลซ้ำ และบัฟเฟอร์รับที่ไม่เพียงพอ พร้อมกำหนดหมายเลขลำดับ การตอบรับ หรือกฎการกู้คืนอื่น ๆ ให้เหมาะกับแอปพลิเคชัน ความเสี่ยงของการเก็บตัวอย่างเป็นระยะแบบอ่านอย่างเดียวต่างจากคำสั่งควบคุม คำสั่งเริ่ม/หยุดไม่อาจละเว้นการตรวจสอบสถานะการดำเนินการเพียงเพราะ UDP ไม่มีการแฮนด์เชค
UDP Server และ UDP Client ในเมนูมักใช้สื่อถึงการรอรับข้อมูล แอดเดรสปลายทาง หรือกลยุทธ์การตอบกลับ ไม่ได้สอดคล้องกับบทบาทการเชื่อมต่อ TCP อย่างครบถ้วน อุปกรณ์บางรุ่นส่งกลับไปยังปลายทางคงที่ ขณะที่บางรุ่นส่งกลับตามแหล่งที่มา ต้องตรวจสอบในคู่มือทั้งเรื่องการรับข้อมูลจากหลายแหล่งและวิธีจัดสรรการตอบกลับ แอดเดรสบรอดแคสต์และพอร์ตไม่มีค่าเริ่มต้นเดียวกันทั้งอุตสาหกรรม และไม่ควรนำตัวเลขในบทความเก่าไปใช้กับผลิตภัณฑ์อื่นโดยตรง
4. เหตุใดการรวบรวมข้อมูลอนุกรมเป็นแพ็กเก็ตจึงเพิ่มเวลารอ
ไบต์อนุกรมมาถึงทีละไบต์ และอุปกรณ์ต้องตัดสินใจว่าจะส่งต่อให้เครือข่ายเมื่อใด เงื่อนไขที่พบบ่อย ได้แก่ จำนวนไบต์สะสม ช่วงเวลา หรืออักขระคั่น เมื่อครบเงื่อนไขความยาวอาจกระตุ้นให้ส่ง และการรอจนครบช่วงเวลาที่กำหนดก็อาจกระตุ้นให้ส่งได้เช่นกัน วิธีรวมเงื่อนไขและความหมายของค่าศูนย์แตกต่างกันตามผู้ผลิต
สมมติว่าข้อความตอบกลับสั้นมีเพียงไม่กี่ไบต์ แต่ตั้งความยาวการรวบรวมข้อมูลเป็นแพ็กเก็ตไว้มาก อุปกรณ์อาจรอต่อจนเข้าเงื่อนไขช่วงเวลา หากระยะหมดเวลาของคอมพิวเตอร์โฮสต์สั้นเกินไป ก็จะตัดสินว่าการตอบกลับล้มเหลว ทั้งที่ข้อมูลยังอยู่ในบัฟเฟอร์ ในทางกลับกัน การรวบรวมและส่งแพ็กเก็ตถี่เกินไปทำให้เกิดบล็อกข้อมูลขนาดเล็กจำนวนมากและเพิ่มภาระการประมวลผล ควรทดสอบโดยพิจารณาความยาวข้อความตอบกลับ ความเร็วอนุกรม และรอบการทำงานของแอปพลิเคชัน
เมื่อ TCP ส่งข้อมูลตามปกติ จะให้สตรีมไบต์ที่เรียงลำดับ และการอ่านหนึ่งครั้งของโปรแกรมอาจได้ครึ่งเฟรมหรือหลายเฟรม การปรับพารามิเตอร์การรวบรวมข้อมูลเป็นแพ็กเก็ตไม่สามารถทดแทนการแบ่งเฟรมในแอปพลิเคชันได้ แอปพลิเคชันยังต้องตัดสินว่าข้อความครบถ้วนหรือไม่จากความยาว อักขระคั่น เช็กซัม หรือสถานะโปรโตคอล แล้วจึงตีความเนื้อหา การถือว่าการอ่านแต่ละครั้งเป็นหนึ่งข้อความตอบกลับโดยตรงทำให้เกิดข้อผิดพลาดเป็นครั้งคราวได้ง่าย
5. ต้องแยก Keepalive ระยะหมดเวลาเมื่อไม่มีการใช้งาน และระยะหมดเวลาของแอปพลิเคชันออกจากกัน
Keepalive ใช้ตรวจสอบว่าการเชื่อมต่ออาจยังใช้งานได้หรือไม่ ระยะหมดเวลาเมื่อไม่มีการใช้งานใช้ปิดเซสชันที่ไม่มีกิจกรรมเป็นเวลานานตามการตั้งค่า ส่วนระยะหมดเวลาของแอปพลิเคชันคือเวลาสูงสุดที่แอปพลิเคชันรอการตอบกลับจากอุปกรณ์ ทั้งสามอย่างแก้ปัญหาต่างกัน จึงไม่สามารถใช้เวลา Keepalive เพียงค่าเดียวอนุมานว่าเครื่องมือวัดควรตอบกลับภายในเวลาเท่าใด
แพ็กเก็ต Keepalive และจำนวนครั้งที่ส่งตรวจสอบขึ้นอยู่กับการนำไปใช้ของระบบและอุปกรณ์ ไม่ควรนำกฎ ‘ปิดหลังไม่ได้รับการตอบกลับสามครั้ง’ มาใช้เป็นมาตรฐานเดียวกันทั้งหมด การเชื่อมต่อกลับคืนไม่ได้หมายความว่าคำสั่งควบคุมก่อนหน้านี้ยังไม่ถูกดำเนินการ ก่อนลองใหม่หลังหมดเวลา ให้พิจารณาว่าสามารถทำซ้ำคำสั่งได้อย่างปลอดภัยหรือไม่ และหากจำเป็น ให้สอบถามสถานะก่อนหรือใช้กลไกธุรกรรมที่โปรโตคอลรองรับ
6. การเชื่อมต่อหลายรายการกับการแปลง Modbus ไม่ใช่ความสามารถเดียวกัน
การอนุญาตให้มีหลายเซสชัน TCP บ่งบอกเพียงความสามารถในการเข้าถึงผ่านเครือข่าย หากมาสเตอร์หลายตัวเขียนลงบัส RS485 เดียวกันพร้อมกัน อาจเกิดคำขอขัดแย้งกันและจับคู่การตอบกลับผิด ต้องตรวจสอบว่าอุปกรณ์มีการจัดสรรสิทธิ์ การเข้าคิว การเข้าถึงแบบอ่านอย่างเดียว หรือโหมดเกตเวย์ที่ชัดเจนหรือไม่ และประสานการทำงานผ่านโซลูชันโดยรวม
การแปลง Modbus RTU เป็น TCP ต้องจัดการโครงสร้างข้อความทั้งสองประเภทและการจับคู่ธุรกรรมอย่างถูกต้อง ไม่ใช่เพียงส่งไบต์ RTU ไปบน TCP ก็เสร็จสมบูรณ์ การมีตัวเลือก ‘Modbus’ ในโหมด TCP ก็ไม่อาจพิสูจน์ว่าอุปกรณ์ทุกรุ่นรองรับได้ บทความนี้จึงไม่นำจำนวนเซสชันสูงสุด กฎการแย่งสิทธิ์ และขอบเขตเมนูจากบทความเก่าที่ไม่มีข้อมูลรุ่นเฉพาะรองรับมาใช้เป็นข้อกำหนดทั่วไป
7. ดำเนินการตั้งค่าและตรวจรับหน้างานตามลำดับ
บันทึกบทบาทของคอมพิวเตอร์โฮสต์ อินเทอร์เฟซของอุปกรณ์ปลายทาง และรูปแบบการสื่อสารอนุกรมก่อน จากนั้นวางแผนแอดเดรสเครือข่าย พอร์ต และขอบเขตการเข้าถึง ในสภาพแวดล้อมทดสอบที่แยกออกมา ให้ใช้อุปกรณ์ปลายทางที่ทราบข้อมูลแน่ชัดหนึ่งตัวทดสอบการรับส่งระดับแอปพลิเคชันให้ครบทั้งสองทิศทาง พร้อมสังเกตสถานะการเชื่อมต่อ จำนวนข้อมูลอนุกรม และข้อมูลตอบกลับดิบ จากนั้นปรับพารามิเตอร์การรวบรวมข้อมูลเป็นแพ็กเก็ตทีละรายการ และบันทึกการตั้งค่าที่สามารถย้อนกลับได้
หลังเชื่อมต่อกลับเข้าระบบภาคสนาม ให้ทดสอบการสอบถามข้อมูลอย่างต่อเนื่อง โหลดที่เกิดพร้อมกัน และการกู้คืนหลังขาดการเชื่อมต่อ พร้อมตรวจสอบระยะหมดเวลา เนื้อหาตอบกลับ และคำสั่งซ้ำ TCP ไม่ได้หมายถึงการเข้ารหัส การเข้าถึงระยะไกลต้องใช้ช่องทางที่ปลอดภัยและการควบคุมการเข้าถึงที่วางแผนไว้ และห้ามเปิดหน้าเว็บจัดการหรือพอร์ตควบคุมสู่อินเทอร์เน็ตสาธารณะโดยตรง เช่นเดียวกัน UDP ก็ไม่อาจละเว้นการจำกัดแหล่งที่มาและการอนุญาตสิทธิ์ได้
8. วิธีตรวจสอบผลิตภัณฑ์เฉพาะรุ่น
รายละเอียดซีรีส์ FCT-1500 ของ Feichang Technology ระบุโหมด TCP Server/Client, UDP, พอร์ตอนุกรมเสมือน และโหมดที่เกี่ยวข้องกับ Modbus ซึ่งสามารถเลือกและตั้งค่าให้เหมาะกับซอฟต์แวร์โฮสต์และโปรโตคอลของอุปกรณ์ปลายทางได้ ในการเลือกผลิตภัณฑ์ ให้ยืนยันอินเทอร์เฟซที่สั่งซื้อจริง โหมดการทำงานที่เฟิร์มแวร์รองรับ และฟังก์ชันการแปลงก่อน จากนั้นตรวจสอบจำนวนการเชื่อมต่อ พารามิเตอร์การรวบรวมข้อมูลเป็นแพ็กเก็ต และการเชื่อมต่อใหม่ อย่าถือว่าข้อมูลประชาสัมพันธ์ของซีรีส์เป็นคู่มือฉบับสมบูรณ์สำหรับทุกการกำหนดค่า
หากต้องการพิจารณาเพียงโหมดการทำงานทั่วไป ให้ดู 1197 หากต้องการตัวอย่างการตั้งค่าเซิร์ฟเวอร์ TCP ที่ต่อเนื่องครบถ้วน ให้ดู 2271 บทความนี้อธิบาย UDP และกลไกการรวบรวมข้อมูลเป็นแพ็กเก็ตแยกต่างหาก เพื่อช่วยให้ผู้อ่านเข้าใจว่าเหตุใด ‘เปลี่ยนไปใช้ UDP’ และ ‘ตั้งเวลาเป็นศูนย์’ จึงไม่ใช่วิธีแก้ปัญหาที่ใช้ได้ทุกกรณี
เอกสารอ้างอิง: ข้อกำหนดทางเทคนิคของ TCP ; ข้อกำหนด UDP ; รายละเอียดซีรีส์ FCT-1500 ของ Feichang Technology . ภาพประกอบเป็นแผนภาพกลไกทั่วไป ไม่ใช่ผลการวัดจริงหรือเมนูของรุ่นใดรุ่นหนึ่ง
วิธีตรวจสอบบทความเก่าเกี่ยวกับการตั้งค่าไคลเอนต์และ UDP ทีละรายการ
เมื่ออุปกรณ์ทำหน้าที่เป็น TCP Client ให้เริ่มการรอรับการเชื่อมต่อในโปรแกรมส่วนกลางก่อน กรอกแอดเดรสส่วนกลางที่เข้าถึงได้และพอร์ตรอรับการเชื่อมต่อของแอปพลิเคชัน จากนั้นตรวจสอบรูปแบบอักขระ ช่องสัญญาณ และการส่งรับทั้งสองทิศทาง แอดเดรสหน้าเว็บจัดการไม่สามารถใช้แทนปลายทางของแอปพลิเคชันได้ บันทึกการตั้งค่าและทดสอบพฤติกรรมหลังปิดแล้วเปิดเครื่องใหม่และหลังขาดการเชื่อมต่อ หากรองรับการเชื่อมต่อระยะสั้นหรือหลายปลายทาง ให้ยืนยันตามรุ่นนั้น ๆ และอย่าอนุมานขีดจำกัดสูงสุดจากชื่อ Client
สำหรับการทดสอบ UDP ให้บันทึกแอดเดรสและพอร์ตที่ผูกไว้ในเครื่องแยกจากแอดเดรสและพอร์ตปลายทาง การส่งไปยังปลายทางคงที่กับการตอบกลับตามแหล่งที่มาเป็นคนละกลยุทธ์ ส่วนเมนู UDP Server หรือ Client ใช้พฤติกรรมใดโดยเฉพาะต้องดูจากคู่มือ อย่ากรอกพอร์ตที่ขัดแย้งกันในช่องพารามิเตอร์เดียวกันของทั้งสองฝั่ง และอย่าใช้การแฮนด์เชค TCP เพื่อตัดสินว่า UDP ออนไลน์อยู่ ให้ใช้ข้อมูลทดสอบปริมาณน้อยที่แยกแยะได้เพื่อตรวจสอบเส้นทางทั้งสองทิศทางก่อน แล้วจึงตรวจสอบว่าแอปพลิเคชันจัดการข้อมูลสูญหาย ข้อมูลซ้ำ และข้อมูลที่มาถึงผิดลำดับอย่างไร
บทความนี้สืบทอดเนื้อหาที่ยังถูกต้องจากบทความเก่าที่เกี่ยวข้อง แผนภาพหลักการเป็นภาพอธิบายหลักการทั่วไป โดยตรวจสอบกลไกทั่วไปและความสามารถของรุ่นเฉพาะแยกจากกัน
แปลจากบทความเทคนิคภาษาจีน ต้นฉบับเผยแพร่ครั้งแรก: 2022-12-09 ต้นฉบับแก้ไขล่าสุด: 2026-10-13T11:01:30+08:00. อ่านต้นฉบับภาษาจีน
