CRC-16 Calculator: คำนวณ checksum Modbus, CCITT และ DNP3 ออนไลน์ฟรี

ใครที่เคยนั่งดึง hex dump ของเฟรม Modbus RTU แล้วงงว่าทำไมอุปกรณ์ถึงไม่ตอบรับคำสั่ง สาเหตุส่วนใหญ่มักเจอกันที่ CRC ผิด CRC-16 เป็น checksum ที่คุ้มครองข้อความหลายพันล้านข้อความต่อวัน ไม่ว่าจะเป็นบนพื้นที่โรงงาน ในระบบไฟฟ้า ในบัสยานพาหนะ หรือในไฟล์ firmware แต่ละ protocol ที่ใช้ CRC-16 จะมีสเปกต่างกัน ทั้ง polynomial, initial value และกฎการเรียงบิต พอระบุผิดแม้แต่จุดเดียว เฟรมก็จะถูกทิ้งเงียบ ๆ ทันที

CRC-16 Calculator ฟรีบนเว็บช่วยจัดการเรื่องนี้ให้หมด วางข้อมูลเป็นข้อความหรือ hex bytes เลือกตัวแปรที่ protocol ใช้ แล้วได้ checksum ทันที พร้อมตารางพารามิเตอร์ครบทั้ง polynomial, initial value, refin, refout, xorout และผลลัพธ์ในรูปแบบ hex, decimal และ binary ทุกอย่างประมวลผลฝั่ง client ในเบราว์เซอร์ ข้อมูลไม่ออกจากเครื่องคุณแน่นอน

บทความนี้จะอธิบายว่าเครื่องมือทำอะไรได้บ้าง พารามิเตอร์แต่ละตัวของ CRC-16 ทำงานอย่างไร และ checksum เหล่านี้ถูกใช้จริงตรงไหน ไม่ว่าคุณจะกำลังต่อ sensor network บน RS-485 ตรวจ payload ของ firmware หรือ debug ลิงก์ SCADA จะมี workflow ที่ช่วยประหยัดเวลาให้ในบทความนี้

ทำไมต้องใช้ CRC-16 Calculator?

• ครบ 10 ตัวแปรในเครื่องเดียว Modbus, CCITT-FALSE, XMODEM, Kermit, X-25, IBM (ARC), USB, MAXIM, GENIBUS และ DNP3 อยู่ในเครื่องมือเดียว ไม่ต้องไปตามหา implementation ใหม่ทุกครั้งที่ datasheet ระบุตัวแปรที่ต่างออกไป
• ค่า check ถูกต้องตาม CRC catalog ผลลัพธ์ตรงกับ CRC-16/arc catalog เช่น CRC-16/ARC ของข้อความ "123456789" ได้ 0xBB3D จึงวางใจนำผลลัพธ์ไปใช้งานจริงได้
• รองรับ input ทั้งข้อความและ hex bytes พิมพ์ข้อความธรรมดาเพื่อทดลองเร็ว ๆ หรือวาง hex bytes ตรง ๆ อย่าง 01 03 00 6B 00 01 เมื่อต้องการเฟรมแบบ byte-accurate
• โปร่งใสทุกพารามิเตอร์ เครื่องมือแสดง polynomial, initial value, input/output reflection และ XOR-out ของแต่ละตัวแปร ใช้เทียบกับ datasheet หรือเช็คตอนเขียน implementation เองได้ทันที
• อัปโหลดไฟล์ได้ถึง 10MB วางไฟล์ binary ลงไปแล้วคำนวณ checksum จาก raw bytes พร้อมแปลงเป็น hex ให้อัตโนมัติเพื่อตรวจสอบ
• รันในเบราว์เซอร์ 100% ไม่ต้องสมัคร ไม่มีการอัปโหลด ไม่มี telemetry เฟรมและไฟล์ของคุณอยู่บนเครื่องคุณเท่านั้น

ฟีเจอร์หลัก

บางรายละเอียดน่าดูใกล้ ๆ:

