L'automate programmable (API) et la programmation
Module 2 / 5
Sommaire
2.3 Mise au point, test et sauvegarde du programme
Écrire un programme n'est qu'une partie du travail. Le moment critique, c'est sa mise au point : on transfère le programme dans l'automate, on l'observe vivre et on le corrige. Cette phase touche directement une machine réelle, donc des mouvements et des risques réels. Ce chapitre pose les bons réflexes : tester en sécurité, encadrer le forçage, et surtout sauvegarder le programme avant et après toute intervention.
Checklist avant de tester un programme
Visualiser les entrées/sorties et l'état du programme
La première étape de la mise au point est l'observation. L'atelier de programmation, connecté à l'automate, permet de voir en temps réel l'état des entrées, des sorties et des variables internes pendant que le programme tourne.
Concrètement, on regarde quelles entrées passent à 1, quelles sorties s'activent, comment évoluent les temporisations et les compteurs. Cette visualisation est l'outil de base pour comprendre ce que fait réellement la machine — et pour diagnostiquer un écart entre le comportement attendu et le comportement observé.
Le mode pas à pas
Lancer un cycle complet en pleine vitesse sur un programme neuf est risqué. Le mode pas à pas consiste à faire avancer le cycle étape par étape, en validant chaque mouvement avant de passer au suivant.
Cela permet de vérifier que chaque phase se déroule comme prévu, dans le bon ordre, sans collision, et de s'arrêter immédiatement si quelque chose ne va pas. C'est particulièrement utile sur les procédés séquentiels décrits en SFC : on suit l'avancement étape par étape.
Le mode pas à pas est un outil de prudence : il rallonge le test mais évite qu'une erreur de programme ne se traduise par un mouvement brutal sur toute la course.
Le forçage : un outil puissant et dangereux
Le forçage consiste à imposer manuellement l'état d'une entrée ou d'une sortie, en court-circuitant la logique du programme. C'est utile pour tester un actionneur isolément ou simuler une entrée absente.
Mais c'est aussi l'une des manipulations les plus dangereuses : forcer une sortie commande directement un actionneur réel, sans la logique de sécurité prévue par le programme. Forcer une entrée peut faire croire à l'automate qu'une condition est remplie alors qu'elle ne l'est pas.
Tester sans mettre en danger ni la production
Une modification de programme ne se teste jamais « à chaud » en pleine production sans précaution. On cherche un cadre où une erreur reste sans conséquence grave.
- Machine en état sûr : énergies maîtrisées, zone de mouvement dégagée et balisée, accès restreint pendant l'essai.
- Hors production réelle quand c'est possible : essai à vide, sans matière, sur une machine consignée pour le test plutôt qu'en pleine cadence.
- Montée en charge progressive : on valide d'abord à vide, en pas à pas, à vitesse réduite, avant d'enchaîner un cycle complet à cadence normale.
- Arrêt d'urgence vérifié avant de lancer le moindre mouvement automatique.
La sécurité des personnes prime toujours sur le délai. Les principes de prévention des risques machines sont rappelés par l'INRS.
Le bon réflexe : sauvegarder avant ET après
Sauvegarde et gestion des versions
C'est le réflexe le plus important du chapitre : on sauvegarde le programme avant et après toute intervention. Avant, pour pouvoir revenir à l'état qui fonctionnait si la modification tourne mal. Après, pour conserver la version validée.
La gestion des versions consiste à conserver l'historique des programmes avec des noms clairs, datés, et la trace de ce qui a changé. Sans cela, impossible de savoir quelle version tourne réellement dans l'automate, ni de revenir en arrière en cas de problème.
Bonne pratique
Sauvegarde datée avant intervention, version validée renommée et archivée, note de ce qui a changé. On sait toujours quelle version tourne.
À éviter
Modifier directement dans l'automate sans sauvegarde préalable, écraser l'ancienne version, ne garder aucune trace. En cas de panne, aucun retour arrière possible.
Documentation, commentaires et transfert
Un programme bien fait se documente. Les commentaires expliquent ce que fait chaque partie ; le nommage clair des variables rend la logique lisible. Cette documentation n'est pas un luxe : c'est ce qui permet à un autre technicien de diagnostiquer une panne rapidement, sans avoir à deviner.
Le transfert est l'opération qui charge le programme depuis l'atelier de programmation vers l'automate. C'est un moment sensible : on s'assure que la bonne version est transférée, que la machine est en sécurité, et on vérifie le bon fonctionnement après transfert.
À retenir
- La visualisation des E/S est l'outil de base : elle dit si l'écart vient du programme ou du terrain (capteur, câblage, adresse).
- Le mode pas à pas fait avancer le cycle étape par étape : prudent, indispensable sur un programme neuf.
- Le forçage est puissant mais dangereux : machine en sécurité, et chaque forçage est retiré en fin de test.
- On teste sans risque : machine en état sûr, hors production réelle quand possible, montée en charge progressive, arrêt d'urgence vérifié.
- On sauvegarde avant ET après toute intervention, avec gestion des versions claire et datée pour pouvoir revenir en arrière.
- Un programme se documente (commentaires, variables nommées) ; le transfert se fait machine en sécurité, sur la bonne version.