Conducerea Unei Celule Flexibile de Fabricatie Holonica cu Retea de Automate Programabile

Conducerea unei celule flexibile de fabricatie holonica cu retea de automate programabile

Cuprins

1 Introducere

2 Arhitecturi de conducere cu inteligenta distribuita a proceselor de fabricatie

2.1 Sisteme Flexible de Fabricatie distribuite (dFMS)

2.2 Arhitecturi de conducere automata cu inteligenta distribuita (DIAS) a FMS

2.2.1 Sisteme clasice de conducere automata a fabricatiei la nivel 3 (shop-floor)

2.2.2 Sisteme holonice de conducere automata a fabricatiei la nivel 3 (shop-floor)

3 Structura de fabricatie de tip job-shop, resurse, functii si regimuri de conducere cu

automat programabil

3.1. Structura de fabricatie, resurse si procese de lucru

3.1.1 Structura de fabricatie, resurse si procese de lucru

3.1.2 Robotii SCARA pentru asamblare rapida si realimentare cu componente

3.1.3 Robotii articulati vertical pentru conturare si asamblare necesitand dexteritate

3.1.4 Dispozitive de comanda a resurselor – controllerul robot

3.1.5 Mașini de frezat cu comanda CNC

3.1.6 Sistemul de transport al fluxului de palete – conveior si componente

3.1.6.1 Dispozitive port-paleta

3.1.6.2 Conveiorul longitudinal si unitatea de transfer

3.2 Implementarea deciziilor MES. Rutarea produselor in CFF cu retea de automate

programabile (PLC)

3.2.1 Solutia de conducere a fabricatiei. Functia de rutare a produselor cu PLC

3.2.2 Arhitectura automatului programabil pentru executia deciziilor MES (rutare

palete) si comunicatie cu resursele

3.2.3 Sistemul RFID RD si RD/WR de identificare a paletelor pe conveiorul CFF

3.3 Interfata PLC cu sistemul de control al magazinului ASRS pentru palete (micro-

controller si controller al robotului Cartezian)

4 Sistemul de programe pentru automatizarea executiei produselor planificata in MES si

regimuri de operare normala ale PLC

4.1 Regimuri PLC standard de control al resurselor CFF pentru rutarea si executia

produselor conform deciziilor MES

4.1.1 Regimul de comanda manuala

4.1.2 Regimul de diagnoza

4.1.3 Regimul de control automat pentru executia produselor

4.2 Solutia de control in timp real cu automat programabil a celulei de fabricație

4.2.1 Problematica rutării paletelor de catre PLC conform deciziei mixte MES de

planificare produse, secventiere operatii si alocare resurse

4.2.2 Date schimbate de către automatul programabil cu planificatorul celulei (SS)

4.2.3 Inițializarea sistemului pentru lansarea in executie a unui lot de produse

4.2.4 Protocolul de comunicație între resursa de transport (conveior) și resursele de

prelucrare / asamblare produse (robot)

4.2.5 Protocolul de comunicatie PLC-Controller Robot Cartezian pentru

Introducerea/ evacuarea paletelor în sistem

4.2.6 Protocolul de comunicatie controllerul robotului Cartezian si microcontrollerul

depozitului ASRS de palete

4.3 Organizarea sistemului de programe PLC pentru regimul de control automat

4.3.1 Programul tip Opritor

4.3.2 Programul de tip lift

4.3.3 Programul de tip transfer

4.3.4 Programul de tip comunicație robot

4.3.5 Programul de tip TCP_data_send

4.3.6 Programul de tip scriere cod

4.3.7 Programul de tip gestiune timp

4.3.8 Programul de tip GUI (Graphic User Interface)

4.3.9 Program de tip comunicație OPC

4.3.10 Funcții specifice TCP/I5

5 Managementul schimbarilor la perturbatii in CFF cu ajutorul automatelor programabile

5.1 Gestiunea situatiilor de defectare / revenire in stare functionala a unei resurse

5.2 Gestiunea situatiilor de epuizare a stocurilor in depozitele locale și implementarea

holonului de realimentare

6 Concluzii

7 Bibliografie

8. Anexa: Programe de aplicatii: cod sursa, capturi de ecran

Cap. 1 Introducere

Sistemele de conducere automata a proceselor de producție distribuite, cu resurse multiple (specifice industriilor: auto, aerospatiala, electrotehnica, farmaceutica, alimentara – caracterizate prin fabricatia discreta, repetitiva de produse realizate prin mai multe operatii tehnologice executate de diferite resurse) au înregistrat o evoluție semnificativă în ultimii ani, datorită avansului în tehnologia informației, aparitiei unor noi paradigme de control: Inteligenta Distribuita, Automatizare Dirijata de Produs, Fabricatie Holonica, Agentificarii componentelor, proceselor si comenzilor de la client prin arhitecturi distribuite de tip Multi-agent, cat si orientarii catre servicii a proceselor de business (managementul comenzilor, al furnizorilor, activitatile CAE, CAD, CAPP) si a celor tehnice (rutare si executie produse, alimentarea depozitelor, inspectie de calitate on line, monitorizarea executiei productiei si trasabilitate a produselor).

Astfel, apare intreprinderea digitala contextuala, in care volume mari de date culese din piete, din activitati de marketing si din retele sociale au permis integrarea totala a proceselor din punct de vedere informational:

Integrarea orizontala intre:

Subsistemele MES (Manufacturing Execution System – conducerea tehnica de nivel superior a productiei): (1) planificarea globala la nivel de loturi de produse comandate (in MES – Manufacturing Execution System centralizat off line, cu Planificator Global, SS – System Scheduler) si (2) alocarea de resurse descentralizata in timp real, cu sistem multi-agent(dMES – distributed MES); comutarile intre aceste moduri de planificare mixta sunt declansate de evenimente perturbatoare in celula flexibile de fabricatie: defectarea resurselor, epuizarea stocurilor locale in statiile de lucru;

Integrarea verticala intre:

Nivelul de de business (relatia cu clientii, furnizorii, reglementari legislative, managementul cererilor de oferta si al comenzilor, pregatirea fabricatiei, facturare si livrare) si nivelul tehnic al proceselor de productie (planificarea loturilor, secventierea operatiilor si alocarea resurselor, crearea stocurilor de materiale necesare fabricatiei, automatizarea executiei produselor, controlul de calitate, monitorizarea proceselor tehnice si trasabilitatea produselor);

Nivelul ierarhic superior MES de conducere semi-heterarhica a productiei (prin dualismul SS – dMES) si nivelul ierarhic inferior de automatizare dirijata de produs a fabricatiei, realizata cu retea de automate programabile (PLC).

Unul dintre cele mai inovatoare aspecte in automatizarea sistemelor de fabricatie o reprezintă apariția sistemelor descentralizate, cu inteligenta distribuita, capabile să reacționeze agil, în timp real, la schimbările mediului de producție (shop-floor), ale pietei, la variabilitatea produselor comandate si la tendinta de customizare in masa )loturi de dimensiune variabila, de la unicate la zeci de mii de unitati) spre deosebire de sistemele tradiționale ierarhice centralizate care se bazează pe particularitatiile si restrictiile mediului în care vor funcționa. Caracteristicile principale urmărite în dezvoltarea acestor noi clase de sisteme de conducere sunt indreptate catre proprietăți cum ar fi agilitate, reconfigurabilitate, robustete la perturbatii, auto-adaptare pentru productie continua si sustenabilitate.

Arhitectura multi-agent (MAS) reprezinta un mijloc de implementare a sistemului de control holonic al fabricatiei, bazat pe entitati – holoni – cu reprezentare duala: a) fizic (resursa, produs, comanda) si b) informatic (date si informatii ce caracterizeaza elementele fizice si relatiile dintre acestea, decizii de conducere) printr-o abordare distribuită ce pleaxa de la resursele, operatiile tehnologice si comenzile multiple ce coexista. MAS ordoneaza sistemul de conducere a fabricatiei ca o compoziție de elemente modularizate, avand corespondenti informatici – agentii (care implementeaza holoni) a caror interacțiune este guvernată de mecanisme contractuale care permit reconfigurarea structurii de productie in conditii de perturbatie de natura economica sau tehnica, in vederea mentinerii angajamentelor asumate de producator (numar si calitate produse, livrarea la timp, etc.).

Obiectivul lucrarii de disertatie este de a propune o solutie de automatizare dirijata de produs bazata pe automate programabile pentru o celula de fabricatie flexibila in care se desfasoara procese de productie de tip job-shop, si pentru care planificarea mixta a loturilor a produselor (secventierea operatiilor si alocarea resurselor) si realizeaza pe un nivel MES de ctip semi-heterarhic (dual: SS – dMES).

Modelul de conducere semi-heterarhica cu integrare SS-dMES este un model de interacțiune care permite cooperarea între două subsisteme diferite: (1) un sistem de planificare centralizat (SS), bazat pe o tehnologie selectabilă de planificare și alocare (de exemplu, programare de constrângeri, normele de producție) și (2) un subsistem descentralizat de execuție a fabricației (dMES), bazat pe o arhitectură holonică de referință și pe aplicarea modelului multi-agent delegat. Acest model de interacțiune va fi definit în termeni de:

Evenimentele care declanșează noi cereri de planificare pentru SS, secvențe de comutare bidirecționale între modurile de planificare ierarhice și heterarhice;

Mecanismul de decizie pentru comutarea între modurile de planificare;

Modelul de acces la serviciile unei resurse luând în considerare participarea resursei la funcția de costuri, sarcina cumulată, consumul de energie, promptitudinea și calitatea serviciilor prestate de echipa de lucru din care face parte resursa respectivă.

Modelul de colaborare pentru interacțiunea SS – dMES implică două niveluri de control (calcul, luarea deciziei, urmarirea aplicarii deciziei):

Nivelul MES, in care se realizeaza simultan functiile de : a) planificarea ordinii introducerii spre executie in CFF a produselor din loturile diferite ce au acelasi termen de livrare; b) secventierea tuturor operatiilor tuturor produselor din loturile de la a), considerand restrictiile de precedenta existente (specificate in holonul produs); c) alocarea de resurse tuturor operatiilor secventiate in b) pentru produsele planificate in a) – aceasta se bazeaza pe specificatiile continute in holonii resursa. Rezultatul final al acestor activitati de calcul de optimizare este reprezentat de lista ordonata a holonilor ordin, care contin informatia necesara executiei produselor. Aceasta lista este furnizata automatului programabil central al CFF. Cele trei activitati MES pot fi executate:

Centralizat, in nivelul MES centralizat implementat de un sistem informatic SS centralizat, cu considerarea de criterii de optimalitate (timp minim de executie, incarcare uniforma a resurselor, s.a.);

Descentralizat, in nivelul MES descentralizat implementat de un sistem multi-agent distribuit dMES, cu considerarea criteriilor de agilitate, neintreruptibilitate a productiei, optimalitate locala la nivelul tuturor produselor in executie simultana

Nivelul de comanda a executiei productiei, cu retea de automate programabile, in care se realizeaza simultan functiile:

Rutarea de catre automatul programabil central al CFF a paletelor cu produse de realizat conform rezultatelor calculului de: a) planificarii produselor, b) secventierii operatiilor si c) alocarii resurselor obtinute in nivelul MES;

Comanda de catre automatul programabil central al CFF de lansare in executie a programelor resurselor pentru realizarea operatiilor asupra produselor;

Comanda de catre automatele programabile locale ale statiilor de lucru a: alimentarii / evacuarii de palete, realimentarii cu componente a magazinelor din posturile de lucru, monitorizarii operatiilor de productie si trasabilitatii produselor.

Nivelul de automatizare B este proiectat si implementat in cadrul prezentului proiect de disertatie cu o retea de automate programabile, functia critica din punctul de vedere al timpului real fiind cea de rutare a paletelor cu produse in conformitate cu specificatiile cuprinse in holonii ordin – rezultati din calculul MES si cu informatiile schimbate ultimativ (inainte de intratrea paletei in postul de lucrru) cu resursa alocata de MES.

In afara functiei de rutare a produselor conform deciziilor de planificare si alocare provenite de la MES, in cadrul proiectului a fost solutionala si problema managementului schimbarilor determinate de evenimente perturmatoare: 1) defectarea / revenirea in stare functionala a resurselor, si 2) epuizarea temporara a stocurilor de materiale in depozitele locale ale statiilor de lucru.

A fost proiectata arhitectura hardware bazata pe automate programabile Indra Logic si microcontrollere ATMEGA, pentru care a fost realizat sistemul de comunicatie cu resursele CFF, cu MES si agentii MAS. De asemenea a fost proiectat si implementat sistemul de programe software pentru regimurile de comanda:

Comanda manuala;

Diagnoza automata;

Rutare automata a paletelor cu produse conform cu recomandarile MES, in regim normal de executie a productiei;

Managementul schimbarilor declansate de defectarea / revenireas in stare de functionalitate a resurselor;

Activarea holonilor de realimentare cu componente a depozitelor locale, si rutarea automata a paletelor cu componente simultan cu executia holonilor ordin aflati in executie.

In lucrare se prezinta rezultate experimentale obitinute, iar in Anexa lucrarii sunt incluse sursele unora dintre programele sistemului PLC

Cap. 2 Arhitecturi de conducere cu inteligenta distribuita a proceselor de

fabricatie

2.1 Sisteme Flexible de Fabricatie distribuite (dFMS)

Sistemele de fabricatie flexibila – FMS (Flexible Manufacturing Systems) sunt specifice proceselor de fabricatie complexa, distribuita intre mai multe resurse de prelucrare (masini CNC, roboti, surse de sudura), manipulare (roboti) si transport al produselor (conveioare, vehicule ghidate automat), si au beneficiat in ultimele doua decenii de solutii, arhitecturi fizice si sisteme software care asigura o adaptare rapida atat din punct de vedere fizic (interschimbabilitatea si modularizarea componentelor mecanice ale resurselor), al topologiei structurii de productie (adaugarea / eliminarea de resurse in functie de cerintele de executie a loturilor, de starea de functionalitate / performantele tehnice si de consumul energetic al acestora), cat si din punct de vedere al sustenabilitatii si robustetii in functionare (optimizarea planificarii loturilor de produse si a alocarii resurselor, incarcarea echilibrata a resurselor, agilitate la dinamica cererilor clientilor – comenzi urgente, variabilitatea produselor, customizarea la nivel de masa).

Acest tip de structuri de fabricatie (FMS) cuprinde un set de statii de lucru, interconectate in diferite variante (job-shop, flow-shop, etc.) prin intermediul unei structuri de transport de tip conveior si a unor dispozitive de manipulare a materialelor si a produselor (roboti industriali), monitorizate prin senzori de prezenta, de identificare si de control (RFID, camere video, etc.) si conduse automat de un sistem informatic integrat [Groover, 1987], [Upton, 1992].

Fig. 2.1 prezinta pozitionarea FMS in raport cu clase de structuri de productie existente.

Fig. 2.1 Pozitionarea FMS in raport cu clase de structuri de fabricatie individualizate [Upton, 1992]

Sistemele de tip FMS prezinta avantaje semnificative [Rembold et al., 1993], [Ranky, 1990], fata de celelalte clase evidentiate: (1) cresterea productivitatii (de 2-3,5 ori); (2) scaderea costurilor de productie (50%); (3) reducerea stocurilor (85%); (4) cresterea calitatii prin control de calitate interfazic, in timp real; (5) cresterea agilitatii (adaptarea la dinamica pietei: comenzi urgente – rush orders, variabilitatea produselor comandate, customizarea in masa) (de 1,5-2 ori); marirea robustetii la perturbatii tehnice (defectare resurse, epuizare stocuri de componente in statiile de lucru) (de 2,5-3 ori).

Structurile de fabricatie de tip FMS sunt specifice pentru industrii pentru care cererile de executie de loturi de produse se plaseaza intr-o gama larga: [unicate, …., productie de masa – mii de produse] / comanda; industrii specifice sunt: auto, aeronautica, componente si subansamble mecanice, farmaceutica, alimentara, s.a.

Un sistem de fabricatie distribuit se defineste ca un sistem de productie care are o distributie geografica localizata la nivelul uneia sau mai multor intreprinderi si care ale carui resurse dispuse in statii de lucru multipleactioneaza in mod colaborativ (autonom cat si in cooperare) pentru a contribui impreuna la realizarea produselor dintr-un lot comandat.

Aceasta distributie a rezultat ca raspuns la competitia tot mai acerba in fata pietei globale, si a implicat ca inteprinderile cu profil productiv sa isi reconsidere modul de organizare. Diferitele tipuri de sisteme distribuite de fabricatie prezinta structuri si caracteristici care pot fi modelate si legate printr-o abordare stratificata, ilustrata de Fig. 2.2 [Leitao si Restivo, 1999].

Nivelul ierarhic superior (nivelul 0) – layer-ul intrar-intreprindere, reprezinta interactiunea dintre intreprinderi / structuri de productie distribuite ale aceluiasi consortiu (grup), care actioneaza impreuna pentru a realiza un obiectiv economic complex comun – de exemplu autovehicule, aeronave. s.a.

Mergand mai departe, se poate identifica un alt nivel, cel al intreprinderiiindividuale, in care coopereaza un numar de structuri de productie (de tip: sectie de productie, linie de fabricatie, turnatorie, presa, etc.) si de business (birouri si departamente de ofertare si engineering / consultanta, proiectare, planificare si urmarire a productiei, aprovizionare, vanzari, etc.) in vederea realizarii loturilor de produse de complexitate mica-medie comandate de clienti – de exemplu motoare, cutii de viteza, s.a. resurse si entitati materiale si umane (statii de lucru, sisteme de transport, sisteme de inspectie, depozite de materiale, avand personal uman), dintre entitatile distribuite geografic, cum ar fi birouri de vanzari si centre de productie, intr-un mediu multi-site.

Urmatorul nivel ierarhic inferior este cel al structurii (fabricii) de productie care reuneste un numar de ateliere de fabricatie (SFF compuse din entitati de tip: prelucrari flow-shop, job-shop;linie de vopsire; sectie de tratament chimic / termic; linie de asamblare / montaj; centre de prelucrare; etc.), in care se exercita o conducere informatizata integrata, tot mai frecvent bazata pe sisteme automate cu inteligenta distribuita – DIAS (Distributed Intelligence Automated Systems). Pe acest nivel toate entitatile sunt de productie (atelier de productie – shop floor), si ele comunica cu nivelul proceselor de business de pe nivelul ierarhic superior (primesc, executa si raporteaza executii de produse / servicii individualizate prin defalcarea comenzilor pe atelierele componente).

Ultimul nivel, ierarhic inferior (4), corespunde platformelor individuale de fabricatie (de tip: statie de lucru, depozit local, ASRS, celula de prelucrare / montaj, etc), autonome, cu capacitati de comunicare, ce pot fi integrate ad-hoc / reconfigurate in echipe de lucru avand capabilitati complementare necesare realizarii unui anumit tip de produs.

Fig. 2.2 Fabricatia distribuita – abordare ierahizata pe nivele de organizare

2.2 Arhitecturi de conducere automata cu inteligenta distribuita (DIAS) a FMS

Consideratiile care vor fi expuse in continuare in cadrul lucrarii se refera la sistemele de conducerea automata cu inteligenta distribuita (DIAS) a structurilor de productie de pe nivelul atelierului de productie – shop-floor), care reprezinta entitatea de baza tehnica, organizatorica si operativa pentru realizarea produselor dintr-un lot comandat. Solutia de comanda automata de tip DIAS, bazata pe automate programabile interconectate, ce va fi elaborata in cadrul prezentei lucrai se refera la un astfel de atelier de productie de complexitate medie (5 resurse robot industrial, 2 resurse masini de frezat CNC, o resursa ASRS prismatic pentru introducere / evacuare de palete, un magazin dual de componente mecanice pentru realimentarea posturilor de lucru si un ansamblu de 10 camere video matriciale pentru inspectia de calitate a produselor si evitarea coliziunilor in operatii robotizate) reprezentativ pentru nivelul ierarhic 3 din Fig. 2.2.

Sistemele de fabricatie distribuita sunt in mod clasic medii heterogene, care cuprind componente software si hardware, fiind distribuite in privinta functiilor, abilitatilor si operatiilor pe care le pot efectua. Structurile de fabricatie deacest tip trebuie sa actioneze colaborativ pentru a indeplini un set de obiective comune:

Executia unui numar de produse dintr-un lot comandat, cu: caracteristicile impuse si la termenul de livrare impus;

Respectarea indicatorilor de calitate declarati pentru fiecare tip de produs;

Reconfigurabilitatea dinamica a consortiului de resurse la aparitia unor evenimente cu caracter tehnic (caderi de resurse, epuizari de stocuri) si / sau economic (tratarea de comenzi urgente); non-intreruptibilitatea productiei in cazul caderii unei resurse;

Agilitate in reactia la dinamica pietei

Sustenabilitatea structurii de productie: reducerea timpilor de executie, echilibrarea incarcarii resurselor, mentinerea de consumuri energetice reduse;

Asigurarea mentenantei preventive.

Sistemele de control al fabricatiei trebuie sa se bazeze pe un set de componente autonome pentru a face mai usoara organizarea acestora ca structuri cooperative, dinamice si distribuite, capabile sa partajeze informatii si mecanisme de decizie pentru atingerea obiectivelor enuntate mai sus. Sistemele de control trebuie sa fie treconfigurabnile si extensibile, facand posibila adaugarea de noi componente fara necesitatea reproiectarii, reprogramarii si reinstalarii unor componente de sistem.

Sistemele clasice de control al fabricatiei au o capacitate scazuta de adaptare si reactie la schimbari dinamice ale mediului (defectarea unor echipamente, variabilitatea cerintei pietei) in principal datorita rigiditatii arhitecturii lor informationale si de automatizare. In Fig. 2.3 sunt prezentate cerinte derivate din segmentele: tehnic (executie produse), economic (competitivitate, piata globala) si relatie cu clientii (calitate a produselor, respectarea termenelor de livrare, cost). Un element important este necesitatea interpretarii unui volum mare de informatii si de date utile peru luarea deciziilor de: segmentare a pietei, extensie produs-serviciu, s.a. Astfel, prin exploatarea masivelor de date de piata, competitie, reglementari legale si preferinte clienti – big data – este posibila luarea de decizii inteligente pentru asigurarea obiectivelor listate mai sus, in cadrul a ceea ce este definit in prezent ca intreprindere contextuala [McKinsey, 2013].

Fig. 2.3 Cerinte pentru proiectarea sistemelor de control al fabricatiei distribuite (dFMS)

Sistemele DIAS de control al fabricatiei flexibile distribuite dFMS trebuie sa detina mecanisme de integrare a unor echipamente si dispozitive automate, cum ar fi roboti sau masini unelte, si sa ofere facilitati de comunicare on line toleranta la defect. De asesemea, trebuie sa furnizeze interfete om-masina pentru asigurarea monitorizarii proceselor de lucru si a trasabilitatii produselor. Pentru eliminarea riscului de blocare a sistemului de conducere automata si a celui de executie a productiei este necesara redundanta, replicarea, eliminarea punctelor critice de comanda / decizie (Single Point of Failure – SPOF) atunci cand sunt proiectate:

