ส่งข้อมูลพอร์ตอนุกรมเข้า Web API ด้วยโหมด HTTP บน MT200: GET กับ POST ต่างกันตรงไหน

วันที่ 19 สิงหาคม 2569 | คู่มือใช้งาน | VR Automation

ทีมไอทีของโรงงานมักมีระบบหลังบ้านที่รับข้อมูลผ่าน REST API อยู่แล้ว ไม่ว่าจะเป็น ERP ระบบบำรุงรักษา หรือแดชบอร์ดที่เขียนเอง แต่เครื่องจักรหน้าไลน์กลับพูดได้แค่ RS232 หรือ RS485 การเขียนตัวกลางแปลงโปรโตคอลขึ้นมาเองหมายถึงต้องมีเซิร์ฟเวอร์อีกเครื่องและโค้ดอีกชุดที่ต้องดูแล เกตเวย์ MT200 มีทางลัดที่ตรงกว่านั้น คือโหมด HTTP ซึ่งเติมและตัดหัวโปรโตคอลให้อัตโนมัติ ทำให้ข้อมูลจากพอร์ตอนุกรมกลายเป็นคำขอ HTTP ที่ Web API รับได้ทันที

หลักการทำงานของโหมด HTTP

เมื่อตั้งช่องซ็อกเก็ตให้ทำงานในโหมด HTTP ผ่านซอฟต์แวร์คอนฟิกหรือหน้าเว็บ อุปกรณ์จะทำสองอย่างโดยอัตโนมัติ

ขาส่งออก อุปกรณ์จะเติมหัวโปรโตคอล HTTP ให้กับข้อมูลที่รับมาจากพอร์ตอนุกรมแล้วส่งไปยังเซิร์ฟเวอร์ HTTP

ขารับกลับ อุปกรณ์จะตัดหัว HTTP ออกจากข้อมูลที่เซิร์ฟเวอร์ส่งกลับมา แล้วส่งเฉพาะเนื้อข้อมูลออกทางพอร์ตอนุกรม

ผลคืออุปกรณ์ปลายทางที่พูดได้แค่ข้อความอนุกรมธรรมดา สามารถคุยกับ Web API สมัยใหม่ได้โดยไม่ต้องแก้เฟิร์มแวร์ของตัวเองแม้แต่บรรทัดเดียว

ความต่างระหว่าง GET กับ POST ในทางปฏิบัติ

คู่มืออธิบายความต่างไว้ตรงจุดที่วางข้อมูล สำหรับคำขอแบบ GET ข้อมูลที่พอร์ตอนุกรมรับมาจะถูกวางไว้หลังส่วนพาธ โดยอุปกรณ์เติมเครื่องหมาย ? ระหว่างพาธกับข้อมูลให้เอง ส่วนคำขอแบบ POST ข้อมูลจะถูกวางไว้ในส่วนเนื้อหา และอุปกรณ์เติมฟิลด์ Content-Length ให้อัตโนมัติตามจำนวนไบต์ที่รับมาจากพอร์ตอนุกรม

ตัวอย่างจากคู่มือ เมื่อพอร์ตอนุกรมรับข้อมูล pppp และตั้งพาธเป็น /1111 คำขอแบบ GET ที่ส่งออกจะเป็น GET /1111?pppp HTTP/1.1 พร้อมบรรทัด Host: 192.168.83.107 ขณะที่คำขอแบบ POST จะเป็น POST /1111 HTTP/1.1 ตามด้วย Host และ Content-Length: 4 แล้วจึงเป็นเนื้อหา pppp

ในขาตอบกลับ ตัวอย่างของคู่มือคือเซิร์ฟเวอร์ตอบ HTTP/1.1 200 OK พร้อม Content-Length: 5 และเนื้อหา DDDDD ซึ่งพอร์ตอนุกรมของอุปกรณ์จะแสดงผลออกมาเป็น DDDDD เท่านั้น โดยหัวทั้งหมดถูกตัดทิ้งไปแล้ว

