가끔 버그가 있지만 우선 순위가 높습니다.

레이저를 사용하여 모양을 금속으로 자르는 CNC (컴퓨터 수치 제어) 프로젝트를 진행 중입니다.

이제 내 문제는 가끔씩 (20 일 동안 1-2 번) 절단이 잘못되었거나 설정에 따라 잘못되었습니다.

그러나 이것은 손실을 유발하므로 고객은 그것에 대해 매우 만족하지 않습니다.

나는 그것의 원인을 찾으려고 노력했다.

1. 로그 파일 포함
2. 디버깅
3. 동일한 환경을 반복합니다.

그러나 반복하지 않습니다.

일시 정지 및 계속 작업은 버그가 다시 나타나지 않고 다시 원활하게 실행되도록합니다.

이 문제를 어떻게 해결합니까? 하드웨어 문제로 표시해야합니까?

해결 방법

ChrisF가 제안한 것처럼 실용적인 단기 솔루션은 일시 중지 및 재개 트릭 을 사용하는 것이지만 고객에게 우선 순위를 알려야합니다. 예를 들면 다음과 같습니다.

• 고장으로 인해 £ 1000의 부품이 폐기되거나 일주일에 한 번 4 시간의 가동 중지 시간이 발생하는 경우 일시 중지-재개 수정으로 인해 생산이 1 % 감소하지만 지금 당장 수정을 선호 할 것입니다.

• 결함으로 인해 £ 1 부품이 폐기되거나 일주일에 한 번 4 분의 가동 중지 시간이 발생하지만 일시 중지-재개 수정으로 인해 생산이 1 % 감소하면 생산 속도에 영향을 미치지 않는 수정을 기다리는 것이 좋습니다.

레이저 마이크로 머시닝 업계에서 수년 동안 일한 결과 공정을 최적화하고 가능한 한 시간당 많은 부품을 생산할 수있는 압력을 알고 있습니다. 문제를 올바르게 해결해야합니다.

벌채 반출

내 경험상 Heisenbug 를 효과적으로 추적하는 유일한 방법 은 풍부한 로깅입니다. 오류의 원인이 될 수있는 코드의 일부와 주변에 모든 것을 기록하십시오. 로그 파일을 효과적으로 읽는 방법을 배우고 모터에서 다음과 같은 오류 를 모니터링하고 있는지 확인하십시오 (단계는 언제 어디에서 움직여야합니까?). 머신의 메모리 사용량을 살펴보십시오. 메모리 누출로 인해 중요한 프로세스가 고갈됩니까?

사용자 조치도 기록하고 있는지 확인하십시오. 운전자가 비상 정지를 치고 있지 않은지 확인하여 문제가 해결되는 동안 갑작스러운 담배 브레이크가 발생할 수 있습니까? 나는 이것이 일어나는 것을 보았다!

정적 분석

또한 특정 패턴을 스크라이브하는 것과 버그가 더 자주 발생하는 것과의 상관 관계를 찾으십시오. 문제를 더 자주 발생시키는 패턴을 찾거나 전혀 발생시키지 않는 경우 문제를 가리킬 수 있습니다.

문제 를보다 자주 유발하는 패턴을 만들어보십시오 . 문제를 확실하게 유발할 수있는 방법을 찾으면 해결 방법의 절반이됩니다.

다른 옵션

마지막으로 하드웨어를 비난하지 말고 완벽하다고 가정하지 마십시오. 여러 번 나는 본질적으로 전기 또는 기계적인 것으로 판명 된 문제에 대해 비난을 받아 왔기 때문에, 항상 당신의 마음의 뒤에 그것을 가지고 있어야합니다.

일반적으로 머신에 액세스하지 못할 수도 있지만 머신에서 일부 문제 만 효율적으로 해결할 수 있습니다. 때때로 며칠은 현장에서 원격 데스크톱을 통해 몇 주가 걸리고 완전히 오프라인으로 몇 달이 걸릴 수도 있습니다. 오프라인 옵션이 부족한 경우 사이트 방문을 제안하는 것을 두려워하지 말고 거절 할 수 있습니다.

heisenbug로 무엇을합니까?에 대한 질문과 답변을보고 싶을 수도 있습니다 . 그리고 재현하지 않는 버그로 무엇을해야합니까? 그러나 상황에 따라 유용하지 않을 수 있습니다.

나는 벽에서 제안을 할 것입니다.

공장 관리자에게 가서 오작동이 발생한 시간에 대해 해당 공구 또는 해당 지역의 전력선 모니터 레코드를 확인하도록 요청하십시오. 또한 그시기에 용접이나 다른 비정상적인 활동이 있었는지 물어보십시오.

수십 년 전, 아버지는 아무 이유없이 추락하고있는 미니 컴퓨터로 시간을 보내고있었습니다. 그들은 제조업체의 고객 담당자라고 불렀습니다.

담당자는 공장 지역 사무실에 와서 미니 옆의 벽에 전압계를 꽂은 후 "이것을 봐라"고 말했다.

몇 분 후, 전압계가 갑자기 늘어져서 다시 돌아 왔습니다. 담당자는 "그가 그의 테스트 아크를 쳤습니다. 잠시만 요." 그 직후 전압계가 다시 꼬리표를 달았습니다. 이번에는 꼬리표가 유지되었습니다.

