Reparação ou troca de uma HMI: que evidências enviar ao parceiro

Um banco de reparação recebe o seu painel como uma caixa com uma história anexada, e a história começa pela identidade. O trio de identidade é o número de artigo completo e a revisão exatamente como impressos, uma fotografia nítida da etiqueta traseira, e uma fotografia da moldura. Para um PanelView Plus 7 isso significa a cadeia 2711P completa como 2711P-T7C22D9P, não uma referência 2711P abreviada. Um banco que recebe a variante errada perde um ciclo completo de diagnóstico.

Esquema do sistema ampliado

×

Três fontes de evidência convergem numa identificação de variante. A identidade vem primeiro, o diagnóstico vem depois.

Porque é que a cadeia completa importa tanto no banco: o bloco final separa pacotes de hardware e de opções, e o banco precisa deles para reproduzir a unidade corretamente. Dois terminais que parecem iguais por fora podem querer cabos de ecrã diferentes, películas diferentes, ou passos de firmware diferentes. A cadeia é a única forma fiável de saber que unidade foi aberta na bancada.

Se a etiqueta estiver ilegível, use uma fotografia da página de diagnóstico e diga-o. A maioria dos painéis imprime no ecrã o número de artigo exato e a versão de firmware, e essa fotografia mais uma nota sobre porque a etiqueta falhou valem mais do que uma referência adivinhada. O que o banco não aceita em silêncio é um número confiante que afinal pertence a outra unidade.

Um limite pertence ao início. O trio de identidade diz ao banco o que ele tem à mão. Não diz ao banco o que está estragado, e não compromete ninguém com um resultado de reparação. Isso vem do registo de sintomas e das verificações que o banco executa.

O registo de sintomas descreve o que mudou, quando mudou, e o que ainda funciona. Mantenha os sintomas de toque, imagem e alimentação separados, como mostra o guia de sintomas ligado, porque apontam para componentes diferentes. Escreva-o como uma lista curta, não como uma história. O banco lê listas; uma narrativa obriga a reler tudo duas vezes.

Esquema do sistema ampliado

×

Dois fluxos chegam ao banco: o que o painel faz e quando começou. Nenhum fluxo prova uma peça falhada.

Inclua quaisquer testes de isolamento que já executou, com os resultados. Uma verificação com rato USB que moveu o cursor enquanto a camada tátil continuava morta, ou um teste com lanterna que mostrou conteúdo ténue num ecrã escuro, cortam cada um um ramo inteiro do diagnóstico. Dê o resultado e a data, e marque a sua conclusão como provisória em vez de a fundir na observação.

As datas pesam mais do que parecem. Uma avaria que apareceu após um corte de energia, uma limpeza do armário, ou uma trovoada lê-se de forma diferente de uma que se instalou ao longo de meses. O banco vê muitos painéis por semana, e um histórico datado permite comparar a sua unidade com casos semelhantes com honestidade.

Uma disciplina mantém o registo útil: nunca resuma fora um detalhe que pareceu irrelevante. Um comportamento de arranque estranho que parou sozinho, uma avaria que só aparece quando o armário está quente, ou uma mensagem que apareceu uma vez pode ser o detalhe que poupa um dia de diagnóstico. As listas são baratas. Deixar coisas de fora é caro.

As notas de ambiente respondem às perguntas que o banco não pode fazer à sua máquina. Como está montado o painel, e que temperatura e limpeza o armário vive? Um painel de uma linha alimentar com lavagem conta uma história diferente de um de uma sala de comando seca, mesmo com sintomas idênticos. Duas frases transportam a maior parte disto.

Esquema do sistema ampliado

×

Três fluxos de histórico moldam expectativas. Informam a inspeção, não predefinem o seu veredicto.

O histórico de reparações anteriores também pertence ao dossier. Se o painel já foi reparado, diga por quem e o que foi substituído. Um banco que abre uma unidade com peças não originais orça o trabalho de forma diferente, e uma reparação anterior pode explicar uma avaria que de resto não faz sentido para aquele modelo. Se o painel veio de um sobressalente de prateleira, registe quanto tempo esteve armazenado e onde.

As condições de armazenamento explicam alguns sintomas de unidade morta à chegada, e é por isso que a pergunta do sobressalente de prateleira existe de todo. Uma unidade guardada dez anos num armazém sem aquecimento tem condensadores diferentes de uma guardada num depósito climatizado. Os bancos vêem isto com frequência, por isso a nota vale o minuto que leva.

O limite das notas de histórico: informam a inspeção, não a decidem. Uma reparação anterior não faz o banco culpar as peças velhas, e um ambiente agressivo não reserva uma causa. Escreva o que aconteceu, e deixe a unidade aberta confirmar ou limpar.

A classe de avaria move a recomendação mais do que qualquer outra coisa que enviar. Uma retroiluminação falhada ou uma camada tátil resistiva desgastada num Comfort Panel é uma reparação de componente definida. Uma unidade que liga sem qualquer ecrã pode ser uma avaria de placa principal ou de alimentação. Um painel inundado ou queimado normalmente não compensa reparar. Registe a que classe a evidência aponta, e marque-a provisória.

