Lỗi một lần trong một thời gian, nhưng ưu tiên cao

Tôi đang làm việc trong một dự án CNC (điều khiển số máy tính) để cắt các hình dạng thành kim loại với sự trợ giúp của laser.

Bây giờ vấn đề của tôi là thỉnh thoảng (1-2 lần trong 20 ngày lẻ) việc cắt có sai hay không theo những gì được đặt.

Nhưng điều này gây ra mất mát nên khách hàng không hài lòng về nó.

Tôi đã cố gắng tìm ra nguyên nhân của nó bằng cách

1. Bao gồm các tệp nhật ký
2. Gỡ lỗi
3. Lặp đi lặp lại cùng một môi trường.

Nhưng nó sẽ không lặp lại.

Tạm dừng và tiếp tục hoạt động sẽ một lần nữa làm cho nó chạy trơn tru mà không xuất hiện lỗi.

Làm thế nào để tôi giải quyết vấn đề này? Tôi có nên nêu nó như là một vấn đề phần cứng?

Công việc xung quanh

Như ChrisF gợi ý, giải pháp ngắn hạn thực dụng có thể là sử dụng thủ thuật tạm dừng và tiếp tục , nhưng bạn phải nói chuyện với khách hàng của mình để biết ưu tiên của bạn là gì. Ví dụ:

• Nếu lỗi làm hỏng một phần £ 1000 hoặc gây ra 4 giờ ngừng hoạt động mỗi tuần một lần, trong khi sửa chữa tạm dừng tiếp tục làm giảm sản lượng 1%, họ có thể sẽ thích sửa chữa ngay bây giờ.

• Nếu lỗi làm hỏng một phần £ 1 hoặc gây ra 4 phút ngừng hoạt động mỗi tuần một lần, nhưng sửa chữa tạm dừng tiếp tục làm giảm sản lượng 1%, có lẽ họ sẽ thích chờ một bản sửa lỗi không ảnh hưởng đến tốc độ sản xuất.

Đã làm việc trong ngành công nghiệp gia công vi mô laser trong nhiều năm, tôi biết bạn có thể chịu được bao nhiêu áp lực để tối ưu hóa quy trình và làm cho máy của bạn sản xuất càng nhiều bộ phận mỗi giờ càng tốt, do đó, bạn sẽ phải chịu áp lực để khắc phục vấn đề đúng.

Ghi nhật ký

Theo kinh nghiệm của tôi, cách duy nhất để theo dõi một cách hiệu quả một con bọ hung là ghi nhật ký nhiều. Đăng nhập mọi thứ trong và xung quanh một phần của mã có thể chịu trách nhiệm cho lỗi. Tìm hiểu cách đọc tệp nhật ký của bạn một cách hiệu quả, đảm bảo bạn đang theo dõi lỗi sau trên động cơ của mình (các giai đoạn của bạn có di chuyển khi cần khi nào không?). Nhìn vào việc sử dụng bộ nhớ trên máy, có bị rò rỉ bộ nhớ khiến quá trình quan trọng bị bỏ đói không?

Hãy chắc chắn rằng bạn cũng đang ghi nhật ký hành động của người dùng, bạn có chắc chắn rằng nhà điều hành không nhấn dừng khẩn cấp để họ có thể bật ra để nghỉ thuốc lá trong khi nó đã được sửa chữa? Tôi đã thấy điều này xảy ra!

Phân tích tĩnh

Ngoài ra, tìm kiếm mối tương quan giữa viết nguệch ngoạc một số mẫu nhất định và lỗi được kích hoạt ít nhiều thường xuyên. Nếu bạn có thể tìm thấy các mẫu gây ra vấn đề thường xuyên hơn (hoặc không bao giờ kích hoạt nó) thì những điều này có thể chỉ ra vấn đề của bạn.

Cố gắng tạo ra các mô hình gây ra vấn đề thậm chí thường xuyên hơn . Nếu bạn có thể tìm ra cách để kích hoạt vấn đề một cách đáng tin cậy thì bạn đã đi được một nửa giải pháp.

Sự lựa chọn khác

