CAN Bus ต่างจาก Modbus ยังไง? คู่มือสำหรับวิศวกรที่รู้ Modbus

ถ้าคุณใช้ Modbus เป็นอยู่แล้ว ทำไมต้องรู้ CAN?

ในงาน Factory Automation Modbus (RS-485 หรือ TCP) เป็นมาตรฐานที่เกือบทุกคนรู้จัก — ใช้อ่านค่า sensor, ควบคุม HMI, อ่าน-เขียน register ของ PLC ตัวอื่น

แต่เมื่อโจทย์เริ่มพาไปเจอกับงานแบบนี้:

• ต้องควบคุม servo/stepper หลายตัวพร้อมกัน และเวลาต้อง deterministic
• ต้องเชื่อมต่อกับ sensor real-time เช่น load cell, temperature ที่ update เร็วๆ
• ระบบยานยนต์, battery management, CNC ที่ใช้ CANopen
• ไม่อยากมี master คนเดียว เพราะ single point of failure

นี่คือจุดที่ CAN Bus เปล่งประกาย โปรโตคอลเดียวกับที่รถยนต์สมัยใหม่ใช้สื่อสารระหว่าง ECU กว่า 50 หน่วย ออกแบบมาเฉพาะเพื่องาน real-time deterministic multi-node control ที่ Modbus ทำไม่ได้ดี

บทความนี้จะเปรียบเทียบสองโปรโตคอลอย่างละเอียด เพื่อให้คุณเลือกใช้ได้ถูกงาน และเข้าใจว่าทำไมบางสถานการณ์ CAN ถึงเหนือกว่า Modbus อย่างชัดเจน

สรุปเปรียบเทียบแบบภาพรวม

สังเกตว่า CAN payload เล็กมาก (8 bytes) แต่เด่นที่ determinism และ multi-master — นี่คือเหตุผลที่ออกแบบมาสำหรับ real-time control

ความต่างที่ 1: Architecture — ใครเป็นใหญ่?

Modbus: Master คนเดียวคุมทุกคน

• Master เป็นผู้ถาม (query) ทุกครั้ง
• Slave ทุกตัวห้ามพูดก่อน ต้องรอให้ Master ถาม
• ถ้า Master ตาย → ระบบหยุดหมด (single point of failure)
• Slave 2 ต้องการส่งข้อมูลด่วน → รอไม่ได้ ต้องให้ Master poll ถึงตัวเอง

CAN: ทุก Node เท่ากัน ใครมีข้อมูลก็พูดได้

• ทุก node มีสิทธิ์เท่ากัน — ใครมีข้อมูลส่งก็ส่งเลย เมื่อ bus ว่าง
• ถ้า 2 node ชนกัน → hardware arbitration ตัดสินโดยดูที่ ID (ต่ำกว่าชนะ)
• Sensor เห็น overheat → สามารถ broadcast ทันที ไม่ต้องรอใครถาม
• ไม่มี single point of failure — Node ตายตัวใดตัวหนึ่ง ระบบที่เหลือทำงานต่อได้

ความต่างที่ 2: Communication Pattern

Modbus = Polling (Request/Response)

ในทุก cycle Master จะวนสำรวจ (poll) slave ทีละตัว:

ผลกระทบ:

• Latency ต่อ slave = (จำนวน slave × round-trip time) → ยิ่ง slave เยอะ ยิ่งช้า
• ถ้า Slave ต้องการ update บ่อย ต้องเพิ่ม baud rate (แต่มี limit ของ RS-485)
• Event-driven แทบทำไม่ได้ — Slave รอถูกถาม

CAN = Event-Driven Broadcast

ทุก node สามารถ broadcast ได้ทันทีเมื่อมีข้อมูลใหม่:

ผลกระทบ:

• Sensor เจอปัญหา → broadcast Emergency (ID ต่ำ priority สูง) ถึงทุกคนใน < 1ms
• ไม่เสียเวลา poll — Node พูดเฉพาะเมื่อมีของใหม่
• 1 message → ทุก node ได้รับพร้อมกัน (ไม่ต้องส่งซ้ำ)

ความต่างที่ 3: การ Addressing

Modbus: Slave ID + Register Address

ต้องการอ่านค่าอุณหภูมิจาก Slave ID 5, register 40001:
┌────────────────────────────────────────────────┐
│ Slave ID │ FC   │ Reg Addr │ Count │ CRC16   │
│   0x05   │ 0x03 │ 0x0000   │ 0x01  │ xxxx    │
└────────────────────────────────────────────────┘
  ↑ "ใคร"   ↑"อะไร"  ↑ "ที่ไหน" ↑"เท่าไหร่" 