담당자는 "이것이 당신의 문제입니다. 당신은 공장 바닥에 용접하는 사람이 있고, 그는 당신과 같은 힘의 다리에 있습니다. 나는 그가 들어가는 동안 그를 세우는 것을 보았습니다."

그들은 사무실에 완전히 별도의 전원 공급 장치를 실행해야했습니다.

문제는 사용자에게 실질적인 결과를 초래하는 실제 문제입니다. 즉, 망가진 작업 등 수정해야합니다. 그러나 "적절하게"수정 될 필요는 없습니다. 당신은 말합니다 :

일시 정지 및 계속 작업을 다시 수행하면 버그가 다시 나타나면서 원활하게 실행됩니다.

이 경우에는이 작업을 수행하십시오. 고객은 정상 실행에 몇 초가 더 걸리더라도 결함이있는 실행에 재료를 낭비하지 않는 것을 기쁘게 생각합니다.

분명히 장기적으로이 문제를 "적절하게"수정해야 할 수도 있지만 손실을 줄이려 면 해결 방법을 사용하여 다른 문제를 해결하십시오.

게임에서 버그가 1 억 회에 불과 1 회 발생했습니다. 운 좋게 이것은 15 ~ 30 분마다 그것을 보았지만 디버거의 코드를 단계별로 실행하는 것은 효과가 없었습니다. 결국 디버그 메시지를 넣었습니다. 문제가있을 때만 무언가를 원했기 때문에 멋진 if 문을 사용해야했습니다. 대부분의 경우 디버깅 코드는 일반 코드에서 계산을 반복했지만 다른 기술을 사용했습니다. 반복은 정확하지 않아도됩니다. 숫자가 항상 10,000 미만이어야한다는 것을 알고 가끔씩 150,000을 기록하는 것 같으면 100,000 이상의 값을 확인하려고합니다. 버그가 발생할 때마다 결과를 연구하고보다 정교한 디버깅 메시지 (또는보다 정확하게 메시지를 표시해야하는지 확인하기위한보다 정교한 검사)를 고안하고 문제가 다시 발생할 때까지 기다렸습니다.

당신의주기는 나의 것보다 훨씬 길어질 것이지만, 결국 문제에 가까워 질 것입니다. 다른 빠른 방법으로 솔루션을 찾을 수 있기를 바랍니다. 그러나 다른 방법이 없다면 결국에는 그것을 잡아 내고 더 나은 아이디어를 얻을 때까지 무언가를 하고 있다는 느낌을 줄 것입니다.

(도움이되는 경우 마침내 문제로 식별 된 몇 줄의 코드를 정리하여 문제를 해결했습니다. 문제가 없다는 것을 맹세하지만 최적화 프로그램과 CPU 모두에 대한 지침을 재정렬한다고 생각합니다. 요즘에는 단일 코어 멀티 프로세스조차도 한 번이라도 생각하기 때문에 레지스터가 기록되기 전에 레지스터가 읽히는 동안 aa에서 모든 위대한 것을 생각합니다. I는 "인스턴스 필드"값이 바로 시작에서 로컬 변수로 이동 하였다. 로컬 변수에 대한 작업을 모든 계산을 교환하고 로컬 값은 동기 블록 내부 위로 만 매우 단부로 이동 하였다. 그리고 사용 된 로컬 가치를 "인스턴스 필드"가 아닌 메소드 리턴 값나는 사용하고 있었다.)

디버깅에서 가장 중요한 규칙 1 : 재현 가능한 시나리오가 필요합니다 .

없는 경우 먼저 작업해야합니다. 금속이 실제로 절단되지 않은 기계의 "시뮬레이션 모드"에서 버그를 재현 할 수 있습니까? 이것은 여기서 의미가있는 것 같습니다. 몇 분 안에 20 일의 과정을 시뮬레이션하면서 여러 가지 다른 절삭 프로그램을 빠르고 자동으로 실행할 수 있습니까? 문제가 나타날 가능성이 높아질 수 있습니다.

그런 다음 이러한 시나리오가 발생하면 다음 단계는 가능한 많은 정보를 수집하고 실제로 디버깅을 시작하는 것입니다.

확실하지 어떤 언어이 실행됩니다,하지만 난 내 코드 (C ++)에서 이상한 버그가 발생하는 경우, 내가 같은 도구를 사용 Valgrind의 또는 cppcheck 아무것도 메모리 현명한에 진행되지 않습니다 보장하기 위해.

RalphChapin의 답변에 대한 확장 :

수년 동안 나는 부착 된 하드웨어로 인해 복제 할 수없는 시스템에서만 보여지는 상당히 많은 버그를 찾아야했습니다.

미친 것처럼 로깅하는 것 외에도 유용하다는 것을 알게되었습니다. 코드가 어디에 있고 관련 변수의 값을 보여주는 정보를 화면에 표시하십시오. 문제가 나타 났을 때 공장 직원조차도 정보를 읽을 수있었습니다.

일반적으로 정확하게 고정하기 위해 몇 번의 수정이 필요했지만 매우 효과적이었습니다.