ข้อผิดพลาด Overflow Trap 0020 ของ SLC 500: การแก้ไขแลตช์ S:5/0
ความผิดพลาดร้ายแรง 0020 ของ SLC 500 หมายถึงกับดักโอเวอร์โฟลว์ S:5/0 ถูกล็อกค้างหลังจากการคำนวณผิดพลาด การล้างบิตด้วย OTU อาจทำให้ CPU ทำงานต่อได้—แต่ต้องวางร...
ทุก ๆ สองสามวัน SLC จะเข้าสู่สถานะฟอลต์ รหัสข้อผิดพลาดหลัก 0020 ฝ่ายปฏิบัติการได้แต่ยักไหล่ ฝ่ายซ่อมบำรุงเคลียร์ฟอลต์ แล้วการผลิตก็เดินหน้าต่อ—จนกระทั่งความผิดพลาดทางคณิตศาสตร์เดิมเกิดขึ้นอีกครั้งในกะกลางคืน รูปแบบนี้คือบิตดักจับโอเวอร์โฟลว์ S:5/0 ที่ทำงานตรงตามที่ Rockwell ออกแบบไว้: ล็อกสถานะเพื่อไม่ให้คุณแกล้งทำเป็นว่าไม่เคยเกิดการคำนวณผิดพลาดขึ้น
ใน 5/04 เช่น 1747-L524 รหัส 0020 หมายความว่าคำสั่งหนึ่งสร้างผลลัพธ์นอกช่วงค่าจำนวนเต็มที่อนุญาต การทำงานแบบจำนวนเต็ม signed 16 บิตอยู่ระหว่าง −32768 ถึง +32767 หากเกินขีดจำกัดนี้ด้วย ADD หรือ MUL หารด้วยศูนย์ เลื่อนตำแหน่งใน FIFO/LIFO จนเกินบัฟเฟอร์ หรือใช้ NEG กับ −32768 โปรเซสเซอร์จะตั้งค่า S:5/0 แล้วค้างอยู่ในสถานะฟอลต์จนกว่าจะมีการปลดล็อกบิตดังกล่าว คู่มือในตระกูล Publication 1747-UM011 / 1747-UM001 อธิบายกับดักนี้ไว้ แต่สิ่งที่หน้างานเห็นมีเพียง CPU ที่หยุดทำงาน
โปรเซสเซอร์ SLC รุ่นเก่ายังคงควบคุมเครื่องจักรแบบดิสครีตจำนวนมาก กับดักโอเวอร์โฟลว์เกือบทั้งหมดเกิดจากคณิตศาสตร์ในแอปพลิเคชัน ไม่ใช่แบ็กเพลนกำลังเสื่อม
OTU ที่ช่วยหยุดปัญหาชั่วคราว
การกู้คืนอย่างรวดเร็วส่วนใหญ่มักใส่ OTU ให้กับ S:5/0 เพื่อให้สแกนทำงานต่อได้หลังเกิดกับดัก ตำแหน่งที่วางคือหัวใจสำคัญ วางไว้เป็น รางสุดท้ายใน LAD 2—ไฟล์ที่เป็นเจ้าของการเรียก JSR—เพื่อให้ซับรูทีนทุกตัวทำงานเสร็จก่อนที่คุณจะเคลียร์แลตช์ วิธีนี้ทำให้ตรวจพบโอเวอร์โฟลว์ระหว่างสแกน แล้วเคลียร์เพียงครั้งเดียวก่อนเข้าสู่ช่วงว่าง
LAD 2 — รางสุดท้าย S:5/0 ----] [----(OTU)----
หากใส่ OTU เดียวกันไว้ภายในซับรูทีนที่เกิดโอเวอร์โฟลว์ คุณจะสร้างโหมดความขัดข้องแบบใหม่ขึ้นมา: เคลียร์เร็วเกินไป เกิดโอเวอร์โฟลว์อีกครั้งภายในการสแกนเดียวกัน แล้วกลับเข้าสู่ฟอลต์ทันที หรือ OTU อาจทำงานบนเส้นทางที่ไม่ได้พบการคำนวณผิดพลาดในสแกนนั้น ทำให้คุณคิดว่า “แก้แล้ว” ทั้งที่รางต้นเหตุยังคงทำงานผิดพลาดซ้ำสัปดาห์ละสองครั้ง
| รายการ | การใช้งาน |
|---|---|
| บิต |
S:5/0 กับดักโอเวอร์โฟลว์ (แลตช์ค้าง) |
| คำสั่ง | OTU |
| ไฟล์ | LAD 2 (หลัก) |
| ตำแหน่ง | หลัง JSR ทุกตัว เป็นรางสุดท้าย |
ดาวน์โหลดโปรแกรม เปลี่ยนคีย์ไปที่ RUN แล้วเฝ้าดู S:5/0 ให้คงสถานะเคลียร์ตลอดสองสามกะ หากยังเงียบอยู่ นั่นหมายความว่าคุณซื้อเวลาได้—not ปิดสาเหตุรากเหง้าได้
ค้นหาคณิตศาสตร์ที่ทำให้เกิดโอเวอร์โฟลว์จริง
ให้มอง OTU เป็นเข็มขัดนิรภัย จากนั้นเริ่มค้นหา:
- การเปลี่ยนแปลงล่าสุดใด ๆ ที่แตะต้องค่าจำนวนเต็ม—จำนวนแบตช์ ค่าแอนะล็อกที่สเกลแล้วถูกโยนเข้า N-file หรือ MUL “ชั่วคราว” สำหรับแปลงหน่วย
- ADD / SUB / MUL / DIV / DDV ที่ไม่มีการจำกัดช่วงค่า
- จุดที่ควรใช้ LADD / LMUL (32 บิต) หลังจากค่าต่าง ๆ ออกจากช่วงปลอดภัยของ 16 บิต
- การใช้ NEG กับค่าที่อาจอยู่ที่ −32768
- ความยาว FIFO/LIFO เทียบกับขนาดบัฟเฟอร์ที่จองไว้จริง
บิตสถานะที่เกี่ยวข้องและควรรู้ระหว่างดีบัก: S:5/1 เปิดใช้งานกับดักโอเวอร์โฟลว์, S:1/0 การสแกนครั้งแรก, S:2/0 ฟอลต์ของโปรเซสเซอร์ อย่าเคลียร์กับดักแบบสุ่มสี่สุ่มห้าในการแก้ไขออนไลน์โดยไม่รู้ว่ารางใดกำลังเป็นต้นเหตุ
ตรวจสอบความเป็นจริงด้านฮาร์ดแวร์
CPU 5/04 ระดับ 1747-L524 ล้าสมัยอย่างมากแล้ว หากยังใช้แชสซีเดิม ควรเก็บ 5/04 สำรองที่ผ่านการทดสอบแล้วไว้บนชั้นวาง—โรงงานที่ยังจัดซื้อผลิตภัณฑ์ในตระกูลนี้มักลงเอยกับโมดูลอย่าง 1747-L542 เครื่องจักรขนาดเล็กบางรุ่นอาจย้ายไปใช้ 5/03 เช่น 1747-L532 แต่เรื่องนี้เป็นการตัดสินใจระดับโครงการ ไม่ใช่วิธีแก้โอเวอร์โฟลว์ ในระยะยาว โรงงานส่วนใหญ่จะย้ายกระบวนการไปยัง CompactLogix หรือ ControlLogix และเลิกใช้กับดักคณิตศาสตร์ 16 บิตไปพร้อมกับแพลตฟอร์ม กลยุทธ์การจัดหาอะไหล่สำหรับระบบ Logix แบบผสมยังคงต้องสอดคล้องกับวิธีที่คุณจัดสต็อก ระบบ PLC และ PAC
จนกว่าการย้ายระบบจะเสร็จสิ้น หลักปฏิบัตินั้นง่ายมาก: วาง OTU ไว้ท้ายสุดของ LAD 2 จากนั้นพิสูจน์ให้ได้ว่า ADD/MUL ตัวใดกำลังรายงานช่วงค่าของตัวเองผิด
เกี่ยวกับผู้เขียน
Mark Townsend | วิศวกรระบบอัตโนมัติอาวุโส – ระบบ Allen-Bradley
Mark Townsend เป็นวิศวกรระบบอัตโนมัติอาวุโสที่มีประสบการณ์มากกว่า 18 ปีกับแพลตฟอร์ม Allen-Bradley ครอบคลุม ControlLogix, CompactLogix และ SLC-500 รุ่นเก่า งานประจำวันของเขาคือการพัฒนาลอจิกใน RSLogix / Studio 5000 และการนำระบบ HMI ของ FactoryTalk View ไปใช้งานในระบบที่มีอายุการใช้งานสูงและฟลีตแบบผสม
