pr ctiques de suport - xtec · 2.2.2 configuració de la xarxa mpi . creació de material didàctic...

Creació de material didàctic de suport als continguts curriculars Curs 2009-2010 relacionats amb les màquines de fabricació flexible. Josep Cañigueral i Barnés Llicència d’estudis retribuïda modalitat B3 IES SEP la Garrotxa

1

PRÀCTIQUES DE SUPORT

PER A LA PROGRAMACIÓ

DELS PLCS


2

INDEX

1 INTRODUCCIÓ................................................................................................................................... 4

2 SIEMENS - COMUNICACIONS MPI ................................................................................................ 5

2.1 ESPECIFICACIONS...................................................................................................................................5

2.2 CONFIGURACIÓ........................................................................................................................................6

2.2.1 Creació del projecte........................................................................................................................6

2.2.2 Configuració de la xarxa MPI......................................................................................................10

2.2.3 Configuració de la comunicació MPI .........................................................................................13

2.3 GESTIÓ DE LES DADES ........................................................................................................................17

2.3.1 Generalitats....................................................................................................................................17

2.3.2 Estructuració de les dades de la taula d’intercanvi ...............................................................18

2.4 PROVA DE LA COMUNICACIÓ .............................................................................................................24

2.4.1 Càrrega de taula de dades i test de la comunicació..............................................................24

3 SIEMENS – SISTEMA DE TRANSPORT DE SOLIDS AMB BOMBA DE BUIT ......................... 26

3.1 ESPECIFICACIONS.................................................................................................................................26

3.2 PLANTEIG SOLUCIÓ ..............................................................................................................................30

3.2.1 Tecnologia emprada .....................................................................................................................30

3.2.2 Llistat d’entrades sortides ...........................................................................................................34

3.2.3 Grafcet de treball total.................................................................................................................36

3.2.4 Grafcet de treball a demanda.....................................................................................................38

3.3 PROGRAMA PLC......................................................................................................................................39

3.3.1 Estructura del programa .............................................................................................................39

3.3.2 Funció de tasques vàries de PLC ...............................................................................................43

3.3.3 Funció de temporitzador a la connexió ....................................................................................47

3.3.4 Funció de control vàlvula ............................................................................................................49

3.3.5 Funció de gestió vàlvules ............................................................................................................55

3.3.6 Funció de control de motor.........................................................................................................58

3.3.7 Funció de gestió del transport....................................................................................................66

3.3.8 Funció de gestió d’ordres en automàtic ...................................................................................92

3.3.9 Funció de gestió de cua de peticions ......................................................................................101

3.3.10 Funció de gestió de mode de treball a demanda .................................................................104

3.3.11 Terminal d’operador i prova del programa............................................................................122

4 ANNEXOS ....................................................................................................................................... 130

4.1 ANNEX 1 – COMUNICACIÓ MPI ........................................................................................................130

4.1.1 Generalitats..................................................................................................................................130


3

4.1.2 Comunicació per intercanvi de dades globals.......................................................................131

4.1.3 Programa exemple per intercanvi de dades globals ...........................................................140

4.1.4 Comunicació MPI per funcions de comunicació ....................................................................141

4.1.5 Programes exemple amb funcions de comunicació.............................................................148

4.2 ANNEX 2 – INTRODUCCIÓ A SCL.....................................................................................................149

4.2.1 Generalitats..................................................................................................................................149

4.2.2 Un primer exemple .....................................................................................................................149

4.2.3 Funcions matemàtiques i de conversió. .................................................................................154

4.2.4 Tractament de dades en llistes i matrius. .............................................................................195


4

1 INTRODUCCIÓ

L’objectiu principal d’aquest conjunt de pràctiques és la de servir de guia per abordar la programació

d’aplicacions d’automatització industrial. Malgrat que l’objectiu de la llicència està enfocat a la creació de

material de suport per a les màquines de fabricació flexible, a nivell industrial hi ha també altres aplicacions que

no tenen res a veure amb les MFF. Amb la pretensió de donar una visió més amplia al treball he seleccionant

una pràctica que no correspon a una aplicació de MFF, malgrat això hi ha molts elements comuns i fàcilment

traslladables. En concret hi ha dues pràctiques explicades pas a pas, de les quals acompanyem el programa en

suport informàtic. La primera és una pràctica de comunicació entre PLCs desenvolupada sobre els quatre PLCs

de la cèl�lula MPS-C de Festo. La segona està basada en un procés industrial molt senzill com és, un transport

de sòlids amb bomba de buit.

Aquesta segona aplicació m’ha facilitat el treball amb sinòptics, que he desenvolupat a la solució proposada

per donar una visió més industrial de l’aplicació. En els sinòptics fets sobre un terminal d’operador de 5

polsades podem introduir problemàtiques presents a qualsevol aplicació industrial, alarmes, modes de marxa,

ajustos de paràmetres, etc.

La pràctica de comunicació escollida representa una solució exclusivament per l’intercanvi de dades entre

PLCs. En cap cas s’aborda la solució de l’automatització d’una estació concreta. Ara bé, el projecte generat, que

també es lliura com a documentació addicional del treball en suport informàtic, serveix de base per a abordar

l’automatització de les 4 estacions descrites a l’exercici 1. S’ha abordat la tecnologia MPI, menys abordada per

altres treballs realitzats per col�legues de professió sobre el mateix equipament. La tecnologia emprada és del

fabricant SIEMENS donat que el principal equipament disponible és la cèl�lula MPS-C de FESTO, que utilitza

tecnologia d’automatització de l’esmenta’t fabricant.

Les dues pràctiques descrites han estat provades bé amb PLCs reals, be amb PLCs de CPUs simulades com

les que incorporen les plataformes de programació de la majoria de fabricants.

A banda de l’anomenada tecnologia Siemens que és la que usem en tot aquest document, per les raons

que ja he esmentat, he de dir que la pràctica de l’aplicació que es presenta podria ser solucionada amb altres

tecnologies com Omron, Schneider, també presents a les escoles i industries del país. Malgrat l’elecció, vull

deixar clar que l’important no és la tecnologia emprada, si no que el que realment importa és la solució

concreta donada per a una aplicació d’automatització industrial. De fet molts fabricants de maquinària han de

construir la mateixa màquina emprant tecnologies diferents, pels desitjos dels seus clients. Evidentment

l’important és la màquina, no si el PLC és un Siemens, un Omron, un Schneider o qualsevol altra.

Finalment per a poder seguir aquestes pràctiques cal tenir un nivell bàsic de coneixement de les

plataformes de programació de Siemens. Concretament he treballat amb STEP7 V5.4 + SP5 i amb el

WinCCFlexible 2008 + SP2


5

2 SIEMENS - COMUNICACIONS MPI

2.1 ESPECIFICACIONS

Treballem sobre la cèl�lula MPS-C de FESTO amb versió de 4 estacions. Les 4 estacions són 1, 2, 3 i 7

anomenades distribució, verificació, procés i classificació. Malgrat que les 4 estacions incorporen en els seus

panells de control la possibilitat de passar-se senyals digitals entre elles interconnectant sortides digitals del

PLC d’una estació amb entrades digitals del PLC d’un altra estació i a l'inrevés, es planteja una alternativa molt

mes potent emprant una comunicació per xarxa MPI. El qualificatiu potent fa referència a la rapidesa de la

comunicació de dades i a la quantitat d’informació que pot esser transmesa.

La comunicació sèrie MPI és un sistema propietari de Siemens que treballa amb norma RS485 i que permet

comunicar fàcilment PLCs i altres dispositius de Siemens aptes per a comunicar-se, a una velocitat màxima de

187,5 kbauds, sense haver d’adquirir targes addicionals amb processadors de comunicació.

Dels dos sistemes possibles per a establir la comunicació emprarem el que s’anomena intercanvi de dades

globals perquè el volum d’informació es relativament petit i perquè necessitem que l’intercanvi es produeixi de

manera continuada.

Si es necessita refrescar la base teòrica d’aquest sistema de comunicació, podeu consultar l’annex 1


6

2.2 CONFIGURACIÓ

2.2.1 Creació del projecte

Comencem per crear un projecte que anomenem COM_MPI i inserir 4 PLCs Siemens S7-300 amb la CPU

que incorpora cadascuna de les estacions de la cèl�lula MPS-C de FESTO.

Figura 2.1 – Creació de projecte i inserció de 4 PLCs

A continuació canviem el nom de cadascun dels PLCs per a relacionar-los amb el nom de cadascuna de les

estacions. D’aquesta forma cada PLC queda associat a la seva estació.

Figura 2.2 – Associar cada PLC a la seva estació dins la cèl�lula

Observar com en començar el nom per PLC00x, els PLCs queden situats en l’ordre que més ens interessi.

Després d’introduir el nom dels quatre PLCs el projecte ens queda amb l’aspecte que podem veure a

continuació. El proper pas és configurar el hardware de cadascun dels PLCs.


7

Per accedir a l’aplicatiu de configuració del hardware, cal seleccionar un PLC concret i a la finestra de la

dreta fer doble clic sobre “hardware”.

Figura 2.3 – Aspecte del projecte previ a la configuració del hardware de cada PLC

En obrir l’aplicatiu per a configuració del hardware cal obrir la llibreria etiquetada amb perfil “estàndard” i

seleccionant la carpeta “SIMATIC 300” començar per inserir un bastidor. Seleccionem la fila 2 del bastidor

destinada a la CPU i seleccionem del catàleg la que vingui amb les estacions de la cèl�lula, comprovant que les

referències siguin idèntiques per a evitar tenir posteriorment problemes de compatibilitat alhora de carregar les

configuracions.

Figura 2.4 – Inserció de la cpu

La majoria de les cpus subministrades amb les estacions MPS-C de Festo són la 313C-2DP de la gama S7-

300 de SIEMENS. Aquestes cpus incorporen de sèrie un port de comunicació profibús que no utilitzarem en

aquesta pràctica. És per això que quan ens sol�liciti la configuració del port profibús, immediatament després de

la inserció de la cpu, direm que no el connectarem, acceptant l’opció que ve per defecte “no conectado a red”.

La cpu esmentada porta de sèrie un nombre suficient d’entrades sortides digitals per a abordar

l’automatització de les estacions de la MPS-C, per la qual cosa no cal afegir cap altra mòdul d’entrades sortides.


8

El hardware d’una estació resta com mostra la figura que segueix, després d’afegir a la fila 1 una font

d’alimentació PS-300 de 2 ampers.

Figura 2.5 – Configuració del hardware del PLC de l’estació de distribució

Donat que la resta de configuracions són idèntiques a la descrita, podem completar la configuració del

hardware del projecte copiant la configuració descrita a la resta de PLCs.

Figura 2.6 – Copiar una configuració entre PLCs


9

Per això només cal seleccionar el bastidor des de la seva barra de títol i amb el botó dret de la rata escollir

copiar des d’una configuració i pegar a l’altra configuració.

L’aspecte del projecte amb les quatre configuracions completades és la que mostra la figura següent:

Figura 2.7 – Projecte amb el hardware dels quatre PLCs configurat

El que s’ha realitzat fins ara no permet encara que les cpus dels diferents PLCs intercanviïn dades, donat

que manca configurar la xarxa de comunicació MPI. El següent apartat mostra els passos a seguir per a

configurar la xarxa.


10

2.2.2 Configuració de la xarxa MPI

Malgrat que podríem configurar la xarxa MPI des de la configuració del hardware de cadascuna de les

estacions, resulta més adequat emprar l’aplicatiu “configurar red” al qual s’accedeix amb el botó

Després d’arrencar, el programa ens mostra els 4 PLCs i la xarxa MPI sense cap mena de connexió amb els

PLCs.

Figura 2.8 – Finestra inicial de l’aplicació “configurar red”

Es poden observar els dos ports de comunicació de cadascuna de les cpus: Amb un quadret vermell el port

MPI i amb un quadret lila, el port profibús DP. Es pot observar també com les adreces de tots els ports són

idèntiques. Quan es connecti més d’un PLC a la xarxa, les seves adreces no podran coincidir. Per a connectar

un PLC a la xarxa, cal marcar i arrossegar el quadret vermell fins a la posició de la línia vermella que simbolitza

la xarxa MPI.

Figura 2.9 – Connexió dels PLCs a la xarxa MPI


11

Després de la connexió dels 4 PLCs, els 4 nodes han agafat de manera automàtica números correlatius, que

poden esser canviats fent doble clic sobre el quadret vermell de connexió del PLC.

Figura 2.10 – Els quatre PLCs de MPS-C connectats a la xarxa

Després d’aquest pas cal desar i compilar la configuració de la xarxa, fent “Guardar y compilar” del menú “red”

Figura 2.11 – Desar i compilar la configuració de la xarxa

Si el resultat de la compilació ha estat correcte, l’aspecte de la finestra canvia i mostra un canvi en el color

dels PLCs. Si amb posterioritat afegíssim un canvi en aquesta configuració caldria repetir el procés de desar i

compilar.


12

Figura 2.12 – Resultat de desar i compilar la configuració de la xarxa

Arribats a aquest punt carregarem la configuració del hardware als PLCs. Carreguem individualment la

configuració de cada PLC, unint el cable PC-Adapter a cada PLC individualment. Un cop completada aquesta

operació, “ver” “estaciones accesibles” amb el cable MPI connectat als quatre PLCs i amb aquests alimentats,

ens hauria d’ensenyar els quatre nodes 2, 3, 4 i 5 configurats. A partir d’aquest moment des d’un sol punt

podem accedir a canviar la configuració i el programa de qualsevol dels quatre PLCs connectats.

En aquesta xarxa de 4 PLCs hi podríem tenir un altra PC amb l’administrador simàtic connectat per tal de

tenir dos punts de configuració programació dels 4 PLCs. L’únic requisit és que els nombres de nodes

d’aquestes estacions fossin diferents. Per defecte l’adreça del PC és la 0, pel que caldria modificar l’adreça de

l’altra PC i posar-la diferent de 0, 2, 3, 4 i 5.

Per a completar la configuració cal definir les àrees de memòria per a realitzar l’intercanvi de dades globals.


13

2.2.3 Configuració de la comunicació MPI

Per a configurar la comunicació de dades MPI, via intercanvi de dades globals cal definir les dades a

intercanviar. No es necessari escriure programa, si no que cal entrar en una opció anomenada “definir datos

globales”, des de per exemple el mateix aplicatiu NETPRO o “configurar red”, descrit a l’apartat anterior.

Concretament cal clicar sobre la xarxa MPI amb el botó dret de la rata i prémer sobre “definir datos globales”

Figura 2.13 – Entrada a configuració de l’intercanvi de dades

Ens apareix la taula de la figura:

Figura 2.14 – Introducció de les cpus que hauran d’intercanviar dades


14

El primer que cal fer en aquesta taula, és introduir a les diferents columnes les cpus del projecte que

hauran d’intercanviar dades. Per això cal prémer amb el botó dret de la rata sobre la capçalera de la columna i

quan ens apareix el botó cpu clicar sobre ell. Se’ns desplega una finestra per a seleccionar el projecte on estan

les cpus que han de comunicar-se i anem obrint l’estructura del primer PLC fins a seleccionar la cpu. Fent doble

clic se’ns posa el nom del PLC i el tipus de cpu a la capçalera de la columna.

Figura 2.15 – Selecció de les cpus dins la taula de dades globals

Un cop tenim, en el nostre cas, les quatre cpus col�locades a la taula de dades globals podem començar a

entrar les adreces concretes on seran les dades a intercanviar entre els PLCs.

Figura 2.16 – Entrada de les adreces de memòria on hi han les dades a intercanviar

Concretament en aquesta primera línia de la taula, es vol configurar que les dades, que a l’estació 1 són a

l’adreça DB1.DBD0 passin a la resta d’estacions també a la mateixa adreça. Manca a la figura anterior un petit

detall que és configurar la casella a sota del PLC de distribució com a “emisor”. Amb això, les dades que el

PLC01 escrigui a db1.dbd0, seran vistes per la resta de PLCs a la mateixa adreça.


15

En aquesta taula no es contempla adreçament simbòlic, per la qual cosa es convenient escriure en el

contenidor de dades corresponent noms simbòlics que fessin més interpretables les dades procedents de la

comunicació. A l’apartat 2.3 s’introdueix una possible forma de fer-ho

Després de marcar com a emissora una de les CPU (De fet només es possible marcar una emissió dins de

cada fila) l’aspecte de la taula és el de la següent figura

Figura 2.17 – Fila correctament configurada dins de la taula de dades globals

Tot i que es possible treballar amb un sol DB per a tot l’intercanvi de dades, en aquest exercici hem definit

un DB per a cadascuna de les estacions, així el DB1 és el que escriu l’estació 1, el DB2 el que es escrit per

l’estació 2 i així successivament. Amb aquest criteri finalitzem la configuració de la taula de dades globals que

acabarà tenint l’aspecte que segueix.

Figura 2.18 – Taula de dades globals completament configurada

Arribats a aquest punt cal compilar la taula per comprovar bàsicament que no es sobrepassin la quantitat

màxima de cercles GD o de línies GD permeses.


16

L’opció esmentada es troba al menú “Tabla GD” opció “Compilar” a la que també es pot accedir amb el boto

corresponent de la barra d’eines.

En finalitzar la compilació, un missatge ens indica el seu resultat per poder continuar o corregir la

declaració.

Figura 2.19 – Compilació de la taula de dades globals


17

2.3 GESTIÓ DE LES DADES

2.3.1 Generalitats

Alhora de definir la taula de dades globals s’ha declarat per a cada línia un paquet DB1.DBD que representa

un paquet de 32 bits, que és la grandària màxima que podem introduir en una sola línia. Resta per part del

programador o programadors de l’aplicació la interpretació dels paquets de dades corresponents. Una de les

opcions és programar fent servir adreçament absolut tenint sempre en memòria, del programador, l’ús al que

es vol destinar un grup de bits concret, del total de 64 que intercanviem per estació. Podríem escriure

programa de la manera que es mostra a la figura següent

Figura 2.20 – Adreçament absolut amb dades provinent de la taula de dades global

El programa elaborat d’aquesta forma podria funcionar però seria poc llegible i sens dubte difícil de seguir,

fins i tot pel programador que l’hagués elaborat havent passat un cert temps des de la posta en marxa.

El que proposo a les pàgines següents és definir una estructura de dades que serveixi per estructurar les

dades que ha d’intercanviar cada estació. Hi han moltes solucions per definir aquesta estructura de dades i

definir-ne una de concreta ens obligaria a aprofundir en la seqüència de cada estació, cosa que no és l’objectiu

de la pràctica. Enlloc d’això hem definit una estructura de dades genèrica que farem servir idèntica per a cada

estació.


18

2.3.2 Estructuració de les dades de la taula d’intercanvi

El primer que cal fer és definir a cadascun dels PLC, els blocs de dades DB que contindran les dades

definides a la taula d’intercanvi de dades globals.

Figura 2.21 – Inserció de blocs de dades DB a la carpeta bloques dels PLC

