title: “การเชื่อมต่อข้อมูลเครื่องชั่ง: จากค่านิ่งสู่บันทึกคุณภาพ”
slug: “weighing-scale-data-integration-factory-2026-th”
lang: “th”
meta_description: “คู่มือการเชื่อมต่อข้อมูลเครื่องชั่งสำหรับโรงงานไทย ครอบคลุมค่านิ่ง tare/net/gross หน่วย สถานะสอบเทียบ ล็อต RS-232 ถึง OPC UA, RFP และการทดสอบรับมอบ”
keywords: “การเชื่อมต่อข้อมูลเครื่องชั่ง, การบันทึกข้อมูลเครื่องมือวัดอัตโนมัติ, การเก็บข้อมูลการตรวจสอบ, บันทึกคุณภาพดิจิทัล”
category: “OT・IoTトレーサビリティ”
การเชื่อมต่อข้อมูลเครื่องชั่ง ไม่ได้เสร็จเพียงเพราะตัวเลขจากหน้าจอเข้าคอมพิวเตอร์ได้ บันทึกคุณภาพที่ใช้งานจริงต้องบอกได้ว่าค่านั้นนิ่งแล้วหรือยัง เป็นน้ำหนักรวม (gross) น้ำหนักภาชนะ (tare) หรือน้ำหนักสุทธิ (net) ใช้หน่วยอะไร และผูกกับล็อต รหัสสินค้า ผู้ปฏิบัติงาน เครื่องชั่ง และเวลาใด บทความนี้อธิบายข้อกำหนดเฉพาะของเครื่องชั่ง ตั้งแต่การออก RFP จนถึง FAT/SAT สำหรับโรงงานในประเทศไทย
หากต้องการภาพรวมของการเชื่อมต่อเกจและเครื่องมือตรวจสอบหลายชนิด อ่าน “ระบบเก็บข้อมูลการตรวจสอบอัตโนมัติ 2026” บทความนี้จะลงลึกว่า สัญญาณน้ำหนักที่เปลี่ยนตลอดเวลาจะกลายเป็นเหตุการณ์ชั่งที่อนุมัติและตรวจสอบย้อนกลับได้อย่างไร เนื้อหานี้ไม่ใช่คำแนะนำทางกฎหมายและไม่รับประกันการอนุมัติแบบ การตรวจรับรอง หรือการรับรองใด ๆ หากใช้เครื่องชั่งเพื่อการค้า การเป็นหลักฐาน กระบวนการที่ถูกกำกับ หรือเอกสารให้ลูกค้า ควรนำวัตถุประสงค์และรุ่นเครื่องไปยืนยันกับหน่วยงานไทย ผู้ผลิต และผู้เชี่ยวชาญที่เกี่ยวข้อง
การเชื่อมต่อข้อมูลเครื่องชั่งต้องเก็บ “เหตุการณ์ชั่ง” ไม่ใช่ตัวเลขอย่างเดียว
สมมติหน้าจอแสดง 12.345 kg และพอร์ตอนุกรมส่ง 12.345 การทดสอบสื่อสารถือว่าผ่าน แต่การทดสอบบันทึกคุณภาพยังไม่ผ่าน เพราะยังไม่รู้ว่าเป็น gross หรือ net, มีค่า tare ค้างจากภาชนะก่อนหน้าหรือไม่, วัตถุยังเคลื่อนไหวอยู่หรือไม่, กะก่อนเปลี่ยนหน่วยหรือไม่ และล็อตที่เลือกบนจอตรงกับของจริงหรือไม่ ตัวเลขที่ตอบคำถามเหล่านี้ไม่ได้จะนำมาสืบค้นเหตุภายหลังได้ยาก
หน่วยออกแบบของฐานข้อมูลจึงควรเป็น เหตุการณ์ชั่ง (weighing event) หนึ่งเหตุการณ์รวมค่าที่รับรอง เงื่อนไขที่ใช้รับรอง วัตถุและบริบททางธุรกิจ ผู้ปฏิบัติงาน อุปกรณ์ และเวลาที่เกี่ยวข้อง เมื่อโครงสร้างถูกต้อง ข้อมูลชุดเดียวกันจะรองรับการตรวจประเมิน การสืบสวน deviation ลำดับวงศ์ล็อต การใช้วัตถุดิบ และการปรับปรุงกระบวนการได้
ชุดข้อมูลขั้นต่ำที่เฉพาะกับเครื่องชั่ง
| หมวด | ข้อมูลที่ควรมี | คำถามในการออกแบบ |
|---|---|---|
| ค่าน้ำหนัก | gross, tare, net | เก็บครบสามค่าหรือเฉพาะ net และคำนวณย้อนกลับได้หรือไม่ |
| สถานะ | stable, in-motion, zero, over/under range | ใช้การตัดสินของเครื่องหรือคำนวณในระบบชั้นบน |
| หน่วย | kg, g และหน่วยที่อนุญาต | เก็บค่าต้นฉบับกับหน่วยเป็นคู่ก่อนแปลงหรือไม่ |
| สภาพอุปกรณ์ | สอบเทียบ/ตรวจรับรอง ข้อผิดพลาด บำรุงรักษา software ID | พิสูจน์ได้อย่างไรว่าเครื่องพร้อมใช้ ณ เวลาชั่ง |
| บริบท | ล็อต สินค้า ขั้นตอน คำสั่งผลิต ผู้ใช้ Scale ID | แต่ละ ID มาจากการสแกน ล็อกอิน หรือ master ใด |
| เวลา | เวลาเครื่อง เวลา gateway รับ เวลาบันทึก server | เวลาใดเป็นหลัก และตรวจ clock drift อย่างไร |
| ที่มา | interface, raw frame, parser version, retry | สร้างกระบวนการแปลงข้อมูลซ้ำได้หรือไม่ |
| การอนุมัติ | รับอัตโนมัติ ชั่งใหม่ ข้อยกเว้น | ใครมีสิทธิ์แก้ และเก็บ audit trail ใด |
OIML R 51-1 เป็นข้อแนะนำสำหรับเครื่องชั่งอัตโนมัติแบบ catchweighing ซึ่งนิยามอุปกรณ์เก็บข้อมูลการวัดและการแยกซอฟต์แวร์ส่วนที่เกี่ยวข้องทางกฎหมายออกจากส่วนที่ไม่เกี่ยวข้องอย่างชัดเจน อีกทั้งกำหนดให้ผลการชั่งมีชื่อหรือสัญลักษณ์ของหน่วยมวล และหนึ่งค่าที่แสดงใช้หน่วยมวลเพียงหนึ่งหน่วย ไม่ได้หมายความว่า R 51 ใช้กับเครื่องชั่งทุกตัวในโรงงาน แต่ให้หลักออกแบบที่สำคัญคือ อย่าแยกตัวเลขออกจากหน่วย และต้องกำหนดขอบเขตระหว่างแอปธุรกิจที่แก้ไขได้กับฟังก์ชันการชั่งที่อาจเกี่ยวข้องทางกฎหมาย
การบันทึกข้อมูลเครื่องมือวัดอัตโนมัติเริ่มจากนิยาม “ค่านิ่ง”
ค่าจากโหลดเซลล์เปลี่ยนตามแรงสั่น ลม แรงกระแทกตอนเทวัตถุดิบ แรงดึงจากท่อ การยุบตัวของพื้น อุณหภูมิ และการสัมผัสของผู้ปฏิบัติงาน พอร์ตอาจส่งหลายค่าต่อวินาที แต่ไม่ควรถือทุก sample เป็นผลผลิตจริง หากบันทึก continuous output โดยไม่มีเงื่อนไขรับรอง งานหนึ่งครั้งจะมีตัวเลขผู้สมัครจำนวนมากและไม่มีใครรู้ว่าค่าใดคือค่าที่อนุมัติ
ใช้ stable flag จากเครื่องชั่งเมื่อมี
ทางเลือกแรกคือ stable flag หรือคำสั่งตอบเฉพาะค่านิ่งตามนิยามผู้ผลิต เพราะใช้ตรรกะเดียวกับจอ การกรอง และความละเอียดของเครื่อง มีขอบเขตความรับผิดชอบชัดกว่าการคาดเดาจาก sampling ในระบบชั้นบน อย่างไรก็ตาม RFP ต้องถามมากกว่าคำว่า “มี stable หรือไม่”
- เกณฑ์ stable ปรับได้หรือไม่ และมีประวัติการเปลี่ยนหรือไม่
- เรียกค่านิ่งแบบ request/response ได้หรือส่งสถานะมากับ continuous output
- ค่านิ่งถูกส่งซ้ำกี่ครั้ง และมี event ID ป้องกันรายการซ้ำหรือไม่
- แยก zero, tare, motion, ค่าติดลบ และ out-of-range ได้หรือไม่
- หลัง reconnect เครื่องส่งค่าจาก buffer เก่าซ้ำหรือไม่
หากเครื่องไม่มี stable ระบบ edge อาจใช้กฎ เช่น ช่วงระหว่างค่าสูงสุดกับต่ำสุดภายในหน้าต่างเวลาหนึ่งต้องไม่เกิน threshold แต่กฎนี้เป็น กฎการใช้งานของ TOMAS TECH ไม่ใช่การแทนที่ stability ของผู้ผลิตหรือความสอดคล้องด้านมาตรวิทยาตามกฎหมาย ต้องระบุ sampling, threshold, observation window, filter และ range แล้วทวนสอบกับสภาพติดตั้งและสินค้าจริง
อย่าบันทึกทันทีทุกครั้งที่สถานะเปลี่ยนเป็น stable
ภาชนะเปล่าที่วางบนแท่นก็นิ่งได้ วัตถุดิบที่เทครึ่งหนึ่งแล้วหยุดชั่วคราวก็นิ่งได้ เงื่อนไขรับรองจึงต้องรวมธุรกิจเข้ากับ stable:
- เปิดคำสั่งผลิตหรือใบตรวจสอบแล้ว
- สแกนสินค้าและล็อตจากของจริงแล้ว
- งานถูกมอบหมายให้ Scale ID ที่ถูกต้อง
- net อยู่ในช่วง recipe/specification ที่ใช้บังคับ
- stable ต่อเนื่องครบเวลาหรือผู้ปฏิบัติงานกดยืนยัน
- ยังไม่มีเหตุการณ์ที่รับรองแล้วสำหรับ order-operation-sequence เดียวกัน
จุดหมายของ automation ไม่ใช่แค่ลดการพิมพ์ แต่คือทำให้หลักฐานที่ใช้รับรองค่ามีมาตรฐานเดียวกัน

