Definição controlada de alarmes e códigos de evento em equipamentos de impressão 3D

Introdução: o mesmo alarme, três respostas em três turnos

Uma máquina de fusão em leito de pó metálico apresentou repetidamente, no turno noturno, o aviso de «teor de oxigénio elevado»: a equipa A continuou a imprimir com base na experiência, a equipa B parou a máquina para purgar novamente o gás e a equipa C simplesmente executou o reset. Os três registos descrevem o mesmo fenómeno, mas nenhum responde a perguntas como «a que código de evento corresponde este aviso, qual é o limiar de disparo, é permitido continuar a impressão e é necessária uma nova verificação após o reset?». Ao executar projetos de ciclo de vida completo, desde o projeto até à entrega física, a lantu3D verificou que as oficinas geralmente não carecem de sensores nem de listas de inspeção; falta-lhes uma tabela de códigos controlada que traduza os eventos brutos produzidos pelo controlador do equipamento em ações determináveis. Este artigo não aborda «como reparar o equipamento», mas uma camada anterior: como numerar e classificar alarmes e códigos de evento, como vinculá-los a ações de interbloqueio, como controlar a supressão e o reset e como congelá-los por versão de firmware, para que o mesmo evento receba sempre o mesmo tratamento em qualquer turno.

I. Definir primeiro os limites: códigos de alarme, sintomas de falha e eventos de qualidade não pertencem à mesma tabela

Primeiro, separe três objetos que são facilmente confundidos. Um código de alarme é um identificador estruturado produzido bit a bit ou por palavra pelo sistema de controlo do equipamento; a sua semântica é definida pela tabela de códigos e deve ser única, estável e legível por máquina. Um sintoma de falha é uma descrição observada pelo operador, como «há estrias no espalhamento de pó»; pertence à linguagem natural e vários sintomas podem apontar para o mesmo código. Um evento de qualidade é uma determinação posterior do impacto na peça, como «este build deve ser isolado para inspeção», e pertence ao nível de liberação. Os pontos de medição de três níveis para qualidade de energia e registo de formas de onda, o mapeamento entre modos de falha, indicadores de monitorização e limiares na manutenção preditiva, e os três estados normal/anormal/requer nova inspeção na verificação de equipamentos são todos métodos que consomem um tipo de evento para tomar outra decisão; eles não definem «de onde vem o código, como os domínios de código são divididos ou o que acontece aos registos antigos quando um código muda». A pergunta para delimitar esta camada é: este conteúdo explica “como calcular uma conclusão depois de receber um sinal” ou “como esse sinal se chama quando é gerado, a que nível pertence e que ação pode acionar”? Apenas o que pode ser concretizado em «um código, uma tabela de classificação, uma regra de interbloqueio e um registo de congelamento de versão» pertence à camada de engenharia de tabelas de códigos.

II. Divisão de domínios de código: dar a cada evento uma identidade que nunca é reutilizada

Recomenda-se uma codificação de comprimento fixo em cinco segmentos: E-<família de equipamento, 2 dígitos>-<subsistema, 2 dígitos>-<número sequencial, 3 dígitos>-<nível, 1 dígito>. Por exemplo, LP-GS-0217-3 representa o evento número 217 do subsistema de espalhamento de pó/gás, com severidade de nível 3. As famílias de equipamento são divididas por plataforma de processo (LP, leito de pó a laser; BJ, jato de ligante; PJ, fotopolimerização; DE, deposição por energia direcionada); os subsistemas são divididos por domínio funcional (GS, circuito de gás e teor de oxigénio; RC, espalhamento de pó e lâmina; LS, laser e percurso ótico; TH, pré-aquecimento da placa; MT, movimento e servos; PW, alimentação elétrica e utilidades; CT, controlo e comunicações). Para cada código, a tabela deve consolidar pelo menos oito campos: código único, descrição-padrão em chinês e inglês, expressão da condição de disparo, nível predefinido, ação de interbloqueio predefinida, condições operacionais permitidas, primeira versão de firmware em que entrou em vigor e posto responsável pelo tratamento. Depois de atribuído, um número sequencial nunca pode ser reutilizado; um evento descontinuado deve apenas ser marcado como deprecated e preservar o mapeamento histórico. É proibido atribuir um número antigo a um novo significado, caso contrário um registo de qualidade de três anos atrás poderá ser interpretado, numa consulta posterior, como um evento completamente diferente.