Sistemul informatic de conducere automata (topologia, reconfigurabilitatea, functionarea semi-heterarhica) si

Alcatuirea consortiului de echipante – resurse de lucru (reconfigurabilitate dinamica, extensibilitate, izolare rapida).

Un aspect important legat de sistemele de control al fabricatiei, absolut necesar pentru asigurarea sustenabilitatii, este integrarea orizontala a planificarii productiei cu secventierea operatiilor / produs si alocarea resurselor / operatii, in vederea unei executii eficiente. Acest lucru necesita o viziune integrata a tuturor functiilor de control al fabricatiei, pentru a obtine o optimizare simultana a planificarii loturilor de productie si a alocarii sarcinilor de fabricatie, luand in considerare disponibilitatea resurselor de fabricatie la momentul curent, stadiul de degradare a performantelor resurselor si mententanta lor predictiva.

Functiile de planificare a loturilor, secventiere a operatiilor / produs si alocare a resurselor / operatii se realizeaza pe nivelul ierarhic 2 (fabrica) in reprezentarea din Fig. 2.3.

Transpunerea celor trei tipuri de decizii luate la nivelul 2 in comenzi efective care:

ruteaza produsele catre resursele asignate, in secventa calculata;

creaza istoricul (log) executiei lotului de fabricatie;

asigura trasabilitatea produselor executate;

monitorizeaza starea resurselor, performantele si calitatea serviciilor asigurate de resurse;

declanseaza reactualizarea secventierii operatiilor si alocarii resurselor la aparitia unor evenimente,

la nivelul structurii efective de fabricatie (shop-floor) de pe nivelul 3 se va realiza prin retea de automate programabile interconectate.

2.2.1 Sisteme clasice de conducere automata a fabricatiei la nivel 3 (shop-floor)

In prezent functioneaza si sunt referite in literatura de specialitate patru tipuri de arhitecturi clasice de control al fabricatiei (Fig. 2.4), implicand transportul,procesarea, manipularea, controlul de calitate si trasabilitatea produselor [Dilts et al., 1991].

Fig. 2.4 Arhitecturi clasice de conducere automata a fabricatiei pe nivelul 3 (shop-floor)

Arhitectura centralizatade conducere presupune existenta unei singure unitati de control care ia toate deciziile cu privire la circulatia, procesarea si manipularea fluxului materialelor din sistem. Un sistem centralizat are avantajul unei arhitecturi simple si ofera posibilitatea optimizarii globale (pe intreg orizontul de executie a loturilor de produse comandate). Totusi, aceasta arhitectura are si cateva dezavantaje importante cum ar fi: timp mare de raspuns in calcule de planificare cand sistemul detine un numar mare de resurse, dificultati in operarea de schimbari in software-ul de control si lipsa tolerantei la defect (atunci cand unitatea centrala se defecteaza, intregul sistem de conducere devine neoperabil).

Arhitectura ierarhica de conducere este rezultatul unei abordari top-down, tip master-slave, in care fluxul de comenzi este transmis strict de la controlerele de nivel superior (nivelul MES – Manufacturing Execution System) catre controlerele de nivel inferior (nivelul de comanda a utilajelor – masini, roboti, depozite etc.), permitand un comportament determinist al sistemului.

Incertitudinea inerenta a sistemelor reale nu este luata in considerare; in cazul unor perturbatii relative la conditiile initiale pentru care sistemul a fost realizat, performantele sistemului se deterioreaza drastic. Timpul de raspuns este mai mic decat in cazul sistemelor cu arhitectura centralizata. Desi arhitectura de control ierarhica permite optimizarea globala, exista dezavantaje majore: operarea oricarei schimbari in structura hardware/software a sistemului este o sarcina foarte dificila care nu poate fi realizata decat prin oprirea sistemului si actualizarea tuturor nivelelor ierarhice cu noile informați; lipsa tolerantei la defect face ca arhitectura de control ierarhica sa functioneze cu mari dificultati in cazul in care o masina CNC sau un robot se defecteaza.

Arhitectura hibrida de conducere deriva in principal din cea ierarhica, diferenta fiind ca acest tip de arhitectura permite cooperarea si partajarea informatiilor intre controlere de nivel ierarhic inferior. Supervizorul initiaza toate procesele iar apoi unitatile subordonate coopereaza pentru a le realiza. Daca apar modificari ale conditiilor initiale de operare, supervizorul preia controlul, astfel incat deciziile controlerelor de nivel inferior sunt limitate la conditiile de operare normale. Deoarece implicarea controlerelor de nivel inferior in procesul de luare a deciziilor este limitata, arhitectura de control hibrida prezinta atat avantajele cat si dezavantajele arhitecturii de control ierarhice.

Arhitectura heterarhica de conducere este formata dintr-un grup de entitati independente reprezentate de agenti care liciteaza pentru comenzi (sarcini de productie), in functie de starea lor curenta si incarcarea viitoare. In acest caz nu exista o relatie de tip master-slave ca in cazul arhitecturilor prezentate anterior. Toti agentii, inclusiv managerul unei comenzi particulare, liciteaza pentru acea comanda. Cand agentul castigator termina sarcina pe care o avea de efectuat, el devine automat noul manager al sarcinii ce urmeaza.Datorita arhitecturii descentralizate, agentii au autonomie locala totala si sistemul poate reactiona prompt la orice schimbare survenita. Totusi, deoarece comportamentul unei comenzi (sarcini) depinde de numarul si caracteristicile altor comenzi din sistem, este imposibil de impus optimizarea controlului la nivel global iar performantele sistemului nu pot fi prevazute.

2.2.2 Sisteme holonice de conducere automata a fabricatiei la nivel 3 (shop-floor)

Pentru a face fata cerintelor de operare la scara globala si pentru a satisface nevoile crescande ale pietei de consum, comunitatea stiintifica a pus bazele unui program international de cercetare in domeniul fabricatiei, denumit Intelligent Manufacturing Systems – [IMS]. Pentru a compensa atat deficientele sistemelor de control ierarhice cat si ale celor heterarhice, IMS a introdus in ultimii ani noi concepte de proiectare a sistemelor de fabricatie: intreprinderea fractala, productia aleatoare, productia bionica si sistemele holonice de fabricatie. Fiecare concept incearca sa modeleze un sistem de fabricatie pe baza unor analogii cu alte sisteme: teoretice/matematice pentru productia fractala [Warneke, 1993]; naturale pentru productia bionica [Okino, 1993]; de organizare sociala pentru productia holonica [van Brussel et al., 1998].

Aceste noi paradigme pentru controlul distribuit al fabricatiei au abilitatea de a raspunde prompt si corect la schimbari de mediu externe si difera de abordarile conventionale datorita capabilitatii inerente de a se adapta schimbarilor fara interventii externe.Aceste paradigme sugereaza faptul ca entitatile individuale din cadrul sistemului trebuie sa aiba o autonomie crescuta si capabilitatea de a lua decizii proprii. Totusi, abordarea ierarhica este necesara pentru a garanta coerenta globala a sistemului si a gestiona conflictele care pot aparea intre entitatile autonome [Sousa et al., 1999].

Esenta conceptului de sistem de fabricatie holonic – HMS (Holonic Manufacturing System) este reprezentata de notiunea de holon, care a fost propusa de scriitorul si filosoful maghiar Arthur Koestler pentru a descrie o unitate organizationala de baza in sistemele biologice si sociale [Koestler, 1969] . El a introdus pentru prima data acest cuvant, in cartea sa „The Ghost in the Machine”, parte a unei trilogii asupra sistemelor ierarhice deschise.

Un holon, dupa definitia dată de Koestler, este o parte identificabila a unui sistem, care are o identitate unica desi este formata la randul sau din parti subordonate, ea fiind la randul ei parte a unui intreg (ansamblu) mai mare.Holonii sunt unitati autonome, ce au un anumit grad de independenta si trateaza diferitele situatii fara a cere instructiuni de la autoritati superioare; in acelasi timp, holonii pot fi controlati de autoritati superioare.

Prima proprietate asigura faptul ca holonii sunt forme stabile, ce supravietuiesc perturbatiilor. Cea de a doua proprietate este ca ei sunt forme intermediare, ce asigura impreuna o functionare corespunzatoare ansamblului. Alternativ, holonii au o tendinta de autoafirmare, ca manifestare a caracteristicii lor de intreg (ansamblu), si o tendinta de integrare, ce exprima dependenta fata de un ansamblu mai mare sau caracteristica lor de parte (subansamblu).

O holarhie reprezinta, dupa definitia data de Koestler, o ierarhie de holoni autoreglabili ce functioneaza:

ca ansambluri autonome in supra-ordonare fata de partile lor componente;

ca parti dependente in subordonare fata de nivelele superioare;

in coordonare cu mediul lor inconjurator.

Holarhia reprezinta deci un sistem de holoni care coopereaza pentru atingerea unui scop sau a unor obiective comune, pe baza unor reguli care guverneaza cooperarea intre acestia si respectiv limiteaza autonomia lor [Brussel, 1994].

Introducerea conceptului de sistem holonic in fabricatie are ca scop obtinerea in cadrul procesului de productie a beneficiilor pe care structurile holonice le furnizeaza organismelor vii, cum ar fi stabilitatea fata de perturbatii, adaptabilitate si flexibilitate la schimbari si folosirea eficienta a resurselor disponibile.

Pentru a translata conceptul de holon al lui Arthur Koestler in fabricatie, consortiul Holonic Manufacturing Systems (HMS) a elaborat in anii 96’-98’ urmatoarele definitii:

Holon – un ansamblu de constructii autonome si cooperative ale unui sistem de fabricatie pentru a transforma, transporta, depozita si/sau valida informatii si obiecte fizice. Holonul consista dintr-o parte de procesare a informatiei si frecvent si dintr-o parte de procesare fizica. Un holon poate fi parte a unui alt holon.

Autonomie – capabilitatea unei entitati de a crea si controla executia propriilor planuri si / sau strategii.

Cooperare – un proces prin care un set de entitati dezvolta planuri comun acceptabile si executa aceste planuri.

Holarhie–setul de relatii intr-un sistem de holoni ce pot coopera pentru a ajunge la obtinerea unui obiectiv. Holarhia defineste regulile de baza pentru cooperarea holonilor si prin aceasta le limiteaza autonomia.

Sistem de fabricatie holonic – o holarhie ce integreaza intreaga gama de activitati de fabricatie de la preluarea unei comenzi pana la proiectare, productie, si marketing pentru a realiza intreprinderea de fabricatie agila.

Atribute holonice – atributele unei entitati ce ii confera calitatea de holon. Setul minim este autonomia si cooperarea. Alte atribute importante sunt algoritmii si procedurile pentru negocierea impartirii sarcinilor de lucru (task-urilor), precum si cele pentru executarea actiunilor stabilite in comun.

Comportarea holonica poate fi exprimata prin doua tendinte complementare, „tendinta de auto-afirmare” si „tendinta de integrare”, [Brussel 1994]. Stabilitatea holonilor rezulta din abilitatea lor de a actiona autonom, fara o coordonare continua, de la nivel superior, in situatii neprevazute.

Autonomia holonilor de a executa sarcini de lucru date este o proprietate mostenita si exprima „tendinta de auto-afirmare” a acestora. Ea se refera la controlul local si operarea masinilor, optimizarea la nivel local, autocoordonarea, autoconfigurarea, autodiagnoza, autoinvatarea, etc.

Cooperareaprin negociere intre holoni exprima „tendinta de integrare”, ce este datorata nevoii de supravietuire si evolutie in mediul in care se afla si se refera la proprietati ca: flexibilitate, orientare, scop, autoorganizare, extensibilitate, etc. (Fig. 2.5).

Fig. 2.5 Holarhie si conceptual de cooperare

Fiecare unitate de productie, resursa tehnologica, activitate logica sau fizica, echipament din cadrul unei structuri de fabricatie (robot, masina de comanda numerica, etc), ordin de productie sau chiar un operator uman poate fi considerat ca fiind un holon [Leitao si Restivo, 1999]. Pe langa faptul ca reprezinta resursa fizica (robotul, masina, etc), holonul detine informatii si cunostinte atat despre resursa cat si despre mediul in care activeaza [Winkler si Mey, 1994]. Holonii coopereaza intre ei, de la planificare si alocarea sarcinilor de productie pana la prelucrari fizice directe, pentru fabricarea unui produs. Structura sistemelor holonice de fabricatie are la baza o ierarhie functionala si unitati cu o structura similara, repetabila la toate nivelurile.

Un holon poate fi parte a unui alt holon si in acelasi timp poate fi constituit din mai mai multi alti holoni. Spre exemplu, o structura de control al fabricatiei poate avea un holon care sa reprezinte celula de fabricatie, constituit din alte seturi de holoni: pentru manipularea pieselor (robotii) sau pentru prelucrarea materialelor (masinile de comanda numerica).

Implementarea conceptelor holonice de control al fabricatiei poate fi realizata utilizand tehnologiile multiagent, care se refera la un nivelul superior de abstractizare si corespunde caracteristicilor de complexitate, modularitate, descentralizare, reutilizare, etc [Marik et al., 2002], [Marik et al., 2003].

In ceea ce privese nivelul de control inferior (al utilajelor din structura de productie – pe nivelul shop-floor), interconectarea cu dispozitivele si resursele fizice, achizitia datelor de la senzori, comanda si actionarea diverselor echipamente cat si comunicatia cu nivelul ierarhic superior (MES) este realizata cu ajutorul automatelor programabile (PLC). In acest sens se pot dezvolta programe de control utilizand standarde pentru limbajele de programare: IEC 1131-3 sau IEC 61499. Acesta din urma defineste noi tehnici pentru controlul si executia algoritmilor in cadrul sistemelor distribuite, prin incapsularea si reutilizarea modulelor software [Vyatkin et al., 2001], [Holobloc, 2003], [Vyatkin si Hanisch, 2003].

In literatura de specialitate se pot intalni diferite lucrari referitoare la arhitectura holonica. Christensen in 1994, a fost primul care a propus o arhitectura generala a holonilor (Fig. 2.6) [Christensen, 1994]. In aceasta se pot observa cele doua componente principale ale unui holon: informatia pe care o detine si elementul fizic pe care il reprezinta. Componenta fizica este optionala, exemple de holoni fara aceasta componenta fiind ordinele de productie, planificatoare, secventiatoare, etc.

Fig. 2.6 Arhitectura generala a unui holon [Christensen, 1994]

Componenta fizica este reprezentata de structura materiala (motor, manipulator, hardware) care realizeaza operatiunea de fabricatie impreuna cu componentele care comanda hardware-ul respectiv (CNC, PLC, Controllere etc). Componenta informationala se compune din trei module: (1) nucleul holonului sau centrul de luare a deciziei, (2) interfata inter-holon pentru interactiune si comunicare cu alti holoni si (3) interfata cu operatorul uman pentru date de intrare (comenzi de operare) si iesire (monitorizarea starilor).

In [Bussmann, 1998] si [Bussmann et al., 2004] se propune o arhitectura bazata pe agenti pentru partea de procesare a informatiilor din arhitectura generala a lui Christensen. Bussmann isi bazeaza propunerea in viziunea holonica asupra entitatilor autonome si cooperative. Aceasta viziune contine trei aspecte. In primul rand, holonii sunt capabili sa controleze in mod autonom comportamentul echipamentului atasat. Holonii isi pot crea si executa planuri proprii si sa isi urmeze propiile strategii in cadrul capacitatilor proprii. Acest comportament autonom implica existenta unui tip de componenta de luare a deciziilor care ghideaza controlul fizic al holonilor. In al doilea rand, doi sau mai multi holoni sunt capabili sa coopereze in locul sau la momentul in care este necesar. Pentru aceasta, holonii trebuie sa fie capabili sa identifice situatiile in care este necesara cooperarea, sa se implice in coordonare sau negociere, si in final, sa stabileasca de comun acord mecanismele de cooperare. In al treilea rand, holonii sunt capabili sa actioneze in cadrul unor organizatii multiple, numite holarhii, care sunt create si modificate in mod dinamic.

PROSA (Product-Resource-Order-Staff Architecture) [Brussel et al., 1998], [Wyns, 1999] este o arhitectura de referinte pentru sistemele holonice de fabricatie, care utilizeaza holonii pentru a reprezenta produsele, resursele, comenzile de productie si activitatile logice care au loc in sistemul de productie. Aceasta arhitectura a fost elaborata la Universitatea Catolica din Leuven, Departamentul de Inginerie Mecanica. Trei tipuri de holoni de baza compun arhitectura PROSA (Fig. 2.7): holoni produs (product holons), holoni resursa (resource holons), si holoni de comanda (order holons). Acesti holoni sunt structurati folosind conceptele de agregare si specializare din programarea orientata pe obiect. Aditional, mai este utilizata o alta categorie de holoni de expertiza (staff holons) a caror misiune este sa asiste si sa coordoneze holonii de baza, un exemplu de astfel de holon fiind un planificator in cadrul unui sistem de fabricatie.

Fig. 2.7 Arhitectura de referinta PROSA

PROSA permite acoperirea aspectelor specifice arhitecturilor ierarhice si heterarhice de conducere, facand posibila conducerea in regim semi-heterarhic, cu auto-reconfigurare dinamica a modurilor de control:

Mod ierarhic, asigurand optimizare globala la nivelul loturilor de fabricatie prin deciziile de: (1) planificare a ordinii de introducere a produselor in celula, (2) secventiere a operatiilor / produs, si (3) alocare a resurselor pentru operatiile secventiate, luate de holonul de expertiza in urma unor calcule off-line.

Mod heterarhic, asigurand agilitate in raspunsul la evenimente care necesita schimbari in strategia de productie (de ex. aparitia unor comenzi rapide – rush orders) si robustete la perturbatii de natura tehnica (de ex. caderi de resurse, epuizare de stocuri de materiale etc.).

Controlul semi-heterarhic este exercitat de cei trei holoni de baza si de cel de expertiza astfel: rezultatele planificarii centralizate, ale secventierii operatiilor si ale alocarii resurselor efectuate in mod optimal de catre holonul staff sunt furnizate doar ca recomandari (si nu ca impuneri) structurii de productie – punerea in opera a acestor recomandari ii revine retelei de automate programabile care ruteaza produsele, comanda: prelucrarea materialelor, aprovizionarea depozitelor locale, controlul de calitate, si realizeaza trasabilitatea produselor. Atata timp cat nu se manifesta perturbatii, productia se desfasoara confor acestor recomandari optimale. De indata ce apare o perturbatie tehnica (cadere de resursa) sau de natura economica (o comanda urgenta), sistemul comuta instantaneu in modul heterarhic, in care planificarea este ignorata si deciziile de secventiere operatii + alocare de resurse sunt luate in timp real, colectiv de agentii de comanda, in mod sub-optimal doar la nivelul ansamblului de produse aflate in executie simultana; procesul de fabricatie nu este intrerupt, functioneaza usor degradat pana la refacerea consortiului de resurse pentru comanda in curs, prin:

revenirea in stare functionala a resursei defectate anterior, sau

activarea unei alte resurse valide, similare celei defectate.

PROSA introduce inovatii semnificative in conducerea automata a sistemelor distribuite: structura sistemului este decuplata de algoritmul de conducere, aspectele logice sunt decuplate de cele tehnice, PROSA deschizand oportunitati pentru dezvoltarea unor algoritmi hibrizi avansati de conducere. Ideea de a adauga holoni de control (staff holons) la holonii de baza decupleaza proprietatile de agilitate si robustete de optimizarea globala a sistemului, lucru posibil doar in sistemele ierarhice. Acest holon de expertiza este vazut ca o entitate care se ocupa cu programarea si planificarea sarcinilor de lucru, avand acces la informatiile referitoare la resursele si comenzile existente in sistem. Prin aceasta, sistemul devine ierarhic, dar nu in sensul strict deoarece acest holon nu da ordine ci doar recomandari pe care ceilalti holoni le pot urma sau nu.

Fiind o arhitectura de referinta, PROSA ofera doar repere generale pentru o arhitectura de sistem. Ea se refera la sistemul de manipulare a materialelor ca fiind un holon resursa, dar nu specifica ce functii sunt indeplinite de fiecare holon de baza atunci cand este necesara o operatie de transport. Se admite ca procesul va cuprinde unele sau toate din urmatoarele elemente:

Holon resursa – o singura entitate ce realizeaza unul sau mai multe procese fizice sau operatii de transport si dispune de sistem de conducere propriu (sau orice operatie efectuata de operator).

Holon produs – o entitate ce consta din produsul fizic care va fi fabricat, specificatia de realizare si suportul logistic, uman si tehnic necesar realizarii efective a produsului (este agregat la nivelul intregului lot de fabricatie comandat).

Holon de comanda – o entitate ce reprezinta cerintele pentru indeplinirea unei anumite comenzi (emise de clientul) si care include informatii precum: ruta produsului (ordinea in care vor fi realizate operatiile si resursa alocata pentru fiecare operatie), caracteristicile tehnice ce trebuie asigurate, schema de inspectie interfazica, si datele vitale inregistrate in timpul executiei (timp de executie, consum de energie, etc).

Holon coordonator – unitate suport (sistem informatic, calculator, operator uman sau o combinatie intre acestia) optionala; asigura coordonarea intre diversi holoni si reprezentarea obiectivelor globale ale structurii de productie.

Arhitectura ADACOR [Leitao, 2004], [Leitao si Restivo, 2003] este construita pe un set de entitati autonome si cooperative, reprezentate de holoni ce suporta distributia de cunostinte si deprinderile lor si imbunatateste capacitatea de adaptare la schimbarile mediului. Fiecare holon este o reprezentare a unei componente de fabricatie ce poate fi atat resursa fizica, cat si o entitate logica. Componentele de fabricatie sunt holonificate pentru a implementa un comportament ce reprezinta obiectivele si functionalitatile sistemului de fabricatie, fiecare holon fiind responsabil de indeplinirea anumitor functionalitati.

Aceasta arhitectura implementeaza reactia sistemului la defectiuni si schimbari rapide, marind agilitatea si flexibilitatea sistemelor de productie automatizate, in special a celor situate in medii afectate frecvent de perturbatii. ADACOR se adreseaza in special nivelului celulei de fabricatie si in special sistemelor de productie flexibile, caracterizate de procese concurente si asincrone cu operatii multiple si rute alternative.

