บั๊กนาน ๆ ครั้ง แต่มีลำดับความสำคัญสูง

ฉันกำลังทำงานในโครงการ CNC (การควบคุมเชิงตัวเลขคอมพิวเตอร์) ซึ่งตัดรูปร่างเป็นโลหะด้วยเลเซอร์

ตอนนี้ปัญหาของฉันเป็นครั้งคราว (1-2 ครั้งใน 20 วันแปลก) การตัดผิดหรือไม่เป็นไปตามที่ตั้งไว้

แต่สิ่งนี้ทำให้เกิดการสูญเสียดังนั้นลูกค้าจึงไม่ค่อยมีความสุขกับมัน

ฉันพยายามค้นหาสาเหตุของมันโดย

1. รวมถึงไฟล์บันทึก
2. แก้จุดบกพร่อง
3. ทำซ้ำสภาพแวดล้อมเดียวกัน

แต่มันจะไม่ทำซ้ำ

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

ฉันจะแก้ไขปัญหานี้ได้อย่างไร ฉันควรระบุว่าเป็นปัญหาฮาร์ดแวร์หรือไม่

หลีกเลี่ยงการทำงาน

ดังที่ChrisFแนะนำวิธีแก้ปัญหาระยะสั้นในทางปฏิบัติอาจใช้การหยุดชั่วคราวและเล่นต่อแต่คุณต้องพูดคุยกับลูกค้าของคุณเพื่อรับทราบลำดับความสำคัญของคุณ ตัวอย่างเช่น:

• หากความผิดพลาดล้มเหลว 1,000 ปอนด์ส่วนหนึ่งหรือเป็นสาเหตุของการหยุดทำงาน 4 ชั่วโมงต่อสัปดาห์ในขณะที่การแก้ไขการหยุดชั่วคราวจะช่วยลดการผลิตลง 1% พวกเขาอาจต้องการการแก้ไขทันที

• หากความผิดพลาดล้มเหลวส่วนที่£ 1 หรือทำให้เกิดการหยุดทำงาน 4 นาทีต่อสัปดาห์ แต่การแก้ไขหยุดชั่วคราวกลับมาลดการผลิต 1% พวกเขาอาจจะชอบที่จะรอการแก้ไขที่ไม่ส่งผลกระทบต่ออัตราการผลิต

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

เข้าสู่ระบบ

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

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

การวิเคราะห์เชิงสถิต

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

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

ตัวเลือกอื่น

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

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

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

ฉันจะทำข้อเสนอแนะนอกกำแพง

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

เมื่อหลายสิบปีก่อนพ่อของฉันกำลังตกนรกด้วยคอมพิวเตอร์ขนาดเล็กที่ล้มเหลวโดยไม่มีเหตุผล พวกเขาเรียกว่าตัวแทนลูกค้าของผู้ผลิต

ตัวแทนเข้ามาในสำนักงานของพวกเขาในโรงงานและเสียบโวลต์มิเตอร์เข้ากับผนังถัดจากมินิแล้วพูดว่า "ดูสิ่งนี้"

ไม่กี่นาทีต่อมาโวลต์มิเตอร์ก็ยุบตัวลงอย่างมีนัยสำคัญจากนั้นก็กลับมา ตัวแทนกล่าวว่า "นั่นคือเขาที่โดดเด่นส่วนโค้งการทดสอบของเขารอสักครู่" หลังจากนั้นไม่นานโวลต์มิเตอร์ก็ลดลงอีกครั้งและคราวนี้มันก็คงที่

ตัวแทนกล่าวว่า "นั่นเป็นปัญหาของคุณคุณมีผู้ชายเชื่อมอยู่บนพื้นโรงงานและเขาก็มีพลังขาเดียวกับคุณฉันเห็นเขาตั้งขึ้นขณะที่ฉันเดินเข้ามา"

พวกเขาต้องใช้ฟีดพลังงานแยกจากกันอย่างสมบูรณ์ไปยังสำนักงาน

