Lógica Ladder executável
Monte contatos, bobinas, selagem, temporizadores e contadores. Cada cenário possui critérios de teste objetivos.
Treinamento prático em automação
Execute seu primeiro programa Ladder no navegador. Depois avance por exercícios guiados com testes automáticos, ligação elétrica virtual, falhas industriais e histórico de progresso.
0
instalações para começar
8
dialetos e visualizações
100+
cenários e práticas
A simulação permite repetir lógica e diagnóstico. Trabalho físico com tensão, painéis e máquinas exige supervisão, instrumentos adequados e procedimentos locais.
Monte contatos, bobinas, selagem, temporizadores e contadores. Cada cenário possui critérios de teste objetivos.
Relacione entradas e saídas com sensores, contatores, motores e sinais analógicos de 4–20 mA.
Vincule tags, crie telas, alarmes e tendências usando os estados do mesmo processo simulado.
Pratique medições, intertravamentos, falhas elétricas e exceções Modbus sem arriscar uma instalação real.
Sintonize uma malha PID e compare sobressinal, acomodação, erro final e erro absoluto integrado.
Salve projetos, tentativas e resultados. Planos de equipe adicionam trilhas e relatórios de alunos.
Modbus TCP + RTU
Monte funções 01–16, corrija endereços e guarde a PDU avaliada como evidência.
Ciclo de scan, estados booleanos, contatos e bobinas.
Temporizadores, contadores, memórias e intertravamentos.
Ligação elétrica, sensores, motores, inversores e sinais analógicos.
IHM, SCADA, Modbus, PID e comissionamento virtual.
O produto ensina conceitos transferíveis e oferece prática repetível. Não é o software oficial da Siemens, Rockwell ou de outro fabricante, não conecta diretamente a uma máquina real e não substitui qualificação, manual do equipamento ou avaliação prática supervisionada.
Guia de prática verificável
Resposta direta
Um simulador de CLP online ensina de verdade quando conecta condição inicial, entradas observáveis, lógica executável, saídas, comportamento da máquina e testes repetíveis. Comece com partida e parada, preveja o resultado e depois teste temporizadores, falhas e reinício sem instalar software do fabricante.
Este guia foi escrito para estudantes de automação, técnicos de manutenção e instrutores que precisam praticar CLP em português pelo navegador. O resultado esperado é específico: o aluno consegue montar, executar, testar e explicar uma pequena sequência, além de declarar o que ainda precisa ser verificado no CLP e na máquina reais.