หัวข้อ	โหมด GET	โหมด POST
ตำแหน่งข้อมูล	ต่อท้ายพาธ	อยู่ในส่วนเนื้อหา
ตัวคั่นที่อุปกรณ์เติมให้	เครื่องหมาย `?`	ฟิลด์ `Content-Length`
ตัวอย่างบรรทัดคำขอ	`GET /1111?pppp HTTP/1.1`	`POST /1111 HTTP/1.1`
เหมาะกับข้อมูล	สั้น เป็นค่าตัวเลขไม่กี่ตัว	ยาวขึ้น หรือเป็นโครงสร้าง JSON
ข้อจำกัดความยาวพาธ	63 ไบต์	63 ไบต์
ค่าเริ่มต้นของอุปกรณ์	ต้องเลือกเอง	เป็นค่าเริ่มต้น

ตารางสรุป http mode get post mt200 — พารามิเตอร์โหมด HTTP ของ MT200 — ค่าอ้างอิงจากคู่มือผู้ผลิต

⚠️ ข้อควรระวัง: ถ้าจะยิงข้อมูลเข้า API ที่ต้องยืนยันตัวตน ให้ใส่หัวสำหรับยืนยันตัวตนในช่อง HTTP parameters แต่ต้องคุมความยาวรวมของหัวทั้งหมดไม่ให้เกิน 250 ไบต์ โทเคนแบบยาวหลายร้อยอักขระจะใส่ไม่ได้ ทางแก้ที่ใช้ได้จริงคือขอคีย์แบบสั้นจากทีมหลังบ้าน หรือย้ายการยืนยันตัวตนไปไว้ที่ระดับเครือข่าย เช่น จำกัด IP ต้นทางแทน

พารามิเตอร์ที่ต้องตั้งตอนสร้างช่องโหมด HTTP

เมื่อสร้างซ็อกเก็ตด้วย SOCK/New แล้วเลือกโหมด HTTP ระบบจะถามพารามิเตอร์เพิ่ม 4 รายการ

HTTP type ชนิดคำขอ ค่าเริ่มต้นคือ POST เลือกได้ระหว่าง POST กับ GET

HTTP path เส้นทางของคำขอ คู่มือระบุว่าต้องขึ้นต้นด้วยเครื่องหมาย / และยาวได้สูงสุด 63 ไบต์

HTTP version เวอร์ชันโปรโตคอล ค่าเริ่มต้น 1.0 เลือกได้ระหว่าง 1.0 กับ 1.1

HTTP parameters สำหรับใส่หัว HTTP เพิ่มเติม ใส่ได้หลายบรรทัดโดยจบแต่ละบรรทัดด้วย Enter ถ้าไม่ต้องการใส่ให้กด Enter ผ่านไป โดยความยาวรวมของหัวคำขอทั้งหมดต้องน้อยกว่า 250 ไบต์ ช่องนี้คือจุดที่ใช้ใส่คีย์ยืนยันตัวตนหรือกำหนดชนิดเนื้อหา

ข้อควรพิจารณาก่อนเลือกโหมด HTTP

โหมด HTTP เหมาะกับการรายงานค่าเป็นช่วงมากกว่าการสตรีมข้อมูลต่อเนื่อง เพราะทุกคำขอมีค่าใช้จ่ายเรื่องหัวโปรโตคอล ถ้าต้องส่งข้อมูลถี่มาก โหมด MQTT หรือ TCP แบบส่งผ่านโปร่งใสจะประหยัดกว่า

ควรวางแผนเรื่องขนาดข้อมูลด้วย เพราะบัฟเฟอร์ของช่องซ็อกเก็ตมีค่าเริ่มต้น 512 ไบต์ และตั้งได้สูงสุด 1400 ไบต์ ข้อมูลที่ยาวกว่านี้จะถูกแบ่งเป็นหลายคำขอ

สำหรับการเข้ารหัส คู่มือระบุว่าโหมด TLS 1.2 รองรับเฉพาะเมื่อซ็อกเก็ตทำงานในโหมด TCP Client เท่านั้น ดังนั้นหากต้องการเรียก HTTPS โดยตรงควรตรวจสอบข้อจำกัดนี้กับรุ่นและเวอร์ชันเฟิร์มแวร์ที่ใช้งานจริงก่อนออกแบบระบบ

การนำไปใช้งานในอุตสาหกรรม

