Ошибка время от времени, но высокий приоритет

Я работаю над проектом ЧПУ (компьютерное числовое управление), который вырезает фигуры в металл с помощью лазера.

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

Но это приводит к убыткам, поэтому клиент не очень этому рад.

Я пытался выяснить причину этого

1. Включая файлы журналов
2. Отладка
3. Повторяя ту же среду.

Но это не повторится.

Операция паузы и продолжения снова заставит ее работать гладко без повторного появления ошибки.

Как мне решить эту проблему? Должен ли я заявить, что это аппаратная проблема?

Работа вокруг

Как предполагает ChrisF , прагматичным краткосрочным решением может быть использование трюка с паузой и возобновлением , но вы должны поговорить со своими клиентами, чтобы узнать, какими должны быть ваши приоритеты. Например:

• Если неисправность выходит за рамки 1000 фунтов стерлингов или вызывает 4 часа простоя один раз в неделю, а исправление паузы и возобновления сокращает производство на 1%, они, вероятно, предпочтут это исправление прямо сейчас.

• Если из-за ошибки происходит потеря 1 фунта или один раз в неделю 4 минуты простоя, но исправление паузы и возобновления сокращает производство на 1%, они, вероятно, предпочтут дождаться исправления, которое не влияет на производительность.

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

логирование

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

Убедитесь, что вы также регистрируете действия пользователя. Вы уверены, что оператор не нажимает на аварийную остановку, чтобы он мог выскочить из-за перебоя сигареты, пока она чинится? Я видел, как это произошло!

Статический анализ

Кроме того, ищите корреляции между написанием определенных образцов и ошибкой, вызываемой более или менее часто. Если вы можете найти шаблоны, которые вызывают проблему чаще (или никогда не вызывают ее), это может указывать на вашу проблему.

Попробуйте сделать шаблоны, которые вызывают проблему еще чаще. Если вы можете найти способ надежного запуска проблемы, то вы на полпути к решению.

Другие опции

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

Даже если вы обычно не имеете доступа к машине, помните, что некоторые проблемы могут быть эффективно решены только на машине. Иногда несколько дней на месте могут стоить недели с помощью удаленного рабочего стола и месяцев в автономном режиме. Если у вас закончились офлайновые варианты, не бойтесь предложить посещение сайта, они могут только сказать «нет».

Возможно, вы также захотите взглянуть на вопросы и ответы на вопрос « Что вы делаете с гейзенбагом?». и что делать с ошибками, которые не воспроизводятся? но они могут быть не очень полезны для вашей ситуации.

Я собираюсь сделать внушительное предложение.

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

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

Представитель вошел в их офис, на заводскую площадь, подключил вольтметр к стене, рядом с мини, и затем сказал: «Следите за этим».

Через несколько минут вольтметр внезапно значительно просел, а затем вернулся. Представитель сказал: «Это он ударил свою испытательную дугу. Подождите минутку». Вскоре после этого вольтметр снова провис, и на этот раз он остался провисшим.

Представитель сказал: «Это твоя проблема. У тебя есть парень, который сваривает на заводском полу, и он на той же силовой ноге, что и ты. Я видел, как он садился, когда шел».

Им пришлось запустить совершенно отдельный источник питания для офиса.

Эта проблема является реальной и имеет реальные последствия для пользователя - то есть испорченную работу и т. Д., Поэтому ее необходимо устранить. Однако, это не должно быть исправлено "должным образом". Вы заявляете:

Операция паузы и продолжения снова заставит ее работать гладко с появлением ошибки.

В таком случае просто сделай это. Заказчик будет рад, что он не тратит впустую материал на дефектные пробеги, даже если нормальные пробеги занимают пару секунд дольше.

Очевидно, что в долгосрочной перспективе вам может понадобиться исправить это «должным образом», но на данный момент сократите свои потери, используйте обходной путь и перейдите к чему-то другому.

У меня была ошибка в игре, которая случалась только 1 раз из миллиарда. К счастью, это означало, что я видел его каждые 15-30 минут, но пошаговое выполнение кода в отладчике не сработало. Я закончил тем, что вставил отладочные сообщения. Им нужно было использовать причудливые операторы if, потому что я хотел что-то, только когда возникла проблема. В большинстве случаев код отладки повторял вычисления в обычном коде, но использовал разные методы. Повторы не должны были быть точными. Если бы я знал, что число всегда должно быть меньше 10 000, а иногда оно доходило до 150 000, я бы просто проверил значение более 100 000. Каждый раз, когда возникала ошибка, я изучал свои результаты, разрабатывал более сложные сообщения отладки (или, точнее, более сложные проверки, чтобы увидеть, должен ли я отображать сообщение), и ждал, пока проблема возникнет снова.

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

(В случае, если это полезно, я, наконец, решил свою проблему, очистив несколько строк кода, которые я окончательно определил как проблему. Я клянусь, в них нет ничего плохого, но я думаю, что и оптимизатор, и процессор переупорядочивали инструкции для производительность, и я думаю, что время от времени они имели шанс получить немного дополнительной скорости. Даже одноядерные мультипроцессы в наши дни, и я думаю, что каждый великий раз в то время, когда регистр читался до того, как он был записан. Я переключил все вычисления для работы с локальными переменными. Значения «поля экземпляра» были перемещены в локальные переменные в самом начале, а локальные значения были перемещены назад только в самом конце, внутри блоков синхронизации. И я использовал локальное значение для возвращаемое значение метода, а не "поле экземпляра"Я использовал.)

Правило № 1 при отладке: вам нужен воспроизводимый сценарий .

Если у вас его нет, вы должны сначала поработать над этим. Можете ли вы воспроизвести эту ошибку в каком-то «режиме симуляции» машины, где фактически не режется металл? Это, кажется, имеет смысл здесь. Можете ли вы запустить несколько различных программ резки быстро и автоматически, имитируя процесс продолжительностью 20 дней за несколько минут? Это может увеличить вероятность появления проблемы.

Затем, когда у вас есть такой сценарий, следующий шаг - собрать как можно больше информации и начать отладку.

Не уверен, на каком языке это работает, но если в моем коде (C ++) возникают ошибочные ошибки, я буду использовать такой инструмент, как valgrind или cppcheck, чтобы гарантировать, что в памяти ничего не происходит.

Расширение ответа Ральфа Чапина:

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

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

Обычно требовалось несколько раундов обработки, чтобы точно определить это, но это было очень эффективно.