Arhitectura ADACOR, bazata pe conceptul de holon, tinde sa fie cat de descentralizat posibil si cat de centralizat este necesar. Se poate folosi de exemplu o abordare ierarhica (centralizata) pentru a se atinge optimul tehnico-economic si o abordare heterarhica (descentralizata) in prezenta evenimentelor neprevazute si modificarilor.Astfel, ADACOR propune descompunerea functiilor de productie intr-un set de entitati autonome si cooperative, ce exp[loateaza avantaje precum: modularitate, descentralizare, agilitate, flexibilitate, robuste si scalabilitate. Introducerea entitatilor supervizoare creeaza o ierarhie in sistemele descentralizate care ajuta la atingerea optimului. Capabilitatile de autoorganizare asociate entitatilor distribuite permit evolutia dinamica si reconfigurarea structurii de control, reunind optimul global al productiei cu raspunsul rapid la perturbatii.

Referitor la tipurile de holoni, arhitectura ADACOR (Fig. 2.8) grupeaza holonii de fabricatie in clase de produse, de taskuri, operationale si de supervizare. Aceasta generalizare se bazeaza pe gruparea componentelor fabricii conform functionalitatii si obiectivelor, ca in conceptul de specializare din modelul orientat pe obiecte.

Holonul de supervizare este inspirat din sistemele biologice si prezinta caracteristici similare celor ale holonilor de coordonare (staff holons) definiti in PROSA, iar holonii produs, task si operationali sunt similari cu holonii produs, comanda si resursa din PROSA.

Fiecare produs care trebuie sa fie fabricat in intreprindere este reprezentat de un holon produs ce contine toate cunostintele legate de produs si este responsabil de procesul de planificare pe termen scurt. In arhitectura ADACOR, holonul produs contribuie de asemenea la integrarea tuturor functiilor de control.

Fig. 2.8 Interactiunea intre holoni in arhitectura ADACOR

Fiecare ordin de productie lansat la nivelul celulei de fabricatie pentru executia unui produs este reprezentat de un holon task, care este responsabil de comanda propriei executii, continind informatii dinamice despre secventierea productiei.

Holonii operationali reprezinta resursele fizice disponibile la nivelul atelierului, cum ar fi operatori, roboti si masini cu comanda numerica, si isi manifesta comportamentele conform cu obiectivele si specificul resursei. Holonul operational coordoneaza agenda resursei, de exemplu lista de planificari ale ordinelor de lucru pe care resursa de fabricatie trebuie sa o execute in timp.

Acest tip de holon poate fi compus la randul lui din mai multi holoni operationali si supervizori. In acest caz, holonul supervizor este componenta logica iar holonii operationali sunt componentele fizice ale holonului principal. De exemplu, o celula de productie poate fi modelata de catre un holon operational compus la randul lui din mai multi holoni operationali, fiecare reprezantand o resursa de productie si un holon supervizor reprezentand unitatea de comanda (controller-ul) a celulei. La randul lor holonii operationali, care reprezinta resursele pot fi formati din alti holoni operationali, cum ar fi masina cu comanda numerica si sculele din magazia aferenta. Holonul supervizor introduce coordonarea si optimizarea globala in mecanismului de control decentralizat. Holonii ADACOR folosesc conceptul de plug and produce, fiind astfel posibil sa fie adaugate noi elemente sistemului fara a fi nevoie de reinitializarea si reprogramarea acestuia. Astfel se poate obtine o mai mare flexibilitate la adaptarea si reconfigurarea sistemului. Fiecare holon este autonom si poate intra sau iesi din sistem la orice moment, fiind doar necesar ca sistemul, ca un intreg, sa nu perceapa aceasta perturbatie

Imbuntatirile aduse de introducerea arhitecturii ADACOR pot fi observate pe doua niveluri diferite: nivelul de proiectare si nivelul operational. La nivelul de proiectare, dat fiind avantajul utilizarii sistemelor descentralizate, proiectarea, intretinerea, expandarea si reutilizarea aplicatiilor de fabricatie este realizata mult mai simplu decat in cazul solutiilor tranditionale. La nivelul operational, arhitectura propusa furnizeaza un mecanism de adaptare a structurii sistemului de control al fabricatiei in cazul aparitiei perturbatiilor si de revenire la modul normal de operare dupa disparitia perturbatiei. In acest fel, optimizarea controlului centralizat, in absenta perturbatiilor, este combinata cu agilitatea controlului hetero-ierarhic in situatii instabile determinate de aparitia frecventa a perturbatiilor. [Leitao si Restivo, 2002, a, b, c], [Leitao et al., 2003, a, b, c], [Leitao si Restivo, 2004].

Cap 3. Structura de fabricatie de tip job-shop, resurse, functii si regimuri de conducere cu automat programabil

3.1. Structura de fabricatie, resurse si procese de lucru

Se considera o structura de productie cu resurse multiple, in care pot fi realizate procese de lucru de tip job-shop (componentele fluxului de materiale pot circula de la fiecare post de lucru la oricare din celelalte). Din punctul de vedere al proceselor de lucru ce pot fi realizate – procesare de materiale (aschiere, vopsire, marcare), asamblare / montaj, inspectie de calitate, alimentare cu componente, manipulare, paletizare si transport aceasta structura de productie este constituita ca o celula flexibila de fabricatie (CFF), vezi Fig. 3.1. Celula flexibila de fabricatie este amplasata in Laboratorul de Robotica si CIM al Facultatii de Automatica si Calculatoare din UPB.

Fig. 3.1 Celula Flexibila de Fabricatie ca structura de productie de tip job-shop

In CFF se realizeaza loturi de produse comandate; un lot poate cuprinde unul sau mai multe tipuri de produse identice. Realizarea fiecarui tip de produs se face prin executia succesiva a mai multor operatii, intre care pot exista sau nu precedente predefinite. Operatiile sunt realizate in 4 posturi de lucru robotizate:

Posturile 1 si 2 in care se pot realiza operatii identice (prelucrare, asamblare / montaj, control de calitate, paletizare) de catre un robot articulat orizontal (SCARA);

Posturile 3 si 4 in care, pe langa operatiile identice posturilor 1 si 2 se pot realiza asamblari / prelucrari speciale datorita gradului inalt de dexteritate a robotilor articulati vertical existenti (antropomorfici), cat si operatii de prelucrare prin aschiere (frezare de degrosare si finisare, gaurire, marcare) de catre o masina de frezat 3D cu comanda numerica CNC.

Produsele sunt amplasate pe palete introduse in celula de un robot Cartezian din postul 0; paletele cu produse circula de la o statie de lucru curenta la cea unde a fost planificata executia operatiei urmatoare. Toti cei 4 roboti din statiile 1, 2, 3 si 4 pot executa un numar de operatii, iar robotii din statiile 3 si 4 pot executa (identic) operatii suplimentare celor din 1, 2.

Robotul SCARA din postul 5 deserveste 2 magazii inteligente de piese, preluand componente sub control de la camere video, si plasand componentele pe palete speciale cu statut de alimentare (aprovizionare) a depozitelor locale din statiile de lucru.

Cele 5 posturi de lucru si alimentare sunt interconectate printr-un sistem de transport in bucla inchisa, prevazut cu tronsoane de derivatie pentru accesul la posturi (Fig. 3.2). Bucla inchisa a conveiorului este segmentata intr-un numar de tronsoane delimitate prin puncte de derivatie a paletelor catre cele 5 statii; actiunea de derivatie este controlata de automatul programabil master al CFF, in conformitate cu o planificare de produse, secventiere de operatii si alocare de resurse existenta.

Fig. 3.2 Sistemul de transport al paletelor in cadrul CFF; segmentarea in tronsoane pentru acces prin derivatie la statiile de lucru robotizate

Capabilitatile resurselor CFF disponibile pentru conducerea automata a proceselor de lucru sunt redate in continuare.

3.1.1 Robotii SCARA pentru asamblare rapida si realimentare cu componente

Acesti roboti sunt amplasati in statiile de lucru 1, 2 si 5 ale CFF. Robotii din statiile 1, 2 sunt de tip Adept Cobra s600, fiind utilizat în operatii de asamblare mecanica, manipularea materialelor, împachetare materiale, alimentare/descărcare utilaje, înșurubare și alte operații ce necesită automatizare precisă, sigură si timp de executie cat mai scurt.

Caracteristicile tehnice ale robotului Adept Cobra s600 (Fig. 3.3a):

Encodere absolute pentru calibrare ușoară; encodere de rezoluție înaltă pentru urmărirea traiectoriei de înaltă precizie la viteze mici;

Motoare de eficiență înaltă oferă o performanță înaltă cu un cuplu mai mare; drivere cu armonice de inerție redusă ce oferă accelerația maximă;

Senzori de temperatură ce monitorizează motoarele și amplificatoarele, asigurand performanță maximă și fiabilitate;

a) Robot Adept SCARA s600 b) Robot Adept Viper s650

Fig. 3.3 Robotii din posturile 1-4 ale CFF, utilizati pentru operatii de asamblare-montaj si prelucrari mecanice

Rata de actualizare de 8kHz pentru servo-control și urmărirea traiectoriei; Adept SmartController CX (cu software Adept Windows instalat);

Panou frontal cu oprire de urgență (consola operator de proces);

Software NFS (Network File Server); Ethernet TCP/IP;

Performante de lucru in regim dinamic: anvelopa de lucru (cursa maximă cu brațul în extensie) – 600 mm; sarcina de lucru transportabilă: 2 kg (mediu), 5.5 kg (maxim); moment de inerție in articulația 4: 450 kg-cm2; forța de împingere a articulației 4 – 35kgf;

Gripper electro-pneumatic tip paralel;

Robotul SCARA din statia 5, utilizat pentru realimentarea cu componente mecanice a depozitelor locale din statiile 1-4, este de tip Adept Cobra s800, avand anvelopa de lucru de 800 mm.

3.1.2 Robotii articulati vertical pentru conturare si asamblare necesitand dexteritate

Pentru operatii de asamblare/montaj complexe, necesitand inalta dexteritate, se utilizeaza doi roboti articulati vertical de tip Adept Viper s650 cu 6 grade de libertate (articulatie sherica a efectorului terminal), datorita complianței, repetabilității și preciziei superioare de poziționare / urmărire de traiectorii complexe (Fig. 3.3b). Acest tip de braț robot este ideal pentru operații de manipulare și interacțiune cu materiale – în scop de transfer, montaj, împachetare a materialelor, alimentare / descărcare utilaje și alte aplicații care cer o automatizare precisă și rapidă.

Caracteristicile tehnice ale robotului Adept Viper s650 sunt:

Control multitasking cu Adept SmartController CX (cu software Adept Windows instalat); sasiu de putere PA-4 cu servo controllere și amplificatoare;

Panou frontal cu oprire de urgență (consola operator de proces);

Software NFS (Network File Server); Ethernet TCP/IP;

Gripper electro-pneumatic tip paralel;

Braț mecanic robot cu capabilitatile: anvelopa de lucru (cursa maximă cu brațul în extensie) – 653 mm; sarcina de lucru transportabilă: 5kg (max.); domeniile de deplasare (6 articulații de rotație): axa 1: ± 170°; axa 2: -170°, +45°; axa 3: -29°, +256°; axa 4: ±190°; axa 5: ±120°; axa 6: ± 360°; momente de inerție (max.): articulațiile 4,5:0.295 kgm2; articulația 6: 0.045 kgm2; viteza compusă (max.) la vârf: 8200 mm/s; repetabilitate (XYZ): ± 0.020 mm;

Conexiuni utilizator interne: 10 electrice, 1 pneumatic; grad de protecție: IP40;

3.1.3 Robotul Cartezian pentru alimentare cu palete

3 module liniare de înaltă calitate Adept Python si unul de rotatie au fost integrate pentru robotul de alimentare / evacuare a paletelor in CFF. Configuratia rezultanta este redata in Fig. 3.4.

Fig. 3.4 Robotul Cartezian Adept Python pentru alimentarea cu palete

Această configurație folosește un modul tip L18 de lungime 1630mm, un modul L12 de 1055mm, un modul L08 de lungime 850mm și un modul de rotație Theta tip LT1.

Componentele sistemului robot Cartezian utilizat pentru I/E de palete robotului sunt:

Modulele Adept Python L18, L12, L08 și LT1; gripper electro-pneumatic tip paralel;

Adept SmartController CX (cu software Adept Windows instalat);

Kit de expansiune PDU3;

Panou frontal cu Oprire de Urgență (consola operator de proces);

Ethernet TCP/IP;

Spațiul de lucru al acestui robot este un paralelipiped cu dimensiuni 1200x600x400 mm.

3.1.4 Dispozitive de comanda a resurselor – controllerul robot

Oricare dintre robotii inclusi in CFF poate fi programat și condus prin intermediul unui controller multitasking extern de tip „Adept SmartController”, care rulează o platformă de control distribuit al mișcării „Adept SmartServo”.

Controllerul integrează opțiuni de vedere artificială precum și posibilitatea urmăririi evoluției unei eventuale benzi transportoare, aflate în raza de acțiune a robotului. El este prevăzut cu port IEEE 1394 (FireWire) prin care pot fi conectate module de intrări/ ieșiri digitale sau module suplimentare de generare a mișcării. Controllerul mai este prevăzut și cu Fast Ethernet respectiv Device Net, precum și cu un modul sDIO care cuprinde 32 de intrări digitale și 32 ieșiri digitale, toate izolate galvanic, și o interfață IEEE 1394 (Fig. 3.5).

Fig. 3.5 Adept SmartController CX

În Fig.3.6. sunt prezentate conexiunile care trebuie realizate între calculator (terminalul unei resurse robot), controller-ul de timp real al resursei și echipamentul industrial tip robot.

Fig. 3.6 Conexiuni necesare între calculator (terminal robot), controller și robot

3.1.5 Mașini de frezat cu comanda CNC

Statiile de lucru 3 si 4 sunt echipate cu cate o masina de frezat 3D + 1 rotatie (universal) cu comanda numerica CNC EMCO Concept Mill (Fig. 3.7), avand urmatoarele caracteristici tehnice prezentate în Tabelul 3.1.

Fig. 3.7 Resursa de prelucrare prin aschiere – freza 3D + 1rot EMCO Concept Mill 105

Tabel 3.1. – Date tehnice mașină CNC EMCO concept Mill 105

3.1.6 Sistemul de transport al fluxului de palete – conveior si componente

Elementul central al celulei de fabricație CFF, cvare interconecteaza posturile de lucru, este un sistem conveior de tip twin-track (cu doua benzi transportoare ce antreneaza papete, materiale, de tip Bosch Rexroth – TSPlus. El este folosit pentru transportul și transferul paletelor pe care se afla produse aflate in diferite stadii de realizare si componente necesare realizarii produselor (ex. pentru asamblare / montaj). Toate componentele sistemului TSPlus sunt prefabricate și modularizatere, fiind asamblate in platforma CFF conform topologiei de opere de tip job-shop, a amplasarii resurselor, a gabaritului si anvelopelor spatiilor de lucru ale acestotra (cell layout).

3.1.6.1 Dispozitive port-paleta

Componenta fizica care asigura circulatia paletelor de la o statie de lucru la alta in sistemul de transport este port-paleta. Aceasta este folosită pentru transportul paletelor, iar pe palete sunt depozitate piesele asupra cărora se fac prelucrările, produsul fiind astfel contruit succesiv, operatie dupa operatie efectuate pe diverse resurse. Port-paletele de dimensiune 160 x 160 mm (Fig. 3.8) sunt antrenate de cele doua benzi paralele ale conveiorului, aceasta metodă de deplasare având următoarele avantaje:

Fig. 3.8. Port-paleta utilizata in transportul paletelor care circula intre statiile de lucru conform rutarii PLC

Poziționare. Paletele sunt poziționate în dreptul stațiilor de lucru cu o precizie de ± 0.05mm prin utilizarea unităților de poziționare, permițând astfel efectuarea operațiilor de asamblare de mare precizie.

Montare. Paletele sunt prevăzute cu dispozitive de fixare pentru a securiza componentele pentru asamblări manuale sau automate. De asemenea, există posibilitatea ca pe palete să se monteze dispozitive de identificare a lor și de transport al unor date/informații folosite pentru coordonarea secvențelor de asamblare.

Oprire. Port-paletele pot fi oprite pe bandă indiferent de orientarea lor pe conveior. Ele se pot de asemenea acumula în cozi de asteptare și apoi li se poate da drumul una câte una.

Detecția. Senzorii montați pe spatele sau lateralul paletelor funcționează împreună cu conveiorul pentru detecția prezenței paletelor. Orientarea și rutarea paletelor poate fi controlată folosind dispozitivele de identificare Rexroth ID/10 sau ID/80.

3.1.6.2 Conveiorul longitudinal si unitatea de transfer

Rolul conveiorului longitudinal (Fig. 3.9a) este acela de a transporta paletele pe segmente de deplasare liniara, fie in bucla principala, fie de la puncte de oprire ale buclei principale (echipate cu unitati de transfer) catre posturile de lucru, pe tronsoanele de derivatie.

a) Tronson de conveior longitudinal b) Unitate de transfer

Fig. 3.9 Tronson de conveior longitudinal si unitate de transfer (Bosch-Rexroth)

Conveiorul in bucla inchisa cu derivatiile catre posturile de lucru robotizate (posturile 1 si 2), robotizate si dotate cu masini de frezat CNC, respectiv de realimentare cu componente a depozitelor locale ale celor 4 posturi de fabricatie 1-4 rezulta din asamblarea tronsoanelor de conveyor longitudinal si a unitatilor de transfer. Pentru a uni două benzi paralele cu o distanță între ele mai mare de 320mm (calea principala de rulare in bucla inchisa) se utilizeaza doa elemente scurte de conveior transversal (de lungime 20 cm). Toate benzile transportoare pentru conveioare sunt puse în mișcare de același tip de motor. Împreună cu port-paletele, unitățile de transfer din Fig. 3.9b sunt elemente cheie ale sistemului de transport care permit realizarea de derivatii pentru dirijarea paletelor in post.

De-a lungul benzilor conveioare se află opritoare pneumatice care pot opri paletele în diferite puncte, aceste opriri fiind necesare fie pentru procesarea (ptrelucrare, asamblare, verificare) produselor transportate, fie pentru a opri eventualele ciocniri între palete. Ele au doar o comandă de tip boolean: dacă aceasta este “false” opritorul blochează trecerea paletei, dacă este “true” opritorul permite trecerea nestingherită a paletei.

Pentru a se putea face devierea de pe o banda principală pe una secundară de deviere catre un post de lucru se folosesc lifturi pneumatice cu trei stări:

Jos: pentru ca paleta să poată trece fără probleme prin dreptul deviației mai departe in traseul buclei principale;

Mijloc: pentru ca paleta să se oprească pe lift și să se facă alinierea cu banda de deviație (tronson longitudinal de derivatie) pe care ea va intra catre postul de lucru;

Sus: paleta s-a aliniat pentru intrarea pe banda de derivatie spre postul de lucru.

3.2 Implementarea deciziilor MES. Rutarea produselor in CFF cu retea de automate

Programabile (PLC)

3.2.1 Solutia de conducere a fabricatiei. Functia de rutare a produselor cu PLC

Prezentul proiect de conducere automata a rutarii produselor in CFF a beneficiat de dezvoltarea anterioara in cadrul Laboratorului CIMR a unui model reconfigurabil și cu auto-organizare pentru controlul sistemelor de fabricație de tip job-shop cu comutare automată între modul centralizat (planificare și alocare ierarhică – sistem de planificare și alocare, SS (System Scheduler) și modul descentralizat (alocare heterarhică a operațiilor pe resurse, MES distribuit – dMES).

Arhitectura de control utilizează conceptul de inteligență distribuită într-o topologie hibridă de calcul, fiind capabilă să își reconfigureze dinamic structura, componentele și modul de operare ca răspuns la modificările comenzilor clienților, stării resurselor și degradării performanțelor. Sistemul MES dezvoltat permite controlul riscului și al hazardului prin estimarea situațiilor neprevăzute și a tiparelor atipice.

Obiectivele secundare de performanță propuse sunt: (i) nervozitatea sistemului MES, (ii) stabilitatea alocării resurselor, operarea continua, lină a structurii de productie, (iii) eficienta nivelului de planificare mixta centralizata (prin SS), si (iv) flexibilitatea și adaptabilitatea sistemului MES cuplat cu fluxul fizic. Orientarea către servicii este impusă ca un model comportamental pentru estimarea stării curente și performanțelor resurselor, cat și pentru implementarea comunicației în cadrul unui cadru multi-agent de control. Pentru a atinge agilitatea dorită în reingineria CFF, aceasta a fost abstractizata prin consortii de resurse modularizate și reutilizabile ale căror interacțiuni sunt configurate. Aceste consortii au fost modelate ca echipe de resurse de fabricație agentificate, e.g. grupuri agregate de agenți colaborativi al căror comportament este reglementat prin contracte de coaliție. O echipă este configurata initial in functie de specificul lotului de produse comandat, si reconfigurată în mod automat de către un agent broker de resurse de câte ori se produce o perturbație. Agentul broker de resurse instanțiază un Model de Acces la Serviciile Resurselor (RSAM) care operează cu date despre modul de execuție al produselor (operații executate de resurse, costul, calitatea și necesarul de energie).

Sistemul distribuit de executie a fabricatiei dMES (distributed Manufacturing Execution System) a fost proiectat și implementat conform arhitecturii de referință PROSA și se bazeaza pe conceptul de sistem multi-agent delegat pentru atingerea acestui obiectiv. Acesta este compus din trei agenți de bază (produs, resursă și ordin) și va permite interacțiunea colaborativă cu agentul supervizor (de expertiza) care este compus din sistemul SS, modelul RSAM și din modulul de comutare a strategiei de control. Sistemul dMES operează cu agenți mobili de tip WIP (Work In Process) implementați cu dispozitive electronice integrate atașate port-paletelor de pe conveior. Această structură permite automatizarea dirijată de produs a procesului de fabricație.

Modelul de conducere semi-heterarhica cu integrare SS-dMES este un model de interacțiune care permite cooperarea între două subsisteme diferite: (1) un sistem de planificare centralizat (SS), bazat pe o tehnologie selectabilă de planificare și alocare (de exemplu, programare de constrângeri, normele de producție) și (2) un subsistem descentralizat de execuție a fabricației (dMES), bazat pe o arhitectură holonică de referință și pe aplicarea modelului multi-agent delegat. Acest model de interacțiune va fi definit în termeni de:

Evenimentele care declanșează noi cereri de planificare pentru SS, secvențe de comutare bidirecționale între modurile de planificare ierarhice și heterarhice;

Mecanismul de decizie pentru comutarea între modurile de planificare;

Modelul de acces la serviciile unei resurse luând în considerare participarea resursei la funcția de costuri, sarcina cumulată, consumul de energie, promptitudinea și calitatea serviciilor prestate de echipa de lucru din care face parte resursa respectivă.

Modelul de colaborare pentru interacțiunea SS – dMES implică două niveluri de control (calcul, luarea deciziei, urmarirea aplicarii deciziei) (Fig. 3.10):

Fig. 3.10 Modelul semi-heterarhic MES cu interacțiune dinamica SS-dMES

Nivelul MES, in care se realizeaza simultan functiile de : a) planificarea ordinii introducerii spre executie in CFF a produselor din loturile diferite ce au acelasi termen de livrare; b) secventierea tuturor operatiilor tuturor produselor din loturile de la a), considerand restrictiile de precedenta existente (specificate in holonul produs); c) alocarea de resurse tuturor operatiilor secventiate in b) pentru produsele planificate in a) – aceasta se bazeaza pe specificatiile continute in holonii resursa. Rezultatul final al acestor activitati de calcul de optimizare este reprezentat de lista ordonata a holonilor ordin, care contin informatia necesara executiei produselor. Cele trei activitati MES pot fi executate:

Centralizat, in nivelul MES centralizat implementat de un sistem informatic SS centralizat, cu considerarea de criterii de optimalitate (timp minim de executie, incarcare uniforma a resurselor, s.a.);

Descentralizat, in nivelul MES descentralizat implementat de un sistem multi-agent distribuit dMES, cu considerarea criteriilor de agilitate, neintreruptibilitate a productiei, optimalitate locala la nivelul tuturor produselor in executie simultana

Nivelul de comanda a executiei productiei, in care se realizeaza simultan functiile:

Rutarea de catre automatul programabil central al CFF a paletelor cu produse de realizat conform rezultatelor calculului de: a) planificarii produselor, b) secventierii operatiilor si c) alocarii resurselor obtinute in nivelul MES;

Comanda de catre automatul programabil central al CFF de lansare in executie a programelor resurselor pentru realizarea operatiilor asupra produselor;

Comanda de catre automatele programabile locale ale statiilor de lucru a: alimentarii / evacuarii de palete, realimentarii cu componente a magazinelor din posturile de lucru, monitorizarii operatiilor de productie si trasabilitatii produselor.

Nivelul de automatizare 3.2 este proiectat si implementat in cadrul prezentului proiect de disertatie cu o retea de automate programabile, functia critica din punctul de vedere al timpului real fiind cea de rutare a paletelor cu produse in conformitate cu specificatiile cuprinse in holonii ordin – rezultati din calculul MES si cu informatiile schimbate ultimativ (inainte de intratrea paletei in postul de lucrru) cu resursa alocata de MES.

MES execută planificarea bazaă pe un anumit nivel prestabilit de orientare, așa cum este livrat inițial de SS. Executia are loc până când intervine un eveniment perturbator. În acest moment, deoarece planul actual nu mai este posibil să fi efectuat, MES ar trebui să beneficieze de un nou plan de la SS, pentru a continua execuția. Acest proces de comunicare trebuie să fie cât mai rapid posibil, deoarece un timp mare de interacțiune SS-dMES ar putea determina ca noulprogram să nu se mai poată executa pe celula. De aceea, decizia trebuie să fie luată în timp real, și anume colaborarea SS-dMES are un caracter on-line.

Pentru realizarea dMES a fost definita o holarhia ca un sistem de holoni si relatiile dinamice dintre ei, care implementează arhitectura de referință PROSA; holonii pot coopera pentru a atinge scopul global. Celula de fabricație opereaza cu 3 holoni de bază: holon resursă (RH), holon produs (PH), și holonul ordin sau comandă (OH. Holonii ordin sunt creați de sistemul de planificare centralizată (SS) dintr-o listă totală de comenzi de produse generate la nivelul ERP al întreprinderii. SS va fi considerat ca holon supervizor (Fig. 3.2).

Fig. 3.11 Holarhia pentru dezvoltare HMES

Se observa ca toate deciziile privind ordinea si modul de executie a produselor sunt transferate sistemului PLC (automatul programabil central al CFF) care realizeaza efectiv rutele paletelor comandand conveiorul, activeaza resursele (roboti, masini CNC), realimenteaza posturile de lucru, preia rezultatele executiei si inspectiei de calitate a produselor realizand trasabilitatea acestora – a carei informatie asociata o transmite nivelului MES, ierarhic superior.

3.2.2 Arhitectura automatului programabil pentru executia deciziilor MES (rutare

palete) si comunicatie cu resursele

Pentru rutarea paletelor cu produse conform calculului de planificare mixta MES, comanda elementelor mecanice constituente ale sistemului de transport este efectuată de un automat programabil Bosch-Rexroth seria IndraControl L40. Automatul are următoarea configurație de module (Fig. 3.11.), conectate la unitatea sa centrala: 5 module de câte 32 intrări digitale; 1 modul de 8 intrări digitale; 3 module de câte 32 ieșiri digitale.

Fig. 3.12 Configurația automatului central al CFF, IndraControl L40

Automatul IndraControl L40 (PLC) prezintă mai multe interfețe de comunicație. Interfața serială este de tip RS-232 și este izolată din punct de vedere electric de componentele unității centrale (Fig. 3.13a). Este nevoie de asigurarea unei tensiuni minime de 2V intre semnale și masă. La pornirea automatului aceasta este inițializată cu următoarele valori: 9600bauds, fără paritate, 8 biți de date și 1 bit de stop.

a) Interfata seriala a PLC b) Interfata Ethernet a PLC

c) Interfata PROFIBUS a PLC

Fig. 3.13 Interfete de comunicatie cu resursele si unitatile de calcul dMES si SS

Rețeaua ProfiBus (Fig. 3.14) are drept DP Master unitatea centrală IndraControl L40 a cărei adresă este configurată automat la valoarea 1. Drept module slave sunt conectate unitatea centrală de extensie Bosh B-IO M-DP, configurată la valoarea arbitrară 3, și cele două procesoare RFID care comandă 4 capete de citire scriere, ale căror adrese sunt configurate la 12 și 13.

Fig. 3.14 Arhitectura rețelei ProfiBus pentru conectarea PLC cu procesoarele RFID pentru citirea codurilor paletelor rutate pe conveior

Configurarea adreselor Profibus ale modulelor slave se face manual cu ajutorul selectoarelor de adresă corespunzător Fig. 3.15.

Fig. 3.15 Selectoarele de adresa ale modulelor slave

Pentru interconectarea automatului programabil al CFF (PLC Indra Control L40) la controllerele de timp real ale resurselor (controllere robot Adept), la terminalele robot (calculatoare personale tip IBM PC care realizeaza: 1) editarea de programe-resursa, 2) interfata cu utilizatorul pentru configurarea statiei, 3) urmarirea istoricului productiei la statie, 4) implementarea holonilor resursa si 5) replicarea modelului de stare si calitate a serviciilor asigurate de resursa, RSAM) si la Planificatorul Centralizat MES (System Scheduler – SS) s-a adoptat un sistem LAN cu conexiunea la rețeaua Ethernet a carei arhitectura este redata in Fig. 3.16.

Fig. 3.16 Conexiunea EtherNet PC ale posturilor de lucru – Automat Programabil CFF

Adresa TCP/IP a automatului este: 172.16.200.250 iar cea pentru stația IBM PC utilizată ca terminal de resursa (ex. robot) la programare și vizualizare este 172.16.200.251. Subnet Mask-ul în ambele cazuri este 255.255.0.0.

3.2.3 Sistemul RFID RD si RD/WR de identificare a paletelor pe conveiorul CFF

Sistemul de identificare a paletelor in CFF folosit este de tip BALLUFF BIS-C 600. El este format dintr-un procesor, capete de citire/scriere și pastilă-memorie RFID asupra căreia se realizeaza aceste operații de scriere/citire.

Procesorul BIS C-602-019-650-03-KL2 (Fig. 3.17a) este conectat cu automatul programabil prin intermediul interfeței ProfiBus iar legătura cu capetele de citire/scriere se realizează prin cablurile speciale oferite de producător.

Configurarea inițială a acestui procesor presupune înlăturarea capacului de protecție a cutiei procesorului și de a fixa cu ajutorul celor 8 contacte interne adresa pe magistrala ProfiBus a modului de scriere/citire, precum și încărcarea fișierului de tip gsd în automat. Această configurare este necesară o singură dată la instalarea modulului.

Capetele de citire/scriere folosite sunt de tipul BIS C 323/10-S4 (Fig. 3.17b).

a) Procesorul BIS C -602-019-650-03-KL2 b) Cap de Citire/Scriere BIS C 323/10-S4

Fig. 3.17 Sistemul de identificare RFID a paletelor (identificare facuta de PLC central)

Memoriile Balluf pe care se face scrierea, tipBIS C-130-05/L (Fig. 3.18), au datele tehnice specificate in Tabelul 3.2.

Fig. 3.18 Pastila de memorie BIS C-130-05/L

Tabel 3.2 Date tehnice ale BIS C -130 – 05/L

Senzorii de citire sunt de tipul BIS C – 60R -001-08P-PU-10 și oferă pe 8 linii digitale datele și pe 1 linie digitală validitatea acelor date (Fig. 3.19) ceea ce conduce la existența a maxim 256 de coduri valide de identificare RFID.

Fig. 3.19 Senzor de citire BIS C-60R-001-08P-PU-10

Liniile D1-D7 oferă codul de identificare în mod binar de pe pastila de memorie, iar linia DATA VALID indică când anume datele de pe firele D1-D7 sunt valide.

Înscrierea codului paletei corespunzător Holonilor de Comandă (OH) și de alimentare (SH) se face după următorul principiu: deși memoria folosită în sistemul de identificare permite scrierea și citirea a 1023 de octeți, senzorii de citire de tipul BIS C-60R-001-08P-PU-10 nu pot oferi decât o informație cuprinsă într-un singur octet. Pentru a evita identificarea greșită sau erorile de scriere se folosesc primii trei octeți de pe paletă (Fig. 3.20), primul dintre cei trei fiind efectiv codul de indentificare iar următorii doi fiind complementul binar față de 1.

Fig. 3.20 Primii trei octeți de pe pastila de memorie

3.3 Interfata PLC cu sistemul de control al magazinului ASRS pentru palete

Introducerea paletelor în CFF precum și preluarea și stocarea acestora după ce produsele au au fost realizate si amplasate pe ele se realizeaza automat, sub comanda automatului programabil central al celulei (PLC) cu ajutorul robotului Cartezian Adept Python in statia de lucru 5 (Fig. 3.21).

Fig. 3.21 Configuratia postului de alimentare a CFF cu palete (magazin ASRS prismatic, robot Cartezian)

Datorită aplicației specifice de alimentare / evacuare de palete, a fost proiectat un magazin prismatic de tip ASRS pentru stocarea paletelor goale (ce urmeaza sa fie introduse in CFF) respectiv evacuarea acelora pe care a fost amplasat la finalul executiei produsul finit. In acest post de lucru se realizeaza si inspectia de calitate a produsului final, cu 2 camere video fixe, amplasate dupa directii normale una la alta. Magazinul ASRS conține patru sertare mobile, acționate de patru pistoane pneumatice, pe fiecare dintre aceste sertare putându-se poziționa fie patru palete cu produs fie palete goale, pe care se va construi progresiv produsul. Aceste palete sunt pe rând introduse în spațiul de lucru al robotului pentru a putea fi preluate sau stocate în funcție de necesitate. S-a apelat la această soluție constructivă întru-cât, anvelopa de lucru a robotului Cartezian este mult mai mică decât volumul total ocupat de produse (vezi Fig. 3.22).

Fig. 3.22 Relatia dintre spațiul de lucru al robotului Cartezian si sertarele magazinului ASRS

Pentru a putea controla dispozitivele mecanice ale magaziei, s-a utilizat un dispozitiv tip microcontroller. Acesta poate comunica direct cu controllerul robotului Cartezian (si prin el cu PLC al CFF) prin intermediul interfeței seriale și prin aceasta preia comenzi în privința sertarului pe care robotul vrea să îl acceseze pentru a poziționa produsul.

Gestiunea ASRS (translari de sertare, opriri) pentru asigurarea accesului robotului Cartzian Adept Python la palete a fost realizata cu un microcontroller (Fig. 3.23).

Fig. 3.23Structura duala de gestiune a magazinului ASRS: Controller robot – microcontroller specializat

Microcontrollerul specializat are drept intrări digitale informațiile oferite de senzorii de poziționare a sertarelor, precum și de butoanele de comandă manuală de pe interfata cu operatorul pentru a da posibilitatea acestuia să acceseze paletele. Ieșirile digitale ale acestui microcontroller sunt conectate la un display alfanumeric pentru a informa utilizatorul asupra stărilor în care se află magazia și comenzile electrovalvelor de comandă ale celor patru pistoane.Senzorii și electrovalvele utilizate sunt identice cu cele care întră în componența sistemului de transport și care au fost prezentate anterior.

Schema electronica proiectata pentru acest microcontroller este redata in Fig. 3.24.

Fig. 3.24 Schema electronica a microcontrollerului ASRS realizata cu procesor ATMEGA

In Fig. 3.25 este prezentata placa electronică al carui circuit implementeaza schema electronica a micontrollerului proiectat, reprezentata in Fig. 3.24.

Fig. 3.27 – Placa electronică realizata pentru microcontrollerul ASRS cu microprocesor ATMEGA

Cap. 4 Sistemul de programe pentru automatizarea executiei produselor

planificata in MES. Regimuri de operare normala ale PLC

4.1 Regimuri PLC standard de control al resurselor CFF pentru rutarea si executia

produselor conform deciziilor MES

Sistemul PLC in retea (PLC central si PLC locale ale statiilor de lucru) are trei regimuri de funcționare: manual, diagnoză și automat.

Regimul manual da posibilitatea operatorul uman de a porni individual elementele constituente ale sistemului de transport, pentru a putea face verificări de rutină asupra functionalitatii acestora sau a aduce sistemul de transport într-o anumită stare dorită.

Regimul de diagnoză permite deplasarea unei palete între oricare dintre posturile de lucru, si oprirea acesteia în anumite puncte cheie ale sistemului de transport astfel încât operatorul să nu fie nevoit să realizeze succesiunea de operații complicate asupra elementelor mecanice. Acest regim oferă drept rezultat, atât deplasarea paletei între punctele dorite precum și diagnoza a stării de funcționare a întregului sistem prin mesaje de confirmare a efectuării operațiilor sau de eroare.

Regimul automat este regimul normal de funcționare pentru executia loturilor de produse planificate, cu operatii secventiate si resurse alocate conform unor criterii tehnico-econmomice optimizate prin calcul pe nivelul MES . Acest regim presupune ca sistemul de transport să interacționeze cu celelalte componente ale celulei de fabricație si să efectueze operațiile necesare deplasării paletelor-produs între posturile de lucru. De asemenea el trebuie să intermedieze comunicația între planificatorul global și celulă, în cazul unui defect să anunțe acest lucru și operatorului uman iar în cazul epuizării unuia din stocurile de piese al roboților de a declansa realimentarea cu piese a robotului respectiv. Toate aceste functii de:

Rutare palete conform deciziilor MES (indiferent de variantele: centralizata – SS sau descentralizata – dMES);

Gestiune procese de introducere / evacuare de palete in CFF;

Gestiune procese de executie a holonilor de alimentare, creati in timp real la epuizarea stocului de componente materiale in depozitul unei statii de lucru;

Colectare informatii despre trasabilitatea produselor si comunicarea acestor date catre nivelul superior MES

sunt realizate de automatul programabil central al celulei (PLC).

4.1.1 Regimul de comanda manuala

Când automatul programabil se află în regimul manual, el trebuie să permită operatorului uman să comande individual oricare din elementele de acționare ale sistemului de transport, pentru a putea face verificări de rutină sau a aduce sistemul într-o anumită stare dorită. În celelalte regimuri de control ale automatului accesul la resursele conveiorului este limitat, putând fi activate doar benzile principale. Stările senzorilor elementelor constituente ale sistemului de transport pot fi cu ușurință monitorizate pentru a confirma: pornirea/oprirea utilajelor, ridicarea/coborârea mecanismelor de transfer al paletei de pe o bandă conveioare pe alta, pozițiile paletelor în dreptul elementelor cheie implicate și pozițiile lifturilor (sus / jos / la mijloc).

Comutarea în regimul manual se realizează după pornirea mediului de programare IndraLogic, iar realizarea conexiunii cu automatul prin apăsarea butonului de “Login”, fie prin apăsarea butonului “Manual” într-un alt ecran de vizualizare, fie prin alegerea vizualizării cu numele “ModManual” ca în Fig. 4.1.

Fig. 4.1 Alegerea Modului manual din lista de vizualizări a interfetei cu utilizatorul

Comenzile elementelor de acționare a sistemului de transport pot fi împărțite în trei categorii:

comanda motoarelor electrice;

comanda opritoarelor mecanice;

comanda lifturilor pneumatice.

Comanda unui motor cu două sensuri de rotație a fost implementată cu ajutorul a două butoane de comandă, câte unul pentru fiecare din cele două sensuri, care realizează activarea ieșirilor digitale corespunzătoare (Fig. 4.2).

Fig. 4.2 Comanda unui motor cu două sensuri de rotație al benzii conveiorului

Deoarece schimbarea de sens a unui motor se face prin inversarea celor trei faze de comandă (motoarele sunt trifazate), activarea simultană a celor două sensuri duce la scurtcircuit respectiv la activarea siguranței termice corespunzatoare motorului respectiv. Fiind o situație anormală, butoanele sunt interblocate astfel încât, dacă unul este activ, celălalt nu poate fi apăsat. Din punct de vedere grafic s-a ales includerea pe lângă litera “M” și a unei săgeți care să indice sensul pe care butonul de comandă al motorului îl va activa (vezi Fig. 4.2).

Comanda opritoarelor mecanice presupune activarea unei ieșiri digitale care la rândul ei activează o electrovalvă pneumatică. Astfel aerul din circuitul pneumatic intră în opritor, făcând acest element să coboare și să lase paleta să treacă mai departe pe banda conveiorului. Pentru a ridica opritorul trebuie doar dezactivată ieșirea digitală care comandă electrovalva și aerul va părăsi opritorul acesta ridicându-se și oprind eventualele palete care circulă pe banda conveioare.

În Fig. 4.3 sunt reprezentate mai multe opritoare și martorii corespunzătoare lor. Butoanele de comandă au fost implementate cu simbolul de comandă “o” iar martorii lor își schimbă culoarea în funcție de opritor (roșu dacă opritorul este inactiv și verde dacă acesta a coborât lăsând paleta liberă).

Fig. 4.3 Butoane de comanda a opritorului in regim PLC manual

Comanda lifturilor cu trei poziții amplasate in punctele de derivatie a buclei principale a conveiorului este asemănătoare cu cea a motoarelor cu două sensuri de rotație (Fig. 4.4).

Fig. 4.4 Comanda unui lift cu trei poziții in puncte de derivatie pe conveior

Au fost realizate două comenzi digitale care pot activa două electrovalve pneumatice. Deși activarea simultană a două butoane nu produce scurtcircuit ca în cazul motorului cu dublu sens, a fost implementat același mecanism de interblocare pentru a evita crearea unor tensiuni în circuitul de aer comprimat. Dacă nu e activă nici o comandă, liftul rămâne în poziția din mijloc. Simbolurile alese pentru butoane sunt “^” pentru comanda de ridicare a liftului iar “v” pentru coborârea acestuia.

În modul manual este util să se știe dacă paleta a ajuns în locațiile dorite și de aceea au fost configurate și elemente grafice care reprezinta pozițile acestora (Fig. 4.5).

Fig. 4.5 Instanță a poziților paletelor în sistem

În Fig. 4.5 este surprinsă o instanță cu trei palete care așteaptă în poziții cheie. Două dintre acestea se află în dreptul senzorilor de citire a codurilor RFID și acestea sunt afișate deasemenea. Dacă senzorii inductivi sunt inactivi, în dreptul poziției cheie nu se află nici un element grafic.

4.1.2 Regimul de diagnoză

În regimul de diagnoză sunt testate elementele mecanice ale sistemului de transport in vederea detectarii rapide a posibilelor defecte de funcționare. Pentru a putea deplasa o paletă prin sistemul de transport trebuie efectuată o succesiune de operații bine determinate, iar în funcție de destinația finală dorită a acesteia, această succesiune este diferită. Regimul de diagnoză a fost implementat pentru a permite fixarea destinațiilor paletei, aceasta putând fi oricare din pozițiile unde o paletă poate fi oprită (in puncte prevazute cu unitate de transfer (vezi Cap. 2), iar apoi pe parcursul traseului operatorul uman este informat printr-un mesaj text asupra pozițiilor intermediare prin care paleta trece.

În cazul în care paleta nu ajunge la destinație după un anumit timp sau nu face tranziția printr-o poziție intermediară suficient de repede, operatorul uman este informat asupra posibilității defectării sistemului.

Comutarea în regimul de diagnoză se realizează după pornirea mediului de programare IndraLogic, fie prin apasarea butonului “Diagnoza” într-un alt ecran de vizualizare, fie prin alegerea vizualizării cu numele “ModDiagnoză”. Interfața prin care se poate face diagnoza este prezentata in Fig. 4.6.

Procedura care a fost implementată pentru verificarea rutării paletelor dintr-un punct al conveiorului principal in bucla inchisa în alt punct este următoarea:

se pornesc motoarele benzilor principale;

se introduce destinația dorită în chenarul “Noua destinație” sub formă numerică

se validează destinația;

se așteaptă ca paleta să ajungă în poziția dorită.

Fig. 4.6 Interfața utilizator pentru modul de diagnoză

Destinațiile se introduc sub forma unor numere, acestea fiind așezate în dreptul fiecărei poziție unde paleta ar putea fi oprită. În exemplul dat se observă că a fost introdusă destinația “4” care corespunde poziției de mijloc pe liftul ce face devierea catre robotul 1.

Fig. 4.7 Eroare în mod diagnoză

Odată ce paleta a atins destinația operatorul este informat printr-un mesaj text, iar un buton de confirmare a citirii mesajului va apărea pe ecran. De fiecare dată când paleta parcurge o zonă de conveior și trece prin dreptul unei poziții operatorul uman este informat prin mesaj text. În cazul în care paleta nu parcurge un segment operatorul este informat ca in situatiile evidentiate in Fig. 4.6 si Fig. 4.7.

4.1.3 Regimul automat pentru executia produselor

Regimul automat este regimul normal de funcționare al automatului programabil, in care acesta realizeaza actiunile care permit executia, operatie cu operatie, a produselor planificate de holonul expertiza (in SS) sau de sistemul multi-agent activat de holonii ordin (dMES), de catre resursele asignate in MES. Ca și funcționalitate, PLCel trebuie să asigure primirea datelor de la planificatorul global / descentralizat, să transpună aceste date în mișcări ale elementelor de execuție rutand astfel produsele și în plus să detecteze stările de anormalitate ale sistemului. Pentru a putea realiza toate aceste trebuiesc rezolvate anumite probleme ce vor fi expuse în sectiunile ce urmează.

4.2 Solutia de control in timp real cu automat programabil a celulei de fabricație

4.2.1 Problematica rutării paletelor de catre PLC conform deciziei mixte MES de

planificare produse, secventiere operatii si alocare resurse

Problema de control al sistemului de transport pentru rutarea produselor din pachetul de produse aflate in execuție simultană presupune preluarea datelor de la planificatorul global (ce ruleaza pe un server de tip IBM xSeries 3500) sau de la sistemul distribuit multi-agent (dMES, ce ruleaza programe de negociere a alocarii resurselor prin holonii ordin asociati produselor) și transpunerea lor în comenzi de rutare: avans / oprire banda, actionare lift, etc., pentru elementele de acționare a conveiorului.

Primul pas de proiectare a constat în alegerea formei sub care se vor reține datele de la planificator. Produsul de pe oricare paleta in circulatie in CFF suferă mai multe operații, fiecare dintre acestea necesitând și o serie de informații suplimentare: postul la care operația se execută, durata operației, etc. Analizând natura si volumul de informație necesar, a fost definita o structura standard de date care sa permita executia holonului ordin asociat oricarui de forma:

TYPE datemasina :

STRUCT

post: BYTE; (*postul de lucru al robotului codificat numeric*)

operatie: BYTE; (*operația care va fi efectuata asupra piesei codificata numeric*)

timpmin: WORD; (*timpul minim pe care îl ia operația la postul robotului*)

timpmax: WORD;(*timpul maxim pe care îl ia operația*)

raport: BYTE; (*un raport succint ce specifica succes, failed etc.. *)

END_STRUCT

END_TYPE

Aceasta structură este repetată pentru fiecare operație pe care produsul trebuie să o suporte pentru a fi finalizat iar memorarea acestora se face într-o matrice numită “sir_palete”. Ea cuprinde 256 de câmpuri, în care se rețin 16 structuri de tipul datamasina, structura fiind de tipul unei matrici cu 256 de linii a câte 16 coloane, fiecare element din matrice fiind la rândul său format din cele 5 elemente constituente ale structurii “datamasina”.

Pentru a avea acces la un element anume al acestei structuri trebuie să se precizeze cele două coordonate (coloana și linia) ale structurii de tipul datamasina dorite precum și câmpul dorit din structura respectivă. Linia este dată de numărul/ordinul paletei asupra căreia urmează să se execute operațiile iar coloana este indexul operației. Pentru a ușura accesul la acești indecși (256) se memorează valorile într-un vector denumit “sir_index” cu 256 de poziții corespunzătoare fiecărei palete/ordin (vezi exemplul din tabelul 4.1), valoarea regăsită aici indicând la a câta operație se află paleta.

Tabel 4.1 Structura vectorului sir_index

Folosind această structură automatul programabil central al celulei (PLC) are toate datele necesare pentru a putea ruta prin comenzi de acțiuni mecanice o paletă-produs în sistem, conform planificarii, secventierii si alocarii mixte efectuate pe nivelul MES (centralizat, off line, de catre SS sau descentralizat, in timp real in dMES efectuata de holonii ordin).

Fig. 4.8 Sistemul de identificare a paletelor utilizand senzori RFID READ si dirijarea acestora ctre post

S-a decis ca sistemul de transport să fie împartit în segmente, fiecare din ele fiind gestionat de un program propriu care, ținând cont și de starea elementelor din tronsoanele de conveior vecine, emite comenzile necesare pentru transportul paletei cu produs în afara propriei arii de acțiune, unde va fi preluata de programul segmentului următor. Astfel, produsul poate urmări traseul de pe benzile conveioare principale făcând fie: 1) o buclă completa, sau 2) putand fi deviat către oricare din cele patru posturi de lucru (circuland pe tronsonul secundar, de derivatie catre post), către postul de alimentare cu piese, sau 3) fiind dirijat către ieșirea din sistem unde produsul de pe paleta este supus unui proces de inspectie de calitate (geometrie, starea suprafetelor, pozitia relativa intre compmoente montate, etc). In cele cinci puncte de pe bucla conveiorului principal unde sunt posibile devieri există senzori ce pot identifica codul înscris pe pastila magnetică și în funcție de destinația următoare traseul paletei va fi sau nu deviat către un post robot sau ieșire (Fig. 4.8).