A la finestra que apareix a continuació cal donar un nom simbòlic al DB de nova creació. Això es

imprescindible per a poder treballar amb adreçament simbòlic en cas de dades provinents d’un DB.

Figura 2.22 – Donar noms simbòlics als DB de dades de la taula de dades globals


19

Un cop hem inserit els 4 DB podem passar a definir la seva estructura. Fent doble clic sobre el DB se’ns

obra l’editor de línies del DB. De fet es tracta del mateix editor KOP que emprem per elaborar codi de programa

en diagrama de contactes.

Figura 2.23 – Editar la declaració de variables del DB

La primera vegada que obrim el DB després de la seva creació apareix una única línia etiquetada com a

variable provisional. Aquesta línia s’esborra i comencem a editar la nostra declaració.

Figura 2.24 – Declaració de variables dins el DB

Aquesta és una de les formes d’omplir la declaració de variables dins un DB. Si a més com s’ha dit abans

volem fer idèntiques les declaracions, podem completar una declaració i fer copiar i pegar a la resta dels DB

d’una estació.

Un cop completats els DB d’una estació podem fer copiar i pegar sobre els 4 DB d’aquesta estació a les tres

estacions restants i tenim completada tota l’estructura de dades.


20

Un altra forma de fer la declaració de l’estructura de dades d’un DB és emprant els tipus de dades d’usuari

o UDT. Això ens permet, un cop definit el UDT, fer la declaració de les dades d’un DB amb l’edició d’una sola

línia dins el DB.

En aquesta pràctica ho farem d’aquesta forma per treballar amb els UDT. El primer que cal fer és inserir un

UDT dins la carpeta bloques d’un PLC i editar-lo.

Figura 2.25 – Inserció d’un UDT

Figura 2.26 – Edició propietats i nom simbòlic del UDT


21

La declaració de variables del UDT es fa de manera idèntica a com es fa en un DB. Cal tenir en compte però

que un UDT no es pot bolcar al PLC com es fa amb un DB. El UDT serveix en aquest cas per facilitar la

declaració de variables dels diferents DB.

A tall d’exemple, sense tenir la pretensió de representar l’estructura de dades necessària per a definir la

comunicació de dades entre les quatre estacions de la cèl�lula s’ha fet l’estructura que segueix amb la pretensió

d’il�lustrar de manera clara el procediment.

Figura 2.27 – Declaració de tipus de variables del UDT

Cal observar que la declaració que s’ha fet no fa referència a cap estació concreta, d’aquesta forma aquesta

declaració pot servir per a totes les estacions. Quan treballem el programa de cada estació el nom del DB ens

indicarà l’estació a la que correspon.

Per a utilitzar el UDT en la declaració de variables d’un DB concret, cal emprar com a tipus de dades d’una

línia concreta de la declaració del DB el número o el nom del UDT.

Figura 2.28 – Declaració de variables de DB emprant UDT


22

Igual que en la declaració d’un tipus simple cal donar un nom a la variable declarada. En aquest cas s’ha

donat el nom TDG de taula de dades globals, que serà el que sortirà quan referenciem en el programa una

variable que correspongui a aquesta estructura.

Per veure els elements de l’estructura cal anar al menú “ver” i prémer sobre “datos”

Figura 2.29 – Activar la vista dades d’una estructura de dades

Que dóna com a resultat

Figura 2.30 – Dades de l’estructura TGD declarada dins DB_DADES_E1 com a tipus UDT1

Per a completar la estructuració de les dades de l’intercanvi de dades globals que afecten tota la cèl�lula cal

repetir l’operació feta amb DB1 per a la resta de DB del PLC de distribució, per exemple. Després podem copiar

els 4 DB als tres PLC de la resta d’estacions. Juntament amb els 4 DB es necessari copiar també la UDT ja que

si no el tipus corresponent no seria reconegut.


23

L’aspecte del programa havent fet tots aquests canvis queda molt més documentat i es molt més fàcilment

interpretable fins i tot per programadors que no hagin vist anteriorment l’aplicació.

Figura 2.31 – Adreçament simbòlic amb dades provinents de la taula de dades globals

Després d’haver configurat la comunicació i d’haver estructurat les dades que hi intervenen cal carregar la

configuració i els DB a cadascun del 4 PLC i fer el test de la comunicació.

Un cop la comunicació sigui en funcionament es pot abordar la programació de les 4 estacions fent un

plantejament previ per redefinir les dades a intercanviar. Això implicarà redefinir la UDT, copiar-la a cada PLC i

actualitzar la declaració dels DB.


24

2.4 PROVA DE LA COMUNICACIÓ

2.4.1 Càrrega de taula de dades i test de la comunicació

La càrrega de la taula s’ha de fer des de l’opció “cargar” del menú “sistema destino”. La taula s’ha de

carregar a les 4 estacions per la qual cosa es convenient que prèviament hàgim completat la configuració del

hardware de cada PLC i hàgim unit els 4 en una xarxa MPI. Des del menú “ver” “estaciones accesibles” de

l’Administrador Simatic hauríem de veure els 4 PLC. En aquestes condicions podem fer la càrrega de la taula

Figura 2.32 – Càrrega de la taula de dades globals

A mesura que es va produint la càrrega a les diferents CPU se’ns informa que cal posar en stop la CPU i ens

demana autorització per a fer-ho. Acabada la càrrega ens demana autorització per a posar en marxa altra cop

la CPU.

Completada la càrrega a les 4 CPU l’intercanvi de dades globals funcionarà de manera automàtica. Per a

comprovar-ho podem visualitzar el DB1 de l’estació de distribució i el DB1 de qualsevol dels altres tres PLC. Un

canvi fet a DB1 de distribució s’ha de veure immediatament reflectit al DB1 de l’altra estació.


25

A la figura següent es poden veure dues taules de variables VAT que permetrien veure els dos DB esmentats

Figura 2.33 – Test de la comunicació amb intercanvi de dades globals


26

3 SIEMENS – SISTEMA DE TRANSPORT DE SOLIDS AMB BOMBA DE BUIT

3.1 ESPECIFICACIONS

Es tracta d’automatitzar un sistema de transport de sòlids, destinat a recollir restes de diferents punts de

treball d’un procés productiu i transportar-les fins a un dipòsit de recollida, que a la vegada descarrega sobre

un contenidor, que quan és ple es recollit i canviat per un transport mecànic. El sistema està format amés del

dipòsit, per una bomba de buit, per una vàlvula de descàrrega de seguretat o de descompressió, associada a la

bomba, per una comporta de buidat del dipòsit i per fins a 6 vàlvules que obren el pas de cadascun dels sis

punts de recollida. Esquemàticament el sistema està representat a la figura 3.01

Figura 3.01 – Esquema general de la instal�lació

Estan representats els elements esmentats amb els seus tags. El sistema ha de tenir dos funcionaments

anomenats total i a demanda. En mode total, les comportes dels aspiradors es van obrint una darrera l’altra, de

manera seqüencial començant per AV1, acabant amb AV6 i tornant a començar per AV1, repetint la seqüència

fins que el sistema s’aturi o es canviï de mode de funcionament. Cada dues recollides cal buidar el dipòsit, per

evitar excessiva acumulació. La seqüència concreta ha de ser: Arrencar bomba BO1, tancar VD, tancar VB,

esperar un temps per crear buit, obrir VA1, esperar el temps consignat com a buidat del lloc 1, tancar VA1,

obrir VA2, esperar el temps consignat com a buidat del lloc 2, tancar VA2, aturar bomba, obrir VD, obrir VB i

esperar temps consignat com a buidat del dipòsit. A continuació cal repetir la seqüència per VA3 i VA4 i per VA5

i VA6 i haurem completat un cicle complert del transport, en el mode total. Tal com s’ha dit el sistema anirà

repetint cicles fins que aturem el transport o hi hagi un canvi de selecció de mode de funcionament.

En el mode a demanda els 6 llocs de treball on es produeixen els residus a transportar, poden sol�licitar

servei del transport de manera individual, amb un polsador situat en el mateix lloc de treball. En aquest mode

de funcionament el control haurà de memoritzar les peticions de servei que es vagin efectuant, com a màxim

una per lloc de treball, i anar donant servei als diferents llocs, en el mateix ordre en que s’ha produït la petició.

En el hipotètic cas que tots 6 llocs sol�licitessin servei al mateix temps, el transport estaria carregant un lloc i la

resta restarien en espera de servei a la cua de peticions. En aquest mode, la descàrrega del dipòsit es faria

també cada dues càrregues o en finalitzar la darrera càrrega si la cua de peticions és buida.

A més dels dos modes de funcionament esmentats, cadascun dels elements de la instal�lació podrà posar-

se en manual o automàtic. Només si tots els elements estan en automàtic podrem seleccionar algun dels dos

modes de treball descrits anteriorment.


27

El manual està previst per a poder provar un dispositiu de manera individual, principalment per part del

personal de manteniment de la planta. Totes les operacions descrites es poden efectuar des d’un terminal

d’operador (pantalla tàctil de 5 polsades) connectat amb el PLC de control de la instal�lació.

A les figures següents es mostra, evidentment amb la solució prevista per l’autor que per descomptat

podria tenir presentacions i formats diferents, el procediment per a posar la bomba i una vàlvula de càrrega en

manual, testejant el seu funcionament. Prement sobre el dispositiu, en aquest cas la bomba, ens apareix una

finestra de control del dispositiu que està composta d’un títol que fa referència a l’element que es controlat, un

interruptor per a situar-lo en manual o en automàtic, un polsador per forçar la marxa en manual, un polsador

per a aturar el dispositiu, un polsador per esborrar alarmes i un polsador per tancar la finestra de control.

Figura 3.02 – Obrim finestra de control bomba. S’indica estat automàtic

Figura 3.03 – Premem interruptor d’estat, posant-lo en manual. S’indica estat manual a la finestra i sobre el

dispositiu

Prement el polsador de marxa manual el dispositiu arrencarà si hi ha les condicions per a fer-ho o es

posarà en alarma. El motor indicarà els estats d’aturat, marxa o en alarma.


28

Figura 3.04 – Premem marxa manual. Indiquem estat dispositiu i ordre de marxa activa a la finestra de control

Quan la bomba confirma marxa, les canonades canvien de color indicant presencia de buit o transport

actiu. Prement sobre una vàlvula qualsevol s’obre la seva finestra de control permetent igual que amb la

bomba, posar-la en manual o en automàtic i en cas que sigui en manual podem obrir-la i tancar-la amb els

corresponents controls manuals.

Figura 3.05 – Control en manual de vàlvula. Obertura manual de A1

Quan la vàlvula, amb el fi de cursa corresponent rep la confirmació d’obertura, la vàlvula senyalitza aquest

estat, mentre que des de la finestra de control es senyalitza l’estat de l’ordre d’obertura. En el cas de les

vàlvules cal senyalitzar els estats de vàlvula oberta, tancada o en alarma per manca de confirmació dels fi de

cursa de posició.

Finalment a la figura següent veiem com en confirmar estat d’obertura la vàlvula VA1, la canonada del lloc

1 canvia de color, indicant que està en càrrega.


29

Malgrat el procediment descrit per a fer treballar els dispositius en manual, això només serà emprat per

part del personal de manteniment per a fer tests periòdics dels dispositius. La instal�lació funcionarà

normalment en els modes de treball previstos de mode total o mode a demanda i per això cal que tots els

dispositius siguin en automàtic.

Figura 3.06 – Bomba i vàlvula A1 en treball manual

Totes les vàlvules portaran fi de curses de posició per a disposar de confirmació d’obertura i tancament en

el control. Les vàlvules són d’accionament pneumàtic en els dos sentits i estan controlades per electrovàlvules

5/2 biestables. El motor també portarà confirmació de marxa per a informar al control, amés d’un contacte del

guardamotor de protecció.

Els polsadors de petició descrits en el mode de treball a demanda, seran lluminosos per tal d’indicar l’estat

de la petició i càrrega en curs o no. Si està en mode total, els pilots seran tots il�luminats exceptuant el que

correspon al lloc que està en càrrega que serà en intermitència. Si està en mode a demanda els pilots seran

apagats i s’il�luminaran en el moment de fer la petició, seguint així mentre duri l’espera. Quan es produeixi la

càrrega el pilot es posarà en intermitència igual que en el mode total.

El canvi de mode de treball així com la marxa i aturada del transport es farà des del terminal d’operador.

Pel que fa al terminal d’operador haurà de presentar amés del sinòptic general de representació de l’estat

dels diferents dispositius amb la possibilitat ja descrita de control manual de cadascun d’ells, una pantalla per

entrar els temps de treball del transport, una pantalla per a gestió de les alarmes i una pantalla per a

configuracions bàsiques de PLC i terminal d’operador.


30

3.2 PLANTEIG SOLUCIÓ

3.2.1 Tecnologia emprada

S’ha escollit treballar amb tecnologia Siemens per dues raons. La primera és perquè es de les tecnologies

més esteses en l’àmbit educatiu i industrial del nostra país i segona perquè sense disposar ni de PLC ni de

terminal d’operador, es possible testejar el funcionament de tota l’aplicació fent servir els simuladors del PLC i

del programa scada necessari per a configurar el terminal d’operador.

Es treballarà per tant amb les següents eines software o programaris:

• Step7 professional v5.4 + SP5 per a programar el PLC

• WinCC Flexible 2008 + SP2 per a programar el terminal d’operador

Es important que quan s’instal�li el WinCC Flexible s’agafi l’opció d’instal�lar-lo integrat en el Step 7, ja que

això permetrà lligar les variables del PLC amb les terminal. Per fer això només cal instal�lar primer el

programari Step 7 i després el WinCC flexible, prestant especial atenció a l’esmentada opció d’integració.

Amés farem servir les següents eines d’enginyeria integrades en el paquet de programació del PLC

• S7 PLCSIM per a treballar amb un PLC virtual

• S7 SCL per a confeccionar alguna funció necessària per la solució plantejada

• S7 GRAPH per a solucionar alguna de les seqüències de l’aplicació

Malgrat escollir Siemens hi ha altres tecnologies, com per exemple Omron o Schneider, que amb un grau

d’implantació menor en l’àmbit educatiu també permetrien treballar amb eines virtuals per a fer un test complet

de l’aplicació, previ a la posta en marxa del procés.

Malgrat també, que la solució pugui ser testejada totalment, la que s’anirà exposant preveu treballar amb

PLCs i terminals d’operador que són força comuns trobar a les escoles com a material de pràctiques, cosa que

permetrà en una etapa final provar la solució sobre un sistema real. L’aspecte del projecte ja configurat és el

que mostra la figura 3.07

Figura 3.07 – Projecte configurat amb una CPU 314-2DP i xarxes MPI i profibús inserides


31

El procés per configurar el projecte amb el PLC és idèntic al exposat a l’exercici de comunicacions MPI. Hem

afegit la inserció de la xarxa profibús en el moment que en inserir la CPU se’ns demana com volem configurar la

interfase DP. Per inserir el terminal d’operador hem de seguir el procediment exposat a la figura 3.08

Figura 3.08 – Inserció del terminal d’operador en el projecte

Quan confirmem la opció mostrada se’ns obra una finestra per a seleccionar el tipus de terminal

Figura 3.09 – Seleccionem el terminal tàctil de 6 polsades TP270


32

Quan donem a acceptar se’ns insereix en el projecte el terminal d’operador seleccionat, si bé amb un nom

genèric generat pel propi WinCC flexible. Canviem el nom del terminal pel de TP270 i el projecte ens queda com

mostra la figura 3.10

Figura 3.10 – Projecte amb el terminal d’operador incorporat

Els propers passos mostren com configurar les comunicacions de PLC i terminal perquè en iniciar la

programació del terminal tinguem tots els objectes definits en el PLC, visibles des del terminal d’operador. Igual

que a l’exercici de comunicacions MPI cal arrencar l’aplicació anomenada Netpro. Disposem de dues opcions.

Figura 3.11 – Connectem PLC i terminal d’operador a la xarxa MPI, arrossegant amb el ratolí, el quadret vermell

fins a la línia de la xarxa

Amb que s’ha fet fins aquí tindrem el PLC i el terminal d’operador configurats per intercanviar dades amb

comunicació MPI. Donat que tant aquesta CPU com el terminal TP270 escollit tenen capacitat per a comunicar

també amb profibús podem configurar l’intercanvi de dades perquè sigui segons aquesta connexió.

En aquest cas la connexió del PLC ja ens ve feta des de la configuració del projecte i només ens cal fer la

connexió del terminal. Donat que físicament el connector que fa servir el terminal és el mateix tant si comunica

MPI com profibús, cal canviar la funcionalitat del connector.

En el mateix netpro, fent doble clic sobre l’àrea de la interfase de comunicació, a la representació de la

pantalla se’ns obre una finestra que permet seleccionar el tipus de comunicació desitjada.


33

Selecció de comunicació profibús en el terminal d’operador.

Figura 3.12 – Seleccionar comunicació en el terminal d’operador

Després d’acceptar, podrem connectar el terminal a la xarxa profibús i haurem completat la configuració de

la comunicació entre PLC i terminal.

Figura 3.13 – Configurar les comunicacions amb profibús i desar, amb NETPRO

Si no disposéssim de comunicació profibús a PLC hauríem d’escollir necessàriament MPI per a comunicar

PLC i terminal. Disposant d’ambdós és millor treballar amb profibús per tal de tenir més capacitat d’intercanvi

de dades. Cal recordar que MPI treballa a 187,5 kb i en canvi profibús ho fa per defecte a 1,5 Mb, poden

treballar fins i tot, a 12 Mb.


34

3.2.2 Llistat d’entrades sortides

D’acord amb les especificacions donades s’han previst les següents sortides: 16 per obrir i tancar les 8

vàlvules de procés, 1 per l’ordre de marxa de la bomba, 1 pel pilot de senyalització d’alarmes actives i 6 pels

pilots de senyalització de treball dels diferents aspiradors.

