Ladder exécutable
Construisez contacts, bobines, auto-maintien, temporisateurs et compteurs. Chaque scénario possède des critères de test objectifs.
Formation pratique en automatisme
Exécutez votre premier program Ladder sans installation. Progressez ensuite avec des exercices guidés, des tests automatiques, du câblage virtuel, des défauts industriels et un suivi des résultats.
0
installation pour commencer
9
dialectes et vues de syntaxe
100+
scénarios et exercices
La simulation permet de répéter la logique et le diagnostic. Les interventions sur tension, armoires et machines réelles exigent toujours une personne compétente, des instruments adaptés et les procédures du site.
Construisez contacts, bobines, auto-maintien, temporisateurs et compteurs. Chaque scénario possède des critères de test objectifs.
Reliez les entrées et sorties aux capteurs, contacteurs, moteurs, variateurs et signaux 4–20 mA.
Associez les variables aux écrans, alarmes et tendances du même procédé simulé.
Entraînez-vous aux mesures, interverrouillages, défauts électriques et exceptions Modbus sans risque pour une installation réelle.
Réglez une boucle PID et comparez dépassement, temps de stabilisation, erreur finale et erreur absolue intégrée.
Enregistrez projets, tentatives et résultats. Les offres équipe ajoutent parcours assignés et rapports.
Modbus TCP + RTU
Construisez les fonctions 01–16, corrigez les adresses et conservez la PDU évaluée comme preuve.
Cycle automate, états booléens, contacts et bobines.
Temporisateurs, compteurs, mémoires, auto-maintien et interverrouillages.
Câblage, capteurs, moteurs, variateurs et signaux analogiques.
IHM, SCADA, Modbus, PID et mise en service virtuelle.
Le produit enseigne des concepts transférables et offre une pratique répétable. Ce n’est pas un logiciel officiel Siemens, Rockwell ou d’un autre constructeur, il ne se connecte pas directement à une machine réelle et ne remplace ni une qualification professionnelle, ni la documentation du matériel, ni une évaluation pratique supervisée.
Guide pratique du simulateur API en ligne
Réponse directe
Un simulateur d’automate programmable utile relie un program exécutable aux entrées, aux sorties et au comportement visible d’une machine. Il permet de prévoir un résultat, de rejouer les mêmes conditions, d’introduire une panne contrôlée et de conserver une preuve observable, sans prétendre reproduire chaque automate industriel.
Ce guide est conçu pour les débutants, techniciens, enseignants et automaticiens francophones qui veulent pratiquer la logique API dans un navigateur avant de passer au logiciel constructeur et au matériel réel. Le résultat visé est précis : le lecteur peut définir un petit contrat d’essai, suivre le chemin du signal, vérifier le fonctionnement normal, diagnostiquer un écart et expliquer ce qui doit encore être validé sur la cible.

