Bug de temps en temps, mais haute priorité

Je travaille sur un projet CNC (commande numérique par ordinateur) qui découpe des formes en métal à l'aide d'un laser.

Maintenant, mon problème est de temps en temps (1-2 fois en 20 jours impairs), la coupe se passe mal ou non selon ce qui est défini.

Mais cela entraîne une perte et le client n'est donc pas très content.

J'ai essayé d'en découvrir la cause en

1. Y compris les fichiers journaux
2. Débogage
3. Répétition du même environnement.

Mais ça ne se répétera pas.

Une opération de pause et de poursuite le fera fonctionner à nouveau sans que le bogue réapparaisse.

Comment puis-je résoudre ce problème? Dois-je le signaler comme un problème matériel?

Contournements

Comme le suggère ChrisF , la solution pragmatique à court terme peut être d'utiliser l' astuce pause et reprise , mais vous devez parler à vos clients pour savoir quelles devraient être vos priorités. Par exemple:

• Si le défaut détruit une pièce de 1000 £ ou provoque 4 heures d'arrêt une fois par semaine, alors que le correctif de pause-reprise réduit la production de 1%, ils préféreront probablement le correctif dès maintenant.

• Si le défaut détruit une pièce de 1 £ ou provoque 4 minutes d'arrêt une fois par semaine, mais que le correctif de pause-reprise réduit la production de 1%, ils préféreront probablement attendre un correctif qui n'affecte pas le taux de production.

Ayant travaillé dans l'industrie du micro-usinage laser pendant de nombreuses années, je sais à quel point vous pouvez être sous pression pour optimiser le processus et faire en sorte que votre machine produise autant de pièces par heure que possible, donc de toute façon vous allez être sous pression pour résoudre correctement le problème.

Enregistrement

D'après mon expérience, le seul moyen de retrouver efficacement un Heisenbug est une journalisation abondante. Connectez tout dans et autour de la partie du code qui pourrait être responsable de l'erreur. Apprenez à lire efficacement vos fichiers journaux, assurez-vous de surveiller l' erreur suivante sur vos moteurs (vos étapes se déplacent-elles là où elles devraient quand elles le devraient?). Regardez l'utilisation de la mémoire sur la machine, une fuite de mémoire provoque-t-elle la famine d'un processus critique?

Assurez-vous que vous enregistrez également les actions des utilisateurs, êtes-vous sûr que l'opérateur ne frappe pas l'arrêt d'urgence afin qu'il puisse sortir pour une pause-cigarette sournoise pendant qu'il est en cours de réparation? J'ai vu ça arriver!

Analyse statique

Recherchez également des corrélations entre le traçage de certains modèles et le déclenchement plus ou moins fréquent du bogue. Si vous pouvez trouver des modèles qui déclenchent le problème plus fréquemment (ou ne le déclenchent jamais), cela peut indiquer votre problème.

Essayez de créer des motifs qui déclenchent le problème encore plus fréquemment. Si vous pouvez trouver un moyen de déclencher le problème de manière fiable, vous êtes à mi-chemin d'une solution.

Autres options

Enfin, ne tardez pas à blâmer le matériel, mais ne supposez jamais qu'il est parfait. Plusieurs fois, on m'a blâmé pour des problèmes qui se sont avérés être de nature électrique ou mécanique, donc vous devez toujours avoir cela à l'esprit.

Même si vous n'avez normalement pas accès à la machine, n'oubliez pas que certains problèmes ne peuvent être résolus efficacement que sur la machine. Parfois, quelques jours sur site peuvent valoir des semaines via un bureau à distance et des mois hors ligne. Si vous manquez d'options hors ligne, n'hésitez pas à proposer une visite du site, ils ne peuvent que dire non.

Vous pouvez également consulter les questions et réponses de Que faites-vous avec un heisenbug? et que faire des bugs qui ne font pas de reproches? mais cela pourrait ne pas être si utile pour votre situation.

Je vais faire une suggestion décalée.

Allez au directeur d'usine et demandez à voir les enregistrements du moniteur de ligne électrique pour cet outil, ou cette zone, pour les moments où les dysfonctionnements se sont produits. Demandez-lui également s'il y a eu des soudures ou toute autre activité inhabituelle à cette époque.

Il y a plusieurs décennies, mon père passait beaucoup de temps avec un mini-ordinateur qui plantait sans raison. Ils ont appelé le représentant client du fabricant.

Le représentant est entré dans leur bureau, dans la zone de l'usine, et a branché un voltmètre dans le mur, à côté du mini, puis a dit "Regardez ça".

Quelques minutes plus tard, le voltmètre s'est soudainement affaissé, de manière significative, puis est revenu. Le représentant a dit: "C'est lui qui a frappé son arc d'essai. Attendez une minute." Peu de temps après, le voltmètre s'est à nouveau affaissé, et cette fois il est resté affaissé.