Odată ce paleta cu produs a ajuns în dreptul senzorilor, cel inductiv este activat iar cel de identificare începe citirea automată a identificatorului paletei. Imediat ce codul unic de identificare a fost citit, el este depus la ieșirea paralelă a senzorului, automatul putându-l citi pe liniile de intrare respective (senzorii de identificare sunt conectați direct prin linii de intrare ieșire digitală).

Imediat după citirea codului de identificare, automatul programabil verifică pe baza lui și a structurii de date ce conține ordinele de producție, care este urmatorul post la care paleta trebuie să ajungă. Dacă acesta nu corespunde postului de lucru unde se poate face devierea, paleta este lasată să treacă mai departe către următoarea poziție unde ar putea fi deviată (ramâne în circuit până când întâlnește locația următoarei operații). Dacă totuși paleta trebuie să efectueze o operație la acest post de lucru, atunci automatul programabil initiaza interogarea prin interfața Ethernet a resursei postului (controller-ul robotului) pentru a afla dacă acesta din urma poate accepta jobul respectiv. Odată primit acceptul jobului, paleta este deviată și adusă în poziția de lucru, iar acest eveniment este semnalizat robotului prin liniile de I/E digitale pentru a se putea începe execuția operației.

În exemplul ce urmează (Tabel 4.2) o paletă se află pe banda principala în drum către macazul corespunzător robotului 2 (Adept Cobra s600), iar codul înscris pe pastila magnetică este cel cu numărul 10. În momentul în care paleta se afla în dreptul senzorului de citire din fața acestui macaz, codul ei este citit într-o variabilă numită Cod_paleta_r2, făcându-se verificarea dacă următorul post la care paleta trebuie să treacă este cel al robotului 2 prin accesarea structurii sir_paleta figurată în tabelul 4.2, și a vectorului sir_index figurat în tabelul 4.1:

Tabel 4.2 Structura de date pentru ordinul 10.

Pentru a cunoaste postul la care paleta trebuie să intre se apelează structura sub forma

sir_palete[code_paleta_r2 ,sir_index[code_paleta_r2]].post, care în acest caz devine:

sir_palete[10,sir_index[10]].post și înlocuind cu valoarea găsita în tabel:

sir_palete[10,2].post adică ceea ce se găsește în câmpul “post” din “Structura2”.

Se observă în exemplul dat postul următor este cel al robotului 2 și de aceea are loc devierea paletei; după ce asupra ei se efectuează operația cu codul 0 (montare ax_1), indexul corespunzător operației din sir_index poziția 10 va fi incrementat devenind 3, urmând ca la o interogare ulterioară sistemul să citească in mod similat cazului descris datele din “Structura3” a tabelului 4.2.

4.2.2 Date schimbate de către automatul programabil cu planificatorul celulei (SS)

Structura de date ce este memorată în automatul programabil presupune transferul a 256 (linii) x 16 (coloane) x 5 (elemente din structura) = 20480 de itemi în structura fișierului de simboluri, ceea ce ar depăși posibilitățile oferite de OPC Server. Din acest motiv s-a hotărât transmisia succesivă a datelor folosind o structură de variabile mai mică, și alegerea logică a fost transmisia simultană a 16 structuri de câte 5 elemente plus alte două elemente de date necesare gestionării acestei structuri, in formatul:

post1: BYTE;

operatie1: BYTE;

timpmin1: WORD;

timpmax1: WORD;

raport1: BYTE;

post2: BYTE;

operatie2: BYTE;

timpmin3: WORD;

timpmax3: WORD;

raport3: BYTE;

…………..

…………..

post16: BYTE;

operatie16: BYTE;

timpmin16: WORD;

timpmax16: WORD;

raport16: BYTE;

Pentru a memora aceste variabile în automatul programabil, planificatorul SS (System Scheduler) scrie în prealabil valoarea holonului de comandă OH (a ordinului) a cărei serie de operații se dorește a fi memorată, în item-ul denumit “order” iar apoi dă comanda de scriere prin setarea item-ului boolean “writeOPC”; în urma repetării operațiilor de 256 de ori se poate transfera întreaga structură din memoria automatului relativ rapid (cu aproximație 30 de secunde).

Odată cu aceste date se transmite în plus un șir de caractere numit “time_insertion” în care este trecut momentul de timp la care ar trebui să fie introdusă în sistem paleta-produs, un indicator boolean care semnalizează dacă paleta mai poate fi produsă numit “failed” și un alt șir de caractere numit “product_name” în care se regăsește denumirea produsului.

Pentru “feedback” se folosesc următoarele variabile

index_pal_1: BYTE; (*indexul/ordinul primei palete din sistem*)

index_pal_2: BYTE;

index_pal_3: BYTE;

index_pal_4: BYTE;

index_pal_5: BYTE;

location_pal_1: BYTE; (*localizarea paletelor*)

location_pal_2: BYTE;

location_pal_3: BYTE;

location_pal_4: BYTE;

location_pal_5: BYTE;

Perechea de variabile index_pal și location_pal arată unde se află fiecare ordin din sistem. Variabilele de stare ale fiecărui robot sunt:

robot1_status:BYTE; (*statusul robotului 1*)

robot2_status:BYTE; (*statusul robotului 2*)

robot3_status:BYTE; (*statusul robotului 3*)

robot4_status:BYTE; (*statusul robotului 4*)

robot5_status:BYTE; (*statusul robotului 5*)

4.2.3 Inițializarea sistemului pentru lansarea in executie a unui lot de produse

Inițial resursele de fabricație nu sunt active in celula și de aceea stocurile de componente din depozitele statiilor de lucru (locale) sunt zero. Pentru a putea începe o producție, depozitelele locale ale statiilor de lucru cu resurse de tip robot sau masina CNC trebuie alimentate cu piese / componente de asamblare; operatia de alimentare trebuie realizată anterior operațiilor de producție efective.

Soluția aleasă pentru această problemă a fost aceea de a implementa patru holoni de alimentare (Supply Holon – SH) a căror structură este asemănătoare cu cea a holonilor de tip produs /ordin dar care sunt introduși în sistem (prin paletele lor goale, decatre robotul Cartezian) inaintea inceperii procesului de producție.

Pentru a ușura implementarea a fost luată decizia de a utiliza structura definită mai sus prin particularizarea ei pentru a face operații de încărcare cu piese de la robotul de alimentare (robotul SCARA Adept Cobra s800), și după transportul acestor 4 palete cu componente la roboții din posturile de lucru 1-4 operatiile de descarcare si umplere a depozitelor locale ale statiilor sunt efectuate chiar de robotii statiilor de lucru (Adept Cobra s600 pentru depozitele din statiile 1-2 si Adept Viper s650 pentru depozitele statiilor 3-4).

Aceste operații au fost codificate unic în funcție de cantitățile maxime ale stocurilor de piese pentru roboți. Pentru acest caz particular s-a adoptat următoarea formulă de codificare:

cod_operație_alimentare = cod_offset + număr_de piese

unde cod_offset este o variabilă care face diferențierea între tipurile de piese utilizate la care se adaugă numărul de piese manipulate la transfer.