III. Classificação e interbloqueio: matriz de ações em quatro estados, do «aviso» à «paragem de segurança»

Recomendam-se quatro níveis de severidade, vinculando cada nível a uma única ação predefinida para evitar decisões discricionárias no local: S1, informação (apenas registado no log de eventos, sem interromper a fabricação, como um aviso de que a pressão diferencial do filtro se aproxima da necessidade de substituição); S2, alerta (a fabricação é mantida, mas com redução de velocidade ou marcação, como quando o oxigénio na câmara sobe para a faixa de 800–1000 ppm, prolongando automaticamente a purga entre camadas e marcando a camada); S3, retenção do processo (pausa o espalhamento de pó, mantém o número da camada atual e a atmosfera inerte, como quando o oxigénio é >1000 ppm durante ≥2 s ou a potência real do laser se desvia ±8% do valor definido por mais de 3 camadas); antes de retomar a impressão, deve-se rever o estado de fusão das 3 camadas anteriores e das 3 posteriores ao número da camada; S4, paragem de segurança (corta a saída do laser, mantém a circulação de gás e isola diretamente o build, como em caso de interrupção do gás de proteção, acionamento do interbloqueio da porta da câmara ou atuação do circuito de paragem de emergência). O reset automático e a supressão são sempre proibidos para S4. A matriz de ações deve ser redigida com seis colunas: «nível → interrompe ou não → mantém ou não a atmosfera → isola ou não o build → requer ou não verificação da primeira peça → posto a notificar», e publicada após aprovação conjunta das áreas de processo, equipamento e qualidade.

IV. Debounce, condições de disparo e snapshot de evidências: tornar cada evento recalculável

A condição de disparo não pode dizer apenas «oxigénio elevado»; deve ser expressa de forma recalculável: variável comparada / operador de comparação / limiar / duração / banda de histerese / condição de ativação. Por exemplo, para o teor de oxigénio, usar limiar de 1000 ppm, duração de 2 s, banda de histerese de 5% (só é desativado quando cai abaixo de 950 ppm) e ativação apenas nos modos de fabricação e pré-aquecimento; não avaliar nos modos de espera e manutenção. Para o desvio da potência do laser, usar ±8%, 3 camadas consecutivas e debounce com período de amostragem de 100 ms; confirmar apenas após três ciclos consecutivos válidos, enquanto picos instantâneos de <50 ms são registados como transientes sem escalonamento. Cada evento confirmado deve gerar um snapshot de evidências com dez campos fixos: código de evento, carimbo de tempo (sincronizado com o relógio do equipamento, desvio ≤1 s), número da camada no momento, valor real da potência do laser, posição do eixo de espalhamento de pó, teor de oxigénio e ponto de orvalho, hash do pacote de parâmetros, versão da tabela de códigos, versão do firmware e identificação do operador. Devem também ser preservadas as formas de onda das variáveis críticas nos 200 ms anteriores e em 1 s posterior ao evento. Sem esse snapshot, não é possível determinar posteriormente os limites do impacto do evento, e a conclusão de liberação para S3/S4 fica sem fundamento.

V. Supressão, reset e bypass temporário: colocar as exceções numa estrutura de autorização