Le représentant a dit: "C'est votre problème. Vous avez un gars qui soude sur le sol de l'usine, et il est sur la même jambe électrique que vous. Je l'ai vu s'installer alors que j'entrais."

Ils ont dû exécuter une alimentation électrique complètement séparée pour le bureau.

Le problème est réel et a de réelles conséquences pour l'utilisateur - c'est-à-dire un travail ruiné, etc. Cependant, il ne doit pas être corrigé "correctement". Vous déclarez:

Une opération de pause et de poursuite le fera à nouveau fonctionner sans problème avec la réapparition du bogue.

Dans ce cas, faites-le. Le client sera heureux de ne pas gaspiller de matériel lors de cycles défectueux, même si les cycles normaux prennent quelques secondes de plus.

Évidemment, à long terme, vous devrez peut-être résoudre ce problème "correctement", mais pour le moment, réduisez vos pertes, optez pour la solution de contournement et passez à autre chose.

J'ai eu un bug dans un jeu qui ne s'est produit qu'une seule fois sur un milliard. Heureusement, cela signifiait que je le voyais toutes les 15 à 30 minutes, mais parcourir le code dans le débogueur n'allait pas fonctionner. J'ai fini par mettre des messages de débogage. Ils avaient besoin d'utiliser des instructions if fantaisistes parce que je ne voulais quelque chose qu'en cas de problème. Dans la plupart des cas, le code de débogage répétait les calculs dans le code normal mais en utilisant différentes techniques. Les répétitions n'avaient pas besoin d'être précises. Si je savais qu'un nombre devrait toujours être inférieur à 10 000 et qu'il semblait atteindre 150 000 à l'occasion, je vérifierais simplement une valeur supérieure à 100 000. Chaque fois que le bogue se produisait, j'étudiais mes résultats, concevais des messages de débogage plus élaborés (ou plus précisément, des vérifications plus élaborées pour voir si je devais afficher un message), et j'attendais que le problème se reproduise.

Vos cycles vont être beaucoup plus longs que les miens, mais vous finirez par résoudre le problème. J'espère que vous pouvez trouver la solution par une autre méthode plus rapide, mais cela finira par l'attraper si rien d'autre ne le fait, et vous donnera le sentiment que vous faites quelque chose jusqu'à ce que vous trouviez une meilleure idée.

(Au cas où cela serait utile, j'ai finalement résolu mon problème en nettoyant les quelques lignes de code que j'ai finalement identifiées comme étant le problème. Je jure qu'il n'y avait rien de mal à cela, mais je pense que l'optimiseur et le CPU réorganisaient les instructions pour performances, et je pense que de temps en temps, ils prenaient des chances d'obtenir un peu de vitesse supplémentaire. Même un seul cœur multi-processus ces jours-ci, et je pense que de temps en temps, un grand registre a été lu avant d'être écrit. J'ai changé tous les calculs pour travailler avec des variables locales. Les valeurs du "champ d'instance" ont été déplacées vers les variables locales dès le début, et les valeurs locales n'ont été reculées qu'à la toute fin, à l'intérieur des blocs de synchronisation. Et j'ai utilisé une valeur locale pour le méthode retourne la valeur plutôt que le "champ d'instance"J'avais utilisé.)

Règle 1 numéro un du débogage: vous avez besoin d'un scénario reproductible .

Si vous n'en avez pas, vous devez d'abord y travailler. Pouvez-vous reproduire ce bug dans une sorte de "mode de simulation" de la machine, où aucun métal n'est réellement coupé? Cela semble logique ici. Pouvez-vous exécuter plusieurs programmes de coupe différents rapidement et automatiquement, simulant le processus de 20 jours en quelques minutes? Cela peut augmenter la probabilité d'apparition du problème.

Ensuite, lorsque vous avez un tel scénario, l'étape suivante consiste à rassembler autant d'informations que possible et à commencer réellement le débogage.

Je ne sais pas dans quelle langue cela est exécuté, mais si je rencontre des bugs erratiques dans mon code (C ++), j'utiliserai un outil comme valgrind ou cppcheck pour m'assurer que rien ne se passe en mémoire.

Une extension de la réponse de RalphChapin:

Au fil des ans, j'ai dû chasser un bon nombre de bogues qui ne se manifestaient que sur des systèmes que je ne pouvais pas dupliquer à cause du matériel connecté.

En plus de me connecter comme un fou, j'ai trouvé utile une autre chose: mettre des informations à l'écran montrant où se trouvait le code et les valeurs de certaines variables pertinentes. Lorsque le problème est apparu, même les ouvriers de l'usine pouvaient me lire les informations.

Il fallait généralement quelques rondes de raffinement pour le définir avec précision, mais c'était très efficace.