Valorile variabilei cod_offset pentru piesele cu care se fac testari (componente de tip: „ax”, „T”, „I”, „L”, „non-L” si „r” sunt următoarele:

100 pentru piesele de tip ax;

130 pentru piesele de tip „T”;

150 pentru piesele de tip „I”;

170 pentru piesele de tip „L”;

190 pentru piesele de tip „non-L”;

210 pentru piesele de tip „r”.

Pentru a putea face mai ușor distincția între holonii asociati executiei produselor (holoni ordin) și cei de alimentare (holoni de alimentare) s-au rezervat pentru cei din urmă codurile unice de identificare RFID de la 251 la 254 ceea ce a condus la o limitare a producției unui lot de fabricatie la maxim 250 de produse.

Structura unui holon de alimentare este exemplificată în tabelul 4.3 și reflecta un dualism între operații de încărcare cu piese de la robotul de alimentare (din postul 5) și operații de descărcare de catre roboții din statiile de lucru (1-4).

Tabelul 4.3 Structura unui holon de alimentare (SH):

Se poate observa din acest tabel că holonul de alimentare, codificat cu 251, efectuează patru operații și apoi părăsește sistemul. Prima operație este cea de încărcare de la postul robotului de alimentare cu 24 de axuri (cod_operație = cod_offset + număr piese = 100+24). Următoarea operație presupune descărcarea acestor piese la postul robot 1 unde va face o cerere de transfer a acestor piese în stocul robotului respectiv. După ce a fost retransportat la postul de alimentare prin operația corespunzătoare structurii 3 va face o altă cerere de încărcare cu 24 de axuri pentru ca apoi după transportul la postul robot 2 să efectueze cererea de descărcare. Ultima operație reprezintă transportul la punctul de ieșire din sistem respectiv evacuarea acestui holon din celula de fabricație.

O altă observație importantă este aceea că cererile de transfer din stocurile robotului de alimentare și cele de descărcare a port-paletei corespunzătoare holonului de alimentare trebuie să aibă aceeași codificare.

Alocarea operațiilor de alimentare și planificarea holonilor specifici acestora se realizează în mod dinamic la începutul producției de către planificator în funcție de operațiile definite de către utilizator.

Odată efectuate operațiile de alimentare cu piese ale roboților din statiile de lucru 1-4, holonii de alimentare își termină ciclul de viață și sunt eliminați din sistem prin transportarea acestora la ieșire și efectuarea de cereri de preluare de către robotul Cartezian din postul 0. Excepție va face holonul de alimentare cu codul 250 care va fi transportat in postul de lucru (nr. 5) al robotului de alimentare unde va staționa, și în timpul producției va fi reutilizat pentru implementarea holonului specific de realimentare atunci cand oricare dintre depozitele locale isi epuizeaza stocul de componente.

4.2.4 Protocolul de comunicație între resursa de transport (conveior) și resursele de prelucrare / asamblare produse (robot)

Automatul programabil este conectat la controllerele resurselor (ex. controllere robot) prin intermediul a două tipuri de interfețe, prima fiind interfața standard Ethernet (Fig. 4.9).

Fig. 4.9 Conexiunea PLC – Controller Robot prin interfața Ethernet

Automatul programabil al CFF este conectat la un switch Ethernet în care sunt legate de asemenea și controllerele robot, putându-se astfel face o transmisie de date facilă între cele două tipuri de echipamente.

Cel de al doilea tip de interfață de comunicație este prin linii digitale de intrare/ieșire.

În conformitate cu datele înscrise în fișierul standard al automatului programabil (în urma planificării ordinii de introducere în celulă a produselor și a alocării resurselor celulei pentru fiecare operație asupra produsului), orice paletă, odată ajunsă pe conveior în amplasamentul de derivație către resursa curent alocată, așteaptă realizarea unei secvențe ultime de comunicație între automat și controllerul resursei (PLC – SmartController robot), Fig. 4.10.

Fig. 4.10 Protocol de comunicație Automat Programabil – Controller Robot

Dacă în urma acestei secvențe resursa confirmă încă (de la planificare in MES si pana la intrarea produsului in postul respectiv a decurs un interval de timp semnificativ) disponibilitatea efectuării operației planificate, atunci automatul programabil va emite efectiv comanda de rutare a paletei cu produs în postul de lucru al resursei. Secvența de comunicație PLC – Controller Resursa este redata în Fig. 4.10 si in Fig. 4.11.

Liniile de semnal au semnificația următoare:

READY – semnalul prin care robotul indică starea de liber sau ocupat;

RQST-JOB – semnalul prin care AP face o cerere pentru ocuparea unui robot;

TCP Robot – linia de transmisie de la robot la PLC – D2 reprezintă acceptul sau refuzul pentru job;

TCP PLC – linia de transmisie de la PLC la robot – D1 reprezintă detaliile legate de job-ul dorit;

Pal în Pos – semnalul către robot care indica prezenta paletei în poziția de lucru a robotului;

Job Done – semnalul care indică terminarea jobului iar D3 reprezintă caracterizarea detaliilor legate de terminarea jobului (succes, fail, etc.);

T1 – timpul de decizie (interogare stocuri, etc.) asupra acceptării jobului;

T2 – timpul necesar sistemului de transport pentru a aduce paleta în poziție;

T3 – timpul necesar efectuării job-ului.

Fig. 4.11 Linii de comunicatie (date, comenzi) intre PLC si controller robot

Automatul programabil citește linia de ready a robotului și detectează dacă acesta este ocupat sau nu. In funcție de răspuns face cererea prin linia de request_job, trimițând codul operației pe TCP/IP la controllerul robotului (Fig. 4.11). Dacă acesta acceptă jobul atunci automatul programabil comandă acțiunile mecanice necesare aducerii paletei în poziție (ex. comandă lift) și se dă semnalul către robot de Pal în Pos (pallet în position). Robotul ridică linia de ready pentru a semnaliza începerea jobului și faptul că a devenit ocupat. Când jobul este încheiat robotul ridică linia de job_done și apoi dă un mic raport despre cum s-a încheiat operația pe TCP.

4.2.5 Protocolul de comunicatie PLC-Controller Robot Cartezian pentru introducerea

/ evacuarea paletelor în sistem

Comunicatia între PLC și controllerul Robotului Cartezian este reprezentata in Fig. 4.12.

Fig. 4.12 Protocolul de comunicație intre PLC – Controllerul Robotului Cartezian

Atât introducerea cât și evacuarea paletelor din sistem trebuie să fie comandate de către automatul programabil conform protocolului din Fig. 4.12, deoarece el face operația de urmărire a paletelor prin sistem și cunoaște cu exactitate pozițiile acestora. Pentru comunicare între cele două dispozitive se folosesc în exclusivitate liniile de intrare/ieșire digitale. Automatul programabil utilizează: două linii de ieșire digitale denumite „Place_Pal” pentru operația de introducere a paletelor în sistem și „Remove_Pal” pentru operația de evacuare a unei palete în sistem care împreună implementează cererea de operație, și două linii de intrare „Pal_placed” pentru încheierea operației de introducere a unei palete la intrarea în sistem și „Pal_removed” prin care robotul semnalizează terminarea operației de evacuare a unei palete din sistem implementându-se astfel „O.I.” din protocolul descris anterior.

Odată ce automatul programabil a făcut o cerere de operație, robotul trebuie să o accepte imediat ce a terminat efectuarea operației anterioare. Dacă automatul face ambele cereri simultan prioritară este introducerea de palete în sistem pentru a evita întârzierile în producție. După acceptarea cererii venite fie prin intrarea digitală denumită „Place_request” fie prin cea „Remove_request”, robotul efectuează acțiunile mecanice specifice de preluare a paletelor din magazie și plasarea lor pe conveiorul principal sau inversul acestora. Odată încheiate acțiunile mecanice, automatul este înștiințat prin activarea ieșirii digitale corespunzătoare a robotului „Place_done” sau „Remove_done”. După ce a primit înștiințarea automatul programabil așteaptă o nouă paletă sa ajungă în locația de evacuare și introducerea unei palete în sistem pentru a relua ciclul.

4.2.6 Protocolul de comunicatie controllerul robotului Cartezian si microcontrollerul

depozitului ASRS de palete

Inițial microcontroller-ul magaziei de palete verifică starea elementelor mecanice ASRS prin acționarea lor pe rând pentru a verifica dacă sertarele se deschid și dacă senzorii de pozițione sunt funcționali. Odată ce a fost descoperit un defect, microcontroller-ul afișează pe displayul utilizatorului mesajul de eroare precum și o notificare prin intermediul interfeței seriale pentru robotul Cartezian. Dacă inițializarea a decurs normal, se așteaptă mesajele de comandă fie de la robotul Cartezian dacă este selectat modul automat, fie de la operatorul uman dacă este selectat cel manual.

Robotul Cartezian este cel care gestionează locația paletelor produs în magazia ASRS prin intermediul protocolului din Fig. 4.13 implementat prin intermediul interfeței seriale.

Fig. 4.13 Protocolul de comunicație Controller Robot Cartezian – Microcontroller Magazie ASRS

Se poate observa că robotul face o cerere de stare către microcontrollerul ASRS pentru a vedea dacă acesta se află în modul manual sau automat. Dacă se află în modul manual nu se mai poate face cererea de operație de stocare pentru că magazia nu va răspunde acestei cereri. Dacă răspunsul este modul automat atunci se face cererea de operație de stocare, adică deschiderea sau închiderea sertarului cu numărul X (de la 1 la 4). După primirea acestei cereri, microcontrollerul magaziei de palete efectuează acțiunile mecanice necesare îndeplinirii acestei acțiuni. Rezultatul operației de stocare poate fi succes sau eșec, iar acesta este trimis către robot pentru a se ține cont de acest lucru.

4.3 Organizarea sistemului de programe PLC pentru regimul de control automat

Sistemul de programe proiectat pentru regimurile de control manual, de diagnoză si de pilotare automată în vederea rutării și execuției produselor și de trasabilitate a proceselor și produselor cu vizualizare prin interfețe grafice, și implementat pe automatul programabil central al CFF are o structură complexă fiind format din mai multe programe ce rulează în paralel, așa cum se prezintă în Fig. 4.14.

Fig.4.14 Organizarea sistemului de programe PLC. Diagrama generală a programelor din automat

Primul dintre acestea este programul de comunicație prin OPC Server cu planificatorul off-line (SS) aflat pe serverul de aplicații. El preia datele de fabricație și le memorează în structura specifică automatului pentru a fi ulterior accesate de către programele de transport. Pentru fiecare paletă se transmite ordinea posturilor cu operațiile corespunzătoare pe la care paleta trebuie să ajungă precum și timpul pentru inserția în sistem.

Failure MANAGER este o unitate care verifică tot timpul statusul roboților. Dacă un robot nu răspunde la semnalul “Request status” atunci “Failure management” oprește (pune pauză) toate programele de transport și informează planificatorul, inițializând comunicația prin OPC pentru a semnaliza astfel schimbarea stării de funcționare a robotului.

Sistemul de transport al paletelor are două tipuri de unități funcționale (programe):

Unitatea de decizie pentru intrare în post de lucru;

Unitatea de transfer.

Unitatea de decizie este cea care, respectând protocolul de comunicație impus, deviază o paletă de pe banda principală pe benzile secundare pentru intrarea la postul de lucru. În momentul în care o paletă este detectată la intrarea în postul de decizie (senzorul și cititorul de cod magnetic aflat înainte de liftul pentru deviere semnalizează prezența) se accesează structura memorată de către programul de comunicație pentru TCP, folosind drept parametru codul paletei pentru a vedea dacă acesta este postul la care aceasta urmează să intre. Dacă nu, atunci unitatea acționează elementele mecanice astfel încât paleta să nu fie deviată de pe banda principală transportoare și să ajungă la următorul post, prin activarea unei unități de transfer. Dacă totuși paleta trebuia să fie deviată, atunci acest program inițiază protocolul de comunicație stabilit conform diagramei din Fig. 4.11 și trimite codul operației pe TCP către robot așteptând acceptul sau refuzul jobului. Dacă jobul este refuzat, atunci se încearcă identificarea și rezolvarea problemei (numai în cazul în care robotul intarzie să răspundă pe TCP, statutul de funcționare fiind deja verificat ciclic de către failure manager acesta din urma luând decizia ca robotul e funcțional). Dacă jobul este acceptat, atunci se iau măsurile necesare pentru a devia paleta către postul robotului urmând ca, la ajungerea acestuia în post să se ridice linia “Pallet in position”.

Unitatea de transfer este cea care, detectând o paleta și fiind îndeplinite anumite condiții externe (tronsonul de deviere/transfer nu este ocupat, robotul a terminat jobul, etc. ) face transferul fie de pe o bandă transportoare principală pe cealaltă, fie de la un post de lucru al unui robot pe o bandă principală de transport. Ea gestionează transferurile între cele două benzi principale și cele de la posturile de lucru ale roboților după ce un job a fost terminat la benzile principale conveioare.

Structura sistemului software de programe gestionate de Automatul Programabil ca unitate centrală de pilotare și urmărire a producției conține un total de 39 de module de programe și trei funcții. Aceste subsisteme software au fost imparțite în 10 categorii:

Programe de tip opritor

Programe de tip lift

Programe de tip transfer

Programe de tip comunicație robot I/E digitale

Programe de tip TCP data send

Program de tip scrie cod (RFID)

Program de tip gestiune timp

Programe de tip gui (graphical user interface)

Program de tipul comunicație OPC

Funcțiile de comunicație specifice TCP/IP

4.3.1 Programul tip Opritor

Programul de tip “opritor” are în gestiune comanda elementului mecanic denumit opritor de pe conveiorul celulei, a cărui funcție este să lase sau nu o paletă sa treacă pe banda conveioare pe care este montat.

Programul de gestiune verifică dacă segmentul următor pe care ar intra paleta-produs este liber sau nu, și în funcție de disponibilitatea acestuia să activeze coborârea opritorului pentru a permite paletei sa treacă. Tot în atribuțiile acestui program se înscrie și introducerea paletei pe una din benzile conveioare laterale către posturile de lucru ale roboților, adică va reprezenta unitatea de decizie din diagrama 4.14.

Fig. 4.15 Diagrama programului Opritor

Din Fig. 4.15 reiese structura logică pe care se bazeaza acest program, el având două regimuri de funcționare predefinite:

modul automat și

modul diagnoză.

În modul automat se așteaptă ca o paleta să ajungă peste opritorul respectiv, eveniment sesizabil prin activarea senzorului boolean din dreptul opritorului. Dacă o paleta este detectată se verifică, prin citirea în structura de date a automatului, dacă postul la care paleta trebuie sa ajungă este cel al robotului în fața căreia se află opritorul sau nu. Dacă paleta trebuie sa ajungă la acest post robot, se verifică starea postului robotului. În cazul în care robotul este liber atunci se ințiaza programul de transmisie a codului prin Ethernet, așteptându-se acceptul sau refuzul jobului.

Acceptare jobului de către robot presupune mișcarea paletei cu deviere către post, iar pentru aceasta programul marchează segmentul următor de banda ca fiind ocupat, așteptând ca paleta să ajungă pe liftul care va face devierea. Odată paleta ajunsă în acest punct opritorul se poate ridica.

Refuzul jobului de către robot survine doar în cazul detecției defectatrii unei resurse, ceea ce conduce la schimbarea stării robotului (de ex. variabila robot1_status devine 2), anunțând planificatorul ca acel robot necesita o operație de alimentare, paleta fiind lăsata sa plece mai departe. Aceasta echivalează cu efectuarea unei bucle complete de mișcare pe conveior.

Dacă în urma verificării structurii interne de date paleta nu trebuie sa intre în postul de lucru al robotului atunci este ocupat segmentul următor de banda (cu condiția ca acesta sa fi fost liber), se lasă atât opritorul cat și liftul următor, și se așteaptă pana când paleta a ajuns la următorul opritor de pe traseul sau, moment în care se eliberează acest segment de conveior, precum și liftul și segmentul de conveior ocupat anterior, revenindu-se la starea inițială.

Fig. 4.16 Structura logică pentru evacuare palete din post

În cazul modului de diagnoză, când o paletă este detectată în dreptul opritorului, se verifică dacă destinația finală a acesteia era chiar acest opritor. Dacă nu, atunci se scrie un mesaj în variabila de notificare precum că paleta a trecut prin acest punct, și se lasă opritorul urmând a fi ridicat după trecerea unei secunde și se revine la etapa inițială. Dacă opritorul era destinația dorită de utilizator, se face doar notificarea utilizatorului precum că paleta a atins destinația.

Toate programele de tip “opritor” au fost realizate astfel cu trei excepții:

la opritoarele din dreptul roboților de tip viper s-a mai introdus și o serie de etape pentru a putea face evacuarea paletelor din postul de lucru ele având structura din Fig. 4.15.

la intrarea în sistem opritorul aflat în acea poziție trebuie sa țină cont de condiții mai complexe pentru a lasă paletele să pătrundă în sistem el făcând și scrierea codului (vezi Fig. 4.16).

la ieșirea din sistem trebuie actualizat și numărul paletelor din sistem și în plus trebuie și realizată cererea de evacuare (vezi Fig. 4.17).

Programele ce gestionează intrarea și ieșirea paletelor din sistem funcționează după diagramele prezentate în Fig. 4.17 si Fig. 4.18, iar funcționarea lor este explicată după cum urmează.

Fig. 4.17 Programul de tip opritor pentru introducerea paletelor în sistem.

Inițial programul de intrare verifică dacă sistemul se află la începutul producției. Dacă răspunsul este afirmativ atunci se dă comanda de plasare a unei palete pe conveiorul principal, prin ridicarea liniei “Place_pal”. Dacă producția a fost deja începută, trebuie verificat dacă mai este necesară introducerea unei noi palete. În cazul negativ, se trece într-o stare de așteptare a unei noi comenzi. Dacă totusi mai trebuie introdusă o paletă în sistem, se așteaptă ca paleta anterioară să fi părăsit postul de intrare, pentru a se elibera segmentul ocupat anterior, ridicarea liftului și a opritorului și a se face cererea de plasare a unei noi palete pe conveior. Odată realizată cererea, se așteaptă ridicarea semnalului “Pal_placed” de către robotul Cartezian, adică terminarea operației de plasare a paletei la intrare. Urmează verificarea dacă timpul de inserare coincide cu cel de producție și se așteaptă până când cele două coincid. Ocuparea segmentului de intrare în sistem, scrierea codului RFID, coborârea opritorului și a liftului pentru a permite deplasarea paletei de la postul de intrare către celelalte posturi nu se poate efectua decât dacă anterior o altă paletă nu a ocupat segmentul de intrare prin traversarea de pe o bandă principală pe cealaltă.

Procedura de ieșire a paletelor din sistem este implementată în cadrul programului opritor care gestionează ieșirea sistemului. Odată detectată o paletă la ieșirea din sistem, automatul trebuie să ridice linia de comandă “Remove_Pal” și să aștepte ridicarea liniei omologe “Pal_Removed” prin care robotul notifică automatul asupra faptului că paleta a fost preluată de pe banda de ieșire. Automatul programabil va decrementa numărul de palete evacuate și dacă în sistem se mai află palete se va relua procedura. Dacă nu mai sunt palete de evacuat, se trece într-o stare de așteptare a unei noi producții.

Fig. 4.18 Procedura de evacuare a paletelor din sistem.

4.3.2 Programul de tip lift

Programul de tip “lift” are în gestiune comanda elementului mecanic cu același nume a cărui funcție este cea de a ridica paleta de pe nivelul benzilor principale ale conveiorului pe una din benzile laterale ale postului robot. Programul de gestiune semnalizează robotului posibilitatea începerii operațiilor necesare odată ce a adus paleta la postul de lucru.

Din Fig. 4.19 reiese structura logică pe care acest program se bazează, el având două regimuri de funcționare predefinite: modul automat și modul diagnoza.

În modul automat se așteaptă ca o paleta să ajungă pe liftul respectiv prin activarea senzorului logic din dreptul lui. Dacă paleta nu este detectată, se verifică și dacă în postul de lucru al robotului se află o paletă asupra căreia s-a terminat operația în curs și care ar trebui evacuată.

Dacă în urma acestei verificări reiese necesitatea evacuării, se trece la memorarea raportului de terminare a operației asupra paletei, ridicarea liftului, ocuparea următorului segment de conveior și la evacuarea paletei din post, așteptându-se ieșirea acesteia. După terminarea evacuării paletei, se lasă liftul liber și se eliberează segmentul de conveior ocupat anterior, revenindu-se la starea inițială.

Fig. 4.19 Diagrama programului Lift

Dacă paleta a fost detectată la intrarea pe lift, iar acesta se află în poziție normală, acest lucru înseamnă că programul de tip opritor anterior liftului a luat deja decizia de a introduce paleta la postul robotului și de aceea este ocupat segmentul următor de conveior, este ridicat liftul, iar paleta deviată către post. Dacă aceasta a ajuns în post se anunță robotul, se oprește mișcarea paletei, se lasă liftul și se eliberează segmentul de conveior utilizat, revenindu-se la starea inițială.

În cazul modului de diagnoză, când o paletă este detectată în dreptul liftului, se verifică dacă destinația finală a acesteia este acest lift. Dacă nu, atunci se verifică dacă pentru a atinge următoarea destinație liftul trebuie să devieze paleta sau nu (în ambele cazuri înscriind în mesajul de notificare trecerea paletei prin acest punct), apoi fie se coboară liftul pentru a permite trecerea pe conveiorul principal fie să ridice liftul iar paleta își continuă drumul pe banda de deviere.

După trecerea unei secunde se revine la starea anterioară a liftului. Dacă liftul era destinația dorită de utilizator, se face doar notificarea că paleta a atins destinația.

4.3.3 Programul de tip transfer

Programul de tip "transfer" are în gestiune comanda unui lift dublu și a opritorului ce îl precede. Acest transfer va prelua paleta de pe o banda principală a conveiorului și o transportă pe cealaltă bandă principală. Fig.4.20 redă structura logică pe care acest program se bazează, el având două regimuri de funcționare predefinite, modul automat și modul diagnoză.

Fig. 4.20 Diagrama logică a programului tip Transfer

În modul automat se așteaptă ca o paletă să ajungă la opritorul ce precede transferul respectiv prin activarea senzorului boolean din dreptul acestuia. Când o paletă a fost detectată se verifică dacă pe banda cealaltă există deja o altă paleta care să ocupe segmentul următor de pe traseu. Dacă această verificare relevă faptul că segmentul este liber, se trece la transferarea paletei prin ocuparea segmentului următor, lăsarea opritorului, ridicarea transferului, pornirea motorului transferului, așteptându-se ca produsul să traverseze banda. Dacă paleta a ajuns la ieșirea de pe transfer atunci se lasă transferul, se oprește motorul transferului și se eliberează segmentul ocupat, revenindu-se la starea inițială.

În cazul modului de diagnoză, când o paleta este detectată în dreptul liftului dublu, se verifică dacă destinația finală a acesteia era chiar acest transfer. Dacă nu este, atunci trebuie să se efectueze transferul și să se înscrie în mesajul de notificare trecerea paletei prin acest punct, apoi să se efectueze operațiile de ridicare a transferului, pornire a motorului transferului, așteptându-se ca produsul să traverseze banda, după care să se efectueze operațiile de lăsare a transferului și de oprire a motorului acestuia. Dacă transferul era destinația dorită de utilizator, se face doar notificarea utilizatorului precum că paleta a atins destinația.

4.3.4 Programul de tip comunicație robot

Programul de tip "ComRobot" are în gestiune implementarea protocolului de interogare prin linii de I/E numerice a fiecărui controller de resurse. El trebuie să decidă dacă controller-ul funcționează corect și să comunice mai departe, prin schimbarea statusului, starea acestuia (Fig. 4.21) fiind parte integrantă din modulul denumit „Failure/Recovery management”.

Din Fig. 4.22 reiese structura logică pe care acest program se bazează, el având un singur regim de funcționare predefinit, modul automat.

Fig. 4.20 Diagrama logică a programului tip ComRobot

Odată cu activarea modului automat, acest program începe să interogheze controller-ul de resurse prin ridicarea liniei RequestStatus la “1” logic. Robotul are la dispoziție 2 secunde să răspundă prin ridicarea la rândul său a liniei de Status Reply.

Dacă controllerul a răspuns la interogare se verifică și dacă acest răspuns a fost întâmplător prin punerea la “0” logic a liniei de RequestStatus, automatul așteptând ca și robotul să lase la nivelul liniei StatusReply în același interval de timp de 2 secunde.

În cazul în care controllerul nu răspunde în intervalul de timp oferit, acest program notifică utilizatorul asupra stării de anormalitate și schimbă indicatorul de stare al resursei din “ok” în “failed” prin scrierea în cuvântul de stare a valorii 0, ciclul de verificare reluându-se.

Interogarea se face ciclic și când un controller răspunde, starea sa este marcată ca fiind “ok” pentru a putea semnaliza intrarea în normalitate (procesul de recuperare) a resursei respective dacă anterior fusese marcată ca “failed”.

4.3.5 Programul de tip TCP_data_send

Programul de tip “TCP_data_send” are în gestiune implementarea protocolului de comunicare prin interfața EtherNet cu fiecare controller de resurse. El trebuie să trimită o cerere către controller oferind informațiile legate de tipul operației dorite și să aștepte răspunsul acestuia.

Din Fig. 4.21 reiese structura logică pe care acest program se bazează, el având un singur regim de funcționare predefinit, modul automat.

Fig. 4.22 Diagrama logică a programului tip TCP_data_send

Odată cu activarea acestui program se verifică dacă un canal de comunicație de tip socket fusese anterior stabilit intre automat și controllerul de resurse. În cazul în care acest canal nu există, se apelează funcția de deschidere și apoi se trece la transmisia primului octet, verificând dacă această operație a fost încheiată cu succes. În cazul în care nu a fost încheiată cu succes se încearcă retransmisia, eșecul fiind notificat utilizatorului. Succesul transmisiei presupune așteptarea răspunsului controllerului la cererea făcută, după care se revine în starea inițială.

4.3.6 Programul de tip scriere cod

Programul de tip “Write_Code” are în gestiune scrierea unui cod de opt biți pe pastila de memorie asociată unei palete produs. Pentru ca acest cod să fie valid trebuie scrise la următoarele două adrese și complementul binar față de “1”.

Din figura 4.23 reiese structura logică pe care acest program se bazează, el având un singur regim de funcționare predefinit, modul automat.

Fig. 4.23 Diagrama logică a programului tip Write_Code

Odată cu activarea acestui program se verifica dacă procesorul sistemului de identificare funcționează corect și dacă o pastilă magnetică se află în poziția pentru scriere. În cazul în care una din aceste condiții nu este îndeplinită se notifică utilizatorul și se revine la starea inițială. Dacă condițiile precursoare acestui proces sunt îndeplinite, se dă comanda de scriere a primului octet și se verifică dacă aceasta a decurs corect. În cazul în care a apărut o eroare se întrerupe scrierea și se notifică utilizatorul revenindu-se la starea inițială.

Dacă totul a decurs corect se scrie și următorul octet în mod analog verificându-se corectitudinea operației de scriere, până când cei trei octeți au fost corect memorați apoi se revine la starea inițială.

4.2.7 Programul de tip gestiune timp

Programul de tip “Gest_Timp” are în gestiune: incrementarea timpului de producție în unități de 500 ms și în cazul în care un robot a fost marcat “failed” în timp ce o paletă se află în postul de lucru, marcarea acesteia pentru scoaterea din sistem. în cazul în care producția s-a terminat se reinițializează sistemul.

Din Fig. 4.24 reiese structura logică pe care acest program se bazează, el având un singur regim de funcționare predefinit, modul automat.

Programul așteaptă trecerea a 500 de ms, pentru a incrementa indexul de timp cu o unitate, apoi trece la verificarea statusurilor roboților și în cazul în care unul din aceștia este marcat “failed”, paleta care se află în post este marcată pentru evacuarea din sistem.

Fig. 4.24 Diagrama logică a programului tip Gest_Timp

După ce se verifică starea resurselor, se trece la verificarea terminării producției în vederea reinițializării sistemului. În cazul în care nu trebuie reinițializat se revine la starea inițială așteptându-se următorul interval de 500ms. În cazul în care producția nu s-a terminat se revine de asemenea în starea inițială.

4.3.8 Programul de tip GUI (Graphic User Interface)

Programul de tip “GUI_pal” are în gestiune mișcarea pe interfața grafică a obiectelor ce identifică o paletă și de aceea va fi detaliat în sectiunea următoare.

4.3.9 Program de tip comunicație OPC

Programul de tip comunicație OPC are drept scop facilitarea comunicării structurii de date standard transmisa de către planificator către automatul programabil și a stării produselor de la automat la planificator. El are două regimuri de funcționare (Fig. 4.25): scriere de date pe OPC (planificatorul scrie – automatul memorează) și citire de date pe OPC (automatul furnizează datele și planificatorul le memorează).

Scrierea și citirea structurii de date din automatul programabil este gestionată de aplicația de planificare de pe serverul celulei. Pentru scrierea datelor în structura de automat programabil, planificatorul trebuie să scrie valorile celor 16 structuri de operație pentru fiecare produs în parte, și codul de ordine al produsului (codul unic după care acesta va fi identificat prin sistem), timpul de inserare în producție în variabilele de comunicare și apoi să dea comanda de copiere prin setarea variabilei booleene “writeOPC”.

După aceasta programul comunicație OPC va copia datele din aceste variabile de comunicație în structura corespunzător codului de produs scris de planificator și va nega variabila “writeOPC” așteptând o nouă comandă de copiere.

Fig. 4.25 Structura programului comunicație OPC

Citirea structurii se face ciclic pentru fiecare produs în parte, planificatorul scriind codul de identificare al produsului și apoi setând variabila “readOPC”. La detecția valorii “true” a acestei variabile automatul va copia din structura de date internă toate operațiile corespunzătoare acestui produs în variabilele de comunicație iar apoi va valida copierea prin negarea variabilei “readOPC”, planificatorul putând astfel avea acces la datele memorate.

4.3.10 Funcții specifice TCP/IP

Cele trei funcții specifice TCP/IP utilizate în cadrul structurii de programe sunt:

TcpClientOpenSocket

TcpReceiveData

TcpSendData

TcpClientOpenSocket se folosește pentru deschiderea unui socket de comunicație și are drept argumente de intrare portul pe care se dorește deschiderea socketului, adresa IP a serverului la care se dorește conectarea și dimensiunea maximă a datelor pe care se dorește a fi transmise. Funcția va returna codul de identificare pentru socketul deschis.

TcpReceiveData se folosește pentru recepționarea datelor pe Tcp/Ip și are drept argumente codul de identificare a socketului pe care se face recepționarea, adresa de memorie a zonei tampon pentru memorarea datelor primite, dimensiunea datelor ce urmează a fi primite precum și durata maximă de așteptare (timeout).

TcpSendData se folosește pentru transmiterea datelor pe Tcp/Ip și are drept argumente codul de identificare a socketului pe care se face transmisia, adresa de memorie a zonei tampon pentru citirea datelor ce urmează a fi transmise, dimensiunea datelor ce urmează a fi transmise precum și durata maximă de așteptare (timeout).

Cap. 5 Managementul schimbarilor la perturbatii in CFF cu ajutorul

automatului programabil

Perturbatiile de natura tehnica care afecteaza functionarea normala, conform unei planificari, secventieri si alocari a priori realizate de MES pot fi de două feluri:

Defectarea / revenirea in stare functionala a unei resurse de producție;

Epuizarea stocului de materiale / componente intr-un depozit local al unei statii de lucru robotizate.

In ambele situatii, automatul programabil al CFF initiaza actiuni specifice pentru gestionarea acestor perturbatii fara intreruperea procesului de productie (Fig. 5.1)

Fig. 5.1 Procesul de gestiune a schimbarilor initiat de PLC la perturbatii in CFF (defectare resurse, epuizari de stoc)

Dupa cum s-a aratat in Cap. 4, la intrarea unei palete cu produs (OH in executie curenta) in postul de lucru are loc un ultim dialog intre automatul programabil si controllerul resursei din acel post (Fig. 4.8) pentru validarea lansarii operatiei care urmeaza sa fie executata (intre mixul planificarii optimale realizate de SS si momentul prezentarii OH unei resurse alocate pentru executia unei operatii curente, starea si performantele resursei s-ar fi putut altera, si deci acest ultim dialog PLC – resursa se impune).

In urma acestui dialog pot aparea trei situatii:

Operatia curenta este validata si productia continua sa fie executata conform planificarii existente (realizate off-line);

Operatia curenta nu este validata datorita unei degradari a resursei (de ex. un robot nu raspunde la interogatiile automatului programabil);

Operatia nu este validata datorita lipsei de materii prime din depozitul local al statiei: controllerul robot raspunde la interogari dar nu este capabil sa efectueze operatia ceruta (de ex.: se cere montarea unei piese de tip ”L”, dar robotul nu are in stoc acel tip de piesa).

In ultimele doua cazuri, pentru a se continua productia este necesara o replanificare a produselor ce trebuiesc executate, simultan cu o eventiala activare in CFF a unei resurse valide, similare celei defectate.

5.1 Gestiunea situatiilor de defectare / revenire in stare functionala a unei resurse

O functie importanta a automatului programabil al CFF este monitorizarea starii resurselor (disponibilitatea operatiilor pe care o resursa le poate efectua in conditii de calitate, timp si consum de energie corespunzatoare) si initierea recalcularii de catre holonii ordin ai produselor aflate in executie la momentul avariei a unei planificari valide, urmarind si un criteriu de optim local, in functie de starea curenta a produselor aflate in executie (localizarea lor in sistemul de transport si procentul in care au fost executate identificat prin indexul operatiei curente).

O resursa (de ex. un robot) poate trece prin urmatoarele stari: functional, defect si fara piese (Fig. 5.2).

Fig. 5.2 Actiuni luate de PLC la tranzitia intre stari

Semnificatia acestor stari este prezentata in Tabelul 5.1:

Tabel 5.1 Semnificatia starilor prin care trece o resursa

Pe baza starii curente si a starii precedente (evenimentul care a produs tranzitia intre stari) se iau urmatoarele actiuni cu scopul de a asigura continuitatea productiei, conferindu-i sistemului capacitatea de toleranta la defect printr-o functionare degradata (resursa afectata este scoasa din noua planificare si se asteapta realimentarea sau repararea defectiunii).

Procedura care realizeaza managementul caderilor de resurse este identica pentru cele doua cazuri care pot aparea: o resursa se defecteaza, respectiv o resursa reintra in functiune. Starea resurselor este permanent verificata de aplicatie si in cazul aparitiei unei neconcordante intre starea curenta a resurselor si starea resurselor in momentul in care a fost calculata vechea planificare, aceasta din urma se reface dupa cum urmeaza:

Pentru a putea rejecta perturbațiile provocate de defectarea sau repararea unei resurse sistemul interoghează ciclic starea acestora prin protocolul implementat prin liniile de intrare ieșire digitale (în cazul de față cea a roboților ) iar dacă una dintre acestea nu răspunde într-un anumit timp este declarată ca fiind defectă. Imediat sistemul reacționează efectuând următoarele operații (Fig. 5.3):

Oprește toate acțiunile de natură mecanică.

Reimprospătează holonul resursă privind noile stări a resursei.

Citește stărea de executie a produselor aflate în sistem (ce operații au fost efectuate).

Evaluează dacă mai pot fi terminate toate ordinele aflate in executie:

În cazul defectării:

Dacă resursa poate fi înlocuită cu alta valida similara, toate produsele pot fi încă terminate;

Dacă resursa nu poate fi înlocuită, toate produsele care utilizează această resursă nu mai pot fi executate și sunt marcate corespunzător.

În cazul unei reparări:

Dacă produsele marcate ca fiind imposibil de realizat se pot executa, le re-marchează pentru executare.

Inițializează planificatorul cu starea actuală a sistemului.

Replanifică produsele ținând cont ordinele executate deja, ordinele marcate ca imposibil de efectuat și cele demarcate.

Supra-scrie planificarea în automatul programabil cu noile date.

Reia toate acțiunile mecanice.

Fig. 5.3 Rejectarea perturbațiilor de funcționare a resurselor.

Legenda: P – operație de planificare; W – așteaptă instrucțiuni; C – verificarea statusurilor; R – Robot operațional; T – operații de transport; F – defectare robot; H – semnal de oprire; S – oprirea acțiunilor mecanice; I – inițializarea planificatorului; Rr – reparare robot; TP- terminarea producției în curs; RP-replanificare;

5.2 Gestiunea situatiilor de epuizare a stocurilor in depozitele locale și implementarea

holonului de realimentare

În mod normal după ce depozitul local al unei resurse de producție a fost alimentată, producția decurge conform planificării realizate a priori (recomandarile SS sunt onorate ca fiind optime). În cazul terminării pieselor din stocul unui depozit robot, evenimentul este detectat când un produs negociază intrarea în post și face o cerere de operație care presupune utilizarea acelui tip de piesă. Răspunsul dat de robot, în acest caz refuzul operației datorită lipsei de piese, va fi cel care va declanșa mecanismul de realimentare exemplificat și în figura 3.42.

Detectarea acestei situații se face cu ajutorul codurilor de alimentare implementate anterior prin aceeași metodă de codificare:

cod_operație_alimentare = cod_offset + număr_de piese

unde cod_offset discriminează tipul de piesă iar numărul de piese va fi dictat de cantitatea maximă de piese transportabile, respectiv capacitatea maximă a stocului pentru acel tip de piesă.

Valorile variabilei cod_offset pentru a putea determina tipul de piesă al cărui stoc a fost epuizat sunt următoarele:

100 pentru piesele de tip ax;

130 pentru piesele de tip „T”;

150 pentru piesele de tip „I”;

170 pentru piesele de tip „L”;

190 pentru piesele de tip „non-L”;

210 pentru piesele de tip „r”;

Dacă codul returnat se află între două limite de cod_offset atunci tipul piesei care a generat planificarea este cel corespunzător limitei inferioare (dacă de exemplu se primește codul 160, el se află între 150 și 170 și de aceea se poate determina faptul că piesa este de tipul „I”).

Mecanismul declanșat presupune ca robotul să treacă din oricare dintre stările normale de funcționare (Idle sau Busy) în cea de realimentare (Depozit Gol); automatul programabil detectează acest eveniment prin interpretarea codului de răspuns în urma negocierii și inițializează planificarea holonului de realimentare.

Codul primit este utilizat în mecanismul de planificare a holonului de realimentare pentru că el reprezintă operația de încărcare cu piese pe care trebuie să o efectueze robotul de alimentare precum și operația de descărcare a port paletei holonului de realimentare pe care o va efectua robotul care necesită alimentarea.

Structura holonului de realimentare (SH) este foarte asemănătoare cu cea a celor de alimentare dar este limitat la trei structuri standard de tip “date_masina” pentru că sistemul permite existența unui singur holon de realimentare care poate servi un singur robot.

Tabelul 5.2 Structura holonului de realimentare:

În tabelul 5.2 este prezentată structura corespunzătoare unui holon de realimentare în urma detectării evenimentului de epuizare stoc piese „I” și necesitatea realimentării cu cinci piese de acest tip prin interpretarea codului de răspuns care este egal cu „135”. Se remarcă același dualism al operațiilor de încărcare și descărcare de piese dar în plus holonul de realimentare este eliminat din sistem prin poziționarea sa în dreptul postului robotului de alimentare.

Odată schimbată starea de funcționare a robotului, acesta este înlăturat temporar din procesul de producție, eventualele cereri de operație pentru acest post fiind ignorate de automat. Totodată nu se mai permite nici intrarea altor port-palete în sistem până când nu se efectuează toate operațiile necesare terminării produselor deja existente în interiorul sistemului în momentul determinării anomaliei de funcționare.

Aceste acțiuni activeaza holonul de realimentare iar robotul de alimentare începe să aleagă piesele necesare și să le plaseze pe port-paleta corespunzătoare. În timpul necesar robotului de alimentare să pregătească holonul, automatul programabil are un regim de normal de funcționare, adică execută operațiile normale de rutare de port-palete și negociere de operații cu ceilalți roboți (Fig. 5.4).

Fig. 5.4 Mecanismul de gestiune a situatiilor de epuizare a stocurilor in depozitele statiilor de lucru

În momentul în care robotul semnalizează faptul că este terminată încărcarea holonului de realimentare, automatul programabil trebuie să realizeze operații suplimentare de rutare, în care această port-paletă cu piese pentru refacerea stocului in depozit are cea mai mică prioritate dintre toate cele existente în sistem, până când holonul de realimentare termină operațiile necesare și ajunge înapoi la poziția de așteptare lângă robotul de alimentare.

Când holonul de realimentare ajunge la robotul ce a declanșat evenimentul, acesta din urmă începe refacerea stocului de piese. Odată cu plecarea din postul realimentat a port-paletei holonului de realimentare, starea robotului se schimbă și robotul își poate relua funcționalitatea. În Fig. 5.4 cererea ordinului 3 determină schimbarea stării robotului întrucât acesta nu are piese pentru onorarea job-ului cerut. În mod normal ciclul de viață al acestui ordin ar trebui să fie egal cu t1, dar din momentul declanșării mecanismului de realimentare și până când trece timpul de realimentare (t realimentare) portpaleta cu SH este buclată pe benzile principale ale conveiorului astfel încât celelalte ordine să aibă prioritate in raport ea și să nu fie afectată producția produselor lor. Când robotul a revenit în procesul de producție, și port-paleta aceasta a ajuns în postul de lucru, începe execuția acestui ordin. Timpul de producție al ordinului 3 este diferit acum pentru că celelalte ordine au fost parțial sau total executate iar acesta a buclat o perioadă pe benzile principale. T2 reprezintă întârzierea produsă de operațiile robotului de alimentare pentru a sorta piesele necesare și de oprerațiile adiționale de rutare.

Uneori se poate ca anumite operații să poată fi efectuate pe mai multe resurse robot iar epuizarea unui stoc de piese a uneia dintre ele să poată fi suplinită de celelalte. În acest caz s-a hotărât replanificarea produselor din sistem la momentul detectării acestei perturbații pentru a se putea evita buclarea ordinului care a declanșat mecanismul.

Modificările necesare implementării unui asemenea mecanism de realimentare au necesitat implementarea următorului algoritm:

Oprirea tuturor acțiunilor de natură mecanică.

Schimbarea stării robotului în cea de „Depozit Gol”.

Blocarea intrării produselor în sistem.

Reîmprospătarea holonul resursă privind noile stări ale resurselor.

Oferirea stării produselor aflate în sistem planificatorului (operațile efectuate).

Evaluarea ordinelor rămase în sistem (dacă pot fi terminate pe celelalte resurse).

Inițializarea planificatorului cu starea actuală a produselor din sistem.

Replanificarea produsele ținând cont de operațiile executate deja și lipsa resursei afectate de epuizare stoc.

Supra-scrierea planificării în automatul programabil cu noile date.

Reluarea tuturor acțiunilormecanice cu buclarea paletelor care nu pot fi efectuate.

Rutarea paletei holonului de realimentare la robotul afectat cu prioritatea minimă.

Dacă au fost efectuate toate ordinele din sistem, deblocarea acestuia și reluarea procesului normal de funcționare.

Cap. 6 Concluzii

În cadrul tezei au fost abordate fundamente teoretice cu privire la structura internă si modul de operare a automatelor programabile, arhitecturile de comandă și solutii de control al sistemelor flexibile de fabricație, sisteme de fabricație distribuita orientate către produse inteligente precum și sisteme cu auto-adaptare.

Aceste abordari au condus la studierea în cadrul lucrarii de disertatie a diferitelor metode de implementare a mecanismelor de automatizare la nivelul resurselor unei celule flexibile de fabricatie (CFF): (1) preluarea deciziilor si datelor de planificare a produselor in loturi de fabricatie, secventierea operatiilor / produse si alocarea resurselor / operatii, toate calculele fiin realizate simultan in vederea optimizarii indicatorilor tehnico-economici ai productiei; (2) rutarea produselor in sistemul de transport si prezentarea lor resurselor din statiile de lucru; (3) trasabilitatea produselor. Au fost analizate beneficiile utilizarii sistemelor de tip automat programabil ca elemente de automatizare a nivelului „atelier de productie” pentru operatii de tip job-shop.

Au fost examinate diferitele structuri și limbaje de programare ale automatelor programabile și metode de trecere de la algoritmi și concepte teoretice la cod de programare. Pentru a lua cea mai bună decizie au fost comparate toate limbajele de programare ce se conformează standardului IEC-61131-3.

Lucrarea de disertatie a abordat deasemenea solutii de management al schimbarilor produsde de evenimente perturbatoare: defectarea unei rrsurse, respectiv epuizarea stocurilor in depozitele locale ale statiilor de lucru. Soluți elaborata a permis comanda,diagnoza și monitorizarea unui sistem de fabricație cu conducere semi-heterarhica (planificare centralizata de la un planificator global – System Scheduler si alocare de resurse in timp real cu sistem multi-agent ce implementeaza conceptul de fabricatie holonica – dMES).

Îndeplinirea acestui ultim obiectiv a presupus elaborarea de algoritmi pentru:

preluarea fișierelor standard de producție și transpunerea lor în comenzi conveior pentru rutarea paletelor cu produse;

tratarea on line a perturbațiilor produse de defectarea resurselor de producție în contextul sistemelor de fabricație;

tratarea on line a perturbațiilor produse de epuizarea stocurilor resurselor de producție.

Rezultatele experimentale demonstrează fezabilitatea implementării soluțiilor alese cu automate programabile precum și performantele superioare dfe conducere (fiabilitate, agilitate, robustete la pertutrbatii).

Au fost de asemenea proiectate și implementate trei regimuri de funcționare: manual, diagnoză și automat, care permit atat autonomie completa in regim nominal cat si controlul total al operatorului uman asupra sistemului de fabricație. Regimul manual permite comandarea individuală a componentelor sistemului fără a ține cont de eventualele interblocări, dar fără a permite acțiuni ce ar putea conduce la distrugerea acestuia.

Regimul de diagnoză permite verificarea diferitelor capabilități de rutare a sistemului și testarea funcționării corecte a componentelor implicate în procesul de producție.

Regimul automat este regimul normal de funcționare al sistemului cu o intervenție minimă din partea operatorului uman.

Rezultatele obtinute in cadrul lucrarii de disertatie au evidențiat posibilitățile de urmărire a producției și a trasabilitatii produselor într-un sistem de fabricație condus de automate programabile care transpun in actiuni operative deciziile de planificare luate pe nivelul ierarhic superior – HMES. Datele culese de automat pot fi comod interpretate de către operatorul uman implicat în procesul de producție, cele două elemente cheie fiind legate prin intermediul interfețelor ―om-mașină realizate.

Au fost dezvoltate, pe baza conceptului de produs inteligent, o serie de arhitecturi particularizate pentru controlul sistemelor de fabricație. A fost proiectată structura software necesară interfațării unor dispozitive ―embedded cu sistemele de fabricație industriale, prin intermediul utilizării WLAN.

Au fost de asemenea analizate posibilitățile de monitorizare a resurselor din punct de vedere al eficienței în execuție pentru a se sintetiza modele comportamentale care să fie comunicate sistemului de planificare (planificator global sau planificator distribuit în cazul produselor inteligente) și eventualelor sisteme de achiziție de date de tip SCADA sau DCS. Acestea au condus la elaborarea unei arhitecturi de nivel înalt pentru dezvoltarea unui sistem de automatizare a producției performant, robust la perturbatii.

Cap. 7 Bibliografie

[1] L.A. Bryan, E.A. Bryan,Programmable Controllers – Theory and Implementation, Second Edition, Editura: Industrial Text Company, Atlanta – Georgia – USA, 1997

[2] This article is not included in your organization's subscription. However, you may be able to access this article under your organization's agreement with Elsevier.

P. Bhowal, R. Mall, A. Basu, Estimating micro-PLC execution time for time critical system design,Journal of Systems Architecture,Volume 45, Issue 14, July 1999, 1245-1248

[3] M. Chmiel, E. Hrynkiewicz,Fast Operating Bit-Byte PLC, Proceedings of the 17th World Congress The International Federation of Automatic Control Seoul, Korea, July 6-11, 2008

[4] R. Wohlschlaeger, IEC 61131-3 Basics and PLCOpen,Panasonic Electric Works Europe AG, Wohlschlaeger / January 2006

[5] Bosch Rexroth Corporation, Understanding the IEC61131-3 Programming Languages, 2009 (http://www.automation.com/pdf_articles/IEC_Programming_Thayer_L.pdf)

[6] C. Chambers, M. Holcombe, J. Barnard,Introducing X-machine models to verify PLC ladder diagrams,Computers in Industry, Volume 45, Issue 3, July 2001, 277-290

[7] A. Hellgren, M. Fabian, B. Lennartson,On the execution of sequential function charts, Control Engineering Practice, Volume 13, Issue 10, October 2005, Pages 1283-1293

[8] E. I. Gergely, L. Coroiu, A. Gacsadi, Design of safe PLC programs by using Petri nets and formal methods,Proceeding ICAI'10 Proceedings of the 11th WSEAS international conference on Automation & Information, 2010

[9] Th. Borangiu, N. Ivanescu, S. Raileanu, A. Rosu, F.D. Anton, S. Anton, A. Dogar, Al. Dumitrache, Holonic Manufacturing Control with Robot-Vision Part Supply, Proc. of the National Conf. Excellence Research – A Way to Innovation, July 27-29, 2008, Brasov, Romania, ISSN 1844-7090, 146-1 – 146-6

[10]J. Barata,The Cobasa architecture as an answer to shop floor agility, manufacturing the future – concepts, technology, Visions. Pro Literatur Verlag, 31-76, 2006

[11] D. Floroian, S. Ryvkin, F. Moldoveanu, M. Cernat,Multi-agent Technology for Manufacturing Shop Floor, 13th IFAC Symposium on Information Control Problems in Manufacturing, Information Control Problems in Manufacturing, Volume 13 | Part 1, 2009

[12] A.N. Ivanescu, S. Brotac, A. Rosu,Modern Solution for Controlling Combined Fodder Plant, Intelligent Manufacturing Systems IMS 2007, May23-25, Alicante, Spain,2007

[13] M. Pěchouček, V. Mařík,Industrial deployment of multi-agent technologies: review and selected case studies,Autonomous Agents and Multi-Agent Systems, Volume 17, Number 3, 2008, 397-431

[14]V. Mařík, P. Vrba, M. Fletcher,Agent-Based Simulation: Mast Case Study, Emerging Solutions for Future Manufacturing Systems, IFIP International Federation for Information Processing, 2005, Volume 159/2005, 61-72

[15] R.F. Babiceanu et al, Framework for control of automated material-handling systems using holonic manufacturing approach, Int. J. Prod. Res., 42, 17, Taylor & Francis, 3551-3564, 2007

[16] P. Vrba, V. Hrdonka,Material Handling Problem: FIPA Compliant Agent Implementation, Multi-Agent Systems and Applications II, Lecture Notes in Computer Science, 2002, Volume 2322/2002,27-45

[17]Adept, SmartController user guide, 2010, www.adept.com

[18]Bosch-Rexroth, TSplus Belt Conveyor – Basic Equipment Manual Installation and Maintenance Guide, 2002, www.boschrexroth.com

[19] Th. Borangiu, A.N. Ivanescu, A. Dogar, Al. Dumitrache, A. Rosu, Continuous Path Following with Applications in Different Robotic Tasks, 16th International Workshop Robotics in Alpe-Adria-Danube Region RAAD 2007, June 7-9, Ljubljana, Slovenia, 2007

[20] Th. Borangiu, A.N. Ivanescu, A. Rosu, G. Gilbert,Holonic Robot Control for Job Shop Assembly by Dynamic Simulation, Proc. of the 16th Mediterranean Conference on Control and Automation – MED'08, June 25-27, 2008, Congress Centre, Ajaccio, France, ISBN 978-1-4244-2505-1, IEEE Catalog No. CFP08MED-CDR

[21] N. Ivanescu, S. Brotac, Th. Borangiu, A. Rosu, Modernizing a Fodder Plant, Proc. of IEEE SMC International Conference on Distributed Human-Machine Systems DHMS 2008, March 9-12, 2008, Athens, Greece, ISBN: 978-80-01-04027-0

[22] Xu Hong, W. Jianhua, Using standard components in automation industry: A study on OPC Specification, Computer Standards & Interfaces, Volume 28, Issue 4, April 2006, Pages 386-395

[23] S. Raileanu, Th. Berger, Y. Sallez, Th. Borangiu, D. Trentesaux, The open-control concept for holonic manufacturing, International Journal of Mechanics and Control Vol.11, No.01, 2010, ISSN: 1590-8844

[23] C.D. Wickens, J.G. Hollands, Engineering psychology and human performance, 3rd edition, Englewood Cliffs, NJ: Prentice-Hall, 2000.

[24] N. Pires, Semi-autonomous manufacturing systems: The role of the human–machine interface software and of the manufacturing tracking software, Mechatronics, Volume 15, Issue 10, December 2005, 1191-1205

[25], R. E. Billo, & B. Bidanda, Modelling effective material tracking systems, a case study in wireless technology, Proceedings of Industrial Engineering Solutions 98, 10–17,1998

[26] R. Gupta and S. R. Das, Tracking moving targets in a smart sensor network, in IEEE 58th Vehicular Technology Conference, vol. 5, 3035–3039, Oct. 2003

[27] W. Nocoń,G. Polaków, LabVIEW Based Cooperative Design for Control System Implementation, Cooperative Design, Visualization, and Engineering, Lecture Notes in Computer Science, 137-140, 2011

[28] J. SuHa, P.H. Seong, A human–machine interface evaluation method: A difficulty evaluation method in information searching, Journal of Reliability Engineering and System Safety, vol. 94, 1557–1567, 2009

[29] P. Valckenaers, B.S. Germain, P. Verstraete, J. Van Belle, Hadeli, H. Van Brussel, Intelligent products: Agere versus Essere,Computers in Industry, Volume 60, Issue 3, 217-228, April 2009

[30] M. Kärkkäinen, J. Holmström, K. Främling, and K. Artto, Intelligent products – a step towards a more effective project delivery chain, Computers in Industry, Vol. 50,141-151, 2003

[31] G. G. Meyer, K. Främling, J. Holmström, Intelligent Products, A survey, Computers in Industry, Volume 60, Issue 3, 137-148, April 2009

[32] Jade – Java Agent Development Framework, http://jade.tilab.com/

[33] Th .Borangiu, S. Raileanu, A. Rosu, M. Parlea, Silvia Anton and F. D. Anton, Semi-heterarchical distributed control of a holonic manufacturing cell, The Journal of Control Engineering and Applied Informatics- CEAI, 2009

[34] J.F. Pétin, D. Gouyon, G. Morel, Supervisory synthesis for product-driven automation and its application to a flexible assembly cell Control Engineering Practice, Vol. 15, Issue 5, 595-614, May 2007

[35] R.W. Brennan, P. Vrba, P. Tichy, A. Zoitl, C. Sünder, T. Strasser, V. Marik , Developments in dynamic and intelligent reconfiguration of industrial automation, Computers in Industry, Volume 59, Issue 6, 533-547, August 2008

[36] Th. Borangiu, S. Raileanu, A. Rosu, M. Parlea and F. D. Anton, Management of changes in a holonic manufacturing system with dual-horizon dynamic rescheduling of production orders, 13th IFAC Symposium on Information Control Problems in Manufacturing- INCOM, Moscow, June 3-5, 2009

[37] Overo Air documentation, https://www.gumstix.com/

[38] E. Nett, WLAN in Automation – More Than an Academic Exercise? Proceedings of Latin-American Symposium on Dependable Computing, 2005, 4-8

[39] P. Neumann,Communication in industrial automation—What is going on? Control Engineering Practice, volume 15, 2007, 1332–1347

[40] B. Scholz, M. Wollschlaeger, Configuration, implementation and management of heterogeneous industrial communication networks using fieldbus technology, Electrical Engineering, volume 81, 1998, 253-261

[41] J. Gausemeier, W. Dangelmaier, M. Fischer, M. Grafe, C. Matysczok, B. Mueck, Virtual and augmented reality support for discrete manufacturing system simulation, Computers in Industry,Vol. 56, Issue 4, May 2005, 371-383

[42] M. Khalgui, O. Mosbahi, Intelligent distributed control systems, Information and Software Technology, Vol. 52, 2010, 1259–1271

[43] P. Bellini, M. Buonopane, P. Nesi, Assessment of a Flexible Architecture for Distributed Control, Programming and Computer Software, Vol. 29, No. 3, 2003, 147–160

[44] Modicon Inc, Modicon Modbus Protocol Reference Guide, June 1996, www.modbus.org/docs/PI_MBUS_300.pdf

[45] Texas Instrument Incorporated, Industrial Automation using CAN Bus Platform White Paper, 2003, http://www.ti.com.cn/cn/lit/an/slla159/slla159.pdf

[46] B. Scholz, M. Wollschlaeger, Configuration, implementation and management of heterogeneous industrial communication networks using fieldbus technology, Electrical Engineering, volume 81, 1998, 253-261

[47] J. Park, S. Mackay, E. Wright, Open industrial Fieldbus and DeviceNet systems, Practical Data Communications for Instrumentation and Control, 2003, Pages 248-290

[48] D. W. Humphrey, ARC White Paper – Profinet An All-Encompassing Industrial Ethernet Solution, November 2005, ww.ARCweb.com

[49] Trentesaux, D. and A. Thomas (2012), Product-driven control: A state of the art and future trends, in Preprints of INCOM 2012: 14th IFAC Symposium on Information Control Problems in Manufacturing. Bucharest, w246-w250

[50] McFarlane, D., Giannikas, W, Wong, A. C.Y. and M. Harrison (2013), Product intelligence in industrial control: Theory and practice, Annual Reviews in Control, Vol.37, 69–88

[51] McFarlane, D., Giannikas, V., Wong, A. C. and M. Harrison (2013), Intelligent products in the supply chain – 10 years on, in Th. Borangiu, A. Thomas and D. Trentesaux (Eds.), Service orientation in holonic and multi agent manufacturing and robotics, Studies in Computational Intelligence, Springer, Vol. 472, 103–117

[52] Borangiu, Th., Raileanu, S., Trentesaux, D., Berger, T. and I. Iacob (2013), Distributed manufacturing control with extended CNP interaction of intelligent products, Journal of Intelligent Manufacturing, 1-11

[53] Di Lecce, V. (2012), Towards Intelligent Sensor Evolution: A Holonic-Based System Architecture, Proceedings of SENSORCOMM 2012: The Sixth International Conference on Sensor Technologies and Applications, Copyright (c) IARIA, 248-254

[54] Holvoet, T., Wyns, D. and P. Valckenaers (2009, Patterns for delegate MAS, SASO '09 Proceedings of the 2009 3rd IEEE Int. Conf. on Self-Adaptive and Self-Organizing Systems, IEEE Computer Society Washington, DC 1-9

[55] Park, H.S. and N.H. Tran (2010, An Intelligent Manufacturing System with Biological Principles, International Journal of CAD/CAM, Vol. 10, No. 1, 39-50

[56] Leitão, P., Barbosa, V. and D. Trentesaux (2011), Bio-inspired multi-agent systems for reconfigurable manufacturing systems, Engineering Applications of Artificial Intelligence, No. 25, 934–944

[57] Park, H.S. and N.H. Tran (2012), A Cognitive Agent based Manufacturing System Adapting to Disturbances, Int. Journal of Control, Automation, and Systems, Vol. 10(4), 806-816

Anexa

Programe de aplicatie: Capturi de ecrane, cod sursa

Fig. A.1 Infrastructura si programe de control pentru conducerea CFF de tip job-shop

Fig. A.2 Program de tip SFC (Sequential Function Chart) pentru comunicatia pe intrari-iesiri digitale cu un echipament de tip robot industrial

Fig. A.3 Programul SFC de gestiune a timpului (folosit pentru insertia paletelor in sistem)

Fig. A.4 Sectiune program SFC pentru gestiunea intrarii paletei in postul 5

Fig. A.5 Sectiune de program SFC pentru gestiunea realimentarii

Fig. A.6 Program comunicatie OPC cu planificatorul global

Fig. A.7 Program de comunicatie pe TCP cu un echipament de tip robot industrial

Fig. A.8 Sectiune program SFC pentru initializarea comunicatiei TCP

Fig. A.9 Sectiune program SFC pentru controlul liftului de intrare in sistemul flexibil de fabricatie

Fig. A.10 Sectiune program de control al opritorului care gestioneaza intrarea paletelor in celula flexibila de fabricatie

Fig. A.11 Sectiune program SFC pentru transferal paletelor intre benzile transportoare

Fig. A.12 Program secvential SFC pentru scrierea codului OPC

Fig. A.13 Program SFC pentru procesarea variabilelor primite pe OPC

Sectiune de cod program pentru procesare variabilelor primite de PLC pe OPC

FOR i:=1 TO 16 BY 1 DO

oper := sir_palete[index_pal_1,i].operatie;

post_oper:= sir_palete[index_pal_1,i].post;

IF (post_oper =1) THEN

IF ( oper<=59) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[oper],'/R1' );

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[nr_EOS_r12-5],'/R1' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[nr_EOS_r12-4],'/R1' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[nr_EOS_r12-3],'/R1' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[nr_EOS_r12-2],'/R1' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[nr_EOS_r12-1],'/R1' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[nr_EOS_r12],'/R1' );

END_IF

END_IF

IF (post_oper =2) THEN

IF ( oper<=59) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[oper],'/R2');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[nr_EOS_r12-5],'/R2' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[nr_EOS_r12-4],'/R2' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[nr_EOS_r12-3],'/R2' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[nr_EOS_r12-2],'/R2' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[nr_EOS_r12-1],'/R2' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal1[i]:=CONCAT(operatii_r12[nr_EOS_r12],'/R2' );

END_IF

END_IF

IF (post_oper =3) THEN

IF ( oper<=68) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[oper],'/R3');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[nr_EOS_r34-5],'/R3' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[nr_EOS_r34-4],'/R3' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[nr_EOS_r34-3],'/R3' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[nr_EOS_r34-2],'/R3' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[nr_EOS_r34-1],'/R3' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[nr_EOS_r34],'/R3' );