จัดการ tare, net และ gross ในบันทึกคุณภาพดิจิทัล
Tare เป็นจุดเสี่ยงมากที่สุดจุดหนึ่ง หากระบบชั้นบนเก็บเพียง net เมื่อเกิดปัญหาจะไม่รู้ว่าใช้ภาชนะผิด มี tare เดิมค้าง หรือใช้ preset tare ผิด หลักที่ปลอดภัยคือเก็บ gross, tare, net และ tare mode ในเหตุการณ์เดียวกันเท่าที่เครื่องรองรับ
กำหนดกฎตรวจสอบความสอดคล้องของสามค่า
ในเชิงแนวคิด net = gross - tare แต่การปัดเศษ ความละเอียดภายใน การแปลงหน่วย และเครื่องหมายอาจทำให้ค่าที่แสดงต่างกันหนึ่ง scale interval RFP ควรกำหนด:
- เปรียบเทียบค่าภายใน ค่าที่ส่ง หรือค่าบนจอ
- tolerance สัมพันธ์กับ scale interval อย่างไร
- สามค่ามาจาก snapshot และเวลาเดียวกันหรือไม่
- แยก measured tare กับ preset tare ด้วยรหัสใด
- การ clear tare, re-tare และ set zero เก็บเป็น event หรือไม่
OPC UA for Weighing Technology มีแบบจำลองที่รวม SetTare, ClearTare, SetPresetTare, SetZero, RegisterWeight ตลอดจนชนิดข้อมูลน้ำหนัก tare mode และสถานะเครื่อง การเขียนว่า “รองรับ OPC UA” ไม่ทำให้ระบบถูกต้องโดยอัตโนมัติ แต่ companion specification ช่วยให้ผู้ซื้อกับผู้ขายใช้คำศัพท์เดียวกันเมื่อกำหนดค่า สถานะ และคำสั่ง
เก็บค่าและหน่วยเป็นวัตถุเดียวกัน
คอลัมน์ weight_kg จะเป็นอันตรายหากมีคนตั้งเครื่องเป็น g แต่ parser ยังคิดว่าเป็น kg ควรเก็บ original value, original unit, normalized value, normalized unit และเวอร์ชันกฎแปลง หากเครื่องส่ง 12500 g และ MES แปลงเป็น 12.500 kg ให้เก็บทั้งคู่ BIPM SI Brochure เป็นเอกสารทางการของ SI และใช้เป็นเกณฑ์จัดมาตรฐานสัญลักษณ์หน่วยในจอ CSV API และรายงานได้
ผูกล็อต สินค้า ผู้ปฏิบัติงาน และ Scale ID ก่อนรับค่าน้ำหนัก
ในการเก็บข้อมูลการตรวจสอบ การระบุวัตถุให้ถูกมักยากกว่าการอ่านค่า น้ำหนักที่แม่นแต่ติดกับล็อตผิดยังเป็นบันทึกคุณภาพที่ผิด ลำดับงานควรเป็น “บริบทก่อน ค่าเป็นขั้นสุดท้าย”
- ผู้ปฏิบัติงานล็อกอินด้วย ID ส่วนบุคคล
- เปิด production/inspection order
- สแกนสินค้าและล็อตจากฉลากของจริง
- ระบบตรวจ order, item, lot, operation และ limit
- ยืนยัน Scale ID ที่ได้รับมอบหมาย
- วางภาชนะและทำ tare ตามวิธีที่อนุมัติ
- รับ event เมื่อ stable และอยู่ในช่วง
- พิมพ์ฉลาก ปลดล็อกขั้นถัดไป หรือเปิด deviation
ดูการระบุของจริงเพิ่มเติมใน “ระบบจัดการบาร์โค้ดโรงงาน 2026” และการกำหนดความละเอียดของ genealogy ใน “ต้นทุนการสร้างระบบตรวจสอบย้อนกลับ 2026”
GS1 Global Traceability Standard จัดบริบทข้อมูลด้วย who, what, when, where และ why ภายใต้แนวคิด Identify–Capture–Share สำหรับเหตุการณ์ชั่ง ตัวเลขจากเครื่องเป็นเพียงส่วนหนึ่งของ “what” การเพิ่มผู้ปฏิบัติงาน วัตถุ เวลา สถานที่ และวัตถุประสงค์ทำให้ข้อมูลหน้างานเชื่อมกับการตรวจสอบย้อนกลับทั้งภายในและห่วงโซ่อุปทาน
เลือก RS-232, USB, Ethernet, fieldbus หรือ OPC UA อย่างไร
อย่าเลือกเพราะเทคโนโลยีใหม่กว่า ให้พิจารณาฐานเครื่องเดิม ระยะทาง สัญญาณรบกวน PLC ข้อมูลสถานะที่ต้องการ cybersecurity และทักษะทีมซ่อมบำรุงในพื้นที่
| วิธี | เหมาะกับ | จุดแข็ง | ความเสี่ยงที่ต้องถามใน RFP |
|---|---|---|---|
| RS-232 | เครื่องเก่าหนึ่งตัวใกล้ PC/gateway | เรียบง่าย พบมาก | สาย isolation frame port reconnect |
| USB | สถานีเดี่ยวติด PC | ติดตั้งทางกายภาพง่าย | virtual COM, driver, หลุด, OS lifecycle |
| Ethernet | หลายเครื่องบนเครือข่ายโรงงาน | ระยะทางและบริหารรวม | IP/VLAN, protocol, time sync, certificate, buffer |
| fieldbus | ระบบที่ PLC เป็นศูนย์กลาง | เหมาะกับ interlock | mapping เฉพาะยี่ห้อ diagnostics และ word definition |
| OPC UA | ต้องการ semantic ข้ามผู้ผลิต | ค่า สถานะ และชนิดอุปกรณ์มีโครงสร้าง | profile/NodeSet, security, implementation gap |
RS-232 ต้องมีตัวอย่าง frame ไม่ใช่แค่คำว่าเชื่อมได้
ASCII frame อาจต่างกันที่ start/end character เครื่องหมาย จุดทศนิยม หน่วย stable marker gross/net checksum command และ timeout ให้แนบ frame จริงกับ RFP และทดสอบ parser กับ firmware รุ่นจริงใน FAT อุปกรณ์ USB ที่แสดงเป็น virtual COM ก็มีคำถามระดับแอปแบบเดียวกัน
Ethernet ต้องระบุ application protocol
คำว่า “ต่อ LAN ได้” ไม่บอกว่าเป็น proprietary TCP, Modbus TCP, HTTP หรือ OPC UA ต้องจำกัดทิศทางและพอร์ตที่อนุญาต ไม่ควรวางเครื่องชั่งในเครือข่าย office แบบเปิด หากใช้ certificate ต้องวางวิธีออก ต่ออายุ เพิกถอน และกู้คืนหลังเปลี่ยนอุปกรณ์ด้วย
OPC UA ต้องดูว่า model อะไร ไม่ใช่ดูเพียงช่องรองรับ
OPC Foundation และ VDMA กำหนด Weighing Technology model สำหรับ automatic filling, catchweigher, checkweigher, continuous, hopper, laboratory, piece-counting, simple, totalizing และ vehicle scale เป็นต้น RFP ควรถามเวอร์ชัน OPC 40200, scale type, Server Facet, nodes และ methods ที่รองรับ หากมีแต่ proprietary nodes การเปลี่ยนผู้ผลิตในอนาคตยังต้องพัฒนาใหม่