หลักการ: Master ต้องรู้ทั้ง "ใคร" (Slave ID), "ที่ไหน" (Register Address), "อะไร" (Function Code) ทุกครั้งที่ต้องการข้อมูล

CAN: Message ID = Meaning + Priority

Servo 1 ส่ง position report:
┌───────────────────────────────────────┐
│  ID: 0x181   │  DLC: 8  │ Data[8]     │
│  (TPDO1 ของ │           │ position... │
│  Servo#1)    │           │             │
└───────────────────────────────────────┘
  ↑ "เรื่องอะไร" + "ด่วนแค่ไหน"

หลักการ: ID ไม่ใช่ address ของใคร — แต่เป็น "ป้ายกำกับข้อมูลนี้คืออะไร" + "priority สูงแค่ไหน"

• ใครก็ตามที่สนใจข้อมูลนี้ — subscribe (filter) รับได้เลย
• ID ต่ำ = ด่วน (เช่น 0x000 = NMT, 0x080 = Emergency)
• ID สูง = ไม่เร่ง (เช่น 0x600+ = SDO configuration)

เปรียบเทียบง่ายๆ:

ความต่างที่ 4: Arbitration (จุดสำคัญที่สุด)

นี่คือหัวใจของ CAN — ทำไมถึงเป็น deterministic ได้

ปัญหา: ถ้า 2 node อยากส่งพร้อมกัน ทำยังไง?

Modbus: ไม่เกิด เพราะมี Master คนเดียว Slave ส่งเมื่อถูกถาม

CAN: เกิดได้ตลอด! แต่มีกลไก "non-destructive bitwise arbitration" แก้ได้โดยไม่ต้องย้อนส่งใหม่

กลไก: Dominant-0 / Recessive-1

บน CAN bus:

• Bit 0 = Dominant (แรงกว่า ถ้าใครส่ง 0 ทุกคนเห็น 0)
• Bit 1 = Recessive (อ่อนกว่า — เกิดเฉพาะเมื่อทุกคนส่ง 1 เท่านั้น)

ทุก node จะอ่าน bus ขณะกำลังส่ง — ถ้าส่ง 1 แต่เห็น 0 บน bus แสดงว่า "คนอื่น dominant อยู่" ต้องยอมถอย

เกิดอะไรขึ้น:

1. Bit 10 (MSB): Node A ส่ง 0, Node B ส่ง 1 → bus เป็น 0
2. Node B อ่าน bus เห็น 0 แต่ตัวเองส่ง 1 → รู้ว่าแพ้ arbitration ถอยทันที
3. Node A ไม่รู้ว่ามีใครแข่ง — ส่งต่อไปจนจบเหมือนปกติ
4. Node B รอ bus ว่าง แล้วค่อยส่งใหม่

ผลลัพธ์: ไม่เสียเวลา retransmit, ไม่มี collision, frame priority สูง (ID ต่ำ) จะได้ส่งก่อนเสมอ อย่าง deterministic

Modbus เมื่อเกิด collision (RS-485):

Modbus ไม่มี arbitration — ถ้ามี 2 master ส่งพร้อมกัน → สัญญาณชน → CRC พัง → ต้องทำ retry ใน application layer (ช้าและไม่ deterministic)

ความต่างที่ 5: Frame Format

Modbus RTU Frame

┌─────────┬─────┬──────────────────┬──────┐
│ Addr    │ FC  │ Data (0-252 B)   │ CRC  │
│ 1 byte  │ 1 B │ variable         │ 2 B  │
└─────────┴─────┴──────────────────┴──────┘

Total: 4-256 bytes @ 115.2 kbps = ~0.3-22 ms per frame

CAN Classic Frame (Standard 11-bit)

┌────┬────────┬─────┬─────┬───┬─────┬──────────┬─────┬─────┬───────┐
│SOF │ ID 11b │ RTR │ IDE │ R │ DLC │ Data 0-8 │ CRC │ ACK │ EOF   │
│ 1b │ 11 bit │ 1b  │ 1b  │1b │ 4b  │ 0-64 bit │ 15b │ 2b  │ 7b    │
└────┴────────┴─────┴─────┴───┴─────┴──────────┴─────┴─────┴───────┘

Total: 44-108 bits @ 500 kbps = ~0.1-0.2 ms per frame

ข้อสังเกต:

• CAN frame สั้นกว่า Modbus frame มาก → ส่งเร็วกว่า
• CAN payload limit 8 bytes → ถ้าจะส่งข้อมูลเยอะ ต้องใช้หลาย frame (แต่ละ frame มี priority แยกกัน)
• CAN มี Hardware ACK bit — receiver ต้อง ACK ทุก frame ที่ถูกต้อง (ถ้าไม่มี ACK = error)

ความต่างที่ 6: Error Handling

CAN มีระบบ error counter ในตัว — ถ้า node ใดส่ง frame ผิดพลาดบ่อยๆ จะถูก disconnect จาก bus โดย hardware (เพื่อปกป้อง network) — feature นี้ Modbus ไม่มี

เมื่อไหร่ควรใช้อะไร?

เลือก Modbus เมื่อ:

• ต้องการอ่าน/เขียน register จำนวนมาก ต่อครั้ง (เช่น อ่าน D0-D100 ในคำขอเดียว)
• การสื่อสารเป็น request-response แบบคลาสสิก (HMI อ่าน PLC, SCADA ถาม sensor)
• Latency 10-100ms ยอมรับได้
• อุปกรณ์ส่วนใหญ่ในระบบรู้จัก Modbus อยู่แล้ว
• ต้องการใช้ RS-485 ระยะไกล (>500m) — Modbus RTU ทำได้ดี

เลือก CAN เมื่อ:

• Motion control — control loop ต้องเร็ว deterministic (servo, stepper)
• Multi-node event-driven — sensor หลายตัว broadcast พร้อมกัน
• Safety-critical — ต้องการ hardware-level error detection
• ใช้ CANopen device ที่ vendor จัดหามาให้ (servo drive, remote I/O)
• ต้องการ fail-operational — node ตายตัวหนึ่ง ระบบยังรันต่อได้

ใช้ทั้งสอง (Hybrid) เมื่อ:

• PLC ควบคุม servo ผ่าน CAN (real-time), HMI อ่านผ่าน Modbus (configuration)
• Backbone เป็น Modbus TCP (SCADA), field-level เป็น CAN (sensor/actuator)

ตัวอย่างสถานการณ์จริง

สถานการณ์ 1: Pick-and-Place Robot (4 axis servo)

ถ้าใช้ Modbus RTU:

• Master poll ตำแหน่ง servo 4 ตัว ทีละตัว = 4 round-trips
• ที่ 115.2 kbps, round-trip ~10ms × 4 = 40ms cycle
• ส่งคำสั่ง move ไป 4 ตัว = อีก 40ms
• Cycle time ~80ms = update rate 12.5 Hz ช้าเกินไปสำหรับ smooth motion

ถ้าใช้ CAN (CANopen):

• Servo ทั้ง 4 broadcast position (TPDO) ทุกๆ 10ms = 100Hz
• PLC ส่งคำสั่ง move broadcast (RPDO) ใน 1 frame
• Cycle time ~1-2ms = update rate 500-1000 Hz เหมาะกับ coordinated motion

ผู้ชนะ: CAN ชัดเจน

สถานการณ์ 2: โรงงานที่มี Temperature Sensor 50 ตัว อ่านทุก 10 วินาที

Modbus: poll sensor ทีละตัว, 50 ตัว × 20ms = 1 วินาที ต่อ cycle — เพียงพอ CAN: sensor broadcast ทุกตัว — overkill และ CANopen device แพงกว่า

ผู้ชนะ: Modbus RTU — ง่าย ถูก เพียงพอ

สถานการณ์ 3: Emergency Stop ทั่วทั้งระบบ

Modbus: ต้องรอ Master poll ถึงตัวแล้วค่อยสั่ง — latency 50-200ms CAN: Emergency frame (ID 0x080) priority สูงสุด, ทุก node รับพร้อมกัน < 1ms

ผู้ชนะ: CAN — safety-critical application

สรุป: Mental Model ที่ต้องจำ

Samkoon PLC รุ่นที่รองรับ CAN จะเปิดโลกใหม่ให้วิศวกร automation — สามารถทำงานที่ Modbus ทำไม่ไหว เช่น multi-axis motion, real-time sensor fusion, event-driven control โดยไม่ต้องเปลี่ยน controller แค่ใช้คำสั่ง SEND_CAN / REV_CAN หรือ CANopen ที่มีในตัว

เริ่มต้นใช้งาน: อ่านคู่มือ สอนใช้ CAN Bus และ CANopen กับ Samkoon PLC เพื่อเริ่มเขียนโปรแกรมแรกของคุณ