LLISTAT DE SORTIDES DEL PLC ALARMES_H A 4.0 Pilot senyalització d'alarmes BO_TRANS_OM A 4.1 Bomba transport - Ordre de marxa ASP1_STREB_H A 4.2 Aspiració 1 - Pilot de senyalització de treball ASP2_STREB_H A 4.3 Aspiració 2 - Pilot de senyalització de treball ASP3_STREB_H A 4.4 Aspiració 3 - Pilot de senyalització de treball ASP4_STREB_H A 4.5 Aspiració 4 - Pilot de senyalització de treball ASP5_STREB_H A 4.6 Aspiració 5 - Pilot de senyalització de treball ASP6_STREB_H A 4.7 Aspiració 6 - Pilot de senyalització de treball VLV_ASP3_OB A 124.0 Vàlvula aspiració 3 - Ordre d'obrir VLV_ASP3_OT A 124.1 Vàlvula aspiració 3 - Ordre de tancar VLV_ASP4_OB A 124.2 Vàlvula aspiració 4 - Ordre d'obrir VLV_ASP4_OT A 124.3 Vàlvula aspiració 4 - Ordre de tancar VLV_ASP5_OB A 124.4 Vàlvula aspiració 5 - Ordre d'obrir VLV_ASP5_OT A 124.5 Vàlvula aspiració 5 - Ordre de tancar VLV_ASP6_OB A 124.6 Vàlvula aspiració 6 - Ordre d'obrir VLV_ASP6_OT A 124.7 Vàlvula aspiració 6 - Ordre de tancar VLV_DESC_OB A 125.0 Vàlvula descompressió - Ordre d'obrir VLV_DESC_OT A 125.1 Vàlvula descompressió - Ordre de tancar VLV_BUIDAT_OB A 125.2 Vàlvula buidat - Ordre d'obrir VLV_BUIDAT_OT A 125.3 Vàlvula buidat - Ordre de tancar VLV_ASP1_OB A 125.4 Vàlvula aspiració 1 - Ordre d'obrir VLV_ASP1_OT A 125.5 Vàlvula aspiració 1 - Ordre de tancar VLV_ASP2_OB A 125.6 Vàlvula aspiració 2 - Ordre d'obrir VLV_ASP2_OT A 125.7 Vàlvula aspiració 2 - Ordre de tancar


35

Pel que fa les entrades hi ha les següents: 16 pels finals de cursa de les 8 vàlvules, i 10 més pels senyals

del guardamotor i de la confirmació de marxa de la bomba, el polsador d’esborrat d’alarmes, el polsador

d’emergència i els 6 polsadors de treball a demanda, dels aspiradors.

LLISTAT D’ENTRADES DEL PLC

VLV_ASP3_FCO E 124.0 Vàlvula aspiració 3 - Fi de cursa d'obertura

VLV_ASP3_FCT E 124.1 Vàlvula aspiració 3 - Fi de cursa de tancament







VLV_DESC_FCO E 125.0 Vàlvula descàrrega - Fi de cursa d'obertura

VLV_DESC_FCT E 125.1 Vàlvula descàrrega - Fi de cursa de tancament

VLV_BUIDAT_FCO E 125.2 Vàlvula buidat - Fi de cursa d'obertura

VLV_BUIDAT_FCT E 125.3 Vàlvula buidat - Fi de cursa de tancament





RESET_ALM_S E 126.0 Polsador de reset alarmes

BO_TRANS_GM_OK E 126.1 Bomba transport - Guardamotor okey

BO_TRANS_CM E 126.2 Bomba transport - Confirmació de marxa

EMERGENCIA_S E 126.3 Polsador d'emergència

ASP1_ADEM_S E 126.4 Aspiració 1 - Polsador de treball a demanda







36

3.2.3 Grafcet de treball total


37

El diagrama anterior és el grafcet del mode de treball total, on per tractar-se d’accions repetitives els

passos per arrencar la bomba i els corresponents al buidat del tanc s’han representat com a macroetapes, de

les quals es representa el seu detall tot seguit.

A la macroetapa M1 tanquem les vàlvules de buidat tanc i de descompressió, arrenquem la bomba i

confirmem el buit i a la macroetapa M2 aturem la bomba i buidem el tanc.


38

3.2.4 Grafcet de treball a demanda

La seqüència del mode de treball anomenat a demanda, aprofita les mateixes macroetapes descrites al

mode de treball total, si bé l’estructura es força diferent. El cicle comença quan es seleccionat el mode de

treball que es descriu. Quan hi ha alguna petició en espera, si no hi ha cap problema que impedeixi el

funcionament del transport, arrenquem la bomba i esborrem el comptador de càrregues que ens servirà per

gestionar el buidat del tanc. Quan la bomba ha confirmat arrencada llegim a la cua de peticions el numero de

lloc que porta més temps en espera. Aquest número ens servirà per escollir una de les 6 branques de la

selecció de seqüència posteriors a l’etapa 41. Finalitzada la càrrega del lloc, ens podem trobar que: hàgim fet

dues càrregues o que n’hàgim fet una i que tinguem la cua de peticions buida ( ambdues situacions faran que

passem a buidar el tanc) o que portem una càrrega i que la cua de peticions no sigui buida cosa que farà que

iniciem una nova càrrega abans de passar a buidat.


39

3.3 PROGRAMA PLC

3.3.1 Estructura del programa

El programa del PLC s’estructura a partir de OB1 (Bloc de programa d’organització 1), com es usual a la

majoria de controladors de Siemens. D’aquí fins a completar el programa, es poden donar moltes solucions per

a fer funcionar el sistema, totes valides mentre compleixin amb les especificacions donades. Malgrat això

qualsevol enginyeria que treballi en el camp de l’automatització industrial, ha de fer un esforç important per

donar una estructura i unes maneres de treballar similars, per tal que tots els programes s’acabin semblant.

Això és especialment important per reduir el temps de programador necessari per a futures intervencions en el

programa, més tenint en compte, que aquestes poden estar fetes per programadors diferents, dels que van

programar la primera versió. Cal considerar que un programa ben estructurat amb unes dades també

correctament definides i estructurades és molt més fàcil de mantenir. De fet a les enginyeries s’acaba

treballant amb un o varis projectes plantilla confeccionats seguint aquestes directrius, amb una llibreria de

funcions pròpies, que serveix de base per a començar el programa de qualsevol aplicació.

En aquest apartat proposo una estructuració concreta per a l’aplicació del transport de sòlids, amb la

pretensió de que sigui traslladable a altres aplicacions i de que ajudi a l’objectiu de confeccionar programes mes

estructurats i ben organitzats.

En primer lloc intentarem justificar el perquè de cadascuna de les funcions en que s’ha dividit el programa.

A la figura 3.14 podem veure la carpeta bloques amb tots els objectes de programa definits a l’aplicació.

Figura 3.14 – Objectes configurats a la carpeta bloques

OBs Constitueixen la interfície entre el sistema operatiu del PLC i el programa de l’usuari. Hi ha OB1 i

OB100

• OB1 és el programa principal, el que es executat de manera cíclica i seqüencial

• OB100 és el programa que s’executa únicament en el primer cicle de programa de la CPU

En executar OB1 el PLC executa totes les funcions en les que hem dividit el programa.


40

Començant per les funcions de rang superior tenim:

• FC40 “GESTIÓ TRANSPORT” Gestiona la selecció de mode de funcionament, l’engegada i aturada del

transport i els permisos de marxa.

• FC41 “GESTIÓ SEQ TOTAL” Gestiona el mode de marxa total amb la seva seqüència de funcionament.

• FC42 “GESTIÓ SEQ ADEM” Gestiona el mode de marxa a demanda amb la seva seqüència de

funcionament. Aquesta funció necessita la funció FC32 “GESTIÓ CUA PETICIONS” per recuperar de la

cua, el número dels llocs que han fet petició i encara no han estat atesos.

• FC43 “GESTIÓ ORDRES AUTO” Combina els estats dels dos modes de funcionament per obtenir les

ordres de marxa de cadascun dels dispositius del transport.

• DB40 “DB GESTIÓ TRANSPORT” Són dades associades a les anteriors funcions, especialment bits de

control, bits d’estat, bits de funcionament en automàtic de dispositius, bits d’estats de les seqüències

dels modes de funcionament, etc.

• DB41 “DB REGULA TRANSPORT” Són dades també associades a les funcions FC40, 41, 42 i 43 però

que poden classificar-se com a regulacions del procés. Tots els temps de treball dels aspiradors, tant els

valors de preselecció com els valors actuals, estan dins aquest DB

• FC30 “GESTIÓ VÀLVULES” Aquesta funció crida a la vegada a la funció FC10 “CTRL VÀLVULA”, tantes

vegades com vàlvules hi hagin a l’aplicació i controla la maniobra , l’estat i les alarmes de cadascuna

d’elles.

• DB1 “DB CTRL VÀLVULES” Són dades associades a la funció FC10 “CTRL VÀLVULA” i que bàsicament

agrupen en una estructura (UDT o tipus de dades d’usuari) totes les dades que estan relacionades amb

el control de la vàlvula des del terminal d’operador. Això permet simplificar els paràmetres de la funció

deixant-los en un nombre prudent. El UDT1 “UDT CTRL VÀLVULA” és la declaració d’aquest tipus de

dades de suport al control de vàlvula. Aquest UDT1 no constitueix codi de programa i no s’ha de

carregar a la CPU, però l’utilitzarem com es veurà més endavant per definir el DB1 i els paràmetres de

FC10.

• FC31 “GESTIÓ MOTORS” Aquesta funció crida a la vegada a la funció FC11 “CTRL MOTOR”, tantes

vegades com motors hi hagin a l’aplicació i controla la maniobra , l’estat i les alarmes de cadascun

d’ells.

• DB2 “DB CTRL MOTORS” Són dades associades a la funció FC11 “CTRL MOTOR” i que bàsicament

agrupen en una estructura UDT totes les dades que estan relacionades amb el control del motor des del

terminal d’operador. El UDT2 “UDT CTRL MOTOR” és la declaració d’aquest tipus de dades de suport al

control de motor i en servirà per definir el DB2 i els paràmetres de FC11.

• FC21 “CTRL ALARMES” Controla l’aparició d’algunes alarmes, determina si hi ha alarmes actives i

noves, gestiona la senyalització de les alarmes i el seu rearme. FC21 treballa amb DB21 “DB ALARMES”

amb l’objectiu de concentrar totes les alarmes en una mateixa àrea de dades.

• Finalment FC20 “PLC VARIS” es una funció que porta associades les dades definides a DB20 “DB PLC

VARIS” i que gestiona coses diverses del PLC: Bits de sistema, lectura del rellotge intern del PLC, canvi

de l’hora del PLC, etc.

• Ens queda per comentar únicament FC1 “TTON” que és una funció per fer un temporitzador a la

connexió amb una base de temps de segons.

A continuació descriurem amb més detall cadascuna de les funcions de l’aplicació.


41

En primer lloc mostrem el codi de OB1, on podem veure en quin ordre són cridades cadascuna de les

funcions.

En primer lloc, cridem a la funció PLC VARIS perquè alguna de les marques que gestionem, com el bit

d'impuls de segon, les necessitem al llarg del programa. A continuació cridem la funció CTRL ALARMES donat

que saber si hi ha dispositius en alarma ha de ser necessàriament previ a avaluar els permisos de funcionament

de la màquina.

A continuació cridem “GESTIÓ TRANSPORT” per avaluar els permisos, la selecció de mode i la marxa

aturada del transport.


42

Cridem “GESTIÓ SEQ TOTAL” per avaluar la marxa en mode total si està seleccionada

A continuació cridem “GESTIÓ SEQ ADEM” per avaluar la marxa en mode a demanda si està seleccionat

aquest mode i no està seleccionat el total.

Finalment cridem “GESTIO ORDRES AUTO” per obtenir les ordres de marxa en automàtic de vàlvules i

motors i tot seguit “GESTIÓ VÀLVULES” i “GESTIÓ MOTORS” per executar les ordres obtingudes.


43

3.3.2 Funció de tasques vàries de PLC

La funció que hem anomenat “PLC VARIS” l’utilitzem per obtenir les marques de “sempre_ON”,

“sempre_OFF” i per obtenir un bit que s’activi un cop cada segon i un bit que faci intermitència de mig segon.

També, dins de “PLC VARIS” cridem a la funció de sistema “READ CLK” per llegir la data i hora del rellotge

intern de la CPU que farem servir per sincronitzar els rellotges de PLC i terminal d’operador. Les funcions de

sistema són funcions que no cal carregar a la memòria del PLC perquè resideixen en el firmware de la CPU.

Malgrat això alhora de programar cal estirar-les de la llibreria i inserir-les a la carpeta bloques per tal de poder-

les utilitzar en el programa.


44

El segment 3 utilitza la marca de cicle 5 referint-se al bit 5 del byte de marques de cicle que la CPU pot

activar si es configura adequadament des del hardware de la CPU. En aquest cas s’ha configurat MB250 com a

byte de marques de cicle, tal com es pot veure a la figura 3.15

Figura 3.15 – Configuració de MB250 com a byte de marques cícliques

Si el byte de marques de cicle no estigués activat no ens funcionarien ni el bit d’intermitència ni la marca de

1 impuls cada segon.

Al segment 4 cridem la funció “READ CLK” que retorna la data i la hora del rellotge intern de la CPU en

format DT (date & time). Cal tenir present que el format DT ocupa 8 bytes i en el paràmetre corresponent de la

funció cal posar-hi una adreça simbòlica com a valor actual del paràmetre. En el nostre cas hem utilitzat el

DB20 per declarar la variable “DB_PLC_VARIS”.plc_data_hora_act que ens emmagatzemarà el valor de

resposta de “READ CLK”

La funció “READ CLK” torna també com a resposta el paràmetre “RET VAL” que ens permet avaluar si hi ha

hagut algun error a l’execució de la funció, malgrat que en el programa no utilitzem aquesta possibilitat, cal

indicar una adreça de memòria per completar la crida a la funció. En aquest cas hem utilitzat l’àrea de memòria

temporal per desar el valor de “RET_VAL”. Si observem la capçalera de la funció situada a l’àrea prèvia al

segment 1, podem veure la declaració de la variable temporal “#plc_llegir_dt_err”, que és la que hem utilitzat a

“READ CLK”.


45

Al segment 5, si està activada la marca “DB_PLC_VARIS”.plc_canviar_dt”, marca que s’activa des del

terminal d’operador, cridem a la funció “SET_CLK” que té una estructura molt similar a “READ_CLK” i que en

aquest cas ens permet posar en hora des del programa el rellotge intern de la CPU.


46

Finalment podem veure la declaració de variables a “DB_PLC_VARIS”. El fet de deixar dos words de reserva

després de cada declaració de DT es deu al fet que el terminal d’operador exigeix un area de memòria del PLC

de 12 bytes per a consultar la hora del PLC i poder sincronitzar-se amb ell.


47

3.3.3 Funció de temporitzador a la connexió

Malgrat que es podrien utilitzar els propis temporitzadors que els PLCs de la gama S7-300 de Siemens

posen a disposició dels programadors, he optat per fer una funció pròpia per disposar tant en la preselecció

com en el valor actual, de registres amb formats de dades estàndard, cosa que facilita la presentació de dades

al terminal d’operador, i la preselecció de valors de temps per part dels usuaris de la instal�lació. A la capçalera

de la funció veiem la declaració dels paràmetres i cada segment porta el seu comentari.


48


49

3.3.4 Funció de control vàlvula

S’han implementat les següents prestacions: Control en manual i en automàtic, selecció de control

monoestable o biestable, selecció individual de fi de cursa no present i en el cas que s’activi fi de cursa no

present, la confirmació es força al cap d’un temps configurable des de l’aparició de l’ordre corresponent.


50

A la declaració de variables de la funció, a l’apartat IN_OUT hi tenim la variable “ctrl_vlv” declarada amb

el tipus “UDT_CTRL_VÀLVULA”. Abans de continuar amb la funció “CTRL_VÀLVULA” veiem la declaració

d’aquest UDT.


51

Una variable que sigui dins l’estructura UDT, declarada a “CTRL_VÀLVULA” com a “ctrl_vlv” serà escrita

d’aquesta manera: Per exemple la variable “man_auto”, serà anomenada al llarg del programa com a

“#ctrl_vlv.man_auto”.


52


53


54


55

3.3.5 Funció de gestió vàlvules

És la funció que crida a “CTRL_VÀLVULA”, tantes vegades com vàlvules hi hagi a l’aplicació. Prèviament a

programar “GESTIÓ_ VÀLVULES”, cal definir l’estructura de dades UDT de cada vàlvula, donat que a l’interfase

de la funció se’ns demanarà on assignar la UDT declarada a “CTRL_VÀLVULA”. A la crida de la funció

“CTRL_VÀLVULA” del FC30, observar com s’ha assignat el paràmetre “ctrl_vlv”.


56


57

No representem la resta de crides per resultar repetitives. Es pot consultar el programa complert utilitzant

les eines de software descrites. És per això que acompanyem el programa complert de l’aplicació


58

3.3.6 Funció de control de motor

La funció de control de motor es molt similar a la funció de control vàlvula descrita a l’apartat 3.3.4 i

contempla les següents funcionalitats:

• Possibilitat de controlar manualment el motor en els dos sentits de gir, des d’un terminal

d’operador, pensat per poder provar-lo sense necessitat d’arrencar tota l’aplicació. Les ordres de

marxa en manual i el mateix control de manual automàtic es troben declarats formant part de la

UDT2 “UDT_CTRL_MOTOR” de suport a la funció “CTRL_MOTOR”, de manera similar a com ho feia

UDT1 amb la funció “CTRL_VÀLVULA”

• Ordres de marxa en automàtic també per ambdós sentits de gir, posades com a paràmetres

d’entrada de la funció

• Control de les alarmes integrat a la funció. Les alarmes que es tracten són: Alarma de proteccions

en el motor i alarmes de manca de confirmació de marxa en ambdós sentits de gir.

• Possibilitat de seleccionar un forçat de la confirmació de marxa, cosa que és especialment útil quan

hem de depurar programes, ja que ens permet fer funcionar tots els dispositius sense haver d’estar

pendent de les confirmacions de marxa.

• Disposem també d’un registre d’estat del dispositiu que ens indica: Motor aturat (0), Motor en

alarma (1) i motor en marxa (2)

A continuació inserim el codi complert de la funció que es pot seguir perfectament amb els comentaris assignats

a cada segment. Com a pas previ comentem la declaració de la “UDT_CTRL_MOTOR”, donat que la funció conte

la UDT, declarada com el paràmetre d’entrada sortida “ctrl_mot”


59

Cadascuna de les variables porta el seu comentari però podem aprofundir-hi una mica.

man_auto – Ens permet seleccionar el control del motor en manual o en automàtic

man_marxa_dreta / man_marxa_esquerra són les ordres de marxa en manual del motor

conf_marxa_dreta / conf_marxa_esquerra són les confirmacions de marxa del motor

conf_marxa_np – Si el posem a 1 ens forçarà la confirmació de marxa del motor amb un temps que podrem

ajustar des del terminal d’operador.

rset_alarm_hmi – esborrat d’alarmes del dispositiu

alarma – Estat d’alarma en el dispositiu

temps_alarma_acc – Es un registre per desar el valor actual del temporitzador de comprovació d’alarma de

manca de confirmació de marxa.

tconf_marxa_ts_sp / tconf_marxa_ts_acc són respectivament els registres de preselecció i valor actual del

temporitzador de confirmació forçada de marxa que s’utilitzarà si abans hem seleccionat senyal de confirmació

de marxa no present.

reg_estat_hmi és el registre d’estat del dispositiu


60


61


62


63


64

Igual que amb la funció de control de les vàlvules, que era cridada a la funció “GESTIÓ_VÀLVULES” tantes

vegades com vàlvules hi ha a la instal�lació, a la funció “GESTIÓ_MOTORS” cridem a la FC11 “CTRL_MOTOR”

tantes vegades com motors hi han. En aquest cas només hi haurà una crida a “GESTIÓ_MOTORS” donat que a