แบ่งหน้าที่ระหว่าง PLC, MES และฐานข้อมูลคุณภาพ
การใส่ทุกอย่างใน PLC หรือส่งทุกการตัดสินไป cloud ทำให้ระบบเปราะ ISA-95 จัดโครงสร้างการเชื่อมระบบองค์กรกับระบบควบคุม โดยทั่วไป Level 1 คือ sensor/device, Level 2 คือ PLC/DCS ที่ควบคุมและกำกับ และ Level 3 คือการบริหารการผลิต เช่น MES/SCADA จึงควรแบ่งตามความเร็วและความรับผิดชอบ
| ชั้น | หน้าที่หลัก | ตัวอย่างข้อมูลเครื่องชั่ง |
|---|---|---|
| เครื่อง/indicator | วัด แสดง stable และสถานะ | gross/tare/net, unit, stable, error |
| PLC/edge | interlock ทันที เฝ้าการสื่อสาร buffer ระยะสั้น | limit, valve permit, dedup, store-and-forward |
| MES | ผูก order สินค้า ล็อต ผู้ปฏิบัติงาน | weighing event, reweigh reason, operation complete |
| Quality DB/QMS | spec, deviation, review, trend | approved result, spec version, deviation ID |
| ERP | master/order/inventory และผลรวม | order, consumption, accepted net, costing |
การหยุดเครื่องระดับ millisecond ควรอยู่ PLC/edge ไม่พึ่ง round trip ไป MES/cloud ส่วน genealogy สิทธิ์ และการเก็บระยะยาวไม่ควรถูกขังใน PLC เมื่อเครือข่ายขาด ระบบต้องเข้าสู่สถานะปลอดภัยที่กำหนด และส่ง event ที่ buffer ไว้ตามลำดับหลังฟื้นตัว
Offline ต้องเลือก stop, limited continuation หรือ controlled fallback
หากเป็น critical characteristic อาจต้องหยุดเมื่อยืนยัน order/spec ปัจจุบันไม่ได้ งานความเสี่ยงต่ำอาจทำต่อด้วย job และ limit ที่ลงลายเซ็นและ preload ที่ edge หากยังใช้กระดาษแล้วป้อนภายหลัง ต้องทำเครื่องหมายต่างจากข้อมูลปกติ พร้อมเหตุผล ผู้ป้อน ผู้ตรวจ และเอกสารต้นฉบับ
เก็บสถานะสอบเทียบ การตรวจรับรอง และเวลาพร้อมผลชั่ง
PDF ใบสอบเทียบใน shared folder ไม่ได้พิสูจน์อัตโนมัติว่า event หนึ่งใช้เครื่องที่มีสิทธิ์ใช้งาน Scale master ควรมี Scale ID, serial, location, capacity, division, use class, last/next calibration, enabled status และ certificate ID ส่วน event เก็บ snapshot สถานะหรือ reference version ที่ใช้ ณ เวลานั้น
อย่าใช้คำว่า “สอบเทียบแล้ว”, “daily check ผ่าน” และ “ใช้ตามกฎหมายได้” แทนกัน การสอบเทียบแสดงความสัมพันธ์กับค่ามาตรฐาน ส่วน type approval, verification, seal หรือ re-verification อาจเป็นหน้าที่ทางกฎหมายอีกชุดหนึ่ง daily check ก็ไม่แทนสองเรื่องนี้ ให้เก็บเป็นสถานะแยกและกำหนดการตอบสนองของงานแต่ละสถานะ
ควรแยกเวลา capture ที่เครื่อง/edge, เวลา gateway รับ และเวลา server commit พร้อมสถานะ NTP และ time zone รูปแบบหนึ่งที่เหมาะกับโรงงานไทยคือเก็บ UTC แล้วแสดง ICT แต่ต้องตกลงกับ MES เดิมและระบุ offset เมื่อแลกข้อมูลข้ามประเทศ
แยกมาตรวิทยาตามกฎหมายกับการควบคุมกระบวนการตั้งแต่ต้น RFP
ประเทศไทยมีพระราชบัญญัติมาตราชั่งตวงวัด พ.ศ. 2542 และกรมการค้าภายในเผยแพร่กฎหมายที่เกี่ยวข้อง แต่ไม่ได้หมายความว่าเครื่องทุกตัวในโรงงานมีข้อกำหนดเหมือนกัน หรือเครื่องที่เรียกว่า process scale จะอยู่นอกขอบเขตเสมอ วัตถุประสงค์ การใช้เพื่อการค้าหรือเป็นหลักฐาน ชนิดเครื่อง ประกาศที่ใช้ และการแก้ฮาร์ดแวร์/ซอฟต์แวร์อาจมีผล
| คำถาม | คำตอบที่โครงการต้องจัดทำรายเครื่อง |
|---|---|
| วัตถุประสงค์ | batching, incoming inspection, shipment, trade price, internal reference |
| ผู้ใช้ผล | PLC, quality release, customer certificate, invoice, inventory |
| สถานะปัจจุบัน | type, verification/seal และเอกสารอ้างอิง |
| การเปลี่ยนแปลง | read-only, remote tare/zero, configuration, software update |
| ผู้ทบทวน | quality, legal, manufacturer, authority ใดต้องยืนยัน |
การอ่านพอร์ตอย่างเดียวมีความเสี่ยงต่างจากการสั่ง zero, tare หรือ parameter ที่เกี่ยวข้องกับ calibration จากระบบชั้นบน ให้แยกฟังก์ชันที่อาจเกี่ยวข้องทางกฎหมายออกจาก MES และขอคำยืนยันเป็นลายลักษณ์อักษรจากผู้ผลิตต่อ seal, type, software ID และสถานะ verification หมวด OIML-CS เป็นข้อมูลอ้างอิงสากล แต่ ใบรับรอง OIML เพียงอย่างเดียวไม่ได้รับประกันความถูกต้องตามกฎหมายสำหรับการติดตั้งและการใช้เฉพาะในประเทศไทย
16 หัวข้อที่ต้องใส่ใน RFP ของโรงงานไทย
- ทะเบียนเครื่อง: ผู้ผลิต รุ่น serial firmware indicator capacity division
- ประเภทการใช้: process, quality, trade/evidence, customer certificate
- ข้อมูลออก: gross, tare, net, unit, stable, zero, range, error
- ขอบเขตควบคุม: read-only หรือ remote zero/tare/register
- การสื่อสาร: physical layer, protocol, frame, checksum, timeout, reconnect
- บริบท: order, item, lot, operation, operator, scale, container ID
- เวลา: source, UTC/ICT, drift และ timestamp หลายจุด
- Idempotency: event ID, replay, duplicate handling
- Offline: เงื่อนไขเก็บ ลำดับ encryption และเมื่อ buffer เต็ม
- Interlock: จุดตัดสินใน PLC และ safe response
- Metrology status: due-date block, daily check, certificate
- Security: account, role, certificate, log, segmentation, patch
- Audit trail: reweigh, cancel, manual entry, master change
- Data ownership: schema, API/export, migration rights
- ภาษา/บริการ: ไทย อังกฤษ ญี่ปุ่น เวลาตอบสนอง และอะไหล่
- FAT/SAT: pass criteria, owner, retest และ evidence ที่ส่งมอบ
ควรบังคับให้ตอบเป็น matrix รายรุ่น คำว่า “รองรับเครื่องชั่งทุกยี่ห้อ” อาจหมายถึงอ่านตัวเลขได้เท่านั้น ตาราง ○△× สำหรับ status, tare mode, error, remote operation และ time sync จะเปิดเผยงาน custom ก่อนทำสัญญา
FAT และ SAT สำหรับการเก็บข้อมูลการตรวจสอบ
FAT ตรวจข้อกำหนดและ abnormal cases ในสภาพผู้ขาย ส่วน SAT ตรวจซ้ำกับเครื่องจริง พื้น แรงสั่น เครือข่าย PLC และวิธีทำงานจริง การส่งค่าปกติหนึ่งครั้งเข้า database ไม่ถือว่ารับมอบเสร็จ
| การทดสอบ | วิธี | เกณฑ์ผ่าน |
|---|---|---|
| Stability | เติมน้ำหนักเป็นช่วงและหยุดกลางทาง | ไม่รับค่านิ่งกลางทางผิด และสร้างหนึ่ง event |
| Gross/tare/net | สลับ measured/preset tare | mode และสามค่าอยู่ snapshot เดียวและสอดคล้อง |
| Unit | เปลี่ยนหน่วยที่อนุญาต | เก็บหน่วยต้นฉบับ หน่วยผิดถูก block หรือแปลงชัดเจน |
| Lot | สแกนถูก ผิด หมดอายุ | ล็อตผิดรับไม่ได้และมี deviation log |
| Scale mismatch | ใช้เครื่องคนละงาน | ตรวจ assignment ผิดและไม่ให้ยืนยัน |
| Due date | จำลองเครื่องเกินกำหนด | หยุดหรือ exception ตามนโยบายอนุมัติ |
| Network loss | ตัดก่อน ระหว่าง หลัง commit | ไม่หาย ไม่ซ้ำ และ replay ถูกลำดับ |
| Power loss | restart เครื่อง gateway PLC | ค่าเก่าไม่กลายเป็นการชั่งใหม่ |
| Clock drift | เลื่อนเวลา gateway | ตรวจพบและไม่เรียง event ผิดแบบเงียบ ๆ |
| Override | reweigh/cancel/correct | เก็บต้นฉบับ เหตุผล ผู้ทำ และ before/after |
| Boundary | ต่ำกว่า เท่ากับ สูงกว่า limit | rounding/comparison ตรง spec |
| Load | หลายเครื่องส่งพร้อมกัน | ไม่หาย ไม่ผูกข้าม ไม่ซ้ำ ภายใน latency ที่ตกลง |
ทดสอบค่าภายในและค่าบนจอที่ขอบเขต
เมื่อ upper limit คือ 10.00 kg ค่าภายใน 10.004 kg อาจแสดง 10.00 kg ผลผ่าน/ไม่ผ่านจึงขึ้นกับว่าใช้ internal, transmitted หรือ displayed value FAT ต้องทดสอบต่ำกว่า เท่ากับ และสูงกว่า แล้วเทียบผลของจอ PLC MES และ Quality DB หลักฐานควรมี input, expected, actual, firmware, settings, tester และเวลา
ทดสอบรายการซ้ำ ไม่ใช่ทดสอบแค่ข้อมูลหาย
การ replay หลัง reconnect อาจลง material consumption สองครั้ง ควรสร้าง event ID เมื่อเครื่องหรือ edge รับรองการชั่ง และใช้ ID เดิมเมื่อส่งซ้ำ ฝั่ง server ต้องประมวลผล ID เดิมแบบ idempotent ไม่ insert เป็นเหตุการณ์ใหม่

