Bug di tanto in tanto, ma alta priorità

Sto lavorando a un progetto CNC (controllo numerico computerizzato) che taglia le forme in metallo con l'aiuto del laser.

Ora il mio problema è di tanto in tanto (1-2 volte in 20 giorni dispari) il taglio va storto o meno secondo quanto impostato.

Ma questo provoca perdita, quindi il cliente non ne è molto contento.

Ho provato a scoprirne la causa

1. Compresi i file di registro
2. Debug
3. Ripetendo lo stesso ambiente.

Ma non si ripete.

Una pausa e l'operazione continueranno a farla funzionare senza intoppi senza la ricomparsa del bug.

Come affrontare questo problema? Devo dichiararlo come un problema hardware?

Aggirare

Come suggerisce ChrisF , la soluzione pragmatica a breve termine potrebbe essere quella di utilizzare la pausa e riprendere il trucco, ma devi parlare con i tuoi clienti per sapere quali dovrebbero essere le tue priorità. Per esempio:

• Se il guasto cede una parte di £ 1000 o causa 4 ore di inattività una volta alla settimana, mentre la correzione di pausa-ripresa riduce la produzione dell'1%, probabilmente preferiranno la correzione in questo momento.

• Se l'errore elimina una parte di £ 1 o causa 4 minuti di inattività una volta alla settimana, ma la correzione di pausa-ripresa riduce la produzione dell'1%, probabilmente preferiranno attendere una correzione che non influisce sulla velocità di produzione.

Lavorando nel settore della microlavorazione laser per molti anni, so quanta pressione puoi essere sotto pressione per ottimizzare il processo e far sì che la tua macchina produca quante più parti all'ora possibile, quindi in entrambi i casi pressione per risolvere correttamente il problema.

Registrazione

Nella mia esperienza, l'unico modo per rintracciare efficacemente un Heisenbug è una registrazione abbondante. Accedi tutto dentro e intorno alla parte del codice che potrebbe essere responsabile dell'errore. Scopri come leggere i tuoi file di registro in modo efficace, assicurati di monitorare i seguenti errori sui tuoi motori (le tue tappe si stanno spostando dove dovrebbero quando dovrebbero?). Guarda l'uso della memoria sulla macchina, una perdita di memoria sta causando la fame di un processo critico?

Assicurati di registrare anche le azioni dell'utente, sei sicuro che l'operatore non stia colpendo l'arresto di emergenza in modo che possano saltar fuori per una pausa di sigarette mentre viene riparato? L'ho visto succedere!

Analisi statica

Inoltre, cerca le correlazioni tra lo scribing di determinati schemi e il bug che viene attivato più o meno spesso. Se riesci a trovare schemi che innescano il problema più frequentemente (o non lo innescano mai), questi potrebbero indicare il tuo problema.

Prova a creare modelli che innescano il problema ancora più frequentemente. Se riesci a trovare un modo per innescare il problema in modo affidabile, sei a metà strada verso una soluzione.

Altre opzioni

Infine, non essere veloce nel dare la colpa all'hardware, ma non dare per scontato che sia perfetto. Molte volte sono stato incolpato di problemi che si sono rivelati di natura elettrica o meccanica, quindi devi sempre averlo nella parte posteriore della tua mente.

Anche se normalmente non si ha accesso alla macchina, ricordare che alcuni problemi possono essere risolti in modo efficiente sulla macchina. A volte alcuni giorni sul posto possono valere settimane tramite desktop remoto e mesi completamente offline. Se esaurisci le opzioni off-line, non aver paura di proporre una visita al sito, possono solo dire di no.

Potresti anche voler esaminare le domande e le risposte a Cosa fai con un heisenbug? e cosa fare con i bug che non vengono riprodotti? ma questi potrebbero non essere così utili per la tua situazione.

Ho intenzione di dare un suggerimento fuori dal comune.

Andare al responsabile della fabbrica e chiedere di vedere i record del monitor della linea di alimentazione per quello strumento o quell'area, per i momenti in cui si sono verificati i malfunzionamenti. Chiedigli anche se ci sono state saldature o altre attività insolite in quei tempi.

Diversi decenni fa, mio ​​padre si divertiva un mondo con un minicomputer che si stava schiantando senza motivo. Chiamarono il rappresentante del produttore.

Il rappresentante entrò nel loro ufficio, nell'area della fabbrica, e collegò un voltmetro al muro, accanto al mini, e poi disse "Guarda questo".

Pochi minuti dopo, il voltmetro si abbassò improvvisamente, in modo significativo, poi tornò. Il rappresentante ha detto "È stato lui a colpire il suo arco di prova. Aspetta un minuto." Poco dopo, il voltmetro si afflosciò di nuovo, e questa volta rimase ceduto.