la instal�lació només hi ha la bomba de buit. Al igual també que amb les vàlvules, prèviament a programar les

crides caldrà declarar el suport de dades de la UDT2 per a cada instància o crida. En aquest cas hem utilitzat el

DB2, “DB_CTRL_MOTORS” per a declarar la variable “bomba” de tipus UDT2.


65

Finalment llistem la funció “GESTIÓ_MOTORS”


66

3.3.7 Funció de gestió del transport

La gestió del transport està organitzada en la FC40 “GESTIO_TRANSPORT” que gestiona permisos de

marxa, els modes de funcionament i la marxa aturada del sistema.

La FC41 “GESTIO_SEQ_TOTAL” gestiona la seqüència de treball en el mode de funcionament total

La FC42 “GESTIO_SEQ_ADEM” gestiona la seqüència de treball en el mode de funcionament a demanda.

Ambdues funcions utilitzen les macroetapes M1 i M2, el codi de les quals es troba en els darrers segments de la

FC42. Aquesta funció necessita gestionar la cua de peticions de servei dels diferents llocs i per això crida a la

funció feta amb text estructurat FC32 “GESTIÓ_CUA_PETICIONS”. Siemens anomena SCL al llenguatge que en

la majoria de plataformes es coneix com a text estructurat. A l’apartat 4.2 hi ha una introducció al llenguatge

SCL. Malgrat això, comentarem amb detall aquesta funció a l’apartat 3.3.8

Finalment a la FC43 “GESTIÓ_ORDRES_AUTO” combinem els passos d’ambdós seqüències per gestionar les

ordres de marxa, obertura i tancament de bomba i vàlvules.

En primer lloc mostrem el codi corresponent a les macroetapes M1 i M2.

Les dades que afecten la gestió del transport estan dividides en dos DB:

DB_GESTIO_TRANSPORT conté les dades, generalment de tipus booleà que necessita el sistema.

Bàsicament hi ha bits per engegar i aturar el transport, per seleccionar el mode de treball i per elaborar el

permís de marxa de cada dispositiu. També hi ha les ordres de marxa de la bomba, les ordres d’obrir i tancar

de les vàlvules i els bits per programar els passos de les diferents seqüències.

DB_REGULA_TRANSPORT conté les preseleccions i el valor actual dels diferents temporitzadors que

intervenen en el procés, també la taula per gestionar la cua de peticions i els registres associats.


67


68


69


70


71

Podem veure a continuació les dades relacionades amb les funcions de gestió del transport


72


73


74


75

A continuació, detallem el codi de “GESTIO_TRANSPORT” i “GESTIÓ_SEQ_TOTAL”


76


77


78


79


80

Aquest registre ens permet indicar a la pantalla, el mode de treball seleccionat


81


82


83


84


85


86


87


88


89


90


91


92

3.3.8 Funció de gestió d’ordres en automàtic

Abans de detallar el codi de la seqüència de funcionament a demanda, examinem aquesta funció que

gestiona les ordres de marxa en automàtic per a poder provar el funcionament en mode total


93


94


95


96


97


98


99


100


101

3.3.9 Funció de gestió de cua de peticions

Aquesta funció esta feta en SCL o text estructurat, perquè aquest llenguatge facilita el tractament de taules

i cues. Abans d’explicar la seqüència del mode de treball a demanda, expliquem en detall aquesta funció que és

la base de la seqüència de treball a demanda

A l’apartat 4.2 de l’annex hi ha una introducció a aquest llenguatge de programació

Comencem per la declaració

Figura 3.16 – Declaració de “GESTIO_CUA_PETICIONS”

Com a variables temporals tenim un índex per a recórrer la taula i un marcador per detectar la presència en

cua d’una petició abans d’incorporar-la o no.

Com a variables d’entrada tenim:

Un bit d’entrada que s’activarà cada cop que un lloc faci petició de servei. L’identificador del lloc que serà el

seu número, entra pel paràmetre “Petició”. Quan s’activa el bit de petició per entrar, la funció comprova que la

petició no sigui ja a la cua, i aleshores, si ja ha estat feta anteriorment no cal fer res més i si l’identificador de

la petició no està a la cua l’introduïm a la posició corresponen

Un bit per fer lectura a la cua del lloc que cal tractar. Caldrà activar aquest bit just abans d’atendre una

petició per saber quin és el lloc que l’ha feta

Un bit que ens indica la fi del servei a una posició determinada, que provocarà que el seu identificador sigui

retirat de la cua


102

Finalment un bit per esborrar la cua que servirà exclusivament per inicialitzar-la

Com a variables d’entrada de sortida, tenim:

La taula de 10 posicions que emmagatzemarà els identificadors que van fent petició. Malgrat que com a

màxim tindrà 6 peticions l’he dimensionada amb 10 per tal de tenir una reserva per futures ampliacions.

El punter de la taula, que ens indicarà en tot moment l’índex de la taula que conté la petició més antiga,

que està a la cua en espera d’atenció per part del transport. Quan el punter és 0 significa que la cua es buida.

Finalment com a variable de sortida tenim:

Lloc en servei que conté l’identificador del lloc que cal tractar o que està en tractament

La figura següent ens mostra part del codi de la funció

Figura 3.17 – Codi de les opcions esborrar cua i entrada de petició

A l’entrada de petició, primer fem un recorregut de la taula per detectar presència d’una petició, amb el

marcador “ident_no_present” i després, si el marcador segueix a true, entrem la petició a la taula


103

La resta de codi està a la figura 3.18

Figura 3.18 – Codi de les opcions fi_servei i lectura de petició

Fi servei decrementa el punter i esborra la posició de la taula ocupada per l’identificador que ha finalitzat

servei. Finalment l’opció lectura assigna a lloc en servei, l’identificador de l’aspirador que porta més temps en

espera.

En el següent apartat detallem el codi de la funció que gestiona el mode de funcionament del transport a

demanda.


104

3.3.10 Funció de gestió de mode de treball a demanda

Detallem el codi de la funció FC42 “GESTIO_SEQ_ADEM”


105


106


107


108


109


110


111


112


113


114


115


116


117


118


119


120


121


122

3.3.11 Terminal d’operador i prova del programa

Explicarem el terminal d’operador a la vegada que provarem el programa. El primer que cal fer es arrencar el

simulador i carregar el programa del transport

Abans d’arrencar, cal forçar les confirmacions de marxa de tots els dispositius per tal que no ens saltin les

alarmes de manca de confirmació dels dispositius. Això es pot fer des dels DB1 i DB2, que contenen les dades de

control dels dispositius, o des del terminal d’operador a la pantalla paràmetres tècnics, on tenim botons per forçar

la confirmació, que activen les marques “conf_marxa_np” o “fc_obrir_np” o “fc_tancar_np”

Figura 3.19 – Runtime del scada i programa del plc executant-se a PLCSIM

Al sinòptic, que correspon amb la imatge inicial del terminal, es veu el transport funcionant en mode total

amb l’aspirador 5 en servei. Comento a continuació les diferents parts del sinòptic

A la part superior tenim els botons de navegació. D’esquerra a dreta tenim botons per anar a sinòptic

principal, a pantalla paràmetres de procés, a pantalla de paràmetres tècnics, a pantalla d’alarmes i a pantalla

d’ajustos de sistema. La data i la hora són les del terminal d’operador però el seu rellotge intern està

sincronitzat amb el del PLC

A la barra de títol, just sota la barra de navegació hi tenim una indicació del mode de treball seleccionat

El motor, els tubs i les vàlvules canvien de color en funció del seu estat. Al costat de cada dispositiu un

símbol d’una ma humana, si és visible, indica que està en manual.

Sobre de cada aspirador hi ha un pilot que senyalitza el mateix, que el pilot que esta situat a camp. El

temps de treball de cada aspirador s’indica sota de cadascun d’ells


123

Els botons total i adem permeten seleccionar el mode de treball i els ON OFF, permeten arrencar o aturar el

transport.

Els valors de temps dels aspiradors són els actuals de treball. Si necessitem canviar la preselecció hem

d’anar a la pantalla paràmetres de control

Figura 3.20 – Ajustos del transport – preseleccions i valors actuals

El forçat de la confirmació de marxa dels dispositius i els temps de retard d’aquestes confirmacions es

poden ajustar a la pantalla de paràmetres tècnics

Figura 3.21 – Ajustos tècnics de dispositius


124

Pantalles d’alarmes

Figura 3.22 – Senyalització d’alarmes a la pantalla d’alarmes actives

L’alarma ha estat provocada en desactivar el guardamotor de la bomba, entrada E126.1 des del simulador.

En el sinòptic es senyalitza l’estat d’alarma del dispositiu, com es pot veure a la figura següent

Figura 3.23 – Bomba en alarma

Finalment a la pantalla del històric veiem les alarmes que ha tingut el sistema ordenades de mes recents a

més antigues


125

Figura 3.24 – Històric d’alarmes

Procedint pas a pas per testejar el programa, activem les entrades E126.1 “guardamotor de la bomba” i

E126.3 “polsador d’emergència”. A continuació arrenquem el runtime de l’aplicació scada

Figura 3.25 – Estat inicial del transport

Observem que tenim la bomba en manual. Per a poder arrencar el transport hem de posar la bomba en

automàtic i esborrar les alarmes, que hi puguin haver actives amb el polsador E126.0 o amb el botó de la

pantalla d’alarmes actives


126

Figura 3.26 – Posar la bomba en automàtic

Selecció de mode de treball

Figura 3.27 – Selecció de mode total

Ara ja podem arrencar el transport, prement el botó ON


127

Figura 3.28 – En engegar s’il�luminen tots els pilots i arrenca la bomba

Quan ha passat el temps de confirmació de buit, indicat sobre la bomba els aspiradors poden començar a

treballar. En treballar, els pilots dels aspiradors es posen en intermitència i el registre de sota l’aspirador indica

el temps actual de treball del mateix

Figura 3.29 – Treball de l’aspirador 3.

Cada dos serveis, en el cas del mode total, després de 1 i 2 o de 3 i 4 o de 5 i 6, la bomba s’atura i buida el

tanc. Cal aturar la bomba obrir la vàlvula de descompressió i obrir la vàlvula de buidat el temps indicat en el

paràmetre del mateix nom


128

Figura 3.30 – Buidat del tanc després de dos serveis, en mode total

Pel que fa al mode a demanda, cal sencillament seleccionar-lo i prémer el botó de marxa del transport. Hi

ha una diferència en el sinòptic, que és la aparició de 6 botons per fer petició de servei, amb la mateixa

funcionalitat que els 6 botons de camp

Figura 3.31 – Selecció de servei per a quatre aspiradors

L’ordre de la petició queda registrat a la taula cua de peticions

Figura 3.32 – Taula cua de peticions amb el registre de les quatre peticions

L’ordre de les peticions ha estat, de més antiga a més recent: 6, 3, 4 i 1


129

Figura 3.33 – Treball de l’aspirador 6 en mode a demanda

Els llocs que han fet petició es poden conèixer amb l’estat del pilot de cada aspirador. El pilot del que està

en servei està en intermitència.

Figura 3.34 – Cada dos serveis o en buidar la cua, la bomba s’atura i es buida el tanc


130

4 ANNEXOS

4.1 ANNEX 1 – COMUNICACIÓ MPI

4.1.1 Generalitats

Totes les CPUs del S7-300 i del S7-400 de Siemens incorporen un port de

comunicacions MPI (multi point interface ) que és el que habitualment s’utilitza per a

programar-les. Aquest port treballa sota norma RS485, a una velocitat màxima de

187,7 kbaudis. Per a accedir-hi des d’un PC podem utilitzar el port sèrie RS232 amb el

PCAdapter de Siemens, o bé una tarja de comunicacions per a PC tipus CP5611/CP5613

(pci) o CP5511/CP5512 (pcmcia). En aquest últim cas la connexió amb el PLC és directe

utilitzant els connectors profibús de Siemens, com el podem veure a la figura.

El port MPI permet a més, interconnectar en una xarxa, varis PLCs de les sèries S7-300 o S7-400, i fins i

tot es possible connectar-hi un S7-200. També podem trobar configuracions en que intervinguin panells

d’operador, o fins i tot ordinadors amb un scada compartint la xarxa MPI amb els corresponents PLCs.

En qualsevol cas aquesta xarxa es pot muntar amb un màxim de 32 participants, inclosos els diferents

punts de programació. Pot haver-hi més d’un programador connectat simultàniament a una xarxa MPI amb

l’única condició de configurar les seves estacions de programació amb un número de node diferent. A la

pràctica però es desaconsella muntar una xarxa MPI amb més de 10 participants. Quan això és necessari, cal

recórrer a xarxes profibús o industrial ethernet.

Figura 4.01 – Xarxa MPI


131

A la figura anterior podem veure quatre S7-300 connectats a un S7-400 i a una MP277, també hi ha una

estació de programació. El quadret vermell de cada interlocutor indica el port MPI de cada estació i a sota

s’indica el número de node amb el que ha estat configurada. Des del PC si tinguéssim instal�lat el software

STEP7 i el WinCCFlexible, podríem accedir a programar qualsevol dels cinc PLCs i el terminal d’operador MP277.

Sense l’adquisició de hardware addicional, el port MPI permet que varies CPUs es puguin comunicar

fàcilment. Hi han dos sistemes: Intercanvi de dades globals, que té el seu equivalent en Omron amb les taules

de data link i comunicació emprant funcions de comunicació, de las que disposen la majoria de fabricants a les

seves llibreries.

4.1.2 Comunicació per intercanvi de dades globals

La comunicació per intercanvi de dades globals, és un sistema de comunicació entre els PLCs que

simplement s’ha de parametritzar, no cal escriure codi de programa en els PLCs per a implementar aquest

sistema de comunicació.

Tot seguit mostrem com s’ha de procedir per a configurar una comunicació per intercanvi de dades globals.

En primer lloc caldrà posar en el mateix projecte totes les CPUs que hagin d’intercanviar dades. Aquestes CPUs

poden ser S7-300 o S7-400. Es possible també comunicar amb un S7-200 però el procediment és

exclusivament emprant funcions de comunicació, raó per la qual ho tractarem a l’apartat corresponent.

A la figura següent veiem un projecte amb tres CPU S7-300:

Figura 4.02 – Projecte amb 3 PLCs


132

S’haurà de configurar el hardware de cadascun dels PLC. Configurar les comunicacions pot ésser el primer

pas abans d’escriure el codi de cada PLC o pot realitzar-se després d’haver dissenyat el programa dels PLCs,

com a pas previ a la posta en marxa. Si es tenen ben definides les comunicacions, és preferible configurar-les

de bon principi, sobretot si treballen varis programadors en el projecte.

Les CPU S7-300 venen configurades de fàbrica amb el número de node 2, així que caldrà en primer lloc

canviar números de node de les CPUs per tal de que puguin comunicar. Habitualment el node 0 està reservat

per a l’estació de programació i el node 1 està reservat per a un terminal d’operador, amb la qual cosa els PLCs

porten números de node correlatius a partir de 2. Si hi hagués més d’un terminal d’operador a la instal�lació

també hauria de portar un número de node diferent de tots els altres. A més de canviar el node cal dir-li a la

CPU que està connectada a la xarxa MPI. Ambdues coses es poden fer des de la configuració del hardware, o

des de l’aplicació NETPRO o configuració de red.

A continuació mostrem els dos procediments: Des de l’aplicació per a configurar hardware HW Config,

premem el botó dret de la rata, sobre la CPU de la qual desitgem modificar la seva configuració i ens apareix el

següent quadre de diàleg:

Figura 4.03 – Configuració de la xarxa


133

A la part central del quadre propietats de la CPU, dins ”interface” observem adreça o node MPI 2 i no

connectat. Per a canviar el node i connectar-la hem de fer un clic sobre el botó "propiedades". En el nou quadre

de diàleg podem introduir l’adreça desitjada i establir la connexió. Acabem posant l’adreça MPI 4 i marcant la

subxarxa MPI(1). Aquesta operació s’haurà de repetir-se per a cadascuna de les CPU.

Figura 4.04 – Connexió a la xarxa MPI

Haguéssim obtingut resultats idèntics si en lloc de configurar CPU a CPU amb HW Config, haguéssim

configurat tota la xarxa amb NETPRO. L’aplicació NETPRO s’arrenca amb l’opció “configurar red” del menú

Herramientas de l’administrador simatic, o fent dos clics sobre l’objecte MPI(1) del projecte.

Botó d’inici de l’aplicatiu de configuració de xarxa

Un cop arracada l’aplicació per a configurar les xarxes del projecte, podem observar les tres CPU del

projecte. La CPU del PLC003 apareix amb el node 4 i connectada, tal com s’ha configurat amb HW Config. O

configuració del hardware.


134

Figura 4.05 – Connexió a MPI desde NETPRO

Per a connectar la resta de PLCs a la xarxa polsem sobre el quadre vermell i arrosseguem fins a la línia de

la xarxa. En fer la connexió el mateix programa ens proposa un nou número de node que no sigui ocupat. Si no

ens agrada podem canviar-lo fent dos clics sobre el quadre CPU, del rectangle PLC00X, a la mateixa aplicació

NETPRO. Ens apareix el quadre de diàleg de “Propiedades de la CPU” i hem de procedir tal com s’ha explicat a

la pàgina 4.

Figura 4.06 – Connexió a MPI desde NETPRO


135

L’aspecte de la configuració final s’observa a la figura següent.

Figura 4.07 – Xarxa MPI completa

Queda finalment guardar i compilar la configuració. Aquesta opció la trobem al menú “red” o la podem

arrencar amb el botó corresponent de la barra d’eines i si no hi ha errors genera de nou els tres sdb dels tres

PLC. Els sdb (system data block) són els blocs que guarden la configuració del sistema.

Després d’aquest apartat inicial de configuració ja podem anar a parametritzar l’intercanvi de dades globals.

S’hi accedeix amb l’opció “Definir datos globales” del menú “Herramientas” de l’Administrador Simatic. També

des del NETPRO prement la línia vermella de la xarxa MPI(1) amb el botó dret de la rata, ens apareix la

mateixa opció.

Un cop arrencada, l’aplicació ens ofereix el següent aspecte:

Figura 4.08 – Taula de dades globals


136

El primer que cal fer és introduir a les capçaleres de les columnes, les CPU que hauran d’intercanviar dades.

Cal prémer sobre la capçalera de cada columna, primer amb el botó esquerra per a seleccionar-la i després amb

el botó dret de la rata i apareix un botó “CPU” que cal prémer abans de seleccionar una de les CPU del projecte.

Figura 4.09 – Inserció del PLC a una columna

Un cop tenim les tres CPU situades, cal escriure en cadascuna de les files les dades a intercanviar. Cal

escriure adreces absolutes. Exemple MD200, MW100, MB50, DB10.DBD50, etc.

S’han de tenir en compte les següents consideracions, en les cpu del S7-300:

• Cada fila de la taula correspon a una línia de dades d’un paquet de dades globals.