• ค่า check ที่ถูกต้องสำคัญมาก เว็บคำนวณ CRC บางเว็บให้ผลลัพธ์ที่ดูน่าเชื่อแต่ผิดสำหรับตัวแปรที่หาได้ยาก เครื่องมือนี้ตรวจกับ reference catalog แล้ว checksum ที่คัดลอกไปคือค่าที่อุปกรณ์คาดหวัง
• hex, decimal และ binary แสดงพร้อมกัน งาน firmware มักต้องดูรูป binary เพื่อเห็นบิตที่ reflect แล้ว ส่วนเอกสารมักเขียนเป็น hex ที่ได้ทั้งสามแบบพร้อมปุ่มคัดลอก ช่วยตัดความผิดพลาดตอนสะกดค่าไปใช้
• hex input แม่นยำระดับ byte รองรับทั้งช่องว่าง คอมมา และ prefix 0x จึงวางเฟรมจาก logic analyzer capture ได้ตรง ๆ

วิธีใช้งาน

1. เปิดเครื่องมือ ที่ CRC-16 Calculator โหลดไวและใช้ได้แม้ออฟไลน์เมื่อแคชแล้ว
2. เลือกโหมด input เลือก Text เพื่อคำนวณจากข้อความ, Hex เพื่อวาง raw bytes เช่น 01 03 00 6B 00 01 หรืออัปโหลดไฟล์ขนาดไม่เกิน 10MB
3. เลือกตัวแปร CRC-16 ที่ protocol ระบุไว้ ถ้ายังไม่แน่ใจว่าเป็นตัวไหน ให้ดูตารางพารามิเตอร์ด้านล่างที่จะอัปเดต polynomial และ init value ตามที่เลือก แล้วเทียบกับ datasheet
4. กดปุ่มคำนวณ checksum ขนาด 16 บิตจะปรากฏทันทีในรูปแบบ hex, decimal และ binary พร้อมตารางพารามิเตอร์เต็ม
5. คัดลอกผลลัพธ์ ด้วยคลิกเดียวแล้วนำไปต่อท้ายเฟรมตามลำดับ byte ที่ถูกต้อง สำหรับ Modbus และตัวแปรที่ reflect จำไว้ว่า low byte จะถูกส่งก่อนบนสาย

แค่นี้เอง เมื่อรู้ตัวแปรที่ใช้แล้ว ทั้ง workflow ใช้เวลาไม่ถึงสิบวินาที

ทำความเข้าใจพารามิเตอร์ของ CRC-16

สอง implementation อ้างว่าเป็น "CRC-16" เหมือนกันก็ยังให้ผลลัพธ์ต่างกันได้ทุก input ต้นเหตุอยู่ที่พารามิเตอร์ห้าตัวนี้:

• Polynomial (poly) คือตัวหารที่กำหนดคณิตศาสตร์ทั้งหมด polynomial 16 บิตที่พบบ่อยคือ 0x8005 (Modbus, ARC, USB, MAXIM) และ 0x1021 (CCITT-FALSE, XMODEM, Kermit, X-25, GENIBUS) ส่วน DNP3 เป็นพิเศษใช้ 0x3D65 โดยปกติ datasheet จะระบุ polynomial ไว้แล้ว แต่จำไว้ว่าแค่ชื่อยังไม่พอ ที่เหลือต้องดูต่อ
• Initial value (init) คือค่าเริ่มต้นของ register ก่อนไบต์แรก นิยมใช้ 0x0000 และ 0xFFFF แค่ init ต่างกันก็ทำให้ checksum ต่างกันหมดสำหรับข้อมูลชุดเดียวกัน เป็นสาเหตุอันดับหนึ่งของ bug แบบ "CRC ไม่ตรง"
• Input reflection (RefIn) คือการประมวลผลแต่ละไบต์จากบิต least-significant ก่อน Modbus reflect input ส่วน XMODEM ไม่ reflect กฎนี้เป็นมรดกจาก hardware shift register ยุคแรก ๆ และหลอก implementation ที่เขียนสดทุกครั้ง
• Output reflection (RefOut) คือการกลับบิต register สุดท้ายก่อนส่งออกผล RefIn กับ RefOut เกือบจะตั้งเหมือนกันเสมอ
• XOR-out (XorOut) คือ mask ที่นำมา XOR ตอนจบ X-25 และ USB XOR ด้วย 0xFFFF ส่วน Modbus ใช้ 0x0000 ขั้นตอนนี้ทำให้ implementation ที่เหมือนกันแทบทุกอย่างต่างกันแค่การกลับบิตได้

