Помилка час від часу, але високий пріоритет

Я працюю над проектом з ЧПУ (комп'ютерне числове управління), який за допомогою лазера ріже фігури в метал.

Тепер моя проблема час від часу (1-2 рази за 20 непарних днів) різання йде неправильно чи не відповідно до того, що встановлено.

Але це призводить до втрати, тому клієнт не дуже радий цьому.

Я намагався з’ясувати причину цього за допомогою

1. У тому числі файли журналів
2. Налагодження
3. Повторення того ж оточення.

Але це не повториться.

Пауза та продовження роботи знов змусять її працювати безперебійно, не з'являючись помилок.

Як вирішити цю проблему? Чи варто заявляти про це як апаратну проблему?

Робота оточує

Як пропонує ChrisF , прагматичним короткостроковим рішенням може бути використання паузи та відновлення трюку, але вам доведеться поговорити зі своїми клієнтами, щоб знати, якими мають бути ваші пріоритети. Наприклад:

• Якщо несправність знищує частину 1000 фунтів стерлінгів або спричиняє 4 години простою один раз на тиждень, тоді як виправлення паузи-відновлення скорочує виробництво на 1%, вони, мабуть, віддадуть перевагу виправленню прямо зараз.

• Якщо несправність втрачає частину £ 1 або викликає 4 хвилини простою один раз на тиждень, але виправлення пауз-відновлення скорочує виробництво на 1%, вони, ймовірно, віддадуть перевагу чекати виправлення, яке не впливає на швидкість виробництва.

Пропрацювавши в галузі лазерної мікрообробки багато років, я знаю, скільки тиску ти можеш мати, щоб оптимізувати процес і змусити машину виробляти якомога більше деталей на годину, так що в будь-якому випадку ти не будеш тиск, щоб правильно усунути проблему.

Ведення журналів

На мій досвід, єдиний спосіб ефективного відстеження Heisenbug - це рясна вирубка. Увійдіть у все та навколо тієї частини коду, яка могла б відповідати за помилку. Дізнайтеся, як ефективно читати файли журналів, переконайтеся, що ви стежите за помилками на своїх двигунах (чи ваші етапи рухаються туди, куди слід, коли слід?). Подивіться на використання пам’яті на апараті, чи витік пам’яті викликає голодний критичний процес?

Переконайтесь, що ви також реєструєте дії користувача, чи впевнені ви, що оператор не потрапляє на аварійну зупинку, щоб вони могли вискочити на швидку перерву сигарети під час її виправлення? Я бачив, як це відбувається!

Статичний аналіз

Крім того, шукайте кореляції між написанням певних шаблонів і помилкою, яку спрацьовує більш-менш часто. Якщо ви можете знайти шаблони, які частіше викликають проблему (або ніколи не викликають її), вони можуть вказувати на вашу проблему.

Постарайтеся зробити шаблони, які викликають проблему ще частіше. Якщо ви можете знайти спосіб надійно запустити проблему, то ви на половині шляху до рішення.

Інші варіанти

Нарешті, не поспішайте звинувачувати обладнання, але ніколи не вважайте, що це ідеально. Мене багато разів звинувачували в проблемах, які виявилися електричними або механічними за своєю суттю, тому це завжди потрібно мати у задній частині розуму.

Незважаючи на те, що ви, як правило, не маєте доступу до машини, пам’ятайте, що деякі проблеми можна вирішити лише ефективно на машині. Іноді кілька днів на місці можуть стояти тижнями через віддалений робочий стіл і місяці поза межами мережі. Якщо у вас не вистачає офлайн-варіантів, не бійтеся запропонувати відвідування сайту, вони можуть сказати лише «ні».

Ви також можете переглянути питання та відповіді на те, що ви робите з heisenbug? і що робити з помилками, які не докоряють? але це може бути не так корисно для вашої ситуації.

Я збираюся висловити непристінну пропозицію.

Перейдіть до заводу-менеджера і попросіть переглянути записи моніторів електропередач для цього інструменту чи тієї області на час виникнення несправностей. Також запитайте його, чи існувало якесь зварювання чи інша незвичайна діяльність приблизно в ці часи.

Кілька десятиліть тому у мого батька було пекло часу з мінікомп'ютером, який врізався без будь-якої причини. Вони назвали замовника виробника представником.

Репортер зайшов у їхній кабінет, на фабриці, і ввімкнув вольтметр у стіну, поруч із міні, а потім сказав: "Слідкуйте за цим".

Через кілька хвилин вольтметр раптово провис, помітно, потім повернувся. Репортер сказав: "Це він вразив свою тестову дугу. Почекайте хвилинку". Незабаром після цього вольтметр знову провис, і цього разу він залишився провислим.

Репортер сказав: "У цьому ваша проблема. У вас є хлопець, що зварюється на заводській підлозі, а він на тій же нозі, що і ви. Я бачив, як він підходив під час заходу".

Їм довелося запустити повністю окремий блок живлення в офіс.

Проблема справжня з реальними наслідками для користувача - тобто зруйнованою роботою тощо, тому вона потребує виправлення. Однак це не має бути закріплено "належним чином". Ви заявляєте:

Пауза та продовження операції знову змусять її працювати безперебійно, коли помилка знову з’явиться.

У такому випадку просто зробіть це. Замовник буде радий, що він не витрачає матеріал на несправні пробіжки, навіть якщо звичайні пробіжки займають на пару секунд більше.

Очевидно, що в довгостроковій перспективі вам може знадобитися це виправити «належним чином», але поки скорочуєте свої втрати, перейдіть до вирішення проблеми та займіться чимось іншим.

У мене була помилка в грі, яка трапилася лише 1 раз на мільярд. На щастя, це означало, що я бачив його кожні 15 - 30 хвилин, але переходити код у налагоджувачу не вдалося. Я в кінцевому підсумку ставив повідомлення про налагодження. Їм потрібно було використовувати вигадливі висловлювання, якщо я хотів чогось лише тоді, коли була проблема. У більшості випадків код налагодження повторював обчислення в звичайному коді, але використовуючи різні методи. Повтори не повинні були бути точними. Якби я знав, що кількість завжди повинна бути меншою за 10 000, і, здавалося, вона потрапляє до 150 000, якщо б я прийшов, я просто перевірив би на суму понад 100 000. Кожного разу, коли виникла помилка, я вивчав би свої результати, розробляв більш детальні повідомлення про налагодження (а точніше - більш детальні перевірки, щоб побачити, чи слід відображати повідомлення), і чекав, коли проблема виникне знову.

Ваші цикли будуть набагато довшими, ніж у мене, але з часом ви вирішите проблему. Я сподіваюся, що ви зможете знайти рішення іншим, більш швидким методом, але це врешті зловить його, якщо нічого іншого не зробить, і дасть вам відчуття, що ви щось робите, поки не придумаєте кращої ідеї.

(У випадку, якщо це корисно, я нарешті вирішив свою проблему, очистивши кілька рядків коду, який я нарешті визначив як проблему. Клянусь, у них нічого поганого не було, але я думаю, що оптимізатор і процесор переробляли інструкції для продуктивність, і я думаю, що час від часу вони ризикують отримати додаткову швидкість. Навіть одноядерний багатопроцесорний процес в наші дні, і я думаю, що кожен чудовий раз в аа в той час як реєстр читали до того, як він був написаний. Я переключив усі обчислення на роботу з локальними змінними. Значення "поля екземпляра" були перенесені на локальні змінні на самому початку, а локальні значення були переміщені назад лише в самому кінці, всередині блоків синхронізації. І я використав локальне значення для значення повернення методу, а не "поле примірника"Я використовував.)

Правило № 1 в налагодженні: вам потрібен відтворюваний сценарій .

Якщо у вас його немає, слід спершу попрацювати над цим. Чи можете ви відтворити цю помилку в якомусь "режимі моделювання" машини, де жоден метал насправді не ріжеться? Це, здається, має сенс тут. Чи можете ви запускати кілька різних програм різання швидко та автоматично, імітуючи процес за 20 днів за кілька хвилин? Це може збільшити ймовірність появи проблеми.

Потім, коли у вас є такий сценарій, наступний крок - зібрати якомога більше інформації та фактично почати налагодження.

Не впевнений, на якій мові це працює, але якщо у мене виникнуть помилкові помилки в моєму коді (C ++), я буду використовувати такий інструмент, як valgrind або cppcheck, щоб переконатися, що нічого не відбувається.

Розширення щодо відповіді Ральфхапіна:

Протягом багатьох років мені довелося полювати неабияку кількість помилок, які виявлялися лише в системах, які я не міг дублювати через прикріплене обладнання.

Окрім ведення журналу, як божевільного, інше, що мені здалося корисним: розміщення інформації на екрані із зазначенням того, де знаходиться код та значення деяких відповідних змінних. Коли проблема з’явилася, навіть працівники фабрики могли прочитати мені інформацію.

Зазвичай потрібно кілька раундів вдосконалення, щоб точно визначити це, але це було дуже ефективно.