• En cada fila hi ha d’haver una CPU emissora i una o més de receptores. Quan s’escriu una dada en una

casella, per defecte queda configurada com a receptora.

• Cada paquet de dades globals, pot contenir un màxim de 4 files de dades, independentment de la

grandària d’aquestes dades. La conclusió es que si es volen transferir moltes dades convé que cada

línia contingui paquets de 32 bits: MD, ED, AD, DBx.DBD, etc. d’aquesta manera podem arribar a un

màxim de 128 bits per cada paquet de dades GD.

• Cada grup de CPU que intercanvien dades s’anomena cercle GD, i cada cercle GD, sols si està format

per dues CPU, pot contenir un màxim de dos paquets GD.

• Cada CPU pot pertànyer a un màxim de quatre cercles GD

• La CPU que emet les dades no té cap confirmació que el destinatari les hagi rebut. Si la comunicació es

crítica per a l’aplicació, cal afegir en les àrees d’intercanvi bits de vida de CPUs o treballar amb funcions

de comunicació, les quals si que tenen com a resposta el resultat de la comunicació.


137

Els botons de la barra d’eines més utilitzats són els següents:

Marcar una dada d’una columna CPU com a emissora

Marcar com a receptora

Compilar la taula de dades globals

Transferir la taula de dades globals a les diferents CPU

El significat de l’identificador GD és el següent: Exemple GD 3.2.2

El primer dígit (3 a l’exemple) significa el número de cercle GD – Cada CPU pot pertànyer a un màxim de 4

cercles GD. El segon dígit correspon al paquet GD. Si el cercle està format per dos PLCs poden intercanviar dos

paquets per cercle. El tercer dígit correspon a la línia GD. Cada paquet pot contenir un màxim de 4 línies GD.

L’aspecte general de la taula compilada és el de la figura:

Figura 4.10 – Taula de dades globals completa


138

Al transferir la taula de dades globals cal tenir en compte que les diferents CPU estiguin connectades i amb

el número de node correcte. Per això cal prèviament bolcar la configuració del hardware, individualment a cada

CPU. Si les CPU estan connectades i és el primer cop que realitzem aquesta operació vindran totes configurades

amb el número de node 2. Podem procedir de la següent manera: Deixem sense alimentació totes les CPU

excepte la que hagi de tenir el número de node més alt ( en el nostre cas la CPU amb MPI 4). Hi carreguem la

configuració que toca i aquesta CPU passarà a ser la número 4. A continuació donem alimentació a la que hagi

de ser la MPI 3 i repetim l’operació i així successivament fins a completar totes les CPU. En acabar, des de

l’administrador simatic hem de veure totes les CPU premen el botó “Ver estaciones accessibles”.

A la taula de la figura estan explotades les màximes possibilitats de comunicació via intercanvi de dades

globals. El cercle GD 1 implica les tres CPUs, essent el PLC001 l’emissor. Les quatre línies de dades comporten

un total de 128 bits. El cercle GD 2 implica també les tres CPU però l’emissor és el PLC003. El cercle GD 3 és un

intercanvi entre el PLC001 i el PLC002, amb dos paquets de dades de 256 bits totals. En el paquet 1 l’emissor

és el PLC002 i en el paquet 2 l’emissor és el PLC001. El cercle GD 4 és un intercanvi entre el PLC001 i el

PLC003, on el PLC003 és l’emissor. Aquest cercle podria ampliar-se encara amb un segon paquet on el PLC001

fos l’emissor. Finalment el cercle GD 5 és un intercanvi entre el PLC002 i el PLC003 idèntic al GD 3 pels PLC001

i PLC002.

Es pot observar com el nombre màxim de cercles GD en que una CPU pot participar és de 4.

Finalment cal esmentar el concepte de factors de cicle que apareix com a característica en els intercanvis

de dades globals. El factor de cicle en un cercle GD, estableix el nombre de cicles després dels quals les dades a

intercanviar seran actualitzades. Els factors de cicle es poden veure amb el menú ver “factores de ciclo”. Es

recomana acceptar els factors de cicle que venen per defecte, ja que si no podríem sobrecarregar en excés la

CPU, allargant el seu temps de cicle i produint l’efecte contrari al desitjat.


139

En aquesta figura podem observar els factors de cicle esmentats. Si les CPU tenen de mitjana un temps de

cicle de 10 mil�lèsimes de segon significa que les dades a intercanviar seran actualitzades cada 80 mil�lèsimes

de segon.

Figura 4.11 – Factors de cicle

Després de carregar la taula de dades globals a la CPU i posar-les totes en RUN, comença l’intercanvi de

dades de manera automàtica.

Per programa, l’únic que cal fer a cada CPU, és consultar les àrees de memòria que tinguem com a

receptores, ja que serà on podrem consultar les dades que ens enviïn la resta de CPUs, i escriure les àrees de

memòria marcades com a emissores, quan vulguem canviar les dades que reben la resta de CPUs. No cal fer

res més donat que el sistema operatiu dels PLCs ja fa la resta.

En front de la principal avantatge d’aquest sistema de comunicació que és la simplicitat, cal esmentar tres

inconvenients: La quantitat de dades que es poden transmetre o rebre són força limitades, s’allarga el cicle de

treball de les CPU donat que les comunicacions s’estableixen de manera permanent, malgrat no sigui necessari

enviar i rebre dades de manera continuada i les CPUs en enviar dades no tenen confirmació de l’èxit de la

comunicació. En el sistema que explicarem a continuació les comunicacions les controla el programa de cada

PLC, la carrega de temps de cicle per a comunicacions no és constant i podem enviar i rebre més quantitat de

dades i finalment hi ha acús de rebut en cadascun dels paquets enviats


140

Aquests tres: el de la quantitat de dades a comunicar, la freqüència amb que s’ha de fer i la necessitat

d’acús de rebut en funció de lo crítiques que siguin les comunicacions són els criteris principals per a decantar-

se per un o altre sistema.

4.1.3 Programa exemple per intercanvi de dades globals

El projecte MPI_GD s’acompanya amb suport informàtic, està configurat amb dues CPU 314C_2DP i està

preparat per ser carregat i provat. L’únic que cal fer és carregar els sdb o dades de sistema a cadascuna de les

CPU i obrir les dues VAT, una per a cada CPU, per a comprovar el funcionament de les comunicacions.

Figura 4.12 – Taula de variables per a test del programa

A la taula de dades globals està configurat que els bytes de marques 0 a 19 passin del PLC001 al PLC002 i

que els bytes, també de marques, del 20 al 39 passin del PLC002 al PLC001. Si forcem el valor FFFFFFFF a la

posició MD0 de VAT1_PLC001, hem de veure com aquest valor s’actualitza també immediatament a MD0 de

VAT1_PLC002.

Figura 4.13 – Taula de variables per a test del programa


141

Igualment si forcem el valor AAAABBBB a MD20 en el PLC002 hem de veure com aquest valor passa

automàticament a MD20 en el PLC001, observant la VAT1_PLC001.

4.1.4 Comunicació MPI per funcions de comunicació

Les funcions en qüestió les proporciona la CPU en el seu firmware, es a dir són SFC o funcions de sistema i

les que ens afecten son les següents:

SFC 65 : X_SEND

SFC 66 : X_RCV

SFC 67 : X_GET

SFC 68 : X_PUT

SFC 69 : X_ABORT

Algunes CPU no disposen d’aquestes funcions en el seu firmware i per tant no podríem utilitzar aquest

sistema. Per a comprovar que la CPU disposa d’aquestes funcions, podem obrir el projecte online, des de

l’administrador simatic i visualitzar el contingut de la carpeta bloques, del projecte online, on apareixen tots els

SFC i SFB disponibles per a aquella CPU.

Figura 4.14 – Funcions de sistema implicades en la comunicació MPI

En el nostre cas observem com la CPU 314C-2DP del projecte MPI_FC té en el seu firmware les 5 funcions

que volem utilitzar. De les CPU disponibles a l’escola únicament la CPU313 i la CPU312IFM no disposen

d’aquestes funcions en el seu firmware.


142

Aquestes funcions realitzen les següents operacions:

X_SEND Envia un paquet de dades al buffer de recepció d’una CPU remota. Aquestes dades poden

descarregar-se a la CPU remota amb la X_RCV que mou el contingut del buffer de recepció a la zona de

memòria especificada. Per tant aquestes dues funcions treballen per parelles.

X_PUT envia un paquet de dades directament a la zona memòria especificada d’una CPU remota.

X_GET Llegeix un paquet de dades, directament de la memòria d’una CPU remota.

X_ABORT s’utilitza quan es vol interrompre un enllaç establert entre dues CPU, per la crida de qualsevol de

les funcions, X_SEND, X_GET o X_PUT.

Al cridar qualsevol d’aquestes funcions des del programa d’una CPU estem utilitzant les comunicacions

només quan es necessiten.

A continuació especifiquem el codi de programa necessari per a utilitzar aquestes funcions. Agafem el

projecte MPI_FC que comunica dues CPU

El primer que cal fer és connectar les dues CPU a la xarxa MPI igual que en la comunicació per intercanvi de

dades globals.

Figura 4.15 – Preparació per a comunicar emprant funcions de sistema

S’observa com hi ha també una xarxa profibús degut a que la CPU315_2DP disposa d’un port profibús

configurat com a mestre.


143

La segona tasca a realitzar és inserir en el projecte offline les funcions de comunicació que pretenem

utilitzar en el projecte. Això ho podem fer de dues maneres: Des de l’administrador simatic obrint la llibreria

“Standard library” a l’apartat “system function blocs” i copiant les funcions que ens interessin a l’apartat

bloques de cadascuna de les CPU. També ho podem fer des de l’editor KOP directament, inserint la funció des

del catàleg d’instruccions i funcions cercant la funció que ens interessi, també des de la mateixa llibreria.

Figura 4.16 – Inserció de funcions de sistema de comunicació en el projecte

Copiem les 5 funcions i les enganxem a cadascuna de les carpetes bloques dels PLC. Després d’això ja les

podrem cridar des d’on vulguem.

Primer programarem un intercanvi de dades utilitzant X_SEND i X_RCV. El significat dels paràmetres

d’aquestes funcions és el següent.

Per X_SEND

Figura 4.17 – Paràmetres de X_SEND

REQ És un paràmetre d’entrada booleà que serveix per activar la petició. Funciona per nivell, quan

s’activa el senyal, el primer que fa la funció, és establir l’enllaç entre les dues CPU si encara no està establert, i

tot seguit s’envien les dades. Si hi hagués una petició pendent de finalitzar el senyal no es té en conte.


144

CONT També és un paràmetre d’entrada booleà. Si està a 1 l’enllaç establert a la primera instància es

manté indefinidament, el que facilita les següents comunicacions, però ocupa recursos limitats del PLC (Cada

CPU té uns recursos d’enllaç limitats). Si està a 0 es trenca l’enllaç després de cada paquet enviat, el que

permet que l’enllaç ocupat quedi lliure per a una altre comunicació.

REQ_ID És un paràmetre d’entrada DWORD. En format hexadecimal podem escriure per exemple

D#16#00000002. Aquest paràmetre serveix per identificar les dades d’emissió. És enviat juntament amb el

paquet de dades i el podrà consultar la CPU de l’interlocutor amb la SFC 66 "X_RCV". En particular aquest

paràmetre serà necessari quan: Des d’una CPU emissora enviem varis paquets amb la X_SEND cap al mateix

interlocutor, o varies CPU emissores envien paquets amb X_SEND al mateix interlocutor. Des de la CPU de

l’interlocutor podrem descarregar les dades rebudes a diferents àrees de memòria, avaluant aquest paràmetre.

DES_ID És un paràmetre d’entrada WORD. També en hexadecimal podem escriure D#16#0003. Aquest

paràmetre comunica a la funció el node destí, o l’adreça MPI, de l’interlocutor al qual volem enviar les dades.

SD Aquest paràmetre d’entrada indica a la funció, l’àrea de memòria en la CPU emissora, que conté les

dades a transferir. El seu format és ANY. El format ANY és un format que inclou de manera implícita: inici de

l’àrea de memòria, àrea de memòria (E, A, M, DB, etc.), format de les dades a transferir i grandària de l’àrea.

Exemples:

P# M0.0 WORD 20 ( 20 words a partir de M0.0 o sigui MW0, MW2, MW4, ....... MW38)

P# DB10.DBX50.0 BYTE 100 ( 100 bytes a partir del Byte 50 del DB10 o sigui DB10.DBB50,

DB10.DBB51,......... DB10.DBB149

P# DB10.DBX100.0 DT 20 ( 20 date and time a partir del byte 100 del DB10)

BUSY És un paràmetre de sortida que ens indica si hi ha alguna emissió en curs o no. BUSY = 1, indica que

encara no ha finalitzat l’emissió. BUSY = 0, indica que no hi cap emissió en curs o que ha finalitzat l’última que

s’ha cursat. El podem utilitzar, per exemple en combinació amb REQ per no activar cap emissió si encara no ha

finalitzat l’anterior. Malgrat tot, això últim no es necessari donat que el paràmetre REQ no activa cap petició si

n’hi ha alguna en curs.

RET_VAL Aquest paràmetre de sortida ens retorna informació de l’estat de l’emissió, que s’hi interessés

permetria fer un cert tractament d’errors d’emissió.

A continuació expliquem l’exemple provat. En primer lloc activem el REQ amb un bit de l’aplicació anomenat

“Enviar_ON”. Quan des de l’aplicació posem aquest bit a 1 i a més s’ha finalitzat l’última transmissió, s’inicia

l’emissió del paquet de dades. Donat que només hi ha dues CPU que intercanvien dades, es previsible no

esgotar els recursos d’enllaç i per tant activem CONT per a mantenir de manera permanent l’enllaç amb la CPU

315_2DP, el que minimitza els temps de comunicació. A DEST_ID i indiquem un 2 que és l’adreça MPI de la

CPU 315_2DP i a REQ_ID identifiquem el paquet com a 1. Malgrat tot en aquest cas concret a l’interlocutor no

caldrà emprar aquesta informació. Finalment a SD indiquem l’àrea de memòria, el contingut de la qual s’ha

d’enviar a CPU 315_2DP.


145

Des de la CPU 314 IFM (MPI 3) enviem un paquet de 50 bytes a la CPU 315_2DP (MPI 2).

Figura 4.18 – Codi exemple amb X_SEND

Per a poder disposar d’aquestes dades la CPU 315_2DP haurà de tenir programada la X_RCV, veiem

l’exemple:

Figura 4.19 – Codi exemple corresponent a X_RCV

La funcionalitat dels seus paràmetres és la següent:

EN_DT És un paràmetre d’entrada booleà, que quan es posa a 1 fa que el paquet de dades més vell de la

cua de recepció es copiï a l’àrea RD.


146

NDA és un paràmetre de sortida, també booleà, que quan es està a 1 indica que s’ha rebut un nou paquet

de dades. A l’exemple està programat que tant bon punt arribi un nou paquet de dades aquest es descarregui

sobre l’àrea especificada.

RD Paràmetre de sortida ANY que especifica l’àrea on s’han de copiar les dades rebudes. El nombre màxim

de dades permès en aquesta àrea és de 76 bytes. Si s’haguessin d’enviar paquets de dades de més de 76

bytes, caldria enviar varis paquets amb X_SEND de menys de 76 bytes i fer un tractament amb el paràmetre

REQ_ID. Fem un exemple a continuació.

Imaginem que des la CPU 314 IFM enviem dos X_SEND, cap a 315_2DP amb REQ_ID 1 i 2 respectivament.

Cadascun dels paquets té 50 bytes i volem descarregar-los sobre els 100 primers bytes del DB11 a la CPU

315_2DP. El programa que hauríem de carregar a l’interlocutor seria el següent:

Per assegurar que les dades que van a parar als Dbs en funció del paquet enviat no se solapin, caldria fer el

traspàs de dades sincronitzat amb un flanc de baixada de M100.7 Caldria per tant modificar el segment 2 i

posar un flanc de baixada de M100.7 enlloc de “Always_ON”

Figura 4.20 – Identificació de paquets si hi ha dos emissors

També podríem enviar paquets des de la CPU 315_2DP cap a la CPU 314_IFM, programant X_SEND a CPU

315_2DP i X_RCV a 314 IFM, d’aquesta forma la comunicació seria en els dos sentits.

També podríem utilitzar les funcions de sistema, X_GET i X_PUT. La diferència amb les anteriors és que

aquestes funcions no necessiten programar-se per parelles si no que cadascuna d’elles ja fa referència a dues

àrees de memòria, una a la CPU local i l’altra a la CPU de l’interlocutor.


147

Si es programa una X_GET i una X_PUT a la mateixa CPU cal programar-les de manera que no es superposi

la seva execució. Una forma de fer-ho és la que es pot comprovar en el següent programa. X_GET s’arrenca

únicament si ha finalitzat X_PUT i aquesta última s’arrenca a la finalització de X_GET.

La mateixa funció s’aconseguiria posant una X_GET o una X_PUT a cadascuna de les CPU.

El paràmetre VAR_ADDR que no apareixia a les altres funcions fa referència a l’àrea de memòria afectada a

l’interlocutor. Finalment la funció X_ABORT s’utilitza per a desfer l’enllaç establert entre dues CPU per

qualsevulla de les funcions anteriors. Seria necessària programar-la si per exemple s’hagués de fer una

comunicació urgent i no disposéssim d’enllaços lliures.

Figura 4.21 – Utilització de X_GET i X_PUT

Finalment les mateixes funcions X_GET i X_PUT s’utilitzarien per a comunicar un S7_300 i un S7_200. Caldria

configurar el port de S7_200 a 187,7 kbaudis amb l’adreça MPI corresponent, com sempre diferent de la del

S7-300. Les funcions esmentades només es poden utilitzar des de S7_300, no cal escriure codi a S7_200.

Nomes podem especificar l’àrea VB de S7-200 i en els punters de les funcions que programem a S7-300 hem

de especificar DB1. Per exemple per especificar 100 bytes a partir de VB0 caldrà indicar a VAR_ADDR

P#DB1.DBX0.0 BYTE 100. Això fa referència a l’àrea VB0 a VB99 de S7_200.


148

4.1.5 Programes exemple amb funcions de comunicació

A les variables que tenim a la VAT2_PLC001 hi hem de veure el mateix que escrivim a les variables

VAT2_PLC002. Projecte MPI_FC.

Figura 4.22 – Taules de monitorització per test de la comunicació


149

4.2 ANNEX 2 – INTRODUCCIÓ A SCL

4.2.1 Generalitats

La instrucció IEC 1131-3 té com a objectiu la normalizació dels llenguatges de programació per a autòmats

programables, de manera que independentment de la tecnologia escollida, els programes escrits per a un PLC

concret es puguin traslladar a un PLC d’un altre fabricant amb poc esforç. Un dels llenguatges definits en

aquesta norma es el ST o “Structured Text” que és un llenguatge d’alt nivell i que com a tal tindrà totes les