ส่งค่ามิเตอร์เข้าระบบ ERP — อ่านค่าจากมิเตอร์ผ่าน RS485 แล้วยิงเป็น POST เข้าเอนด์พอยต์ของ ERP ตามรอบ โดยไม่ต้องมีเซิร์ฟเวอร์ตัวกลาง
แจ้งเตือนเข้าระบบแจ้งซ่อม — เมื่อเครื่องจักรส่งข้อความแจ้งความผิดปกติออกทางพอร์ตอนุกรม ให้เกตเวย์แปลงเป็นคำขอ HTTP เข้าระบบเปิดใบงานทันที
บันทึกข้อมูลลงฐานข้อมูลผ่าน API สั้น ๆ — ใช้โหมด GET กับค่าตัวเลขไม่กี่ตัว ทำให้เขียนฝั่งรับได้ง่ายและอ่านล็อกของเว็บเซิร์ฟเวอร์ได้ตรง ๆ

ดูสินค้าในหมวดที่เกี่ยวข้องได้ที่ เกตเวย์เชื่อมต่อระบบและอุปกรณ์เครือข่ายอุตสาหกรรม หรือเลือกชมสินค้าทั้งหมดที่ ร้านค้า VR Automation

คำถามที่พบบ่อย (FAQ)

โหมด HTTP รองรับ HTTPS ด้วยหรือไม่

คู่มือระบุตัวเลือกความปลอดภัยของซ็อกเก็ตไว้ว่า TLS 1.2 แบบไม่ใช้ใบรับรองรองรับเฉพาะโหมด TCP Client ส่วน AES และ DES3 รองรับทั้ง TCP และ UDP ดังนั้นหากต้องการเรียกปลายทางแบบ HTTPS ควรตรวจสอบข้อจำกัดกับรุ่นและเฟิร์มแวร์ที่ใช้จริงก่อนออกแบบระบบ

ใส่หัว HTTP เพิ่มเองได้กี่บรรทัด

ใส่ได้หลายบรรทัด โดยจบแต่ละบรรทัดด้วยการกด Enter แต่คู่มือกำหนดเพดานรวมไว้ว่าความยาวของข้อมูลหัวคำขอ HTTP ทั้งหมดต้องน้อยกว่า 250 ไบต์

ข้อมูลที่เซิร์ฟเวอร์ตอบกลับมาจะมีหัว HTTP ติดมาด้วยไหม

ไม่มี คู่มือระบุว่าอุปกรณ์จะกรองข้อมูล HTTP ที่รับมา ตัดส่วนหัวออก แล้วส่งเฉพาะเนื้อข้อมูลไปยังพอร์ตอนุกรม ตัวอย่างในคู่มือคือเซิร์ฟเวอร์ตอบ Content-Length เป็น 5 พร้อมเนื้อหา DDDDD และพอร์ตอนุกรมจะได้รับเฉพาะ DDDDD

สรุป

โหมด HTTP ทำให้อุปกรณ์อนุกรมรุ่นเก่าคุยกับ Web API สมัยใหม่ได้โดยไม่ต้องเขียนตัวกลางเอง กฎที่ควรจำมีสามข้อ คือ GET วางข้อมูลหลังพาธพร้อมเครื่องหมายคำถามที่อุปกรณ์เติมให้ POST วางข้อมูลในเนื้อหาพร้อม Content-Length ที่คำนวณอัตโนมัติ และหัวคำขอทั้งหมดรวมกันต้องน้อยกว่า 250 ไบต์ ออกแบบเอนด์พอยต์ให้พาธสั้น ข้อมูลกระชับ แล้วโหมดนี้จะทำงานได้เสถียรในระยะยาว

แหล่งข้อมูลและมาตรฐานอ้างอิง

Catalog: Mortise and tenon series product software functions_20250312.pdf (75 หน้า) — VR Automation (เอกสารเทคนิคจากผู้ผลิต)
Steve’s Internet Guide — Using HTTP APIs For IoT: Beginners Guide — อธิบายการใช้ HTTP GET/POST สำหรับส่งข้อมูลอุปกรณ์ IoT
ThingsBoard — IoT Gateway REST Connector — ตัวอย่างรูปแบบเกตเวย์ที่แปลงข้อมูลอุปกรณ์เป็น REST endpoint
IoT For All — IoT Is Eating the World: APIs and REST — บริบทการแมป HTTP method เข้ากับการทำงานของระบบหลังบ้าน