END_IF

END_IF

IF (post_oper =4) THEN

IF ( oper<=68) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[oper],'/R4');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[nr_EOS_r34-5],'/R4' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[nr_EOS_r34-4],'/R4' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[nr_EOS_r34-3],'/R4' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[nr_EOS_r34-2],'/R4' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[nr_EOS_r34-1],'/R4' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal1[i]:=CONCAT(operatii_r34[nr_EOS_r34],'/R4' );

END_IF

END_IF

IF (post_oper =5) THEN

IF (oper =254 OR oper=0)THEN

op_index_pal1[i]:='wait/R5';

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal1[i]:='alim_ax/R5';

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal1[i]:='alim_T/R5';

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal1[i]:='alim_I/R5';

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal1[i]:='alim_L/R5';

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal1[i]:='alim_nL/R5';

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal1[i]:='alim_r/R5';

END_IF

END_IF

IF (post_oper =255) THEN

op_index_pal1[i]:='OUT';

END_IF

IF (post_oper =0) THEN

vi_index_pal1[i]:=TRUE;

op_index_pal1[i]:='';

ELSE

vi_index_pal1[i]:=FALSE;

END_IF

IF (vi_index_pal1[i-1] OR op_index_pal1[i-1]='OUT') THEN

vi_index_pal1[i]:=TRUE;