prestacions d’un llenguatge d’aquest tipus: instruccions matemàtiques complexes, tipus de dades complexes,

tipus de dades definits per l’usuari, tractament de dades, i les estructures de control clàssiques que tenen tots

els llenguatges d’alt nivelll: IF THEN ELSE, REPEAT UNTIL, WHILE DO, FOR TO i CASE OF.

SCL “ Structured Control Language “ és el llenguatge de text estructurat per a PLCs de Siemens i està basat

en el llenguatge d’alt nivell PASCAL. Permet una fàcil integració en el context d’una solució global per a un

problema d’automatizació, ja que un bloc programat en SCL pot ser cridat des d’un bloc escrit en KOP, en

Grafcet, en AWL o en FUP i a la inversa, un bloc escrit, per exemple en KOP pot ser cridat des d’un bloc escrit

en SCL. Una altra característica és que SCL tracta totes les àrees de memòria del PLC com a variables globals,

la qual cosa permet, com a la resta de llenguatges, intercalar una adreça absoluta de memòria (entrada,

sortida, marca, DB, perifèria, etc.) en l’àrea d’instruccions del bloc com si es tractés d’una variable del bloc.

SCL està especialment indicat per a la resolució dels següents tipus de problemes: Problemes matemàtics

complexes, problemes de tractament de dades, gestió de dades en taules i matrius, registre de dades, etc.

4.2.2 Un primer exemple

Suposem que volem consultar l’estat de l’entrada E124.0 per activar o desactivar la sortida A124.0. En KOP o

diagrama de contactes es tan senzill com això:

Figura 4.23 – Codi KOP o LADDER a traduir


150

Suposant que el lector té coneixements bàsics de programació en llenguatge d’alt nivell, és senzill veure que la

solució al problema escrita en llenguatge algorítmic és:

si (E124.0 = 1) aleshores

A124.0 := 1;

sino

A124.0 := 0;

fsi

Aquesta part de codi, incorporat a una funció concreta com FC51, té traducció directa a SCL com:

Deixant a part la traducció precisa de les diferents estructures i operadors de SCL, qüestió que anirem veient

progressivament, aquesta funció (FC51), serà cridada per tal de ser executada des d'OB1.

Figura 4.24 – Crida de la funció generada sense paràmetres

Suposem ara que volem fer el mateix amb l’entrada E124.1 per activar la sortida A124.1. Evidentment, caldrà

modificar el codi font de la FC51 de la següent manera:


151

Amb aquesta modificació la crida a la funció no patirà cap canvi, però és obvi que haurem obligat al

programador a canviar el codi d’una funció escrita en SCL. Si es volguessin afegir més entrades i sortides

aplicant-hi el mateix tractament, caldria modificar de nou el codi de la funció FC51.

Per evitar aquesta repetició en la modificació del codi, és recomanable l’ús de paràmetres, amb això ens

estalviarem escriure l’adreça de memòria directament a la funció FC51. Un paràmetre és assimilable a una

variable que és carregada amb un valor concret al fer una crida a la funció. Això ens permet escriure la funció

sense fer referència a adreces absolutes de memòria, utilitzant en el seu lloc els paràmetres o variables

mencionades, com a objectes genèrics. Els paràmetres poden ser d’entrada ent (quan només ens interessa

consultar el seu valor), sortida sort (quan només ens interessa donar-li un valor) i entrada sortida ent_sort (en

el cas que ens interessi consultar i modificar el seu valor)

Fixem-nos ara en l’exemple inicial modificat amb l’ús de paràmetres, el veurem primer en llenguatge algorítmic.

acció actuarSortida(ent entrada: bool, sort sortida: bool)

si (entrada = 1) aleshores

sortida := 1;

sino

sortida := 0;

fsi

facció

En llenguatge algorítmic es distingeix entre funcions (només tenen paràmetres d’entrada i retornen un únic

valor del tipus definit per a la funció) i accions (poden rebre qualsevol tipus de paràmetre i no retornen cap

valor).


152

En SCL traduïm l’acció precedent com la funció FC52 quedant com segueix:

S’ha declarat “entrada” com a paràmetre o variable d’entrada, i sortida com a paràmetre o variable de sortida.

Quan cridem a la funció des de l’OB1 l’aspecte de la crida ha canviat apareixent en la mateixa els paràmetres

definits, com s’observa en la següent figura:

Figura 4.25 – Crida de la funció generada amb paràmetres

Es precisament a la crida quan assignem un valor al paràmetre formal entrada i una adreça “punter” al

paràmetre formal sortida. Treballant d’aquesta manera no serà necessari modificar el codi de la funció per

actuar sobre una sortida addicional, sino que efectuarem una segona crida assignant nous valors actuals als

paràmetres. L’última versió de la FC51 en el que actuàvem sobre dues sortides, quedarà resolt amb dues crides

a la FC52, tal i com es mostra a continuació:


153

Figura 4.26 – Dues instàncies de la funció amb l’assignació de paràmetres proposada

Es obvi que es poden realitzar crides addicionals, de fet poden fer-se tantes com sigui necessàries.

Aquesta manera de treballar té dos avantatges ben clars: el primer és que reduïm la memòria ocupada pel

programa, ja que dupliquem la crida a la funció en comptes del codi. Com més crides fem, més aprofitem el

codi. El segon avantatge fa referència a la transparència de la funció, és a dir, la funció és molt més intel�ligible

amb paràmetres que sense. Una funció amb paràmetres ens permet observar el seu funcionament tot veient els

valores de resposta, i a més a més la introducció d'un paràmetre ens permet evitar la modificació del codi d'una

funció, per exemple, canviar una adreça de memòria.


154

4.2.3 Funcions matemàtiques i de conversió.

Funció que indica si una variable està o no dins de marges o fora de control.

Es tracta d'una funció de vigilància d'una variable de procés o d'una variable interna de control, de manera

que si el seu valor està per sobre d'un màxim, introduït com a paràmetre d'entrada, o per sota d'un mínim,

introduït també com a paràmetre d'entrada, ens activa una sortida d'avís, alarma o indicació de fora de control.

Els paràmetres necessaris són:

ent valorProcés: real,

valorMàxim: real,

valorMínim: real,

sort alarma: bool,

Podem plantejar una funció que ens retorni alarma tenint com a entrades els tres paràmetres anteriors. En

llenguatge algorítmic, la funció queda de la següent manera:

funció indicarForaDeControl(valorProcés, valorMaximo, valorMinimo: real): booleà

var

alarma: booleà;

fvar

si (valorProcés >= valorMàxim) o (valorProcés <= valorMínim) aleshores

alarma := cert;

sino

alarma := fals;

fsi

retorna alarma;

ffunció;

Per programar aquesta funció en llenguatge SCL, cal fer els següents passos:

• Crear un projecte en STEP 7, associant-li un sol programa S7, ja que si no treballem amb una aplicació concreta no caldrà assignar-li cap hardware.

• Escriure el codi font en llenguatge SCL dins del contenidor de fonts del nostre projecte. • Compilar el codi per traduir-lo a un codi executable pel PLC

Estudiem en detall cadascun d'aquests passos:


155

Creació del projecte.

Obrim l'administrador Simatic, i creem un nou projecte anomenat SCL_01.

Figura 4.27 – Creació de projecte sense CPU, per provar una funció

Dins de la carpeta "Fuentes", inserim una nova font que s'anomeni "fueraDeControl". Una font de SCL pot contenir diferents funcions, així com altres tipus de blocs OB i DB:

Figura 4.28 – Procediment per inserir una font SCL i font ja inserida en el projecte


156

Fent doble clic sobre l'objecte que acabem d'inserir, obrim l'eina SCL (mòdul de programació de blocs).

Figura 4.29 – Aspecte de l’editor de fonts SCL

Amb l'ajut de l'editor, ens estalviarem feina si utilitzem l'opció d'inserir plantilla de bloc (FB o FC). Al

següent punt es fa el raonament del per què inserir un tipus de plantilla i no un altre.

Figura 4.30 – Inserció de plantilles a les fonts SCL

Abans de començar a escriure el codi cal uns aclariments, ja que caldrà plantejar-se amb quin tipus de

blocs S7 treballarem (FC o FB), i veure com traduïm la declaració de variables, les estructures de control i la

resta d'elements contemplats en la notació algorítmica.

En primer lloc, cal dir que tant les funcions com les accions de la notació algorítmica es corresponen amb

FCs o FBs al traduir-les a SCL. SCL, per tant, no distingeix entre funcions i accions, i de fet l'única distinció

entre ambdues es troba en la declaració de variables.

Sobre la qüestió de quan fer servir un FC o quan un FB, la distinció és la següent: utilitzarem un bloc FB

quan es generi molt informació addicional que s'hagi d'emmagatzemar i no estigui contemplada en els

paràmetres d'entrada. Tota aquesta informació addicional es guardarà en el DB d'instància del FB. Si en cas

contrari, la informació rellevant es troba en els paràmetres de sortida de la funció, el mòdul a utilitzar serà un

FC.-


157

Per facilitar l'edició disposem de plantilles, tant de blocs com de paràmetres com d’estructures de control.

Així doncs, començarem inserint una plantilla de bloc FC.

Escriptura del codi.

Figura 4.31 – Inici d’edició a partir de la plantilla inserida

A la línia 2 apareix la declaració de la funció, en la qual hem substituir xxx pel número de la FC que farem

servir, per exemple FC2. També apareix el tipus de dades corresponent al valor de retorn de la funció. En la

plantilla apareix INT, per pot ser qualsevol tipus de dades o VOID si la funció no ha de retornar cap valor.

De les línies 3 a 8 cal introduir la declaració de tots els objectes necessaris per a la correcta execució de la

funció. També podem aprofitar els avantatges de l'editor i inserir una plantilla per constants i paràmetres

("Insertar/Plantilla de bloque/Constante").

Les variables estàtiques que en un FB són les variables que es guarden al DB d'instància, poden ser

declarades també en un bloc FC, però cal tenir en compte, que al compilar quedaran configurades com

variables temporals, i per tant, el seu valor es perdrà al finalitzar l'execució.

En la figura es poden observar tots els tipus d'objectes que poden declarar-se, la sintaxi de la declaració i el

tipus de mòdul de programa S7 que el suporta. També estan indicats en l'ordre més correcte amb que cal

declarar-los.


158

Figura 4.32 – Possibilitats a l’àrea de declaració dels diferents blocs de funció

SCL distingeix entre variables i paràmetres. Els paràmetres apareixen en la interfície de la funció al ser cridada.

En canvi, les variables no apareixen en la interfície, i en el cas que siguin variables temporals es perdran al

finalitzar l'execució de la funció. Només en el cas que siguin variables estàtiques i treballem amb un bloc FB es

guardaran en el DB d'instància.

Finalment, les línies 9 i 10 de la plantilla de la FC i naturalment, totes les que fossin necessàries,

contindrien el codi de la funció amb les estructures de control pertinents.

La línia 11 assigna a la funció el valor constante 100, de manera que sigui el seu valor de retorn, i amb la

línia 12 acaba la funció.


159

Realitzem ara la declaració de la funció indicarFueraDeControl i dels seus paràmetres:

Figura 4.33 – Declaració de variables de la funció “indicarFueraDeControl”

Com que només hem de declarar paràmetres d'entrada i una variable temporal que es correspondrà amb la

variable de retorn de la funció, eliminem la resta d'apartats de la declaració. Observem que la funció s'ha

declarat amb nom simbòlic. Això ens obligarà a declarar un bloc FC amb el mateix nom a la taula de símbols.

En aquesta taula de símbols es pot accedir directament des del menú "herramientas". Hi assignem la FC120.

Figura 4.34 – Entrada del nom de la funció a la taula de símbols

Ja per acabar l'edició de la funció completem l'àrea d'instruccions amb l'estructura IF THEN ELSE, que es pot

inserir si es vol, a l'àrea d'edició.


160

Figura 4.35 – Codi complert de la funció indicarFueraDeControl

Compilació i prova del codi font

Per provar la funció caldrà compilar-la i programar la seva crida des de l'OB1.

• Prémer sobre el botó "Compilar" de la barra d'eines

• Si volem veure els possibles errors de compilació, cal tenir actiu el botó "Resultados" de la barra d'eines.


161

Aquest és el resultat de la compilació que apareix a la finestra inferior de l’àrea de treball

Figura 4.36 – Resultats de la compilació

Aquest resultat ens indica que no hi ha cap error en el nostre bloc i que ja està a punt per ser provat.

Abans de provar, cal programar la crida a la funció. Ens situem al contenidor de blocs, obrim l'OB1 en KOP, i inserim la FC120 en un segment.

Figura 4.37 – Aspecte de la crida, previ a l’entrada de paràmetres

Apareix el nom de la funció, els tres paràmetres d'entrada i en el paràmetre RET_VAL apareix el valor de

retorn de la funció. RET_VAL és per tant una paraula reservada i es fa servir com un paràmetre de sortida del

tipus declarat per la funció. Si la funció s'ha declarat com booleana RET_VAL es bool, si la funció es declarada

como INT RET_VAL és també de tipus enter, etc.

Per completar la crida a una funció (FC) cal assignar valors als paràmetres de la funció.


162

En el exemple, utilitzem la funció per controlar una variable de procés. El valor d'aquesta variable està a

MD50. caldrà indicar una alarma si el seu valor és inferior a 30 o superior a 50,5. La marca M100.0 estarà a 1

si hi ha alarma o a 0 en cas contrari.

Figura 4.38 – Entrada de paràmetres completada

Engeguem el simulador des de l'administrador Simatic i carreguem tots els blocs a la CPU, per, a

continuació, col�locar en RUN el commutador d'estat del PLC. Per tal de provar la funció inserim en el simulador

una variable global i l'indiquem MD0, amb el format regulació real, la qual cosa ens permet canviar el seu valor

entre un mínim i un màxim, talment com si fos un potenciòmetre. En les figures següents podem observar la

resposta de la funció per a tres valors a MD0.

En el primer cas, el valor de MD0 està entre 30 i 50.5 i per tant, M100.0 està a 0 indicant que la variable es

troba dins dels marges.

Figura 4.39 – Test de la funció amb el PLCSIM, amb resultat de no alarma


163

En aquest segon cas, la variable ha sobrepassat valorMaximo, per tant, el valor de retorn de la funció serà

1, indicant així alarma de procés:

Figura 4.40 – Test de la funció amb resultat d’alarma

La mateixa situació es dóna quan el valor a MD0 és inferior a 30, tal i com mostra la següent figura.

Figura 4.41 – Test de la funció completat

Amb això hem comprovat que la funció es comporta tal i com volíem, d'aquesta manera la podem donar per

bona.


164

Funció per convertir un valor real a temps simatic.

Suposem que tenim un sistema de control d'una màquina o procés on intervenen un PLC i una pantalla com

a interfície d'usuari. Tal com mostra la figura estan connectats per MPI

Figura 4.42 – Projecte amb PLC i pantalla

En la interfície d'usuari del sistema descrit s'ha previst una pantalla de configuració des d'on es podrà

canviar el valor de preselecció de diferents temporitzadors del procés

Els temporitzadors de la gamma de l'S7-300/400 fan servir el tipus de dades S5TIME. Aquest tipus de

dades no és estàndard, i té l'inconvenient de canviar la base de temps de manera automàtica segons el valor

de preselecció proposat. Això vol dir, que segons l'interval de temps desitjat per preseleccionar el

temporitzador, caldrà canviar el format de preselecció.

Per tal de facilitar la tasca de l'operador de planta, hem dissenyat la interfície, de manera que permeti

l'entrada directa de temps en segons, en format real de dos decimals, amb la qual cosa tindrem una definició

de centèsimes de segon.

Caldrà per tant dissenyar una funció de conversió que ens permeti passar el temps de format real a format

S5TIME.

En aquesta funció farem servir diferents funcions de conversió de tipus. En primer lloc disposem de la

funció de conversió timeToS5time a la llibreria estàndard de funcions S7. Utilitzant aquesta funció, reduïm el

problema en fer una conversió de tipus real a tipus time.

És a dir:

• Passem l'entrada de segons a milisegons (entrada*1000.0) • Convertim el resultat anterior (real) a enter 32 bits (realAEnter) • Convertim el resultat anterior (enter) a time (enterATime)


165

En pseudocodi el resultat seria:

funció realAS5time(entrada: real): s5time

var

aS5T: s5time;

fvar

aS5T := timeAS5time (EnterATime(realAEnter(entrada*1000.0)));

retorna aS5T;

ffunció;

I escrita en SCL la funció queda així:

Figura 4.43 – Codi de la funció de conversió REAL_TO_S5TIME

Hem utilitzat dues funcions de conversió implícites en SCL: DINT_TO_TIME i REAL_TO_DINT. I també hem

utilitzat la funció TIM_S5TI que ve inclosa a la llibreria estàndard de l'apartat IEC function blocks.


166

Per tal de poder provar la funció hem dissenyat un senzilla interfície a la pantalla TP270, que es descriu a

continuació:

Figura 4.44 – Sinòptic programat a la pantalla per provar la funció

A la columna preselecció hem inclòs tres camps d'entrada que representen tres temporitzadors, cada camp

té el valor de preselecció en format real.

Els tres camps de sortida situats sota la columna "Valor actual", ens permeten visualitzar el valor actual de

cadascun dels temporitzadors.

Els botons de comandament d'estat situats a la dreta ens permeten engegar o aturar cadascun dels

temporitzadors de manera independent. Al ser temporitzadors SE, quan acabi el temps de comptatge, el mateix

temporitzador esborra el bit d'engegada associat al botó de comandament d'estat. Aquesta acció es pot

observar sobre la mateixa pantalla.

El primer pas serà provar que la introducció d'un valor real en cadascun dels camps de preselecció es

tradueixi al corresponent valor S5TIME d'engegada del temporizador. Això s'aconseguirà programant els tres

temporitzadors a l'OB1.

Degut a que tant la preselecció com el bit d'engegada es modifiquen des de la pantalla, hem definit els

següents valors a DB10.

Amb aquestes variables la programació dels temporitzadors ens queda:


167

Figura 4.45 – Declaració en el DB10 de les variables implicades

En primer lloc cridem a la funció REAL_TO_S5TIME, i li donem com a entrada el valor de preselecció que

s'hagi introduït en el corresponent camp d'entrada de la pantalla. La resposta de la funció la descarreguem a

“D_TP”.T1_S5T_SP en format S5TIME. Aquest mateix valor, és el que introduïm com a preselecció del

temporitzador.

Figura 4.46 – Crida de la funció i arranc del temporitzador


168

L'engegada del temporitzador la farem amb “D_TP”.T1_ON, el qual s'activa o es desactiva des de la

pantalla. Quan el temporitzador acaba el temps, es desactiva també el bit d'engegada. En la següent imatge

podem veure el resultat de la conversió:

Figura 4.47 – Assignació de valor de preselecció a T1 des de la pantalla per comprovar la funció de conversió

Per executar el programa, caldrà fer els següents passos: engeguem el simulador, carreguem el programa

