UNIVERSITATEA TEHNICA CLUJ-NAPOCA FACULTATEA DE AUTOMATICA SI CALCULATOARE SECTIA CALCULATOARE
Implementarea unui compilator LAD pentru automate programabile bazate pe procesoare PIC
ÎNDRUM TOR TIIN IFIC: l.dr.-ing. HALLER Piroska CONDUC TOR,
ABSOLVENT,
l.-ing Kutasi D. Nimród
Szatmári Em ke
2008 1
UNIVERSITATEA TEHNICA CLUJ-NAPOCA FACULTATEA DE AUTOMATIZARE SI CALCULATOARE SECTIA CALCULATOARE
VIZAT DECAN Prof.Dr.Ing. Sergiu NEDEVSCHI
VIZAT SEF CATEDRA
TEM PROIECT DE DIPLOM Candidat : Szatmári Em ke Anul absolvirii: 2008
Conduc torul temei: Kutasi D. Nimród 1. Con inutul proiectului
a) Tema proiectului de diplom : Implementarea unui compilator LAD pentru automate programabile bazate pe procesoare PIC. b) Problemele principale care vor fi tratate în proiect: - No iuni de compilatoare, analiz lexical , analiz semantic , limbaj formal - Limbajul automatelor programabile LAD (Ladder Logic). Prezentare. - Proiectarea compilatorului pentru instruc iuni tip bi i. - Descrierea instruc iunilor în limbaj formal. Implementarea analizelor lexicale, semantice. - Proiectarea suprafe ei grafice - Generarea unui cod C, pentru procesorul ales c) Desene obligatorii: - Diagrama use-case a compilatorului - Diagrama de clase, diagrama de obiecte - Diagrama de colaborare - Suprafa a grafic implementat d) Softuri obligatorii - Compilatorul LAD Bibliografie recomandat : 1. 2. 3.
Csörnyei Zoltán, Kása Zoltán: Formális nyelvek és fordítóprogramok, Kolozsvári Egyetemi Kiadó, 2007 Microchip – C18 C Compiler User’s Guide Bach Iván: Formális nyelvek, Typotex Kiadó, 2001
Termene obligatorii de consulta ii: - s pt mânal Locul practicii: Universitate Primit la data de: 01. 06. 2007 Termen de predare: 06.06. 2008 Semn tura efului de catedr Semn tura coordonatorului
Semn tura îndrum torului tiin ific
Semn tura candidatului
2
CUPRINS Cuprins...................................................................................................................12 1. Introducere ........................................................................................................13 1.1. Introducere general .......................................................................................13 1.2. Introducere istoric .........................................................................................13 1.3. Limbaje formale..............................................................................................13 1.3.1. Limbaje regulare i automate finite .......................................................14 2. Compilatorul ....................................................................................................15 2.1. Analiza .......................................................................................................18 2.1.1. Analiza lexical ...............................................................................18 2.1.2. Analiza sintactic .............................................................................20 2.1.3. Analiza semantic ............................................................................24 2.2. Sinteza.......................................................................................................24 2.2.1. Generarea codului ............................................................................24 2.2.2. Optimizarea codului.........................................................................24 3. Imlementarea practic a compilatorului LAD..............................................25 3.1. Introducere ................................................................................................25 3.2. Specificarea cerin elor ..............................................................................25 3.2.1. Analiza i definirea acestora............................................................26 3.3. Arhitectura PIC-urilor...............................................................................26 3.3.1. Architektura PLC-ului cu PIC18F452 ............................................27 3.3.2. Asemanari i deosebiri între PLC-uri pe baz de PIC .....................28 3.4. Proiectare ..................................................................................................29 3.4.1. Diagrama use case ...........................................................................29 3.4.2. Diagrama de clase............................................................................34 3.4.3. Diagrama de obiecte ........................................................................36 3.4.4. Modelul dinamic ..............................................................................38 3.4.4.1 Scenariu ...................................................................................38 3.4.4.2 Diagrama de colaborare ...........................................................39 3.4.4.3 Diagrama secven ial ...............................................................41 3.5. Implementare .............................................................................................42 3.5.1. Introducere .......................................................................................42 3.5.2. Libr ria claselor QT.........................................................................42 3.5.3. Tr s turile claselor QT ....................................................................43 3.5.4. Limit ri de m rimi generale ............................................................43 3.5.5. Tipuri speciale..................................................................................44 3.5.6. Declararea claselor...........................................................................45 3.5.7. Tratarea erorilor ...............................................................................48 3.5.8. Pa ii analizei ....................................................................................48 4. Rezultate i compara ii .....................................................................................49 4.1. Rezultate ...................................................................................................49 4.2. Compara ii ................................................................................................54 5. Concluzii i planuri de viitor............................................................................57 5.1. Concluzii ...................................................................................................57 5.2. Planuri de dezvoltare în viitor...................................................................57 Bibliografie .............................................................................................................58
3
Implementarea unui compilator LAD pentru automate programabile bazate pe procesoare PIC Abstract Scopul lucr rii este crearea unui compilator, care pe baza unui program lad genereaz cod C pentru programarea PLC-urilor. Programul satisface cerin ele standardului IEC 1131-3. Poate interpreta programe scrise în LAD, le salveaz , dup care pot fi redeschise i ulterior interpretate. În lucrare vor fi prezentate p r ile componente ale unui compilator, metodele de analiz lexical i sintactic , generarea codului, respectiv metodele de recunoastere i tratare a erorilor. De asemenea g sim o scurt prezentare a limbajelor formale regulare i automate. Programul a fost implementat cu ajutorul libr riei de clase grafice QT, a c rei prezentare o consider important . Dup partea teoretic prin procedeele de proiectare ajungem la implementarea compilatorului, parte pe care s-a pus un mare accent. La final, programul este comparat cu programe similare, i vor fi prezentate sugestii de dezvoltare în viitor. Va fi prezentat un program grafic, scris in limbaj LAD, men ionând fazele compil rii. Dup acesta g sim imagini din program i explica ii cu privire la pa ii pe care utilizatorul trebuie s le parcurg în timpul realiz rii unui program LAD. Introducere Primul compilator a ap rut în 1952, limbajul de programare A-0. Acesta avea înc multe deficien e i gre eli. Au observat c pentru a putea realiza un compilator mai bun sunt necesare legi mai stricte, fapt ce a condus la necesitatea dezvolt rii limbajului formal. Specifica ii Cerin e pe care trebuie s le satisfac programul: - Sciere program - Salvare program - Deschidere program - Compilare program - Simulare program - Uploadare program - Ad ugare pachet Alte cerin e sunt realizarea programului în mod general, astfel încât cu ajutorul acesteia s se poat realiza programe pe mai multe tipuri de PLC pe baz de PIC. Arhitectura automatelor programabile PLC-urile sunt sisteme pe baz de PIC, care au intr ri, ie iri digitale, respectiv analogice. Sunt echipate mai departe cu afi aj LCD, leduri de stare, tastatur . Comunicarea între un automat programabil i calculator se face prin intermediul por ii
4
seriale. Diferen a dintre diferitele PLC-uri const mai ales în num rul de intr ri-ie iri analogice i digitale, dar este posibil ca PLC-urile s fie alimentate unul diferit de cel lalt, adic uni cu 24V, al i 5V etc. O alt diferen , probabil cea mai important , este diferen a de memorie a acestora, i astfel diferen ele de locul în care sunt legate ie irile si intr rile digitale i analogice. Proiectare Primul pas al proiect rii a fost realizarea diagramei use case. Acesta con ine posibilit ile programului.
figura 1: Diagrama use case PIC choose: prin deschiderea unei ferestre se poate alege PIC-ul care st la baza programului. Open project: prin deschiderea unei ferestre se poate alege un proiect realizat anterior. Write program: realizarea programului LAD, prin procedeu drag and drop din lista de pictograme în suprafa a de programare. Save project: salvarea proiectului creat Interpreted: interpretarea anumitor valori de intrare. Realizeaz o parte din func iunile analizei sintactice. Compile: procedeul de compilare Error handling: ajut la informarea utilizatorului despre erorile realizate. Run simulation: realizeaz simularea programului realizat Upload program: ajut la trimiterea programului spre automatul programabil. 5
Add package: ad ugarea unui pachet, care este evident ad ugarea unui nou PIC colec iei de PIC-uri. Pachetul Este alc tuit din trei p r i: 1) package.txt: aici sunt salvate numele PIC-uilor i caracterisicile acestora(num rul de intr ri ie iri, tensiune de alimentare etc.). Numele maxim al unui PIC este de 50, iar a caracteristicilor de 450 caractere. 2) directorul icons, unde sunt pictogramele respectiv în parameters.txt parametrii corespunz tori ai acestora. Sunt în ordine alfabetic . 3) pic.txt: unde sunt stocate opera iile realizabile cu un anumit PIC Diagrama de clase
figura 2: Diagrama general de clase QMainWindow: relizeaz controlul programului, este clasa principal
6
PieceList: con ine pictogramele utilizabile în cazul unui PIC QListWidgetItem: con ine o anumit pictogram QtableWidget: cu ajutorul acesteia se dau datele de intrare LadWidget: fereastra unde se scrie programul Compiler: clasa care realizez compilarea Realizare Programul a fost realizat în limbaj C, utilizând libr ria claselor QT. Acesta ofer un mediu grafic, care poate fi compilat pe toate sistemele de operare. Este prietenos, logic i u or de urm rit, în raport cu alte clase ca MFC sau SDI. Func ionarea claselor QT se bazeaz pe semnale(signal), ce pot fi trimise spre func ii speciale(slot-uri). Opera iile realizate pân acum sunt urm toarele: - set, reset, and, nand, upedgde, downedge, corespondece, timer, mul Acestor opera ii le corespund pictogramele:
Rezultate În urm toarele rânduri i poze v voi prezenta realiz rile mele: În urm toarele dou poze sunt exemplificate cele dou posibilit i de începere al unui proiect. În primul caz(a), se începe un nou proiect, alegerea PIC-ului, iar în al doilea caz(b) se deschide un nou proiect.
b
a
Un program realizat fie în felul urm tor:
7
Compara ii cu alte produse software Atât firmele mari, cât i persoanele fizice realizeaz programe compilatoare LAD. Cele mai mari firme ce merit men ionate sunt Siemens i Moeller. Cele dou firme reprezint dou categorii diferite, cea a lui Siemens este mai avansat , iar cel Moeller se declar câ tig tor mai ales la proiectele mai mici. Programul meu astfel o pot compara mai mult cu Easy-Soft(software-ul firmei Moeller). Principalul avantaj în raport cu software-ul realizat de mine o are în mul imea de opera ii care se pot efectua pe PLC-uri, iar dezavantajul este pre ul, respectiv faptul c nu are posibilitate de ad ugare pachet. Pe internet sunt o mul ime de astfel de programe. O proprietate al lor este faptul c nu pun accent pe partea greafic respectiv pe cea de update. De obicei este necesar o nou versiune a programului. Un astfel de program este programul realizat de Jonathan Westhues, LDmicro, care poate compila din LAD în cod ma in . În lucrare se poate vedea un program realizat cu acesta. Concluzii Am reu it s realizez elurile propuse, adic realizarea compilatorului. Parcurgând documenta iile g site, respectiv pa i de proiectare, am reu it s descriu limbajul formal al acesteia. Am realizat mai departe compilatorul, alc tuit din analizorul lexical, sintactic i generator de cod. În timpul documenta iei cu privire la func ionarea compilatoarelor, am realizat faptul c nu am nevoie de analizor semantic, respectiv de optimalizator de cod. Acesta din urm ar fi necesar mai mult în cazul în care a fi transcris programul LAD în limbaj assembler sau cod ma in . Un alt atu al programului este faptul c parcurgerea cre rii unui proiect este într-un mediu foarte prietenos. Sunt posibilit i de ad ugare pachet de PIC, care ulterior se pot utiliza pentru creare de programe pe PIC-ul respectiv. Sunt posibilit i de simulare. În timpul compil rii, apar erorile existente în program. Rezultatul programului este un fi ier în limbaj C, care cu ajutorul programului MPLAB, care este un soft gratuit, din fi ierul rezultat realiteaz un fi ier cod ma in , pe care o trimite mai departe în PLC.
8
Planuri de dezvoltare Un prim pas în dezvoltarea programului este realizarea mai multor pictograme respectiv datele aferente acestora. Trebuie avut îns grij la limitele programului, adica a limbajului, care este cel LL(1). În cazul în care limbajul programului pentru un anumit PIC nu mai este LL(1), analiza lexical trebuie rescris . Dac nu se trece aceast limit , dezvoltarea programului este mult mai u or, prin pacheturile care se pot realiza, dup cum a fost descris. Un alt pas important este integrarea în program al comunic rii dintre calculator i automat programabil, pentru a nu fi necesar un alt program corespunz tor opera iei, respectiv compilatorul s fie compilator LAD-cod ma in .
9
SAPIENTIA ERDÉLYI MAGYAR TUDOMÁNYEGYETEM M SZAKI ÉS HUMÁNTUDOMÁNYOK KAR VILLAMOSMÉRNÖKI TANSZÉK SZÁMÍTÁSTECHNIKA SZAK
LAD fordító PIC alapú PLC-re Diplomadolgozat
TÉMAVEZET ,
VÉGZ S HALLGATÓ,
Kutasi Nimród
Szatmári Em ke
2008 10
Kivonat
A dolgozatom célja egy olyan fordító elkészítése, amely áramútterv szer programot fordít C nyelvre, PLC-k programozása céljából. A program eleget tesz az IEC 1131-3 standardnak. Képes értelmezni egy LAD nyelven megírt programot, átírni azt szöveges formába, lementeni, majd a kés bbiek során kinyitni és értelmezni. A dolgozatban bemutatásra kerülnek a fordítóprogramok részei, a lexikális és szintaktikus elemzés, a kódgenerálás, különböz
felismerési illetve hibakezelési
eljárások. Betekintést nyerhetünk a formális nyelvek világába, reguláris nyelvekr l, automatákról tudhatunk meg néhány szót. A program QT grafikus elemkönyvtár segítségével íródott, ennek nagyon rövid ismertetését is fontosnak találtam. Az elméleti rész után a tervezési lépéseket végigkövetve eljutunk a kivitelezés aprólékos
bemutatásához.
Miután
összehasonlítom
más
hasonló
software
programokkal, következtetéseim és jöv beli terveim következnek, ahol a további terveim körvonalazódnak. A dolgozatom egy rövid példát is mutat be egy kis LAD program fordításáról. Megjeleníti a fordítást a különböz fázisaiban, illetve végigfutunk a program grafikus felületén is, lépésr l lépésre, elmagyarázva, hogy mikor mit kell tegyen a felhasználó. Bemutatom az ablakokat, kis magyarázattal, hogy hol mi látható és mi értelme van. Kulcsszavak: kompilátor, LAD, PLC
10
Abstract The objective of this paper is the creation of a compiler, which translate a ladder logic program into C language, intended for PLC’s. The program fulfills the IEC 1131-3 standard. Interprets programs written in LAD, and translates into text form which can be saved afterwards. The saved programs can be reloaded and reinterpreted. The paper presents the main parts of a compiler, lexical and syntactic analysis, code generation and several recognition and failure handling procedures. We get a sight into the principles of formal and regular languages. The program was written using QT graphical libraries, which will also be presented in the paper. After the theoretical introduction through the design step we get to the detailed presentation of the implementation. The program will be compared with similar programs and design and upgrade possibilities will be suggested. The paper presents a short example of the compiling procedure. Also the user interface with the symbol and tools will be presented, explaining step by step what the user should do. Keywords: compiler, LAD (leader logic), PLC
11
TARTALOMJEGYZÉK Tartalomjegyzék ...................................................................................................12 1. Bevezetés ............................................................................................................13 1.1. Általános bevezet ..........................................................................................13 1.2. Történelmi bevezet .......................................................................................13 1.3. Formális nyelvek.............................................................................................13 1.3.1. Reguláris nyelvek és véges automaták ..................................................14 2. A fordítóprogram.............................................................................................15 2.1. Analízis ......................................................................................................18 2.1.1. Lexikális elemz ..............................................................................18 2.1.2. Szintaktikus elemz .........................................................................20 2.1.3. Szemantikus elemz ........................................................................24 2.2. Szintézis ....................................................................................................24 2.2.1. Kódgenerálás....................................................................................24 2.2.2. Kódoptimalizálás .............................................................................24 3. LAD fordító gyakorlati megvalósítása ...........................................................25 3.1. Bevezet ....................................................................................................25 3.2. Követelmény specifikáció.........................................................................25 3.2.1. Követelmények elemzése, definiálása ............................................26 3.3. A PIC-ek architektúrája ............................................................................26 3.3.1. A PIC18F452 mikrovezérl re fejlesztett PLC architektúrája..........27 3.3.2. Hasonlóságok és különbségek más PIC alapú PLC-kkel ................28 3.4. Tervezés ....................................................................................................29 3.4.1. Felhasználói esetek (Use case diagram) ..........................................29 3.4.2. Osztály diagram ...............................................................................34 3.4.3. Objektum diagram ...........................................................................36 3.4.4. Dinamikus modell............................................................................38 3.4.4.1 Forgatókönyvek .......................................................................38 3.4.4.2 Kollaborációs diagram .............................................................39 3.4.4.3 Szekvencia diagram .................................................................41 3.5. Implementáció ...........................................................................................42 3.5.1. Bevezet ...........................................................................................42 3.5.2. A QT grafikus elemkönyvtár ...........................................................42 3.5.3. QT jellegzetességek .........................................................................43 3.5.4. Általános méretbeli korlátozások ....................................................43 3.5.5. Saját típusok.....................................................................................44 3.5.6. Osztályok deklarációi ......................................................................45 3.5.7. Hibakezelés......................................................................................48 3.5.8. Az elemzés menete ..........................................................................48 4. Eredmények és összehasonlítások ...................................................................49 4.1. Eredmények ..............................................................................................49 4.2. Összehasonlítások.....................................................................................54 5. Következtetések és tervek ................................................................................57 5.1. Következtetések ........................................................................................57 5.2. Jöv beli fejlesztési tervek.........................................................................57 Irodalomjegyzék .....................................................................................................58
12
1. Bevezetés 1.1. Általános bevezet Ahhoz, hogy egy számítógép azt tegye, amit elvárnak t le, meg kell neki adni pontosan a feladat specifikációit. Els megközelítésben a probléma az, hogy más nyelvezetet ért a számítógép, nulla illetve egyes, és más nyelvezetet a felhasználó, román, magyar, angol stb. Ennek megfelel en kellett találni egy középutat, amely mindkét félnek megfeleljen. Ezt jelentették a programnyelvek. A mai programnyelvek eljutottak már arra a szintre, hogy nemcsak a feladat megfogalmazását teszik lehet vé, hanem ennek a tervezését és megírását is, ezeket nevezzük magas szint programozási nyelveknek. [4] A választott középút azonban meg mindig nagyon távol van a számítógép által értelmezhet nyelvt l. Ahhoz hogy értelmezhet legyen a középút, fordítókra (kompilátorokra) van szükség. Ezek feladata tehát a magas szint programozási nyelvek lefordítása gépi kódra. 1.2. Történelmi bevezet Az els lépést az emberközeli nyelvek felé az assembler jelentette az 1950-es évek elején. Mnemonyikokkal jelöli a különböz gépi utasításokat. Az els fordítót Grace Hopper írta(1952) egy A-0 nev programozási nyelvre melynek azonban voltak hiányosságai. 1957-ben megjelenik az els teljes fordító, a Fortran (formula translator) nyelvre, amelyet John Bachus és társai írtak az IBM-nél, amely 18 emberélet munkát foglalt magában. 1960-ban megjelenik a COBOL nyelv fordítója, amelyet már több architektúrára lehetett fordítani.[9] A fordítók írása nagyon komplex feladat volt, rengeteg id t és energiát emésztett fel, csökkentése csak egy pontosan leírt és jól strukturált nyelv esetén lehetségesek. Ezt el ször 1960-ban az Algol 60 nyelv kompilátoránál vezették be. Ez alkotta meg a technikai alapját a ma használt fordító tervezéseknek. Ekkor használtak el ször a nyelv leírására egy formális nyelvet.[5] 1.3. Formális nyelvek A számítástechnika rohamos fejl dése volt els sorban a kiváltó oka a formális nyelvek után való érdekl désnek. Szükségessé vált a különböz nyelvek pontos leírásának a lehet sége. Egy nyelv formális leírása a következ [1]: G(N,Σ,P,S) Ahol: - G: grammatika, nyelvtan - Σ: terminális szimbólumok halmaza, a nyelv karakterkészletének véges halmaza, jelölésük kisbet k és más szimbólumok - N: nemterminálisok halmaza: nagybet k - P: helyettesítési szabályok halmaza: Σ ∪ N részhalmazai lehetnek - S: mondatszimbólum: ∈ N - Σ∩N = ∅ Egy nyelv leírtnak tekinthet , ha meg vannak adva: Σ, N, P és S. Például: G = ({S, B, C}, {a, b, c}, P, S) P = { S aSBC, S abC, CB BC, bB bb, bC bc, cC cc }
13
A grammatikák által generált nyelvet L(G)-vel jelöljük. Ez általában egy végtelen halmaz. A fordítóprogram elemzésre a nyelv(L) egy részterét kapja. Chomsky nyelvosztályok A helyettesítési szabályok bonyolultsága szerint négy nyelvosztályt különböztetünk meg[1]: - 3-as nyelvosztály: a baloldalon csak egy nemterminális, a jobb oldalon egy nemterminális és egy terminális szerepelhet. Az ilyen grammatikát bal vagy jobbreguláris nyelvtannak nevezzük, attól függ en, hogy a nemterminális a jobb vagy a baloldalon van. Pl. A∀a, A∀aB, A∀Ba - 2-es nyelvosztály: a baloldal csak egy nemterminális szimbólumot tartalmazhat, a jobb oldala pedig bármit. Ezeket a nyelveket CF(context free) más szóval környezet független nyelveknek nevezzük. Általános felírása: A∀α Pl. A∀aBCb - 1-es nyelvosztály: általános formája βAγ βαγ, amit úgy is lehet értelmezni, hogy az A∀α szabály csakis a β, γ környezetében alkalmazható. Ez a nyelvosztály tehát a CS(context sensitive) magyarul környezetfügg nyelvosztály. - 0-s nyelvosztály: megkötés csak, hogy grammatika legyen, tehát minden szabály bal oldalán kell legyen legalább egy nemterminális elem. 1.3.1. Reguláris nyelvek és véges automaták A véges automata leírása: M( Q, , , q0, F) Ahol: - Q: az automata állapotainak véges halmaza - : az elemzend jelsorozat karakterei - : az automata véges mozgási szabályainak halmaza - q0 az induló állapot, q0 ∈ Q - F az elfogadó állapotok halmaza, F ∈ Q Egy automata leírtnak tekinthet , ha meg vannak adva Q, Például: M ({S, A, B, C, D}, {a, b, c}, , S,{C}) = {(S, a)=A;(S, b)=D;(D,a)=A;(A, a)= A;(A, b) = B; (B, b)=B;(B, c) = C; (C, c) = C}
, , q0 és F.
A véges automatákat irányított gráfokkal szemléltetjük, ami nagyon megkönnyíti tanulmányozásukat. Az el bbi automata ábrázolása:
ábra
14
Reguláris nyelvek és kifejezések A reguláris nyelv tehát olyan nyelv, amelyben A∀a, A∀aB, A∀Ba helyettesítési szabályok lehetségesek. Egy ilyen nyelv egy másik leírási formája a reguláris kifejezés, amely egy formula. Minden reguláris nyelvet le lehet írni egy vele ekvivalens rguláris kifejezéssel, illetve több reguláris kifejezés létezik ugyanaz a nyelv leírására.[2] Például az L={abncm | n>0,m>=0}nyelvet a „a(b)+c* „kifejezés írja le. Ahol + jelentése: pozitív egész szám, nem zéró, a * jelentése pozitív egész vagy zéró is. 2. A fordítóprogram Ha a forrásnyelv egy assembly nyelv és a tárgykód a gépi kód, akkor a fordítóprogramot assemblernek nevezzük. A számítógépek szerepe nap mint nap n . Modern mikroprocesszoros rendszerek találhatók autókban, mikrohullámsüt kben, mobil telefonokban és magán számítógépekben (PC) is. Minden ilyen eszközt be kell programozni ahhoz, hogy m ködni tudjon. Programjaik különböz matematikai tulajdonságokkal rendelkeznek és ennek megfelel en különböz fejlett programozási nyelvekben, vannak megírva. Miel tt a megírt programot feltöltenénk a mikrokontrollerbe, mikroprocesszorba, le kell fordítani az saját utasításkészletére. Ez a “mindennapi” m velet tehát a fordító feladata. Els megközelítésben, egy program létrehozásától annak futásáig a következ lépéseken kell átmennie:
2-1 ábra: Program létrehozásától futásáig való lépések Vannak olyan esetek is, amikor nem ilyen egyszer az átvitel a forrás illetve a tárgynyelv program között. Sok esetben nem létezik fordító a két nyelv között, mivel például túl nagy a távolság köztük. Ilyenkor több lépésben történik a fordítás, több különböz nyelvek között. Ekkor azt mondjuk, hogy a fordítóprogram n menetben végzi el a fordítást. A fordítóprogramok szerkezete A fordítóprogram feladata egy forrásnyelv program tárgyprogrammá alakítása. Figyelembe kell vegye, hogy lehetnek hibák, a legtöbb esetben vannak is. Ilyenkor nem az a mi elvárásunk, hogy a fordító kiakadjon. Feladata tehát nemcsak a fordítás, hanem a fordítás különböz lépéseir l, ennek eredményér l való minél pontosabb tájékoztatás. Struktúrája:[3] Compiler(forrásnyelv program)(tárgyprogram, lista) Ebben a jelölésben a bemenetet az els zárójelben, a kimenetek a másodikban lev adatok jelentik. A lista nevezet kimenet egy olyan elem, amelyben a fordításról, fordítás eredményér l vannak adatok. A compilert továbbá felbonthatjuk finomabb
15
részekre, funkcionális egységekre. Ebben az esetben a compiler az el bb említett compiler bels magja lesz, ami csak a fordítással foglalkozik. Mivel a forrásnyelv program háttértárolón van, szükséges ennek a beolvasása. Ezt a m veletet az úgynevezett input-handler végzi, amely továbbá kiemel más, további m veletek elvégzésére szükségtelen karaktert, mint például a CR(kocsi vissza), LF(sorvégjel) stb. Formája: Input-handler(forrásnyelv program)(karaktersorozat) A forrásnyelv programban talált hibákról a programozót értesíteni kell. Ennek eredményét sok esetben háttértárolóra kell írni. Ezt a m veletet az outputhandler végzi. Output-handler(forrásnyelv program, hibák)(lista) A compiler által készített tárgykódot is tárolni kell háttértárolón. Ezt a kódhandler végzi. Kód- handler(tárgykód)(tárgykód program) Az input-handlert és az output-handlert hasonló bemenetük miatt egy programba be lehet s ríteni, a source-handlerbe. Source-handler(forrásnyelv program, hibák)( karaktersorozat, lista) Összegezve, a fordítóprogram struktúrája a következ képen ábrázolhatjuk:
2-2 ábra: A fordítás általános struktúrája Eddig úgy tekintettük a compilert mint egy egységes doboz, de valójában compilert két nagy részre osztjuk: analízis és szintézis. Az analízis az els lépése a fordításnak. Meghatározza az egyes szimbolikus egységeket, konstansokat, változókat, kulcsszavakat, szintaktikai elemeket stb. Feladatát három nagy részre oszthatjuk: lexikális elemzés, szintaktikus elemzés és szemantikus elemzés. A szintézis, amely a második része a compilernek, az inputként kapott tárgykódot szintetizálja és a különböz részek értelmezésének következtében felépíti a program teljes kódját. Feladata két nagy részre oszlik: kódgenerálás és kódoptimizálás. Az eddig felsoroltakból arra a következtetésre lehet jutni, hogy a fordítás öt lépésb l megvalósítható. Valóságban ez szinte egyáltalán nincs így. Például az IBM 16
els PL/I kompilere több mint öt menetb l állt, de olyan fordítók is léteznek, amelyek a fordítást akár egy lépésb l elvégzik. A lépések számát meghatározzák: - a kompiler számára rendelkezésre álló memória - méret és sebessége - a tárgyprogram mérete és sebessége - hibajavítási lehet ségek - hibajavítási, felismerési stratégiák - a compiler megírására rendelkezésre álló id stb. A következ ábra egy általánosan elfogadott fordítási struktúrát mutat be.
2-3 ábra: A fordító általános struktúrája [6]
17
2.1. Analízis Ez a rész feltördeli a bemenetként kapott karaktersorozatot és egy grammatikát feleltet meg neki, hogy meghatározza az egyes szimbolikus egységeket, konstansokat, változókat, kulcsszavakat, szintaktikai elemeket stb. A felismert struktúrából létrehoz egy átmeneti megjelenítési formát, ami könnyebben értelmezhet a fordító számára. Ha az analizálás folyamán valamely rész nem ismerhet fel teljesen vagy nem felel meg a grammatikának, hibák vannak. Ezekb l a hibákból üzenetek jönnek létre, hogy a programozó javítási m veleteket tudjon véghezvinni. A következ kben az analizálás általános részeinek az elemzése lesz kifejtve, lehet ségek, problémák illetve ezeknek a megoldása. 2.1.1. Lexikális elemz Az analízis egyik legegyszer bb m velete a lexikális elemzés. Alapvet feladata a bemenetként kapott karaktersorozatban a szimbolikus egységek felismerése, amely a szimbólum szövege illetve típusából, két jól elkülöníthet részb l áll. A szimbolikus egységeket pontosan le lehet írni reguláris kifejezésekkel. A legtöbb programozási nyelv tetsz legesen sok fehér karaktert(space, tab) enged meg a különböz egységei között. Mivel ezeknek a karaktereknek csak a programozó szemében van jelent ségük, általában formai, és a további lépésekben semmi szerepük nincs, a lexikális elemz feladata kisz rni. A CR és LF a source-handler sz ri. A lexikális elemz létrehozásának lépései: - megkeressük azt a reguláris nyelvtant, ami leírja a forrásnyelvet, illetve a lexikális elemz nek inputként beérkez szimbólumsorozatot - létrehozzuk a reguláris nyelvtannal ekvivalens determinisztikus véges automatát - elkészítjük az automata implementációját Az implementálása a determinisztikus véges automatáknak egy nagyon egyszer m velet, gyakorlatilag switch-case utasítások sorozata. Minden case az automata egyik állapotának a megfelel je. Fontos megjegyezni azt, hogy az elemz egy szimbólumot a lehet leghosszabbnak vesz. Például ha az elemz találkozik a string szóval, akkor nem str és ing szavakként fogja felismerni ezeket, hanem az elvárt string-ként. Ugyan így ha a strings szóval találkozik, nem string és s részeket fogja felismerni, hanem a strings-et. Az már nem az feladata, hogy eldöntse, hogy ez helyes-e vagy nem. A lexikális elemzés egy másik feladata, hogy például egy felismert konstans értéket átalakítson egy egyszer bb ábrázolási formára. Például a string szócskának megfeleltethet egy S bet t vagy egy számot stb. Egy szimbólumhoz természetesen kiegészít információk is tartoznak, ezek tárolására általában egy szimbólumtáblát használnak. Egy pointer mutat a szimbólumtábla egy bejegyzésére, ahol a többi információ van. Tekintsünk például egy feltételes módú részt: A szimbólumok kódjai legyenek: if then else azonosító konstans =
51 52 53 10 15 20 18
:= ;
21 22
Legyen a programsor: if time=100 then next:=1 else next:=2; A lexikálisan elemzett sorozat: 51 10-0001 20 15-0002 52 10-0003 21 15-0004 53 10-0003 21 15-0004 A 0001..0004 számok a szimbólumtáblázatba való bejegyzésekre mutató pointerek. Vannak olyan esetek, amikor a szimbólum szövegéhez nem tartozik hozzá minden karakter ami segít ennek az értelmezésében. Például a karakterlánc esetén “Ez egy string” csak az Ez egy string alkotja a szimbólumot. Nem tartoznak ide a kezd és végkarakterek (“). A lexikális elemz kimenetét, a szimbólumsorozatot arra is fel lehet használni, hogy a kódból visszaállítsuk az eredeti forrásnyelv programot szépen, rendezett formában, fehérkarakterekkel ellátva. Általános problémák 1) Kulcsszavak és standard szavak A kulcsszavak olyan azonosítók, amelyek nem átértelmezhet k. Hasonló ehhez a standard szavak esete, azzal a kivétellel, hogy jelentésük megváltoztatható egy nyelven belül. Mindkett jük kezelése hasonló módon történik. A legégszer bb, ha mindkett t speciális kezd és végkarakterekkel látjuk el. Általános kezelésük: 1. Minden ilyen szót egy reguláris kifejezéssel írunk le, automatát szerkesztünk hozzá. Hátrányuk, hogy nagyméret programot kapunk. 2. Külön táblába írjuk a kulcsszavakat, illetve standard szavakat, majd amikor az elemz talál egy azonosítót, akkor megnézi, hogy benne van a kulcsszavak illetve standard szavak táblázatába. Ha igen, akkor ez az azonosító egy kulcsszó illetve standard szó, ha nem, akkor a felhasználó által definiált azonosító. A keresés sebessége függ a táblázat felépítési módjától. Standard szó esetében azt eldönteni, hogy a megtalált szó az eredeti jelentésében van használva, vagy át volt értelmezve a felhasználó által, nem a lexikális elemz feladata, hanem a szintaktikus elemz é. 2) El reolvasás Mivel a lexikális elemz a legtöbb karakterb l álló szimbólumsorozatot igyekszik felismerni, a szimbólum jobboldali végpontjának a meghatározására gyakran több karaktert is el re kell olvasni. Ez olyan esetekben látszik mint például a Fortran nyelv DO kulcsszava, ahol a DO 5 K=13.5 és DO 5 K=13,5 között a különbség az, hogy az els esetben értékadás( DO5K= 13.5), míg a második esetben a szokásos ciklikus utasításról van szó. Ilyen esetben a reguláris kifejezést úgy alkotjuk meg, hogy bevezetünk egy el reolvasási operátort, ami segít eldönteni, hogy az éppen analizált karakterlánc hozzárendelés vagy ciklus akar lenni. Például a mi esetünkben: „DO/(D|L)*=(D|L)*,” Ez azt jelenti, hogy el re kell olvasni bet ket és számokat, „=” 19
jelt, majd újból bet ket és számokat ahhoz, hogy el tudjam dönteni, hogy éppen mir l van szó. Az el reolvasás méretét a programozási nyelv leírásából meg lehet határozni. A modern programozási nyelveknél általában egy, két karakterr l van szó, azonban pesszimista esetben négy karakter el reolvasása is szükségessé válhat. 3) Hibakezelés Ha a lexikális elemz találkozik egy olyan karaktersorozattal, amelynek nem tud megfeleltetni egy szimbólumot sem, akkor azt mondjuk, hogy lexikális hiba van. A lexikális hibák nagy része gépelési hiba, vagyis hiányzik egy karakter, rossz karakter van beírva, néhány karakter fel van cserél dve stb. Az elvárt viselkedési mód az lenne, hogy ne álljon meg az els hiba után a fordítás, minél több hibát kéne észrevegyen egyetlen fordítási lépésben. Ennek több megoldása is létezhet, azonban minden esetben kell adjon hiba üzenetet, de lehet séget is a továbbfordításra. Egy általános fordító esetében megjelen hibák egy plusz karakter beütése, például then helyett thexn, vagy változó-1 közül kimaradó - jel. Mivel az én esetemben ilyenek nem fordulhatnak el , további információt a megadott könyvészetben kell keresni.[3][4] 2.1.2. Szintaktikus elemz Olyan programnyelvi tulajdonságok elemzését végzi amelyek CF nyelvekkel írhatók le. Feladata eldönteni, hogy egy szimbólumsorozat a nyelv egy mondata vagy sem. Legyen G(N, , P,S) Alapfogalmak: - mondatforma(α): S *α, ahol α∈(Σ ∪ N) - mondat(x): S *x, ahol x∈(Σ)* - részmondat(β részmondata α-nak): α=α1βα2 egy mondatforma és létezik A∈N úgy hogy S *α1Aα2 és A *β - egyszer részmondat(β részmondata α-nak): hasonló az el z höz, csak A β - nyél: egy mondatforma legbaloldalibb egyszer részmondata Egy mondat szintaxisfájának levelei a nyelvtan terminális szimbólumai, a gyökere pedig a kezd szimbóluma (S). A nyelvtanok lehetnek nemegyértelm , illetve egyértelm nyelvtanok. A fordítóprogramok csak egyértelm nyelvtanok által generált nyelvek fordítását végzik. Más követelmények a nyelvtannal kapcsolatban: 1. ciklusmentes legyen: tehát A +A bármely A∈N esetén 2. redukált: ne legyen benne felesleges nemterminális szimbólum, tehát minden nemterminális szimbólum el kell forduljon legalább egy szintaxisfában. A szintaktikus elemz feladata tehát a bemenetként kapott szimbólumsorozat megfelel szintaxisfájának el állítása. Ha ez sikerül, akkor azt mondjuk, hogy a program szintaktikusan helyes. A szintaxisfa el állítása több féle képen lehetséges: 1. felülr l lefelé haladó elemzés: amikor a mondatszimbólumból kiindulva építjük fel a szintaxisfát. Ezt f leg didaktikai célból készült fordítók esetén alkalmazzuk. 2. alulról felfelé elemzés: a levelekb l kiindulva haladunk a mondatszimbólum felé. Nagyrészt ezt használják a bonyolultabb fordítók. 20
Az elemzés lehet továbbá jobbról balra, illetve balról jobbra való elemzés. A jobbról balra való elemzés azt jelentené, hogy az elemzend forrásnyelv programot a program végét l kezdve elemeznénk el re haladva, a balról jobbra elemzés esetén az írás irányában haladunk. Általában ez utóbbit használják. Felülr l lefelé haladó elemzés A szintaxisfa mondaszimbólumából kiindulva vezetjük le a szintaxisfát, balról jobbra való levezetéssel. Az els pozitív, részleges választ akkor tudjuk megadni arra vonatkozóan, hogy a mondatot lehetséges-e levezetni a mondatszimbólumból, ha megtaláltuk azt a mondatformát, amelyben az els néhány karakter már a mondat els része. Amíg tehát nem ismerjük a legbaloldalibb terminális szimbólumát, nem tudunk mondani gyakorlatilag semmit. Ennek tudatában bevezetjük a következ fogalmakat: - legbaloldalibb helyetesítés: ha létezik A α∈P akkor a xAβ β mondaforma legbaloldalibb helyetesítése xαβ - legbaloldalibb levezetés: ha az S *x levezetésben mindig a legbaloldalibb helyettesítést használtunk, akkor ez a levezetés a legbaloldalibb levezetés lesz A továbbiakban, a levezetésekben mindig legbaloldalibb levezetést alkalmazok. A felülr l lefelé elemzésnek egy megoldása az, hogy levezetjük az összes lehetséges szintaxisfát, és megnézzük, hogy a levelek sorozata kiadja-e a mondatot. Ez természetesen id igényes feladat. A jobb megoldás az, hogy kiindulunk a mondatszimbólumból és legbaloldalibb helyettesítésekkel, figyelembe véve a mondatot, megpróbáljunk alkotni a szintaxisfát. Természetesen egy adott pillanatban az alkalmazott helyettesítés nem garantálja azt, hogy ez a pillanatnyilag helyes megoldás. Ezért ha eljutunk egy bizonyos ponton oda, hogy a mondattól eltérünk, nem biztos még, hogy hiba van, hanem visszalépünk egy fels bb szintre és ott más szabályt alkalmazunk. Végigjárva az összes lehetséges lépést biztosan megkapjuk a mondatot, ha ez eleme a nyelvnek. Ha nem akkor hiba van. Vannak olyan nyelvtanok, amelyek esetében egy adott helyettesítési lépésben egyértelm en el lehet dönteni, hogy a levezetés folyamán éppen melyik az alkalmazandó helyettesítési szabály, vagy esetleg nincs olyan szabály, amely teljesíti a feltételeket. Ezt az elemzési módszert visszalépés nélküli elemezésnek nevezzük. El nye, hogy nagyon felgyorsítja a fordítást. LL(k) nyelvtanok Alaptulajdonsága, hogy ha S *wx legbaloldalibb levezetés építésekor eljutunk az S *wAβ mondatformáig és az Aβ *x-et akarjuk elérni, akkor az A-ra alkalmazható A α helyettesítést egyértelm en meghatározhatjuk ha ismerjük az x els k darab szimbólumát. First k(α α) = {x|α *xβ és |x|=k}∪ {x|α *x és |x|
21
2.1.2-1 ábra: Followk(β) LL(1) nyelvtan Olyan LL(k) nyelvtan, ahol k=1. Ez azt jelenti, hogy a még nem elemzett szimbólumsorozatból el reolvasva egy szimbólumot, meg lehet határozni, hogy melyik helyettesítési szabályt kell alkalmazni. A világon a fordítóprogramok többsége LL(1) nyelvtanokon alapuló elemzési módszereket használ. El nyük, hogy könny ek és átláthatóak, de f ként didaktikai célokra használandó fordítókban implementálják. A másik 20%-ot a LALR(1) nyelvek teszik ki. Az LL(1) nyelvtanok esetén megkülönböztetünk: - egyszer LL(1) grammatikát: a helyettesítési szimbólumok jobboldala páronként különböz terminális szimbólummal kell kezd djön, ε mentes kell hogy legyen(A ε szabály ne legyen) - ε mentes LL(1) grammatika: az ε mentesség melett egy másik feltétel, hogy az A α1|α2|..|αn esetén First(αi) ∪ First(αj)=∅ ha i≠j - er s LL(1) nyelvtan: A α1, α1 *ε és First 1(α1)∩ Follow1(A)=∅, 1≤ j ≤ n, i≠j LL(1) elemzés Táblázattal: - vezessük be a legjobboldalibb szimbólumnak a # szimbólumot - a helyettesítési szabályokat sorszámozzuk meg - tekintsünk egy vermet, amelynek az alján legyen a # szimbólum - legyen egy lista amely tartalmazza a szabályok sorszámát - az elemzés állapotai: (ay#, Yα#, v) ahol ay# a még nem elemzett szöveg, Yα# az elemzés mondatformájának még nem elemzett része, v a szabályok sorszámát tartalmazó lista
22
A táblázat elemeit a következ képpen t ltjük ki:
{(bβ , i) ha M [ X , b] =
X → bβ az i − dikhelyettesítés pop ha X = b accept ha X = b error egyébként
2.1.2-2 ábra: Az elemz szerkezete
A kitöltési szabály els sora változik az LL(1) nyelvtan kategória függvényében. A táblázat egy lehetséges formája:
2.1.3-1 ábra Ábra Rekurzív leszállás módszere: - a nyelvtan szimbólumaihoz eljárásokat rendelünk - külön procedúrát írunk az accept és error eljárások megvalósítására - next_simbol az el reolvasást, a lexikális elemz t megvalósító eljárás. Eredményét a actual_simbol nev változóba tölti.
procedure accept(simbol) begin if actual_simbol = simbol then next_simbol; else error(...); end procedure A()
begin if A a then accept; else if A B then B; else if A A1A2 then A1;A2; end
23
Lentr l felfelé haladó elemzés Ide tartoznak az LR(k) nyelvtanok amelyek közül a leghasználtabb az LR(1) nyelvtan. A napjainkban használt, úgymond valódi fordítók nagy része LR(1) nyelvtanok szerinti nyelveket fordítanak. A lentr l felfelé haladó elemzések esetében legjobboldalibb levezetéseket végzünk. Minden LR(k), k>1, nyelvtanhoz létezik vele ekvivalens LR(1) grammatika.[3]. 2.1.3. Szemantikus elemz Azon programnyelvi követelmények, amelyek nem írhatók le CF nyelvekkel, sztatikus szemantikához tartoznak. Általában a következ tulajdonságokat vizsgálják: - változók deklarációja és a változók hatásköre, láthatósága - változók többszörös deklarációja - operátorok és operandusaik közötti típus-kompatibilitás - procedúrák, tömbök formális és aktuális paraméterei közötti kompatibilitás - túlterhelések egyértelm sége Általában külön programrészletet írnak minden egyes szemantikus tulajdonság vizsgálatára. Nagy segítség a szimbólumtábla jó tervezése. Mivel a mi esetünkben nincs szükség szemantikus elemz re ezért ezzel továbbá nem foglalkozok. 2.2. Szintézis A szintézis két nagy részb l áll, a kódgenerálás illetve a kódoptimalizálás. Sok esetben nem ennyire szétválasztva és egyszer en, hanem ezeknek a keveréke, vagy ismételt, egymás utáni egybeágyazása, végrehajtása alkotja, amint azt a 2-3 ábrán is láthatjuk. 2.2.1. Kódgenerálás Sok esetben a kódgenerátor kimenete egy közbels programformának tekinthet . Lehet számítógépt l és az operáció rendszert l független speciális kód, vagy akár fejlett programozási nyelv kód, de legtöbb esetben a gépi kód. A program kódjának felépítésére több módszere létezik. Ezek közül a legfontosabb az aktivációs rekordot alkalmazó módszer. Mivel a feladatunk nem kér ennyire bonyolult kódgenerálást, nem térek ki ennek részletes bemutatására. 2.2.2. Kódoptimalizálás Az optimalizálás célja, hogy a generált kód min sége javuljon, vagyis csökkenjen a program végrehajtási ideje, illetve a mérete. Sok esetben nem választják teljesen külön a kódgenerálást a kódoptimalizálástól, hanem párhuzamosan végzik ket. Az optimalizálással szemben támasztott legfontosabb követelmények a biztonság, vagyis eredménye nem térhet el az optimalizált kód eredményét l. Sok esetben ezért az is el fordul, hogy a kódoptimalizálás rontja a program min ségét. Másrészt a kódoptimalizálás lehet gépfügg , amikor például jobb regiszter felhasználással gyorsítjuk a program futását, avagy gépfüggetlen, amikor olyan stratégiákat alkalmazunk, amelyek függetlenek a kódot végrehajtó környezett l. Az én programom esetében nem használok külön kódoptimalizálást, azonban ha a fejlesztések során nem LAD C, hanem LAD gépi kód, vagy LAD assembler fordítóra térek át, akkor ennek kihagyása nagy hátrányokkal járhat.
24
3. LAD fordító gyakorlati megvalósítása 3.1 Bevezet A LAD szócska a Ladder Logic szavak rövidítéséb l származik. Ladder Logic – Létralogika, az áramútterv grafikus megvalósítása. Jelentése különböz ikonok, jelek segítségével való programírás. A LAD programozást vezérlési rendszerek logikájának a leírása, de f ként a PLCk programozására használják. A PLC-k a relés vezérlések kiváltására készültek, de a tudományuk itt nem állt meg. A gyakorlati alkalmazások számtalan példája azt mutatja, hogy a PLC programokban nem csak azokat a funkciókat valósítják meg amit a hagyományos huzalozott vezérlések valósítanának meg (ugyanarra a feladatra értve), hanem sokkal többet. A Létralogikát tehát sokat használjak PLC-k programozására, példák erre akar a legnagyobb cégek: a Siemens amely a saját PLCire áramuttervel való programozását a SIMATIC Manager(STEP7) nev programmal teszi lehet vé, míg a legnagyobb ellenfele a Moeller cég, az Easy soft nevezet programmal végzi a saját PLCinek a programozását. Más ilyen programok a Omron, Mitsumishi (GX-Developer), Allen Bradley (RSLogix), Modicon, Unitronics OPLC, Telemecanique és még sokan mások, lásd [11] Nemcsak a nagy cégek készítenek LAD logikát lehet vé tev programokat, hanem sok más cég illetve magán személy is, természetesen ez utóbbiak inkább didaktikus célból készülnek, illetve, hogy b vítsék a GPL licensz programokat. A LAD nyelvet az IEC 1131-3 standard irja le. Ez a standard a PLC-k programozásával foglalkozik. 3.2 Követelmény specifikáció Egy olyan rendszer elkészítése a cél, amelyen keresztül a felhasználók grafikus környezet segítségével programozni tudnak valamennyi PLC-t. A grafikus környezet létralogikán, más szóval létra diagramon (LAD) alapszik. Ez azt jelenti, hogy a feladatot áramútterv alapján készíti el a felhasználó. A program írása közben a felhasználó információt kap a program helyességér l. Megtudhatja, hogy a különböz operátorok kaptak-e elegend paramétert illetve ezek megfelel ek-e. A felhasználónak lehet ség nyúlik egy adott PLC-re nemcsak programot írni, hanem az írt programot szimulálni és betölteni a PLC-be. Egy másik különlegessége a rendszernek, hogy lehet ség van b víteni a programot más PLCkre, illetve más PIC-ekre alapuló PLC-re, különböz csomagok hozzáadásának a segítségével. A rendszer használatához nem szükségesek jogosultságok. Bárki használhatja, aki hozzáfér, azonban egyszerre csak egy felhasználó programozhat a program segítségével, illetve ez a felhasználó egyszerre csak egy projektet készíthet. Lehet ség nyílik továbbra a projektek lementésére megnyitására, a lementési könyvtár El feltételek(preconditions): - windows környezet - legalább egy csomag feltelepítése. Megjegyzés: 1 csomag 1 PLC-t jelent.
25
3.2.1 Követelmények elemzése, definiálása A rendszer felhasználóinak a típusa: User (felhasznaló)
A rendszernek a következ funkciókat kell ellátnia: - program írás - program lementés - program visszaolvasás - program fordítás - program szimulálás - program betöltése - csomag hozzáadása A használati esetet a felhasználó indítja el, amikor elindítja a programot. 3.3. A PLC-k architektúrája A PLC egy programozható irányítóberendezés. Nem PIC, nem mikrovezérl , hanem egy készülék mikroprocesszorral (esetleg mikrovezérl vel) ki és bemenetekkel, kommunikációs porttal. A PLC-ket els sorban az iparban használják, gépek, berendezések, gyártósorok vezérlésére. Digitális (két állapotú) és analóg ki és bemenetei vannak, amelyek iparban szabványos jelek fogadására és kiadására alkalmasak. (gyakori digitális jelek: 24V DC, 24V AC, 120/230V AC, gyakori analóg jelek: 0-10V, 0-20mA, 4-20mA, 0-5V, h elemek, ellenállás h mér k). A digitális kimenetek közvetve vagy közvetlenül a berendezés beavatkozó szerveire kapcsolódnak mint például a mágnesszelepekre, villanymotorokra stb. A digitális bemenetek a berendezés részeinek állapotáról (végállás kapcsolók, pozíció, érzékel k, fotocellák) vagy kezel szervekr l jöv jeleket fogadnak (kapcsolók, nyomógombok). Az analóg bemenetek mér jeleket fogadnak (nyomás, áram, feszültség, h mérséklet, áramlás, stb). Analóg kimenetek alkalmasak fokozatmentes szabályozó-beavatkozó szervek meghajtására (frekvenciaváltók, proporcionális szelepek, f t teljesítmény meghatározása, stb). A PLC legfontosabb tulajdonságai, hogy valamilyen magasabb szint programozási nyelven programozható, gyakorlatilag minden vezérlésben és szabályozásban használt szabványos ipari jelhez közvetlenül illeszthet , vagy van már kész megoldás az illesztés fizikai megvalósítására. Saját, bels operációs rendszerrel rendelkezik, ami felügyeli a bels perifériákat és a b vít modulok m ködését, a kommunikációt (ha van), futtatja a felhasználó vezérl programját, és valamilyen szinten kezeli a hibákat. Felépítését tekintve kétféle PLC-t szoktak megkülönböztetni: - Kompakt: Minden egyben van. A PLC tartalmazza a tápegységet, van be és kimenete, kommunikációs csatlakozója. Általában van b vítési lehet ség is, ha a beépített ki és bemenetek száma nem lenne elég. Egy gyártónál is rendszerint sokféle altípusa létezik különböz I/O számmal és fajtával. Kisebb feladatokra használják, ahol kicsi az I/O igény. - Moduláris: A komplett PLC részegységekb l (modulokból) építhet fel. Van egy CPU, ami lényegében maga a vezérl , de ki és bemenetek nélkül. Ehhez
26
lehet különböz tápegységeket, ki és bemeneteket tartalmazó modulokat választani, amelyek egymáshoz csatlakoztatva adják a kész konfigurációt. Ezzel a megoldással a PLC konfigurálható az adott feladatra. Használható kevés, de nagyon sok ki és bemenet, vagy speciális modul. A közepes és nagyobb teljesítmény PLC -kre jellemz ez a kialakítás. 3.3.1. A PIC18F452 mikrovezérl re fejlesztett PLC architektúrája A PLC egy kompakt rendszer, 8xDI, 8xDO, 4xAI, 2xAO, billenty zettel és kijelz vel. A bemutatott PLC processzora egy PIC18F452 - 8 bites mikróvezérl . M szaki jellemz k:
Tápfeszültség .................................................................................... 24VDC Felvett áram .......................................................................................250mA Digitális bemenetek ..................... 8DI, +24VDC, galvanikusan leválasztott Digitális kimenetek .....................8DO, +24VDC, galvanikusan leválasztott Analóg bemenetek ..................................... 4xAI, 0...20mA vagy 0..10VDC Analóg kimenetek .......................................... 2xAO, 0..20mA és 0..10VDC Kijelz .................................. LCD, 4x20 karakter, háttérvilágítás, kontraszt Állapot LED-ek...................................................... 4 LED a kezel felületen Billenty zet ..............................12 billenty ,10 szám + 2 kontrol + funkcók Kommunikáció.....................................................................RS232 interfész A rendszer kiterjeszthet még 8 digitális be- illetve kimenettel. A kezel felület:
3.3.1-1 ábra A PLC kezel felülete
A kezel felület felépítése: - Kijelz LCD 4x20 karakter - Billenty zet 12 billenty vel - Állapot LED-ek a következ funkciókkal: • 5V – tápfeszültsék jelenlét 27
• • •
ERROR – hiba állapot, piros szín SHIFT – a billenty zet másodfunkciós üzemmód ONLINE – nincs használva
3.3.2. Hasonlóságok és különbségek más PIC alapú PLC-kkel Általában változik a kezel felület és f ként a PIC-el kapcsolatos adatok, mint például a tápfeszültség, a felvett áram illetve a ki-és bemenetek számai, ennek feszültségei stb. A program fordítása szempontjából érint a ki-bemenetek száma ezek elhelyezkedése a memóriazónába, a memóriazóna méretei és helye, amelyeket fel lehet használni mint memóriazónák a programban. Egy másik fontos dolog, ami változhat a különböz mikrovezérl knél az az utasításkészlet. Ezt a fordító utolsó része, a kódgenerátor veszi majd figyelembe.
28
3.4 Tervezés 3.4.1. Felhasználói esetek (Use case diagram) A következ kben az egyes használati esetek forgatókönyveit, illetve a használati eset diagramot tárgyalom. A program futása a felhasználó kezdeményezésekor indul: elindítja a programot. A program indítása után két lehet ség van a programozás elkezdésére. Az egyik az, hogy egy új projektet hozunk létre, a másik, hogy megnyitunk egy régebbi, el z leg megírt projektet. Az új projekt létrehozása egy új csomag, illetve a PIC megadásával történik. A különböz PIC-ek esetén változik a lehetséges m veletek típusa és száma. A program írása közben egy interpreter ellen rzi a beadott adatokat(vagy nem). A PIC kiválasztásakor (PIC choose) egy ablak jelenik meg, ahol egy listából történik ennek a kiválasztása. Megjelennek a különböz PIC-ekhez tartozó információk is. Egy régi projekt megnyitása(Open project) a grafikus környezeteknek megfelel szokásos módon történik, tehát megadható a projektig vezet út, grafikusan. A program írása (write program) a kiválasztott PIC-nek megfelel en, az ehhez hozzátartozó, m veletek sokaságával lehetséges. A m veletek, operációk, megjelennek a grafikus felületen, egy különálló egységben, és a drag and drop-nak megfelel en m ködnek. Az ikonok egy másik ablakrészbe kerülnek át a drag and drop m velet után. A programozási ablakba nem kell berakni a sorkezdet szimbólumot, ezt magától beteszi, ha egy bizonyos sorban megjelenik egy m velet. A programírás közben lehet ség nyílik a program lementésére (Save project) is, kés bbi megnyitás céljából. A szokásos, grafikus felületeknek megfelel képen történik a lementés. Lehet ség van lementeni újból a régi név alá, vagy más nevet adni neki. Ha a program úgy lenne lekapcsolva, hogy nem volt lementve a projekt, akkor újból lehet ség adódik ennek a lementésére. A programozási ablakrészbe tett operációknak vannak paraméterei. Ezeket egy másik ablakrészben kell megadni. Itt táblázatos formájában jelennek meg a különböz paraméterek, paraméter névvel illetve értékkel ellátva. A felhasználó itt adhatja meg az operációk paramétereinek értékeit, amelyek interpretálva (interpreted) vannak. Tehát ha az érték nem felel meg formailag a követelményeknek, akkor azt nem fogadja el a program, hiba üzenetet ír ki a Status Bar-ba, ha jó akkor egyszer en elfogadja. Ez utóbbira nem tesz megjegyzést. A program megírása után lehet ség adódik a program lefordítására (compile). A fordítás eredménye megjelenik az ablakban, szöveg formájában. Jelzi a sorokat, ahol a hibák vannak, és a vélt hibát, hibákat (error handling). A vélt hibák természetesen nem feltétlenül a valós hibák. A felhasználó a megjelölt hibák kijavítása után, újból tehet fordítási kísérletet. Ez addig megy, amíg sikerül teljesen kijavítani a hibákat. Ekkor megtörténik a teljes fordítás, amelyr l a felhasználó üzenetet is kap. A fordítása az ikonoknak (operációknak), amelyeknek nyelvi szempontból természetesen egy egy szócska felel meg, ANSI C nyelvre történik. Minden PIC esetén más más formális nyelv írja le annak a m ködését. Általános esetben egy PICnek megfelel formális nyelv a következ :
G(N,Σ,P,S), ahol N ={ 29
S, Zone, ONR, INR, MNR, OutNr, InNr, MemNr, OBytSize, IBytSize, MBytSize, Z, Y, U, P, B, G, F, K }:nem terminálisok Σ={ set, reset, upedge, downedge, open, close, and, nand, ;, Q, I, M, q, i, m, ., 0..32767 }:terminálisok P={ S → <set> Zone <;> |
Zone <;> | Zone S | <downedge> Zone S | Zone S | Zone S | Zone S | Zone S |<;>
Zone → ONR | INR | <M>MNR | ONR | INR | <m> MNR ONR → OutNr<.>OBytSize INR → InNr<.>IBytSize MNR → MemNr<.>MBytSize OutNr → Z|YZ|10Z|11Z|12U (0..127-ig) Z → 0|1|2|..|9 Y → 1|2|..|9 U → 0|1|2|..|7 (ertelmi kulombsegek vannak U/B kozott) P → 0|1|2|3|4|5 B → 0|1|..|7 G → 0|1 F → 0|..|6 K → KZ|Z InNr → 0|1|..|7 MemNr → KY|YZ|YZZ|YZZZ|1ZZZZ|2ZZZZ|3GZZZ|32FZZ|327PZ|3276B 0|1|..|32767 IBytSize → Z|1P (0..15) OBytSize → Z|1P (0..15) MBytSize → B ---------------------------------------------------------------------------------------------<set> → set → reset → upedge <downedge> → downedge → open → close → and → nand <;> → ; → Q → I <M> → M → q → i <m> → m <.> → .} 30
S = {S}
Amint azt észre lehet venni, a tervezett nyelvtan LL(1) nyelvtan, vagyis egy karakter el reolvasásával meg tudja állapítani, hogy a sorra következ szimbólum melyik szimbolikus egység kezdete lehet. Ha nem találja a további karakterekben meg ezt a szimbolikus egységet, akkor azt jelenti, hogy hiba van. Példa: S → Zone S | <set> Zone <;> | <;> Zone → ONR | INR | <M>MNR Jelentése: - a mondat kezd dhet and szóval, amit követ egy zóna. Ez lehet kimeneti (ONR) bementeti (INR) vagy memória (MNR) zóna. A zónák alatt értünk egy byte-ot és egy bittet. A zóna után jöhet egy új egység, ami egy másik operációt ír le, a saját paramétereinek az értékével. - a mondat végén szerepelhet csak a set szócska, ezt a zónája után lev <;> jelzi. A <;> a mondat végjel szimbólum.
3.4.1-1 ábra: A LAD fordító használati eset diagramja
31
A: MemNr → KY|YZ|YZZ|YZZZ|1ZZZZ|2ZZZZ|3GZZZ|32FZZ|327PZ|3276B 0|1|..|32767- nek a leírása formálisan. A különböz PIC-ek esetében változhat az operációk száma, hány byte tartozik egy ki/be illetve memória zónához, tehát változnak a terminálisok és a nem terminálisok illetve a helyettesítési szabályok is. A program lehet séget ad az alapértelmezett könyvtár megváltoztatására. Ez azért fontos, mert ez az a hely, ahova a projekteket menteni lehet alapértelmezetten, továbbá a következ induláskor is ezt a lokációt veszi kiinduló pontnak. Tehát ha egyszer jól beállítottuk az alap könyvtárt, akkor nem kell többet foglalkoznunk vele. A program feltöltése el tt lehet ség adódik a program m ködésének a szimulálására (run simulation). A bemeneti értékeket egy táblázat segítségével lehet megadni. A program ez alapján jeleníti meg a szimuláció eredményét. A beadott értékek lépés függ ek(id pillanatok). Ez el tt természetesen kell kompilálni a programot. Ha úgy gondoljuk, hogy az írott program megfelel az elvárásainknak, akkor ezt akar fel is tölthetjük a PLC-re (upload program). Megjegyzésként talán csak annyi, hogy csak lefordítás után lehet a programot feltölteni a PLC-re. A lefordítás eredménye egy ANSI C forráskód. A feltöltés egy másik program segítségével történik, az MPLAB-al. A program lehet séget ad továbbá más csomagok hozzáadására (add package). Egy csomag egy PIC-re vonatkozó utasítások, fordítási szabályok, ikonok összességét foglalja magába. A csomag el állítója kell ismerje a PIC, illetve a program architektúráját. Egy másik fontos dolog, hogy a csomag el állítója figyelembe kell vegye azt, hogy a PIC-el lehetséges operációk leírása formálisan eleget kell tegyen az LL(1) nyelveknek. Tehát ha nem tenne eleget, akkor azzá kell átírni. Ez azért fontos, mert a fordítás szintaktikus elemzésénél LL(1) nyelv szerint vannak megoldva a szimbólumok felismerései, és ez bizonyos lépések egymásutánját jelenti, ami viszont nem változtatható. Ennek megfelel en azt feltételezzük, hogy egy PIC-re vonatkozó csomagban hiba nem lehet. Ha mégis van akkor arról jelzést kap a felhasználó. A PIC-re vonatkozó csomag: - a) egy package.txt-be vannak tárolva a PIC neve és jellemz i. A PIC nevének a maximális megengedett hossza 50, a jellemz inek a leírása pedig maximum 450 karakterb l valósítható meg.
Például: NÉV
PIC18F452
JELLEMZ K Tápfeszültség: 24VDC Felvett áram: 250mA Digitális bemenetek: 8DI, +24VDC, galvanikusan leválasztott Digitális kimenetek: 8DO, +24VDC, galvanikusan leválasztott Analóg bemenetek: 4xAI, 0...20mA vagy 0..10VDC Analóg kimenetek: 2xAO, 0..20mA és 0..10VDC Kijelzo LCD: 4x20 karakter, háttérvilágítás, kontraszt Allapot LED-ek: 4 LED a kezelofelületen Billentyuzet: 12 billentyu,10 szám + 2 kontrol + funkcók Kommunikáció: RS232 interfész
32
14 bites utasítások, 8 bites adatok, 8 szinto hardver verem, Közvetlen, közvetett és relatív címzési módok, 4 megszakítási forrás: Külsi RB0/INT láb, TMR0 idizíti túlcsordulás, PORTB(74) változása miatt, Adat EEPROM írása kész, 1000 írási/törlési ciklus .....................................
PIC16F84 .... -
b) egy icons könyvtárban vannak az ikonok, tehát e mellé kell tenni a még fel nem installált ikonokat. Kell ügyelni természetesen, hogy egy új ikonnak se legyen ugyan az a neve, mint egy már léz nek, s t a kezd bet je sem lehet ugyan az. Ez utóbbi az LL(1) nyelv megszorítása miatt. Az icons könyvtárban vannak továbbra a parameters.txt-be az ikonok(operációk) paramétereinek száma és típusa. Ezek is névsor szerint vannak rendezve, ezt továbbra is be kell tartani.
-
c) egy pic.txt nevezet állományba be kell helyezni a PIC-hez tartozó parancsokat. Ezek a parancsok névsor szerint vannak elhelyezve, és ez továbbra is meg kell, hogy maradjon. Ezt a program ügyeli fel. Tehát az új csomagban ha nincs is betartva a lexikális sorrend az állományban lexikálisan lesznek.
Mivel a text állományokra nem alkalmaztam semmi féle kódolást, lehet ség van a különböz adatok megváltoztatására, vagy esetleg egyedi hozzáf zésekre. Tehát ha szeretnénk egy adott létez PIC-nek valamely parancsát kijavítani, vagy mást betenni, akkor ez megoldható nagyon egyszer en, mint text állományba való írás. Ennek következtében megtörténhet, hogy hibásan íródnak be adatok, például nem az elvárt lexikális sorrendbe. Ennek hátránya, hogy a program nem tudja kijavítani a hibát, ellenben hibaüzenet jelzi azt, hogy létezik. A további kijavítás teljesen a felhasználó feladata.
33
3.4.2. Osztálydiagram A programban felhasznált osztályok: MainWindow A f ablak osztálya, amely kereteiben történnek a különböz m veletek. Tartalmaz egy-egy mutatót a különböz osztályokra, mint például a PiecesList illetve a PuzzleWidget osztályok. Tartalmaz ezen kívül egy táblázatot is, amelyet adatok bevitelére használunk
3.4.2-1. ábra: Az alkalmazás vezérlését megvalósító osztályok
34
compiler: Ez végzi a forráskód fordítását. Részei ennek megfelel en a lexikális, szintaktikusbelemz k illetve a kódgenerátor. MainWindow A f ablak osztálya, amely kereteiben történnek a különböz m veletek. Tartalmaz egy-egy mutatót a különböz osztályokra, mint például a PiecesList illetve a LadWidget osztályok. Tartalmaz ezen kívül egy táblázatot is, amelyet adatok bevitelére használunk. A f ablakban menük és az ennek megfelel m veletek is tárolva vannak, illetve a többi osztálytól érkez , különböz jelek fogadására létrehozott úgymond signal függvények. myString Egy olyan osztály, amely saját string m veleteket tartalmaz, a létez string osztály egy tovább fejlesztése. A fordítási m veleteket el segít osztály. Lehet vé tesz például olyat, hogy egy adott char*-ban megkeres egy karakter sor-ként megadott karakter csoport tagjait, és visszatéríti azt, amelyiket megkapta. Egy másik hasznos függvénye például a myStrcut_1, amely egy karakter sorozatból áttesz egy másikba egy részt i-t l j-ig. Ui_newprojectForm Az új projekt létrehozásához felhasznált ablak grafikus felülete van itt megvalósítva, primitíven, vagyis mint a projekthez tartozó grafikus felület kompilált változata. NewProjectForm A newprojectForm osztály kiegészítését tartalmazza, vagyis azon m veletek és fügvények összességét, amelyek kiterjesztik a grafikus felület m ködését. Ilyen lehet példaul az, hogy kap egy jelet egy másik egységt l és mit kezdjen vele, vagy ha történik egy billenty lenyomás, akkor azt tovább adja a többi érdekelt, esetleg nem grafikus felületnek is. Ui_newprojectnameForm A projekt nevét megadó ablak grafikus felületének a kompilált változata. NewProjectNameForm A newprojectnameForm osztály, függvényekkel kiegészített változata. Lehet vé teszi nemcsak az állomány nevének a megadását, hanem a lementés helyének a megadását is, az elvárt windows környezetnek megfelel módon. PiecesList Az ablak azon részét ügyeli fel l, amely a különböz darabokat, ikonokat és a hozzájuk tartozó, rájuk vonatkozó m veleteket tartalmazza. LadWidget Az ablak azon részének a grafikus felületét ügyeli felül, amelyben a program írása történik. A fontosabb osztályok diagramja:
35
Mivel az összes osztály diagramjait adataikkal és függvényeikkel együtt igen s r lenne megjeleníteni, a következ kben ábrázolom az összes osztályt, illetve a köztük lev kapcsolatokat. Ahol szükséges, a kapcsolatok megjelenítése miatt, ott néhány attribútumot is megjelenítek.
3.4.3-2. ábra: Tervezési osztály diagram 3.4.3. Objektumdiagram A következ ábrák az objektumok közötti kapcsolatokat mutatja két különböz id ben. Az els két eset egy új projekt létrehozásának lépései. Csak ekkor élnek a project, illetve projectname objektumok, amelyek a NewProjectForm és NewProjectNameForm osztályok egy egy példányai. A harmadik objektum ábra a program futásának egy lépését mutatja be. A PiecesList objektumhoz tartoznak QListWidgetItem objektumok, amelyek a PIC-hez tartozó ikonokat, vagyis a PIC-el végezhet m veleteket tartalmazzák. A Table tartalmazza az ikonhoz tartozó információkat: a paramétereit illetve ezek értékeit.
36
3.4.3-1 ábra: PIC kiválasztásának objektum diagramja
3.4.3-2 ábra: Projekt névadásának az objektum diagramja
Az új projekt létrehozásakor a f ablakon belül egy új ablak jelenik meg. Itt ki kell választani a PIC-et, közben megjelennek ennek a jellemz i, amire írjuk a programot, majd megnyomni a next gombot. A next gomb lenyomásával jóváhagytuk a kiválasztott PIC-et, és megjelenik a következ ablak, ahol a projektnek nevet adhatunk, és kiválaszthatjuk, hogy hova legyen majd lementve. Ha nem választunk, akkor az alapértelmezett könyvtárba ment dik le.
3.4.3-3 ábra: A program futásának az objektum diagramja
37
A PuzzelWidget az ablak egy részlét foglalja magába, amely tartalmazza a PIC-en elvégezhet operációkat, a program m veletsorát. Az operációkat jellemzik a pieceLocations, pieceNrs, piecePixmaps, pieceLine objektumok. Ezek sorra az operációk helyet, az operáció számát, az ikonját illetve a sorát tartalmazzák. 3.4.4 Dinamikus modell 3.4.4.1 Forgatókönyvek A használati esetek szerint a következ kommunikációs modelleket írhatom fel: 1. PIC choose: a felhasználó kiválaszthatja, hogy melyik PIC-re írja a programot.
app → addPics(picname, description) user → chosePic (Pic) app → askProjectName (defaultDirectory) user → setProjectName (projectName, directory) app → addPicIcons (Pic) 2. Open project: a felhasználó egy már meglév projektet nyit ki. user → openProject (actual directory, project name) app → interpret (project file) app → addPicIcons (Pic) 3. Write program: a felhasználó programot ír. user → dragDropIcons(iconName) app → putIconParameters(iconName) user → changeIconParameters() app → checkIconParameters(iconName) 4. Save project: a felhasználó egy gomb lenyomásával lementi a programot, amit írt. A f program értelmezi, majd lementi lexikálisan. user → saveProject(projectName) user → saveProjectAs() app → getDefaultLocation() app → translate(projectName) 5. Interpreter: értelmezi a beadott adatokat, hogy ezek megfelelnek-e formailag a követelményeknek. user → changeData (value, parameter) app → interpret(value, parameter) app → errorShow(error) 6. Compile program: a program lefordítja a LAD kódot.
38
app → compile (projectName) 7. Error handling: az applikáció megjelenít egy hibát a képerny n. app → showError(error) 8. Run simulation: a felhasználó beadja a bementi értékeket a különböz lépésekben. app → showSimulationParameters (operationList) user → setSimulationParametersValue (values) app → simulate (operationList, values) 9. Upload program: egy másik program segítségével a felhasználó elindítja a PIC-be való feltöltést. Megj: ez nem az én programom keretein belül történik. user → upload(compiledProject) 10. Change default directory: a felhasználó kiválasztja az új default directory-t. app → showDefaultDirectory (defaultDirectory) user → chandeDefaultDirectory (newDirectory) app → saveDefaultDirectory (newDirectory) 11. Add package: a felhasználó új csomagot ad a létez k mellé. user → addNewPackage (package) app → addIcons (icons) app → addPicParameters (pic, parameters) app → addPicDescription (pic, description) 3.4.4.2 Kollaborációs diagram A következ kben megpróbáltam ábrázolni a különböz objektumok egymással való kommunikációját egy kollaborációs diagram segítségével. A számozás jelzi egy általános, hibák nélküli, egymást követ lépések sorozatát, a program megírásának menetét. A használt jelölések: - „5: függvénynév”: jelzi az ötödik lépést el idéz függvényt. Sok esetben ezek nem implicit meghívások, hanem üzenetek. - a „→”: jelzi a folyamat irányát - a szaggatott „→”: jelzi, hogy indirekt befolyásolja a következ objektumot. Tehát az adott példában, hogy egy ikont áttéve a LadWidget ablak részbe, kap egy dropEvent jelzést (signal), és nem pedig egy függvényhívás a lépésben el tte lev objektumtól. - „i”: jelzi, hogy a m velet akárhányszor megtörténhet, s t általában többsz r. A mi esetünkben jelzi, hogy a MainWindow objektum több ikont fog neki küldeni. - a „2.1”: kifejezi, hogy ez a m velet is lehetséges a 2-es lépés után.
39
3.4.4.1-1 ábra: A program kollaborációs diagramja
Azért, hogy az ábra ne legyen olyan bonyolult, nem tettem be minden hova a lépésszámnak megfelel m veletet. Ezt a továbbiakban egészítem ki: 1: newProjectFile() 2: onNextButtonPressed() 2.1: onBackButtonPressed() 3: onOkButtonPressed() 4i: addPiece (pixmap, location, icon) i: new (parent) 5: dropEvent (event) 6.1: append (location) 6.2: append (line) 6.3: append (number) 6.4: append (pixmap) 7: onPieceDropped(name, nr, row, column) 8: compile (projectName) 9: result()
40
3.4.4.3. Szekvencia diagram A következ kben két diagramot mutatok be. Az els a projekt létrehozásának szekvencia diagramja, a második a lad program létrehozása.
3.4.4.3-1 ábra: A projekt megnyitásának a szekvencia diagramja
A fenti szekvencia diagram a felhasználó File men , new ...-jának a megnyomásával kezd dik. Ennek következtében a MainWindow létrehozza a NewProjectForm osztály egy példányát. Itt a felhasználó kiválaszt egy PIC-et. Minden PIC kiválasztás esetén küld egy jelzést a MainWindow-nak. A felhasználó ha döntött egy bizonyos PIC mellett, akkor a next button-al tovább lép. A next gomb megnyomásakor egy jelzés történik a MainWindow-nak, aminek hatására bezárja a
41
NewProjectForm példányát, és létrehoz egy NewProjectNameForm példányt. A felhasználónak lehet sége van vissza lépni az el z oldalra. Ezt a back gombbal teheti meg. A back gomb megnyomásakor a NewProjectNameForm példány küld egy üzenetet a MainWindow-nak. Ez megszünteti t, illetve újból indít egy NewProjectForm példányt. Az next gomb megnyomásával visszakerül az el z állapotba. Ekkor végre nevet adhat a projektjének, és megadhatja a helyet is ahova le szeretné menteni, természetesen, ha ez különbözik a default-tól. A névadás eredménye elküld dik a MainWindow-nak. Amikor a felhasználó Ok gombot nyom, egy új üzenet indul a MainWindow felé, ami bezárja a NewProjectNameForm példányt, és betölti a létez PieceList példányba a PIC-hez tartozó ikonokat, amint azt a következ szekvencia diagramon látható. 3.5. Implementáció 3.5.1. Bevezet Az els fontos döntés a programmal kapcsolatban az volt, hogy milyen nyelven írjam meg, a másik pedig az, hogy milyen grafikus környezete legyen. A nyelvvel kapcsolatban dönt nek az bizonyult, hogy melyik programozási nyelven van a legtöbb tapasztalatom, hogy melyik programozási nyelv engedékenyebb, illetve, hogy melyik támogatná esetleg az eddigi tervezést. A grafikus felület tekintetében a grafika szépsége, a felület kezelhet sége, követhet sége volt a mérvadó, illetve az, hogy platform független legyen. Mivel a két rész, mármint a fordítás, mint háttérben futó operáció, és a grafikus felület, összeköthet is legyen, a nyelv és grafikus felület választása szorosan köt dött egymáshoz. A választás ennek következtében a C nyelvre esett, illetve a grafikus felületet megvalósítani segít környezet a QT grafikus elemkönyvtár. 3.5.2. A QT grafikus elemkönyvtár A Qt a Trolltech cég által létrehozott grafikus widget-készlet, amely els sorban a több platformon történ fejlesztés miatt lett közkedvelt. Elérhet a különféle Unix, Linux, Windows és Macintosh rendszereken, s t már a beágyazott (embedded) eszközökre is elkészült, Qtopia néven. Sajátossága még a licence, amely nyílt forráskódú rendszerek készítésekor ingyenessé teszi a használatát. Alapjában véve három féle licencr l beszélhetünk. Az egyik a „commercial license”, ami mindent megenged, tartalmaz példákat, azok leírásait, forráskódjait és a helpet. A trial licenc ad egy 40 napos próba periódust az eszközök használatára, adja ugyanazokat a példákat, csak minden indításakor a helpnek, a példáknak illetve a programnak, amiben használjuk az osztályait, kiteszi a saját reklámját f ablakként, és nem lehet látni, mi van a hátánál. A harmadik licenc az ingyenes, ennek a hátránya csak hogy a vele készült programok ugyancsak nyílt forráskódúak kell legyenek illetve nincsenek példaprogramok azon megvalósításaikkal. A Qt-vel készült például az Opera webböngész , illetve a Borland cég Kylix nev fejleszt eszköze. 2006 közepét l már Java fejlesztésre is használható .A nyílt forráskódú felhasználások közül a legjelent sebb talán a KDE Desktop Environment.
42
3.5.3. QT jellegzetességek QTben minden programhoz tartozik egy projekt állomány, amely tartalmazza a program által használt állományokat. A mi esetünkben:
# A programban használt header állományok HEADERS += compiler.h \ defines.h \ usefull.h\ mainwindow.h \ myString.h \ newproject.h \ newprojectname.h \ pieceslist.h \ ladwidget.h # A programban használt user interface állományok FORMS += newproject.ui newprojectname.ui # A programban használt forrás állományok SOURCES += compiler.cpp \ usefull.cpp\ main.cpp \ mainwindow.cpp \ myString.cpp \ newproject.cpp \ newprojectname.cpp \ pieceslist.cpp \ ladwidget.cpp Az ui (user interface-felhasználói interface) állományok és a qmake eszköz létrehoz makefile szabályokat, hogy meghívja az uic-t, a QT felhasználói interface kompilert. Így jön létre az Ui_formName osztály, amely tartalmazza a grafikus felületen megszerkesztett rész C program változatát. A QT egy másik jellegzetessége a signal és slot típusú vezérlés. Ez lehet vé teszi, hogy a programozó összekössön objektumokat, anélkül, hogy ezek ismernék egymást. Elég, ha egy fels bb egység ismeri mindkett jüket. A SLOT-ok hasonlítanak a szokásos C++ tagfüggvényekre (member functions). Lehetnek virtuálisak, felülírhatóak, privát, lehetnek paramétereik, meg lehet hívni ket direkt módon stb. A különbség az, hogy hozzá lehet kötni ket signalokhoz. Ez azt jelenti, hogy automatikusan meg lesz hívva, ha kiadjuk a neki megfelel jelzést. A kett jük közötti összekötés a következ képen néz ki: connect(sender, SIGNAL(signal), receiver, SLOT(slot));
3.5.4. Általános méretbeli korlátozások Mivel egyik f célom az általánosítás volt, szükségszer en be kellett vezessek néhány korlátot. Ezek a következ k:
#define PIC 50
: pic maximális neve
43
#define PICDESCRIPTION 450 : pic leírásának maximális hossza #define PROJECTNAME 30 : project maximális neve #define PICMAXICONS 50 : egy PIChez tartozó maximális ikon szám #define MAXICONNAME 20 : egy ikon maximális neve #define MAXICONPARAMETERS 10 : ikon max paramétereinek száma #define MAXICONPARAMETERNAME 20 #define MAXICONPARAMETERLINE MAXICONNAME+MAXICONPARAMETERS*MAXICONPARAMETERNAME : maximális megengedett ikonok száma egy sórban #define MAXELEMENTSONWIDGET 50 #define MAXCOLUMNSONWIDGET 20 #define MAXROWSONWIDGET 20 #define XPEACE 80 : a felületen a X léptéke #define YPEACE 100 : a felületen a Y léptéke A defines.h állományban találhatóak. Ha úgy találjuk, hogy a méretek nem elegend ek, akkor ezeket meg lehet változtatni. A programban mindenhol általánosan vannak meg. 3.5.5. Saját típusok Mivel egy ikonhoz több információ tartozik, ésszer ezeket az információkat valamilyen szinten összekötni. Ennek következtében az ikonok tárolására létrehoztam a következ típust:
typedef struct ic{ char name[MAXICONNAME]; unsigned char parameterNr; char parameterList[MAXICONPARAMETERS][MAXICONPARAMETERNAME]; }icon; Tartalmazza az ikon nevét, paramétereinek számát, és magukat a paramétereket. Ez azért fontos, hogy a felhasználónak egyszer legyen az operációhoz tartozó paraméterek beadása. A location (hely) típus, megadja, hogy egy bizonyos operációikon hol van. Jellemz i a sor, oszlop, és az operáció száma. Megjegyzésként, hogy az operációikon nem jellemez teljesen egy operációt, hanem ennek a száma. Ezeket a számokat a PiecesList osztja ki, amikor egy ikon példány elhagyja a listáját. typedef struct loc{ int nrofop; int row; int column; }location; Egy másik fontos típus a picOp típus, amely egy operációhoz tartozó jellemz ket tartalmazza magában. Ez az el bbi icon és location típusokhoz tartozó adatok illetve a paraméterek értékeinek a vektora. E típushoz tartozik még egy operator = = függvény, amely a QT listáiban az összehasonlításokhoz, megtalálásokhoz kell.
44
typedef struct operations { icon aboutIcon; location poz; char parameterListValue[MAXICONPARAMETERS][MAXICONPARAMETERNAME]; operator== (operations op){ return op.poz.nrofop == poz.nrofop; } }picOp; 3.5.6. Osztályok deklarációi A legfontosabb osztály a MainWindow osztály, ami a vezérlést végzi. F bb metódusai és attribútumai: class MainWindow : public QMainWindow { Q_OBJECT
public:
MainWindow(QWidget *parent = 0);
public slots: void setupLad(); void onNextButtonPressed(); void onPicListWidgetCklick(int); void onBackButtonPressed(); void onProjectNameChanged(const QString &); private slots: void setCompleted(); void onPieceDropped(QString &name,int nr,int row,int column); void onOkButtonPressed(); void onValueModified(int,int); void newProjectFile(); void open(); bool save(); bool saveAs(); bool description(); bool addPackage(); void simulation(); bool compiling(); bool download(); void def(); void clear(); void about(); private: unsigned char picNr; 45
char picname[PIC]; void setupMenus(); void setupWidgets(); bool newProject(); void addProjectName(); void setNewProject(); void updateParameterList(picOp &p); void createActions(); void createMenus(); void createStatusBar(); bool loadFile(const QString &fileName); bool saveFile(const QString &fileName); QString currentDir; QString defaultDir; char projectname[30]; QLabel *messageLabel; QLabel *valueLabel; icon icons[PICMAXICONS]; QList picoperations; int iconNr; int actualOperationItem; // File menu QMenu *fileMenu; QAction *newAction; QAction *openAction; QAction *saveAction; QAction *saveAsAction; QAction *exitAction; ............... QPixmap puzzleImage; PiecesList *piecesList; LadWidget *ladWidget; QTableWidget *table; compiler *compile;
}; class PiecesList : public QListWidget { Q_OBJECT public:
PiecesList(QWidget *parent = 0); void addPiece(QPixmap pixmap, QPoint location,icon I);
46
protected: int takenPiece; void dragEnterEvent(QDragEnterEvent *event); void dragMoveEvent(QDragMoveEvent *event); void dropEvent(QDropEvent *event); void startDrag(Qt::DropActions supportedActions); }; class LadWidget : public QWidget {
Q_OBJECT
public:
signals:
LadWidget(QWidget *parent = 0); void clear(); void setStartIcon(QPixmap); void puzzleCompleted(); void pieceDropped(QString &,int,int,int); void pieceDoubleClicked(int);
protected: void dragEnterEvent(QDragEnterEvent *event); void dragLeaveEvent(QDragLeaveEvent *event); void dragMoveEvent(QDragMoveEvent *event); void dropEvent(QDropEvent *event); void mousePressEvent(QMouseEvent *event); void paintEvent(QPaintEvent *event); private:
};
int findPiece(const QRect &pieceRect) const; const QRect targetSquare(const QPoint &position) const; QList piecePixmaps; QList pieceRects; QList pieceLocations; QList pieceLine; QList pieceTypes; QList pieceNrs; QRect highlightedRect; int inPlace; QPixmap startIcon;
47
class compiler{ public: private:
compiler();
int lexical(int argc, char *argv[]); void hiba(unsigned char db, FILE *f); void h(FILE *f,char sor,char oszl,unsigned char db); void beMeretek(unsigned int v[][2]); // szepsegert void baytmeret(char S[],char i,unsigned int sor,unsigned int oszlop,FILE *fout2,unsigned M[][2],char tip,FILE *fout1) void pont(char S[],char i,unsigned int sor,unsigned int oszlop,FILE *fout2,unsigned M[][2],char tip,FILE *fout1) void meret(char S[],char i,unsigned int sor,unsigned int oszlop,FILE *fout2,unsigned M[][2],char tip,FILE *fout1) void parancs(char S[],char i,unsigned int sor,unsigned int oszlop,FILE *fout2,unsigned M[][2],FILE *fout1) void tipusok(FILE *fin,FILE *f1,FILE *f2,char sor,char oszl,char tipus,unsigned M[][2],char s[]); void fuggvenyek(FILE *fin,FILE *f1,FILE *f2,char sor,char oszl,char tipus[],unsigned M[][2],char s[]);
int int int int int int
};
3.5.7. Hibakezelés A kompilátor esetében a hibakezelés alatt az elemzend programban el forduló hibát értem. Ezek megjelenítésére egy általános függvényt használok, amely tartalmazza az összes lehetséges hibát:
void compiler::hiba(unsigned char db, FILE *f) { switch(db) { case 0: fprintf(f,"opciok.txt file hiba\n");break; case 1: fprintf(f,"Argumentum hiany\n");break; case 2: fprintf(f,"Nem jo bemeneti zona\n");break; case 3: fprintf(f,"Nem jo bemeneti bajt\n");break; case 4: fprintf(f,"Nem jo kimeneti zona\n");break; case 5: fprintf(f,"Nem jo kimeneti bajt\n");break; //........... } } A programban van hibakezelés, ami azt jelenti, hogy olyan hibákat is lekezel, amik elméletileg nem kellene létezzenek. Ilyenek például az, hogy nincs meg a picdescription.txt vagy az icons könyvtárban valamelyik .png stb. Ezekre mind jelzéseket kapunk. Például: QMessageBox:: information(this, tr(error), tr("The error message"),QMessageBox::Ok); 3.5.8. Az elemzés menete Az általam választott nyelv grammatikája egyszer LL(1) grammatika. Ez azt jelenti, hogy nincsenek A → ε helyettesítési szabályaim, illetve, hogy egy szimbólum el reolvasásával meg tudom határozni, hogy melyik szimbolikus egységr l van szó.
48
Az elemzések sorrendje: az ikonokat átírom nyelvi formába, lementem, majd a fordító elemzésnek teszi alá. El ször a lexikális elemz értelmezi a hibákat, majd egy állományba írja. A szintaktikus elemz a lexikális elemz kimenetét és a hibák állományát kapja bemenetként. A talált hibákat az hibák állomány végére teszi. A következ lépés a kódgenerátor. Az kimenete a C állomány. A fordítás után az egy állományba került hibák a sorok szerinte (amelyben találva voltak), sorrendbe teszi, majd közli a felhasználóval. 4. Eredmények és összehasonlítások 4.1. Eredmények A következ kben a megvalósítás eredményeit ismertetem: 1) Program indítása után: Az els lépés a PIC kiválasztása vagy egy régi, el z leg lementett program kinyitása. A PIC kiválasztása a számomra rendelkezésre álló PLC és a PIC leírása alapján történik. Ezt a 4.1-1 ábra mutatja. A másik lehet ség a program kezdésekor a projekt megnyitás, amit a 4.1-2 ábra mutat.
4.1-2 ábra: Megnyitás
4.1-1 ábra: Kiválasztás
2) A projekt nevének adása: Itt lehet ség van nemcsak a program nevének a megadására, hanem a hely megváltoztatására is, ahova a projekt le lesz mentve. Ezt a következ ábrán láthatjuk:
4.1-3 ábra: A projekt nevének megadása
49
3) A program megírása: Egy példaprogram a következ képen néz ki:
4.1-4 ábra: Egy példa program
A jobboldali felén vannak a használható ikonok, a baloldalon pedig a program írása történik. Az alsó részben a különböz ikonokhoz tartozó paraméterek nevei illetve értékei találhatók. Amikor egy ikont átviszünk a listából (jobboldalról) a programozási felületre, akkor legalul, a Status Bár-ba megjelenik annak a neve. Szimuláció esetében ugyancsak az alsó részben jelennek meg a bemeneti adatok. 4) A program fordítása: A Tools menü egy parancsa a fordítás. Ha vannak hibák akkor megjelennek az ablak alsó felében.
4.1-5 ábra: A fordítás
50
5) A program feltöltése: Az MPLAB software-el történik. El ször lefordítja gépi kódra, majd kiküldi a PLCnek. Példa A következ kben egy olyan példaprogramot mutatok be, amit végig is viszek a különböz lépéseken.
A program írása után a lementett projekt állomány (test2.lad) a következ képen néz ki: PIC18F452 and I0.0 set Q0.0; and I0.1 set Q0.1; Ennek jelentése, hogy: -1 sor: a PIC neve amire íródott a program - további sorok jelentése: ha a 0-s byte 0-s bitjén logikai 1 jelenik meg akkor a kimenet 0-s byte 0-s bitjén is jelenjen meg a logikai 1-es.
4.1-6 ábra: LAD program
A lexikális elemz kimenete: sQ(0).(0);sQ(0).(1) A szintaktikus elemz kimenete: sQ0.0;sQ0.1 A kódgenerátor kimenete, a létrehozott C kód: #include #include "DigitalIO.h" #include "MainProgram.h" #include "ConvFunct.h" #include "delaysmy.h" #define FALSE 0 #define TRUE 1 #pragma romdata CONFIG // ****** Configuration bytes ****** rom const unsigned int config_word1 = 0xF2FF; rom const unsigned int config_word2 = 0xFEF0; rom const unsigned int config_word3 = 0xFFFF; rom const unsigned int config_word4 = 0xFFFB;
51
rom const unsigned int config_word5 = 0xFFFF; rom const unsigned int config_word6 = 0xFFFF; rom const unsigned int config_word7 = 0xFFFF; #pragma udata access UNear near unsigned int AnalogIN_0, AnalogIN_1, AnalogIN_2, AnalogIN_3; near DI01 DigitalIN_0; near DI02 DigitalIN_1; near DO01 DigitalOUT_0; near DO02 DigitalOUT_1; #pragma udata access UNear near unsigned char I2CStatus; near unsigned char DelayCounter1,DelayCounter2; near unsigned char RcvDataCounter, RcvData[5]; near unsigned char USARTData[10], USARTCount, RefIExt, RefUExt; near unsigned char TimerValue; near unsigned char Timer10ms, RampEnable; near char SendEnab; near unsigned int I_Ref2PSPWM, U_Ref2PSPWM; near unsigned long AnnealingTimeCounter, TimeTemp,ActRefValue,RampTimerCounter; near unsigned int IdleCounter; near unsigned int REFI, REFISEL, UMAX, RAMPU, REFUSEL; near ConvStates STATECONV; near Errors ERROR; #pragma code low_vector = 0x018 void low_interrupt(void) { _asm goto LOW_INT_HANDLE _endasm; } #pragma code #pragma code high_vector = 0x08 void high_interrupt(void) { _asm goto HIGH_INT_HANDLE _endasm; } #pragma code void InitCPU(void) { WDTCONbits.SWDTEN = 0; //initialization Input/Output Ports initialization // Port A ADCON1 = 0x89; TRISA = 0xFF; PORTA = 0x00;
// Set Port A pins AN0,AN1,AN4,AN5-analog // all inputs
// Port B INTCON2bits.RBPU = FALSE; PORTB = 0x00; TRISB = 0xFF;
// Turn on the Port B pullups // Clear PORT B data latch // Set all bits as inputs
52
// Port C PORTC = 0x00; TRISC = 0x80;
// Clear PORT C data latch
PORTD = 0x00; TRISD = 0xFF; PORTE = 0x00; TRISE = 0x01;
// Set the RE0 input for analog input
// INT 0 (external interrupt) // INTCON2 &= 0x80; INTCONbits.INT0IE = FALSE; INTCON3bits.INT1IE = FALSE; INTCON3bits.INT2IE = FALSE;
// Set for falling edge detection // Make sure that INT 0 interrupt is disabled // Make sure that INT 1 interrupt is disabled // Make sure that INT 2 interrupt is disabled
// Timer 0 TMR0L = 58; T0CON = 0b11000111; INTCON2bits.TMR0IP=0; INTCONbits.TMR0IE = FALSE;
// General timing // 1ms // 8bit,T0Clock = Internal,PRESCALER = 256 // Low priority interrupt // Make sure that Timer 0 interrupt is disabled
// Timer 1 // T1CON = 0x00; PIE1bits.TMR1IE = FALSE;
// Prescaler = 1x (-> 1 tick = 0.92us), timer is off // Make sure that Timer 1 interrupt is disabled
// Timer 2 PR2 = 255; T2CON = 0x04; TMR2 = 0x00;
// This will get us a 19KHz PWM period // Prescaler = 1x, timer is on // Reset the timer - not really important for a PWM
//
// CCP1 (Compare) CCPR1L = 0x00; CCP1CON = 0x0C; PIE1bits.TMR2IE = FALSE;
// This will get us a 0% PWM duty cycle // CCP1 is in PWM mode // Make sure that Timer 2 interrupt is disabled
// CCP2 (PWM) CCPR1L = 0x00; CCP2CON = 0x0C; PIE2bits.CCP2IE = FALSE;
// CCP2 module set to PWM mode // Make sure that Compare 2 interrupt is disabled
// EEPROM EECON1bits.EEPGD = FALSE; INTCONbits.GIE = FALSE; }
// Set access towards the data EEPROM, not the program // flash // disable interrupts
/*****************INTERRUPTS ***************/ #pragma interrupt HIGH_INT_HANDLE void HIGH_INT_HANDLE(void) { } #pragma interruptlow LOW_INT_HANDLE
53
void LOW_INT_HANDLE(void) { } /*************** MAIN PROGRAM *****************/ void main(void) { DigitalOUT_0.DO01=0; DigitalOUT_1.DO02=0; DigitalIN_0.DI01=0; DigitalIN_1.DI02=0; InitCPU(); DigitalIN_0.DI01=ReadDigitalInput1(); DigitalIN_1.DI02=ReadDigitalInput0();
//Reads the digital inputs
DigitalOUT_0.DO01 = DigitalIN_0.DI01; sDigitalIN_1.DI02 = DigitalIN_1.DI02; WriteDigitalOutput1(DigitalOUT_0.DO01); WriteDigitalOutput0(DigitalOUT_1.DO02);
//Writes the digital outputs
}
4.2. Összehasonlítások A f bb cégek, amelyek lehet séget adnak LAD programozásra, a Siemens illetve a Moeller cégek. A Siemens cég SIMATIC Manager nev programja talán a legelterjedtebb, hazánkban f ként. Lehet vé tesz LAD (Ladder Logic – Létra logika, az áramútterv grafikus megvalósítása), STL (Statment List – assemblerhez hasonló programozás) és FBD (Function Block Diagram – Digitális elektronikában használt kapukhoz hasonló eszköztárral rendelkezik. Itt feszültségszintek felelnek meg a logikai szinteknek) nyelveknek való programírást. Egy másik nagy cég a Moeller cég, amely méltó vetélytársává vált a Siemens cégnek az utóbbi években. A Moeller Easy, kis kategóriás, de nagy tudású logikai modul, kijelz vel és gombokkal. Inkább az egyszer bb automatizálási rendszerekben használják, ezért az én programom inkább ez utóbbival hasonlítható össze. Az Easy szoftverek tartalmazzák az egyes PLC-családokhoz tartozó készülékek teljes hardver dokumentációját, valamint a szoftverek kezelését is. Az Easy Soft a windows alapú operációs rendszereken fut: WIN NT 4.0 SP6tól, Windows 2000 SP4, Windows XP SP1 stb. Nincs linuxon vagy más operációs rendszeren futó változata. Jellegzetességei: - megfelel az IEC(nemzetközi standard) kapcsoló és tekercs - megfelel az ANSI (Amerikai standardnak) - nem ingyenes a software
54
Egy példa a Moeller cég EASY-SOFT programjára:
4.2-1 ábra: Példa egy Easy Soft programmal megírt LAD program
Összehasonlítás:
Jellegzetesség
Moeller Easy Soft
Operációs rendszer Windows alapú
LAD Manager
Nem OP függ . M ködik windows, linux, MAC stb. Licensze Nincs ingyenes verzió Ingyenes Kezel felület Barátságos Baratságos M veletek Nagyon sok m velet, sok PLC-re Kevés m velet, kevés PIC sokasága alapú PLC-re B víthet ség Pénz függvényében új software Bármikor b víthet , ha családnak megfelel en elkészült a megfelel csomag Más szükséges Nincs MPLAB, ingyenes programok Dokumentáció Van Van
55
Amint a táblázatból kiderül vannak el nyei és hátrányai az én programomnak a Moeller cégéhez képest. Ez természetes is, figyelembe véve azt, hogy nem ugyanannyi volt sem a rendelkezésre álló id , sem pedig a programozók száma. Az interneten rendkívül sok LAD fordító létezik. Ezek közül megemlítem a Jonathan Westhues által megírt LDmicro nevezet programot, amely PIC16-os család számára írt fordító (PIC16F877, PIC16F876, PIC16F628-okra teszteltek, illetve a PIC16F88, PIC16F819-ra nem teszteltek)[14]. F bb különbségei az általam írt programhoz képest, hogy nem C, hanem hex állományt generál, nem lehet b víteni, illetve a programozási felülete dos-os felület. El nyei a LAD Manager-el szemben, hogy több m veletet tud, azonban ezeket sem lehet b víteni. Egy példa egy LDmicro programmal készített LAD programra:
4.2-2 ábra: Az LDmicro program
Jellegzetesség
LDmicro
Operációs rendszer Windows alapú
LAD Manager Nem OP függ . M ködik windows, linux, MAC stb.
56
Licensze Kezel felület M veletek sokasága B víthet ség
Ingyenes Dos-os, nem annyira barátságos Sok m velet, kevés PLC-re Nincs lehet ség
Más szükséges Nincs programok Dokumentáció Van
Ingyenes Baratságos Kevés m velet, kevés PIC alapú PLC-re Bármikor b víthet , ha elkészült a megfelel csomag MPLAB, ingyenes Van
Az internetten több más ezer ilyen fordító létezik. Általános jellemz rájuk, hogy nem fektetnek hangsúlyt a grafikai felületre, illetve a program b víthet ségére. Ennek következtében én ezekre a dolgokra fektettem inkább hangsúlyt, és nem arra, hogy megírjak minden elképzelhet m veletet, ugyanis a b vítés, lehet séget ad bármikor egy adott PIC-el kapcsolatos m veletek illetve más PIC-ek hozzáadására. 5. Következtetések és tervek 5.1. Következtetések Sikerült megvalósítani a célkit zéseket, vagyis a fordító elkészítését. A kompilátor tervezésének lépésein végighaladva megvalósítottam az én feladatomnak megfelel specifikus lexikális, szintaktikus elemz ket illetve a kódgenerálást. A dokumentálódás folyamán és tervezés lépesein végigmenve rájöttem, hogy az alkalmazásomnak nem szükséges a szemantikus elemzés megírása, illetve a kódoptimalizálás. Ez utóbbi inkább akkor lett volna szükséges, ha LADr l assembler nyelvre fordítottam volna, vagy gépi kódra. Ennek eredménye képen elkészítettem a LAD Manager programot, amely lehet ségei között megemlítem a beadott adatok, ikonok értelmezését, állományok lementését, visszaolvasását. Képes továbbá szimulálni a programot, a hibákat megjeleníteni stb. A programozott szimbólum sorozatot átalakítja formális nyelvé, majd ezt a kompilátor segítségével átalakítani C kóddá. Az MPLAB programmal létre lehet hozni a gépi kódot, amit majd elküld a PLC-nek. 5.2. Jöv beli fejlesztési tervek A lehetséges m veletek kiterjesztése, ennek megfelel en valószín , hogy nem lesz elég már az LL(1) nyelvtan, hanem ki kell terjeszteni LL(2)-re például, de nem csak ez a lehet ség van természetesen. Egy másik fontos lépés lenne a programba való beintegrálása a számítógépPLC kommunikációnak. Ehhez azonban kell egy C→ gépi kód típusú fordító is, vagy a fordítás teljesen LAD-r l (az ennek megfelel formális nyevr l) gépi kóddá legyen.
57
IRODALOMJEGYZÉK:
[1.]
Bach Iván: Formális nyelvek, Typotex Kiadó, 2001
[2.]
Csörnyei Zoltán, Kása Zoltán: Formális nyelvek és fordítóprogramok, Kolozsvári Egyetemi Kiadó, 2007
[3.]
Csörnyei Zoltán: Fordítási algoritmusok, Ábel könyvkiadó, 2000
[4.]
Csörnyei Zoltán: Bevezetés a fordítóprogramok elméletébe I, Tankönyvkiadó,
[5.]
Niklaus Wirth: Compiler Construction, 2005: http://www.oberon.ethz.ch/WirthPubl/CBEAll.pdf
[6.]
Alfred V. Aho, M. S. Lam, R. Sethi, J. D. Ullman: Compilers Principles, Techniques, and Tools second edition. AddisonWesley, 2007
[7.]
Alfred V. Aho, R. Sethi, J. D. Ullman: Compilers: Principles, Techniques, and Tools. Addison-Wesley, 2001
[8.]
Wikipedia: http://en.wikipedia.org/wiki/Compiler
[9.]
Jasmin Blanchette; Mark Summerfield: C++ GUI Programming with Qt 4, Second Edition, Prentice Hall, 2008
[10.]
Harald Störrle: UML 2 (Unified Modeling Language), Panem Könyvkiadó Kft., 2007
[11.]
http://szirty.uw.hu/lang/index.html
[12.]
http://www.hik.hu/tankonyvtar/site/books/b10110/index.html
[13.]
http://cq.cx/ladder.pl
[14.]
Microchip – C18 C Compiler User’s Guide
58
