|
Machinebesturing
Gebruik Object Oriented-programmatie
samen met IEC 61131
version française
Object Oriented-programmeren is alles behalve nieuw. De sterkte van OO is
dat het, vergeleken met traditioneel programmeren, een veel duidelijke
structuur biedt. Voor machinebouw kan de combinatie van IEC 61131 met
Object Oriented-programmeren (IEC 31113-3) de ontwikkelaar het leven
makkelijker maken. Maar nog belangrijker: de ontwikkelingstijd van een
machinesturing - en vooral latere varianten - zal een flink stuk korter
zijn.
De machinebesturing vervangt steeds meer de
traditionele PLC. Dat is niet zo verwonderlijk, want het ooit zo recht-toe
recht-aan cyclische programma dat in de PLC continu draait, biedt niet
langer voldoende structuur. Besturingen zijn een stuk complexer vandaag:
naast de logische taken, moet de PLC meteen ook een hele rits andere
besturingstaken afhandelen, zoals motion control, HMI, rekenkundige
bewerkingen, datalogging, alarmering en communicatie. IEC 61131 heeft hier
al veel in verbetering in gebracht, maar - ondanks alles - blijft het nog
steeds zo dat ‘hoe langer mijn programma, hoe meer tijd nodig is om alle
regels af te werken’.
Modulariteit
En daar komt OO in het spel. In een OO-omgeving wordt elke afzonderlijke
taak (object) voorzien van een eigen functie met eigen code (methode), een
eigen database en een eigen cyclustijd. Dit maakt dat ook onderhoud aan
het in een OO geschreven programma eenvoudiger is. Modulariteit staat
voorop bij Object Oriëntatie, maar de kracht schuilt ook in de eenvoudiger
programmering ten opzichte van de meer traditioneel georiënteerde
programmeertalen. Een object hoeft slechts eenmaal te worden
‘geprogrammeerd’, waarna het steeds kan worden hergebruikt. Niet
onbelangrijk: een eenmaal gemaakt object kan als zelfstandige eenheid
worden getest. Met andere woorden: het object kan geïsoleerd worden van de
rest van het programma.
Innovatief
Hét grote voordeel van OO ligtvoor de hand: tijdsbesparing. De
Client/Server-technologie in combinatie met objectgeoriënteerde
programmering en een grafische presentatie, maakt een veel sneller en
eenvoudiger realisatie van machinebesturingen mogelijk. De denkwijze en de
manier van presenteren slaan een brug tussen de constructeur en
softwareontwikkelaar.
Voordat begonnen wordt met het schrijven van de eerste regel code, wordt
eerst vastgesteld uit welke afzonderlijke klassen (functies) de machine
bestaat. Elke klasse wordt beschreven en de onderlinge relaties tussen de
klassen worden benoemd (client-server kanalen). Vervolgens wordt
omschreven wat een klasse moet doen. Oftewel welke functies (methodes)
moet de klasse uitvoeren. Denk hierbij aan: Initialiseren, Alarmering,
Lezen en Schrijven van variabelen, de cyclische taak (PID, boren,
verplaatsen, aan-uitschakelen van ventielen etc.), de real-time taak
(servo positioneren, etc.), de background taak (HMI, archivering etc.).
Een ‘klasse’ zal zijn gegevens voor de overige klassen verbergen. Andere
klassen kunnen deze gegevens niet direct benaderen maar alleen via de
publieke Client-Server kanalen. Er wordt een duidelijke scheiding tussen
de interface en de implementatie aangebracht. Dit is de essentie van
Object Oriented programmeren.
Elke klasse kan nu door een andere programmeur worden gebouwd en kan
afzonderlijk worden getest. Een eenmaal goedgekeurde klasse kan
probleemloos worden opgenomen in het project en natuurlijk in de
bibliotheek.
IEC 31113-3: inclusief OO
De IEC 61131-3 norm gaat nog een stap verder doordat hij uitgebreid is met
objectgeoriënteerde programmering. Een programmeur kan zich concentreren
op de werking van zijn specialisme. Hij zorgt voor de interface naar de
omgeving, zoals van te voren is besproken. Zodra hij zijn informatie heeft
verkregen kan hij deze verwerken en nieuwe informatie beschikbaar stellen.
Met andere woorden: zodra hij van de fotocellen informatie krijgt dat er
een werkstuk op zijn plek ligt, kan de bewerking beginnen. Wanneer deze
handeling klaar is gaat er een signaal naar de volgende actie bijv.
transporteur die zijn beweging in gang zet. De transporteur of rollenband
heeft een eigen klasse. Deze is zo geschreven dat automatisch herkend
wordt of de band aan het begin van een lijn staat, tussen twee stations in
of aan het eind. Automatisch wordt vollopen en aflopen bewaakt. Deze
universele klasse wordt onderhouden door één programmeur die eventuele
nieuwe wensen van collega’s verwerkt. Zijn collega’s hebben steeds de
beschikking over de laatste versie. De herkenbaarheid wordt enorm
vergroot, de betrouwbaarheid neemt toe omdat de klassen uitgebreid getest
kunnen worden en de ontwikkeltijd van nieuwe applicaties wordt enorm terug
gebracht. De inbedrijfstelling wordt teruggebracht tot een minimum.
Debuggen
De grafische weergave van de klassen toont ‘on-line’ duidelijk de
samenhang tussen de objecten. In één overzicht zijn het totale project, de
functionaliteit, dataverkeer en de interfaces beschikbaar. Complexe
koppelingen zijn hierdoor eenvoudig te herkennen, te controleren en zo
nodig te wijzigen. De constructeur herkent zijn machine en de programmeur
herkent de klassen. Duidelijk is welke informatie wordt verwacht en welke
eventueel mist. De klassen zijn afzonderlijk getest, de interne data is
voor het overzicht dus niet meer van belang. Door de informatie terug te
brengen tot de essentie wordt het overzicht vergroot, de oorzaak van een
probleem zal sneller gelokaliseerd worden en de programmeur van de
‘probleem’ klasse hoeft slechts zijn code te controleren. <<
Kader:
Hoe werkt Object Oriented IEC 61131-3 in de praktijk?
Hoe werkt de combinatie van OO en IEC-61131 (of IEC 61131-3) in de
praktijk? We bekeken LASAL Class, één van de eerste object georiënteerde
programmeeromgevingen die speciaal ontwikkeld is voor de machinebouw/PLC
gebruikers.
Het pakket maakt het mogelijk programmacode te schrijven in structured
Text volgens IEC- 61131, Instructielijst (AWL/IL), Ladderdiagram (LD/KOP),
C++, en het biedt een interpreter voor volgorde besturingen. Er wordt
gebruik gemaakt van client-server technologie, grafische presentatie en
object oriëntatie. Op eenvoudige wijze kan met meerdere mensen
tegelijkertijd en in verschillende talen aan een applicatie worden
gebouwd. (‘multi development possibility’).
De programmeur koppelt objecten langs grafische weg aan elkaar. Hij
plaatst bijvoorbeeld een I/O-module (een object) op het scherm. Vervolgens
trekt hij een lijn van een serverkanaal naar het gewenste cliëntkanaal van
bijvoorbeeld een PID-regelaar (een object). De achterliggende methode
‘softwarecode’ koppelt beide softwarematig aan elkaar. Wat de besturing
met de I/O-signalen doet ligt vast in het object dat bij de PLC hoort. Dat
kan een eenvoudige functie zijn maar net zo goed een zeer complexe
functie. Er kan direct een actuator worden aangestuurd, maar ook een
timer- of een tellerfunctie of een diagnosefunctie behoren tot de
mogelijkheden. Zelfs een complete servoas, een uitneemunit van een
spuitgietmachine, een feeder op een verpakkingsmachine, of… kunnen een
object vormen. Zo wordt het net zo makkelijk om een servoas aan de
hardware te koppelen als het aansluiten van een sensor op een ingang.
Specifieke kennis van de klassen is niet nodig om deze te gebruiken. De
klassen inclusief hun methodes (functies) worden vastgelegd in een
bibliotheek en zijn geschikt voor hergebruik. Via slepen en het eventueel
invullen van de betreffende parameters is dat heel eenvoudig geworden.
Naast LASAL Class is er ook LASAL Screen Editor en LASAL Text beschikbaar.
Met LSE kunnen grafische objecten ontworpen worden welke een rechtstreekse
koppeling hebben met hun besturingsobjecten. LSE biedt de gebruiker een
HMI-interface direct geïntegreerd in zijn programmeeromgeving. De huidige
processoren zijn zo krachtig dat één enkele CPU volstaat om mits OO
geprogrammeerd zowel de besturingstaak als de HMI taak voor zijn rekening
te nemen.
Voorbeelden van toepassingen
Sinds de eerste voorzichtige verkenningen, zijn er diverse toepassingen
met de OO-methode gerealiseerd. Collega’s maken collega’s enthousiast en
systeemintegratoren zien de voordelen in van het hergebruik, de
multi-developer mogelijkheden en de platformonafhankelijkheid. Een
relatief eenvoudige boormachine die een stuk metaal moet verplaatsen en
met een instelbare steek gaten moet boren. Een ‘slicer’ voor
kaas/vleeswaren/brood die ingesteld moet kunnen worden op productdikte,
gewicht, presentatie. Een VVVS verticale vorm vul sluitmachine die chips,
snoep, groente etc. verpakt waarbij de keuze voor servo, draaistroom of
zelfs hydroaandrijving gemaakt moet worden. Een sorter waar de klant zelf
het aantal afgifte units wil bepalen, elke unit is een klasse geworden die
eenvoudig vanuit de bibliotheek toegevoegd worden afhankelijk van het
gewenste aantal.
Ook relatief eenvoudige machines halen overigens hun voordeel uit de OO
methodiek.
Slotopmerking
De beschikbaarheid van OO-programmeertools zal de komende jaren alleen
maar toenemen. Studenten komen immers met deze bagage van hun studie en
zijn gewend om in deze structuren te denken. Voor de huidige
PLC-programmeurs zal het weer een nieuwe uitdaging zijn om zich ook deze
techniek eigen te maken. Dat dat zal lukken lijdt geen twijfel, de stap
van schuifregister naar ARRAY en struct is eind vorige eeuw ook gelukt. <<
Commande machine
Utilisez la programmation orientée objet
avec la norme IEC 61131
La programmation orientée objet est tout sauf neuve.
La force de l’orientation objet (OO), par rapport à la programmation
traditionnelle, réside dans la structure plus claire qu’elle propose. Pour
la construction de machines, la combinaison de l’IEC 61131 avec la
programmation orientée objet (IEC 31113-3) peut faciliter la vie du
développeur. Et plus important encore: le délai de développement d’une
commande machine – et surtout des variantes ultérieures – sera
sensiblement réduit.
La commande machine remplace de plus en plus le PLC
traditionnel. Cela n’a rien de surprenant car le programme cyclique tout
ou rien qui tourne en continu dans le PLC n’offre plus une structure
suffisante. Les commandes actuelles sont plus complexes: outre les tâches
logiques, le PLC doit aussi gérer une série d’autres tâches de commande
comme le contrôle de mouvement, la HMI, les opérations de calcul,
l’enregistrement de données, les alarmes et la communication. La norme IEC
61131 a déjà apporté de grandes améliorations mais nous en sommes – malgré
tout – toujours à une situation où ‘plus mon programme est long, plus la
gestion de toutes ces lignes est longue’.
Modularité
Et c’est là qu’intervient l’OO. Dans un environnement OO, chaque tâche
distincte (objet) est dotée d’une fonction propre et d’un code propre
(méthode), de sa base de données et de son temps de cycle. De ce fait, la
maintenance d’un programme écrit en OO est fortement simplifiée. L’OO met
la modularité à l’avant-plan. Néanmoins, sa force réside aussi dans la
simplification de la programmation par rapport aux langages de
programmation à orientation plus traditionnelle. Un objet ne doit être
programmé qu’une seule fois, ensuite il est en permanence réutilisable.
Cette facilité a son importance: un objet utilisé une fois peut être testé
comme unité indépendante. En d’autres termes: l’objet peut être isolé du
reste du programme.
Innovateur
Le grand avantage de l’OO est évident: le gain de temps. La technologie
client/serveur en combinaison avec la programmation orientée objet et une
présentation graphique, permet une réalisation plus rapide et plus simple
des commandes machine. La méthode de réflexion et la manière de
présentation jettent un pont entre le constructeur et le développeur de
logiciels.
Avant de démarrer l’écriture de la première ligne de code, il faut d’abord
déterminer les différentes classes (fonctions) de la machine. Chaque
classe est décrite et les relations réciproques entre les classes sont
nommées (canaux client-serveur). Vient ensuite la description de la tâche
d’une classe, c.-à-d. les fonctions (méthodes) dont elle doit s’acquitter.
Pensez par exemple à l’initialisation, au déclenchement d’alarmes, à la
lecture et l’écriture de variables, aux tâches cycliques (PID, forage,
déplacement, activation-désactivation de vannes…), aux tâches temps réel
(positionnement asservi…), aux tâches en arrière-plan (HMI, archivage…).
Une ‘classe’ dissimulera ses données aux autres classes. Les autres
classes ne peuvent s’approcher directement de ces données, seulement via
des canaux client-serveur publics. Il existe une séparation claire entre
l’interface et l’implémentation. Voilà l’essence de la programmation
orientée objet.
Chaque classe peut désormais être construite par un autre programmeur et
testé séparément. Une classe qui a été approuvée peut être reprise sans
problème dans le projet et, naturellement, dans la bibliothèque.
IEC 31113-3: y compris l’OO
La norme IEC 61131-3 va un pas plus loin car elle est étendue avec la
programmation orientée objet. Un programmeur peut se concentrer sur le
fonctionnement de sa spécialité. Il se charge de l’interface avec
l’environnement, comme discuté auparavant. Dès qu’il a obtenu son
information, il peut la traiter et mettre de nouvelles informations à
disposition. En d’autres termes: dès qu’il reçoit des photocellules
l’information qu’une pièce de travail est en place, le traitement peut
démarrer. Lorsque cette opération est prête, un signal part vers l’action
suivante, par exemple le transporteur qui initie son mouvement. Le
transporteur ou convoyeur à rouleaux a sa propre classe. Celle-ci est
décrite de manière à reconnaître automatiquement si la bande se trouve en
début de ligne, entre deux stations ou à la fin. Le remplissage ou le
vidage est automatiquement surveillé. Cette classe universelle est
maintenue par un seul programmeur qui traite les éventuelles nouvelles
demandes de collègues. Ses collègues disposent toujours de la dernière
version. La reconnaissance est fortement accrue, la fiabilité augmente car
les classes peuvent être testées extensivement et le délai de
développement des nouvelles applications est sensiblement raccourci. La
mise en service est réduite à son minimum.
Débogage
La représentation graphique des classes montre clairement ‘en ligne’ la
cohésion entre les objets. Le projet global, la fonctionnalité, le trafic
de données et les interfaces sont disponibles dans un seul aperçu. Les
liaisons complexes se reconnaissent, se contrôlent et se modifient dès
lors aisément. Le constructeur reconnaît sa machine et le programmeur
reconnaît les classes. Les informations escomptées et les informations
manquantes sont clairement identifiées. Les classes sont testées
séparément, les données internes n’importent donc plus pour l’aperçu. En
ramenant l’information à l’essentiel, l’aperçu est agrandi, la cause d’un
problème sera plus vite localisée et le programmeur de la classe
‘problématique’ n’a plus qu’à vérifier son code. <<
Cadre:
Comment fonctionne la norme IEC 61131-3 orientée objet dans la pratique?
Comment fonctionne la combinaison de l’OO et de la norme IEC 61131 (ou IEC
61131-3) dans la pratique? Nous avons examiné LASAL Class, un des premiers
environnements de programmation orientés objet, spécialement conçu pour
les constructeurs de machines/utilisateurs de PLC.
Le progiciel permet d’écrire un code programme en Texte structuré selon la
norme IEC-61131, en liste d’instructions (AWL/LIST), en schéma à contact
(LD/CONT), en C++ et offre un interpréteur pour les commandes
séquentielles. Il a recours à la technologie client-serveur, à la
présentation graphique et à l’orientation objet.
Plusieurs personnes peuvent travailler simultanément en toute simplicité à
une application dans différents langages (‘multi development
possibility’). Le programmeur connecte les objets de manière graphique. Il
place par exemple un module d’E/S (un objet) à l’écran. Ensuite, il tire
une ligne d’un canal serveur vers le canal client souhaité d’un régulateur
PID par exemple (un objet). La méthode sous-jacente ‘code logiciel’ les
relie ensemble par logiciel. Ce que fait la commande avec les signaux
d’E/S est déterminé dans l’objet qui va de pair avec le PLC. Cela peut
être une fonction simple mais cela peut être aussi une fonction très
complexe. Un actionneur peut être piloté directement. Cependant, une
fonction de temporisation ou de comptage ou encore, une fonction de
diagnostic est également envisageable. Même l’asservissement d’un axe
complet, une unité d’enlèvement d’une machine de pulvérisation, un
distributeur d’une machine d’emballage… peuvent constituer un objet. Il
est ainsi tout aussi facile de relier un axe asservi que de raccorder un
capteur à une entrée. Pas besoin de connaissances spécifiques des classes
pour les utiliser. Les classes, y compris leurs méthodes (fonctions) sont
définies dans une bibliothèque et sont aisément réutilisables par simple
glissage et remplissage éventuel des paramètres adéquats. Outre LASAL
Class, il y a aussi LASAL Screen Editor et Lasal Text. LSE permet de
développer des objets graphiques qui ont un lien direct avec leurs objets
de commande. LSE offre à l’utilisateur une interface HMI directement
intégrée dans son environnement de programmation. Les processeurs actuels
sont tellement puissants qu’une seule CPU peut se charger - moyennant une
programmation OO - tant de la tâche de commande que de la tâche HMI.
Exemples d’applications
Depuis les premières explorations prudentes, diverses applications ont été
réalisées avec la méthode OO. Les collègues suscitent l’enthousiasme
d’autres collègues et les intégrateurs de système apprécient les avantages
de la réutilisation, les possibilités multi-développeur et l’indépendance
de la plate-forme.
Une foreuse relativement simple qui doit déplacer un bout de métal et
forer des trous avec un point de réglage. Une trancheuse pour le
fromage/la charcuterie/le pain qui doit être réglée en fonction de
l’épaisseur de coupe, du poids, de la présentation. Une scelleuse
d’emballage vertical plein pour l’emballage de chips, bonbons, légumes…
laissant le choix entre un entraînement servo, à courant triphasé ou
hydraulique. Un autoclave, des robots multi-axe. Un élevage de vaches
laitières nécessitant plusieurs régulations de vannes identiques, une
station météo et une commande d’éclairage. Une trieuse permettant au
client de déterminer lui-même le nombre d’unités de sortie, chaque unité
se matérialisant par le simple rajout d’une classe à partir de la
bibliothèque, en fonction de la quantité souhaitée. Ou encore une
bobineuse avec une cisaille à la volée, une balance industrielle, une
planteuse, une machine de traitement de pâte, des éplucheuses d’oignons…
Même des machines assez simples profitent de la méthode OO.
Remarque finale
La disponibilité d’outils de programmation OO ne fera qu’augmenter dans
les prochaines années. Les étudiants disposent en effet de ce bagage en
fin d’études et sont habitués à réfléchir dans ces structures. Pour les
programmeurs de PLC actuels, l’appropriation de cette technique
constituera un nouveau défi. Pas de doute qu’ils y parviendront. En effet,
le pas du registre à décalage à la matrice et au struct a également été
réussi le siècle dernier.<<
|