เมื่อรวมกันแล้วแต่ละชุดพารามิเตอร์มีค่าเฉพาะตัว จน CRC catalog กำหนด check value ของแต่ละตัวแปรจากข้อความอ้างอิง "123456789" ตัวอย่างเช่น CRC-16/ARC (poly 0x8005, init 0x0000, reflected) ได้ 0xBB3D ขณะที่ CRC-16/MODBUS (poly เดียวกันแต่ init 0xFFFF) ได้ 0x4B37 และ CCITT-FALSE (poly 0x1021, init 0xFFFF, ไม่ reflect) ได้ 0x29B1 ถ้า implementation ของคุณตรงทั้งสามค่านี้ ถือว่าถูกต้องเกือบแน่นอน

อีกเรื่องละเอียดแต่ใช้จริง: ลำดับ byte บนสาย protocol แบบ serial ส่วนใหญ่ส่ง checksum 16 บิตแบบ little-endian คือ low byte ออกก่อน เฟรม Modbus ที่ลงท้าย 0x4B37 จะส่งสองไบต์สุดท้ายเป็น 37 4B เครื่องมือให้ค่า 16 บิตเชิงตรรกะ ส่วนการประกอบเฟรมเป็นหน้าที่ของเรา

กรณีใช้งานจริง

Modbus RTU Frames บน RS-485

Modbus RTU ปิดท้ายทุก request และ response ด้วย checksum แบบ CRC-16/MODBUS เมื่อ slave device เมินคำสั่ง ให้คำนวณ CRC ของเฟรมซ้ำด้วยเครื่องมือนี้ วาง hex bytes ตรงตามที่ลงสาย แล้วเทียบกัน วิศวกรภาคสนามมักเปิดเว็บนี้ไว้ในแท็บคู่กับ serial monitor เลยล่ะ

ตรวจสอบ Firmware และ Hex Dumps

Bootloader และ routine อัปเดต OTA มักแนบ CRC-16 ท้ายไฟล์ image เพื่อจับความเสียหายของ flash อัปโหลดไฟล์ binary (ถึง 10MB) เลือกตัวแปรตามที่ระบุในซอร์สโค้ด bootloader แล้วยืนยันค่า trailer ก่อนแฟลช ใช้เวลาสองนาที แต่ช่วยกันบอร์ดตายได้ทั้งตัว

DNP3 และข้อความ SCADA

DNP3 โปรโตคอลหลักของระบบสาธารณูปโภคในอเมริกาเหนือ ใช้ CRC-16/DNP3 (poly 0x3D65, reflected, xorout 0xFFFF) บนทุกเฟรม link-layer ตอน integrate กับ RTU หรือ relay ในสถานีไฟฟ้า ตารางพารามิเตอร์ของเครื่องมือทำหน้าที่เป็น spec sheet ไปในตัว: ยืนยัน poly, init และ reflection ก่อนเขียน parser แม้แต่บรรทัดเดียว

Debug การเชื่อมต่อ Protocol

เมื่อสองระบบคุยกันไม่เข้าใจ ให้ checksum ทั้งสองฝั่ง ดึง bytes ที่แต่ละฝั่งส่ง รันผ่านเครื่องมือด้วยตัวแปรเดียวกัน แล้วคุณจะรู้ทันทีว่า bug อยู่ที่ตัวข้อมูล ที่การคำนวณ CRC หรือที่ลำดับ byte ปัญหาที่เคยคลุมเครือแบบ "device ปฏิเสธเฟรมของฉัน" จะกลายเป็น diff ที่ชี้จุดและแก้ได้เลย

แนวปฏิบัติที่ดี

