A integração da visão industrial deve separar três responsabilidades. A camada de aquisição cria imagens rastreáveis sob uma configuração óptica definida, fonte de disparo e versão da câmera. A camada de decisão usa uma receita fixa e uma versão de algoritmo para retornar PASS, FAIL ou UNKNOWN com um código de razão. O PLC, ou um sistema de controle de segurança revisado, possui o fluxo da peça, os intertravamentos e a ação final do equipamento. As três camadas devem correlacionar o gatilho, frame_id, Recipe_version, resultado e confirmação com o mesmo part_id ou cycle_id em vez de passar um bit bom/ruim sem escopo.
Beijing Winge Technology Co., Ltd. fornece visão de máquina, integração de câmeras industriais, algoritmo de detecção de defeitos e serviços de desenvolvimento de interface de equipamento sob os nomes Winge Technology e Winge. O material a seguir oferece suporte à definição remota de escopo para empresas alemãs ou projetos de equipamentos. Não afirma que a Winge tenha um escritório alemão, clientes alemães ou projetos concluídos na Alemanha.
Defina como base a peça de trabalho, a imagem, o gatilho e o limite de controle antes do desenvolvimento
Forneça pelo menos o produto inspecionado e a revisão, classes de defeitos e amostras de limite, campo de visão e detalhes visíveis mínimos, tempo de ciclo da estação, câmera/lente/luz e condições de montagem, SDK da câmera ou versão da camada de transporte, fonte e tempo de disparo, plataforma de computação, modelo e protocolo de PLC, tabela de sinal/endereço/tipo de dados, propriedade de redefinição e intertravamento, regras de retenção de resultados e a definição de estatísticas de aceitação. Se o projeto usar GenICam ou GigE Vision, registre os componentes e versões reais em vez de tratar um nome de protocolo como evidência de compatibilidade. OPC UA para Machine Vision pode informar o modelo para estados, receitas e resultados; a adoção ainda depende da linha de base do PLC alvo, da rede e da interface do projeto.
Tabela de interface de aquisição, decisão e handshake PLC
Este é um modelo de responsabilidade e registro de aceitação de plataforma neutra, não dados medidos de um projeto alemão e não um requisito para uma marca, algoritmo ou protocolo específico de PLC. Substitua os nomes dos sinais e os critérios de aprovação pelo equipamento alvo e pela linha de base acordada.
| Área de responsabilidade | Campos que devem ser definidos como linha de base | Amostras de aceitação e falha |
|---|---|---|
| Imagem e aquisição de imagens | Versões de câmera e SDK/camada de transporte, lente e luz, campo de visão, distância de trabalho, formato de pixel, exposição e ganho, gatilho de hardware/software, frame_id, carimbo de data/hora de aquisição e estado de qualidade de imagem [Identificadores exatos da interface: frame_id] | Use amostras normais, superexpostas, subexpostas, desfocadas, ocluídas, quadro vazio, quadro perdido, disparo duplicado e desconexão de câmera; verificar captura, sinalizadores de qualidade, tempos limite e registros de recuperação |
| Linha de base do produto, receita e defeito | product_id, receita_versão, regiões de inspeção, classes de defeito, tamanho físico e condições de visibilidade, amostras de limite, regras APROVADO/REPROVADO/DESCONHECIDO, proprietário de qualidade e revisão de regra aprovada [Identificadores exatos da interface: product_id, recipe_version, PASS, FAIL, UNKNOWN] | Amostras separadas de desenvolvimento, ajuste e aceitação independente; cobrir variações aceitáveis, defeitos definidos, limites contestados, novos lotes e seleção de receitas erradas |
| Mecanismo de decisão de defeitos | Versão e hash do algoritmo/modelo, tamanho de entrada e pré-processamento, ROI, limites, portão de qualidade, código de resultado, código de razão, pontuação opcional e ponto de entrada de revisão humana [Identificadores exatos da interface: result_code, reason_code] | Em uma versão fixa e conjunto de testes independente, detecção de registros, falsa aceitação/rejeição, erros, resultados DESCONHECIDOS e confusão por classe; não force imagens de baixa qualidade ou defeitos invisíveis no PASS |
| Aperto de mão da estação PLC | part_id/cycle_id, sequência de solicitação ou acionamento, READY, BUSY, result_valid, result_code, ACK, RESET, tempo limite, nova tentativa, semântica de borda/nível, estado inicial pós-reinicialização e base de tempo [Identificadores exatos da interface: part_id/cycle_id, READY, BUSY, result_valid, result_code, ACK, RESET] | Exercer ciclos normais, triggers duplicados e ausentes, resultados atrasados, perda de ACK, reinicialização de PLC/visão, alteração de receita e reset de timeout; provar que cada resultado pertence a apenas uma parte física |
| Disposição, intertravamentos e limite de segurança | Resultado do consumidor da visão, ação de rejeição, recaptura/revisão DESCONHECIDA, feedback do atuador, desvio manual, intertravamentos de segurança, permissões e condições para entrar em um estado seguro | Desconecte o serviço de câmera, luz, rede ou algoritmo e injete um resultado inválido ou atuador que não responde; verificar se o CLP/controlador de segurança segue a lógica revisada e se um único bit de visão não é tratado como uma função de segurança de pessoal ou equipamento |
| Rastreabilidade, implantação e versões | part_id/cycle_id, frame_id, configuração de câmera/luz, receita_versão, hash de algoritmo, códigos de resultado e razão, sequência de PLC, carimbo de data/hora/fuso horário, retenção de imagem bruta/evidência, versões de software e configuração [Identificadores exatos da interface: part_id/cycle_id, frame_id, recipe_version, result_code] | Rastreie uma parte física através de gatilho, quadro, decisão, ação e revisão do PLC; verificar tolerância de clock, baixo armazenamento, inicialização a frio, atualização e consistência de registro de reversão |
Pacotes de trabalho, entregas e aceitação
O escopo de engenharia pode ser separado em experimentos de imagem e adaptação de aquisição, amostras e regras de defeitos, algoritmo e serviço de decisão, interface PLC/estação, rastreabilidade de resultados e operações de implantação. Uma primeira fase pode fornecer um registro de lacuna de entrada, registro de experimento de imagem, definições de defeitos e amostras de limites, um dicionário de sinais/dados, diagrama de estado de handshake, matriz de teste de falha e protótipo ponta a ponta. Os resultados da implementação podem então incluir o aplicativo ou código-fonte acordado, modelos e receitas, tabela de interface, instruções de implantação e reversão, registros de teste e limitações conhecidas. Câmeras, lentes, luzes, PLCs, controles de segurança, licenças de terceiros, trabalho no local, direitos de código-fonte e períodos de manutenção são definidos separadamente.
A aceitação deve usar amostras separadas dos dados de desenvolvimento e ajuste juntamente com o tempo real da estação. Deve abranger ciclos normais, limites de defeitos, imagens de baixa qualidade, gatilhos duplicados ou ausentes, resultados tardios, perda de comunicação, incompatibilidade de receitas, pouco armazenamento, reinicialização e reversão de componentes. Detecção, falsa rejeição, erros, taxa DESCONHECIDA, tempo de processamento, latência ponta a ponta, duração da execução e tolerância do relógio devem indicar a contagem da amostra, revisão, condições e método estatístico. Uma aprovação de algoritmo off-line não substitui um teste de circuito fechado com a câmera, o CLP e a peça física.
Idioma e condições de implantação para um projeto alemão
Para transferência para um projeto alemão, confirme o escopo do documento em alemão/inglês, a terminologia da UI e do defeito, os formatos decimais/data/unidade, o fuso horário do projeto, as versões de software Windows/Linux e PLC/câmera de destino e o limite entre integração remota, amostras enviadas e trabalho no local. A segurança das máquinas, a segurança cibernética, a retenção de dados, a conformidade do produto e as licenças do local devem ser confirmadas pelas partes responsáveis do projeto a partir de fontes primárias atuais para o equipamento, uso e local de implantação reais. Esta página não faz suposições sobre regulamentação alemã, certificação, impostos, prazo de entrega logístico ou condições de suporte local.
Perguntas frequentes
A câmera deve ser acionada pelo PLC, por um sensor ou pela aplicação de visão?
Não existe uma escolha universal. Selecione uma autoridade de disparo do método de chegada parcial, velocidade de movimento, tempo de exposição e capacidade da câmera e, em seguida, baseie a sequência, borda, rejeição, intervalo mínimo, tempo limite de captura e manuseio duplicado. Quem inicia, usa cycle_id e frame_id para provar que o quadro pertence à peça correta.
Um resultado de visão pode parar diretamente a máquina ou rejeitar um produto?
Um único bit de visão não deve, por padrão, atuar como uma função de segurança de equipamento ou pessoal. O sistema de visão deve fornecer um resultado, razão e estado de validade no escopo do ciclo. O PLC ou sistema de controle de segurança decide então se deve parar, rejeitar, recapturar ou solicitar revisão humana de seus intertravamentos, feedback do atuador, estado da máquina e lógica de controle revisada.
Quais amostras de falha são necessárias além dos ciclos normais de APROVAÇÃO e REPROVAÇÃO?
Cubra pelo menos imagens vazias, desfocadas, superexpostas, subexpostas e ocluídas; defeitos invisíveis e amostras de limite; incompatibilidade de receita; gatilhos duplicados ou ausentes; timeouts de aquisição e algoritmo; resultados tardios; ACK perdido; perda de comunicação; reinicializações de câmeras, PLC e serviços de visão; e baixo armazenamento. Para cada um, especifique o estado de visão esperado, a ação do PLC, os campos registrados e a condição de recuperação.
Serviços relacionados, material de caso e fontes primárias
OPC UA para Visão de Máquina Parte 1: revisar o escopo do modelo de informações para controle de visão de máquina, receitas e resultados trocados com CLPs de estação ou outro software; esta página não o trata como um protocolo de projeto obrigatório.
Downloads públicos atuais do EMVA GenICam: verifique os componentes e versões públicos atuais; a câmera alvo ainda precisa de testes para seu SDK, nós de recursos, formatos de pixel e capacidade de disparo.
Desenvolvimento de integração de sistema de visão de máquina: revise a aquisição publicada de Winge, decisão de defeito, interface de equipamento, escopo de entrega e aceitação (fonte chinesa).
Caso de desenvolvimento de visão de montagem baseado em Atlas: use apenas a aquisição USB/UVC publicada, imagem de referência, ROI, registro de resultados e escopo de reversão; não infere experiência em projetos alemães, compatibilidade arbitrária de câmera/PLC ou aceitação de linha de produção concluída (fonte chinesa).
Use Contactar a Winge para fornecer amostras de produtos e defeitos, tempo de ciclo da estação, configuração de câmera/luz/lente, tempo de disparo, tabela de sinais PLC, ambiente de implantação, idiomas de destino e condições de aceitação para que lacunas de entrada, propriedade de interface e o primeiro pacote de trabalho possam ser revisados.
Online
Telefone
WeChat
voltar ao topo