Bug de vez em quando, mas de alta prioridade

Estou trabalhando em um projeto CNC (controle numérico por computador) que corta formas em metal com a ajuda do laser.

Agora, meu problema é de vez em quando (1-2 vezes em 20 dias ímpares), o corte dá errado ou não, de acordo com o que está definido.

Mas isso causa perda e o cliente não fica muito feliz com isso.

Eu tentei descobrir a causa disso

1. Incluindo arquivos de log
2. Depuração
3. Repetindo o mesmo ambiente.

Mas isso não se repete.

Uma operação de pausa e continuar fará com que funcione sem problemas, sem que o bug reapareça.

Como faço para resolver esse problema? Devo declarar isso como um problema de hardware?

Soluções alternativas

Como ChrisF sugere, a solução pragmática de curto prazo pode ser usar o truque de pausa e retomar , mas você precisa conversar com seus clientes para saber quais devem ser suas prioridades. Por exemplo:

• Se a falha interromper uma parte de £ 1000 ou causar 4 horas de inatividade uma vez por semana, enquanto a correção de pausa / retomada reduzir a produção em 1%, provavelmente a preferência será a correção no momento.

• Se a falha interromper uma parte de £ 1 ou causar 4 minutos de inatividade uma vez por semana, mas a correção de pausa / retomada reduzir a produção em 1%, provavelmente eles preferem esperar uma correção que não afeta a taxa de produção.

Tendo trabalhado na indústria de micro-usinagem a laser por muitos anos, eu sei quanta pressão você pode estar sofrendo para otimizar o processo e fazer com que sua máquina produza o máximo possível de peças por hora, para que, de qualquer maneira, você esteja sob pressão para corrigir o problema corretamente.

Exploração madeireira

Na minha experiência, a única maneira de rastrear efetivamente um Heisenbug é o log copioso. Registre tudo dentro e ao redor da parte do código que pode ser responsável pelo erro. Aprenda a ler seus arquivos de log de maneira eficaz, verifique se você está monitorando os seguintes erros nos seus motores (os estágios estão se movendo para onde deveriam quando deveriam?). Observe o uso de memória na máquina. Um vazamento de memória está causando a fome de um processo crítico?

Verifique também se está registrando ações do usuário, se o operador não está pressionando a parada de emergência para que possa fazer uma pausa de cigarro enquanto ela está sendo consertada? Eu já vi isso acontecer!

Análise estática

Além disso, procure correlações entre escrever certos padrões e o bug ser acionado com mais ou menos frequência. Se você puder encontrar padrões que acionam o problema com mais frequência (ou nunca o acionam), isso pode indicar seu problema.

Tente criar padrões que acionem o problema com mais frequência. Se você puder encontrar uma maneira de acionar o problema de maneira confiável, estará na metade do caminho para uma solução.

Outras opções

Por fim, não seja rápido em culpar o hardware, mas nunca assuma que é perfeito. Muitas vezes fui acusado de problemas que se revelaram de natureza elétrica ou mecânica, então você sempre deve ter isso no fundo da sua mente.

Mesmo que você normalmente não tenha acesso à máquina, lembre-se de que alguns problemas só podem ser resolvidos com eficiência na máquina. Às vezes, alguns dias no local podem valer semanas via área de trabalho remota e meses completamente off-line. Se você ficar sem opções off-line, não tenha medo de propor uma visita ao site, eles podem apenas dizer não.

Você também pode consultar as perguntas e respostas para O que você faz com um heisenbug? e O que fazer com erros que não são reproduzidos? mas isso pode não ser tão útil para a sua situação.

Vou fazer uma sugestão inusitada.

Vá ao gerente da fábrica e peça para ver os registros do monitor da linha de energia dessa ferramenta ou dessa área, para os horários em que ocorreram problemas de funcionamento. Também pergunte a ele se houve alguma soldagem ou qualquer outra atividade incomum naquela época.

Várias décadas atrás, meu pai estava se divertindo muito com um minicomputador que estava travando sem motivo algum. Eles ligaram para o representante do cliente do fabricante.

O representante entrou em seu escritório, na área da fábrica, e conectou um voltímetro na parede, ao lado do mini, e disse: "Veja isto".

Alguns minutos depois, o voltímetro caiu repentinamente, significativamente, depois voltou. O representante disse: "Foi ele que fez seu teste. Espere um minuto." Pouco tempo depois, o voltímetro caiu novamente e, desta vez, ficou quieto.

