แผนปัจจุบัน
M-01 ทำงาน
- พลังงานใน 30 นาที
- 31.1 kWh
- กำลังไฟฟ้าสูงสุด
- 64.7 kW
Hardware / Industrial 4G LTE Router
Industrial 4G LTE Router
Gateway สำหรับตู้ควบคุม PLC และมิเตอร์ เชื่อมข้อมูลหน้างานผ่าน Ethernet และ RS485 พร้อม 4G LTE และ Node-RED
Industrial 4G LTE Router
รายละเอียดและขอบเขตการใช้งาน
รายละเอียดอ้างอิงจากภาพสินค้าที่ผู้จำหน่ายระบุ ยืนยันรุ่น สเปก อุปกรณ์ในชุด และการเชื่อมต่อ AIoT TH Cloud ก่อนเสนอราคา
- พอร์ตสื่อสาร
- 1 WAN + 1 LAN · 2 RS485
- สัญญาณ I/O
- 1 DI + 1 DO
- ไฟเลี้ยง
- 9–36 V DC
- ซอฟต์แวร์
- Node-RED · Linux / OpenWrt · Python
- รูปแบบข้อมูล
- RS485 / Ethernet → Gateway → Cloud
- ก่อนสั่งซื้อ
- ยืนยันรุ่น firmware อุปกรณ์ในชุด และการเชื่อมต่อปลายทาง
- อุณหภูมิอ้างอิง
- −40°C ถึง 85°C ตามภาพผู้จำหน่าย
- ตัวเครื่องอ้างอิง
- โลหะ · IP30
ภาพอ้างอิงพอร์ตและคุณสมบัติ
ภาพและรายละเอียดเพิ่มเติม
อุปกรณ์ที่เหมาะกับการเชื่อมต่อ
เหมาะกับโรงงาน ตู้ไฟ และจุดวัดที่เดินสายสัญญาณ
- PLC และมิเตอร์ที่มีช่องทางสื่อสารที่รองรับ
- ตู้ควบคุมและจุดรวมสัญญาณ RS485 / Ethernet
- ตรวจโปรโตคอลและรายการค่าที่อุปกรณ์เปิดให้อ่าน
เตรียมก่อนติดตั้ง
ให้ผู้รับผิดชอบไซต์ยืนยันไฟเลี้ยง ตำแหน่งติดตั้ง และเครือข่ายก่อนเลือกอุปกรณ์เสริม
- ตรวจแหล่งจ่ายไฟตามรุ่นและพื้นที่ว่างในตู้
- สำรวจจุดติดเสาอากาศและเครือข่าย 4G หรือ LAN
- จัดทำ point list และทดสอบเทียบค่ากับอุปกรณ์ต้นทาง
ขอบเขตซอฟต์แวร์และชุดส่งมอบ
พอร์ต DO เป็นคุณสมบัติฮาร์ดแวร์ ระบบ AIoT TH ระยะแรกใช้สำหรับอ่านข้อมูล การควบคุมและซอฟต์แวร์เสริมต้องกำหนดขอบเขตเพิ่มเติม
- รุ่นย่อย firmware และซอฟต์แวร์ที่ติดตั้งมา
- เสาอากาศ สาย แหล่งจ่ายไฟ และอุปกรณ์ยึดตามใบเสนอราคา
- งานตั้งค่า Cloud การทดสอบ และเอกสารส่งมอบที่ตกลงร่วมกัน
การใช้งานในโรงงาน
เริ่มจากปัญหาหน้างาน ไปสู่ระบบที่ใช้ได้จริง
ตัวอย่างแนวทางออกแบบระบบ พร้อมอุปกรณ์ ข้อมูล ผู้รับผิดชอบ และเงื่อนไขก่อนเริ่มโครงการ ไม่ใช่ผลลัพธ์จากลูกค้าจริง
DIGITAL TWIN · ข้อมูลจำลอง
digital twin จำลอง: พื้นที่ อุปกรณ์ และเหตุการณ์ในจอเดียว
digital twin จำลองคือแบบจำลองที่รันในเบราว์เซอร์ ไม่ได้สะท้อน PLC หรือไซต์ลูกค้า และไม่ควบคุมอุปกรณ์จริง
กำลังเปิดผัง 3D…
สด (จำลอง) · 08:00:00
ผัง 3D จำลอง ไม่ใช่พิกัดจริง · ป้ายบนฉากแสดงค่าจาก digital twin จำลอง · เลือกอุปกรณ์บนฉากหรือจากโครงสร้าง twin
กำลังไฟฟ้ารวม62.0 kW
อุณหภูมิ M-0246.0 °C
การสั่นสะเทือน M-022.10 mm/s
WHAT-IF · จำลอง
เทียบแผนปัจจุบันกับทางเลือก · 30 นาทีจำลองข้างหน้า
ทางเลือก
M-01 หยุด
- พลังงานใน 30 นาที
- 17.4 kWh
- กำลังไฟฟ้าสูงสุด
- 36.2 kW
คำนวณจากแบบจำลองในเบราว์เซอร์ เพื่อเทียบผลของการเลือก ไม่ใช่การพยากรณ์ของไซต์จริง
ประวัติการตรวจสอบและคำสั่ง
เลือกอุปกรณ์บนฉาก แล้วกดตรวจสอบหรือควบคุม
เส้นทางข้อมูล
PLC / Meter → Modbus TCP / RS485 → Gateway → MQTT TLS :8883 → Monitor
CCTV ใช้เครือข่าย IP ผ่าน PoE / NVR แยกจาก LoRaWAN; ภาพในฉากเป็นภาพประกอบ ไม่มีวิดีโอสด
สิ่งที่เจ้าหน้าที่เห็น
เชื่อมค่าพลังงานและสถานะเครื่องกับตำแหน่งหน้างาน เพื่อให้ช่างตรวจอุปกรณ์ที่เกี่ยวข้อง
ตัวอย่างการออกแบบระบบรู้ว่าโรงงานใช้พลังงานตรงไหน และช่วงใด
ตัวอย่างระบบ: ตู้เมน + ไลน์ผลิต + ระบบลมอัด
จากค่าไฟรวมปลายเดือน สู่ข้อมูลมิเตอร์รายพื้นที่ที่ทีมวิศวกรรมใช้ตรวจโหลดและวางแผนปรับปรุงได้
สมมติโรงงานต้องการติดตามมิเตอร์ 3 จุด เริ่มจากดูค่าและประวัติของแต่ละจุดก่อน งานคำนวณต้นทุนหรือพลังงานต่อชิ้นต้องมีข้อมูลและสูตรที่ตกลงเพิ่ม ไม่ถือว่ารวมอัตโนมัติ
ปัญหาที่พบ และแนวทางแก้ไข
เห็นค่าไฟรวม แต่ระบุจุดใช้ไฟสูงไม่ได้
ทีมต้องไล่หาสาเหตุจากหลายตู้ และอาจเลือกแก้จุดที่ไม่ใช่ต้นเหตุ
แนวทางแก้ไข · กำหนดมิเตอร์หลักและมิเตอร์ย่อยตามวงจร เก็บค่าเป็นรายจุด แล้วเทียบช่วงเวลาที่มีเงื่อนไขการผลิตใกล้กัน
จดมิเตอร์ด้วยมือคนละเวลาและคนละไฟล์
เทียบข้อมูลยาก และไม่รู้ว่าค่าที่ต่างกันเกิดจากช่วงเวลาหรือโหลดจริง
แนวทางแก้ไข · อ่านค่าจากมิเตอร์ที่รองรับผ่าน Gateway กำหนดชื่อ หน่วย และเวลาให้เป็นมาตรฐาน พร้อมตรวจค่ากับหน้าจอมิเตอร์
รู้ว่าโหลดผิดปกติเมื่อจบกะไปแล้ว
ทีมไม่มีข้อมูลช่วงเกิดเหตุเพื่อใช้ตัดสินใจว่าจะตรวจอุปกรณ์ใดก่อน
แนวทางแก้ไข · กำหนดเกณฑ์จากรูปแบบใช้งานของไซต์ ส่งการแจ้งเตือนตามขอบเขตที่เปิดใช้ และให้ผู้รับผิดชอบตรวจสอบหน้างาน
อุปกรณ์และส่วนประกอบ
- มิเตอร์ที่รองรับ 3 จุด: เมน ไลน์ผลิต และคอมเพรสเซอร์
- Industrial Gateway ที่มีพอร์ตตรงกับมิเตอร์ พร้อมไฟเลี้ยงและเครือข่าย
- Cloud จัดจุดวัดตาม Site / Area / Asset
- Dashboard ประวัติและการแจ้งเตือนตาม Package
ข้อมูลที่ใช้ติดตาม
- กำลังไฟฟ้า kW และพลังงานสะสม kWh
- แรงดัน กระแส และ Power factor หากมิเตอร์เปิดให้อ่าน
- เวลาอัปเดตล่าสุดและสถานะการเชื่อมต่อ
เส้นทางข้อมูล
- มิเตอร์ไฟฟ้า
- RS485 / Ethernet
- Industrial Gateway
- AIoT TH Cloud
- Dashboard / แจ้งเตือน
กระบวนการทำงานและผู้รับผิดชอบ
กำหนดขอบเขตวงจร
วิศวกรไฟฟ้า
เลือกจุดที่ต้องเทียบ ระบุว่ามิเตอร์ใดเป็นเมนหรือย่อย เพื่อไม่รวมพลังงานซ้ำ
ตั้งค่าการอ่าน
ผู้ดูแลอุปกรณ์
ตรวจ register หน่วย CT ratio และรอบอ่านตามรุ่นมิเตอร์และการใช้งาน
ตรวจค่าต้นทาง
ผู้ติดตั้ง + ทีมโรงงาน
เทียบค่าบน Dashboard กับมิเตอร์ในช่วงเวลาเดียวกัน และบันทึกข้อคลาดเคลื่อน
ติดตามรูปแบบโหลด
วิศวกรพลังงาน
ดูค่าปัจจุบันและประวัติร่วมกับตารางเดินเครื่อง ไม่สรุปประสิทธิภาพจากยอดรวมอย่างเดียว
ตรวจเหตุแจ้งเตือน
ซ่อมบำรุง
เมื่อได้รับแจ้ง ให้ตรวจอุปกรณ์และเงื่อนไขการผลิตก่อนตัดสินใจปรับการใช้งาน
ทบทวนผลปรับปรุง
หัวหน้าฝ่ายผลิต
เปรียบเทียบช่วงที่มีบริบทใกล้กัน บันทึกสิ่งที่เปลี่ยนและข้อมูลที่ยังขาด
ช่วยโรงงานแต่ละฝ่ายอย่างไร
วิศวกรรมพลังงาน
ช่วยชี้ช่วงเวลาและพื้นที่ที่ควรสำรวจโหลดเพิ่มเติม
ซ่อมบำรุง
มีค่าและเวลาอ้างอิงสำหรับตรวจอุปกรณ์ที่ถูกแจ้งเตือน
ฝ่ายผลิต
ใช้ข้อมูลประกอบการทบทวนการเปิดเครื่องและการเปลี่ยนกะ
ผู้บริหาร / วางแผนต้นทุน
มีข้อมูลวัดจริงประกอบข้อเสนอปรับปรุง โดยยืนยันสูตรต้นทุนแยกต่างหาก
เหมาะกับใครบ้าง
- โรงงานที่มีหลายวงจรหรือหลายอาคารและต้องการแยกข้อมูลพลังงาน
- ทีมวิศวกรรมที่มีมิเตอร์อ่านข้อมูลได้ และมีผู้รับผิดชอบตรวจค่าหน้างาน
- โครงการที่เริ่มจากจุดสำคัญก่อนขยาย ไม่จำเป็นต้องติดตั้งทั้งโรงงานพร้อมกัน
ตรวจรับอย่างไรว่าใช้งานได้
- ค่าบน Dashboard ตรงกับหน่วยและสเกลของมิเตอร์
- ตรวจพบข้อมูลค้างหรือขาด และอธิบายเวลาอ้างอิงได้
- ผู้รับผิดชอบค้นประวัติเหตุการณ์และทดสอบรับแจ้งได้ตามขอบเขต
ตัวอย่างการออกแบบระบบเห็นสถานะเครื่องจักร และมีข้อมูลย้อนดูตอนเกิดเหตุ
ตัวอย่างระบบ: ไลน์บรรจุที่มีเครื่องจักรหลายสถานี
เชื่อมสัญญาณจาก PLC หรือเซ็นเซอร์ เพื่อให้ฝ่ายผลิตและซ่อมบำรุงเห็นข้อมูลชุดเดียวกัน ก่อนนำไปพัฒนาการวิเคราะห์ประสิทธิภาพ
ตัวอย่างสมมติใช้สถานีป้อน บรรจุ และแพ็ก ทีมเริ่มจากอ่าน Run / Fault และตัวนับที่ PLC เปิดให้เข้าถึง ไม่แก้ระบบควบคุมเดิมโดยอัตโนมัติ และไม่ใช้สถานะ Offline แทนเหตุเครื่องหยุด
ปัญหาที่พบ และแนวทางแก้ไข
ต้องเดินดูเครื่องเพื่อรู้ว่าเครื่องใดทำงานอยู่
หัวหน้ากะไม่เห็นภาพเดียวกันเมื่อดูแลหลายจุด
แนวทางแก้ไข · กำหนดสถานะที่ PLC เปิดให้อ่าน แล้วแสดงค่าตามเครื่องจักรพร้อมเวลาอัปเดต
ข้อมูลหยุดเครื่องมาจากการจำหรือบันทึกย้อนหลัง
ทีมเริ่มตรวจปัญหาโดยไม่มีเวลาและสัญญาณต้นทางประกอบ
แนวทางแก้ไข · เก็บประวัติสถานะและค่าที่เกี่ยวข้อง ใช้ช่วยหาเวลาตรวจสอบ แล้วให้คนยืนยันสาเหตุจริง
ต้องการ OEE แต่มีเพียงสัญญาณ Run
คำนวณตัวเลขได้แต่ความหมายอาจไม่ตรงการผลิตจริง
แนวทางแก้ไข · แยกโครงการอ่านข้อมูลออกจากงานวิเคราะห์ กำหนดกะ จำนวนผลิต ชิ้นดี และ ideal cycle time ก่อนตกลงสูตร OEE
อุปกรณ์และส่วนประกอบ
- PLC หรือเซ็นเซอร์ที่ให้สถานะตามที่ตกลง
- Gateway พร้อม Ethernet / RS485 หรือ Digital input ที่ตรงกับสัญญาณ
- Cloud จัด Asset แยกตามสถานี
- Dashboard ดูค่าและประวัติร่วมกับทีมผลิตและซ่อมบำรุง
ข้อมูลที่ใช้ติดตาม
- Run / Stop / Fault ตามนิยามที่ยืนยันกับผู้ดูแลเครื่อง
- ตัวนับผลิต อุณหภูมิ หรือกระแสเฉพาะที่มีแหล่งข้อมูล
- สถานะ Gateway และเวลาอัปเดต แยกจากสถานะเครื่อง
เส้นทางข้อมูล
- PLC / Sensor
- ค่าหรือสถานะที่อ่านได้
- Gateway
- Cloud แยกตาม Asset
- หน้าจอฝ่ายผลิต
กระบวนการทำงานและผู้รับผิดชอบ
นิยามสถานะ
ผลิต + ผู้ดูแล PLC
ตกลงว่า Run, Stop และ Fault หมายถึงอะไร รวมถึงช่วงเปลี่ยนสินค้าและหยุดตามแผน
จัดทำรายการสัญญาณ
วิศวกร Automation
ระบุ address ชนิดข้อมูล หน่วย และวิธีอ่านที่ไม่กระทบงานควบคุม
ตรวจเหตุการณ์จริง
ผู้ติดตั้ง + Operator
เทียบสถานะบนหน้าจอกับการทำงานของเครื่องในช่วงทดสอบที่ตกลง
ติดตามระหว่างกะ
หัวหน้ากะ
ดูสถานะและความสดของข้อมูล ใช้ประวัติช่วยเลือกช่วงที่ต้องตรวจสอบ
หาสาเหตุหน้างาน
ซ่อมบำรุง
ตรวจเครื่องและบันทึกสาเหตุในกระบวนการของโรงงาน ไม่สรุปจากสัญญาณเดียว
ทบทวนข้อมูลสำหรับวิเคราะห์
วิศวกรรมการผลิต
ยืนยันข้อมูลผลิต กะ และสูตรก่อนพัฒนารายงาน downtime หรือ OEE เพิ่มเติม
ช่วยโรงงานแต่ละฝ่ายอย่างไร
หัวหน้ากะ / ฝ่ายผลิต
เห็นค่าตามสถานีและมีเวลาอ้างอิงเมื่อประสานงาน
ซ่อมบำรุง
ใช้สัญญาณย้อนหลังประกอบการตรวจสาเหตุ แทนการเริ่มจากความทรงจำอย่างเดียว
วิศวกร Automation
มี point list และนิยามสัญญาณร่วมกันสำหรับดูแลและขยายระบบ
ผู้จัดการโรงงาน
เข้าใจว่าข้อมูลใดมีจริง และข้อมูลใดยังขาดก่อนลงทุนวิเคราะห์ประสิทธิภาพ
เหมาะกับใครบ้าง
- โรงงานที่มี PLC หรือสัญญาณสถานะที่สามารถเปิดให้อ่านได้
- ทีมผลิตและซ่อมบำรุงที่พร้อมตกลงนิยามสถานะร่วมกัน
- ผู้ที่ต้องการเริ่มเก็บข้อมูลพื้นฐานก่อนทำ downtime หรือ OEE ตามขอบเขตเพิ่มเติม
ตรวจรับอย่างไรว่าใช้งานได้
- สถานะบน Dashboard ตรงกับเครื่องในกรณีทดสอบ
- แยกเครื่องหยุดออกจาก Gateway ขาดการเชื่อมต่อได้
- มีรายการสัญญาณและนิยามที่ผู้ดูแลเครื่องยอมรับ
รายละเอียดและแนวทางเลือก
ก่อนเชื่อม Router เข้ากับอุปกรณ์โรงงาน
การสื่อสาร RS485 ต้องมีค่าตรงกันทั้งระบบ
RS485 ระบุชั้นสัญญาณ ไม่ได้ยืนยันว่าอุปกรณ์ทุกตัวใช้โปรโตคอลเดียวกัน หากอ่าน Modbus RTU ต้องตรวจ baud rate, parity, stop bits และ slave ID ร่วมกับ register map ที่ตรงรุ่น จำนวนพอร์ตไม่ได้บอกจำนวนอุปกรณ์ที่ใช้งานได้จริงโดยไม่มีการประเมิน
- ตรวจชนิดข้อมูลและการเรียง byte
- กำหนดรอบอ่านและ timeout ที่เหมาะสม
- ให้ผู้รับผิดชอบหน้างานตรวจสายและการเข้าหัว
Node-RED และ Python ต้องมีขอบเขตการดูแล
ภาพอ้างอิงระบุการพัฒนาต่อยอดด้วย Node-RED และ Python แต่ต้องยืนยัน firmware ทรัพยากรและแพ็กเกจของรุ่นที่ส่งมอบ รวมถึงผู้ดูแล flow หรือโค้ด การเพิ่ม logic บน Gateway ไม่ใช่เหตุผลให้เปิดการสั่งงาน PLC โดยไม่มีการออกแบบเพิ่มเติม
- ยืนยัน firmware และซอฟต์แวร์ที่รวมมา
- บันทึกการตั้งค่าและวิธีกู้คืน
- แยกการเก็บข้อมูลออกจากงานควบคุม
ระบบที่เกี่ยวข้องกับหน้านี้
อ่านขอบเขตระบบก่อนเปิดใช้งาน หรือนำตัวอย่างไปวางแผนโครงการของคุณ
ข้อมูลจำลอง · ไม่มีการสั่ง PLC จริง
Factory Operations
ทดลองตรวจสถานะเครื่องจักร พลังงาน ค่าจำลองและ Alarm พร้อมฉาก 3D และประวัติเหตุการณ์ของพื้นที่ทดลอง
ข้อมูลสาธารณะจริง · อ่านอย่างเดียว
Flood Monitoring
ติดตามสถานีฝน ระดับน้ำ และน้ำบนถนนบนแผนที่จริง พร้อมเวลาอัปเดตและแหล่งข้อมูล
คำถามเกี่ยวกับหน้านี้
รองรับ VPN ตามภาพสินค้าทุกแบบหรือไม่
ภาพเป็นข้อมูลอ้างอิงของผู้จำหน่าย ต้องยืนยันรุ่นและ firmware ที่ส่งมอบ รวมถึงข้อกำหนดเครือข่ายก่อนระบุความสามารถ VPN ในโครงการ
ใช้พอร์ต DO สั่งอุปกรณ์ผ่าน AIoT TH ได้เลยหรือไม่
ไม่ได้โดยอัตโนมัติ พอร์ต DO เป็นคุณสมบัติฮาร์ดแวร์ ส่วนแพลตฟอร์มระยะแรกเน้นอ่านข้อมูล งานควบคุมต้องออกแบบและตกลงแยก
เลือก Hardware และ Software ให้ทำงานร่วมกัน
เริ่มจากอุปกรณ์และจุดวัดของคุณ แล้วกำหนดขอบเขตที่เหมาะกับไซต์