Actions

L'éditeur d'action : identité et emplacement, le bloc de script, ce qu'un script peut lire et écrire, chaque message de validation, le verbe Exécuter et sa journalisation, qui a déclenché la dernière exécution, ce qui exécute l'action, Activer et Désactiver, Copier et Supprimer, et les limites d'une exécution.

Une action est un bloc d'instructions JavaScript qui lit l'espace d'adressage et écrit des variables mémoire et des tags. Les actions sont le chemin d'écriture de Logic : elles s'exécutent à la demande (Exécuter), sur un déclencheur, depuis un Bouton de tableau de bord qui leur est associé, ou au démarrage ou à la fin d'un essai de Process, par une commande d'action Logic. Sélectionnez une action sous la section Actions de la colonne Logic, ou appuyez sur Ouvrir sur sa ligne dans le tableau de son dossier ou de la racine de sa section, pour ouvrir son éditeur (une action créée avec Nouveau… > Nouvelle action ne s'ouvre pas, elle est mise en évidence dans ce tableau, voir Créer et copier); lire demande Voir Logic, modifier Configurer Logic, exécuter Piloter Logic.

L'en-tête montre la marque de l'action, le nom, la ligne « Un script que vous exécutez à la demande, ou qu'un déclencheur exécute pour vous, en écrivant des variables et des tags. » et un badge Désactivée tant que l'action est éteinte. La colonne du formulaire porte IDENTITÉ, SCRIPT DE L'ACTION et Utilisé par; le rail porte DERNIÈRE EXÉCUTION.

Identité

Script de l'action

La carte SCRIPT DE L'ACTION est l'éditeur de script, avec l'indication « Instructions JavaScript (let, if, for, fonctions). Écrivez les variables mémoire par affectation (Variables.Setpoint = 21.5;) et les tags avec Connector.Driver.Device.Tag.Write(value). Les lectures ne sont pas filtrées par la qualité : vérifiez .State() et protégez les manques avec?? avant tout calcul. » Le script s'enregistre automatiquement à chaque frappe et est validé toutes les demi-secondes; le message apparaît sous l'indication. La validation n'exécute jamais le script.

Un script est du JavaScript ordinaire en mode strict (variables locales, if, boucles, fonctions, Math, Date, JSON) sur le même espace d'adressage et la même surface de lecture que les expressions, avec deux différences. Les lectures ne passent pas la barrière de qualité : un vide se lit comme null, alors vérifiez .State() et protégez le calcul avec ??; traiter une mauvaise lecture est justement ce à quoi servent les actions. Et un script peut lire des variables d'expression (leur valeur publiée); seule une expression ne peut pas les référencer.

Un point en direct (un tag, une variable, une alarme, un canal de Process) est le point, pas sa valeur : lisez donc sa valeur par un membre, if (Variables.Start.ValueToBool()), Variables.Level.ValueToReal() > 80, if (Alarms.High.IsActive). Écrit nu dans le test de if, while, do, for ou ?:, comme opérande de !, && ou ||, dans une comparaison ou dans l'arithmétique (+= et les autres affectations composées compris), il compterait toujours comme vrai ou ne lirait jamais sa valeur : if (Variables.Start) { … } exécuterait son bloc à chaque exécution, quelle que soit la valeur de la variable. La validation le refuse et nomme le membre à lire à la place (Ce que la validation refuse). Un point passé à une fonction, et tout membre d'un point, reste tel qu'il est écrit. Il en va de même pour un switch sur un point nu ou un case qui en nomme un (lisez .Value), pour le côté gauche de ?? (lisez .Value) et pour un emplacement ${…} d'un gabarit littéral (lisez .ValueToString()). Une affectation composée à une variable (Variables.Total += 1, -=, ||= et les autres) lit la variable comme le point avant d'écrire, elle est donc refusée avec l'affectation simple qui fonctionne : Variables.Total = Variables.Total.ValueToReal() + 1.

Ce qu'une action peut écrire

Exactement deux constructions modifient l'installation, et les deux passent par le canal d'écriture journalisé :

Un tag porte deux verbes d'écriture, et le script choisit selon qu'il a besoin de la réponse :

L'attente se fait sur la voie des actions : un équipement lent ne retient donc que les actions derrière celle-ci, et elle ne retire jamais l'écriture; une valeur qui n'est pas confirmée à temps voyage encore, et son accusé de réception est journalisé à son arrivée. C'est ce que dit la réponse, en toutes lettres : « « Cmd » n'a pas été confirmé en 2000 ms; la valeur est encore en route vers l'équipement. » Avec continueOnFailure omis ou à true, le verbe répond false et le script poursuit; avec false, l'exécution se termine à cette ligne, en nommant la cible et la raison.

Aucune écriture n'interrompt un script à elle seule. Une écriture refusée avant tout envoi et une écriture que l'équipement refuse ou à laquelle il ne répond jamais échouent toutes deux seules : le reste du script s'exécute, et l'exécution se termine comme une exécution réussie avec des écritures en échec. Rien n'est défait non plus : ce qui s'est appliqué avant une écriture en échec reste appliqué, et le journal montre chaque écriture de l'ancienne vers la nouvelle valeur sous la source Action. Les raisons dans lesquelles se lit un refus :