O representante disse: "Esse é o seu problema. Você tem um cara que está soldando no chão da fábrica e ele está na mesma perna de força que você. Eu o vi montando quando eu estava entrando".

Eles tiveram que executar um fornecimento de energia completamente separado para o escritório.

O problema é real, com consequências reais para o usuário - ou seja, trabalho arruinado, etc., portanto, ele precisa ser corrigido. No entanto, não precisa ser corrigido "corretamente". Você declara:

Uma operação de pausa e continuação fará com que funcione sem problemas com o bug reaparecendo.

Nesse caso, basta fazer isso. O cliente ficará feliz por não estar desperdiçando material em execuções defeituosas, mesmo que as execuções normais demorem mais alguns segundos.

Obviamente, a longo prazo, você pode precisar corrigir isso "adequadamente", mas, por enquanto, reduza suas perdas, siga a solução alternativa e entre em outra coisa.

Eu tive um bug em um jogo que aconteceu apenas 1 vez em um bilhão. Felizmente, isso significava que eu estava vendo a cada 15 a 30 minutos, mas percorrer o código no depurador não estava funcionando. Acabei colocando mensagens de depuração. Eles precisavam usar declarações if sofisticadas, porque eu só queria algo quando havia um problema. Na maioria dos casos, o código de depuração repetia os cálculos no código regular, mas usando técnicas diferentes. As repetições não precisavam ser precisas. Se eu soubesse que um número sempre deveria estar abaixo de 10.000 e parecia atingir 150.000 de vez em quando, eu apenas verificaria um valor acima de 100.000. Cada vez que o bug ocorria, eu estudava meus resultados, desenvolvia mensagens de depuração mais elaboradas (ou mais precisamente, verificações mais elaboradas para ver se eu deveria exibir uma mensagem) e aguardava o problema surgir novamente.

Seus ciclos serão muito mais longos do que os meus, mas você acabará se aproximando do problema. Espero que você possa encontrar a solução por algum outro método mais rápido, mas isso acabará por resolver se nada mais acontecer, e lhe dará a sensação de que você está fazendo algo até ter uma idéia melhor.

(Caso seja útil, finalmente resolvi meu problema limpando as poucas linhas de código que finalmente identifiquei como o problema. Jurarei que não havia nada errado com elas, mas acho que o otimizador e a CPU estavam reorganizando as instruções para desempenho, e acho que de vez em quando eles estavam se arriscando a ganhar velocidade extra.Mesmo um único núcleo se multi-processa nos dias de hoje, e eu acho que tudo de vez em quando um registro é lido antes de ser gravado. Alterei todos os cálculos para trabalhar com variáveis ​​locais. Os valores do "campo da instância" foram movidos para variáveis ​​locais logo no início, e os valores locais foram retornados apenas no final, dentro dos blocos de sincronização. E usei um valor local para o valor de retorno do método em vez do "campo da instância"Eu estava usando.)

Regra 1 número um na depuração: você precisa de um cenário reproduzível .

Se você não tiver um, deve trabalhar nisso primeiro. Você pode reproduzir esse bug em algum tipo de "modo de simulação" da máquina, onde nenhum metal é realmente cortado? Isso parece fazer sentido aqui. Você pode executar vários programas de corte diferentes de maneira rápida e automática, simulando o processo de 20 dias em alguns minutos? Isso pode aumentar a probabilidade do problema aparecer.

Então, quando você tiver esse cenário, a próxima etapa é coletar o máximo de informações possível e iniciar a depuração.

Não sei em qual idioma isso é executado, mas se houver erros irregulares no meu código (C ++), usarei uma ferramenta como valgrind ou cppcheck para garantir que nada ocorra na memória.

Uma extensão da resposta de RalphChapin:

Ao longo dos anos, tive que caçar um número razoável de bugs que só apareciam em sistemas que não conseguia duplicar por causa do hardware conectado.

Além de registrar como louca outra coisa, achei útil: Colocar informações na tela mostrando onde estava o código e os valores de algumas variáveis ​​relevantes. Quando o problema apareceu, até os trabalhadores da fábrica puderam ler as informações para mim.

Geralmente, eram necessárias algumas rodadas de refinamento para identificá-lo exatamente, mas era muito eficaz.