del PLC al simulador i engeguem el runtime de Protool. A l’introduir un valor a temps 1, ens podem fixar que el

camp seg (segment 1) coincideix amb el valor S5TIME del temporitzador.


169

Conversió de temps simatic a real.

Com es pot intuir, sovint es fa necessària la funció contrària per poder convertir a tipus real el temps

transcorregut en el temporitzador. Això es podria utilitzar per tal de visualitzar els temps actuals de

temporitzadors quan estan activats.

Per poder construir aquesta segona funció que anomenarem S5TIME_TO_REAL, utilitzarem la funció

S5TIME_TIME (FC33) de l'apartat de funcions IEC de la llibreria estàndard que acompanya al paquet STEP 7.

Cal però destacar un parell de punts importants al respecte:

• Els temps actuals poden descarregar-se dels temporitzadors de dues possibles maneres. La primera seria utilitzant els paràmetres DUAL, aquest paràmetre es declara com a tipus WORD, i conté el temps que resta per completar el temps preseleccionat en format de tipus ENTER. Una segona opció, seria descarregar els paràmetres DEZ, el paràmetre de tipus DEZ també es declara com a tipus WORD, però ara el format no és de tipus ENTER si no de tipus BCD, que és equivalent a dir format S5TIME. És per aquest motiu que la nostra funció llegirà el temps actual a través del paràmetre DEZ.

• En comptes d'indicar el temps que falta per completar el cicle, indicarem el temps transcorregut des de l'engegada del temporitzador. És per això, que la nostra funció haurà de tenir com a paràmetre d'entrada el valor de preselecció. del temporitzador.

El codi de la funció escrita directament en SCL és:

Figura 4.48 – Codi de la funció S5TIME_TO_REAL


170

És una funció molt semblant a la anterior però voldria destacar dos aspectes:

• "entrada" és el paràmetre que rebrà al valor actual del temporitzador del paràmetre DEZ, que està declarat como WORD. Però cal tenir en compte que SCL no disposa de la conversió WORD_TO_S5TIME, per la qual cosa no podem traspassar directament la sortida de DEZ a l'entrada de S5TI_TIM. Tot i que hi ha altres solucions, en el nostre cas ho hem resolt declarant el que s'anomena "vista sobre una variable". Si observem l'apartat de variables d'entrada, veiem la declaració d'entrada_S5T AT entrada: S5TIME. Això vol dir exactament que entrada_S5T conté el mateix que entrada però que el seu contingut serà interpretat com S5TIME. D'aquesta manera podrem passar entrada_S5T a S5TI_TIM sense cap problema. Només cal tenir en compte que en la interfície de la funció només ens apareixerà la variable "entrada".

• Les conversions aplicades són: entrada_S5T passa a format TIME (miliseg), el resultat es passa a DINT, i finalment a REAL. Aquest resultat es divideix per 1000.0, i així el passem a segons. Per acabar, restem aquest resultat del valor preseleccionat per tal d'obtenir el temps transcorregut en comptes del temps restant.

Per provar la funció només ens queda cridar-la des de l'OB1. Com a paràmetre de sortida de la funció hi

posarem l'adreça DB10, la qual està assignada als camps de sortida de la pantalla.

La crida de la funció queda de la següent manera:

Figura 4.49 – Crida a la funció S5TIME_TO_REAL

Al paràmetre DEZ del temporitzador li assignem la variable temporal de l'OB1 #A1_W declarada lògicament

de tipus WORD. També li passem a SP el valor de preselecció del temporitzador com REAL. Finalment, la funció

ens retorna a RET_VAL el valor actual del temporitzador en segons per tal de poder-lo visualitzar des de la

pantalla.


171

Com podem comprovar en el sinòptic contigu, veiem els temps transcorreguts des de l'engegada dels tres

temporitzadors a la columna valor actual.

Figura 4.50 – Comprovació des de la pantalla, de les funcions de conversió


172

Funció per normalitzar o escalar una entrada analògica.

Com ja s'ha dit a la introducció, la realització de càlculs és una de les aplicacions on SCL pren clar

avantatge respecte KOP o inclús AWL. Per comprovar-ho, podem dissenyar el primer exercici en KOP i en SCL, i

comparar l'extensió del codi generat al PLC.

La normalització de variables analògiques a Siemens té les següents particularitats:

S'aplica generalment la funció de la llibreria estàndard FC105 SCALE. Aquesta funció aplica una conversió

lineal entre el valor d'entrada, (variable entre 0 i 27648 si l'entrada és de rang unipolar o entre -27648 i

+27648 si l'entrada es de rang bipolar) i un valor de sortida variable entre LO_LIM i HI_LIM.

Cal tenir en compte, però, que el valor d'entrada proporcionat per les targetes analògiques de l'S7-300 pot

sobrepassar el valor 27648. Un exemple, és quan s'ha connectat un sensor de rang de sortida 2 a 10 volts i el

sensor està proporcionant 10,5 volts a la targeta analògica, això indicarà que hi ha un desbordament a la

variable del procés que s'està mesurant. En aquesta situació, la funció SCALE proporcionada per STEP-7

donaria com a sortida, el valor HI-LIM. L'inconvenient d'aquest resultat és que no proporciona informació sobre

com s'està sobrepassant el valor màxim.

L'objectiu, per tant, d'aquest exercici és corregir la limitació de la funció SCALE fent que quan el sensor

d'un valor superior a 10 volts, 20 mA, etc,... la nostra funció mostri també un valor que estigui per sobre de

HI_LIM. Això significa que en el cas de desbordament, el valor pot arribar entre 27648 i 32767.

A la figura annexa es pot veure una crida a la FC105 SCALE, amb els seus paràmetres, el significat de

cadascun dels paràmetres s'anirà comentant al llarg de l'exercici:

Figura 4.51 – Crida a la funció “SCALE” de la llibreria de Siemens


173

Descriurem a continuació els punts clau en el procés d'escalat del valor d'entrada analògic.

En primer lloc, el sensor pot donar diferents rangs de valors (0-10v, 1-5v, 4-20mA, etc). quan la variable

en el procés varia de LO_LIM a HI_LIM. La variable en el procés pot variar fora dels marges indicats, provocant

que el sensor proporcioni un senyal fora dels rangs de mesura indicats.

En segon lloc la targeta d'entrada analògica connectada al PLC proporciona en una paraula de l'àrea de

memòria de perifèria d'entrades un valor enter comprès entre, 0 i 27648 si el rang del sensor és unipolar, o

entre -27648 i +27648 si el rang del sensor és bipolar.

En tercer i últim lloc, hem d'aplicar la funció escalar, i donar com a sortida el valor de la variable del procés

en unitats d'enginyeria. Donant per entès, que aquest valor estarà, en condicions normals, comprès entre

LO_LIM i HI_LIM.

Gràficament:

Figura 4.52 – Gràfic per il·lustrar el procés de normalització o escalat d’una variable analògica

La gràfica correspon a una entrada unipolar. Per a un valor “INPUT” qualsevol entre 0 i 27648 la funció ens

respon amb VAR_PV, que es correspondria amb el valor de la variable del procés. Cal que ens fixem en el detall

que la funció podria perfectament donar valors per sobre de HI_LIM quan INPUT varia de 27648 a 32767.

La fórmula que cal aplicar es dedueix de l'equació d'una recta que passa per dos punts (x1, y1), (x2, y2)

