Informatique PLC

Préembule

 

Le logiciel de contrôle du télescope ETCS (Euler Telescope Control System) permet le contrôle des éléments physique du télescope (motorisation, hydraulique, M3, etc). Il est composé d'un ensemble de Function Block (FB) écrits en structured text et exécutés sur la PLC de T4 .

Le développement de ETCS est fait avec l'utilitaire Beckhoff TwinCat3 qui permet la création du code et la configuration du matériel.

L'interface natif de ETCS est graphique, la majorité des FBs peuvent être gérés (commande et statut) par l'intermédiaire d'écran tactile au moyen de Visu développé pour l'ETCS. Ces Visus sont accessibles également par WEB.

ETCS implémente le protocole OPC/UA. Cette fonctionnalité permet le controle à distance des FBs au travers du programme python: tcs_srv.

ETCS consiste en

  • un programme Main qui lance un Main Function Block par éléments
  • des ensemble de State Machines (Fonction Block) pour chacun des éléments
  • des Functions ou Function Block utilisable sous la forme de librairies
  • des Visus

 

Fonctionnement d'une State machine

 

La majorité des States Machines du Project T4 implémentent (programmation Object Oriented) la classe FB_BaseProcess, qui a comme impact un comportement cohérent de la mise en oeuvres des State Machines.

 

Une State Machine (SM) implémentant FB_BaseProcess est gérée au moyen de quelques flags de type booléen:

  • b_enable: autorise la SM à démarrer. Lorsque le système est au repos, toutes les SM sont enabled. Si un requête est posée sur une SM, alors les SMs partageant le même mouvement sont disabled. Ainsi il est par exemple impossible de faire tourner à droite et à gauche simultanément.
  • b_requested: est mis à TRUE pour démarrer une SM, sous condition que b_enabled soit TRUE également. Si la SM n'est pas enabled, alors la requête est annulée, donc oubliée.
  • b_busy: indique que la SM est en fonction. b_busy passe à FALSE lorsque la SM est terminée.
  • b_started: indique que les initialisations de la SM sont effectuées. C'est le cas après le premier passage dans la SM.
  • b_alarmed: indique le statut de sortie de la SM. Si cette valeur est TRUE une fois que b_busy est passé à FALSE, b_alarmed indique une erreur donc le code est dans i_errorId et le message d'erreur dans s_currentStatus

 

Les SMs progressent au rythme d'un pointeur d'état qui est de type INT. Ce pointeur se nomme i_SM_state et la valeur maximal de ce pointeur atteinte avant une erreur est mémorisée dans la variable i_SM_lastState.

En cas de problème, on a une SM arrêtée (b_busy=FALSE) une erreur dans i_errorID et un message dans s_currentStatus. Grâce à i_SM_lastState, on obtient la partie du code où est survenu l'erreur. Remarque: c'est uniquement la discipline du programmeur de la SM qui permet que cette valeur soit à jour et cela grâce à la ligne de code suivante (exemple):

10: SetSMLastState(i_SM_state);

Certaines SM ont besoin d'argument (une position par exemple), FB_BaseProcess permet, et ceci est facilement modifiable, 2 argument de type INT et 2 arguments de LREAL. ce sont:

  • i_arg1
  • i_arg2
  • f_arg1
  • f_arg2

 

Getter et Setter

La classe FB_BaseProcess, définie dans PLC->...->POUs->Utilities, met à disposition des getters et des setters (méthodes pour les get et les set dans la programmation Object Oriented) pour chacune de ses variables de classe.

Ainsi et par exemple:

VariableTypeGetterSetter
i_SM_state INT GetSMState() setSMSTATE(value)
i_busy BOOL IsBusy() SetBusy(value)
i_arg1 DINT GetDintArg1() SetDintArg1(value)
f_arg1 LREAL GetLrealArg1() SetLrealArg1(value)
s_currentStatus STRING GetCurrentStatus() SetCurrentStatus(value)

 

Notion de Token

 

Lorsqu'un mouvement est géré par plusieurs SMs, une seule peut être activée au même moment (voir plus haut b_enable et b_requested). La SM active reçoit un token (de type booléen: b_token) qui reflète cette information. Le token reste attribué une fois que la SM est terminée.

Ce token a deux utilités:

  • Il indique quelle SM a été la dernière utilisée dans son groupe
  • Pour les Visus: il permet de récupérer le statut (String) représentatif du dernier mouvement

 

Debugging des SMs

Hors TwinCat3, normalement chaque SM est représentée graphiquement dans les Visus dédiées aux State Machines:

VisuStateMachines.PNG

On y voit les éléments de gestion de la SM ainsi qu'un bouton Reset qui permet de libérer la SM et cas de deadlock.

Exemple de structure: le code M3

 

Le code des SMs est installé dans la Solution ETCS (Euler Telescope Control System) dans les POUs:

On y trouve des SMs nécessaires au fonctionnement de M3 en mode observation et d'autres utiles au développement.

POUsM3.PNG

Le POU de base est FB_MAIN_M3 qui est lancé par le POU standard MAIN (PRG). Ici:

fb_MAIN_M3();

Actuellement et pour ce simplifier la tâche, les 2 groupes de fonctionnement sont définis dans GVL. Leur usage est défini plus bas:

tokenList_M3Rot: ARRAY [1..17] OF POINTER TO FB_BaseProcess;
tokenList_M3Lin: ARRAY [1..8]  OF POINTER TO FB_BaseProcess;

Les Visus sont sous VISUs->M3 et VISUs->Utilities