Temporisation de surveillance de remplissage qui ne déclenche jamais

Cause principale : le TON mémorise son temps écoulé tant que IN reste vrai ; toute retombée de IN à 0 remet le compteur à zéro. Or le bit de niveau bas clignote à plusieurs hertz à cause du clapotement et de la mousse. Le temps écoulé est donc réinitialisé en permanence et n'atteint jamais 12 s : l'alarme est structurellement impossible à obtenir, même avec la vanne fermée, puisque le capteur continue de ballotter.

Seconde cause possible : le bloc de l'étape 20 n'est appelé que pendant l'étape active ; si la séquence sort de l'étape ou si le bloc est sauté par un saut conditionnel, le TON n'est plus scanné et son temps est perdu. Une temporisation placée dans un bloc non appelé ne compte pas.

Essais de discrimination :

1. Forcer le bit d'entrée à 1 en table de variables et observer la sortie Q du TON au bout de 12 s : si Q passe à 1, la logique de tempo est bonne et le problème vient du clignotement ; si Q ne passe pas, le bloc n'est pas scanné.
2. Mettre en ligne une variable de temps écoulé (ET) et la tracer sur 30 s : une dent de scie confirme les réinitialisations.
3. Vérifier l'appel effectif du bloc (statut du bloc, compteur d'appels) et l'état de l'étape au moment de l'essai.
4. Contrôler le câblage et l'affectation de l'entrée (PNP/NO, adresse cohérente avec le schéma).

Principe : ne pas piloter la tempo par un signal instable. On mémorise la condition de défaut potentiel à partir du front montant de « vanne ouverte », on confirme l'état du capteur par un filtrage, puis on lance une tempo non réinitialisable tant que la séquence est dans l'étape de remplissage.

Pseudo-code :

// à l'entrée de l'étape 20
Niveau_Bas_Filtre := TON1(IN := Niveau_Bas, PT := T#300ms).Q ;
// lancement du contrôle, mémorisé
IF front(etape20) THEN Defaut_Arm := TRUE ; END_IF ;
// la tempo n'est réarmée que par l'acquittement
Defaut_Pas_Remplissage := TON2(IN := (Niveau_Bas_Filtre AND Defaut_Arm),
                               PT := T#12s).Q ;
// sortie de défaut mémorisée
IF Defaut_Pas_Remplissage THEN Alarme := TRUE; Arret_Pompe := TRUE; END_IF ;
// réarmement manuel
IF Acquit AND NOT Niveau_Bas THEN Alarme := FALSE; Defaut_Arm := TRUE; END_IF ;

Points clés : le filtre de 300 ms (ou un R_TRIG + SR) supprime le clapotement ; la tempo est armée par le front d'entrée d'étape et non par le capteur, donc elle ne peut plus être remise à zéro par le ballotlement ; le réarmement est manuel pour que l'opérateur constate le défaut. On ajoute une seconde surveillance, sur le débit ou sur le niveau haut non atteint, pour couvrir le cas d'un capteur de niveau bas bloqué à 0.

Réaction au défaut : arrêt de la pompe, fermeture de la vanne de la cuve concernée, maintien des autres cuves dans un état sûr, alarme visualisée avec le code défaut et la cuve concernée, pas de reprise automatique. L'objectif est double : protéger le produit et la pompe (marche à sec) et donner à l'opérateur une information exploitable.

Pourquoi pas d'arrêt général : un arrêt total sur un défaut de remplissage d'une seule cuve dégraderait la disponibilité sans gain de sécurité réel. En revanche, si le défaut peut conduire à un débordement, la vanne doit être fermée et le niveau haut surveillé indépendamment.

Remise en service : acquittement manuel par l'opérateur, à l'extérieur de la zone, après constat de la cause (vanne fermée, pompe, capteur). Le défaut doit être mémorisé (SR ou bit d'alarme) pour ne pas disparaître quand le niveau remonte. Conditionner la reprise à la présence du niveau bas effectif et à l'absence du défaut.

Traçabilité : horodater le défaut dans l'automate ou le superviseur, compter les occurrences par cuve ; c'est cette donnée qui permettra de distinguer un défaut process (vanne, pompe) d'un défaut de capteur, et d'alimenter la maintenance.