• « L'écriture dans « X » a été rejetée: la valeur n'est pas finie. » (NaN ou infini)
• « « Tag » n'est pas matérialisé dans le connecteur. » (un équipement désactivé, ou un tag que le Connector ne porte pas)
• « « valeur » n'a pas pu être converti pour « Tag ». »
• « « X » est protégé en écriture par « <qui la retient> ». » (une recette en cours ou un verrouillage retient la source)
• « « Cmd » n'a pas été écrit : l'équipement n'est pas connecté. » (l'équipement est déjà connu pour être hors service, alors rien n'est mis en file pour lui)
• « L'écriture dans « Tag » a échoué : le Connector ne fonctionne pas. »
• « La variable « X » est introuvable. » et « « Variables.X » est une variable d'expression : elle est calculée, jamais écrite. »
• Ce que l'équipement ou son pilote a répondu, dans ses propres mots, quand le refus est venu du fil.

Une valeur qu'une écriture plus récente sur le même tag a devancée dans la file de l'équipement n'est pas un échec : « « Cmd » a été remplacé par une valeur plus récente avant l'envoi. » est exactement ce qui s'est passé, c'est la valeur la plus récente qui est dite à l'équipement, et rien n'en est rapporté nulle part sauf à un WriteAndWait, qui répond false parce que cette valeur n'est pas celle qui est partie.

Ce qui met fin à une exécution : une erreur du script lui-même (une erreur de syntaxe, une adresse qui ne nomme rien, une exception), un WriteAndWait(…, false) dont l'écriture a échoué, et les limites d'exécution décrites sous Exécuter.

Les échecs que l'exécution peut elle-même rapporter découlent de qui a attendu. Un Write refusé avant tout envoi l'est pendant que le script tourne encore : l'exécution le compte et le journal des actions le dit; un Write que l'équipement refuse ensuite reçoit sa réponse bien après la fin de l'exécution, alors c'est la console Événements, sous le nom de l'action, qui le porte, et jamais l'exécution. Un WriteAndWait est resté pour la réponse : il la compte donc dans un sens comme dans l'autre.

Ce que la validation refuse

Les trois messages de WriteAndWait jugent ce que dit le texte lui-même. Un argument que l'éditeur ne peut pas trancher à la lecture (une variable, une expression calculée) est jugé au moment où l'appel a lieu, et la même phrase met alors fin à l'exécution à cette ligne.

Les variables locales de JavaScript (let x = 1; x = x + 1;) ne sont touchées par aucune de ces règles.

Exécuter