Cuối cùng, đừng nhanh chóng đổ lỗi cho phần cứng, nhưng đừng bao giờ cho rằng nó hoàn hảo. Đã nhiều lần tôi bị đổ lỗi cho các vấn đề hóa ra là điện hoặc cơ học, vì vậy bạn luôn phải có điều đó ở phía sau tâm trí của bạn.

Mặc dù bình thường bạn có thể không có quyền truy cập vào máy, hãy nhớ rằng một số vấn đề chỉ có thể được giải quyết hiệu quả trên máy. Đôi khi một vài ngày tại chỗ có thể có giá trị hàng tuần thông qua máy tính để bàn từ xa và hoàn toàn ngoại tuyến hàng tháng. Nếu bạn hết các tùy chọn ngoại tuyến, đừng ngại đề xuất truy cập trang web, họ chỉ có thể nói không.

Bạn cũng có thể muốn xem xét các câu hỏi và câu trả lời Bạn sẽ làm gì với một con bọ hung? và phải làm gì với những lỗi không được repro? nhưng những điều này có thể không hữu ích cho tình huống của bạn

Tôi sẽ đưa ra một đề nghị ngoài lề.

Đi đến người quản lý nhà máy và yêu cầu xem các bản ghi giám sát đường dây điện cho công cụ đó hoặc khu vực đó trong thời gian xảy ra sự cố. Cũng hỏi anh ta nếu có bất kỳ hàn, hoặc bất kỳ hoạt động bất thường nào khác, vào khoảng thời gian đó.

Vài thập kỷ trước, cha tôi đã có một thời gian khủng khiếp với một chiếc máy tính mini bị hỏng mà không có lý do nào cả. Họ gọi đại diện khách hàng của nhà sản xuất.

Người đại diện đi vào văn phòng của họ, trong khu vực nhà máy và cắm một vôn kế vào tường, bên cạnh chiếc mini, rồi nói "Xem cái này".

Vài phút sau, vôn kế đột nhiên chùng xuống, đáng kể, rồi quay lại. Người đại diện nói "Đó là anh ta đang đánh vòng cung thử nghiệm của mình. Đợi một chút." Ngay sau đó, vôn kế lại chùng xuống và lần này nó bị chùng xuống.

Người đại diện nói: "Đó là vấn đề của bạn. Bạn đã có một anh chàng hàn trên sàn nhà máy, và anh ta đang ở trên cùng một sức mạnh của bạn. Tôi thấy anh ta đang thiết lập khi tôi đang bước vào."

Họ đã phải chạy một nguồn cấp dữ liệu hoàn toàn riêng biệt cho văn phòng.

Vấn đề là một vấn đề thực sự với hậu quả thực sự cho người dùng - tức là làm hỏng công việc, v.v. vì vậy nó cần sửa chữa. Tuy nhiên, nó không phải được sửa "đúng". Bạn nói:

Tạm dừng và tiếp tục hoạt động sẽ một lần nữa làm cho nó chạy trơn tru với lỗi xuất hiện trở lại.

Trong trường hợp đó chỉ cần làm điều này. Khách hàng sẽ rất vui khi họ không lãng phí vật liệu cho các lần chạy bị lỗi ngay cả khi các hoạt động bình thường mất thêm vài giây.

Rõ ràng trong thời gian dài bạn có thể cần phải sửa lỗi này "đúng" nhưng cho thời gian được cắt bạn thua lỗ, đi với cách giải quyết và nhận được vào cái gì khác.

