ASCII สำหรับข้อมูล PLC: เลขฐานสิบ เลขฐานสิบหก และรหัสควบคุม

ASCII ยังคงใช้กันอย่างแพร่หลายในโครงการ PLC เพราะอุปกรณ์อุตสาหกรรมจำนวนมากแลกเปลี่ยนข้อความทีละหนึ่งไบต์ เครื่องอ่านบาร์โค้ด เครื่องพิมพ์ฉลาก เครื่องชั่ง ไดรฟ์ เกตเวย์อนุกรม และเทอร์มินัลสำหรับผู้ปฏิบัติงาน มักแสดงคำสั่งและค่าการวัดเป็นรหัสอักขระ วิศวกรที่สามารถแปลงไปมาระหว่างอักขระ ค่าทศนิยม และไบต์เลขฐานสิบหก จะตรวจสอบและแก้ไขลิงก์เหล่านี้ได้รวดเร็วยิ่งขึ้น

ASCII กำหนดอะไรไว้บ้าง

American Standard Code for Information Interchange ฉบับดั้งเดิมเป็นชุดอักขระแบบเจ็ดบิต โดยกำหนดค่าไว้ 128 ค่า ตั้งแต่ 0 ถึง 127 ค่า 0 ถึง 31 และ 127 เป็นอักขระควบคุม ส่วนค่า 32 ถึง 126 เป็นอักขระที่แสดงผลได้ ซึ่งรวมถึงตัวอักษร ตัวเลข เครื่องหมายวรรคตอน และช่องว่าง

ข้อกำหนด RFC 20 ที่โฮสต์โดย IETF บันทึกตำแหน่งรหัสและความหมายที่ตั้งใจไว้ ระบบสมัยใหม่มักจัดเก็บอักขระ ASCII ไว้ในไบต์ขนาดแปดบิต บิตสูงสุดจะเป็นศูนย์สำหรับ ASCII มาตรฐาน

เลขฐานสิบ เลขฐานสิบหก และเลขฐานสองคือไบต์เดียวกัน

แท็ก PLC อาจแสดงค่าเดียวกันในรูปแบบตัวเลขหลายแบบ ตัวอักษร A พิมพ์ใหญ่มีค่าเป็น 65 ในเลขฐานสิบ, 41 ในเลขฐานสิบหก และ 01000001 ในเลขฐานสอง ตัวเลข 0 มีค่าเป็น 48 ในเลขฐานสิบ หรือ 30 ในเลขฐานสิบหก สิ่งเหล่านี้ไม่ใช่อักขระคนละตัว แต่เป็นการมองรูปแบบตัวเลขเดียวกันคนละแบบ

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

รหัสควบคุมมีความสำคัญในข้อความอุตสาหกรรม

โพรโทคอลอนุกรมจำนวนมากใช้อักขระควบคุมเป็นตัวคั่น การขึ้นบรรทัดใหม่แบบแคริเอจรีเทิร์นมีค่า 13 ในเลขฐานสิบ หรือ 0D ในเลขฐานสิบหก การป้อนบรรทัดมีค่า 10 ในเลขฐานสิบ หรือ 0A ในเลขฐานสิบหก Start of Text คือ 02 ในเลขฐานสิบหก ขณะที่ End of Text คือ 03 ในเลขฐานสิบหก อุปกรณ์อาจเพิกเฉยต่อคำสั่งที่ถูกต้องได้ หากไม่มีตัวปิดท้ายตามที่กำหนด

อย่าสันนิษฐานว่าอุปกรณ์ทุกเครื่องใช้ CR/LF บางเครื่องต้องการเฉพาะ CR บางเครื่องใช้ตัวคั่นที่แสดงผลได้ ความยาวข้อความคงที่ หรือไบต์ตรวจสอบความถูกต้อง ให้ยืนยันเฟรมที่แน่นอนจากคู่มือโพรโทคอลของผู้ผลิต

สตริง PLC กลายเป็นอาร์เรย์ไบต์ได้อย่างไร

แพลตฟอร์ม PLC จัดเก็บสตริงแตกต่างกัน บางแพลตฟอร์มเก็บความยาวปัจจุบันไว้ก่อนข้อมูลอักขระ ขณะที่บางแพลตฟอร์มสำรองอาร์เรย์ขนาดคงที่และปิดท้ายข้อความด้วยไบต์ศูนย์ เมื่อข้อมูลข้ามขอบเขตของโพรโทคอล อุปกรณ์ปลายทางจะเห็นเป็นไบต์ ไม่ใช่ชนิดสตริงภายในของคอนโทรลเลอร์