END_IF

oper := sir_palete[index_pal_2,i].operatie;

post_oper:= sir_palete[index_pal_2,i].post;

IF (post_oper =1) THEN

IF ( oper<=59) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[oper],'/R1' );

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[nr_EOS_r12-5],'/R1' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[nr_EOS_r12-4],'/R1' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[nr_EOS_r12-3],'/R1' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[nr_EOS_r12-2],'/R1' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[nr_EOS_r12-1],'/R1' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[nr_EOS_r12],'/R1' );

END_IF

END_IF

IF (post_oper =2) THEN

IF ( oper<=59) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[oper],'/R2');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[nr_EOS_r12-5],'/R2' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[nr_EOS_r12-4],'/R2' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[nr_EOS_r12-3],'/R2' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[nr_EOS_r12-2],'/R2' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[nr_EOS_r12-1],'/R2' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal2[i]:=CONCAT(operatii_r12[nr_EOS_r12],'/R2' );

END_IF

END_IF

IF (post_oper =3) THEN

IF ( oper<=68) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[oper],'/R3');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[nr_EOS_r34-5],'/R3' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[nr_EOS_r34-4],'/R3' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[nr_EOS_r34-3],'/R3' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[nr_EOS_r34-2],'/R3' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[nr_EOS_r34-1],'/R3' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[nr_EOS_r34],'/R3' );

END_IF

END_IF

IF (post_oper =4) THEN

IF ( oper<=68) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[oper],'/R4');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[nr_EOS_r34-5],'/R4' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[nr_EOS_r34-4],'/R4' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[nr_EOS_r34-3],'/R4' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[nr_EOS_r34-2],'/R4' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[nr_EOS_r34-1],'/R4' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal2[i]:=CONCAT(operatii_r34[nr_EOS_r34],'/R4' );

END_IF

END_IF

IF (post_oper =5) THEN

IF (oper =254 OR oper=0)THEN

op_index_pal2[i]:='wait/R5';

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal2[i]:='alim_ax/R5';

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal2[i]:='alim_T/R5';

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal2[i]:='alim_I/R5';

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal2[i]:='alim_L/R5';

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal2[i]:='alim_nL/R5';

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal2[i]:='alim_r/R5';

END_IF

END_IF

IF (post_oper =255) THEN

op_index_pal2[i]:='OUT';

END_IF

IF (post_oper =0) THEN

vi_index_pal2[i]:=TRUE;

op_index_pal2[i]:='';

ELSE

vi_index_pal2[i]:=FALSE;

END_IF

IF (vi_index_pal2[i-1] OR op_index_pal2[i-1]='OUT') THEN

vi_index_pal2[i]:=TRUE;

END_IF

oper := sir_palete[index_pal_3,i].operatie;

post_oper:= sir_palete[index_pal_3,i].post;

IF (post_oper =1) THEN

IF ( oper<=59) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[oper],'/R1' );

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[nr_EOS_r12-5],'/R1' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[nr_EOS_r12-4],'/R1' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[nr_EOS_r12-3],'/R1' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[nr_EOS_r12-2],'/R1' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[nr_EOS_r12-1],'/R1' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[nr_EOS_r12],'/R1' );

END_IF

END_IF

IF (post_oper =2) THEN

IF ( oper<=59) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[oper],'/R2');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[nr_EOS_r12-5],'/R2' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[nr_EOS_r12-4],'/R2' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[nr_EOS_r12-3],'/R2' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[nr_EOS_r12-2],'/R2' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[nr_EOS_r12-1],'/R2' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal3[i]:=CONCAT(operatii_r12[nr_EOS_r12],'/R2' );

END_IF

END_IF

IF (post_oper =3) THEN

IF ( oper<=68) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[oper],'/R3');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[nr_EOS_r34-5],'/R3' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[nr_EOS_r34-4],'/R3' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[nr_EOS_r34-3],'/R3' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[nr_EOS_r34-2],'/R3' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[nr_EOS_r34-1],'/R3' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[nr_EOS_r34],'/R3' );

END_IF

END_IF

IF (post_oper =4) THEN

IF ( oper<=68) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[oper],'/R4');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[nr_EOS_r34-5],'/R4' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[nr_EOS_r34-4],'/R4' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[nr_EOS_r34-3],'/R4' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[nr_EOS_r34-2],'/R4' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[nr_EOS_r34-1],'/R4' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal3[i]:=CONCAT(operatii_r34[nr_EOS_r34],'/R4' );

END_IF

END_IF

IF (post_oper =5) THEN

IF (oper =254 OR oper=0)THEN

op_index_pal3[i]:='wait/R5';

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal3[i]:='alim_ax/R5';

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal3[i]:='alim_T/R5';

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal3[i]:='alim_I/R5';

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal3[i]:='alim_L/R5';

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal3[i]:='alim_nL/R5';

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal3[i]:='alim_r/R5';

END_IF

END_IF

IF (post_oper =255) THEN

op_index_pal3[i]:='OUT';

END_IF

IF (post_oper =0) THEN

vi_index_pal3[i]:=TRUE;

op_index_pal3[i]:='';

ELSE

vi_index_pal3[i]:=FALSE;

END_IF

IF (vi_index_pal3[i-1] OR op_index_pal3[i-1]='OUT') THEN

vi_index_pal3[i]:=TRUE;

END_IF

oper := sir_palete[index_pal_4,i].operatie;

post_oper:= sir_palete[index_pal_4,i].post;

IF (post_oper =1) THEN

IF ( oper<=59) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[oper],'/R1' );

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[nr_EOS_r12-5],'/R1' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[nr_EOS_r12-4],'/R1' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[nr_EOS_r12-3],'/R1' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[nr_EOS_r12-2],'/R1' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[nr_EOS_r12-1],'/R1' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[nr_EOS_r12],'/R1' );

END_IF

END_IF

IF (post_oper =2) THEN

IF ( oper<=59) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[oper],'/R2');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[nr_EOS_r12-5],'/R2' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[nr_EOS_r12-4],'/R2' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[nr_EOS_r12-3],'/R2' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[nr_EOS_r12-2],'/R2' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[nr_EOS_r12-1],'/R2' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal4[i]:=CONCAT(operatii_r12[nr_EOS_r12],'/R2' );

END_IF

END_IF

IF (post_oper =3) THEN

IF ( oper<=68) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[oper],'/R3');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[nr_EOS_r34-5],'/R3' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[nr_EOS_r34-4],'/R3' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[nr_EOS_r34-3],'/R3' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[nr_EOS_r34-2],'/R3' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[nr_EOS_r34-1],'/R3' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[nr_EOS_r34],'/R3' );

END_IF

END_IF

IF (post_oper =4) THEN

IF ( oper<=68) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[oper],'/R4');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[nr_EOS_r34-5],'/R4' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[nr_EOS_r34-4],'/R4' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[nr_EOS_r34-3],'/R4' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[nr_EOS_r34-2],'/R4' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[nr_EOS_r34-1],'/R4' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal4[i]:=CONCAT(operatii_r34[nr_EOS_r34],'/R4' );

END_IF

END_IF

IF (post_oper =5) THEN

IF (oper =254 OR oper=0)THEN

op_index_pal4[i]:='wait/R5';

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal4[i]:='alim_ax/R5';

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal4[i]:='alim_T/R5';

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal4[i]:='alim_I/R5';

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal4[i]:='alim_L/R5';

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal4[i]:='alim_nL/R5';

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal4[i]:='alim_r/R5';

END_IF

END_IF

IF (post_oper =255) THEN

op_index_pal4[i]:='OUT';

END_IF

IF (post_oper =0) THEN

vi_index_pal4[i]:=TRUE;

op_index_pal4[i]:='';

ELSE

vi_index_pal4[i]:=FALSE;

END_IF

IF (vi_index_pal4[i-1] OR op_index_pal4[i-1]='OUT') THEN

vi_index_pal4[i]:=TRUE;

END_IF

oper := sir_palete[index_pal_5,i].operatie;

post_oper:= sir_palete[index_pal_5,i].post;

IF (post_oper =1) THEN

IF ( oper<=59) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[oper],'/R1' );

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[nr_EOS_r12-5],'/R1' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[nr_EOS_r12-4],'/R1' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[nr_EOS_r12-3],'/R1' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[nr_EOS_r12-2],'/R1' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[nr_EOS_r12-1],'/R1' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[nr_EOS_r12],'/R1' );

END_IF

END_IF

IF (post_oper =2) THEN

IF ( oper<=59) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[oper],'/R2');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[nr_EOS_r12-5],'/R2' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[nr_EOS_r12-4],'/R2' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[nr_EOS_r12-3],'/R2' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[nr_EOS_r12-2],'/R2' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[nr_EOS_r12-1],'/R2' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal5[i]:=CONCAT(operatii_r12[nr_EOS_r12],'/R2' );

END_IF

END_IF

IF (post_oper =3) THEN

IF ( oper<=68) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[oper],'/R3');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[nr_EOS_r34-5],'/R3' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[nr_EOS_r34-4],'/R3' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[nr_EOS_r34-3],'/R3' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[nr_EOS_r34-2],'/R3' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[nr_EOS_r34-1],'/R3' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[nr_EOS_r34],'/R3' );

END_IF

END_IF

IF (post_oper =4) THEN

IF ( oper<=68) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[oper],'/R4');

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[nr_EOS_r34-5],'/R4' );

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[nr_EOS_r34-4],'/R4' );

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[nr_EOS_r34-3],'/R4' );

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[nr_EOS_r34-2],'/R4' );

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[nr_EOS_r34-1],'/R4' );

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal5[i]:=CONCAT(operatii_r34[nr_EOS_r34],'/R4' );

END_IF

END_IF

IF (post_oper =5) THEN

IF (oper =254 OR oper=0)THEN

op_index_pal5[i]:='wait/R5';

END_IF

IF(oper >=100 AND oper <= 129) THEN

op_index_pal5[i]:='alim_ax/R5';

END_IF

IF(oper >=130 AND oper <= 149) THEN

op_index_pal5[i]:='alim_T/R5';

END_IF

IF(oper >=150 AND oper <= 169) THEN

op_index_pal5[i]:='alim_I/R5';

END_IF

IF(oper >=170 AND oper <= 189) THEN

op_index_pal5[i]:='alim_L/R5';

END_IF

IF(oper >=190 AND oper <= 209) THEN

op_index_pal5[i]:='alim_nL/R5';

END_IF

IF(oper >=210 AND oper <= 229) THEN

op_index_pal5[i]:='alim_r/R5';

END_IF

END_IF

IF (post_oper =255) THEN

op_index_pal5[i]:='OUT';

END_IF

IF (post_oper =0) THEN

vi_index_pal5[i]:=TRUE;

op_index_pal5[i]:='';

ELSE

vi_index_pal5[i]:=FALSE;

END_IF

IF (vi_index_pal5[i-1] OR op_index_pal5[i-1]='OUT') THEN

vi_index_pal5[i]:=TRUE;

END_IF

END_FOR

(*numele operatiei actuale pe roboti*)

IF paleta_in_r1 <>0 THEN

oper:=sir_palete[paleta_in_r1,sir_index[paleta_in_r1]].operatie;

IF ( oper<=59) THEN

nume_oper_rob[1]:=operatii_r12[oper];

END_IF

IF(oper >=100 AND oper <= 129) THEN

nume_oper_rob[1]:=operatii_r12[nr_EOS_r12-5];

END_IF

IF(oper >=130 AND oper <= 149) THEN

nume_oper_rob[1]:=operatii_r12[nr_EOS_r12-4];

END_IF

IF(oper >=150 AND oper <= 169) THEN

nume_oper_rob[1]:=operatii_r12[nr_EOS_r12-3];

END_IF

IF(oper >=170 AND oper <= 189) THEN

nume_oper_rob[1]:=operatii_r12[nr_EOS_r12-2];

END_IF

IF(oper >=190 AND oper <= 209) THEN

nume_oper_rob[1]:=operatii_r12[nr_EOS_r12-1];

END_IF

IF(oper >=210 AND oper <= 229) THEN

nume_oper_rob[1]:=operatii_r12[nr_EOS_r12];

END_IF

ELSE

nume_oper_rob[1]:='-';

END_IF

IF paleta_in_r2 <>0 THEN

oper:=sir_palete[paleta_in_r2,sir_index[paleta_in_r2]].operatie;

IF ( oper<=59) THEN

nume_oper_rob[2]:=operatii_r12[oper];

END_IF

IF(oper >=100 AND oper <= 129) THEN

nume_oper_rob[2]:=operatii_r12[nr_EOS_r12-5];

END_IF

IF(oper >=130 AND oper <= 149) THEN

nume_oper_rob[2]:=operatii_r12[nr_EOS_r12-4];

END_IF

IF(oper >=150 AND oper <= 169) THEN

nume_oper_rob[2]:=operatii_r12[nr_EOS_r12-3];

END_IF

IF(oper >=170 AND oper <= 189) THEN

nume_oper_rob[2]:=operatii_r12[nr_EOS_r12-2];

END_IF

IF(oper >=190 AND oper <= 209) THEN

nume_oper_rob[2]:=operatii_r12[nr_EOS_r12-1];

END_IF

IF(oper >=210 AND oper <= 229) THEN

nume_oper_rob[2]:=operatii_r12[nr_EOS_r12];

END_IF

ELSE

nume_oper_rob[2]:='-';

END_IF

IF paleta_in_r3 <>0 THEN

oper:=sir_palete[paleta_in_r3,sir_index[paleta_in_r3]].operatie;

IF ( oper<=68) THEN

nume_oper_rob[3]:=operatii_r34[oper];

END_IF

IF(oper >=100 AND oper <= 129) THEN

nume_oper_rob[3]:=operatii_r34[nr_EOS_r34-5];

END_IF

IF(oper >=130 AND oper <= 149) THEN

nume_oper_rob[3]:=operatii_r34[nr_EOS_r34-4];

END_IF

IF(oper >=150 AND oper <= 169) THEN

nume_oper_rob[3]:=operatii_r34[nr_EOS_r34-3];

END_IF

IF(oper >=170 AND oper <= 189) THEN

nume_oper_rob[3]:=operatii_r34[nr_EOS_r34-2];

END_IF

IF(oper >=190 AND oper <= 209) THEN

nume_oper_rob[3]:=operatii_r34[nr_EOS_r34-1];

END_IF

IF(oper >=210 AND oper <= 229) THEN

nume_oper_rob[3]:=operatii_r34[nr_EOS_r34];

END_IF

ELSE

nume_oper_rob[3]:='-';

END_IF

IF paleta_in_r4 <>0 THEN

oper:=sir_palete[paleta_in_r4,sir_index[paleta_in_r4]].operatie;

IF ( oper<=68) THEN

nume_oper_rob[4]:=operatii_r34[oper];

END_IF

IF(oper >=100 AND oper <= 129) THEN

nume_oper_rob[4]:=operatii_r34[nr_EOS_r34-5];

END_IF

IF(oper >=130 AND oper <= 149) THEN

nume_oper_rob[4]:=operatii_r34[nr_EOS_r34-4];

END_IF

IF(oper >=150 AND oper <= 169) THEN

nume_oper_rob[4]:=operatii_r34[nr_EOS_r34-3];

END_IF

IF(oper >=170 AND oper <= 189) THEN

nume_oper_rob[4]:=operatii_r34[nr_EOS_r34-2];

END_IF

IF(oper >=190 AND oper <= 209) THEN

nume_oper_rob[4]:=operatii_r34[nr_EOS_r34-1];

END_IF

IF(oper >=210 AND oper <= 229) THEN

nume_oper_rob[4]:=operatii_r34[nr_EOS_r34];

END_IF

ELSE

nume_oper_rob[4]:='-';

END_IF

IF data_pal_r5 <>0 THEN

oper:=sir_palete[data_pal_r5,sir_index[data_pal_r5]].operatie;

IF(oper >=100 AND oper <= 129) THEN

nume_oper_rob[5]:=operatii_r34[nr_EOS_r34-5];

END_IF

IF(oper >=130 AND oper <= 149) THEN

nume_oper_rob[5]:=operatii_r34[nr_EOS_r34-4];

END_IF

IF(oper >=150 AND oper <= 169) THEN

nume_oper_rob[5]:=operatii_r34[nr_EOS_r34-3];

END_IF

IF(oper >=170 AND oper <= 189) THEN

nume_oper_rob[5]:=operatii_r34[nr_EOS_r34-2];

END_IF

IF(oper >=190 AND oper <= 209) THEN

nume_oper_rob[5]:=operatii_r34[nr_EOS_r34-1];

END_IF

IF(oper >=210 AND oper <= 229) THEN

nume_oper_rob[5]:=operatii_r34[nr_EOS_r34];

END_IF

ELSE

nume_oper_rob[5]:='-';

END_IF

(*Numele produsului*)

IF pname1<> sir_products[index_pal_1] THEN

IF index_pal_1<>0 THEN

pname1:= sir_products[index_pal_1];

ELSE

pname1:='';

END_IF

END_IF

IF pname2<> sir_products[index_pal_2] THEN

IF index_pal_2<>0 THEN

pname2:= sir_products[index_pal_2];

ELSE

pname2:='';

END_IF

END_IF

IF pname3<> sir_products[index_pal_3] THEN

IF index_pal_3<>0 THEN

pname3:= sir_products[index_pal_3];

ELSE

pname3:='';

END_IF

END_IF

IF pname4<> sir_products[index_pal_4] THEN

IF index_pal_4<>0 THEN

pname4:= sir_products[index_pal_4];

ELSE

pname4:='';

END_IF

END_IF

IF pname5<> sir_products[index_pal_5] THEN

IF index_pal_5<>0 THEN

pname5:= sir_products[index_pal_5];

ELSE

pname5:='';

END_IF

END_IF

IF (close_socks) THEN

SysSockClose(diSocket_r1);

SysSockClose(diSocket_r2);

SysSockClose(diSocket_r3);

SysSockClose(diSocket_r4);

close_socks:=FALSE;

diSocket_r1:=-1;

diSocket_r2:=-1;

diSocket_r3:=-1;

diSocket_r4:=-1;

END_IF