Existem necessidades legítimas de supressão no local, como durante a calibração de um analisador de oxigénio, mas elas devem ser controladas por engenharia: a supressão só é permitida para S1–S3 e é permanentemente proibida para S4; o pedido deve indicar o código, a justificação, o meio de monitorização alternativo e o prazo de validade; recomenda-se um prazo ≤8 horas ou ≤1 build, prevalecendo o que ocorrer primeiro, com expiração automática; a execução requer autorização dupla das áreas de equipamento e qualidade. Durante a supressão, todos os eventos devem continuar a ser registados normalmente, acrescentando-se apenas suppressed=true e o número da autorização; os eventos nunca devem ser descartados silenciosamente. O reset também não é simplesmente pressionar um botão: antes do reset de S3/S4, é obrigatório preencher o código de causa-raiz, correspondente a uma entrada do dicionário de falhas, e identificar o responsável pela ação. Após o reset, deve-se validar uma amostra-padrão da primeira peça e rever falta de fusão e porosidade nas 3 camadas anteriores e nas 3 posteriores à camada do evento. O isolamento do build só pode ser removido quando os quatro registos estiverem completos. Recomenda-se incluir no painel mensal os indicadores «taxa de supressão ≤1% dos builds», «proporção de eventos não classificados ≤2%», «mais de 5 repetições da mesma causa-raiz em 1 hora gera automaticamente uma ordem de trabalho de causa-raiz» e «integridade evento–snapshot ≥99%».

VI. Congelamento de versões e alterações: para onde vão os códigos antigos após uma atualização de firmware?

A tabela de códigos é um documento controlado, não uma folha de cálculo Excel que pode ser alterada livremente. Cada publicação deve gerar um número de versão, hash SHA-256, data de entrada em vigor, lista de números de série de equipamentos aplicáveis e versão mínima de firmware; esses dados devem ser vinculados por uma chave tripla à versão do pacote de parâmetros e ao número do build, sendo gravados na cadeia de evidências de entrega. A inclusão ou revisão de um código deve seguir uma solicitação de alteração: análise de impacto (quais registos históricos, cartões de trabalho e lógicas de interbloqueio são afetados) → revisão tripartida → mapeamento entre códigos antigos e novos → transição na data de entrada em vigor → invalidação dos cartões de trabalho antigos. Antes e depois de uma atualização de firmware, é obrigatório executar uma comparação de consistência da tabela de códigos: verificar item a item se o número, o nível e a descrição efetivamente emitidos pelo controlador correspondem à versão controlada atual. Em caso de divergência, a liberação para operação do equipamento deve ser bloqueada. Recomenda-se conservar as tabelas de códigos históricas e os logs de eventos pelo menos durante a vida útil do produto, acrescida de 3 anos, com arquivamento em modo somente leitura.

VII. Lista de verificação de implementação e erros comuns

A implementação pode avançar em 30 dias: na semana 1, exportar a lista completa de eventos do controlador, recodificá-la segundo o formato de cinco segmentos e estabelecer o registo dos domínios de código; na semana 2, concluir a matriz de ações de quatro níveis e as expressões de condição de disparo, acrescentando debounce e banda de histerese; na semana 3, integrar automaticamente os dez campos do snapshot de evento com o hash do pacote de parâmetros e o número da camada; na semana 4, realizar um exercício de consulta retrospetiva de 30 minutos — selecionar aleatoriamente um evento S3 de três meses antes e exigir a reconstrução da versão da tabela de códigos, condição de disparo, snapshot e conclusão de liberação vigentes naquele momento, com meta de taxa de sucesso ≥95%. Há quatro erros comuns: escrever códigos de alarme como descrições em linguagem natural, impossibilitando a leitura por máquina; definir apenas o limiar, sem duração nem condição de ativação, causando uma enxurrada de alarmes falsos em manutenção; deixar de registar diretamente os eventos durante a supressão, quebrando a cadeia de evidências; e continuar a usar a tabela de códigos antiga após uma atualização de firmware, misturando significados antigos e novos.

Conclusão

A definição controlada de alarmes e códigos de evento do equipamento é a engenharia fundamental que traduz «o que a máquina disse» em «o que a oficina deve fazer». Ela não substitui o cálculo de consumo energético, a gestão da qualidade de energia, a manutenção preditiva ou a gestão de lotes de inspeção; em vez disso, fornece a esses métodos um dicionário de entrada estável, recalculável e rastreável. Para plataformas que abrangem toda a cadeia, do projeto, processo e fabricação até à entrega física, apenas garantindo que cada código seja único, cada nível tenha uma única ação, cada exceção deixe um registo e cada versão possa ser congelada será possível transformar um aviso do turno noturno num facto de engenharia que conduz à mesma conclusão em qualquer turno.