• ยืนยันชื่อตัวแปรให้เป๊ะก่อนอย่างอื่น คำว่า "CCITT CRC-16" กำกวม เพราะ datasheet ต่าง ๆ ใช้เรียกทั้ง CCITT-FALSE, XMODEM และ Kermit ให้เทียบ check value ไม่ใช่แค่ชื่อ
• ตรวจ setup ด้วยข้อความ "123456789" คำนวณข้อความอ้างอิงนี้ทั้งในเครื่องมือและใน firmware ถ้าตรงกันและตรงกับค่า catalog แปลว่า pipeline ต่อถูกต้อง
• ใช้โหมด hex สำหรับงาน protocol จริง โหมดข้อความสะดวก แต่การเข้ารหัส UTF-8 อาจแทรก bytes ที่ไม่ได้ตั้งใจ hex input การันตีความแม่นยำระดับ byte
• ระวังลำดับ byte ตอนต่อท้ายผลลัพธ์ ตัวแปรที่ reflect อย่าง Modbus และ Kermit นิยมลงสายแบบ low-byte ก่อน ควรจด convention นี้ไว้ในโน้ต protocol ของทีม
• คำนวณ checksum จากช่วง byte ที่ spec กำหนดเป๊ะ การใส่หรือไม่ใส่ address byte, length field หรือ header คือ off-by-one คลาสสิกของการ debug checksum
• อย่าแก้ CRC ไม่ตรงด้วยการสุ่มลองตัวแปรไปเรื่อย ๆ ไม่ตรงหนึ่งจุดแปลว่าพารามิเตอร์ผิด ให้ไล่พารามิเตอร์จาก datasheet หรือ implementation ที่พิสูจน์แล้ว แล้วยืนยันด้วย check value

เริ่มคำนวณ CRC-16 ได้เลย

CRC-16 Calculator ฟรี ไม่ต้องสมัคร และรันในเบราว์เซอร์ทั้งหมด ครบ 10 ตัวแปร protocol ค่า check ตรงตาม catalog ผลลัพธ์ hex/decimal/binary และรองรับไฟล์ถึง 10MB ทุกอย่างที่ต้องใช้เพื่อหยุดเดาและเริ่มตรวจสอบ เปิดไว้ในแท็บคู่กับ serial console ของคุณได้เลย

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• CRC-32 Checksum Calculator — สำหรับ checksum 32 บิตที่ใช้ใน ZIP, PNG และ Ethernet
• Hash Type Identifier — ระบุว่า hash algorithm ใดสร้าง digest ลึกลับที่มีอยู่
• Base64 Tool — encode/decode Base64 payload ด้วย workflow แบบ offline-first

ขอให้สนุกกับการคำนวณ!

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

ถ: CRC-16/Modbus กับ CRC-16/CCITT ต่างกันอย่างไร?

ตอบ: ทั้งคู่ใช้ polynomial และ initial value ต่างกัน Modbus ใช้ poly 0x8005, init 0xFFFF และ reflected I/O ส่วน CCITT-FALSE ใช้ poly 0x1021, init 0xFFFF และไม่ reflect ข้อมูลเดียวกันแต่ได้ checksum ต่างกันหมด ต้องใช้ตัวแปรตรงตามที่ protocol ระบุเสมอ

ถ: ทำไม CRC-16 ที่คำนวณได้ไม่ตรงกับ checksum ของอุปกรณ์?

ตอบ: สาเหตุที่พบบ่อยคือใช้ตัวแปรผิด (init ต่างกัน), ช่วง byte ผิด (ใส่หรือไม่ใส่ header byte) หรือลำดับ byte ตอนต่อท้ายผลลัพธ์ผิด ให้ตรวจการตั้งค่าด้วยข้อความ "123456789" แล้วเทียบกับ check value ใน catalog

ถ: ค่า check value เอาไว้ทำอะไร?

ตอบ: check value คือ CRC ของข้อความทดสอบมาตรฐาน "123456789" ที่ CRC catalog ระบุไว้สำหรับทุกตัวแปร เช่น CRC-16/ARC ได้ 0xBB3D และ CRC-16/MODBUS ได้ 0x4B37 ช่วยให้ตรวจ implementation ได้ในขั้นตอนเดียวโดยไม่ต้องใช้ข้อมูล protocol จริง

ถ: คำนวณ CRC-16 จากไฟล์ binary ได้ไหม ไม่ใช่แค่ข้อความ?

ตอบ: ได้ เครื่องมือรับอัปโหลดไฟล์ได้ถึง 10MB แปลง raw bytes เป็น hex และคำนวณ checksum จากเนื้อหาไฟล์ทั้งหมด เหมาะกับ firmware image และ configuration blob

ถ: ข้อมูลของฉันถูกอัปโหลดไปเซิร์ฟเวอร์หรือเปล่า?

ตอบ: ไม่ การคำนวณทั้งหมดรันฝั่ง client ในเบราว์เซอร์ด้วย JavaScript ข้อความ เฟรม hex และไฟล์ของคุณไม่ออกจากเครื่อง จึงใช้กับข้อมูล protocol ที่เป็นความลับได้อย่างปลอดภัย