Exécuter est le verbe de tête de la barre au-dessus d'une action ouverte; il n'est dessiné que pour un rôle qui détient Piloter Logic et il est grisé avec « Runtime arrêté » pendant que la station est en lecture seule (le verrou d'ingénierie ne le grise pas : exécuter est du pilotage, pas de la configuration). Quand le rôle détient aussi Configurer Logic, le brouillon de l'éditeur est enregistré d'abord et l'exécution porte sur la définition enregistrée; sans cette permission, l'exécution porte sur la définition durable (les champs sont en lecture seule, donc les deux ne diffèrent jamais).

Chaque exécution se fait sur la voie des actions avec un moteur de script neuf : aucun état ne fuit d'une exécution à l'autre, et deux scripts ne tournent jamais en même temps, ils s'exécutent un à la fois, dans l'ordre où ils ont été demandés. La voie n'est pas le cycle de 100 ms. Les expressions, les alarmes, les acquittements et les écritures qui arrivent d'ailleurs continuent pendant qu'un script tourne : un cycle peut donc tomber au milieu d'un script et deux lectures d'un même script voir des cycles différents; en échange, une action qui s'arrête pour attendre un équipement ne retarde que les actions en file derrière elle, et rien d'autre dans la station.

Une exécution est interrompue au-delà de 500 ms (« Le script a été interrompu : il a dépassé la limite de temps de 500 ms (boucle infinie?). »), de 100 000 instructions ou de 4 MB de mémoire, chacune avec un message qui nomme la limite. Les 500 ms mesurent le script en train de s'exécuter : le décompte est suspendu tant qu'un WriteAndWait attend un équipement et reprend ensuite, si bien qu'un script correct n'est jamais blâmé pour la lenteur de l'équipement. Une action désactivée échoue sans s'exécuter (« L'action est désactivée. »); un runtime arrêté répond « Le runtime de la logique n'est pas en service. »

Le journal des actions signale « Exécution réussie en 12 ms. » quand chaque écriture est passée, « Exécution réussie en 12 ms, 1 écriture en échec : Cmd : « Cmd » n'a pas été écrit : l'équipement n'est pas connecté. » quand le script lui-même est allé au bout et qu'une écriture non (avec « Exécution réussie en 12 ms, 3 écritures en échec, la première : Cmd : « Cmd » n'a pas été écrit : l'équipement n'est pas connecté. » à partir du deuxième échec), ou « Échec de l'exécution : <raison> » quand c'est l'exécution elle-même qui s'est mal terminée.

L'exécution en échec parvient à la console Événements, sous le nom de l'action et avec ce qui l'a lancée : Manuel pour le verbe, Dashboard pour un Bouton, MCP pour l'agent, le nom du déclencheur pour une exécution planifiée, et Process · <unit> · <action> pour un essai de Process. Il est journalisé comme un avertissement la première fois, résumé tant qu'il échoue pour la même cause, et noté une fois encore au rétablissement, et cette ligne de rétablissement est la seule entrée qu'une exécution réussie y écrive jamais. Une écriture refusée parvient à la console de la même façon et sous le même nom, et pour la même raison c'est l'action qui est nommée et non l'exécution : la réponse de l'équipement peut arriver des secondes après la fin de l'exécution, et il ne reste plus d'exécution à faire échouer. Une exécution qui réussit simplement, et chaque valeur qu'elle écrit, ne vont qu'à la capture détaillée : un script qui écrit à chaque cycle produit des valeurs par milliers, et une console qui en est pleine est une console où personne ne lit les nouvelles de la station.

Le rail DERNIÈRE EXÉCUTION montre quand l'action s'est exécutée pour la dernière fois (ou « Jamais exécutée. »), « Durée : N ms », qui l'a déclenchée (ci-dessous), la dernière erreur dans une note de prudence, les écritures en échec de cette exécution dans une note de prudence à elles (la même phrase que portait le journal des actions, si bien qu'une exécution qui a réussi en laissant quand même une consigne là où elle était le dit aussi ici), et le rappel « Les exécutions se font sur la voie des actions, une à la fois. Seule une exécution en échec parvient à la console des événements; une exécution réussie, et chaque valeur qu'elle écrit, est conservée pour la capture détaillée. Les déclencheurs appellent les actions selon leur planification. » Le rail appartient à l'action vivante : un enregistrement automatique ne le vide jamais; un redémarrage du runtime, si.

Déclenchée par

Sous la durée, la ligne « Déclenchée par : … » dit ce qui a exécuté l'action en dernier :

Utilisé par

La carte Utilisé par liste tout ce qui, dans la station, exécute l'action (« Tout ce qui, dans la station, exécute cette action. »), lue à l'ouverture de l'action : une ligne par commande de Process qui la déclenche, par déclencheur qui lui est associé et par Bouton de tableau de bord qui l'exécute.

Sans rien, elle dit « Rien dans la station n'exécute cette action. »; quand les références ne peuvent pas être lues, « Cette action est peut-être encore utilisée. Réessayez avant de la supprimer ou de la renommer. » avec Réessayer. La carte ne fait que lire, donc chaque rôle la voit, y compris quand la station est verrouillée en ingénierie. Lisez-la avant de désactiver ou de supprimer une action : une commande de Process dont l'action a disparu n'exécute rien et le dit sur sa propre page.

Lire l'essai qui l'a déclenchée

Une action qu'un essai de Process déclenche à la fin lit cet essai sous la branche LastRun de l'unité, qui le porte déjà quand l'action s'exécute; une action déclenchée au démarrage lit les métadonnées de l'essai qui commence sous Procedure.Metadata. Les points de Process se lisent comme des valeurs brutes, sans .Value après eux, contrairement aux variables, et un point que l'essai ne porte pas se lit null, donc protégez-le :

if (Process.Oven_soak.Oven_1.LastRun.Verdict === "Ok") {
  Variables.Last_serial = Process.Oven_soak.Oven_1.LastRun.Metadata.Serial;
}
const peak = Process.Oven_soak.Oven_1.LastRun.Evaluations.Soak_check.Temperature_in_range.MaxValue;
if (peak !== null) {
  Variables.Last_peak = peak;
}

Les adresses s'écrivent en entier, comme toute adresse d'un script : une adresse ne peut pas se construire à partir d'une variable.

Commandes

Le volet de la racine Actions liste chaque action avec son état dans la colonne Valeur : « Activée · dernière exécution <quand> », avec « · erreur » quand la dernière exécution a échoué, « · écriture en échec » quand elle a réussi et qu'une de ses écritures non, ou « Désactivée ».

Ce que les actions ne font pas

Elles ne lancent pas les commandes d'essai de Process, ne préparent pas une procédure et n'ajoutent pas de commentaire d'essai (ces points ne sont que des valeurs de disponibilité et de préparation, en lecture seule); elles n'acquittent pas les alarmes; elles ne s'exécutent pas en parallèle; elles ne gardent aucun état d'une exécution à l'autre et ne partagent aucune fonction; et elles ne partent ni sur un changement de valeur, ni sur une condition, mais seulement par Exécuter, par l'intervalle d'un déclencheur, par un bouton de tableau de bord, par l'agent ou par la commande d'un essai de Process. Un essai de Process n'attend jamais l'action qu'il déclenche, et le résultat de l'action n'est jamais écrit dans l'essai.