Pilot ต้องมี “เครื่องที่ยาก” ไม่ใช่มีแต่เครื่องใหม่
Pilot ที่ใช้ Ethernet scale ใหม่เพียงตัวเดียวไม่พิสูจน์การขยายสู่ฐานเดิม ควรมีรุ่นเก่าที่ใช้จำนวนมากและอย่างน้อยหนึ่งสภาพยาก เช่น แรงสั่นสูง tare ซับซ้อน washdown บ่อย หรือภาชนะหลายแบบ
- สังเกตการคัดลอก การเลือกล็อต และ reweigh ปัจจุบัน
- อนุมัติ data dictionary ของค่า สถานะ หน่วย ID และความหมายของข้อมูลหาย
- เก็บแบบ read-only คู่กับบันทึกเดิม
- เปิด spec check, stable, dedup และ deviation
- ต่อ interlock หลัง risk review
- ให้ electronic record เป็นฉบับหลักหลัง training, backup, change control
- ใช้ template รายรุ่นและ SAT pack ขยายผล
การจบ parallel run ควรดูว่าครบสินค้า range ภาชนะ กะ และ abnormal cases ที่เป็นตัวแทนแล้ว ไม่ใช่ครบจำนวนวันเท่านั้น
แบบจำลองสมมติสำหรับอธิบายของ TOMAS TECH
ตัวเลขต่อไปนี้เป็น แบบจำลองสมมติสำหรับอธิบายของ TOMAS TECH ไม่ใช่ค่าเฉลี่ยตลาดหรือคำรับรองผู้ขาย ต้องแทนด้วยข้อมูลโรงงานจริง
สมมติชั่ง 240 ครั้ง/วัน 250 วัน/ปี การเขียนและป้อนซ้ำใช้ 45 วินาที/ครั้ง ตรวจซ้ำ 20 วินาที ปัญหาจากการป้อนมือเกิด 3 ครั้งต่อการชั่ง 1,000 ครั้งและใช้สืบสวน 25 นาที/เรื่อง หลัง automation มี controlled exception 2% และใช้ 2 นาที/เรื่อง
- จำนวนชั่งต่อปี = 240 × 250 = 60,000 ครั้ง
- เวลาบันทึก/ตรวจเดิม = 60,000 × 65 วินาที = ประมาณ 1,083 ชั่วโมง
- ปัญหาเดิม = 60,000 ÷ 1,000 × 3 = 180 เรื่อง
- เวลาสืบสวนเดิม = 180 × 25 นาที = 75 ชั่วโมง
- Exception หลังระบบ = 60,000 × 2% = 1,200 เรื่อง
- เวลาจัดการ exception = 1,200 × 2 นาที = 40 ชั่วโมง
- เวลาที่ลดตามแบบจำลอง = 1,083 + 75 − 40 = ประมาณ 1,118 ชั่วโมง/ปี
ถ้าคิดการเงิน ใช้ ชั่วโมงที่ลด × ต้นทุนแรงงานรวมของบริษัท แล้วหัก support รายปี งานสอบเทียบ/ทวนสอบเพิ่ม เครือข่าย อุปกรณ์ทดแทน training และ master maintenance ระยะคืนทุนอย่างง่ายคือ เงินลงทุนเริ่มต้น ÷ ผลประโยชน์สุทธิต่อปี แต่อย่าตัดสิน compliance หรือความเสี่ยงคุณภาพร้ายแรงด้วยค่าแรงอย่างเดียว ควรเก็บเวลาคัดลอก reweigh network error และ investigation จริงเป็นเวลา 2–4 สัปดาห์ก่อนอนุมัติ business case
ความผิดพลาดที่พบบ่อยและวิธีป้องกัน
รับน้ำหนักอัตโนมัติ แต่ป้อนล็อตภายหลัง
การป้อนทีหลังยังเปิดช่องให้น้ำหนักที่ถูกต้องไปผูกกับงานผิด ต้องบังคับให้บริบทครบก่อนชั่ง หากระบุของจริงไม่ได้ ให้ส่ง event ไป hold queue พร้อม reason code แทนการเปิดให้ back-entry แบบเงียบ ๆ
ใช้ค่า stability เดียวกับเครื่องทุกตัว
แรงสั่น ความละเอียด พิกัด และการติดตั้งต่างกันทำให้ setting เดียวใช้ไม่ได้ ควร version configuration ตาม model, range และสถานที่ และทวนสอบใหม่หลังการเปลี่ยนแปลงที่มีผล
เครื่องเกินกำหนดมีเพียงคำเตือน
คำเตือนที่เกิดซ้ำจะกลายเป็นเสียงพื้นหลัง ต้องกำหนด stop, quality-approved limited use หรือ reference-only ตาม risk ล่วงหน้า เพื่อไม่ให้ผู้ปฏิบัติงานตัดสินสดภายใต้แรงกดดันการผลิต
ส่งน้ำหนักตรงเข้า ERP แล้วข้อมูลต้นทางหาย
ERP เหมาะกับผลรวม แต่อาจไม่เก็บ raw frame, stable, tare mode และ retry history ควรเก็บ weighing event ฉบับหลักใน MES/Quality DB แล้วส่งเฉพาะผลผลิตที่อนุมัติไป ERP
ถือว่า “รองรับ OPC UA” คือรับประกัน interoperability
Server อาจใช้ OPC UA แต่มีเฉพาะ proprietary nodes ต้องตรวจ companion specification, data type, method, security policy และ certificate operation กับอุปกรณ์จริง
คำถามที่พบบ่อยเกี่ยวกับการเชื่อมต่อข้อมูลเครื่องชั่ง
การเชื่อมต่อข้อมูลเครื่องชั่งคือการ export CSV ใช่หรือไม่?
ไม่ใช่เพียงเท่านั้น บันทึกที่ตรวจสอบได้ต้องรวม stable, gross/tare/net, unit, device state, time, lot, item, operator และ Scale ID รวมทั้งเก็บ replay, cancel และ reweigh
เครื่อง RS-232 รุ่นเก่าทำการบันทึกข้อมูลเครื่องมือวัดอัตโนมัติได้หรือไม่?
หลายกรณีทำได้ แต่ต้องตรวจ frame จริง stable/unit marker, request/response, isolation และ reconnect กับ firmware จริง หากออกเพียงตัวเลข ต้องระบุข้อจำกัดของการอนุมานในระบบชั้นบน
PLC หรือ MES ควรตัดสินผลการตรวจสอบ?
PLC/edge เหมาะกับการหยุดทันทีและ deterministic interlock ส่วน MES/QMS เหมาะกับ order, lot, spec version, authorization, release และ deviation การแบ่งจริงต้องอิง risk และเวลาตอบสนอง
บันทึกคุณภาพดิจิทัลเก็บ net อย่างเดียวพอหรือไม่?
โดยทั่วไปไม่พอสำหรับการสืบสวนที่ดี ควรเก็บ gross, tare, net และ tare mode เมื่อเครื่องให้ได้ หรืออย่างน้อยต้องสร้างวิธีคำนวณ net หน่วย และ rounding rule ย้อนกลับได้
OPC UA ทำให้เครื่องทุกยี่ห้อ plug-and-play หรือไม่?
ไม่ ควรเทียบเวอร์ชัน OPC 40200, type, facet, node, method และ extension ที่รองรับ แล้วทดสอบความหมายจริงใน FAT อย่างไรก็ตาม common model ช่วยลดการผูกกับ proprietary string ในอนาคต
เครื่องชั่งกระบวนการในไทยอยู่นอกมาตรวิทยาตามกฎหมายหรือไม่?
สรุปจากชื่อ process scale อย่างเดียวไม่ได้ การใช้เพื่อการค้า/หลักฐาน ชนิดเครื่อง ประกาศ และการดัดแปลงอาจมีผล ต้องตรวจข้อมูลปัจจุบันของกรมการค้าภายในและขอคำยืนยันสำหรับเครื่องและการเชื่อมต่อที่เฉพาะเจาะจง
ก่อนออก RFP ต้องเตรียมอะไรขั้นต่ำ?
ทะเบียนเครื่อง คู่มือสื่อสารและ sample frame แบบฟอร์มเดิม flow ของ order/lot network diagram, PLC I/O, สถานะสอบเทียบ/กฎหมาย รายการ exception และ expected FAT/SAT
สรุป: เชื่อม “เหตุการณ์ชั่งที่สร้างซ้ำได้” ไม่ใช่เชื่อมแค่ค่าน้ำหนัก
เริ่มการเชื่อมต่อข้อมูลเครื่องชั่งด้วยนิยาม stable, gross/tare/net, unit, สถานะเครื่อง เวลา ล็อต สินค้า ผู้ปฏิบัติงาน Scale ID และ event ID ที่ปลอดภัยต่อการส่งซ้ำ จากนั้นจึงเลือก RS-232, USB, Ethernet, fieldbus หรือ OPC UA วางการควบคุมทันทีที่ PLC/edge บริบทธุรกิจที่ MES และการอนุมัติคุณภาพที่ QMS แยกส่วนที่อาจเกี่ยวข้องทางกฎหมายออกจากแอปกระบวนการ แล้วทดสอบ boundary, fault, disconnect และ duplicate ก่อนให้บันทึกอิเล็กทรอนิกส์เป็นฉบับหลัก
TOMAS TECH ช่วยโรงงานไทยจัดทำทะเบียนเครื่องหลายรุ่น ตรวจการสื่อสารจริง เขียน RFP ที่เปรียบเทียบผู้ขายได้ แบ่งหน้าที่ PLC/MES/QMS และออกแบบ FAT/SAT ได้ แม้ยังไม่ทราบว่าเครื่องเก่าแต่ละรุ่นส่งข้อมูลอะไร ปรึกษาโครงการเชื่อมต่อเครื่องชั่งกับเรา
แหล่งข้อมูลอ้างอิง
- OPC Foundation, OPC UA for Weighing Technology (OPC 40200): https://reference.opcfoundation.org/specs/OPC-40200/1
- OPC Foundation, VDMA Weighing Initiative: https://opcfoundation.org/markets-collaboration/weighing/
- International Society of Automation, ISA-95 Standard: https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
- OIML R 51-1, Automatic catchweighing instruments: https://www.oiml.org/en/files/pdf_r/r051-1-e06.pdf
- OIML Certification System, instrument categories: https://www.oiml.org/en/oiml-cs/categories
- BIPM, SI Brochure: https://www.bipm.org/en/publications/si-brochure/
- กรมการค้าภายใน, พระราชบัญญัติมาตราชั่งตวงวัด พ.ศ. 2542: https://www.dit.go.th/th/law/act/weights-measures-2542/
- GS1 Global Traceability Standard: https://www.gs1.org/standards/gs1-global-traceability-standard/current-standard