Error de vez en cuando, pero alta prioridad

Estoy trabajando en un proyecto de CNC (control numérico por computadora) que corta formas en metal con ayuda de láser.

Ahora mi problema es de vez en cuando (1-2 veces en 20 días impares) el corte sale mal o no según lo establecido.

Pero esto causa pérdida, por lo que el cliente no está muy contento con eso.

Traté de descubrir la causa de esto

1. Incluyendo archivos de registro
2. Depuración
3. Repetir el mismo ambiente.

Pero no se repetirá.

Una operación de pausa y continuación hará que vuelva a funcionar sin problemas sin que vuelva a aparecer el error.

¿Cómo abordo este problema? ¿Debo decirlo como un problema de hardware?

Trabajar alrededor

Como ChrisF sugiere, la solución pragmática a corto plazo puede ser utilizar el truco de pausa y reanudar , pero debe hablar con sus clientes para saber cuáles deberían ser sus prioridades. Por ejemplo:

• Si la falla destruye una parte de £ 1000 o causa 4 horas de tiempo de inactividad una vez por semana, mientras que la corrección de pausa-reanudación reduce la producción en un 1%, probablemente preferirán la solución en este momento.

• Si la falla destruye una parte de £ 1 o causa 4 minutos de tiempo de inactividad una vez a la semana, pero la solución pausa-reanudación reduce la producción en un 1%, probablemente preferirán esperar una solución que no afecte la tasa de producción.

Después de haber trabajado en la industria del micro maquinado por láser durante muchos años, sé cuánta presión puede estar bajo para optimizar el proceso y hacer que su máquina produzca tantas partes por hora como sea posible, por lo que de cualquier manera estará bajo presión para solucionar el problema correctamente.

Inicio sesión

En mi experiencia, la única forma de rastrear efectivamente un Heisenbug es un registro abundante. Registre todo en y alrededor de la parte del código que podría ser responsable del error. Aprenda a leer sus archivos de registro de manera efectiva, asegúrese de estar monitoreando el siguiente error en sus motores (¿sus etapas se mueven donde deberían cuando deberían?). Mire el uso de memoria en la máquina, ¿hay una pérdida de memoria que causa la falta de un proceso crítico?

Asegúrese de registrar también las acciones de los usuarios, ¿está seguro de que el operador no está presionando la parada de emergencia para que pueda salir por un breve cambio de cigarrillo mientras se está reparando? ¡He visto que esto suceda!

Análisis estático

Además, busque correlaciones entre escribir ciertos patrones y que el error se active con mayor o menor frecuencia. Si puede encontrar patrones que desencadenan el problema con mayor frecuencia (o nunca lo desencadenan), esto puede indicar su problema.

Trate de hacer patrones que desencadenen el problema con mayor frecuencia. Si puede encontrar una manera de desencadenar el problema de manera confiable, entonces está a medio camino de una solución.

Otras opciones

Finalmente, no se apresure a culpar al hardware, pero nunca asuma que es perfecto. Muchas veces me han culpado por problemas que resultaron ser de naturaleza eléctrica o mecánica, por lo que siempre debe tener eso en mente.

Aunque normalmente no tenga acceso a la máquina, recuerde que algunos problemas solo pueden resolverse de manera eficiente en la máquina. A veces, unos pocos días en el sitio pueden valer semanas a través del escritorio remoto y meses completamente fuera de línea. Si te quedas sin opciones fuera de línea, no tengas miedo de proponer una visita al sitio, solo pueden decir que no.

También es posible que desee ver las preguntas y respuestas a ¿Qué hace con un heisenbug? y ¿Qué hacer con los errores que no reprochan? pero estos podrían no ser tan útiles para su situación.

Voy a hacer una sugerencia fuera de lo común.

Diríjase al gerente de fábrica y solicite ver los registros del monitor de la línea eléctrica para esa herramienta, o esa área, para los momentos en que ocurrieron las fallas. Pregúntele también si hubo alguna soldadura, o alguna otra actividad inusual, en esos momentos.

Hace varias décadas, mi padre estaba pasando un mal rato con una minicomputadora que no funcionaba por ningún motivo. Llamaron al representante del cliente del fabricante.

El representante entró en su oficina, en el área de la fábrica, enchufó un voltímetro a la pared, al lado del mini, y luego dijo "Mira esto".