Il rappresentante ha detto "Questo è il tuo problema. Hai un ragazzo che salda sul pavimento della fabbrica, ed è sulla stessa gamba di potere che sei. L'ho visto sistemarsi mentre stavo entrando."

Hanno dovuto eseguire un alimentatore completamente separato per l'ufficio.

Il problema è reale con conseguenze reali per l'utente - vale a dire lavori in rovina ecc., Quindi deve essere risolto. Tuttavia, non deve essere corretto "correttamente". Tu dichiari:

Una pausa e continua l'operazione farà di nuovo funzionare senza problemi con la ricomparsa del bug.

In tal caso, basta farlo. Il cliente sarà felice di non sprecare materiale in corse difettose anche se le corse normali richiedono un paio di secondi in più.

Ovviamente a lungo termine potrebbe essere necessario risolvere questo problema "correttamente", ma per il momento tagliare le perdite, andare con la soluzione alternativa e prendere qualcos'altro.

Ho avuto un bug in un gioco che è successo solo 1 volta su un miliardo. Fortunatamente, ciò significava che lo vedevo ogni 15-30 minuti, ma non è stato possibile esaminare il codice nel debuggger. Ho finito per inserire messaggi di debug. Avevano bisogno di usare fantasiose dichiarazioni if ​​perché volevo qualcosa solo quando c'era un problema. Nella maggior parte dei casi il codice di debug ripeteva i calcoli nel codice normale ma utilizzava tecniche diverse. Le ripetizioni non dovevano essere precise. Se sapessi che un numero dovrebbe essere sempre inferiore a 10.000 e che a volte sembra colpire 150.000, verificherei solo un valore superiore a 100.000. Ogni volta che si verificava un bug, studiavo i miei risultati, inventavo messaggi di debug più elaborati (o più precisamente, controlli più elaborati per vedere se dovevo visualizzare un messaggio) e aspettavo che il problema si ripresentasse.

I tuoi cicli saranno molto più lunghi dei miei, ma alla fine ti avvicinerai al problema. Spero che tu possa trovare la soluzione con un altro metodo più veloce, ma questo alla fine lo catturerà se non altro, e ti darà la sensazione che stai facendo qualcosa fino a quando non ti viene un'idea migliore.

(Nel caso sia utile, ho finalmente risolto il mio problema ripulendo le poche righe di codice che ho finalmente identificato come problema. Giuro che non c'era niente di sbagliato in esse, ma penso che sia l'ottimizzatore che la CPU stessero riordinando le istruzioni per prestazioni, e penso che ogni tanto prendessero la possibilità di ottenere un po 'di velocità in più. Anche un singolo core multi-processi in questi giorni, e penso che ogni volta sia fantastico leggere un registro prima che fosse scritto. Ho cambiato tutti i calcoli per lavorare con le variabili locali. I valori "Campo istanza" sono stati spostati nelle variabili locali proprio all'inizio e i valori locali sono stati spostati indietro solo alla fine, all'interno dei blocchi di sincronizzazione. E ho usato un valore locale per il metodo restituisce valore anziché il "campo istanza"Stavo usando.)

Regola 1 numero uno nel debug: è necessario uno scenario riproducibile .

Se non ne hai uno, dovresti lavorarci prima. Riesci a riprodurre quel bug in una sorta di "modalità di simulazione" della macchina, dove nessun metallo viene effettivamente tagliato? Questo sembra avere senso qui. Puoi eseguire diversi programmi di taglio in modo rapido e automatico, simulando il processo di 20 giorni in pochi minuti? Ciò può aumentare la probabilità che si verifichi il problema.

Quindi, quando si dispone di uno scenario del genere, il passaggio successivo è raccogliere quante più informazioni possibili e iniziare effettivamente il debug.

Non sono sicuro della lingua in cui viene eseguito, ma se dovessi riscontrare errori irregolari nel mio codice (C ++), userò uno strumento come valgrind o cppcheck per assicurarmi che nulla vada bene per la memoria.

Un'estensione sulla risposta di RalphChapin:

Nel corso degli anni ho dovuto cercare un discreto numero di bug che si mostravano solo su sistemi che non potevo duplicare a causa dell'hardware collegato.

Oltre a registrare come un matto un'altra cosa che ho trovato utile: mettere sullo schermo informazioni che mostrano dove si trovava il codice e i valori di alcune variabili rilevanti. Quando il problema si presentava, anche gli operai della fabbrica potevano leggermi le informazioni.

Di solito ci sono voluti alcuni giri di raffinatezza per fissarlo esattamente, ma è stato molto efficace.