1)1(12

12yxx

xx

yyy +−∗

−−=

Aplicada al nostre problema, els punts de la recta són (0, LO_LIM), (27648, HI_LIM). La fórmula per al cas

de rangs unipolars és:

LIMLOINPUTLIMLOLIMHI

PVVAR _27648

___ +∗−=

0 27648 32767

HI_LIM

LO_LIM

INPUT

VAR_PV


174

Si el rang és bipolar els punts són (-27648, LO_LIM), (+27648, HI_LIM) i la fórmula canvia a la següent

expressió:

LIMLOINPUTLIMLOLIMHI

PVVAR _))27648(()27648(27648

___ +−−∗

−−−=

Estem ara en condicions de resoldre el problema amb SCL.

Creació del projecte:

Creem el projecte SCL001 i inserim un programa S7, tal como mostra la figura:

Figura 4.53 – Projecte SCL001 per a provar la funció d’escalat

A continuació cal crear el codi font en SCL de la nostra funció, cal tenir en compte, que primer crearem el

codi font, i després caldrà compilar-lo per generar el bloc executable que enviarem al PLC:

Creació de l'estructura per escriure el codi font SCL

• Entrem dins la carpeta "Fuentes" fent-hi doble clic. • Premem el botó dret del ratolí, i escollim l'opció "Insertar nuevo objeto / Fuente SCL" del menú

contextual

Figura 4.54 – Inserció de font SCL


175

• Canviem el nom de la funció escollint l'opció "Cambiar nombre" del menú contextual, i fent que passi a dir-se funcionEscalar en comptes de fuenteSCL(1).

Figura 4.55 – Canvi de nom de font SCL

De moment hem optat per treballar amb objectes de tipus "Font SCL", però més endavant també veurem

que es pot treballar amb objectes de tipus "Arxiu de control de compilació SCL".

• Obrim la font que acabem d'inserir (funcionEscalar) fent-hi doble clic. Veurem que s'obre l'editor per poder escriure el codi font.

• Seleccionem l'opció del menú general "Herramientas / Preferencias", activem totes les opcions de la pestanya "Crear bloques", i premem sobre el botó "Aceptar".

Figura 4.56 – Opcions del compilador de SCL


176

• Per tal d'estalviar-nos feina i errors podem utilitzar una plantilla de bloc escollint del menú general "Insertar / Plantilla de bloque / FC"

Figura 4.57 – Inserció de plantilla de funció

Comentem tot seguit el significat d'aquestes línies: En primer lloc, es demana el número de la FC que

volem editar, i si aquesta funció retornarà algun valor. si es així, cal indicar el tipus de dades del valor de

retorn. En la plantilla proposada la funció retorna un valor enter.

En segon lloc, ens demana la declaració de variables, en la qual només es pressuposa que existeixen

variables temporals, però a més a més de temporals, les variables, al igual que en KOP o en FUP, poden ser

d'entrada (VAR_INPUT), de sortida (VAR_OUTPUT), o d'entrada sortida (VAR_IN_OUT). Si se tractés d'un bloc

FB, les variables podrien ser, a més a més, estàtiques.

VAR_INPUT: són valors que introduïm a la funció. Des de la funció només podem llegir aquests valors.

VAR_OUTPUT: la funció entrega valors de sortida sobre aquests paràmetres, però no pot consultar el seu

valor mentre s'executa.

VAR_IN_OUT: la funció entrega valors de sortida sobre aquests paràmetres, però a més a més, pot

consultar el seu estat o valor en qualsevol moment.

Els tres tipus de variables, VAR_INPUT, VAR_OUTPUT i VAR_IN_OUT, apareixen como a paràmetres quan

s'invoca a la funció des d'un altre bloc. En cap cas apareixen les variables temporals ni las estàtiques quan

treballem amb FBs.


177

Per últim, la nostra funció (funció Escalar) deixa espai per a l'àrea d'instruccions, i acaba amb un valor

constant de retorno per a la funció i la paraula clau END_FUNCTION.

Generació del codi font SCL, declaració de variables:

Per concretar la nostra funció escalar, caldrà abans identificar els paràmetres o variables que necessitarem. Poden deduïr-se de la pròpia expressió que abans hem descrit.

Tindrem per tant, els següents paràmetres d'entrada: IN: Valor d'entrada de la funció. És el valor que ens proporciona la targeta analògica del PLC. Serà un valor

enter entre 0 i +32767 si el rang és unipolar, o entre –32767 i +32767 si el rang és bipolar.

HI_LIM: Valor màxim del marge del captador en unitats d'enginyeria. Es correspon amb el valor de la

variable del procés per al màxim senyal proporcionat per el captador: 10v, 20mA, etc. Serà un valor real.

LO_LIM: Valor mínim del marge del captador en unitats d'enginyeria. Es correspon amb el valor de la

variable del procés per al mínim senyal proporcionat pel captador: 0v, 4mA, etc. Serà també un valor real.

Bipolar: bit que indicarà a la funció que es tracta de rangs bipolars si està a 1 o unipolars si està a 0.

I els següents paràmetres de sortida:

RET_VAL: Valor de retorn de la funció que indicarà diferents estats.

VAR_PV: Valor de la variable de procés ja escalada que se correspon amb l'entrada proporcionada.

No són necessàries en aquesta funció variables d'entrada/sortida, però sí que definirem la constant K1 i la

variable temporal AR1. Cal observar la sintaxis per la declaració de la constant K1.

D'altra banda, la funció no proporcionarà valor de retorn, i per tant, indicarem la paraula clau VOID a la

capçalera.

És interessant observar també como només amb la declaració de variables i constants s'ha realitzat una

compilació per comprovar errors sintàctics i no s'han presentat errors.


178

Figura 4.58 – Compilar la funció amb l’àrea de declaració

Generació del codi font SCL, cos de la funció:

En la següent figura ja podem observar el codi de la funció. Cal observar que el paràmetre IN és de tipus

enter, i per tant, cal convertir-lo a real abans de poder operar amb la resta de variables.


179

Figura 4.59 – Codi de la funció i compilació completa

En KOP caldria utilitzar instruccions de conversió, en SCL també cal fer bàsicament el mateix, amb

l'avantatge que aquestes funcions ja estan definides en el llenguatge, és a dir, podem cridar a la funció

INT_TO_REAL sense més preocupació que la de la correspondència de tipus. Podem simplificar la funció

utilitzant la variable AR1 cobrint el cas per quan el rang és unipolar o bipolar.

Crida a "funcionEscalado", i comprovació dels resultats:

Ens cal finalment, programar la crida a la funció i provar-la. La cridem des de l'OB1, per exemple, como un

segment en KOP. Observar com a la carpeta “bloques” del nostre projecte apareix la funció FC55.

Per comparar la nostra funció amb la estàndard de Siemens, cridarem a les dues funcions simultàniament,

comparant resultats amb PLCSIM.

Les dues funcions tenen els mateixos paràmetres d'entrada i diferents paràmetres de sortida, amb això

podrem comparar resultats.


180

Després de transferir el programa al simulador, visualitzem en el propi simulador: PEW256 per forçar

l'entrada, MD0 i MD4 per veure els resultats.

En les següents figures tenim resultats per entrada “0”, per entrada “27648”, i per entrada “30000”.

Figura 4.60 – Comprovació de la funció i comparació de resultats amb “SCALE”

Per últim en la diapositiva final, s'observa la diferència entre la nostra funció i la de Siemens. Per a una

entrada 30000 superior a 27648, la funció de Siemens es queda a HI_LIM i la nostra segueix donant el valor de

proporcionalitat.


181

Figura 4.61 – Comprovació de la funció i comparació de resultats amb “SCALE”


182

Funció per a calcular el volum, el pes i el percentatge de càrrega d'una sitja.

En una sitja de forma cònica i cilíndrica es mesura el nivell de càrrega amb un sensor d'ultrasons Aquest

sensor entrega un senyal proporcional a l'alçada que hi hagi entre la superfície del líquid o sòlid que conté, i la

vora superior de la sitja. Si ens fixem en l'esquema, podem veure en detall com anomenem a cada part

mesurable de la sitja.

Per calcular el volum, podrem distingir

entre dos casos: el contingut supera l'alçada

h2, o el contingut no la supera.

En el primer cas es tractarà de calcular

el volum d'un cilindre d'alçada (h-h2) al que

hi afegirem el volum fix del con inferior.

En el segon cas es tractarà de calcular el

volum d'un con truncat d'alçada h i radi R.

Per tal de facilitar els càlculs trobarem

primer el volum del con truncat inferior.

El volum de la part del con que falta per

completar el con inferior, té una alçada

teòrica hci que es troba per trigonometria a

partir de R2, R1 i h2.

21

22

RR

hRhci

−⋅=

Figura 4.62 – Esquema del dipòsit que cal cubicar

El volum d'aquest con imaginari de radi R2 a la base, l'anomenarem Vci, i es calcula:

hciRVci ⋅⋅⋅= )2(3

1 2π

El volum total del con final de la sitja Vc serà el volum del con amb base de radi R1, menys el volum del

con amb base de radi R2


183

VcihcihRVc −+⋅⋅⋅= )2()1(3

1 2π

Amb aquestes dades, les formules a aplicar seran les següents:

Cas 1: h >= h2

Volum = Volum cilindre d'alçada h-h2 + volum con

VchhRVolum +−⋅⋅= )2()1( 2π

Cas 2: h < h2

En aquest cas, caldrà determinar el radi R corresponent al cercle on està la superfície del producte

emmagatzemat. Per trigonometria:

hci

hcihRR

)(2 +⋅=

VcihcihRVolum −+⋅⋅⋅= )()(3

1 2π

Amb aquesta introducció, podem ja plantejar el disseny de la funció que volem implementar.

La funció tindrà com variables de entrada:

InSensor: Enter amb valor de conversió provinent de la targeta analògica on està connectat el

sensor.

R1, R2, h1, h2: Reals amb valors expressats en metres per a fixar les dimensiones de la sitja.

Densitat: Real amb el valor de densitat del producte emmagatzemat.

Com a variables de sortida:

Volum, Pes: Reals que retornen el valor de volum i pes respectivament

%CapacitatTotal: Real amb el percentatge t’emplena’t de la sitja

Per tal de facilitar els càlculs guardant els resultats parcials, definirem també unes variables temporals:

Variables temporals:

hci, h, R, Vci, AR1: Reals


184

La seqüència d'operacions de la funció serà:

• Control d'errors en entrades • Escalat d'InSensor per a obtenir h. Amb això practicarem crides de funcions des de SCL. • Determinar valors auxiliars. • Determinar Volum, Peso i %CapacitatTotal

Escrivim el codi a VolumDiposit, que ja haurem creat.

En aquesta figura veiem la declaració de variables completa:

Figura 4.63 – Declaració de variables de volumDipòsit

Hem afegit una variable temporal anomenada error, la qual farem servir per la crida a la funció scale.

També hem declarat h com a variable de sortida en comptes de temporal, ja que ens pot ser útil per

determinades aplicacions.


185

En la part de programa, comencem fent un control de paràmetres d'entrada. En concret, si R1 o h1 són

zero, assignem un valor nul als paràmetres de sortida, i posem a 1 RetValue per indicar que hi ha un error als

paràmetres d'entrada. D'altra banda, si R1 i h1 tenen valors diferents de zero, la funció segueix el seu curs

normal.

Per cridar la funció Scale, el més fàcil és utilitzar el menú "insertar", i escollir l'opció "Llamada de bloque".

Això fa que s’obri per defecte la llibreria estàndard.

Figura 4.64 – Inserció d’una funció des de la llibreria de Siemens

La funció Scale es troba al grup TI-S7 Converting Blocks i és la FC105, la seleccionem, fent-hi doble clic.

Figura 4.65 – Aspecte de la crida des de SCL

Apareix el nom de la funció i entre parèntesi els seus paràmetres, amb comentari inclòs del tipus de

paràmetre (IN, OUT), i el tipus de dades associat al paràmetre (INT, REAL, BOOL)


186

En tancar els parèntesis, observem que hi ha un comentari amb indicació WORD. Això fa referència a que la

funció retorna un valor amb format de dades Word. Com es va veure al primer exercici, la font per la funció

Scale començaria així: "FUNCTION FC105: WORD" en comptes de "FUNCTION FC105: VOID". Tal i com hem

vist en la pròpia FC que estem desenvolupant.

Per tant, la crida a la funció Scale per resoldre la nostra funció quedaria:

Figura 4.66 – Crida de “SCALE” des de SCL i entrada de paràmetres

El codi complet de la funció quedarà de la següent manera, i passem tot seguit a comentar-lo:

Figura 4.67 – Codi complet de la funció volumDiposit


187

Si hi ha valors d'entrada incorrectes, es posen a zero les sortides i s'indica error a RetValue. Si els valors

d'entrada estan en el rang correcte, RetValue retorna zero, i fem un escalat de l'entrada del sensor entre 0 i la

alçada total de la sitja, h1+h2.

Determinem els valors auxiliars que hem comentat al plantejament. Apliquem dues formules segons si el

nivell està per sobre o per sota del con. Calculem el pes, el volum total i el percentatge t’emplena’t.

Ara per tant, ens caldrà programar la crida a la funció i provar-la amb PLC_SIM. La crida a la funció la

realitzem a OB1 i queda així:

Figura 4.68 – Crida de la funció volumDiposit

Comprovem la funció assignant valors de prova a les variables d'entrada, a la variable InSensor li assignem

el canal analògic PEW256. I a les variables de sortida assignem els registres de l'àrea de marques, i així

podrem observar el seu valor al simulador.


188

Finalment, engegarem el simulador, carreguem el programa i depurem la funció fins que ens funcioni

correctament.

Figura 4.69 – Depuració de la funció volumDiposit

Podem, al igual que amb KOP, veure el funcionament de la funció activant la funció "Observar". En

l'exemple, hem fet proves per dipòsit ple, dipòsit buit, i un parell de valors de nivell mitjà. Cal tenir en compte

que el volum està en m3, l'alçada en metres i el pes en Kg.


189

Dipòsit ple: Dipòsit buit:

Figura 4.70 – Valors de resposta de volumDiposit amb nivells 0 i màxim

Valors mitjà 1: Valors mitjà 2:

4,78 m de producte. 1,5 m de producte

54,82 % de capacitat 5,09 % de capacitat

Figura 4.71 – Valors de resposta de volumDiposit amb nivells mitjà

Qualsevol dels dos exercicis anteriors també es podria programar en KOP, però el codi que s'hauria d'escriure

seria bastant més extens.


190

Càlcul de temps d'activació o funcionament de dispositius.

Aquest és també un problema bastant usual en el control de processos. Molts cops caldrà controlar la

duració d'un procés o el temps de funcionament d'un dispositiu que realitza cicles de treball prolongats de

l'ordre d'unes quantes hores, per exemple, compressors frigorífics, bombes, emplenat de sitges, etc.

En aquests casos no s'han de comptabilitzar els temps d'interrupció (alarmes de dispositius, aturades per

accions de l'operador, etc.), sinó només els temps efectius destinats a la tasca o procés del qual es vol mesurar

el temps. A més a més, el valor d'aquest temps cal visualitzar-lo en un dispositiu HMI, el que implica una

actualització constant del seu valor.

No seria adequat, per tant, actualitzar el temps només en acabar el cicle, ja que el valor visualitzat tindria

sempre l'error del temps corresponent a l'últim cicle.

La funció medirTemps que implementarem en l'exemple, tindrà com a entrada dos senyals: el senyal on/off

del dispositiu o procés, i un senyal per poder posar a zero els comptadors. Aquest segon senyal podria provenir

del terminal de l'operador o scada, i la seva actuació estaria protegida amb un password per evitar l'esborrat

accidental dels comptadors.

El format data i hora CPU (DT date and time) és un format de dades complex que ocupa 8 bytes de

memòria i per tant hem d'utilitzar funcions incloses a la llibreria estàndard del Step 7. Com que el volum de dades que tractem amb la funció serà gran comparat amb els exercicis anteriors, i com que a més a més serà una funció que es podrà fer servir bastants vegades en un mateix projecte, implementarem la funció amb un FB. D'aquesta manera, els paràmetres que no es vulguin incloure en la interfície, es declararan com a variables estàtiques, i els seus valors actuals quedaran emmagatzemats al corresponen DB d'instància del FB.

Per sintetitzar, en aquest exercici practicarem amb formats DT, crides de funcions en SCL, crides de FB i

multiinstàncies. Els paràmetres a utilitzar seran els següents: Entrada:

DP_ON_OFF:Senyal on off del dispositiu o procés DP_RES_ACC:Esborrat de comptadors

Entrada Sortida:

DP_NC_ACC: Número de cicles acumulat al dispositiu o procés DP_T_ACC: Temps acumulat de funcionament en dispositiu o procés DP_T_UC: Temps últim cicle en dispositiu o procés

Sortida:

DP_DT_IUC: Data i hora inici últim cicle en dispositiu o procés DP_DT_FUC: Data i hora finalització últim cicle en dispositiu o procés

Estàtics:

DP_FUP: Flanc de pujada per al senyal on off del dispositiu o procés DP_A_FUP: Auxiliar per a l'obtenció del flanc anterior DP_FDOWN: Flanc de baixada per al senyal on off del dispositiu o procés DP_A_FDOWN: Auxiliar per a l'obtenció del flanc anterior DT_UMIN: Data i hora de l'últim registre

Comencem editant la nostra funció inserint en la carpeta "fuentes" del projecte SCL001 la font SCL

"medirTiempo". Anem a l'editor de SCL, inserim plantilla per a bloc FB, i realitzem la declaració de variables especificada anteriorment.

En aquest exemple he declarat les dues variables DP_DT_IUC i DP_DT_FUC com paràmetres de sortida. De

fet, les podríem també considerar como variables estàtiques. La meva opinió és la següent: si aquestes dues variables han de visualitzar-se en el sistema HMI, si són declarades como paràmetres de sortida, serà possible


191

enllaçar-les amb altres variables d'un DB específic per al sistema HMI. Si pel contrari, són declarades com variables estàtiques, el sistema HMI haurà de llegir-les del propi DB d'instància del FB. Totes dues solucions són possibles, tot i que per estil de programació prefereixo la primera opció. A més a més, el fet d'incloure-les como paràmetres de sortida, ens permetrà practicar amb el format DT.

L aspecte de la declaració del nostre FB és el següent:

Figura 4.72 – Declaració de variables i paràmetres de la funció

Respecte a les tasques en les que podem dividir la nostra funció, les enumerarem com segueix:

• Elaborar flancs de pujada i baixada del senyal d'engegada del procés. • Anotar data i hora d'inici de cicle quan apareix el flanc de pujada, posar a zero el comptador d'hores de

l'últim cicle i incrementar l’acumulador de maniobres o cicles. • Mentre el senyal del procés estigui en ON, llegir el rellotge de la CPU i comparar la data i hora actual

amb la de l'últim registre per a detectar el pas d'un minut. Quan això succeeixi, incrementar acumuladors i actualitzar registre.

• Quan aparegui el flanc de baixada anotar data i hora de parada i incrementar acumuladors com en el

pas anterior.

• Esborrar acumuladors quan aparegui el senyal d'esborrat dels mateixos.


192

Comentem cadascun de les parts de codi corresponents a aquestes tasques:

Elaboració de flancs de pujada i baixada.

Figura 4.73 – Codi SCL per elaborar flancs de pujada i baixada

Si el procés està en ON, posem a 1 l'auxiliar per a flanc de baixada, el qual l'utilitzarem més endavant. Si

l'auxiliar per a flanc de pujada no està a 1, és que estem en el flanc de pujada, i per tant activem tant el flanc de pujada com el seu auxiliar.

Com es pot observar, en el següent cicle de programa el flanc de pujada passarà a 0 degut a que el seu

auxiliar romandrà activat. Si el procés passa a OFF, posem a 0 el flanc de pujada i el seu auxiliar. Si l'auxiliar per a flanc de baixada està a 1, és que estem en el flanc de baixada, i per tant l'activem al mateix temps que desactivem l'auxiliar per a flanc de baixada. Al igual que abans, en el següent cicle de programa que romangui el procés en OFF, es posarà a 0 el flanc de baixada.

Anotar data i hora d'inici del cicle.

Figura 4.74 – Codi SCL per registrar data i hora d’arranc del dispositiu

Quan apareix el flanc de pujada incrementarem el comptador de cicles o maniobres. Llegim l'hora del

sistema amb SFC1 i la registrem com la data i hora d'inici de l'últim cicle o maniobra (DP_DT_IUC). Guardem aquesta data i hora a DT_UMIN, ja que ens serà útil per a comparacions posteriors. Posem a zero el comptador d'hores de l'últim cicle.


193

Llegir rellotge de la CPU:

Figura 4.75 – Crida de vàries funcions des de SCL

Mentre el procés estigui en ON, llegim el rellotge de la CPU amb SFC1 i comparem el DT (date and time)

corresponent amb el registrat a l'inici del cicle. Per comparar els DTs utilitzem la FC 34 de l'apartat funcions IEC de la llibreria estàndard de l'Step7. Caldrà

restar dos DT i trobar el temps transcorregut entre els dos DT, si el temps transcorregut és igual o superior a un minut, incrementem els acumuladors de temps.

Per últim, actualitzem DT_UMIN per a posteriors comparacions. Cal fer uns aclariments respecte la

comparació de DTs. Al fer la comparació, hem de convertir el format TIME a ENTER, i com que en realitat conté el temps en milisegons, comparem amb els milisegons que té un minut. Per a sumar als acumuladors passem a REAL el temps en milisegons, i abans de realitzar la suma amb l’acumulador, el dividim pel número de milisegons que té una hora.

Anotar data i hora d'aturada.

Figura 4.76 – Registre de l’hora d’aturada

Si estem en el flanc de baixada, llegim el rellotge de la CPU, calculem el temps transcorregut des de l'últim minut, i el sumem als acumuladors, convertit a hores.

Esborrar acumuladors

Figura 4.77 – Esborrat de registres acumuladors


194

Si se presenta el senyal d'esborrat d’acumuladors, posem a zero tant el comptador de maniobres com el de

temps de funcionament.

Ens resta només, cridar al bloc de funció i provar-lo. Com en els casos anteriors, el cridem des de l'OB1, i el provem amb el simulador.

Figura 4.78 – Crida del FB

Al cridar a l'FB, hi ha alguna diferència respecte les crides a FCs. En primer lloc l'assignació de valors als

paràmetres, es pot deixar en blanc. En aquest cas, l'FB treballarà amb els valors del DB d'instància, el número del qual es demana a la capçalera de la crida. Si el número de DB no existeix, ens demana si e volem generar. Finalment, la crida quedarà com segueix:

Figura 4.79 – Crida del FB amb assignació del DB d’instància

Assignem les entrades E124.0 per al senyal ON OFF del procés, i E124.1 per a l'esborrat dels acumuladors.


195

4.2.4 Tractament de dades en llistes i matrius.

Filtrat d'una variable analògica.

Els problemes tipus on s'han de tractar gran quantitat de dades (organitzades per exemple en un array),

també se resolen d'una manera òptima amb SCL. En l'exemple que se descriu, es tracta de resoldre un

problema bastant usual en els sistemes automàtics on cal treballar amb valors analògics.

El senyal que ens arriba d'un captador, porta un rissat incorporat que pot tenir diverses causes, de vegades

difícils d'eliminar. Aquest rissat, provoca que el valor numèric de la conversió de la variable pateixi continues

variacions, que per exemple, si la variable es visualitza en una pantalla, provoqui un efecte molest. Per poder

solucionar el problema, introduïm un filtre entre el valor que ens arriba directament de la targeta analògica i el

valor que donem per a la variable, que finalment serà el que es visualitzarà.

El filtre que es proposa, consisteix en emmagatzemar una determinada quantitat de valors passat com a

paràmetre, calcular la mitja d'aquests valors, i donar aquesta mitja com valor de la variable.

En aquest cas necessitarem un array per a emmagatzemar els valors que ens van arribant per l'entrada. La

funció utilitzada serà un FB, d'aquesta manera els paràmetres quedaran en el DB d'instància de l'FB.

Determinació de la posició de càrrega en un robot cartesià.

Un robot cartesià ha d'emmagatzemar tres tipus diferents de peces cilíndriques que es distingeixen

bàsicament pel seu color, poden ser negres, taronges o de color gris clar. Les peces negres i taronges són de materials plàstics, i les peces gris clar són de materials metàl�lics.

Les peces s'emmagatzemen segons el tipus, en tres files de 13 peces cada fila distanciades entre elles

60mm segons l'eix x. L'origen es troba a l'extrem superior dret del sinòptic que se mostra a continuació, i la primera peça de cada fila està situada a les coordenades (100, 250) per a les peces negres, (100, 350) per a les peces grises i (100, 450) per a les peces taronges.

El tipus de peça es detecta abans de l'entrada al magatzem mitjançant tres detectors, un de capacitiu

(detecta qualsevol tipus de peça), un altre inductiu (detecta només les peces metàl�liques), i un altre de reflexió directa, que detecta les taronges i les metàl�liques, però no les negres. Els tres detectors es troben connectats a les entrades:

E0.0 inductiu E0.1 capacitiu E0.2 reflex La presència o no de peça en cadascuna de les posicions del magatzem, es guarda en un array de bits al

DB10, de manera que un 1 en l'índex [11, 2] de l'array, vol dir que hi ha una peça metàl�lica a la posició 11. L'objectiu serà dissenyar una funció, que tenint com entrades els senyals dels tres detectors, i la taula de

posicions del DB, ens doni com sortides el tipus de peça (negra =1, metàl�lica =2 i taronja =3) i les coordenades de la posició de descàrrega per a les funcions de posicionament dels eixos. A més a més, la funció haurà d'avisar-nos en cas de fila completa


196

Figura 4.80 – Esquema del magatzem objecte de la funció proposada

Plantegem la funció utilitzant pseudocodi:

acció buscarPosicióCàrrega(ent inductiu, capacitiu, reflex: bool,

entsort taulaPosicions: taula[13, 3] de bool,

sal posX, posY: real, sal tipusPeça: int, sal filaPlena: bool)

const

delta_x: real = 60.0;

inici_x: real = 100.0;

fconst

var

j: int;

trobat:: bool;

coordy: taula[3] de real;

fvar

{Assignem coordenades Y a taula}

coordy[1] := 250.0;

coordy[2] := 350.0;

coordy[3] := 450.0;

{Determinar tipus de peça}

tipusPeça := 0;


197

si (capacitiu = 1) aleshores

si (inductiu = 1) aleshores

tipusPeça := 2;

sino

si (reflex =1) aleshores

tipusPeça := 3;

sino

tipusPeça := 1;

fsi

fsi

fsi

{Determinar posicions}

si tipusPeça <> 0 aleshores

j:= 1;

filaPlena := FALS;

trobat := (taulaPosicions[j, tipusPeça] = 0);

mentre (trobat = FALS) i (j <= 13) fer

trobat := (taulaPosicions[j, tipusPeça] = 0);

j := j+1;

fmentre

{Assignem coordenades nul�les en cas de fila plena, o posició x,y en la resta de casos}

posx := 0,0;

posy := 0,0;

si j>13 aleshores

filaPlena := CERT;

sino

posx := inici_x + delta_x * (j-1);

posy := coordy[tipusPeça];

fsi

fsi

facció


198

Generació del codi SCL

Tot seguit, implementem la funció en SCL, caldrà per tant, com hem fet en passos anteriors, inserir un

objecte de codi font SCL, i començar a programar.

El primer pas serà fer la declaració de variables, constants i paràmetres. Cal observar, el matís que prenen

les variables en pseudocodi o en SCL, és a dir:

- el que en pseudocodi es declara com a variables locals (de var a fvar), en SCL es declara com a VAR_TEMP.

- els paràmetres que es declaren en pseudocodi com a entrada (ent), en SCL es declaren com a VAR_INPUT.

- els paràmetres que es declaren en pseudocodi com a sortida (sort), en SCL es declaren com a VAR_OUTPUT.

- els paràmetres que es declaren en pseudocodi com a entrada/sortida (entsort), en SCL es declaren com a VAR_IN_OUT.

Figura 4.81 – Declaració de la funció buscarPosicionesCarga


199

La resta del codi, l'implementem d'una manera molt similar al pseudocodi:

Figura 4.82 – Assignar valors inicials

Figura 4.82 – Codi complet de la funció


200

Crida a la funció i declaració dels símbols

Finalment, ens restarà fer la crida a la funció des de l'OB1, i provar el seu funcionament. En aquest cas,

serà necessari també, crear la corresponent estructura de dades en el DB10 declarant els símbols necessaris:

Figura 4.83 – Declaració de dades al DB10

Declarant també l'array de bits de posició al DB10:

Figura 4.84 – Declaració de la taula de posicions al DB10

Fem la crida a la funció "buscarPosicionesCarga" des de l'OB1.

Figura 4.85 – Crida a la funció per determinar les posicions x i y del robot cartesià

Engegada del simulador i comprovació de resultats

Per últim, obrim el simulador i carreguem la carpeta “bloques” veient els resultats als paràmetres de

sortida.


201

En primer lloc provem els tres tipus de peça amb el magatzem buit. Com podem observar en els resultats,

per a peça metàl�lica ens dóna el tipus de peça correcta i la posició de la primera peça a la fila corresponent es

també correcta.

Figura 4.85 – Resposta de la funció per peça metàl�lica i magatzem buit

Per a peça taronja els resultats són també correctes.

Figura 4.86 – Resposta de la funció per peça taronja i magatzem buit

Ara provarem amb posicions del mig. Per aconseguir-ho, inserim al nostre projecte una taula de dades amb

els valors de la taula de posicions per a poder ocupar posicions a voluntat.

Figura 4.87 – Resposta de la funció amb ocupacions variades de magatzem


202

En la situació mostrada, la primera posició lliure per a peces negres, és la 9, de coordenades (250, 580).

Això és exactament el que ens dóna la funció com a resposta, tal i com s'observa en la figura següent:

Figura 4.88 – Resposta de la funció amb ocupacions variades de magatzem i peça negra

Per tal d'acabar de comprovar la nostra funció, ens assegurarem que pel cas "fila plena", la gestió del

magatzem es fa correctament:

Figura 4.88 – Magatzem ple per peces metàl�liques

Amb les dades de la taula anterior, la resposta de la funció és la següent:

Figura 4.89 – Resposta 0 a registres de posició si magatzem ple

És a dir, com que filaPlena = 1, els registres de posició també es posen a zero, tal i com estava previst.

pr ctiques de suport - xtec · 2.2.2 configuració de la xarxa mpi . creació de material didàctic...

Documents