Esquema do sistema ampliado

×

As classes ramificam a recomendação. Atribua uma provisoriamente a partir da evidência e deixe o banco confirmá-la.

A classe importa porque muda a primeira hora do banco e as suas expectativas em conjunto. Uma reparação de componente tem uma lista de peças conhecida e um custo limitado. Uma avaria ao nível da placa começa com diagnósticos que podem acabar em qualquer lado. Saber em que conversa está evita tanto a esperança falsa como a substituição prematura de uma unidade reparável.

Quando a classe não está clara, diga o que verificou e o que excluiu. Uma nota como o ecrã fica preto, LED de alimentação aceso, verificação com rato respondeu, logo o runtime corre mas o caminho de imagem falha, dá ao banco uma partida ganha. Uma nota que diz painel morto obriga-os a estabelecer o básico do zero.

Mantenha um limite: a sua estimativa de classe é uma hipótese, não um achado. O banco confirma a classe quando a unidade é aberta, e uma classe provisória bem escrita que afinal se revele errada continua a ser uma boa resposta, porque cada teste documentado lhes diz onde já procurou.

O estado do projeto decide se uma troca é realista, e é por isso que partilha a primeira página do dossier com a identidade. Com uma cópia de segurança verificada, uma unidade de troca pode ser carregada e instalada, e reparar o original torna-se uma questão de sobressalentes. Sem cópia de segurança, o armazenamento do painel guarda a única cópia do projeto da máquina, e as rotas que preservam o armazenamento passam para a frente.

Esquema do sistema ampliado

×

Um facto escrito divide o mapa de rotas. Indique o ramo cedo, e a análise começa no caminho certo.

Diga no pedido que prefere uma rota que preserva o armazenamento, quando é esse o caso. Esta única linha poupa uma ronda inteira de perguntas, porque quem analisa sabe de imediato que uma unidade de substituição virgem, por mais depressa que envie, não resolve o seu problema. A mesma linha também explica porque pode recusar uma oferta de outro modo atractiva.

O estado da cópia de segurança emparelha com o registo da ferramenta. Escreva que ferramenta construiu o projeto e que versão, por exemplo uma aplicação FactoryTalk View Machine Edition arquivada em .apa, ou um projeto TIA Portal. Uma troca carregada a partir de um ficheiro que ninguém consegue abrir não é uma troca, é um segundo painel com o mesmo problema, um passo mais tarde.

Uma fronteira mantém-se aqui também. O estado da cópia de segurança molda a rota, não garante uma. Se a referência exata está disponível para troca, e quanto custa uma reparação que preserva o armazenamento, ficam abertos até o fornecedor os verificar contra fontes atuais.

Feche o dossier com a sua rota preferida e a condição por trás dela. Reparação preferida, troca, fornecimento da referência exata, ou substituição completa iniciam cada uma análises diferentes. Indicar a preferência mais a sua restrição, como sem cópia de segurança do projeto, permite a quem analisa confirmá-la ou contestá-la com evidência. Uma preferência com motivo é analisável. Uma preferência sem explicação costuma ser reaberta mais tarde.

Esquema do sistema ampliado

×

A sequência de fecho transforma evidência num pedido decidível. O resultado fica aberto até o fornecedor o verificar.

Acrescente os números de operação que dimensionam a resposta. A tolerância à paragem e o número de unidades idênticas em serviço mudam ambos o plano mais do que a própria avaria. Uma paragem de linha única sem sobressalente empurra para a opção documentada mais rápida, e um parque da mesma referência torna uma boa reparação valiosa como futuro sobressalente.

Submeta através do formulário de pedido com os ficheiros anexados, e guarde a sua própria cópia de tudo o que enviar. Envie imagens na resolução original em vez de capturas comprimidas, porque os sufixos da etiqueta são o primeiro detalhe a desaparecer na compressão. Fotografias da etiqueta traseira, do estado do ecrã, e das páginas de projeto ou firmware cobrem a maior parte do que o passo seguinte precisa.

O dossier prepara a análise mas não fixa o resultado. Orçamentos, sucesso da reparação e disponibilidade de troca dependem de verificações que o fornecedor executa. Formule o pedido à volta de evidência e preferências em vez de promessas sobre custo ou viabilidade. Um fornecedor que recebe este dossier pode orçamentar, recusar ou redirecionar à primeira passagem em vez de pedir o básico. Esse é todo o objetivo do dossier.

• Envie o número de artigo completo, a revisão, e fotografias nítidas da etiqueta e da moldura.
• Registe sintomas por camada, com resultados de testes e datas.
• Diga se existe uma cópia de segurança de projeto verificada. Ela decide a viabilidade da troca.
• Dê a tolerância à paragem, a contagem do parque instalado, e a sua rota preferida com o motivo.

• a página da categoria de referências HMI
• como registar sintomas de toque e de ecrã
• a lista de verificação da cópia de segurança do projeto