Tôi đã có một lỗi trong một trò chơi chỉ xảy ra 1 lần trong một tỷ. May mắn là điều này có nghĩa là tôi đã nhìn thấy nó cứ sau 15 đến 30 phút, nhưng bước qua mã trong trình gỡ lỗi sẽ không hoạt động. Tôi đã kết thúc việc đưa vào các thông báo gỡ lỗi. Họ cần sử dụng các câu lệnh if ưa thích vì tôi chỉ muốn một cái gì đó khi có vấn đề. Trong hầu hết các trường hợp, mã gỡ lỗi đã lặp lại các phép tính trong mã thông thường nhưng sử dụng các kỹ thuật khác nhau. Việc lặp lại không phải chính xác. Nếu tôi biết một con số phải luôn dưới 10.000 và nó dường như đạt 150.000 lần, tôi chỉ cần kiểm tra giá trị hơn 100.000. Mỗi lần xảy ra lỗi, tôi sẽ nghiên cứu kết quả của mình, đưa ra các thông báo gỡ lỗi phức tạp hơn (hay chính xác hơn là kiểm tra công phu hơn để xem liệu tôi có nên hiển thị thông báo không) và đợi vấn đề phát sinh trở lại.

Chu kỳ của bạn sẽ dài hơn tôi rất nhiều, nhưng cuối cùng bạn sẽ giải quyết được vấn đề. Tôi hy vọng bạn có thể tìm ra giải pháp bằng một phương pháp khác, nhanh hơn, nhưng điều này cuối cùng sẽ nắm bắt được nếu không có gì khác, và sẽ cho bạn cảm giác rằng bạn đang làm gì đó cho đến khi bạn nảy ra ý tưởng tốt hơn.

(Trong trường hợp hữu ích, cuối cùng tôi đã giải quyết vấn đề của mình bằng cách dọn sạch một vài dòng mã mà cuối cùng tôi đã xác định là sự cố. Tôi sẽ thề không có gì sai với họ, nhưng tôi nghĩ cả trình tối ưu hóa và CPU đều sắp xếp lại các hướng dẫn cho hiệu suất, và tôi nghĩ thỉnh thoảng họ lại có cơ hội để có thêm một chút tốc độ. Ngay cả một quy trình đa lõi đơn lẻ ngày nay, và tôi nghĩ rằng mọi thứ tuyệt vời trong một lần trong khi một thanh ghi đã được đọc trước khi nó được viết. Tôi đã chuyển tất cả các tính toán để làm việc với các biến cục bộ. Các giá trị "trường Instance" đã được chuyển sang các biến cục bộ ngay khi bắt đầu và các giá trị cục bộ chỉ được di chuyển trở lại ở cuối, bên trong các khối đồng bộ hóa. Và tôi đã sử dụng một giá trị cục bộ cho giá trị trả về của phương thức chứ không phải là "trường thể hiện"Tôi đã sử dụng.)

Quy tắc 1 số một trong gỡ lỗi: bạn cần một kịch bản có thể lặp lại .

Nếu bạn không có, bạn nên làm việc đó trước. Bạn có thể tái tạo lỗi đó trong một số loại "chế độ mô phỏng" của máy không, nơi không có kim loại thực sự bị cắt? Điều này dường như có ý nghĩa ở đây. Bạn có thể chạy một số chương trình cắt khác nhau một cách nhanh chóng và tự động, mô phỏng quá trình 20 ngày trong vài phút không? Điều đó có thể làm tăng xác suất của vấn đề hiển thị.

Sau đó, khi bạn có một kịch bản như vậy, bước tiếp theo là thu thập càng nhiều thông tin càng tốt và thực sự bắt đầu gỡ lỗi.

Không chắc ngôn ngữ này được chạy bằng ngôn ngữ nào, nhưng nếu tôi gặp lỗi lỗi trong mã của mình (C ++), tôi sẽ sử dụng một công cụ như valgrind hoặc cppcheck để đảm bảo không có gì xảy ra với bộ nhớ.

Một phần mở rộng về câu trả lời của RalphChapin:

Trong những năm qua, tôi đã phải săn một số lỗi khá lớn chỉ xuất hiện trên các hệ thống mà tôi không thể sao chép vì phần cứng kèm theo.

Ngoài việc đăng nhập như điên, một điều khác tôi thấy hữu ích: Đưa thông tin lên màn hình hiển thị mã ở đâu và giá trị của một số biến có liên quan. Khi vấn đề xuất hiện, ngay cả các công nhân sàn nhà máy cũng có thể đọc cho tôi thông tin.

Nó thường mất một vài vòng tinh chỉnh để xác định chính xác nhưng nó rất hiệu quả.