Décrire l’état initial, l’action demandée, le résultat observable, les priorités d’arrêt et la condition de remise à zéro avant d’écrire la logique.
Relier l’échantillonnage des entrées, l’évaluation du program et la mise à jour des sorties pour prévoir l’état au cycle suivant.
Séparer le capteur, la voie d’entrée, la variable, la décision logique, la sortie, l’actionneur et le retour physique afin de localizer un désaccord.
Identifier chaque bit, temporisateur, compteur ou étape qui conserve une valeur, ainsi que son propriétaire, son initialization et sa remise à zéro.
Tester les commandes simultanées, les seuils exacts, les retards, les pertes de retour et le redémarrage au lieu de valider uniquement le cycle idéal.
Conserver le program, les conditions, les valeurs observées, le diagnostic et les limites pour pouvoir recréer le cas dans l’environnement constructeur.
Formuler une condition initiale, un stimulus et un résultat mesurable.
Preuve: Une autre personne peut reproduire le test sans deviner l’intention.
À éviter: Utilizer une animation ou une page terminée comme seul critère.
Nommer chaque signal, son état normal, son adresse logique et son effet physique.
Preuve: Chaque commande possède une source et chaque résultat un retour indépendant.
À éviter: Confondre la commande de sortie avec la preuve de mouvement.
Noter les entrées, l’état mémorisé et les sorties attendues avant l’exécution.
Preuve: Les changements affichés suivent la prévision cycle par cycle.
À éviter: Modifier le program avant d’avoir établi une référence.
Démarrer depuis un état connu et répéter le cycle complet.
Preuve: Plusieurs exécutions produisent le même résultat borné.
À éviter: Tester seulement une phase sans arrêt ni remise à zéro.
Bloquer un signal ou modifier une condition à la fois après avoir prévu l’effet.
Preuve: Le premier point de désaccord sépare les hypothèses principales.
À éviter: Forcer plusieurs valeurs et perdre la trace de la cause.
Supprimer la cause, restaurer l’état initial et rejouer le cas défaillant.
Preuve: Le fonctionnement et l’arrêt reviennent sans contournement caché.
À éviter: Prendre l’acquittement d’une alarme pour une réparation.
| Symptôme observé | Examiner | Interprétation | Action de preuve suivante |
|---|---|---|---|
| L’entrée ne change jamais | État du capteur, câblage simulé, voie d’entrée, variable et polarité logique | Le premier changement absent situe l’écart entre terrain, interface et mappage. | Vérifier le point suivant du chemin avec une valeur connue. |
| La logique est vraie mais la sortie reste inactive | Propriétaire final de la sortie, inhibitions, mode et état de la voie | Un bit intermédiaire vrai ne commande pas nécessairement la sortie physique. | Tracer la dernière affectation et les conditions prioritaires. |
| La sortie est active mais la machine ne réagit pas | Interface, énergie, actionneur, charge et retour de position | L’automate peut avoir exécuté la commande alors que la couche physique ne suit pas. | Comparer la commande avec un retour indépendant sans forcer le mouvement. |
| La séquence se bloque | Étape active, transition, temporisation, retour attendu et délai maximal | Une condition impossible ou un retour absent empêche la transition. | Prouver séparément chaque terme de la transition. |
| Le défaut disparaît après remise à zéro | Premier symptôme, historique, états mémorisés et cause encore présente | La remise à zéro a modifié la preuve sans démontrer la cause initiale. | Reproduire le cas et conserver les états avant et après. |
| Le simulateur et l’automate cible diffèrent | Version, tâche, cycle, type de données, E/S, temporisation et limites publiées | Une hypothèse du modèle ne correspond pas à l’environnement cible. | Réduire l’exemple puis le vérifier dans l’outil officiel. |
Preuve produit / 05
La plateforme associe un éditeur de logique, des états d’E/S, des modèles de machine, des scénarios reproductibles et des contrôles comportementaux. Le résultat est visible dans le système simulé, pas seulement dans une coloration de code ou une page terminée.
C’est un environnement qui exécute une représentation de la logique API et montre son effet sur des entrées, des sorties ou un modèle de machine dans des conditions contrôlées.
Oui pour les concepts, la logique, les séquences et le diagnostic de base. Le matériel, la sécurité, le câblage et les détails constructeur exigent ensuite une pratique supervisée.
La pratique décrite ici fonctionne dans un navigateur. Les projets natifs et la validation de l’automate cible nécessitent toutefois le logiciel constructeur approprié.
Aucune importation native ni émulation de micrologiciel n’est promise. Recréez le comportement, puis compilez et testez le projet dans l’environnement officiel.
Déclarez l’état initial et le résultat attendu, puis testez le cycle normal, les commandes simultanées, les seuils de temps ou de comptage, les défauts, la remise à zéro et le redémarrage.
Non. Il prouve une commande à une frontière donnée; un retour distinct de contacteur, de vitesse ou de processus doit confirmer le résultat physique.
Non. Il permet une pratique reproductible, mais le comportement exact du matériel, des E/S, des réseaux, de la sécurité et du cycle doit être validé sur la cible.
Conservez le besoin, les conditions initiales, le program, les valeurs observées, le cas limite, la panne, l’action de preuve, la récupération et une note claire sur les limites.