Unos minutos más tarde, el voltímetro se hundió repentinamente, significativamente, luego regresó. El representante dijo "Ese fue él golpeando su arco de prueba. Espere un minuto". Poco después de eso, el voltímetro se hundió nuevamente, y esta vez se mantuvo hundido.

El representante dijo: "Ese es tu problema. Tienes a un tipo soldando en el piso de la fábrica, y él está en la misma pierna que tú. Lo vi preparándose mientras yo entraba".

Tuvieron que ejecutar una fuente de alimentación completamente separada para la oficina.

El problema es real y tiene consecuencias reales para el usuario, es decir, trabajo arruinado, etc., por lo que debe solucionarse. Sin embargo, no tiene que arreglarse "correctamente". Usted declara:

Una operación de pausa y continuación hará que vuelva a funcionar sin problemas con la reaparición del error.

En ese caso solo haz esto. El cliente estará feliz de no estar desperdiciando material en ejecuciones defectuosas, incluso si las ejecuciones normales tardan un par de segundos más.

Obviamente, a largo plazo, es posible que deba solucionar esto "correctamente", pero por el momento reduzca sus pérdidas, siga la solución y busque otra cosa.

Tuve un error en un juego que ocurrió solo 1 vez en mil millones. Afortunadamente, esto significaba que lo veía cada 15 a 30 minutos, pero pasar por el código en el depurador no iba a funcionar. Terminé poniendo mensajes de depuración. Necesitaban usar declaraciones if elegantes porque solo quería algo cuando había un problema. En la mayoría de los casos, el código de depuración estaba repitiendo cálculos en el código regular pero usando diferentes técnicas. Las repeticiones no tenían que ser precisas. Si supiera que un número siempre debe ser inferior a 10,000 y en ocasiones parece llegar a 150,000, solo verificaría un valor superior a 100,000. Cada vez que ocurría el error, estudiaba mis resultados, ideaba mensajes de depuración más elaborados (o más precisamente, comprobaciones más elaboradas para ver si debía mostrar un mensaje), y esperaba que el problema volviera a surgir.

Tus ciclos serán mucho más largos que los míos, pero eventualmente te acercarás al problema. Espero que pueda encontrar la solución por algún otro método más rápido, pero esto lo detectará eventualmente si nada más lo hace, y le dará la sensación de que está haciendo algo hasta que se le ocurra una idea mejor.

(En caso de que sea útil, finalmente resolví mi problema limpiando las pocas líneas de código que finalmente identifiqué como el problema. Juro que no tenían nada de malo, pero creo que tanto el optimizador como la CPU estaban reordenando las instrucciones para rendimiento, y creo que de vez en cuando corrían el riesgo de obtener un poco de velocidad adicional. Incluso un solo multiproceso central en estos días, y creo que cada gran vez de vez en cuando se leía un registro antes de escribirlo. Cambié todos los cálculos para trabajar con variables locales. Los valores del "campo de instancia" se movieron a variables locales justo al comienzo, y los valores locales se movieron hacia atrás solo al final, dentro de los bloques de sincronización. Y utilicé un valor local para valor de retorno del método en lugar del "campo de instancia"Había estado usando)

Regla 1 número uno en depuración: necesita un escenario reproducible .

Si no tienes uno, deberías trabajar en eso primero. ¿Puede reproducir ese error en algún tipo de "modo de simulación" de la máquina, donde no se corta metal realmente? Esto parece tener sentido aquí. ¿Puede ejecutar varios programas de corte diferentes de forma rápida y automática, simulando el proceso de 20 días en unos minutos? Eso puede aumentar la probabilidad de que aparezca el problema.

Luego, cuando tenga tal escenario, el siguiente paso es recopilar tanta información como sea posible y comenzar a depurar.

No estoy seguro de en qué idioma se ejecuta esto, pero si experimento errores erráticos en mi código (C ++), usaré una herramienta como valgrind o cppcheck para garantizar que no ocurra nada en la memoria.

Una extensión de la respuesta de RalphChapin:

A lo largo de los años, tuve que buscar un buen número de errores que solo se mostraban en sistemas que no podía duplicar debido al hardware conectado.

Además de iniciar sesión como loco, otra cosa que encontré útil: poner información en la pantalla que muestra dónde estaba el código y los valores de algunas variables relevantes. Cuando apareció el problema, incluso los trabajadores de la fábrica podían leerme la información.

Por lo general, se necesitaron algunas rondas de refinamiento para precisarlo exactamente, pero fue muy efectivo.