Mapa do sistema / 02
Trate-os como pontos de verificação conectados. Cada ponto tem um estado esperado, um estado observável e uma fronteira com a parte seguinte do sistema. Essa estrutura evita confundir uma indicação de software com prova física.
Defina estado inicial, ação, resultado esperado, condição de parada e comportamento proibido antes de desenhar a primeira rede.
Relacione leitura das entradas, avaliação do programa, memória das instruções e atualização das saídas em scans consecutivos.
Separe sensor, canal de entrada, tag, lógica, saída, interface, atuador e realimentação para observar cada fronteira.
Use estados, permissivos, transições, tempos máximos e política de reinício em vez de memórias ocultas.
Mude uma entrada, um tempo ou a ordem dos eventos e confirme que a resposta continua determinística e explicável.
Guarde programa, condições, valores e resultado, documentando o que deve ser repetido no ambiente oficial e no equipamento.
Procedimento / 03
Execute as etapas em ordem na primeira vez. Depois, a mesma estrutura vira um ciclo de diagnóstico: defina a condição esperada, observe a fronteira, interprete a diferença e escolha uma ação que a comprove.
Escreva a função da máquina, suas E/S e critérios de aceitação.
Evidência: Outra pessoa consegue repetir o teste sem adivinhar o objetivo.
Evite: Começar copiando uma solução completa.
Anote entradas, continuidade da rede e saídas antes de executar.
Evidência: A observação coincide com a previsão em vários scans.
Evite: Usar o destaque verde como única prova.
Implemente partida, parada, permissivo e realimentação com prioridade clara.
Evidência: A sequência parte, funciona e para a partir de estado conhecido.
Evite: Ocultar condição ausente com temporizador.
Mude tempos, ordem, entradas simultâneas e estado de reinício.
Evidência: Cada variação termina em um estado definido.
Evite: Testar apenas o caminho ideal.
Trave um sinal ou remova realimentação e preserve o primeiro sintoma.
Evidência: A fronteira com falha fica localizada por uma prova.
Evite: Alterar várias condições de uma vez.
Remova mudanças temporárias, restaure e repita regressões.
Evidência: Operação e recuperação ficam demonstradas sem bypass.
Evite: Confundir reconhecimento do alarme com reparo.
Matriz de diagnóstico / 04
A tabela é um auxílio de raciocínio, não uma lista para troca de peças. Preserve o sintoma inicial, inspecione a fronteira indicada e use a interpretação para escolher o próximo teste controlado. Os procedimentos do local e os manuais do equipamento continuam sendo a autoridade.
| Sintoma observado | Inspecionar | Interpretação | Próxima ação de prova |
|---|---|---|---|
| A entrada não muda | Sensor, indicador, fiação, canal e tag | A primeira transição ausente localiza a falha antes ou depois do módulo. | Verifique a próxima fronteira autorizada. |
| A rede está verdadeira e a saída não | Escritor final, inibições, tag e canal | Um bit intermediário não demonstra o comando físico final. | Encontre quem realmente escreve a saída. |
| A saída muda e a máquina não | Interface, proteção, energia, atuador e feedback | A lógica pode ter funcionado mesmo com falha na camada física. | Continue o caminho sem forçar o equipamento. |
| A sequência para | Estado, transição, temporizador e realimentação | Falta uma condição ou a transição é impossível. | Avalie cada termo separadamente. |
| A falha some depois do reset | Primeiro sintoma, histórico, tempos e causa ativa | O reset mudou a evidência sem demonstrar a causa. | Reproduza de modo controlado e registre antes e depois. |
| O CLP real se comporta diferente | Versão, tarefas, instruções, E/S e configuração | O modelo e o alvo não compartilham alguma premissa. | Reduza o caso e confira a documentação oficial. |
Evidência do produto / 05
A plataforma liga Ladder e Texto Estruturado a E/S tipadas, modelos de máquina, falhas controladas, verificações automáticas e resultados salvos. As capacidades públicas são vinculadas a partir deste guia.
A simulação ensina raciocínio transferível; não executa firmware Siemens, Rockwell ou de outro fabricante, não valida funções de segurança e não autoriza trabalho elétrico ou comissionamento real.
Caderno de comissionamento / 06
Use estes casos como tarefas escritas, não como instruções de clique. Em cada caso, declare a condição esperada antes de agir, preserve a primeira observação útil e explique por que o resultado final demonstra o requisito. Outro programa ou componente também pode estar correto se produzir o mesmo comportamento delimitado e a mesma evidência.
Caso 01
prever → observar → comprovar
Contexto de engenharia. Defina estado inicial, ação, resultado esperado, condição de parada e comportamento proibido antes de desenhar a primeira rede. Comece com uma condição normal escrita e identifique qual solicitação, estado, resultado físico ou valor de comunicação fornecerá confirmação independente. Não comece alterando a configuração: o estado inicial faz parte da evidência e deve ser reproduzível.
Preparação controlada. Use a etapa “Definir a tarefa” do fluxo: Escreva a função da máquina, suas E/S e critérios de aceitação. O registro de aceitação deve mostrar este resultado: Outra pessoa consegue repetir o teste sem adivinhar o objetivo. Anote as condições iniciais, o estímulo exato e o ponto de observação para que outra pessoa repita o caso sem depender da sua memória.
Desafio de falha. Introduza ou analise “A entrada não muda” como um desvio delimitado. Inspecione sensor, indicador, fiação, canal e tag A interpretação de trabalho é: A primeira transição ausente localiza a falha antes ou depois do módulo. A próxima ação para comprová-la é: Verifique a próxima fronteira autorizada. Altere apenas uma condição antes de observar o resultado e preserve horários ou medições quando o tempo for relevante.
Revisão e recuperação. A armadilha mais comum é começar copiando uma solução completa. Depois de remover a causa, repita o caso normal e ao menos uma condição de parada, timeout, desconexão ou reinício pertinente. Remova forças e desvios temporários, devolva o modelo a um estado conhecido e guarde evidência de que operação e recuperação são deliberadas.
Explique em voz alta: Existe simulador de CLP online grátis? Uma resposta curta e defensável é: Sim. O primeiro exercício e vários laboratórios públicos rodam no navegador. Consulte a página de planos para os limites atuais de salvamento e trilhas.
Caso 02
prever → observar → comprovar
Contexto de engenharia. Relacione leitura das entradas, avaliação do programa, memória das instruções e atualização das saídas em scans consecutivos. Comece com uma condição normal escrita e identifique qual solicitação, estado, resultado físico ou valor de comunicação fornecerá confirmação independente. Não comece alterando a configuração: o estado inicial faz parte da evidência e deve ser reproduzível.
Preparação controlada. Use a etapa “Prever o scan” do fluxo: Anote entradas, continuidade da rede e saídas antes de executar. O registro de aceitação deve mostrar este resultado: A observação coincide com a previsão em vários scans. Anote as condições iniciais, o estímulo exato e o ponto de observação para que outra pessoa repita o caso sem depender da sua memória.
Desafio de falha. Introduza ou analise “A rede está verdadeira e a saída não” como um desvio delimitado. Inspecione escritor final, inibições, tag e canal A interpretação de trabalho é: Um bit intermediário não demonstra o comando físico final. A próxima ação para comprová-la é: Encontre quem realmente escreve a saída. Altere apenas uma condição antes de observar o resultado e preserve horários ou medições quando o tempo for relevante.
Revisão e recuperação. A armadilha mais comum é usar o destaque verde como única prova. Depois de remover a causa, repita o caso normal e ao menos uma condição de parada, timeout, desconexão ou reinício pertinente. Remova forças e desvios temporários, devolva o modelo a um estado conhecido e guarde evidência de que operação e recuperação são deliberadas.
Explique em voz alta: Preciso instalar TIA Portal ou RSLogix? Uma resposta curta e defensável é: Não para os exercícios do navegador. O ambiente oficial correto será necessário para validar um projeto nativo ou controlador real.
Caso 03
prever → observar → comprovar
Contexto de engenharia. Separe sensor, canal de entrada, tag, lógica, saída, interface, atuador e realimentação para observar cada fronteira. Comece com uma condição normal escrita e identifique qual solicitação, estado, resultado físico ou valor de comunicação fornecerá confirmação independente. Não comece alterando a configuração: o estado inicial faz parte da evidência e deve ser reproduzível.
Preparação controlada. Use a etapa “Montar o caso normal” do fluxo: Implemente partida, parada, permissivo e realimentação com prioridade clara. O registro de aceitação deve mostrar este resultado: A sequência parte, funciona e para a partir de estado conhecido. Anote as condições iniciais, o estímulo exato e o ponto de observação para que outra pessoa repita o caso sem depender da sua memória.
Desafio de falha. Introduza ou analise “A saída muda e a máquina não” como um desvio delimitado. Inspecione interface, proteção, energia, atuador e feedback A interpretação de trabalho é: A lógica pode ter funcionado mesmo com falha na camada física. A próxima ação para comprová-la é: Continue o caminho sem forçar o equipamento. Altere apenas uma condição antes de observar o resultado e preserve horários ou medições quando o tempo for relevante.
Revisão e recuperação. A armadilha mais comum é ocultar condição ausente com temporizador. Depois de remover a causa, repita o caso normal e ao menos uma condição de parada, timeout, desconexão ou reinício pertinente. Remova forças e desvios temporários, devolva o modelo a um estado conhecido e guarde evidência de que operação e recuperação são deliberadas.
Explique em voz alta: Posso aprender lógica Ladder do zero? Uma resposta curta e defensável é: Sim. Comece com contatos, bobinas e ciclo de scan; depois adicione selagem, temporizadores, contadores e sequências.
Caso 04
prever → observar → comprovar
Contexto de engenharia. Use estados, permissivos, transições, tempos máximos e política de reinício em vez de memórias ocultas. Comece com uma condição normal escrita e identifique qual solicitação, estado, resultado físico ou valor de comunicação fornecerá confirmação independente. Não comece alterando a configuração: o estado inicial faz parte da evidência e deve ser reproduzível.
Preparação controlada. Use a etapa “Testar variações” do fluxo: Mude tempos, ordem, entradas simultâneas e estado de reinício. O registro de aceitação deve mostrar este resultado: Cada variação termina em um estado definido. Anote as condições iniciais, o estímulo exato e o ponto de observação para que outra pessoa repita o caso sem depender da sua memória.
Desafio de falha. Introduza ou analise “A sequência para” como um desvio delimitado. Inspecione estado, transição, temporizador e realimentação A interpretação de trabalho é: Falta uma condição ou a transição é impossível. A próxima ação para comprová-la é: Avalie cada termo separadamente. Altere apenas uma condição antes de observar o resultado e preserve horários ou medições quando o tempo for relevante.
Revisão e recuperação. A armadilha mais comum é testar apenas o caminho ideal. Depois de remover a causa, repita o caso normal e ao menos uma condição de parada, timeout, desconexão ou reinício pertinente. Remova forças e desvios temporários, devolva o modelo a um estado conhecido e guarde evidência de que operação e recuperação são deliberadas.
Explique em voz alta: Funciona em Mac, Linux e Chromebook? Uma resposta curta e defensável é: As práticas principais funcionam em navegador moderno. Ferramentas oficiais de alguns fabricantes podem exigir Windows.
Caso 05
prever → observar → comprovar
Contexto de engenharia. Mude uma entrada, um tempo ou a ordem dos eventos e confirme que a resposta continua determinística e explicável. Comece com uma condição normal escrita e identifique qual solicitação, estado, resultado físico ou valor de comunicação fornecerá confirmação independente. Não comece alterando a configuração: o estado inicial faz parte da evidência e deve ser reproduzível.
Preparação controlada. Use a etapa “Injetar uma falha” do fluxo: Trave um sinal ou remova realimentação e preserve o primeiro sintoma. O registro de aceitação deve mostrar este resultado: A fronteira com falha fica localizada por uma prova. Anote as condições iniciais, o estímulo exato e o ponto de observação para que outra pessoa repita o caso sem depender da sua memória.
Desafio de falha. Introduza ou analise “A falha some depois do reset” como um desvio delimitado. Inspecione primeiro sintoma, histórico, tempos e causa ativa A interpretação de trabalho é: O reset mudou a evidência sem demonstrar a causa. A próxima ação para comprová-la é: Reproduza de modo controlado e registre antes e depois. Altere apenas uma condição antes de observar o resultado e preserve horários ou medições quando o tempo for relevante.
Revisão e recuperação. A armadilha mais comum é alterar várias condições de uma vez. Depois de remover a causa, repita o caso normal e ao menos uma condição de parada, timeout, desconexão ou reinício pertinente. Remova forças e desvios temporários, devolva o modelo a um estado conhecido e guarde evidência de que operação e recuperação são deliberadas.
Explique em voz alta: O simulador conecta a um CLP real? Uma resposta curta e defensável é: Não é prometida conexão ou transferência direta para hardware. O objetivo é praticar comportamento e diagnóstico antes da ferramenta oficial.
Caso 06
prever → observar → comprovar
Contexto de engenharia. Guarde programa, condições, valores e resultado, documentando o que deve ser repetido no ambiente oficial e no equipamento. Comece com uma condição normal escrita e identifique qual solicitação, estado, resultado físico ou valor de comunicação fornecerá confirmação independente. Não comece alterando a configuração: o estado inicial faz parte da evidência e deve ser reproduzível.
Preparação controlada. Use a etapa “Fechar o teste” do fluxo: Remova mudanças temporárias, restaure e repita regressões. O registro de aceitação deve mostrar este resultado: Operação e recuperação ficam demonstradas sem bypass. Anote as condições iniciais, o estímulo exato e o ponto de observação para que outra pessoa repita o caso sem depender da sua memória.
Desafio de falha. Introduza ou analise “O CLP real se comporta diferente” como um desvio delimitado. Inspecione versão, tarefas, instruções, e/s e configuração A interpretação de trabalho é: O modelo e o alvo não compartilham alguma premissa. A próxima ação para comprová-la é: Reduza o caso e confira a documentação oficial. Altere apenas uma condição antes de observar o resultado e preserve horários ou medições quando o tempo for relevante.
Revisão e recuperação. A armadilha mais comum é confundir reconhecimento do alarme com reparo. Depois de remover a causa, repita o caso normal e ao menos uma condição de parada, timeout, desconexão ou reinício pertinente. Remova forças e desvios temporários, devolva o modelo a um estado conhecido e guarde evidência de que operação e recuperação são deliberadas.
Explique em voz alta: Qual exercício devo fazer primeiro? Uma resposta curta e defensável é: Monte partida e parada com prioridade de parada, preveja cada estado e teste entrada mantida, comando simultâneo e reinício.
Superfície de respostas / 07
Estas respostas concisas definem os limites de operação, treinamento e produto que resumos gerais costumam omitir. O fluxo completo e a tabela de diagnóstico acima fornecem a evidência por trás delas.
Sim. O primeiro exercício e vários laboratórios públicos rodam no navegador. Consulte a página de planos para os limites atuais de salvamento e trilhas.
Não para os exercícios do navegador. O ambiente oficial correto será necessário para validar um projeto nativo ou controlador real.
Sim. Comece com contatos, bobinas e ciclo de scan; depois adicione selagem, temporizadores, contadores e sequências.
As práticas principais funcionam em navegador moderno. Ferramentas oficiais de alguns fabricantes podem exigir Windows.
Não é prometida conexão ou transferência direta para hardware. O objetivo é praticar comportamento e diagnóstico antes da ferramenta oficial.
Monte partida e parada com prioridade de parada, preveja cada estado e teste entrada mantida, comando simultâneo e reinício.
É evidência de uma trilha específica, não licença profissional. Combine com programas explicáveis e prática física supervisionada.
Não. Ela permite repetir lógica e falhas; comportamento elétrico, mecânico, de rede e segurança precisa de validação real.
Continue o caminho do sinal / 08