ปัญหาคือปัญหาจริงที่มีผลกระทบที่แท้จริงสำหรับผู้ใช้ - เช่นงานที่ถูกทำลายเป็นต้นดังนั้นจึงจำเป็นต้องแก้ไข อย่างไรก็ตามไม่จำเป็นต้องแก้ไข "ถูกต้อง" คุณระบุ:

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

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

เห็นได้ชัดว่าในระยะยาวคุณอาจต้องแก้ไขปัญหานี้ "อย่างถูกต้อง" แต่สำหรับเวลาที่ถูกตัดของคุณสูญเสียไปกับการแก้ปัญหาและได้รับเข้าสู่สิ่งอื่น

ฉันมีข้อบกพร่องในเกมที่เกิดขึ้นเพียง 1 ครั้งในหนึ่งพันล้านครั้ง โชคดีที่นั่นหมายความว่าฉันเห็นมันทุก ๆ 15 ถึง 30 นาที แต่การก้าวผ่านโค้ดใน debuggger ก็ไม่ได้ผล ฉันลงเอยด้วยการแก้ไขข้อความ พวกเขาจำเป็นต้องใช้คำสั่ง if-fancy เพราะฉันต้องการบางสิ่งเมื่อเกิดปัญหา ในกรณีส่วนใหญ่รหัสการดีบักทำการคำนวณซ้ำในรหัสปกติ แต่ใช้เทคนิคที่แตกต่างกัน การทำซ้ำไม่จำเป็นต้องแม่นยำ หากฉันรู้ว่าตัวเลขควรต่ำกว่า 10,000 และดูเหมือนว่าจะมีจำนวนถึง 150,000 ครั้งฉันจะตรวจสอบค่ามากกว่า 100,000 ทุกครั้งที่มีข้อผิดพลาดเกิดขึ้นฉันจะศึกษาผลลัพธ์ของฉันคิดค้นข้อความแก้ไขข้อบกพร่องที่ซับซ้อนมากขึ้น (หรือแม่นยำมากขึ้นตรวจสอบอย่างละเอียดมากขึ้นเพื่อดูว่าฉันควรแสดงข้อความ) และรอให้ปัญหาเกิดขึ้นอีกครั้ง

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

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

กฎข้อที่ 1 หมายเลขหนึ่งในการดีบัก: คุณต้องมีสถานการณ์จำลองได้

หากคุณไม่มีคุณควรทำงานก่อน คุณสามารถสร้างข้อผิดพลาดนั้นได้ใน "โหมดการจำลอง" ของเครื่องโดยที่ไม่มีโลหะถูกตัดจริงหรือไม่? นี่ดูเหมือนจะสมเหตุสมผลแล้ว คุณสามารถรันโปรแกรมตัดหลายแบบได้อย่างรวดเร็วและอัตโนมัติโดยจำลองกระบวนการ 20 วันในไม่กี่นาที? ที่อาจเพิ่มความน่าจะเป็นของปัญหาที่ปรากฏขึ้น

จากนั้นเมื่อคุณมีสถานการณ์เช่นนั้นขั้นตอนต่อไปคือการรวบรวมข้อมูลให้ได้มากที่สุดและเริ่มการดีบั๊กจริง ๆ

ไม่แน่ใจว่าจะใช้ภาษาใด แต่ถ้าฉันพบข้อผิดพลาดที่ไม่แน่นอนในรหัสของฉัน (C ++) ฉันจะใช้เครื่องมือเช่นvalgrindหรือcppcheckเพื่อให้แน่ใจว่าไม่มีสิ่งใดเกิดขึ้นกับหน่วยความจำที่ชาญฉลาด

ส่วนขยายของคำตอบของ RalphChapin:

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

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

โดยทั่วไปจะใช้การปรับแต่งสองสามรอบเพื่อตรึงมันลงอย่างแน่นอน แต่มันก็มีประสิทธิภาพมาก