ตรวจสอบทั้งความยาวสตริงที่ประกาศไว้และบัฟเฟอร์พื้นฐาน ไบต์เก่าที่อยู่นอกความยาวปัจจุบันอาจปรากฏในข้อมูลที่ส่ง หากรูทีนส่งบัฟเฟอร์ทั้งหมด ให้ล้างปลายทางหรือส่งเฉพาะจำนวนอักขระที่ใช้งานอยู่

วิธีตรวจสอบวิเคราะห์ที่ใช้ได้จริง

1. บันทึกไบต์ที่ส่งออกจริงด้วยเครื่องมอนิเตอร์พอร์ตอนุกรม เครื่องวิเคราะห์โพรโทคอล หรือหน้าวินิจฉัยของเกตเวย์
2. เขียนไบต์แต่ละตัวในรูปเลขฐานสิบหก แล้วจับคู่ค่าที่แสดงผลได้กลับเป็นอักขระ
3. ระบุไบต์สำหรับการจัดเฟรม ตัวปิดท้าย ตัวคั่น ฟิลด์ความยาว และค่าตรวจสอบความถูกต้อง
4. เปรียบเทียบข้อมูลที่บันทึกได้กับคู่มืออุปกรณ์ รวมถึงช่องว่างและตัวพิมพ์ของตัวอักษร
5. บันทึกข้อความที่ทราบว่าใช้งานได้ดีอีกครั้ง แล้วเปรียบเทียบตำแหน่งของไบต์

แนวทางระดับไบต์นี้ช่วยแยกปัญหาการจัดรูปแบบออกจากปัญหาการเดินสาย อัตราบอด และพาริตี หากข้อมูลที่บันทึกได้เป็นข้อความที่อ่านออกแต่ไม่ครบ ให้มุ่งตรวจสอบการประกอบสตริง หากไบต์ทุกตัวผิด ให้ตรวจสอบการตั้งค่าทางกายภาพและการสื่อสารอนุกรมก่อน

ข้อผิดพลาดที่พบบ่อยในการนำไปใช้งาน

สับสนระหว่างตัวเลขกับค่าตัวเลขของมัน

อักขระ “5” คือ ASCII ค่า 53 ในเลขฐานสิบ ไม่ใช่ค่าจำนวนเต็ม 5 การแปลงค่าที่วัดได้เป็นข้อความต้องใช้รูทีนจัดรูปแบบ การคัดลอกจำนวนเต็มดิบลงในบัฟเฟอร์อักขระจะสร้างไบต์ควบคุมแทน

ผสมข้อความเลขฐานสิบหกเข้ากับไบต์ไบนารี

ข้อความ “41” ประกอบด้วยอักขระสองตัว ได้แก่ 34 ในเลขฐานสิบหก และ 31 ในเลขฐานสิบหก ไบต์เดียวที่มีค่า 41 ในเลขฐานสิบหกจะแทนตัวอักษร A ให้ตัดสินใจก่อนว่าโพรโทคอลต้องการข้อความเลขฐานสิบหกที่มนุษย์อ่านได้ หรือข้อมูลไบนารีดิบ

ละเลยการเข้ารหัสที่นอกเหนือจาก ASCII

ASCII ครอบคลุมตัวอักษรภาษาอังกฤษและชุดสัญลักษณ์ที่จำกัด UTF-8 ใช้ค่าไบต์เดียวกับ 128 อักขระแรก แต่ตัวอักษรที่ไม่ใช่ ASCII ใช้หลายไบต์ อุปกรณ์รุ่นเก่าอาจปฏิเสธไบต์เหล่านั้นหรือนับจำนวนผิด

แนวทางการออกแบบโค้ด PLC ที่ดูแลรักษาได้ง่าย

รวมการจัดรูปแบบโพรโทคอลไว้ในรูทีนเดียว ตั้งชื่อค่าคงที่สำหรับรหัสควบคุม แทนการกระจายค่าตัวเลขคงที่ไว้ทั่วลอจิกแบบแลดเดอร์หรือ Structured Text บันทึกบัฟเฟอร์ที่จะส่งจริงเป็นเลขฐานสิบหกระหว่างการทดสอบเดินระบบ และใส่ตัวอย่างไว้ในเอกสารโครงการ

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

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

รายการตรวจสอบการทดสอบเดินระบบ

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

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