VISION X 9 Folyamatmegjelenítő rendszer

PROVICON Irányítástechnikai és Informatikai Kft.

VISION X 9 Folyamatmegjelenítő rendszer

1 2 3 4 5 6 7 8 9

Általános leírás Projektek Változók

Dokumentáció

Képek, képszerkesztés Kommunikáció Események kezelése Adatbázis kezelés Adatgyűjtés Hálózat kezelés Programozás, az XSDL nyelv alapjai Jogosultságok, felhasználó kezelés

Függelék

Rendszerkonfiguráció

PROVICON Kft.

Video megjelenítés Driver interfész VISION X Szimbólumok H-1047 Budapest, Batthyány u. 19.

Tel: + 36 1 231-0513

Fax: + 36 1 370-5415

http://www.provicon.hu

10 11 12 A1 A2 A3

[email protected]

VISION X9 Folyamatmegjelenítő Rendszer 1989-2007 Előszó Miben különbözik az X-sorozat a VISION program korábbi változataitól? Sok mindenben. Az X változat elsősorban a belső objektum-szerkezet és a bővíthetőség tekintetében változott, miközben megőrizte nemcsak a kompatibilitását, de a rendkívüli funkcionalitását is, ami a VISION 7 és 2000 változatra volt jellemző. A program új változata a komponens alapú megközelítést támogatja, sokféle új megjelenítési funkcióval, képek, taszkok önálló indításának a lehetőségével, Web-szolgáltatásokkal és számos új objektummal, valamint szolgáltatással. A programfejlesztés során a legkorszerűbb eszközöket alkalmaztuk (Delphi 7és 8 .NET, ill. Delphi 2005) és olyan objektum-szerkezetet alakítottunk ki, amely a tetszés szerint skálázható, moduláris programrendszerek magas igényeit elégíti ki. Arra törekedtünk, hogy a piaci kereskedelemben kapható program-komponenseket (editor, syntax elemzők, OPC browser, Lon eszközök, hálózati komponensek, installációs programok, stb.) beépítsük a rendszerbe – kerül, amibe kerül. A rendszer új programozási nyelve az XSDL (Extensible Structure Declaration Language), ami a magasszintű, objektum orientált programozási nyelvek összes szolgáltatását biztosítja (többdimenziós tömbök, egymásba ágyazott struktúrák, tipusok, halmazok, objektumok, eljárások, függvények, tulajdonságok, metódusok, öröklések, stb.) A programozók számára azonban megkönnyíti az áttérést, az XSDL-ben megkonstruált, már megszokott VAL nyelv, amit az új rendszerben XVAL-nak hívunk. Az új pogram gyorsabb, mégis kisebb; kevésbé terheli a processzort, viszont támaszkodik a grafikus kártyánk szolgáltatásaira. Az önálló megjelenítője tehát gyorsabb lett, de az aktív komponensre épülő Web-es megjelenítő sebessége is a párját ritkítja. A rendszer teljesen 32bites, de már 64-bites programmodulok is helyet kaptak benne, a 64 bites változókat pedig már a 32-bites környezetben is használhatjuk. A program tervezésénél alapvető követelménnyé lépett elő a design és a program kezelhetősége, vagyis a program-ergonómia. A letisztult koncepció és az egységes fájlrendszer is ezt a célt szolgálja, csakúgy, mint a Windows-ban ma már megszokott, intézőre épülő projekt-támogatás. Az X rendszerben a projektek összes komponense grafikusan szerkeszthető, beleértve a kommunikációt, az alarmrendszert és az adatbázis kezelést is – mintha csak képeket rajzolnánk. A legérdekesebb különbségek azonban még csak nem is ezek, hanem az alkalmazásfejlesztés megközelítésének a felhasználóhoz sokkal közelebb álló és a fejlesztést is megkönnyítő módja. Mielőtt ezeket részletesen is bemutatnám, engedjék meg, hogy e dokumentumban külön is köszönetet mondjak mindazoknak a kollégáknak, felhasználóinknak, akik tanácsaikkal, javaslataikkal segítették a program új, minden eddiginél hatékonyabb szolgáltatásainak a megalkotását. Nélkülük most nem élvezhetnénk ezek előnyeit. Gurka Tibor

Általános leírás

1

Tartalomjegyzék: 1. Bevezetés ............................................................................................................................................................ 6 1.1. Rendszerszemlélet az alkalmazásfejlesztésben ........................................................................................... 6 1.1.1. Csoportosítás, könyvtárak.................................................................................................................... 7 1.1.2. Strukturális megfontolások.................................................................................................................. 7 1.2. Információs rendszerek ............................................................................................................................... 8 1.3. Dokumentum vezérlés................................................................................................................................. 8 1.4. Egyszerűbb, áttekinthetőbb fájlrendszer...................................................................................................... 8 1.5. Önfejlesztő képesség ................................................................................................................................... 9 1.6. Kulcstulajdonságok ................................................................................................................................... 10 1.7. Fontosabb szolgáltatások........................................................................................................................... 11 1.7.1. Teljeskörűség..................................................................................................................................... 11 1.7.2. Kompatibiltás, platform-függetlenség, verziókövetés ....................................................................... 11 1.7.3. On-Line programszerkesztési szolgáltatások..................................................................................... 11 1.7.4. Nyelvfüggetlenség, nemzetközi projektek készítése ......................................................................... 11 1.7.5. Grafikai szolgáltatások ...................................................................................................................... 12 1.7.6. Hálózati szolgáltatások, telefonvonalas hálózatok ............................................................................ 13 1.7.7. Adatbázis kezelés .............................................................................................................................. 14 2. VISION Installáció ........................................................................................................................................... 15 3. VISION Projektek............................................................................................................................................. 16 3.1. Projekt lista................................................................................................................................................ 16 3.2. Projekt indítása.......................................................................................................................................... 17 3.3. Projekt menedzser ..................................................................................................................................... 18 3.3.1. Képek felépítése és részei.................................................................................................................. 19 3.3.2. Kezeléssel kapcsolatos általános tudnivalók ..................................................................................... 20 3.4 Projektek részei, az alkalmazás-fejlesztés fázisai....................................................................................... 21 3.4.1. Projekt konfiguráció .......................................................................................................................... 21 3.4.2. Struktúrák .......................................................................................................................................... 22 3.4.3. Változók ............................................................................................................................................ 22 3.4.4. Ciklikus programok ........................................................................................................................... 25 3.4.5. Alarm programok .............................................................................................................................. 25 3.4.6. Szervízek ........................................................................................................................................... 26 3.4.7. Kommunikáció .................................................................................................................................. 26 3.4.8. Adatbázisok ....................................................................................................................................... 27 3.4.9. Képek................................................................................................................................................. 28 3.4.10. Ablakok (overdraw) ........................................................................................................................ 29 3.4.11. Sablonok .......................................................................................................................................... 29 3.4.12. Jelentések......................................................................................................................................... 30 3.4.13. Szimbólumok................................................................................................................................... 30 3.4.14. Könyvtárak ...................................................................................................................................... 31 3.4.15. Bitmapek.......................................................................................................................................... 32 3.4.16. Függőségek...................................................................................................................................... 33 3.4.17. Unitok .............................................................................................................................................. 35 3.4.18. Külső programkapcsolat .................................................................................................................. 36 3.4.19. Erőforrások ...................................................................................................................................... 37 3.4.20. Információs rendszerek.................................................................................................................... 37 3.4.21. Csatolt dokumentumok.................................................................................................................... 38 3.4.22. Saját súgó......................................................................................................................................... 38 3.4.23. A VISION rendszer származtatása .................................................................................................. 39

PROVICON 2005.08.26.

VISION X általános leírás

5

1. Bevezetés

1

A VISION folyamatmegjelenítő rendszer új változata, az X-sorozat, egyike a leggyorsabb, legalkalmazkodóbb és grafikailag leglátványosabb objektum-orientált programoknak a teljeskörű megoldást kínáló folyamatmegjelenítő rendszerek között. A VISION X korlátlan skálázhatósága nemcsak új változók, képek, jelentések, stb. online bevitelét, módosítását teszi lehetővé, de új változótipusok és rendszerkomponensek kifejlesztését is. A VISION X-ben a legkorszerűbb komponensek és számítástechnikai megoldások kaptak helyet. A program új, magas szintű programozási környezete, az XSDL (Extensible Structure Declaration Language) az elterjedt programnyelvek összes szolgáltatásával rendelkezik (többdimenziós tömbök, strukturált tipusok, eljárások, függvények, objektumok, tulajdonságok, metódusok, események, öröklések, stb.). Ráadásul ugyanazon a magas szintű nyelven konfigurálható az összes rendszerkomponens – grafikusan vagy szövegesen. A VISION X az első megjelenítő rendszer, amely egységes konfigurációs nyelvi környezetet biztosít az összes komponens számára, legyen az kép, kommunikáció, alarm, adatbázis, vezérlő-, feldolgozó program, vagy akár maga a projekt. Minden programozható és minden komponensnek ugyanaz a szintaktikája. Valójában maga a megjelenítő rendszer, annak változó- és képtipusai, szimbólumai, de a teljes rendszerstruktúra is XSDL-ben készült, a felhasználóink nem csak saját alkalmazásaikat, de akár magát a rendszert is tovább fejleszthetik. A VISION X felhasználóknak mégsincs szükségük mélyreható programozói ismeretekre, mivel a beágyazott grafikus szerkesztő a teljes feladatot átvállalja. A VISION X komponensek és kompozíciók (XSDL fogalom) egyben grafikus rendszerelemek is. A kommunikáció például a képekhez hasonló objektumokból áll (interfész objektumok, driver, modem, csomópont, OPC, IO, stb.), amelyek ugyanúgy tulajdonságokon keresztül konfigurálhatók, mint egy négyszög, vonal vagy szöveg – a kommunikáció tehát ugyanazzal a grafikus szerkesztővel “rajzolható”. A 18 éves rendszerfejlesztés és az ezernyi alkalmazás tapasztalata a folyamatmegjelenítés kristálytiszta koncepciójának a kifejlődéséhez vezetett. A VISION X a design és a programergonómia, ill. az egyszerűség és a komplexitás kivételes egységét adja. Design

Programergonómia

Egyszerűség

6

Komplexitás


1.1. Rendszerszemlélet az alkalmazásfejlesztésben

1

Az X változat legfontosabb előnye talán a rendszerszemléletű megközelítésben rejlik, amelyet már az alkalmazásfejlesztés fázisában is felhasználhatunk. Az új rendszerben arra érdemes törekedni, hogy az alkalmazások képeinek, változóinak és egyéb adatbázisainak a struktúrája tükrözze a felhasználói rendszer felépítését. Ezt a rendszer két új szolgáltatása teszi lehetővé:

1.1.1. Csoportosítás, könyvtárak A fent említett kívánalmaknak megfelelően az új rendszerben létrehozhatunk könyvtárakat is egy-egy alkalmazáson belül, amelyek ugyanazon csoporthoz tartozó képeket, változókat, stb. tartalmaznak. Amellett, hogy az alkalmazói fájlrendszer bármelyik komponenséből is készíthető több példány, ezeket ráadásul még alkönyvtárakba is csoportosíthatjuk aszerint, hogy melyik alrendszerről, vagy funkcionális csoportról van szó. Természetesen továbbra is dolgozhatunk multiprojekt környezetben és használhatunk unitokat is, a könyvtár-szintű csoportosítás ezen túlmutató, belső struktúrákat jelent az egyes projektekben, ill. unitokban. Alkönyvtárak alkalmazásával a fájlrendszert áttekinthetőbbé tehetjük és feladatkörükhöz rendelhetjük.

1.1.2. Strukturális megfontolások A rendszerszemléletű megközelítéshez kapcsolódik és fontossága miatt önálló fejleményként érdemes megemlíteni az struktúra fogalmát. Arról van szó, hogy a felhasználói rendszert egy, vagy több fa-struktúrával írhatjuk le – függetlenül az előző pontban említett könyvtárszintű csoportosítástól. Ez rendkívül kényelmessé és áttekinthetővé teszi a felhasználó számára programunk kezelését, hiszen azokat a struktúrákat tükrözi vissza, amelyek magára a technológiára, ill. az üzemvitelre jellemzők. A fa-struktúra tükrözheti a földrajzi elhelyezkedést (pl.: megyei -> városi -> üzemi -> diszpécseri szint), a funkcionális felépítést (létesítmény-felügyelet /gépház, kazán, klíma, beléptetés, tűzjelző- és riasztórendszer, stb./, folyamatfelügyelet, üzemvitel, adatfeldolgozás, stb), az alá- és fölérendeltségi viszonyokat, a gépészeti berendezések felépítését, leírhatja az eseményeket, változókat, adatbázisokat, képeket és azok objektumait. Ezeket a megfontolásokat persze eddig is figyelembe kellett vennünk az alkalmazások fejlesztésénél és a menürendszer megalkotásánál, de az új rendszerben eleve létrehozhatunk struktúra leíró fájlokat, amelyek “leveleihez” hozzákapcsolahatjuk a változóinkat, képeinket, azok halmazait, vagy a képen látható objektumainkat. A struktúrák felhasználásával készíthetünk saját menürendszert, de az előnyei akkor is kihasználhatók, ha a felhasználó a trendlistában, vagy az alarmlistában keres, mivel előzetesen a fa-struktúrából kiválaszthatja, hogy melyik alrendszer adataira kíváncsi, s így nem az összes trendváltozó, vagy esemény között kell keresgélnie. Az egyes alrendszerek letiltása, engedélyezése (pl. karbantartás, vagy meghibásodás esetén) is sokkal kényelmesebb ezáltal, hiszen a fa-struktúra leveleire, mint objektumokra kiadott parancsokkal elszürkíthetjük akár a megfelelő grafikai részleteket; az attribútumokat pediga fa alsóbb szinjei és a hozzájuk rendelt objektumok automatikusan öröklik.


7

1.2. Információs rendszerek Az informatikai rendszerek bevezetése vadonatúj programszolgátatások előtt nyitott kaput. Alkalmazásainkat ezentúl néhány egérkattintással bővíthetjük vevők, szállítók nyilvántartására szolgáló adatbázis kezeléssel, és a műszaki információs rendszerek leírására, kezelésére, valamint a hibakezelések és a karbantartások menedzselésére szolgáló önálló program-modullal. Természetesen az előző pontban ismertetett struktúrákra illeszkedő módon, ill. integrálva a megjelenítő rendszer működtető adatbázisaihoz. A karbantartási periódusok ui. hozzárendelhetők a VISION-ből érkező mennyiségi- és üzemóra változókhoz. Az adott gépelemkészlet pedig előhívható a grafikus kép objektumaira kattintva. (megjegyzem, a kereskedelemben kapható karbantartó programoknak épp a felügyeleti programokkal való kapcsolat okozza a legnagyobb problémát, ezért általában önálló programként használják őket). Hab a tortán, hogy a meghibásodások, karbantartások regisztrálása közvetlenül befolyásolja a struktúra elemeit, így a képen látható grafikus objektumok viselkedését – hiba esetén pl. a program elszürkíti a szimbólumokat. A program emellett képes e-mailt, SMS-t küldeni (azon a nyelven, amelyen a fogadó beszél), hozzárendelhetők az eszközökhöz fotók, kameraképek, persze maguk a VISION objektumok és csatolt dokumentumok (DOC, XLS, HTML, PDF, stb.) tetszés szerint. A karbantartói program részletes bemutatása persze meghaladja ezen összefoglaló kereteit.

1.3. Dokumentum-vezérlés Ez egyszerűen azt jelenti, hogy a fájlrendszer bármelyik elemére katintva betöltődik a megfelelő kiszolgáló (társított) program. Így a képfájlra kattintva elindul annak megjelenítője és szerkesztője, a ciklikus programra kattintva elindul a ciklikus taszk, a kommunikációs taszkra kattintva elindul maga a kommunikáció, a projekt fájlra kattintva pedig betöltődik az egész projekt és elindul annak összes komponense. A dokumentum vezérlés elve egy érdekes, új módját szolgáltatja a rendszer szerver-kliens hálózati működtetésének is: a taszk, kép, projekt, stb. bármelyike egy távoli számítógépen is elindítható, ha a hálózati tallózóban megkerestük és kiválasztottuk azt a távoli számítógépen. Ehhez még telepítenünk sem kell a programot, csak a társításról kell gondoskodnunk.

1.4. Egyszerűbb, áttekinthetőbb fájlrendszer A rendszer egységes nyelvi környezetbe került, ezért megszűntek a konfigurációs fájlok (CFG), a DRW, az APL, a WRN, a VAR, az STR és a TRE fájlok is, valamint azok objektjei (a lefordított, O-végű változatok). A fájlrendszer ezentúl VAL kiterjesztésű fájlokból áll, ami egyben azt is jelenti, hogy azokat a struktúrákat, amit eddig pl. a VAR fájlba írtunk, ezután beírhatjuk bármelyik képbe, vagy akár a ciklikus programba is. Röviden, megszűnt a rendszerfájlok kiterjesztés szerinti funkcionális különbsége. Csak VAL és SDL fájlkiterjesztések vannak – ez utóbbiak az XSDL programok számára (új változótipusok, struktúrák, eljárások, függvények, stb.), hogy ne keveredjenek a leegyszerűsített VAL nyelvvel.

8


1

A projekt fájlok VPR, és a projekt listafájlok VPL kiterjesztése is csak a dokumentumvezéreltség elve miatt voltak szükségesek (ld. 3. pont), mert egyébként ezek is XSDL állományok, csakúgy, mint az összes többi fájl, ill. program.

1.5. Önfejlesztő képesség A rendszer bővítése, új változótipusokkal, objektumokkal való kiegészítése, strukturális átalakítása, új képtipusok bevezetése, jelentések megadása, stb., nem igényli többé magának a VISION-nek a módosítását. Az XSDL rendszerleíró fájlokkal minden megoldható. A rendszer önfejlesztő képessége tehát egy forradalmian új megoldásnak köszönhető. Az XSDL-ben került leírásra a rendszer összes objektuma, kompenese, de még maga a folyamatmegjelenítés feladata is, annak összetevőivel, a felhasználó kezeléssel, a változókkal, a kommunikációval, a hálózat kezeléssel, stb. Ugyanis e programok nem Delphi-ben íródtak (csak a mögöttük meghúzódó alapobjektumok), hanem XSDL-ben, vagyis ugyanazon a nagyteljesítményű programozási nyelven, amelyen magukat a VISION alkalmazásokat is készítjük. Ezáltal viszont bárki képes továbbfejleszteni a VISION-t, aki hajlandó elmélyedni az XSDL rejtelmeiben, hogy ezáltal a maga, ill. a felhasználója számára a legoptimálisabb rendszert alakítsa ki - rugalmasan, a mindenkori igények szerint. A PROVICON Kft. a jövőben egy programot fog indítani ezen felhasználói kezdeményezések koordinálására, Interneten keresztül történő menedzselésére, amelybe megpróbálunk mind több automatizálási szakembert és egyetemi, főiskolai hallgatót is bevonni. Reményeink szerint így kisebb fejlesztői társadalom alakulhat ki, akik újabb dinamizmust adhatnak a VISION-fejlesztés eddig is rendkívüli lendületének.


9

1

1.6. Kulcstulajdonságok A VISION folyamatmegjelenítő rendszer a teljeskörű feladatmegoldás érdekében számos szolgáltatással rendelkezik. Ezek közül a kulcsfontosságúak a következők: • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

10

Kettős pufferelésű, villogásmentes animáció Platformfüggetlenség (DOS/DPMI – csak 4.0 verziószámig, Windows, Unix) On-line integrált fejlesztői tulajdonságok, azonnal érvényesülő editálás, konfigurálás Többnyelvűség, programfüggetlen rendszererőforrások, nemzetközi projektek támogatása Saját (XVAL) és idegen nyelvű (Pascal, C, C++, Delphi, Visual Basic) programozhatóság Teljes programozhatóság Teljeskörű szerver kliens hálózatkezelés, multiszerveres rendszerarchitektúra Telefonvonalas hálózat nyitott (IP) vagy zárt protokoll (DFS) felhasználásával Web-alapú hálózatok, többféle Web-technológia Távprogramozás telefonvonalon keresztül, vagy lokális hálózaton 512 változás/10ms (51200 változás/másodperc) hálózati átviteli sebesség! Multiszerveres és redundáns hálózati rendszerek, többszörös adattárolás 10 ms-os ciklusidejű többszintű kommunikáció Extrém sebességű taszk-taszk kommunikáció TCP/IP protkollal, RPC szolgáltatások Beépített nagyteljesítményű adatbáziskezelő modul, külső (pl. SQL) adatkapcsolatok Analitikus grafikai szolgáltatások (kamera, árnyék, nézőpont, metamorfózis, stb.) Automatikus vonalrajzolás és vonalmenti animáció Képprogramozás (ld. Demo/TETRIS játék)! Képstilisztika, képmodellezés Nagysebességű grafikai megjelenítés (tipikusan 50-400 frissítés másodpercenként) 3D megjelenítés, analitikus szimbólumrajzolás Összetett szimbólumok (többszörös animációs lehetőséggel) Képparaméterezés, képrutinok Professzionális (pl. 3D Stúdiós) animációs lehetőségek Miliszekundumos taszk és trendkezelés Alkalmazás klónozás ismétlődő alrendszereket tartalmazó óriás alkalmazások kifejesztéséhez Alkalmazás szintű objektumok (unit) ismétlődő, variablis alrendszerek bevitelére Rendszerintegrációs képességek, több független alkalmazás egyidejű kezelése Független Windows alkalmazások integrálása VISION környezetbe Esemény időbeni visszajátszása (replay) Dinamikus külső adatkapcsolatok pl. Excel-lel: (DDE szerver, kliens, NetDDE, OLE) COM/DCOM interface külső programok számára OLE szerver, beépítés és automatizáció (pl. Winword dokumentáció vagy Excel táblázat előállítása, mentése és nyomtatása VISION-ből) Az összes elterjedt adatbázis kezelése a beépített SQL utasításmodul révén OPC (OLE for Process Control) integrálás Teljeskörű Audit-Trail (adat nyomkövetés) Nemzetközi szabványok alkalmazása: CFR Standard Part 11


1

1.7. Fontosabb szolgáltatások

1

1.7.1. Teljeskörűség A VISION program a teljeskörű feladatmegoldás (complete solution) kategóriájába tartozó folyamatmegjelenítő rendszer. Az összetettebb alkalmazásoknál szükséges számítások, adatfeldolgozások, adatbázis kezelés, többszintű hálózatkezelés, stb., a VISION program saját VAL programnyelvén is megoldható. Nem szükséges tehát külső eszköz (Visual Basic, C++, Access, Excel stb.) igénybe vétele ahhoz, hogy a változatos felhasználói igényeket kielégítsük, s így az alkalmazás sem függ pl. a Microsoft-tól. Ez a tulajdonság nemcsak az alkalmazásfejlesztő társaság, de a végfelhasználó szempontjából is lényeges előny, hiszen a VAL források birtokában így hosszú távon biztosított az alkalmazás összes szolgáltatásához való hozzáférés, a későbbi bővítések, módosítások elvégzése anélkül, hogy a felhasználói programokat újra kellene iratni - mondjuk azért, mert az alkalmazásfejlesztő társaság, vagy a programozó többé nem elérhető. Végső soron a felhasználó sem függ beszállítójától. A teljeskörű feladatmegoldás nélkülözhetetlen a platformfüggetlenség megvalósításához is. Ne felejtsük el, hogy a VISION alkalmazások nemcsak a Windows alatt, de DOS-on és UNIX-on is futtathatóak. A teljeskörűség a garancia a felhasználói programok hosszútávú verziókövetésére, az új operációs rendszerek, számítástechnikai megoldások (pl. Internet-es hozzáférés), stb., alkalmazására is.

1.7.2. Kompatibiltás, platform-függetlenség, verziókövetés A VISION rendszer 16 éves múltja azt bizonyítja, hogy a verziókövetés a korábbi változatokkal való kompatibilitás megőrzése mellett biztosítható. Éppen nemrég történt, hogy egy 1992-ben készült UNIX-os VISION alkalmazást kellett Window-ra adoptálni. A futtatható változat előállítása mindössze néhány percet vett igénybe. A megváltozott felbontás, színmélység és fontkészlet bevezetése pedig egy napig tartott. A VAL nyelvű felhasználói programon egyáltalán nem kellett változtatni.

1.7.3. On-Line programszerkesztési szolgáltatások A különleges interaktív fordítónak köszönhető, hogy az új program, kép, adat, alarm, kommunikációs üzenet, stb., látható fordítási procedúra nélkül, miliszekundumok alatt épül be a futó alkalmazásba, vagyis a VISION-ben igazi On-Line szerkesztésre van lehetőség. Hálózati kiépítés esetén a módosítások automatikusan letöltődnek az összes, hagyományosan a futtatórendszer hatása alatt működtetett terminálra is anélkül, hogy azok működését a programmódosítások befolyásolnák - tehát az adatgyűjtés, kommunikáció, alarmkészítés, stb., változatlanul folyik tovább. Ezt a tulajdonságot távprogramozásnak nevezzük, ami különösen a telefonvonalon létesített hálózati kapcsolat esetén válik igazán izgalmassá!

1.7.4. Nyelvfüggetlenség, nemzetközi projektek készítése Az általános tulajdonságok közül is kiemelkedik a program nyelvfüggetlensége, vagyis az a tulajdonság, hogy a felhasználó On-Line módon, menet közben változtathatja meg a program VISION X általános leírás

11

saját- és alkalmazói nyelvét. A nyelvválasztás tehát egyaránt kiterjed a rendszerre és az alkalmazásra is, beleértve az összes menüt, dialóg ablakot, nyomógombot, stb. A nyelvfüggetlenség elsősorban a nemzetközi projektek, vagy a több országban is forgalmazott alkalmazások esetén előnyös, ill. ott nélkülözhetetlen.

1.7.5. Grafikai szolgáltatások A rendkívüli hálózatkezelési és kommunikációs sebességek mellett a program fő erőssége a grafikai megoldások köré csoportosítható. A DynaWindows-ra épülő animáció lehetővé teszi, hogy a képeket a reklámgrafikában használt speciális képátúsztatási technikákkal cseréljük (page, explode, fade, scroll, split, push, ...), de a feltételesen felrajzolt objektumokat is lehet folyamatosan nagyítani, felrobbantani, úsztatni, stb. A Dynawindows-ban megrajzolt ablakokat ugyancsak lehet animálni. Például egy VISION ablak folyamatosan kicsinyíthető, nagyítható, foroghat a tengelye körül, lehet kör alakú, vethet árnyékot az alatta fekvő ablakokra, de lehet akár átlátszó is. A legérdekesebb grafikai szolgáltatások a következők: • A külön programból (pl. 3D Studio) származó animációk bármely dinamikus kép részét képezhetik. A transzparens mozgó grafika jóvoltából a háttérben látható kép, mind a statika mind a dinamika tekintetében átlátszik. A rendszerhez tartozik továbbá egy kiterjedt 3D mozgó grafikákból álló szimbólum-könyvtár, ami közvetlenül beépíthető az alkalmazásokba. Ezek között különféle animált tartályok, szerelvények, lapát, szivattyú, szelep, PLC, PC, nyomtató és számos egyéb számítástechnikai berendezés is megtalálható. • A 3D hatású (színátmenetes) csővezetékek és tartályok előállítása nem igényli külön speciális elemkészlet használatát, mivel az egyszerűen a vonal ill. kitöltési stílus megváltoztatásával állítható elő az analitikus grafika által nyújtott szolgáltatások felhasználásával. • A képstilisztika is eredeti VISION tulajdonság. Használata esetén rajzolás közben nem kell törődnünk a színek vagy a betüstílusok kiválasztásával, mivel azt objektum tipusonként maga a program határozza meg automatikusan egy stilisztikai könyvtár alapján. Ezáltal a képrajzolás időigénye lényegesen csökkenthető úgy, hogy a képminőség tekintetében egyáltalában nem kötöttünk kompromisszumot. • A képmodellezés a képsablon fogalmának kiterjesztésével előre definiált felépítésű képek, képminták felrajzolását teszi lehetővé. Hangsúlyozzuk, hogy itt nemcsak a keretformátumnak, de komplett alkalmazói képeknek, táblázatoknak, menüknek a kiválasztása is lehetséges. • A VISION további érdekes tulajdonsága az automatikus vonalhúzás, vagyis vonalhálózat auto-matikus felrajzolása objektumhoz kötött azonosító pontok (markerek) között. Így az objektumok mozgatását követi a vonalhálózat. • A mozgó kitöltési minta anyagáramlás megjelenítésére szolgál tartályokban, csővezetékekben ill. vonalhálózat mentén. Ez utóbbi különösen az előző pontban ismertetett automatikus vonalhúzással párosítva használható. • A mozgópont animáció objektumok vonalhálózaton való automatikus mozgatására szolgál. A mozgópont automatikusan megkeresi bármely két markerpont között vezető legrövidebb 12


1

utat a vonalhálózat mentén, majd az objektumot egyenletes sebességgel végigvezeti rajta. Ez a szolgáltatás forgalmi rendszerek megjelenítésére használható. • A metamorfózis egy rendkívül látványos grafikai eljárás objektumok, ill. objektumcsoportok közötti átmenet folyamatos megjelenítésére. • A Window-animáció a VISION-ben megrajzolt ablakok látványos megjelenítését végzi

(nagyítás, kicsinyítés, forgatás, stb.).

1.7.6. Hálózati szolgáltatások, telefonvonalas hálózatok A VISION program rendkívüli sebességű hálózatkezelésre képes. Az adatok 10 ms késleltetéssel és 51200 változás/másodperc átviteli kapacitással kerülnek továbbításra. Ez a világviszonylatban is egyedülálló sebesség a gyakorlatban azt jelenti, hogy a VISION hálózati terminálok a változásokat gyakorlatilag egyidőben jelzik függetlenül a változók és a hálózati terminálok számától. A hálózati kapcsolat hagyományosan TCP/IP protokoll segítségével valósul meg. A hálózati kapcsolatban működő VISION terminálok a rendszer adataihoz való hozzáférés szempontjából - hacsak a rendszerkonfiguráció során másképp nem rendelkezünk egyenrangúak. Vagyis látható az összes kép, on-line adat, napló, göngyölt adat, adatbázis, valamint az alarmrendszer hangos és szöveges jelzései. A VISION-el megvalósított szerverkliens hálózat azonban nemcsak az alkalmazás de a rendszer szolgáltatásait is megosztja a terminálok között. Így lehetséges az alkalmazások (táv)konfigurálása, (táv)programozása a hálózat bármely termináljáról, de a szerver számítógép összes többi szolgáltatása (pl. a soros portok, vagy az egérmozgatások) is átirányíthatók. A kapcsolt telefonvonalon létesített kommunikációra a VISION program esetében négyféle lehetőség is kínálkozik: 1. 2. 3. 4.

Microsoft Dialup-Networking driver-en keresztül létesített hálózati kapcsolat A VISION program speciális DFS driver-én keresztül létesített hálózati kapcsolat Modem-el kapcsolt kommunikációs protokoll Operációs rendszer szintjén létesített telefonvonalas távhozzáférés (pl. PcAnywhere)

Az első két módszer lényegében hagyományos hálózati kapcsolat telefonvonalon keresztül történő kiépítésére szolgál. Csakhogy a standard megoldás (Microsoft Dialup Network) számos hátrányos tulajdonsággal rendelkezik a VISION DFS driver-ével szemben. Ti. az utóbbi driver a VISION file-rendszer tulajdonságainak ismeretében optimális átviteli tulajdonságokat nyújt, hiszen csak a szükséges adatmozgatásokat végzi az egyébként lassú telefonvonalon keresztül (gondoljunk pl. egy többszáz kilobájtos adatbázis lekérdezésére). A DFS driver a korábbi adatmozgatásokat a célszámítógépen eltárolja és így csak az új információk továbbítására van szükség. Ez a megoldás ugyancsak jól működik a folyamatmegjelenítő rendszerekban szokásos trend, alarm és gyűjtött adatbázis adatok továbbítására. A telefonvonalon DFS-el létesített hálózati kapcsolat tehát gyors, s így hasonlóan jól használható a hagyományos hálózati terminálokhoz. A kapcsolatfelvétel egyaránt kezdeményezhető a központ (lekérdezés) és az alállomások által (aktív bejelentkezés), automatikusan, vagy kezelői aktivitásra. A DFS driver másik előnyös tulajdonsága a zártsága, vagyis az a tulajdonság, hogy csak VISION terminálok képesek ilyen


13

1

hálózati kapcsolat kialakítására. Telefononvonalon keresztül tehát nem léphet rá akárki a rendszerünkre, amint az a Microsoft Dialup Network esetében lehetséges a jól ismert IP protokoll révén - s így az ipari központ is védett marad az illetéktelen behatolással szemben. Amennyiben nem szükséges teljeskörű hálózati kapcsolat, sokszor elegendő a normál Modem-es kommunikáció. A VISION program lehetővé teszi, hogy bármely kommunikációs protokoll modem-en keresztült kapcsolt telefonvonalhoz csatlakkozzék. Tipikus példa valamely PLC adatainak telefonvonalon keresztül való leolvasása. Ez a megszorítás a távoli számítógépek meghatározott adatainak a lekérdezését teszi lehetővé általában nagyobb sebességű hozzáférést eredményezve, mintha hálózati kapcsolatot létesítettünk volna. A 4. módszerrel létesített telefonvonalas kapcsolat lényegében a távoli készülék távirányítását teszi lehetővé. Ilyenkor csak a számítógép billenttyű és egér parancsai továbbítódnak és a távoli számítógép reakciói láthatók lassú firssítéssel. Ezzel a megoldással viszont teljes kontrollt gyakorolhatunk a távoli számítógép felett és nemcsak a VISION taszk, de a teljes Desktop is látható. Sőt, akár ki is léphetünk és újra is indíthatijuk a távoli számítógépet: CtrlAlt-Del, majd a belépő felhasználó neve és kulcsszava megadásával. Ennek a módszernek a lassúság mellett hátránya, hogy a Host/Gateway - Kliens funkciókat fixen ki kell osztanunk.

1.7.7. Adatbázis kezelés A VISION program figyelemreméltó tulajdonsága az integrált nagyteljesítményű adatbáziskezelő motor. Ez a szolgáltatás igen bonyolult adatbáziskezelési feladatok megvalósítását is lehetővé teszi akár közvetlen táblázatkezelési, akár SQL-szintű eljárásokkal. A VISION program lehetőséget ad a legkülönfélébb adatgyűjtések, göngyölt adatbázisok, időszaki naplók, kiszakaszolási naplók, gépjegyzékek, technológiai naplók, batch adatok, stb. létrehozására. Az így létrejött változatos naplók azután különféle szempontok szerint szelektálhatók, listázhatók, táblázatokba rendezhetők, görbék rajzolhatók a képernyőre és nyomtatóra, de az adatok exportálhatók, importálhatók, vagy éppen egymásba meríthetők, hogy csak néhányat említsünk a lehetőségek közül. Fontos adatbáziskezelői funkció a statisztikai modul is. Ez a programrész lehetővé teszi az adatok tetszőleges időtartamra vagy egyéb szelekciós szempont alapján való statisztikai kiértékelését - tipikusan a minimális, a maximális, az átlagértékek és a szórás kiszámítását, de rajzolható az adatokból eloszlásdiagram is. Az adatbázisok kezelése több szinten lehetséges. Vannak előre konfigurálható adatbázis műveletek (pl. üzemóra számlálás, mennyiségi adatok integrálása, számlálók kezelése, stb.), valamint programozható adatbázis műveletek. Az adatbázis tipusa alaphelyzetben dBase, amit a VISION saját adatbáziskezelő motorja közvetlenül kezel. A beépített SQL eljárások alkalmazásával azonban az összes elterjedt adatbázis-tipus elérésére is lehetőség van (Paradox, Excel, MS-Access, MS-SQL, InterBase, Informix, Oracle, stb.).

14


1

2. VISION Installáció

1

A program a CD behelyezése után automatikusan települ az alább látható installációs program bejelentkezésével. Amennyiben ez a kép nem jelenik meg, indítsuk el a CD-n található SETUP.EXE programot.

A telepítés a szokásos kérdések (elfogadja a licence szerződést, telepítési könyvtár, stb.) után indul el. A telepítési könyvtárként elfogadhatjuk a program által felkínált ‘Program files’ direktorit, de választhatunk tetszés szerinti más könyvtárat, ill. meghajtót is.


15

3. VISION Projektek

1

A VISION program a továbbiakban a projekt fájlra épül, ami ugyanolyan XSDL szintaktikájú fájl, mint az összes többi, csak a megkülönböztetés érdekében VPR (Vision Project) kiterjesztést kapott. Amennyiben a VPR kiterjesztéshez társítottuk a a projektek összevont futtatásáért felelős VPR.EXE programot (ez a program installálásával megtörténik), akkor bármelyik VPR fájlra kattintva elindítható a projekt. A projektek kezelésére azonban számos további szolgáltatás áll a rendelkezésünkre.

3.1. Projekt lista Projekteket legegyszerűbben magából a projekt listából készíthetünk, a Start menüben is megtalálható Projekt lista (VPL.EXE) elindításával:

Maga az új projekt a Létrehoz gombbal keletkezik, miután kitöltöttük az alábbi dialógust:

16


1

Amint látható, itt többféle projekt tipusból is választhatunk: Default projekt: Üres projekt: Hálózai kliens: Unit: Összevont projekt:

Alap fájlrendszer létrehozása Üres fájlrendszer készítése Meglévő szerver alkalmazásra kapcsolódó hálózati kliens Speciális, ismétlődő alrendszert tartalmazó objektum alkalmazás Több különálló projekt összevonásával keletkező szuperprojekt

A projekt megadásánál lehetőleg olyan felbontást válasszunk, ami az alkalmazás tényleges felbontása lesz, egyébként a tervezés és a kivitelezés között apró eltérések keletkeznek majd képeinken. A színfelbontás tekintetében célszerű a Windows saját beállításához igazodni és célszerű minél nagyobb színmélységet, truecolor-t alkalmazni. Maga a projekt a rendben gomb megnyomására jön létre és be is töltődik a Vision projekt nevű programba (VPR).

3.2. Projekt indítása Meglévő projektjeinket a projekt lista elemeire való dupla kattintással, a megnyit gombbal, ill. magának a projekt fájlnak a nevére kattintva indíthatjuk el. Ennek hatására betöltődik a már sokat emlegetett Vision projekt program, a rendszer projekt menedzsere.


17

3.3. Projekt menedzser

1

A projekt menedzser hivatott a VISION programhoz tartozó taszkok szervezésére és futtatására. Az alkalmazásokat általában projektként indítjuk el, de hangsúlyozzuk, hogy az X9 rendszer támogatja a fájlszintű taszk-kezelést is – vagyis valamennyi képünk, kommunikáció, program, trend-, alarm-, adatgyűjtő szerver, stb., önállóan is elindítható. A projekt menedzser látható a következő ábrán:

A kép bal oldalán a projekt komponensei (az alkalmazás-fejlesztés során ezt töltjük ki), a jobb oldalon alul pedig maga a betöltési folyamat, ill. annak végeredménye látható. A képen látható ikonok a gyors navigációt segítik, lévén a projekt legfontosabb elemei érhetők el innen: • • • • • • •

18

Rendszer konfiguráció – globális paraméterek, file- és alarm-rendszer, stb. Felhasználó kezelés – felhasználók és jogosultságaik felvétele Változók kezelése – változótáblák létrehozása és változók konfigurálása Kommunikációs taszkok – kommunikációs struktúrák grafikus tervezés Ciklikus programok – ciklikusan végrehajtandó számítások, feladatok Képlista, ill. képek – megjelenítendő folyamatsémák Főkép – a rendszer induló képe (általában a főmenü, ill. főkép)


3.3.1. Képek felépítése és részei

1

A VISION képek felépítését a projekt ablak részeinek a bemutatásával ismertetjük:

Projekt menedzser

Toolbox menü, az egyes részek külön-külön ki-, ill. bekapcsolhatók

Legördülő menü

Termék verziószáma, szintje és regisztrált felhasználója

Eseménynapló utolsó sora

Aktuális projekt kiválasztása a betöltött projektek közül

Projekt betöltésének folyamata és a rendszer egyéb üzenetei

` Program státusz-sor

Gyors navigáció ikonjai

Az egyes ablakrészek között, ún. splitterek (elválasztók) találhatók, amelyek elmozdításával a kép átrendezhető. A Toolbox menüsora is átrendezhető, onnan az egyes elemek kivehetők, áthelyezhetők, dokkolhatók, a kép alsó felébe mozgathatók – ha szükséges. Természetesen minden képrész levehető, vagy felrakható a jobb egérgom hatására megjelenő menü alapján. Ez látható jobb oldalt. Emellett érdemes megjegyezni még az F2 billentyű-parancsot, amivel részenként levehető és visszahelyezhető a legördülő menü, valamint a Toolbox:

A projekt menedzser például a Toolbox legelső gomjára kattintva vehető le, de a jobb egérgom hatására megjelenő menüben egy érdekes további opció is megmutatkozik: megjelenítés automatikusan, egérpozicionálással. Ez úgy lehetséges, hogy az egeret a kép bal széle felé közelítjük – mire a projekt menedzser előkúszik -, majd a kép belseje felé mozogva eltűnik. A program megjegyzi a képrészek állapotát, amikor kilépünk. Ezért a legközelebbi indításkor a rendszer ugyanolyan beállításokkal indul. VISION X általános leírás

19

3.3.2. Kezeléssel kapcsolatos általános tudnivalók Amint a projekt egyes fejezetei között lépegetünk, a képek bal oldalán rendre egy-egy újabb menücsoportot láthatunk az XP-ben megismert formátumban. Ezek az adott témakör parancsait foglalják össze, de ezek éppúgy megtalálhatók a jobb egérgomb menükben és magában a projekt menedzserben is. Ez a sokféleség talán elsőre érthetetlen, de ne felejtsük el, hogy a projekt menedzser nem mindig látható, sőt, általában nem látható – a felhasználói környezetben. A programmal való ismerkedés során érdemes elolvasni az egyes fejezetek súgóit, amit a felhasználó-kezelés példáján mutatunk be:

Bevezetés kérése az adott témakörhöz kapcsolódóan

Súgó

Amennyiben gyors segítséget kértünk, a kép jobb alsó felében látható súgó automatikusan követi a témakört, ahová éppen kattintottunk. Így az adott témakörhöz tartozó információ a súgó ablakában mindig elolvasható. A súgó egyébkén nagyjából ugyanazokat az információkat tartalmazza, mint ez a dokumentum, tehát a programmal való ismerkedés közben a leírás megfelelő részeire fókuszálhatunk.

20


1

3.4 Projektek részei, az alkalmazás-fejlesztés fázisai

1

3.4.1. Projekt-konfiguráció A konfiguráció a VISION projekt (VPR) alapparamétereinek a beállítására szolgál. Ezek közé tartozik a rendszer időszelekciójának, ill. a műszakoknak a beállítása, a funkciómenük beállítása, a redundancia, a program által használt fájloknak és adatbázisoknak a beállítása, az alarm-rendszer, a menü-rendszer és a duplamonitoros konfiguráció. A konfiguráció kiválasztása után a kép jobb oldalán látható ablak jelenik meg. Vegyük észre, hogy ezen a képen alaphelyzetben minden menüpont szürke, vagyis a szerkesztés engedélyezéséhez még a szerkesztés üzemmódot is be kell kapcsolnunk (Ctrl-Alt-E). Ehhez persze rendelkeznünk kell konfigurációs jogosultsággal is.

Ezek után a konfiguráció alábbi fejezetei közül válogathatunk: • • • • • • •

Rendszer-konfigurációja Fájlnevek megadása Alarm-rendszer konfigurációja Hálózatkezelés, projekt hálózati beállításai Alarm nyomtatás beállítása Menürendszer Duplamonitoros üzemmód beállítása


21

3.4.2. Struktúrák

1

Struktúrák deklarálásával tetszőleges fa-struktúrákat, hierarchikus menü-rendszereket hozhatunk létre. A struktúrák azonban nemcsak a képmenük előállítását könnyítik meg, segítségükkel az adatokhoz való hozzáférést is strukturálhatjuk. A trendek, az alarmok és a gyűjtött adatok egyaránt hozzárendelhetők a fa ágaihoz és leveleihez. Ez különösen sok változót tartalmazó alkalmazások esetén előnyös, hiszen nem kell az egész változótáblában tallóznunk, amikor egy jelleggörbét szeretnénk felrajzolni, vagy amikor az alarmok között szeretnénk megkeresni egy alrendszer, vagy egy konkrét berendezés hibaállapotát. Figyelmünket a fa által leszűkített alrendszer adataira koncentrálhatjuk. A struktúrák rendkívül kényelmessé és áttekinthetővé teszik programunk kezelését a fel-használó számára, mivel ez tükrözi a technológia, ill. az üzemvitel sajátosságait. A fa elkészíthető a földrajzi elhelyezkedés (pl.: megyei -> városi -> üzemi -> diszpécseri szint), a funkcionális felépítés (létesítmény-felügyelet /gépház, kazán, klíma, beléptetés, tűzjelző- és riasztórendszer, stb./, folyamatfelügyelet, üzemvitel, adatfeldolgozás, stb), az alá- és fölérendeltségi viszonyok, vagy a gépeszeti berendezések felépítése szerint, de leírhatja az eseményeket, a változókat, az adatbázisokat, a képeket és azok objektumait is. Az egyes alrendszerek tiltása, engedélyezése (pl. karbantartás, vagy meghibásodás esetén) elvégezhető a hozzárendelt struktúra ágaira, ill. leveleire – mint objektumokra – kiadott parancsokkal; a fa alsóbb szintjei öröklik a tiltás/engedélyezés állapotot..

3.4.3. Változók A VISION rendszerleíró adatbázisának legfontosabb eleme a változók deklarációja, mivel az összes taszk változókon keresztül kommunikál egymással. A képeken látható objektumok tulajdonságait, pl. a színt, közvetlenül hozzárendelhetjük a VISION változókhoz, ill. azok kifejezéseihez. Amikor a kommunikációs taszk beolvas egy üzenetet, az üzenetben megadott változólista kiértékelésével a változók felülíródnak a kommunikációs üzenetben továbbított adatokkal. Ha a változó értéke megváltozott, a hozzárendelt objektumok is frissülnek – megváltozik a például a szín. Ugyanez a helyzet a ciklikus- és az alarmprogramok esetében is. A változók osztott erőforrások, amelyeknek 10-féle alaptipusa létezik:

22


1

1. Analóg változók. Lineárisan skálázható adatok, általában 0-10V vagy 4-20mA bemenetek fizikai mértékrendszerben való megjelenítésére szolgál 2. Analóg trendváltozók. Normál analóg változók automatikus hisztorikus adattárolás képességgel 3. Egész változók. Nem skálázható egész változók (általában számlálók, üzemállapotok, egész értékű mennyiségek) 4. Lebegőpontos változók. Nem skálázható lebegőpontos változók (általában származtatott adatok vagy szabályzó P, Y, SP jelei) 5. Lebegőpontos trendek. Normál lebegőpontos változók automatikus hisztorikus adattárolás képességgel 6. Diszkrét változók. Kétállapotú jelek leírására szolgáló adat típus. Leírása kétértékű attribútum táblával történik. 7. Diszkrét trendek. Normál diszkrét változók automatikus hisztorikus adattárolás képességgel 8. Többállapotú változók. Komplex gépészeti elemek leírására szolgáló, több diszkrét jelvonal egyesítésével keletkező adat típus. Leírása többértékű (esetleg parancsadással bővített) attribútum táblával történik. 9. Többállapotú trendek. Normál többállapotú változók automatikus hisztorikus adattárolás képességgel (a trend grafikus képe lehet érték diagramm vagy színsáv diagramm) 10. Szövegváltozók. Alfabetikus adatok tárolására szolgáló változótipus (pl. dátum/idő, felhasználó neve, változó technológiai azonosítók); 31-, ill. 255 hosszú karaktersorok tárolására alkalmas. Az alap tipuskészlet tetszőlegesen bővíthető új változótipusokkal, de ehhez már az XSDL nyelv ismerete is szükséges.


23

A numerikus változók a 8-64 bites sávot teljesen lefedik, vagyis az analóg, egész és lebegőpontos változókon belül egyaránt létrehozható 64-bites változat. A VISION-ben ezért igen nagy értéktartományú, ill. felbontású számokat is készíthetünk. A VISION változók maguk is önálló objektumok, amelyek “belsejében” trend-, alarm- és adatgyűjtő objektumok is vannak. Ezért kell megadnunk a taszkok alap-ciklusidejét a változófájl létrehozásakor. A változófájlban megadott változók, jellegüknél fogva globálisak; az összes taszk (kép, ciklikus program, kommunikáció, alarm, stb.) “látja” őket. A változók elérésének a módja azonban tovább szűkíthető aszerint, hogy az adatokat a hálózati kliensek számára is láthatóvá kívánjuk tenni, ill. az adatok a felhasználóhoz kötöttek. Eszerint háromféle publicitás adható meg: • • •

Published (network): az adatot mindenki láthatja, a hálózati klienseket is beleértve. Ez a változótipus használandó a folyamatváltozók esetében. Public: az adatot csak a helyi számítógépen futó taszkok láthatják, a hálózati kliensek nem, ill. azok saját önálló adataikkal dolgoznak. Private: az adatok most is csak a helyi számítógépen futó taszkok számára hozzáférhetőek, mint a public esetében, de csak az adott felhasználói account számára. A private adatok felhasználónként különbözhetnek (tipikusan ilyenek a felhasználó neve, kulcsszava, más azonosítói), ezért felhasználóváltással cserélődnek.

A public és a private egyaránt lokális, csak a helyi számítógépen látható adatokat jelent, mégsem ugyanaz, mint a local változótipus! Ugyanis a public és a private adatok egyaránt globális változók – abban az értelemben, hogy a taszkok között megosztottak. Mindhárom adattipus a Global .XDO adatbázisban kerül eltárolásra. A már említett local adattipus viszont csak abban a taszkban használható, amelyikben létrehozták. A globális változók előállítására szolgáló változódeklaráció során a local adattipus értelemszerűen nem érhető el. A lokális változókat az egyes taszkok szerkesztésénél készítjük el, külön-külön. A változók listája különféle szempontok szerint szűkíthető. Eszerint lekérdezhetjük külön a letiltott változóinkat, de még ennél is látványosabb a változók trendek formájában történő megjelenítése:

24


1

A változók sorára kattintva jelenik meg a bal oldalon látható változó-lekérdezési ablak, ahol a változók adatait módosíthatjuk, grafikusan.

3.4.4. Ciklikus programok A VISION program saját magasszintű nyelven programozható, VAL-ban (Vision Application Language), ill. XSDL-bel (Extensible Structure Declaration Language). A ciklikus programok ilyen alkalmazói programrészeket tartalmaznak. A VISION taszkjai nem interpretatív jellegűek (eltérően a scriptelhető rendszerektől), mivel saját fordítóval és szerkesztővel rendelkeznek, amely futtatható kódot generál. A futtatható kód előállítása betöltéskor történik meg (hasonlóan a .NET rendszerek JIT fordítójához). A ciklikus program lefutásának gyakorisága miliszekundumban állítható és azt a rendszer nagy pontossággal be is tartja. Ezzel kvázi real-time taszkokat készíthetünk az alkalmazói programunkhoz (Windows alatt persze valódi real-time taszkok nem készíthetőek, csak az időzítés pontossága, ill. gyakorisága állítható a taszkok prioritásának a megválasztásával.) A ciklikus program hozzáfér az öszes globális változóhoz (public v. published); fő feladata a rendszerben elvégzendő számítások (pl. integrálás) ciklikus végrehajtása, programozott adatbázis kezelés, speciális vezérlések, időzítések, analízis. A ciklikus programokra bonyolult feladatokat is rá lehet bízni, mivel a rendszer gyors, és a programozási nyelv képes struktúrált adatok, tömbök intelligens kezelésére, eljárások, függvények deklarációjára, sőt még objektum-orientált programozási feladatokra is (objektumok létrehozása, öröklés, tulajdonságok, metódusok, stb.)

3.4.5. Alarm programok Az alarm rendszer éppúgy a VISION saját magasszintű programnyelvén alapul, mint a ciklikus programozás, de az csak meghatározott vezérlő objektumokat, ún. alarmokat (AL objektumokat) tartalmazhat. Előállításuk grafikus szerkesztővel lehetséges, alarmokat


25

1

ezért egyszerű egérműveletekkel hozhatunk létre, miközben az eseményekhez akár bonyolult alarm-kiszolgálókat is írhatunk – köszönhetően a rendszer programozhatóságának. Az alarmok létrehozásához a következő adatokra van szükségünk: • •

Alarm feltétel (a feltétel bekövetkezésére történik meg a bejegyzés a naplóba) Üzenet (ez lesz a naplóban szereplő szöveg)

Ha a feltétel teljesül, a rendszer üzenetet küld. Persze az alarmokhoz tartoznak még különféle opciók is, amelyben előírhatjuk a alarm-feltétel által generált alarmok tipusát (bekövetkezés, megszűnés, nyugtázás) és hozzárendelhetjük őket a megfelelő kiszolgáló eseményekhez (pl. hangjelzés generálása, üzenet megjelenítése ablakban, email küldése, stb.) A VISION-ben az alarmok csoportokra és tipusokra oszlanak. A 8 alarm csoport tetszés szerint konfigurálható (elnevezés, szín, rendszerbeli kiszolgálás). A 3 tipus pedig az események bekövetkezése, megszűnése és nyugtázása szerint jön létre. Így összesen 24-féle alarm létezik.

3.4.6. Szervízek A szervíz egy speciális fogalom a VISION-ben, azoknak a taszkoknak az azonosítására szolgál, amelyek globális eseménykiszolgálást végeznek. A szervíz tulajdonképpen nem más, mint az összes Windows-esemény közös ága. Ha a kezelő pl. képet vált, a szervíz lefut, de ugyanez történik pl. akkor is, ha rákattint valamelyik menüre, begépel egy új adatot, megnyomja az F1 gombot, stb. Felvetődik a kérdés, hogy mikor van szükségünk erre a szolgáltatásra, amikor minden objektum önálló eseménykiszolgálóval is rendelkezik, az eltérő feladatokat pedig nyilván ott kell meghatároznunk. Akkor lehet szükségünk globális eseménykiszolgálóra, ha a felhasználó aktivitásához szeretnénk kötni programrészeket (pl. saját időzítést szeretnénk készíteni). Ezeket a globális kiszolgálásokat nagyon fáradtságos és unalmas munka lenne az egyedi eseménykiszolgálókhoz hozzáfűzni – különösen egy meglévő, több ezer objektumot tartalmazó rendszerben, utólag. A szervízek másik tipikus felhasználása az üzenetküldés automatizálása a felhasználó által végrehajtott adatbevitel, vagy módosítás után. A szervíz tehát a speciális programozási feladatok egyszerűsítésére szolgál.

3.4.7. Kommunikáció A komunikációt az alarmokhoz hasonlóan önálló taszkokhoz rendeljük, amelyek csak meghatározott tipusú objektumokat tartalmazhatnak. Itt valamivel több objektumra van szükségünk, mint az alarmok esetében, mivel a kommunikációs médiumot, a protokollt, az állomásokat és az üzeneteket is létre kell hoznunk, ill. össze kell rendelnünk egymással. A kommunikáció a következő objektumokat tartalmazza: • • • •

26

Interfész (kommunikációs médium: soros vonal, UDP, TCP/IP vagy OPC kliens) Driver (kommunikációs protokoll) Csomópont (tipikusan a komunikációs célállomás) Üzenet (adott tipusú adatok olvasása/írása megadott címtől kezdve)


1

A kommunikáció megadása ezen objektumok létrehozását és egymással való összerendelését igényli. A csomópontokat a driverhez és az interfészhez, az üzeneteket pedig a csomóponthoz kötjük. A kommunikáció konfigurációjának ez a fázisa a grafikus szerkesztővel egyszerűen elvégezhető. Az üzenet a változók listáján keresztül rendeli össze a kommunikációs eszközt a VISION online adatbázisával. Az üzenetekben felsorolt változók, tipusuk és méretük szerint dekódolódnak - bitfolytonosan. Egy diszkrét változó pl. 1 bitet foglal el, egy 3-bites morestate pedig hármat. A változólistában persze kihagyásokat is eszközölhetünk (erre szolgál a none), ha az adatok között bármilyen okból szünetet kell hagynunk. Végeredményben az üzenet a kommunikációs céleszköz adott tipusú és adott kezdőcímű adatainak a másolata a VISION globális változókra.

3.4.8. Adatbázisok Az adatbázis taszkok a külső és belső adatbázis-kezelő rendszerekkel való kapcsolat kialakítására és menedzselésére szolgálnak. A VISION program saját adabáziskezelővel is rendelkezik, amelyek a trendek, a gyűjtött adatok és dBase formátumú adatbázisok kezelésére képesek. Ezek az ún. rendszer (értsd: VISION) adatbázisok. Ezen kívül a rendszer képes úgyszólván az összes elterjedt adatbázis-kezelő rendszer integrálására is; vannak olyan adatbázis tipusok, amelyekhez négyféleképpen is illeszkedhetünk. A program kétféle külső (nem VISION-ös) adabázis kezelő rendszert támogat: •

BDE (Borland Database Engine) alapú adatbázis kezelő: Paradox, Dbase, Interbase, Informix, DB2, MS-SQL, MS-Access, Oracle, stb.

•

OLE DB (ADO: ActiveX for Database Objects) Microsoft adatbázis kezelők: MSSQL, MS-Access (Jet), Excel, Oracle, stb.

Már ebből a listából is látható, hogy pl. az MS-SQL egyaránt kiszolgálható Borland és Microsoft alapokon. Tovább bővíti a lehetőségünket az ún. ODBC adatbáziskezelők támogatása – mindkét rendszerben. Ezek a globális DSN (Data Source Name) leírón keresztül férhetők hozzá, ami Borland adatbáziskezelőjében is látható álneveket (ún. alias-okat) generál, így azok megjelennek a VISION-ben is. Maga a konfiguráció a következő objektumok megadását igényli: • •

Adatbázis Táblázat

Az adatbázis a már említett három kategóriából (ti. VISION, BDE és OLE DB) választhadetó, a táblázat pedig az adatbázishoz kapcsolódik. A táblázat egyes mezőit összekapcsolhatjuk a VISION változókkal, az adatműveletek automatizálásának elősegítése érdekében. Az adatbázisok konfurációjánál létrehozhatunk még ún. Query (lekérdező) objektumokat is, de ezeket bárhol máshol, pl. a ciklikus programokban is megtehetjük, ahol az adott adatbázis művelet (pl. select) végrehajtása szükséges.


27

1

3.4.9. Képek A technológia állapotát képeken jelenítjük meg. A képek objektumokból épülnek fel, amelyek éppúgy VAL nyelvű (XSDL) struktúrákat tartalmaznak, mint az alarmok, az adatbázisok, változók, stb. Például egy bár felrajzolása, a BR objektum elhelyzését, majd a tulajdonságok (szín, kitöltés, mintázat, stb.) beállítását igényli. A képen látható objektumok valamennyi tulajdonsága függővé tehető a globális változóktól, amelyek vagy számítások, vagy a kommunikáció révén kapnak értéket (külső eszközöktől, PLC-től, vagy a hálózati szervertől) – ezáltal pedig közvetlenül befolyásolják a megjelenített képelem viselkedését. A képek használhatóságát az előre gyártott objektumok relatív nagy száma biztosítja (bárgráf, trend, szöveg, számkijelző, skála, fájlnéző, legördülő- és beviteli menü, checkbox, rádiógomb, menük, stb.), de a fejlesztő maga is készíthet új objektumokat – szimbólumként, vagy alacsonnyabb szinten: XSDL objektumok megalkotásával. A képek persze nemcsak saját rajzelemekből állhatnak, megjeleníthetők rajtuk Windows bitmapek (bmp, jpg), clipartok (wmf), animációk (gif, ani, flc, fli) és még nagyon sokféle külső forrásból származó képtipus. Az OLE (Object Linking and Embedding) interfészen keresztül pedig Windord dokumentumok, Excel táblázatok, Powerpoint ábrák, Autocad, vagy Corel rajzok is megjeleníthetők – önálló objektumként. További lehetőségként HTML (ill. DHTML) elemeket is felrajzolhatunk. A VISION képeknek alapvetően hatféle tipusa létezik: 1. 2. 3. 4. 5. 6.

Operátori képek (nem görgethető, a főablak teljes megjelenítési felületét használó kép) Extradraw képek (görgethető, a főablak méreténél nagyobb kép) Overdraw képek (különálló ablakok) Szimbólum (ismétlődő képrészletek) Keretek v. sablonok (képenként ismétlődő menük és egyéb keretinformációk) Jelentések (vektorgrafikusan nyomtatható képek, listák) A “képek” gyűjtőszó valójában csak az első két képtipust tartalmazza, mivel önálló képként csak ezek jelennek meg a számítógép főablakában, a többi az operátori kép részeként (szimbólum, keret), vagy különálló ablakban (overdraw), vagy csak nyomtatásban jelenik meg (jelentés).

Az operátori kép a leggyakrabban használt képtipus, mivel a megjelenítésnél nem szerencsés olyan képeket rajzolni, amelyeknek csak egy része látszik, a többi a megjelenítő-felületen (ablakon) kívülre esik. Ezért van kisebb jelentősége az extradraw képeknek, habár ezekre is szükség lehet (nagyméretű térképek, nagykiterjedésű vonalábrák, atomerőművi rávezető indikátor, 28


1

stb.) A görgető funkció ettől függetlenül bekapcsolható operátori képeken is. Erre akkor lehet szükség, ha az ablakot összenyomtuk.

3.4.10. Ablakok (overdraw képek) Az ablakok ugyanolyan VISION-ben rajzolt képek, mint az operátori képek, csak nem a főablakban, hanem a fölött, önállóan jelennek meg. Az ablakokat gyakran overdraw képnek is nevezzük a VISION program (Windows-t megelőző) hagyományaira tekintettel. Az ablakoknak is sokféle tipusa létezik az ablak fejlécétől (caption), az áttetszőségtől és a felrajzolás módjától függően. A VISION ablakok ui. látványos módon: forgatva, nagyítva, vagy áttetszően is megjeleníthetők.

Az ablakok lehetnek modálisak (tiltóak) - ami azt jelenti, hogy az ablakot be kell zárni az alkalmazás további használata előtt -, és lehetnek önálló képek, amelyek fennhagyhatók a képen. Ez utóbbi ablaktipus a Windows összes többi ablaka fölé kerül, így hibaüzenet megjelenítésére különösen alkalmas.

3.4.11. Sablonok A sablon olyan képrész, ami több képre is felrajzolható és olyan közös objektumokat, pl. menüket és más fontos információkat tartalmaz, amelyekre több helyen is szükségünk van. Amikor az operátori képet készítjük, a rendszer felkínálja a rendelkezésre álló sablonokat, hogy a képet már eleve a sablon által megkívánt elrendezésben készítsük el. Ezért a munkát érdemes a sablonok megrajzolásával kezdeni. A sablon készítése egy varázslóval lehetséges, ami az elrendezés (menü felül, alul, jobbra, balra) alapján bemásol alkalmazásunkba egy előre megrajzolt képet. Ezt azután tetszés szerint módosíthatjuk; felrajzolhatjuk rá a saját emblémánkat, kialakíthatjuk az alkalmazás menürendszerét, stb. A sablont persze bármikor később is módosíthatjuk, a változások automatikusan megjelennek majd az összes sablont használó képen. Ezért elsősorban az elrendezést és a menürendszer helyigényét kell rögzítenünk a sablon első változatainak a megrajzolásánál, különben a képeinket is módosítanunk kell. A sablon egyébként a szimbólumokhoz hasonló eljárással rajzolódik a képre, tárolása a szimbólumokkal együtt, a könyvtárban történik (library.xdo). Egy kép csak egy sablont használhat, de a sablonok száma nem korlátozott.


29

1

3.4.12. Jelentések Jelentéseket többféleképpen is készíthetünk a VISION programban. Használhatunk e célra speciális jelentés-készítő objektumot (Rave riport), vagy akár Excel-t is. Ám a leggyorsabb eredményt mégis a képrajzolástól remélhetjük. Amikor jelentést “rajzolunk”, valójában képet szerkesztünk, azonban a megjeleníthető objektumoknak csak egy része férhető hozzá – azok, amelyek vektorgrafikusan nyomtathatók. Ilyenek az alapobjektumok (kör, nényszög, polygon, stb.), a különféle táblázatok és trendek. A jelentés a lap formáját és elrendezését meghagyva kerül kinyomtatásra, ezért készítése előtt már eleve kiválasztjuk a lap méretét és formáját (álló/fekvő, A4, stb.), mielőtt a rajzoláshoz egyáltalán hozzákezdenénk. A jelentésekre elhelyezett táblázatoknak persze nemcsak az adott képen látható része kerül kinyomtatásra, de a táblázatban (adatbázisban) szereplő összes sor – annyi lapon, ahány szükséges. A sorrendben a táblázat fölé/mögé rajzolt képelemek az utolsó lapra kerülnek (pl. az aláírás).

3.4.13. Szimbólumok A szimbólum az ismétlődő képrészek kialakítására szolgáló képtipus. Megrajzolása ugyanúgy lehetséges, mint a többi VISION képé, az összes rajzelem szerepeltethető a szimbólumban is. A szimbólumokat a képre történő felrajzolás (a realizáció) során önálló tulajdonságokkal láthatjuk el. Eleve a pozíció és a méret alapján annyi előfordulása lehet a szimbólumnak, amennyi csak szükséges. A paraméterezésen keresztül azonban változó információkat is hozzárendelhetünk, amelyek a benne foglalt objektumok tulajdonságait egyedileg befolyásolhatják (pl. a tártályszintet, a szelepek állapotát, stb.) Egy szimbólumhoz tetszőleges számú ilyen paraméter rendelhető, értéküket pedig változóktól tehetjük függővé – hasonlóan az objektumok többi tulajdonságához. A szimbólumok tehát nemcsak statikus rajzelemek ismétlésére jók, de a változókon keresztül bonyolyult rajzok, önálló gépek, üzemrészek, stb. megrajzolására is. A VISION program rendelkezik saját szimbólum könyvtárral, amely mintegy 1000 szimbólumot tartalmaz kategorizálva. Egyetlen alkalmazás sem készíthető el azonban önálló szímbólumrajzolás nélkül. Ha egy képrész legalább kétszer megismétlődik egy képen, készítsünk inkább szimbólumot, ahelyett, hogy a képelemeket lemásolnánk. A későbbi módosításokat könnyíthetjük meg ezzel.

30


1

3.4.14. Könyvtárak A könyvtárak tartalmazzák az alkalmazói program közös eljárásait és függvényeit, ill. azok gyűjteményét. Az itt deklarált eljárások az alkalmazói program minden taszkjában “látszanak”, tárolása a Library.XDO adatbázisban történik – hasonlóan a sablonokhoz és a szimbólumokhoz. Amikor új könyvtárat készítünk, a program egy Publics..End struktúrát hoz létre a fájlon belül, ahová a publikálandó eljárások elhelyezhetők. Ezen kívül lehetőleg ne deklaráljunk függvényeket és eljárásokat, mivel azok később nem lesznek meghívhatóak a taszkokból. Akkor sem, ha a lokális eljárásra egyébként magában a könyvtárban kerül sor. Megtévesztő lehet, hogy erre a fordító nem jelez hibát, csak majd később a linker (szerkesztő). Gyakorlatilag ugyanezt lehet elmondani az itt deklarált globális (published v. public) változókról is. Ezek is csak akkor lesznek láthatóak a meghívott eljárásokból, függvényekből, ha azokat valóban publikáltuk is a globális adatbázisba. Általános szabályként ezért azt érdemes szem előtt tartani, hogy a függvények és az eljárások lehetőleg ne hivatkozzanak globális változókra, csak a saját lokális változóikra, ill. az átadott paraméterekre, és ne hivatkozzanak lokális eljárásokra, függvényekre sem. Az eljárások szintaktikája a következő: Eljárásnév:: procedure (par1: tipus1[; pari: tipus]) Begin End A függvényeké pedig: Függvénynév:: függvénytipus function (par1: tipus1[; pari: tipus]) Begin Függvénynév=… ‘értékadás a függvénynek End Ahol a tipus az XSDL nyelv által létrehozott bármilyen adattipus lehet (integer, bool, long, ushort, string, shortstring, Tcolor, stb.), a függvénytipus pedig a függvény visszatérő paramétere. Az eljárás paramétereként átadhatók változóparaméterek (var tipusmódosító után; például i1: var integer) és opcionális paraméterek (optional tipusmódosító után; például i1: optional integer). Mindez persze kombinálható is: i1: var optional integer. A függvények és eljárások további paraméterei és a deklarált tipusok tekintetében érdemes tanulmányozni a rendszerkönyvtárban található VAL.SDL fájlt. Ez tartalmazza az összes rendszerfüggvény prototipusát.


31

1

3.4.15. Bitmapek

1

A bitmapek címszó a külső (értsd: nem VISION) forrásból származó képek gyűjtőneve. Ide tartoznak azok a fájlok, amelyeket hagyományosan is bitmapeknek nevezünk, de a clipartok és az animációs fájlok is. Bitmapek felhasználásával igényesen kivitelezett képelemekkel szépíthetjük alkalmazásainkat, ill. önálló animációkkal bővíthetjük azt. Egy szivattyú megjelenítésére és animációjára számos példa található a könyvtárakban – úgy a bitmapek, mint az animációk között. A bitmapeket a következő kategóriákra osztjuk: 1. Bitmapek: tipikusan BMP, PCX, JPG és GIF fájlok 2. Clipartok: tipikusan WMF és EMF fájlok, vagyis a Windows metafájlok 3. Animációk: tipikusan ANI, FLI és FLC fájlok Az 1. és 3. kategóriában tartozó bitmapek pixelgrafikusak, míg a clipart-ok vektorosak. Ez utóbbi kategória fájljai tehát nem veszítenek látványosságukból nagyítással, kicsinyítéssel, szemben a pixelgrafikus ábrákkal, amelyek a saját felbontásukban a leglátványosabbak. A bitmapek felrajzolása az LD objektummal valósul meg, a felrajzolás módját pedig a fájl tipusa szerint változtathatjuk. Egy bitmap lehet transzparens, árnyékolt, fekete-fehér; az animációk lejátszása pedig előre, hátra, illetve oda-vissza lehetséges. LD-vel azonban nemcsak az eddig ismertetett fájtipusok jeleníthetők meg, de az összes OLE szerver adata is. Ezáltal lehetséges Word dokumentumok, Excel táblák, CorelDraw rajzok megjelenítése is – többek között. Az OLE szerveren alapuló képrajzolásnak azonban hátránya, hogy használatához az illető kiszolgálónak is telepítve kell lennie, így például a Word dokumentumok megjelenítéséhez szükség van a Microsoft Office-ra. A bitmapek forrása Gyakran felvetődő kérdés, hogyan helyezzünk el alkalmazásainkban olyan bitmapeket, amelyeket önálló könyvtárban tárolunk. Habár az LD parancs megengedi, hogy a fájl nevében a teljes elérési utat szerepeltessük, s ezáltal tetszőleges tárhelyen lévő bitmapekre hivatkozzunk, ez mégsem célszerű - az alkalmazás mobilizálása és a Web-en történő közzététel miatt. Ezért célszerű tehát a bitmapeket lokalizálni, vagyis az alkalmazás könyvtárába másolni.

32


Általában olyan fájlokkal célszerű dolgozni, amelyek elérési útja az alkalmazás könyvtárához képest relatív, vagyis az alkalmazásban, vagy annak alkönyvtáraiban helyezkednek el. Ebben az esetben az alkalmazás bármilyen drive-ra átmásolható és az Interneten is közzé tehető. Pontosan erre szolgálnak a Bitmapek címszó alatt található “lokalizációs” parancsok, amelyek a bitmap formátumú vágólapnak a tartalmát és bármely egyéb könyvtár tartalmát képesek az alkalmazás mappájába másolni. Abban az esetben, ha ugyanazokat a bitmapeket több alkalmazásban is meg szeretnénk jeleníteni, akkor a VISION telepítési könyvtárában található BITMAP alkönyvtárban kell elhelyezni egy önálló alkönyvtárban. Ugyanis a program a relatív fájlneveket az alkalmazás könyvtára után itt keresi. Például abban az esetben, ha egy kép neve SAJAT\TARTALY.BMP, akkor e kép egyaránt lehet az alkalmazás könyvtárában nyitott SAJAT mappában, de éppúgy a VISION\BITMAP alatt nyitott SAJAT mappában is.

3.4.16. Függőségek A függőségek a rendszer három adatbázisának (global, library, system) és az alkalmazói fájlrendszernek a kapcsolatát írják le. Amint más magasszintű programnyelvekben, a VISIONben is lehetséges, hogy az alkalmazói fájlrendszer egyes elemei egymás deklarációira hivatkozzanak. Ha pl. valamelyik fájlban létrehozunk egy globális változót (public v. published előtaggal), akkor azt is elő kell írnunk, hogy a globális adatbázis ettől kezdve függjön az illető programmodultól, ahol az adat létrejött (a függőség megadása a global.sdl fájlban történik a #dep, vagy #dec sorában, ahogy azt lentebb részletesen is bemutatjuk). Annak érdekében, hogy a fájlrendszer kezelése ne legyen túl komplikált, konvenciókat alkalmazunk. A rendszer ezen alapértelmezések szerint automatizálja a működtető adatbázis függőségeinek a beállítását. A rendszer adatbázisai alapértelmezésben a következőktől függenek: • • •

A globális adatbázis csak a változó-deklarációs fájloktól és a unitoktól függ A könyvtár csak a szimbólumoktól, a sablonoktól és a saját könyvtáraktól függ A rendszer adatbázis csak a súgótól és az struktúráktól függ

Abban az esetben pl., ha új változó-deklarációt készítünk, a program automatikusan frissíti a globális adatbázis függőségeit – hozzáfűzi a függőség-listához az új fájlnevet. Ugyanez történik a könyvtárelemként értelmezett szimbólumok, sablonok esetében is, vagy, amikor új VISION X általános leírás

33

1

könyvtárat készítünk a saját függvényeink, eljárásaink számára. A unitok függőségei is automatikusan jönnek létre, amikor új unit-objektumokat, majd unitokat deklarálunk. Mindebből pedig az következik, hogy a fejlesztőnek nem kell foglalkozni a függőségek beállításával, azt a rendszer automatizálja. Azonban abban az esetben, ha globális változókat valamiért nem a változó-deklarációs fájlban, hanem egy képben, vagy a ciklikus programban szeretnénk felvenni, annak függőségét már nekünk kell beállítani. Ugyanez a helyzet akkor, ha egy alkalmazásba kézzel másolunk be szimbólumokat, unitokat. A függőségek grafikus beállítására szolgál a rendszerkonfigurációs kép, de a megfelelő Global.sdl és Library.sdl fájlok szövegszerkesztővel történő módosítása sem túl komplikált feladat. Ehhez a fejezet végén adunk használható tanácsokat. 3.4.16.1. Összehasonlítás más programozási nyelvekkel Más programozási nyelvekkel összehasonlítva szembeötlő különbségek vannak. Az elterjedt nyelveken (C++, C#, Delphi, Visual Basic, stb.) a programrendszer elemeinek a függősége azáltal jön létre, hogy az exportált adatokat külön include-, ill. header-fájlokba, vagy – mint a Pascal esetében – interfészekbe írjuk. Egy programmodul azáltal képes elérni egy globális változót, hogy az illető deklarációt maga is inkudálja; vagy úgy, ahogy a C-ben megszoktuk (#include), vagy úgy, ahogy a Delphi/Pascal csinálja (uses). Az XSDL nyelven mindez egyszerűbb, mert nem kell felsorolnunk az XDO adatbázis előállításáért felelős összes fájlt azokban a képben, programokban, amelyek hivatkoznak az adatokra. Valójában a programoknak nem is kell azt tudniuk, hogy melyik modul felelős az illető adat előállításáért – ahogy egy DLL-ről sem kell azt tudnunk, hogy milyen fájlok lefordításával keletkezett. Az XDO tehát pont úgy viselkedik, mint egy könyvtár. Ez a megoldás a fájlrendszer túlnyomó részét kitevő képek és más taszkok programozását teszi kényelmessé, hátránya viszont, hogy az XDO előállításáért felelős modulokat a Global.SDL/Library.SDL/System.SDL fájlokban meg kell adni. Az előző fejezetben ismertetett konvenciókat alkalmazva azonban még ezzel sem kell törődnünk. 3.4.16.2. A függőségek szintaktikája a rendszerleíró fájlokban A két legfontosabb rendszerleíró fájl, aminek a grafikus szerkesztését a függőségek képen végezzük, a Global.SDL és a Library.SDL. Ezek a fájlok a megfelelő XDO adatbázisok ún. target fájljai, vagyis ezek tartalmazzák az XDO generálási utasításokat. Ezek legfontosabb elemei a #dep, vagy #dependency sorok: #dep képnév1, képnév2,… Ez azt jelenti, hogy az XDO adatbázis függ a képnév1.val és a képnév2.val nevű fájloktól (pl. szimbólumoktól). Vagyis a fordítónak először a képnév2, majd a kénév1 fájlokat kell lefordítania, mielőtt magát az eredmény adatbázist (Global.xdo v. Library.xdo) előállítja, mivel ezek a fájlok – az utasítás szerint – tartalmaznak az adott adatbázisba publikálandó adatokat (eljárásokat, függvényeket). A Global.sdl és a Library.sdl fájlban több #dep sor is lehet, a kiértékelés pedig hátulról visszafelé történik. Ezt akkor kell tudnunk, ha pl. a képnév1 tartalmaz olyan hivatkozásokat, amelyeket a képnév2-ben állítunk elő. Ekkor a helyes sorrend a példabeli. Vegyük észre:

34


1

cirkuláris hivatkozások nem megengedettek. Vagyis a képnév1 már nem tartlmazhat olyan deklarációkat, amiket a képnév2 használ. 3.4.16.3. Unitok függőségei Fontossága miatt külön foglalkozunk a UNIT-ok függőségeinek a beállításával, amenyiben a Global.sdl fájlt kézzel állítjuk elő, ill. kézzel módosítjuk (mert egyébként a bevezetőben említett automatizmus itt is érvényes). A megfelelő deklarációs sorok felépítése ebben az esetben a következő: #uni ahol a unithivatkozás tartalmazza a unit-alkalmazás változódeklarációjának az elérési útját (ált. relatív elérésű alkönyvtárát és a var fájl nevét), valamint a unit-ok nevét a következő formában: :

unit_var_file(unit1[uniti])

A unit1 az első unit neve, uniti pedig a következőké. Például: #uni hutes\var(RH1,RH2,RH3,RH4) Itt RH1, RH2… az egyes unitok nevei, publikálásukért pedig a hutes alkönyvtárban lévő var.val változódeklarációs fájl felelős.

3.4.17. Unitok A “unit” a VISION program legmagasabb szintű, s egyben rendkívül hasznos objektuma. Tulajdonképpen egy komplett alkalmazás, benne változókkal, képekkel, szimbólumokkal, alarmokkal, feldolgozó prgoramokkal, jelentésekkel, stb. Felhasználása ismétlődő komplex alrendszerek esetén célszerű. Például abban az esetben, ha egy átemelő, vagy egy kút önálló unitként készül el, csupán egyszer kell azt kidolgozni, s a tucatnyi kútból és átemelőből álló teljes alkalmazásban azok változói és képei automatikusan megismétlődnek. Unitok alkalmazásával nagyságrendekkel csökkenthető az alkalmazásfejlesztésre szánt munka, mivel a változóknak csupán a töredékét kell felvennünk, s ami még ennél is fontosabb, csak ezt a töredék változót kell animálnunk, ill. alarmok és jelenések formájában feldolgoznunk. További előny az alkalmazás áttekinthetősége és könnyed bővíthetősége, hiszen bármilyen apró módosítás, hibajavítás automatikusan kiterjed az egész rendszerre – a hiba, hogy valamelyik rendszert véletlenül kifelejtettük, kizárt.


35

1

1

A unit tehát alapvető fontossággal bír a moduláris és skálázható ipari folyamatmegjelenítő rendszerek kifejlesztésénél. A unit felvétele a unit-objekt alkalmazás kifejlesztése után (a példában ilyen a ‘kut’ és a ‘gephaz’), egy önálló név megadásával történik. Ez a név a unitban foglalt képek, alarmok, változók, stb. elé íródik, így például a unit főképének a hivatkozása az U1 unitban U1.FOKEP, az U2 unitban U2.FOKEP, stb. lesz. A unitok egymásba is ágyazhatók és hierarchikus rendszert alkotnak.

3.4.18. Külső programkapcsolat A VISION program nemcsak a saját magasszintű (XSDL vagy XVAL) programnyelvén programozható, de Visual Basic-ben, Delphi-ben, C-ben, .NET-ben is. A külső csatolás a VISCOM.DLL fájlon keresztül lehetséges, ami közvetlen kapcsolatot tud létesíteni a VISION változókkal. A Delphi, C++ és a Visual Basic esetében ráadásul a VISION e programok interfész adatbázisát is előállítja, ami azt jelenti, hogy a VISCOM.DLL által átadott változótáblára az adott nyelv szintaktikájának megfelelő globális változókkal hivatkozhatunk. Ez rendkívül gyors és kényelmes módszer, hiszen nem kell bonyolult transzfer eljárásokkal bíbelődnünk, a VISION változókat az adott nyelvben közvetlenül írhatjuk-olvashatjuk.

36


3.4.19. Erőforrások

1

A VISION program tartalmaz egy on-line erőforrás fordító programot, ami képes a Windows erőforrás fájlok beolvasására és értelmezésére. Az erőforrások nagyon sokfélék lehetnek: tartalmazhatnak bitmapeket, ikonokat, kurzorokat, szöveg táblákat, de önálló dialóg ablakokat is. A VISION esetében a • •

bitmapek és szövegtáblák

alkalmazására a leggyakoribb. Gondoljunk a többnyelvű alkalmazások problémájára. Abban az esetben, ha egy alkalmazásnak több nyelven is futnia kell, közvetlen szövegek helyett, az erőforrás azonosítóját használhatjuk, így nyelvváltáskor az automatikusan cserélődik. A többnyelvű alkalmazások, ill. a nyelvi adatbázisok elkészítésére azonban a VISION X sorozata egy Excel táblára épülő automatikus nyelvi adatbázis generáló módszert is felkínál, amelynek az a lényege, hogy a program az új szövegeket automatikusan felveszi egy Excel táblába, s amennyiben nyelvváltás történik a tábla további oszlopaiban található nyelvekre lecseréli azokat. Nem kell tehát erőforrás azonosítókkal bíbelődnünk, használhatjuk a saját anyanyelvünket. Ezért az erőforrások használata egyre inkább a bitmapekre korlátozódik. Felvetődik a kérdés, hogy miért célszerű a bitmapeket erőforrás fájlokban tárolni, ahelyett, hogy önálló fájlként kezelnénk őket. A válasz egyszerű: a sebesség miatt. Ugyanis az erőforrásokat a program induláskor tölti be, így az abban foglalt bitmapek megjelenítése sem igényél további diszkműveleteket. Ilyen erőforrás-fájlokban találhatók egyébként a VISION program saját ikonjai is (Resource alkönyvtár), több ezer. Egy részükre a VISION alkalmazásokban is hivatkozhatunk (ld. BM objektum)

3.4.20. Információs rendszerek Az információs rendszerek bevezetése vadonatúj programszolgátatások előtt nyitott kaput. Alkalmazásainkat ezentúl néhány egérkattintással bővíthjük vevők, szállítók nyilvántartására szolgáló adatbázis kezeléssel, és a műszaki információs rendszerek leírására, kezelésére, valamint a hibakezelések és a karbantartások menedzselésére szolgáló önálló program modullal. Természetesen a VISION architektúrákra illeszkedő módon, ill. integrálva a megjelenítő rendszer működtető adatbázisaihoz. A karbantartási periódusok ui. hozzárendelhetők a VISION-ből érkező és a gépészetet leíró fa-struktúra leveleihez kapcsolt mennyiségi- és üzemóra változókhoz. Az adott gépelemkészlet pedig előhívható akár a grafikus kép objektumaira kattintva. Hab a tortán, hogy a meghibásodások, karbantartások regisztrálása közvetlenül befolyásolja az architektúra elemeit, így a képen látható grafikus objektumok viselkedését – hiba esetén pl. a program elszürkíti a szimbólumokat. A program emellett képes e-mailt, SMS-t küldeni (azon a nyelven, amelyen a fogadó beszél!), hozzárendelhetők az eszközökhöz fotók, kameraképek, persze maguk a VISION objektumok és csatolt dokumentumok (DOC, XLS, HTML, PDF, stb.) - tetszés szerint.


37

3.4.21. Csatolt dokumentumok Alkalmazásainkhoz csatolt dokumentumokat fűzhetünk Word, Excel, PDF, AutoCAD, vagy bármilyen egyéb módon. A csatolt dokuementumok között szerepeltethetők például fotók, IO listák, a felhasznált berendezések adatlapja, a tesztelési eljárás eredményei, a validációs jegyzőkönyvek, stb. Az ilyenformán csatolt dokumentumokat azután maga a VISION program is képes megjeleníteni – feltéve, hogy az adott program OLE szervere is rendelkezésre áll. Ez Word esetében például az Office telepítését igényli.

3.4.22. Saját súgó A VISION alkalmazásokhoz készíthető saját súgó, amelynek fejezeteire, ill. az egyes dokumentumokon belüli könyvjelzőkre a VISION alkalmazás objektumaiból is hivatkozhatunk, de a tartalma megjelenik a VISION projekt-menedzserében is. Ezáltal viszont ún. szelektív súgó készítésére nyílik lehetőségünk. Saját súgónk éppúgy struktúrákat képez, mint bármilyen architektúra; állhat önálló könyvekből, azon belül fejeztekből, alfejezetekből és paragrafusokból – tetszés serint. A súgó egyes oldalai is lehetnek igen sokfélék; a leggyakrabban e célra Word-öt, vagy más HTM formátumú dokumentum előállítására alkalmas eszközt használunk. Ez utóbbi (HTM) formátum azért is célszerű, mert a megjelenítéséhez nem szükséges a forrás előállítására szolgáló OLE szerver (mint a Word dokumentum esetén az Office), hiszen az Internet böngésző ma már minden operációs rendszernek része. Ráadásul lehetővé teszi látványos grafikai elemek, pl. Flash animációk felrajzolását is. Végeredményben az alkalmazás saját súgója a felhasználó igényeihez leginkább alkalmazkodó módon képes leírni a teljes alkalmazói rendszert, annak fejezeteit pedig az alkalmazás képeihez, vagy folyamataihoz kötötten tudja felkínálni. A dolog érdekessége, hogy a VISION súgó is ugyanazon a konfigurációs nyelven kerül leírásra, amelyen egyébként a képek vagy a változók, tehát a szelektív súgó az alkalmazói fájlrendszerhez szervesen illeszkedik. A VISION program saját súgója is ugyanolyan módon készült, mint az alkalmazói programoké. Ennek XSDL forrásdokumentuma a VISION telepítése könyvtára alatt a HELP-ben található, vision.sdl néven.

38


1

3.4.23. A VISION rendszer származtatása

1

A rendszer érdekes tulajdonsága, hogy annak teljes leírása, a képek/ablakok felépítése, a kommunikáció, az adatbázisok struktúrája, a jelentések, de maguk a projektek is ugyanazon az XSDL programnyelven készültek, mint a VISION alkalmazások, tehát a rendszer generáló nyelve ugyanaz, mint az alkalmazásoké. Ezáltal viszont bárki készíthet új változóvagy képtipusokat a VISION-höz, megváltoztathatja a projektek komponenseit, az objektumok tulajdonsagait – amennyiben az XSDL szolgáltatásokat részleteiben is elsajátítja.

A VISION rendszer tulajdonképpen ebbe a deklarációs világba enged betekintést. Azt mutatja be, hogy jöttek létre a VISION változótipusai, objektumai, majd azok felhasználásával a képek, alarmok, adatbázisok és végül a projektek. Habár a rendszer generáló állományaihoz szerkeszői jogosultságokkal hozzáférhetünk, lehetőleg ne módosítsuk a rendszerleíró fájlok tartalmát, hiszen meglévő alkalmazásaink működése függ ezektől.


39

1

Projektek Előszó: A VISION-ben az alkalmazásokat projektek írják le. Azonban egy alkalmazás nem feltétlen egy projekt, tartalmazhat akár több projektet is összevonva (szuperprojekt). A projekt magának a projekt fájlnak az elindításával indítható (VPR kiterjesztésű), vagy a projekt listából való kiválasztás után.

Tartalomjegyzék: 1. Bevezetés.............................................................................................................................. 41 1.1. Önálló projekt lista ........................................................................................................ 41 2.2. Beépített projekt lista .................................................................................................... 42 2. Projekt készítése................................................................................................................... 43 2.1. Projekt-típusok .............................................................................................................. 44 3. Projekt módosítása ............................................................................................................... 47 3.1. Módosítás az önálló projekt listában............................................................................. 47 3.2. Módosítás a VISION projektben................................................................................... 48 4. Meglévő projekt felvétele..................................................................................................... 49 4.1. Tömörített projekt felvétele........................................................................................... 50 4.2. Tömörítetlen projekt felvétele ....................................................................................... 50 5. Projekt törlése....................................................................................................................... 51


40


1. Bevezetés A VISION alkalmazói program a projekt fájlra épül, ami ugyanolyan XSDL szintaktikájú fájl, mint az összes többi, csak a megkülönböztetés érdekében VPR (Vision Project) kiterjesztést kapott. Amennyiben a VPR kiterjesztéshez társítottuk a projektek összevont futtatásáért felelős VPR.EXE programot (ez a program installálásával megtörténik), akkor bármelyik VPR fájlra kattintva elindítható a projekt. A projektek kezelésére azonban számos további szolgáltatás áll a rendelkezésünkre.

1.1. Önálló projekt lista A projektek önálló menedzselésére szolgál a VPL.EXE (Vision Project List) program, ami az alábbi ábrán látszik:

Innen ugyanúgy készíthetünk uj projekteket, mint magából a VPR programból (ld. később), továbbá módosíthatjuk a meglévőket, vagy törölhetjük azokat igény szerint. A projekt listában lehetőség van még a projektek szűrésére is a projekt osztály megadásával. Eszerint az alábbi projekt osztályokat különböztetjük meg:

Projektek

41

2

• • • • • • •

Alapértelmezett – nincs meghatározva a projekt-osztály Tesztprojekt – a projekt teszt célokat szolgál Alkalmazás – valódi (üzembe helyezett) alkalmazás Demonstráció – demo program Gyakorlat – betanulás során készített példaprogramok Oktatás – oktatás céljából készített példaprogramok Prezentáció – bemutató, előadás céljából készített projekt

A végleges projektek osztálya az alkalmazás, de a projekt célja szerint készíthetünk számos további projektet is. Az osztályozásnak azonban csak a szűrés miatt van jelentőssége, hogy ezáltal nagy számú projektet tartalmazó számítógépünkön könnyen meg tudjuk találni a kérdéses projektet. További szűrések jobb egérgomb menüvel lehetségesek. Innen választhatunk csak unit-okat, szuperprojekteket, azaz összevont projekteket és kliens alkalmazásokat – akár kombinációban az előzőekben ismertetett projekt-osztályokkal.

2.2. Beépített projekt lista Maga a VPR program (Vision Project) is képes a projektek menedzselésére, csak nem olyan sokrétűen, mint az önálló VPL program. Ez a projekt lista a program elindítása után megjelenő menüből Projekt kiválasztása listából opciót választva, vagy a toolbox alábbi ikonjára kattintva jelenik meg:

Ennek hatására jön elő az alábbi ablak: A Projekt indítása dialógusban hasonló műveleteket végezhetünk, mint a különálló projekt kezelőben: készíthetünk új projektet, vagy törölhetjük a meglévőeket. Szerkesztésre azonban itt nincs lehetőség, csak akkor, ha megnyitjuk a projektet és a VPR későbbiekben ismertett komponens szerkesztő ablakában megváltoztatjuk azt. A default projekt beállítása azért hasznos, mert ezáltal egy projekt a sok közül kiemelésre kerül; ez látszik a bejelentkező menü legfelső sorában (pl. Programszolgáltatások) és a lista is erre a sorra fókuszál, amikor megnyitjuk.

42

Projektek

2

2. Projekt készítése Projekt készítése lehetséges:

a

létrehoz

gomb

megnyomásával

2

De az indító menü is tartalmaz egy Új projekt menüpontot (ld. oldalt) és a futó VISION projekt megfelelő jobb egérgomb menüje, sőt a projekt legördülő menü is. Bármelyiket használhatjuk. Ezt megnyomva jelenik meg az Új projekt varázsló alább látható dialógusa:

Projekt-típusok

Ebben a projekt-név a projekt fájlnév, a cím és a leírás megadása a legfontosabb. A projekt fájl neve a projekt nevéből automatikusan öröklődik, akárcsak a cím, ezért először a nevet érdemes megadni, majd TAB-ot gépelni. Persze más könyvtár is megadható, mint amit a program felkínál. Kérjük, válassza ki a megfelelő felbontást is, mivel – noha vektorgrafius a rendszer – a legjobb minőséget akkor kapjuk, ha ugyanabban a felbontásban futtatjuk, mint amiben fejlesztettük. Különféle projekt-típusok léteznek. Ezek a default, az üres, a kliens, a unit, az összevont és a a felhasználói profilok egész sora, köztük az ún. szabványos profillal. Ez utóbbiak adott struktúrákkal, menükkel, keretekkel, adatbázisokkal előkészített keretalkalmazások. Célszerű ilyeneket a saját magunk számára is készíteni, hiszen adott területre szánt alkalmazásaink hasonlóak lehetnek. A saját profilok a rendszer Profiles könyvtárában szerepelnek, ide kell bemásolni mintaalkalmazásainkat. Nézzük azonban végig az összes projekt-típust:

Projektek

43

2.1. Projekt-típusok Az alábbi alap projekt típusok léteznek:

2

Default projekt:

A default projekt az alapértelmezett fájlrendszert tartalmazza, benne ciklikus programmal, alarm programmal, szervízzel, kommunikációval, stb. Ám ezeket a fájlokat a program üresen hozza létre

Üres projekt:

Üres projekt készítésével olyan fájlrendszert kapunk, ami nem tartalmaz fájlokat, csak a projekt struktúrát. A rendszer komponenseit ilyenkor egyenként kell létrehoznunk

Hálózati kliens:

A hálózati kliens alkalmazás arra szolgál, hogy általa szerverrel létesítsünk kapcsolatot. A hálózati kliens kiválasztásakor az alábbi képet kapjuk:

Ebben az ún. LinkPrefix megadása szükséges úgy, hogy kikeressük a szerveren az alkalmazás VPR fájlját. Ez lesz a szerver projekt könyvtára. Fontos, hogy az így kikeresett projekt neve azonos legyen azzal, amit az előző lapon megadtunk. Ezt a körülményt a program meg is vizsgálja nekünk. Eltérés esetén ezt a hibaüzenetet kapjuk:

Unit:

A Unit egy speciális alkalmazás típus, ami arra használható, hogy mint obnjektumot építsük be azt főalkalmazásainkba. Unit készíthető minden összetettebb alrendszerről, szabályzóról, műszerről, átemelőről, gépházról, szivattyú telepről, stb. A unit a modularizálást segíti, s mint ilyen, az ismétlődő komplex alrendszereket tartalmazó alkalmazások leghasznosabb eleme. A Unit megadásakor ugyanúgy további beállításokat kér a program tőlünk, mint a kliens alkalmazás esetén:

44

Projektek

2

Ezen a képen az ún. Unit előtagok adhatók meg, ami megkönnyíti majd a unit-ok felvételét a főalkalmazásba, hiszen nem kell azzal bíbelődnünk, hogy begépeljük a unit nevét, rövid nevét és leírását – feltéve, hogy elég ügyesen adtuk meg az előtagot. Az URL pedig a publikálásra szánt unit-ok internetes linkje, hiszen lehet, hogy a műszerünkről, vagy egy kommunikációs berendezésünkről készítettünk unit-ot, vagyis a cégünk által fejlesztett valamelyik termékről. Ilyenkor a unit reklámhordozóként is funkcionálhat, vagy egyszerűen csak információkat közvetít ezen a módon. Összevont alkalm.:

Az összevont alkalmazás különálló projektek összevonásával keletkezik. Elindulásakor az összes benne foglalt projekt betöltődik és párhuzamosan fut. Például több üzem önálló projektjeit egy külön integrált projekt formájában egyesíthetjük és megjeleníthetjük az üzemvezető számítógépén. Természetesen itt is szükség van további információkra, hogy ti. mely projekteket szerenénk összeválogatni:

A kép bal oldalán a meglévő projektjeink látszanak, a jobb oldalon pedig azok, amiket össze kívánunk vonni. A válogatás a hozzáadás –

Projektek

45

kivonás parancsokkal (gombokkal) lehetséges, vagy egyszerűen csak dupla kattintással a megfelelő listában. Fontos, hogy egynek a projektek közül főprojektnek kell lennie (ez látható a képen jobb alul). A főprojekt kiválasztása jobb egérgomb menüvel történik: kiválasztás főprojektként. Ekkor beíródik a kiválasztott projekt a jelzett cellába és a szuperprojekt befejezhető. A szuperprojektekkel kapcsolatban érdemes tudni, hogy lehetséges a bennük foglalt változók közötti adatcsere és ráválthatunk egyik projektből a másikra, tehát mint egyetlen óriás projektet kezelhetjük. Ez úgy történik, hogy a megfelelő képnév vagy változónév elé a @1, @2, stb. szövegrészt írjuk, ahol a szám a projekt sorrendjére (és nem a nevére) utal. Például a másodikként deklarált projekt főképére az exec “@2.fokep” paranccsal válthatunk. Profilok:

A felhasználói profilokkal kapcsolatos legfontosabb információkat már ismertettük, s ennél több nem is mondható el róluk, mivel a konkrét céljuk és funkciójuk az adott feladatkörhöz kötött. Létezik azonban a VISION-ben erre pár példa: Click&Move application:

AMC (Advanced Motion Control) keretalkalmazások

HAGA alkalmazás:

HAGA szabályzókat tartalmazó keretalkalmazások

Nivelco alkalmazás:

Nivelco szintmérőket tartalmazó tartályparki keretalkalmazások

VISNAP Video Client:

VISNAP Video megfigyelő kliens alkalmazás, ill. keretalkalmazás

Ez a lista azonban saját profilokkal bővíthető. Csupán az szükséges, hogy a minta alkalmazásunkat bemásoljuk a VISION Profiles alkönyvtárába. Ilyenkor még fontosabb, hogy az alkalmazásnak saját leírása és ikonja legyen, hiszen épp ezek jelennek meg a projekt-típus listában. Amenyiben van egy 137x368 pixel méretű képünk, azt ProjectBanner.bmp néven ugyancsak kimenthetjük az alkalmazás könyvtárába, hogy az új projekt választás képen megjelenjen, amikor a profilt kiválasztottuk – haszonlóan a példa profilokhoz:

46

Projektek

2

AMC:

HAGA:

VISNAP:

NIVELCO:

2

3. Projekt módosítása Szükség lehet arra, hogy a projekt fő adatait, nevét, címét, projektfájlját, leírását, ikonját, felbontását, stb. módosítsuk később. Ezek szerkesztésére, módosítására kétféle lehetőség is kínálkozik.

3.1. Módosítás az önálló projekt listában A fejezet elején bemutatott projekt listában (VPL.EXE) a projekt egyszerűen a szerkesztés gomb megnyomásával módosítható. Ennek hatására ugyanaz a dialógus jelenik meg, mint a projekt készítésekor, így a módosítás is abban az ablakban végezhető el, mint amiban az új projekt készült:

Látható, hogy a projekt típusa utólag már nem változtatható, csak újrakreálással.

Projektek

47

3.2. Módosítás a VISION projektben A futó projekt fő adatai a VISION projektben (VPR), tehát a futó programon belül is megváltoztathatóak. Mégpedig ugyanúgy komponens-elem szerkesztéssel, mint a képek, vagy a konfiguráició. Ugyanis maga a projekt is egy önnálló komponenst alkot.

Fő adatok: név, fájlnév, cím, leírás, felbontás, ikon és projekt-osztály

A projekt módosításához tehát vissza kell kattintanunk a projektmenedzserben a legelső sorra – ez a projekt-komponens, ami a projekt fő adatait tartalmazza. Majd kapcsoljunk szerkesztés üzemmódba a szokásos módon: Ctrl+Alt+E, vagy toolbox: Ennek hatására a projekt szerkeszthetővé válik és a fő adatok módosíthatók. A projekt típusának és könyvtárának a megváltoztatására azonban most sincs lehetőség. Végül a projekt adatai szövegszerkesztéssel is átírhatók, hiszen az összes adat valójában a VPR fájlban van, ami egy XSDL szintaktikájú szövegfájl. Ha VISION-ben választunk szövegszerkesztést – grafikus szerkesztés helyett –, akkor a jobb oldalon látható ablakban tudjuk a projektünket módosítani. Néha ez a módszer egyszerűbb. A VPR amúgy szövegesen tartalmazza a konfiguráció összes beállítását, de a képek és a szimbólumok listáját is. 48

Projektek

2

4. Meglévő projekt felvétele Előfordulhat, hogy olyan projektet szeretnénk megjeleníteni a VISION-ben, ami máshol keletkezett. Például, amikor a saját fejlesztő gépünkről szeretnénk átmásolni a projektet a végleges helyére. Ilyenkor a célszámítógépen még nincs rajta a projektünk, ezért azt úgy kell ott létrehozni, hogy a meglévőt rámásoljuk. A projekt a célszámítógép bármely könyvtárába egyszerűen felmásolható és a VPR fájl elindításával elindítható. Ez azonban még nem elegendő, a projektet a projektek listájába is fel kell venni, vagyis a projektet regisztrálni is kell. Ez többek között azért szükséges, mert bizonyos adatok – pl. a projekt felbontása és típusa – a projekt listában vannak megadva. A meglévő projektet ezért a projekt varázsló alább látható Meglévő hozzáadása gombjával kell felvennünk a rendszerbe:

Ezt megnyomva az alábbi dialógus jelenik meg: Itt azt kell eldöntenünk, hogy a projekt tömörítve, vagy tömörítetlenül áll-e a rendelkezésünkre. A tömörített projekt VPK kiterjesztéssel bír (valójában ZIP fáj) és a VISION projekt archiválójával jön létre. A projektet tehát ebben a tömörített formájában is mozgathatjuk, egyetlen kisméretű fájlként. De annak sincs akadálya, hogy az egész projektdirektorit másoljuk át a célszámítógépre. Ez a tömörítetlen fájlok esete.

Projektek

49

2

4.1. Tömörített projekt felvétele Amenyiben a projekt VPK kiterjesztésű, tömörített formában áll a rendelkezésünkre, a következőt kell tenni: Meg kell adni a tömörítetlen projekt helyét (ez lehet pl. a pendrive-unk), majd a célkönyvtárt, amit a VISION projekt könyvtára alatt érdemes kialakítani, hogy megőrizzük a fájlnevek relatívitását. A projektet a program a Befejez gomb megnyomásakor kitömöríti a megadott célkönyvtárba.

4.2. Tömörítetlen projekt felvétele Amennyiben tömörítetlen formában áll rendelkezésünkre a projekt, további két lehetőség van: 1. Azt a könyvtárat használjuk, amit a tallózóval kikerestünk 2. Vagy egy másik könyvtárat, ahová a fájlokat a programmal át akarjuk másoltatni Ez utóbbi eset látszik a következő képen. Tehát ebben az esetben a program ismét másol, csak most nem kell közben kitömörítenie a fájlokat. Ha kész, nyomjuk meg a Befejez gombot.

50

Projektek

2

5. Projekt törlése A projekt törlésére is többféle lehetőség van. Egyrészt kitörölhetjük a projektet az önálló projekt lista programban és a VISION projekten belül is. A törlés azonban nem feltétlenül jelenti magának a projektnek (a projekt fájloknak) a törlését, alapesetben a törlése csak a projekt listából való eltávolítást jelent.

Ezután a program rákérdez, hogy a projekt fájljait is törölni kívánjuk-e.

Ekkor semmisíti meg a program a projektet teljesen, egyébként csak a regisztrációját törli.

Projektek

51

2

Változók Előszó

2

A VISION rendszerben a változók központi helyet foglalnak el. Úgy is fogalmazhatunk, hogy a VISION változó-orientált rendszer. Változókon keresztül kommunikálnak egymással a taszkok, ezek határozzák meg a grafikus objektumok tulajdonságait, kapcsolják össze egymással az adatbázisokat, az objektumokat, s persze a vezérlőberendezésből beolvasott adatokat is változókban tároljuk el. A folyamat felől érkező adatok, valamint a belső számítások eredményeinek a tárolására a VISION-ben 10-féle változótípust használunk. Ezeket foglaljuk össze a következőkben.

Tartalomjegyzék: 1. Bevezetés........................................................................................................................................... 53 1.1. Változótípusok ........................................................................................................................... 54 1.1. Konzisztens változótáblák, új tábla készítése ............................................................................ 55 1.2. Táblázat- és szövegszerkesztés .................................................................................................. 56 2. Változódeklaráció.............................................................................................................................. 56 3. Közös szerkesztői műveletek ............................................................................................................ 58 3.1. Új változó létrehozása................................................................................................................ 58 3.2. Változó törlése ........................................................................................................................... 58 3.3. Változó átnevezése..................................................................................................................... 58 3.4. Léptetés ...................................................................................................................................... 58 3.5. Keresés ....................................................................................................................................... 59 3.7. Excel export, import................................................................................................................... 59 3.8. Mentés........................................................................................................................................ 59 3.9. Egyéb műveletek........................................................................................................................ 61 4. Változótípusok................................................................................................................................... 62 4.1. Analóg változók ......................................................................................................................... 62 4.2. Analóg trendváltozók................................................................................................................. 64 4.3. Lebegőpontos változók .............................................................................................................. 65 4.4. Lebegőpontos trendváltozók ...................................................................................................... 66 4.5. Egész változók ........................................................................................................................... 67 4.6. Szöveg változók ......................................................................................................................... 68 4.7. Típusdeklaráció.......................................................................................................................... 69 4.7.1. Attribútum tábla.................................................................................................................. 69 4.7.2. Attribútum táblák megadása ............................................................................................... 70 4.8. Diszkrét változók ....................................................................................................................... 71 4.9. Diszkrét trendváltozók ............................................................................................................... 72 4.10. Többállapotú változók.............................................................................................................. 73 4.11. Többállapotú trendváltozók ..................................................................................................... 74 4.12. Konstansok............................................................................................................................... 75 5. Változók strukturálása....................................................................................................................... 76 6. Változóreferenciák ............................................................................................................................ 78 6.1. Analóg- és analóg trendváltozók referenciái.............................................................................. 79 6.2. Lebegőpontos- és lebegő-trendváltozók referenciái .................................................................. 79 6.3. Diszkrét és többállapotú változók referenciái ............................................................................ 80 6.4. Szövegváltozók referenciái ........................................................................................................ 80


52

Projektek

1. Bevezetés A változók kezelése – néhány specialitást leszámítva – hasonlít más programozói rendszerekhez (C, VB, Delphi). Így például a kétállapotú ún. diszkrét változó Byte típusú (nem Bool), a számítások eredményeit pedig tipikusan 4 byte-os Float típusú, azaz lebegőpontos változókban tároljuk el (Pascal-ban Single). A különbségek egyrészt a trendekkel, másrészt az ún. nyersérték fizikai mértékrendszerbe való átskálázásával kapcsolatosak. Az egész típusú adatok ui. egy belső leképzésen mennek át, valahányszor az illető adatra hivatkozunk - legyen az akár a képernyőre való kiírás, vagy egy képlet kiértékelése. Ennek a leképzésnek, vagy átskálázásnak az eredményeképpen kapjuk meg a fizikai mértékrendszernek megfelelő mérési adatokat. Ebből következik, hogy az analóg változók valójában mind lebegőpontosak, a típusmegadás (integer, byte, word, long, stb.) itt a nyersértékre utal. Külön is kiemeljük, hogy az átskálázásra mindig csak a hivatkozás pillanatában kerül sor, az adatok egyébként abban a formában kerülnek eltárolásra, ahogy azt a terepi számítógéptől (PLC) kaptuk. Ez a körülmény a rendszer validálásánál lehet érdekes. További sajátosság, hogy bármely diszkrét, analóg, lebegőpontos, stb. változóról készíthető történeti trend is – egyszerűen a változó típusának a megfelelő megadásával. A trendkészítés tehát nem önálló funkció, hanem változótipushoz rendelt tulajdonság. A másik érdekes speciális változótípus az ún. többállapotú változó, ami a kétállapotú diszkrét jelek kiterjesztésével keletkezik. Ahogy a neve is mutatja, ez a változótípus egyszerre több állapotjel kombinációjának a megjelenítésére használható, legtöbbször a komplex gépészeti elemek (szelepek, szivattyúk, motorok, stb.) leírására szolgál. Amint látni fogjuk, a többállapotú változó nemcsak az állapotjelzéseket, de a vezérléseket, tehát a kimenő parancsokat is magában foglalhatja a komplex gépelemre kiadott parancsok és visszajelzések kombinált megjelenítését eredményezve. A változók valójában objektumok a VISION-ben, aminek nemcsak értéke, de számos további paramétere is van (pl. minimuma, maximuma, dimenziója, stb.). A változódeklaráció során tulajdonképpen ezeket az extra adatokat adjuk meg, amire hivatkozhatunk magában az alkalmazói programban. E lehetőségeket a fejezet végén mutatjuk meg a változóreferenciák ismertetésekor. A változók deklarációját, így az egyes mezők funkcióját és értelmét maga a rendszer tartalmazza, mégpedig a program telepítési könyvtárában a System alatt. A változók leírásáért az VAR.SDL fájl felel. Nézzük ezek után a változók típusait és a változószerkesztő működését.

Változók

53

3

1.1. Változótípusok A VISION változótípusokat foglalja össze a következő táblázat: Változótípus

Tárolótípus

Byte

1. Analóg változó (skálázott)

Byte Shortint Word Integer Longint Dword Dlong Real

1 1 2 2 4 4 8 4

Nyersérték tartománya 0 .. 255 -128 .. 127 0 .. 65535 -32768 .. 32767 + 2147483648 0..4294967296 0..2E64 + 1.7*10+38

2. Analóg trendváltozó

mint fent

3. Lebegőpontos változó

Float Double

4. Lebegőpontos trendváltozó

mint fent

5. Direkt egész változó (nem skálázott)

Byte Shortint Word Integer Longint Dword Dlong

1 1 2 2 4 4 8

6. Diszkrét változó

Byte

1

0 .. 1

7. Diszkrét trendváltozó

Byte

1

0 .. 1

8. Többállapotú változó

Speciális byte

1

0 .. 255

9. Többállapotú trendváltozó

Speciális byte

1

0 .. 255

10. Szöveg változó

Shortstring String

32 255

54

mint fent 4 8

+

1.7*10+38 dupla precizitású szám mint fent 0 .. 255 -128 .. 127 0 .. 65535 -32768 .. 32767 + 2147483648 0..4294967295 0..2E64

ASCII karakterek ASCII karakterek

Változók

3

1.1. Konzisztens változótáblák, új tábla készítése A rendszerben egy v. több ún. konzisztens változótábla készíthető, ami az egyes változókat a deklaráció sorrendjében tartalmazza. A változótábla előállítása és módosítása az ebben a fejezetben ismertetett változódeklaráció révén, on-line lehetséges – anélkül, hogy az alkalmazói fájlrendszer újrafordítását külön kellene kezdeményeznünk. Habár 1 változódeklaráció 1 ilyen táblát eredményez, az alkalmazáson belül tetszés szerinti számú változótábla felvehető, célszerűen a technológiai, vagy a funkcionális szempontok szerint csoportosítva az adatokat. Ez annak köszönhető, hogy a projektmenedzseren belül több változófájlt is készíthetünk – eltérő trend-, alarm- és adatgyűjtési ciklusidőkkel. Vagyis a változótáblák – a funkcionális szempontokon túl – hozzáköthetők a feldolgozás sebességigényéhez is. A gyors mintavételezésű trendeket, vagy azokat a változókat, amelyek gyorsabb alarm feldolgozást igényelnek külön változótáblában lehet tárolni. Új változótáblát a szokásos módon – jobb egérgomb menü B új változó fájl – kezdeményezhetünk, megadva az új fájl nevét, rövid nevét és leírását, valamint a már említett ciklusidőket. Mint látni fogjuk, a változók, mint objektumok önmagukban hordoznak bizonyos alarm-, adatgyűjtési és trend funkciókat – és ezen taszkok ciklusidejét határozhatjuk meg az új tábla felvételekor. A ciklusidőket persze utólag is módosíthatjuk a komponens lista elemeire a jobb egérgombbal kattintva, majd az előugró (popup) menüből: Tulajdonságok-at választva. A módosításhoz először szerkesztési állapotba kell a rendszert hozni a szokásos módon (Ctrl+Alt+E).

Cikulsidő módosítása szerkesztési állapotban

Megjegyezzük, ugyanezen a módon változtatható az összes többi taszk ciklusideje is (ciklikus program, alarm program, kommunikáció). A változótáblák egyetelen ún. shared memóriaterületbe töltődnek – sorban minden egyes tábla –, ami azt jelenti, hogy az összes taszk ezen keresztül fér hozzájuk. Nemcsak azok, amelyek a programon belül futnak, de a „kívülről” indított programok is, pl. képek. A változótáblák száma nem korlátozott, de a teljes változószám igen (licence!).

Változók

55

3

1.2. Táblázat- és szövegszerkesztés A változók e fejezetben ismertetett táblázatos szerkesztése valójában a szöveges formátumú változódeklarációs file létrehozását eredményezi. Ez a file természetesen egyszerű szövegszerkesztővel is megváltoztatható, sőt maga a program is képes ebbe az üzemmódba kapcsolni (Ctrl+Alt+T). Sok esetben a szövegszerkesztővel végzett módosítások sokkal gyorsabban eredményre vezetnek. A szöveges formátumú változódeklarációs file felépítését és szintaktikáját a filerendszer részeként ismertetjük, a továbbiakban a táblázatos műveletekre koncentrálunk.

2. Változódeklaráció Az alkalmazás változói változódeklaráció révén jönnek létre. Ez a művelet képezi az alapját lényegében az összes további műveleteknek, a képelemek animációjának, az alarmok készítésének, a programozásnak, stb., mivel a változók kapcsolják azokat össze egymással és a külső berendezésekkel. A változódeklaráció a projektmenedzser Változók ágára kattintva (a változó komponenst megnyitva), majd onnan a jobb egérgomb menüből Változók szerkesztése opciót választva kezdeményezhető. Természetesen itt is használható a Ctrl+Alt+E gyorsítóbillentyű, mely az összes többi komponenshez hasonlóan a változók esetén is szerkesztés állapotot idéz elő. Használhatjuk továbbá a Szerkeszés legördülő menü megfelelő menüpontját is: Elem szerkesztése (ki-be) Szerkesztés üzzemmódba váltva a következő képernyő jelenik meg.

Az összes változón belül a megfelelő, szerkesztendő változó tábla kiválasztása

56

Változók

3

A kép jobb oldala a már deklarált változókat mutatja, az összes tipust egymás után, de a baloldalon található kiválasztó menü révén (Változótipusok) lekérhetjük a konkrét típusnak megfelő változótáblázatokat is. Felhívjuk a figyelmet arra, hogy ez a kép egy új projekt elindításakor már tartalmazhat bizonyos adatokat, amennyiben ún. Default projektet készítettünk, mivel a program néhány változó prototípust ilyenkor automatikusan létrehoz, megkönnyítendő a további változók elkészítését a felkínált minták alapján. Üres projekt készítése esetén azonban a kezdeti változódeklaráció is üres. Az egyes változók módosítása, új változók bevitele és törlése ezen változótábla soraira való dupla kattintással vagy jobb egérgomb, majd Megnyitás, Törlés, Új, stb. útján kezdeményezhető. Ennek hatására jelenik meg a változótípusonként eltérő szerkesztő ablak, de csak akkor, ha a megfelelő változótípust előzetesen kiválasztottuk. A változók további adatai ui. csak akkor jelennek meg a táblában, ha csak analóg, diszkrét, többállapotú, stb. adatokat szerkesztünk, mivel a program különben nem tudja azonos formátumra hozni a közös mezőket a táblázatban, azaz nem tudja beolvasni az összes mezőt (egy analóg változónak pl. van dimenzió mezője, de egy diszkrétnek már nincs). Például analóg változó szerkesztéséhez először a bal oldalon látható XP-menüben az Analógra kell kattintanunk, majd a táblázatban megjelenő változók soraira dupla kattintás, vagy jobb egérgomb menü, majd Megnytás. Erre a következő ablak jelenik meg:

A szerkesztőablaknak vannak közös vezérlő elemei. Ilyenek az Új változó létrehozása és Törlése, vagy a léptető gombok. Ezeket a közös műveleteket ismertetjük először, majd a szerkesztőablak működését változótípusok szerint.

Változók

57

3

3. Közös szerkesztői műveletek Az új változó létrehozása, törlése, ismétlése, minden szerkesztőablakban közös.

3.1. Új változó létrehozása Új változó az erre szolgáló nyomógomb megnyomásával készíthető. Ez a művelet egyaránt kiváltható az egyes szerkesztőablakokon belül, vagy a változótábla tetején a toolbox-ban látható új elem nyomógomb segítségével: Az új változó az éppen kijelölt változó lemásolásával, majd automatikus átnevezésével keletkezik (egy új sorszámot kap). Tehát csak az eltéréseket kell begépelnünk. Ez persze azt is jelenti, hogy célszerű a hasonló változókat egymás után létrehozni.

3.2. Változó törlése A törlés a megfelelő nyomógomb megnyomásával végezhető el. A művelet az új változó létrehozásához hasonlóan egyaránt kiadható az egyes szerkesztőablakokban vagy a változótábla tetején látható toolbox-ban: Természetesen a rendszer visszakérdez mielőtt a változót kitörölné, de még így is lehetőség van az eredeti állapot helyreállítására, amennyiben később a mentés során, az ún. Todo listában a Mégse opciót választjuk. Ezt a mentés funkciónál ismertetjük. A törlés nem csupán a változó megszüntetésével jár, de az egész alkalmazás átvizsgálását is maga után vonja. A hivatkozást tartalmazó fájlok objektjeit a program letörli, hogy legközelebb azok feltétlenül leforduljanak. Tehát magában a forrásfájlokban, mégha azok tartalmaztak is hivatkozásokat az adott változóra, nem végez változtatást a rendszer, viszont később, az adott kép, alarm, kommunikációs program felolvasásakor hibajelzést fog adni. Ekkor a programozónak kell döntést hozni, hogy mi legyen a megszüntetett változóra hivatkozó objektumokkal. Jobb ezért, ha a változó törlése előtt magának az alkalmazásnak a mentesítéséről gondoskodunk: kitöröljük azokat a programsorokat, megszüntetjük azokat az objektumainkat, amelyek az adott változóra hivatkoztak.

3.3. Változó átnevezése Az átnevezés a változó nevének a szerkesztőablakban való átgépelésével végezhető el. Ez ugyan triviálisan hangzik, de tudni kell, hogy az átnevezés hatására a rendszer meglehetősen bonyolult műveletekbe kezd. Megvizsgálja, hogy az adott változó mely képeken, programokban, alarmokban, üzenetekben stb. szerepel, s ott kicseréli annak nevét az új elnevezésre. Tehát az átnevezés a forrásprogramokat is módosítja. Ez a művelet néhány másodpercig is eltarthat.

3.4. Léptetés A változók előre-hátra léptethetők a szerkesztőablakokon belül is. Nem kell tehát a táblázatba visszalépnünk ahhoz, hogy új változót olvassunk be a szerkesztőablakba a

58

Változók

3

szomszédosak közül. A változótáblázat ebben az esetben is követi az éppen editált változó pozícióját. A fel-le billentyűk helyett opcionálisan a PgUp és PgDn lapozóbillentyűk is használhatók.

3.5. Keresés Keresés a toolbox megfelelő nyomógombja segítségével kezdeményezhető a felkínált dialóg ablak kitöltésével. Itt többféle mezőre is kereshetünk: változónévre, technológiai azonosítóra, leírásra, vagy dimenzióra, és a találati minták között előre-hátra lépegethetünk. A keresés töredékszóra opciótól függően keres a program részleges, vagy teljes azonosságra.

3

Ennél hatásosabb a szerkesztő-ablakokon belüli keresés. A szerkesztő ablakok bal alsó sarkában található az a beviteli menü, ami a változó gyors pozícionálását vonja maga után. Nem kell ENTER-t gépelnünk, a rendszer automatikusan követi a változókat az éppen bevitt aktuális karakterszámig, vagyis a keresés itt mindig töredékszóra történik.

3.7. Excel export, import Lehetőségünk van arra, hogy a változóbábla tartalmát – adott formátumban – Excel-be konvertáljuk. Ez az Excel export funkció. Ilyenkor annak a változótábla résznek a konvertálása történik, amit éppen kiválasztottunk, és csak annak. Ha azt akarjuk tehát, hogy az összes változót átkonvertálódjon, az összes változó-t kell választanunk. Az Excel-ben az egyes változótípusok saját munkalapra kerülnek (Analog, Discrete, Direct, stb.). Az ellenkező irány persze érdekesebb lehet, hiszen az Excel import jelenti, hogy az adott formátumú Excel fájlból a rendszer képes felépíteni a saját változótábláit. A változó Excel fájljainak a felépítése érdekében először exportáljuk a változóinkat (lehetőleg minden típusból, vagy az összes változót), hogy lássuk, milyen munkalapokat, s azon belül milyen mezőket vár a program. A munkalapokon belül a munkalap oszlopai a változó struktúrájának, ill. mezőinek felelnek meg. A fájlok prototípusai a program telepítési könyvtárában, az Excel alkönyvtárban találhatók. A konkrét exportot innen másolja a program és tárolja le az alkalmazás könyvtárába. Az importalás is elsődlegesen az alkalmazás könyvtárában keres, de a tallózóból más könyvtár és fájl is kiválasztható.

3.8. Mentés A módosításokat a ment gomb megnyomásával kell fixálni, de a rendszer akkor is rákérdez erre a műveletre, ha egy másik komponensre váltanánk, vagy ki akarnánk lépni a programból. Mindenesetre érdemes tudni, hogy az új változók bevitele, meglévőek módosítása még nem írja felül az adatbázist, csak a ment gomb, illetve az általa behívott ún. Todo listára adott válasz: alkalmaz. Ha a következő ábrán látható Todo listán képen Mégse-t választunk, minden visszaáll eredetire. Változók

59

3

A todo listában a módosítások kategorizálva jelennek meg, külön a módosított változók, az új változók, a törlendő változók és az átnevezett változók. Fixálása az alkalmaz megnyomásával lehetséges, mint említettük. Azonban előtte még leellenőrizhetjük, hogy valóban ezt akartuk-e (ez lenne a todo lista célja). Amennyiben valamit elrontottunk, Undo-t, Redo-t kérhetünk, vagy a lista egyes soraira kattintva a jobb egérgombbal egyenként kitörölhetjük az elemeket a todo listából. Az előfordulásai menüpont is hasznos lehet. Ezzel azt kérdezhetjük meg a programtól, hogy az illető változó vajon hol szerepel, milyen képeken, programokban, komponenseken. Ilyenkor a mentés dialógus átalakul:

Keresés további előfordulásokra

INT változó előfordulásai

60

Változók

Előfordulás a képen belül

Ez egy rendkívül hasznos segédlet, mivel ezzel interaktívan feltérképezhetjük az alkalmazásunkat az adott változó után kutatva. Olyannyira, hogy ezt a funkciót nemcsak a todo listában, de magán a változó-szerkesztő képen is bekapcsolhatjuk (jobb egérgomb B Előfordulásai):

3

Ablak bezárása

Ha most a változó listában mozgunk, különféle változókra szelektálunk, az alsó táblázat is követi azt, frissíti az előfordulási listát. A program tehát valóban interaktívan kutatja végig az alkalmazást az adott változóra. Ezt a dokkolt ablakot a talált fájlok előtt látható vörös X-szel zárhatjuk be.

3.9. Egyéb műveletek Az egyéb műveletek között megtalálható a vágólapon keresztül való másolás, duplikálás, és a kivágás. Ezek pontosan úgy használhatók a változók esetében is, mint általában a Windowsban. A Ctrl+D (duplikálás) billentyű a Ctrl+C (másolás), és Ctrl+V (beillesztés) szekvencia gyosítására szolgál, segítségével gyors másolatokat készíthetünk a változóinkról – a nevet ilyenkor a rendszer növekvő sorszámokkal különbözteti meg, csakúgy, mint a új változó készítésekor.

Változók

61

4. Változótípusok Ahogy a bevezetőben már utaltunk rá, a VISION rendszer változói típusonként eltérőek. Ezeket részletezzük a következő pontokban.

3

4.1. Analóg változók Az analóg változók táblázatának kiválasztására az alábbi dialóg ablak jelenik meg: Általános hivatkozási adatok

Méréstartomány és alarmjelzési szintek

Felhasználói hozzáférési jogok

Nyersérték tipusa: • Shortint • Byte • Integer • Word • Long • Dword • Dlong • Real

Skálázási paraméterek

Alarm engedélyzés

A változó azonosítása a főbb adatok menücsoportban állítható be. Ez tartalmazza a változó nevét, technológiai azonosítóját, leírását, típusát és dimenzióját. Ezeket az adatokat rendre a megfelelő editbox-ba való begépeléssel, ill. a legördülő listából való kiválasztással adhatók meg – értelemszerűen. A technológiai azonosító funkciója azonban valószínűleg külön is magyarázatra szorul. Ennek a másodlagos azonosítónak az a szerepe, hogy a felhasználó számára érthető formában azonosítsa a változókat. Sokszor előfordul ui. hogy az alkalmazott tervjelek számítástechnikai azonosításra nem alkalmasak, mivel speciális jeleket, space-t, vagy ékezetes karaktereket tartalmaznak (pl. T100/X-10). Az is gyakori, hogy e jelek ismétlődnek. Mármost a VISION rendszerben egyetlen konfigurációs opcióval eldönthetjük, hogy a felhasználó számára a kétféle jelazonosító közül melyik jelenjen meg, a számítástechnikai azonosító vagy a tervjel ill. technológiai azonosító. A technológiai azonosító online is módosítható. 62

Változók

Ahogy a bevezetőben említettük, az analóg változók egész típusú folyamatváltozók fizikai mértékrendszerre való átskálázásával keletkező lebegőpontos adatok. Ezért kell kiválasztanunk a jel tárolási típusát (Byte, Shortint, Word, Integer, Longint, Real) az általános paramétereknél, meghatározva ezzel a nyers érték tartományát és előjelességét. Ezenkívül a változódeklaráció magában foglalja a fizikai mértékrendszerre való áttérés megvalósításához szükséges skálázás paramétereit: Fizikai_adat = Nyers_adat * Faktor + Offset Ezt a lineáris leképzést adhatjuk meg a Nyersérték menücsoportban. Kétféle módszert alkalmazhatunk. Egyrészt közvetlenül megadhatjuk a lineáris leképezés szorzófaktorát és eltolását, vagy begépelhetjük a mérés ún. nyersérték-tartományát. Ez utóbbi esetben a program maga számolja ki a szükséges faktor és offszet értékeket a jel fizikai mértékrendszerbeli minimum (LL) és maximum (HH) tartományával való összevetés alapján. Az értéktartomány beállítása lehetséges a Tartomány menücsoportban. Négyféle határérték adható meg. A minimum (LL), előminimum (L), előmaximum (H) és a maximum (HH). A két legszélső értéket sokszor vész-határoknak is nevezik, de a VISION-ben ez a két érték egybeesik a méréstartománnyal (ld. skálázásról mondottakat). Az értéktartomány fenti kijelölésének az alarmok szempontjából van jelentősége. Az alarm beállításával jelölhetjük ki a program számára, hogy a megfelelő határérték elérésekor egyben figyelmeztető jelzés is keletkezzék. Ezek az engedélyek az alarm menücsoportban adhatók ki. A határérték közelében ingadozó jel alarm ismétlése ellen véd a hiszterézis (ezt az értéket a program a mért értékből levonja, vagy ahhoz hozzáadja, amikor az adott határértéket a jel eléri, így védve a határérték közelében ingadozó jel alarm-ismétlése ellen). A hiszeterézis fizikai mértékrendszerben adandó meg. Végül meg kell még adnunk a változóhoz kapcsolódó hozzáférési engedélyeket a felhasználó számára. A felhasználó csak az itt engedélyezett adatok módosítását végezheti majd el. Alatta, a helyettesítési érték ablakban adjuk meg azt az alapértékét, ami a kezelő által letiltott méréseknél jelenik majd meg, ill. azoknál ahol az Automatikus tiltás L-el opcióval a határértéken kívüli tartományokba csúszott mérés helyettesítését engedélyeztük (pl. távadó meghibásodása vagy karbantartás miatt) – így pl. a 4 mA alatti tartományban negatív és valótlan értékek helyett. Az Adatgyűjtés a változók adatbázisban való eltárolásával kapcsolatos leggyakoribb műveleteket automatizálják. Így készíthetünk átlagokat, mennyiségi integrálokat, üzemórákat, számlálókat, vagy csak egyszerűen pillanatérték rekordokat az egyes adatainkról. Később a gyűjtött adatok tetszés szerint összeválogatva táblákba redezhetők, s azokból mindenféle grafikonok, valamint statisztikák készíthetők – változatos időtartományokban (óra, műszak, nap, hét, hónap, negyedév, tartomány, stb.) és felbontásban. Az adatgyűjtéssel önálló fejezetben foglalkozunk, itt csak rögzítenénk, hogy az adatgyűjtés megadásával valójában egy bonyolult előfeldolgozást igénylő adatbázis műveletre adunk utasítást a programnak, ami a gyakorlatban szükséges legfontosabb feladatokat végzi el számunkra – teljesen automatikusan. Vegyük észre, hogy a paraméterezésen túl két önálló funkciót is bekonfiguráltunk: az alarm jelzést a határétékekről és az adatgyűjtést. Ez egy újabb funkcióval bővülhet még, a trendkészítéssel, de ehhez más változótípust kell választanunk.

Változók

63

3

4.2. Analóg trendváltozók Az analóg trendváltozók táblázatának kiválasztására, a változó sorára, vagy az új változó menüre kattintva az alábbi dialóg ablak jelenik meg:

3

Hisztorikus trend adatai

Az analóg trendváltozók egyes adatmezői teljes egészében megfelelnek az analóg változóknál leírtaknak. Ezek a változók pontosan úgy is viselkednek, mint az analóg változók, tehát pl. szerepelhetnek kifejezésekben, kiírhatók a képre, adatbázisba és közvetlenül szerepeltethetők a kommunikációs üzenetekben is. Mindössze annyi a különbség, hogy e változók története is regisztrálva van. A történeti adattárolásra vonatkozó specifikáció található meg a szerkesztőablak Trend mintavételezés adatcsoportjában. Három paraméter megadása szükséges: 1. Teljes hossz (total):

A trendben tárolt összes minták száma. Az ennél régebbi elemek automatikusan kitörlődnek a cirkuláris pufferből. A teljes hossz igen nagy szám lehet (longint).

2. Ablakhossz (window):

Ez a paraméter adja meg a trendablakban ábrázolt minták számát. Természetesen ez az érték nem lehet nagyobb, mint a teljes hossz. Az ablakméret tehát a megjelenítés szempontjából lényeges. A felrajzolt ablak a trend teljes hosszában visszamozgatható a minták mentén, az itt megadott alapérték változtatható – akár programból, akár a felhasználó által a trendek listájában (nagyítás görhetővel és jelölő négyszöggel).

64

Változók

3. Mintavételezési faktor:

Ez a paraméter írja elő, hogy milyen gyakorisággal kerülnek új minták a trendbe. Ennek a számnak a változófájl létrehozása során megadott mintavételezési faktorral vett szorzata adja meg, hogy hány másodpercenként veszünk mintát. Mivel a mintavételezési faktor ms-os léptékű, a mintavételezési idő is ms-os. Azonban a rendszer 10ms-os felbontással dolgozik, tehát a leggyakoribb mintavételezés 10ms-os, a következő 20, és így tovább.

A trendek alaphelyzetben equidisztánsan (egyenlő távolságú mintavételezéssel kerülnek eltárolásra), de abban az esetben, ha az Index-nél hozzárendelünk egy másik változót, a trend tárolása időbélyegessé alakul. Ezt az időbélyteget vagy indexet határozza meg a címzett második változó, ami lehet szavas, duplaszavas, lebegőpontos, és a dimenziójából derül ki, hogy milyen időléptékű (s, sec, mp, ms, µS, uS). Az időbélyeg ebből adódóan akár mikroszekundumos is lehet. Hogy relatív (index), vagy abszolút időt (időbélyeg) határoz-e meg, a konfigurációtól függ (Rendszer B Trend index mód). Példa Feltéve, hogy a mintavételezési faktor = 1, számítsuk most ki a szükséges paramétereket arra az esetre, ha 1 hónap adatait kívánjuk tárolni 1 perces mintavételi gyakorisággal, és 1 teljes napot kívánunk a trendablakban megjeleníteni. A megfelelő paraméterek a következők: Teljes hossz: Ablak hossz: Mintavételezés:

44640 1440 60

(31x1440) (60x24) (60x1)

4.3. Lebegőpontos változók A lebegőpontos változók táblázatának kiválasztására az alábbi dialóg ablak jelenik meg:

Változók

65

3

Mint látható, ez a szerkesztőablak az analóg változóknál leírtakhoz képest semmilyen újdonsággal nem szolgál, hacsak azzal nem, hogy számos adat nem szerepel. A lebegőpontos változóknál ui. nincs szükség skálázásra, mivel feltételezzük, hogy a lebegőpontos számok már eleve fizikai mértékrendszerben jelennek meg. Ez a tipikus helyzet akkor is, ha a lebegőpontos adatok a PLC-ből származnak. Lebegőpontos folyamatváltozókra lehet pl. szükség a PLC-ben megvalósított szabályzók esetén. A lebegőpontos értékek 4- vagy 8-byte felbontásúak lehetnek. Az alarm készítés, értéktartományok beállítása és a hozzáférési jogok megadása megfelel az analóg változóknál leírtaknak.

4.4. Lebegőpontos trendváltozók A lebegőpontos trendváltozók táblázatának kiválasztására az alábbi dialóg ablak jelenik meg:

Mint látható, ez a szerkesztőablak sem tartalmaz újdonságokat az analóg trendváltozóknál leírtakkal összehasonlítva. A lebegőpontos változók előző pontban leírt sajátosságai miatt itt is hiányzik a skálázás, a lebegőpontos változóhoz képest viszont van trend. A lebegőpontos trendminták 4- vagy 8-byte felbontásúak. Az alarm készítés, az értéktartományok beállítása, a hozzáférési jogok megadása és a történeti adattárolás paraméterei megfelelnek az analóg trendváltozóknál leírtaknak.

66

Változók

3

4.5. Egész változók Az egész változók a lebegőpontos változókhoz hasonlóan nem skálázhatók, a bennük tárolt adat azonos azzal, amit a külső eszközből beolvastunk. Az egész változók esetén is elmarad tehát az adat skálázása (faktorral való szorzás majd offszettel való eltolás), így az gyorsabb és kevesebb tárhelyet is igányel, mint annak analóg megfelelője. Akkor célszerű egész változókat használni, ha az adatot is abban a formátumban kell a megjelenítő rendszerben feldolgozni, amilyen formában a PLC-ből kiolvastuk. Tipikusan a különféle számlálók, üzemállapot jelzések, üzemmódok tartoznak ide, de abban az esetben is egész változót használunk, ha a digitális jeleket egész változók formájában (egyszerre 8-, 16-, vagy 32-őt beolvasva) dolgozzuk fel (az egyes bitekre . formában hivatkozhatunk). Az egész változók táblázatának kiválasztására, a változó sorára, vagy az új változó menüre kattintva az alábbi dialóg ablak jelenik meg:

A képen látható beállítások teljes egészében megfelelnek az analóg változókéval. Az ábrán jól látható, hogy elmaradt a nyersérték beállító menücsoport. Az egész változó konkrét típusa most a főbb adatoknál kiválasztot típus (byte, shortint, integer, word, longint, dword, dlong). Ezek felölelik a teljes 8-, 16-, 32- és 64-bites tartományt – előjelesen, vagy előjel nélkül. Az egész változókat az analóg megfelelőktől megkülönböztetendő direkt változóknak is nevezzük.

Változók

67

3

4.6. Szöveg változók A szövegváltozók táblázatának kiválasztására az alábbi dialóg ablak jelenik meg:

3

Szövegváltozó méret (32, v. 255 char)

Mint látható, a szövegváltozók rendkívül egyszerűen deklarálható adattípusok. Elnevezéséből következik, hogy a szövegváltozó (avagy string) szöveges adatok tarolására szolgál (pl. operátor neve, dátum/idő, anyagok elnevezése, különféle azonosítók, stb.). Itt megadhatjuk a string kezdeti értékét is. Megjegyezzük, hogy ez a kezdeti érték a többi változótípusnál mindig 0. A string változóban tehát előre megadott fájlnevek, elérési útvonalak, kulcsszavak is megadhatók úgy, hogy azt később akár programból, akár a kezelő által is módosíthatjuk. Mindez persze konstans megadásával is lehetséges (ld. később), a szövegváltozó azonban változtatható. A kezdeti értékkel kapcsolatban azt is tudnunk kell, hogy az adatok pillanatértékeit a rendszer egy külön adatbázisban (DATA.TAB) eltárolja. Automatikusan (a default beállítás szerint 5 percenként) és kilépéskor. A program legközelebbi indításakor tehát mindig a változók legutóbbi értékével indul. Így a string kezdeti értéke is csak egyetlen esetben játszik szerepet: az adat létrehozásakor. (ill. a DATA fájl letörlése esetén), utána már az van benne, amit legutóbb beleírtunk. Külön is érdemes odafigyelni a hozzáférési jogok megadásánál szereplő rejtett opcióra. Ez különösen kulcsszavak esetén vagy egyéb titkosított információk esetén lehet hasznos. Így a kezelő standard módszerrel (pl. változótáblán keresztül) nem férhet hozzá a változó tartalmához. A szerkesztőablak kezelése egyébként megfelel a többi változó szerkesztőablakánál elmondottaknak.

68

Változók

4.7. Típusdeklaráció A típusdeklaráció a diszkrét és a többállapotú változók kezelése szempontjából egyaránt alapvető jelentősségű. Ezért e változótípusok ismertetése előtt ismerkedjünk meg az attribútum tábla fogalmával.

3

4.7.1. Attribútum tábla A típusdeklaráció a diszkrét és a többállapotú változók értéktartományának az ún. attribútum táblákhoz való hozzárendelését végzi. Az attribútum tábla meghatározza a változó adott numerikus értékének szöveges jelentését és egy további színt, kitöltést vagy más numerikus adatot, azaz attribútumot. Például: Attribútum tábla: Változó értéke

Megnevezés

Attribútum

0 1 2 4

Hibás Nyitva Zárva Távműk

FlashRed Green Red Yellow

A dolog jelentőssége abban áll, hogy egy-egy attribútum tábla egyszerre több diszkrét és többállapotú változóhoz is hozzárendelhető, hiszen éppen ezért nevezzük e táblázatokat típusnak. Tehát a jelek kódolása és értelmezése egy-egy közös táblázatra nyúlik vissza, az elnevezések vagy az attribútumok megváltoztatása az összes változóhivatkozásnál automatikusan megjelenik. Fontos hangsúlyozni, hogy az attribútumok bevezetése miatt a képrajzolás közben sem kell törődnünk a színek megadásával – elég, ha a megfelelő változó ATTR referenciájára hivatkozunk: valtozo.attr. Ezzel a változó értéke helyett a színét kapjuk majd vissza. A valtozo.text pedig a szöveget adja meg (Hibás, Nyitva, Zárva, Távműk). A változó értéktartományának szétválasztásával az attribútum tábla egyaránt képes kimenő és bejövő jelek deklarálására is egyazon a táblázaton belül. A bejövő jeleket meghatározó részt Input attribútum táblának, a kimenő részt Output attribútum táblának nevezzük. Például, egy szelep két végálláskapcsolójának a jelzése kerülhet az input oldalra, míg a szelepre kiadott nyitás- és zárásparancsok képezhetik a kimeneti oldalt. A működtetés szempontjából azonban azok az állapotok az igazán érdekesek, amelyek a megfelelő input-output kombinációkra vonatkoznak, hiszen ezek felelnek meg a szerelvény megengedett állapotainak. Ezt az összevont táblázatot nevezzük kombinált attribútumnak. Alapértelmezés szerint a változók input része az alsó 4-biten (alsó tetrád) tárolódik, az output része pedig a felső 4-biten (felső tetrád). Az attribútum táblák input (16-nál kisebb), output (16-nál nagyobb) és kombinált részei (alsó és felső tetrádok vegyes értékei) a változótípus értelmezésétől, a felhasználás céljától is függnek. A többállapotú változókat ui. nem kell feltétlenül az alsó, vagy a felső négy bitre korlátozni, használhatják akár a teljes értékkészletet is, ami bájtos változók esetén 0-tól 255-ig terjed. Mindez a változó kommunikációs üzenetétől függ és nem önmagában a változótól. A kommunikációs üzenetekben ui. azt tudjuk eldönteni, hogy az adott többállapotú változónak az alsó 4-bitje, a felső 4-bitje, vagy a teljes 8-bit kerüljön-e továbbításra. Ezért, ha eleve tudjuk, hogy a változó teljes értékkészletét akarjuk használni, akkor az input és az output oldal megkülönböztetése sem szükséges.

Változók

69

4.7.2. Attribútum táblák megadása A típusdeklaráció az előző pontban ismertetett táblázat kitöltéséből áll. A típusok táblázatának a kiválasztására, az egyes tipusok soraira, vagy az új változótípus menüre kattintva az alábbi dialóg ablak jelenik meg:

3

Színmegadás dupla kattintással

A táblázatot egyszerűen begépeléssel tölthetjük ki, ill. az attribútumot, ami alapértelmezésben a szín, az attribútum listából (alapértelmezésben egy színdialógus) választhatjuk ki. Ez az ablak az attribútum tábla “szín” cellájára való dupla rákattintással hívható elő. Ekkor jelenik meg a szabványos színek bevitelére szolgáló kép: Abban az esetben, ha a kiterjesztett színkészletet választjuk (ld. szín beállátási mód menücsoport), akkor a Windowsból jól ismert színkiválasztó, ill. színkeverő ablakban adhatjuk meg az R-G-B színt: Érdemes azonban a VISION szabványos színeit alkalmazni, hogy az egyes állapotokat exakt színekkel jellemezhessük. Ne felejtsük el, hogy a színjelzés technológiai állapotok jelöl (hiba, nyitva, zárva, túlmelegedés, stb.). A szerkeszőablak jobb oldalán azon változók listája látszik, amelyek az adott típusra hivatkoznak. Tipust csak akkor törölhetünk, ha ez a mező üres.

70

Változók

A táblázatok kitöltéséhez a szerkesztőablak számos segítséget kínál. Először is a kép bithasználat mezőjében azt láthatjuk, hogy az input és. az output oldal bitjei hogyan töltik ki a többállapotú, vagy a diszkrét változó értéktartományát. Diszkrét változó esetén csak a legalsó bit lehet érintve a deklaráció által – máskép fogalmazva az érték 0 vagy 1 lehet. Ez nyilvánvaló. Nem ilyen egyszerű azonban a helyzet a többállapotú változók esetében. Ezeknél a változóknál a felső négy bit képviseli a kimeneti oldalt, az alsó négy bit pedig a bemeneti oldalt, de a változó együtt használhatja az alsó és a felső oldalt, vagyis a teljes bájtot is (ld. az attribútum tábláknál elmondottakat). Mármost arra vigyáznunk kell, hogy az input attribútum táblába gépelt, inputnak szánt sorok csak az alsó négy bitre hassanak, vagyis az értéktartomány 0..15 között legyen, az output oldal viszont 16-nál nagyobb számokat tartalmazzon. Ellenkező esetben a program hibát fog jelezni a megfelelő többállapotú változó hozzárendelésekor. Az értéktartományon kívüli deklarációs sorok piros színnel jelennek majd meg az attribútum táblában. Az értéktartomány megfelelő beállítását segítheti a Hexa értékek beviteli mód kiválasztása. Végülis a sikeresen deklarált típus 1..4 input bitet és 0..4 output bitet, avagy 1..8 bitet (a teljes bájtot) foglalhatja le. Az ábrán egy 3-bites tipus deklarációjára láthatunk példát. Természetesen nem minden típus használható az összes diszkrét és többállapotú változóra, hiszen az érintett biteknek konzisztenciában kell állniuk a változó értéktartományával. Az ábrán látható típus tehát 3-bit értéktartományú vagy annál kisebb többállapotú változókhoz rendelhető hozzá.

4.8. Diszkrét változók A diszkrét változók táblázatának kiválasztására az alábbi dialóg ablak jelenik meg:

A szerkesztőablak általános paraméterekre vonatkozó főbb adatok menücsoportja itt is ugyanazokat a mezőket tartalmazza, mint az összes többi változónál. Az egyetlen újdonság az attribútum táblák kiválasztására szolgáló kombinált adatbeviteli (combobox-dropdown) menü. Az éppen kiválasztott attribútum tábla meg is jelenik a

Változók

71

3

szerkesztőablakban, hogy ezzel ellenőrizhessük: valóban ezt a tipust kívántuk a változóhoz hozzárendelni. A típus kiválasztásánál vigyáznunk kell, hogy csak 1-bites típust alkalmazzunk!

4.9. Diszkrét trendváltozók A diszkrét trendváltozók táblázatának kiválasztására az alábbi dialóg ablak jelenik meg:

Mint a többi trendváltozó esetében, itt is szükséges a trend mintavételezés megadása. A dialógus többi mezője azonos a diszkrét változókéval. A megjelenő attribútum tábla itt sem szerkeszthető, csak típusszerkesztéssel (4.7.2). A diszkrét trendváltozó kétféle görbe kirajzolására képes: négyszög diagram, vagy színsáv.

Ez a különbségtétel nem a változó megadásánál van, hanem a konfigurációnál (Rendszer). Alaphelyzetben a színes diszkrét trend opció kikapcsolt, tehát négyszöget rajzol.

72

Változók

3

4.10. Többállapotú változók A többállapotú változók táblázatának kiválasztására az alábbi dialóg ablak jelenik meg:

3

A szerkesztőablak általános paraméterekre vonatkozó főbb adatok menücsoportja itt is ugyanazokat a mezőket tartalmazza, mint az összes többi változónál. A diszkrét változókhoz hasonlóan most is megjelenik az attribútum táblák kiválasztására szolgáló kombinált adatbeviteli menü. Az éppen kiválasztott attribútum tábla pedig itt is megjelenik a szerkesztőablakban, hogy ezzel ellenőrizhessük: valóban ezt a típust kívántuk a változóhoz hozzárendelni, azonban szerkeszteni itt sem lehet, csak a tipusszerkesztőben. A típus kiválasztásánál vigyáznunk kell, hogy a megfelelő értéktartományú típust válasszuk ki. Ellenkező esetben a megfelelő sorok piros színűek és a program hibát jelez, amennyiben ezt az állapotot kívánjuk elmenteni. A kiválasztást segíti az Ősszes / Bit <= / Bit = előválogató. Ezzel azt érjük el, hogy csak az adott szabálynak megfelelő táblák jelenjenek meg a legördülő menüben. A Bit = opció például csak azokat a táblákat jeleníti meg, amelyek értéktartománya azonos a megadott input/output értékkel. Persze kisebb bitszámú tábla is megadható, lehet, hogy 4 bitből csak 2-t használunk, mert a PLC-ben egységesen 4 bitet foglaltunk le a többállapotú változóinknak, de a megjelenítés során már a tényleges állapotokkal dolgozunk. Ez tehát nem hiba, ezért is lehet szükségünk a Bit <= szűrésre. A hozzáférési engedélyek menücsoportban az input és az output rész (amennyiben e kettőt külön kezeltük) módosítását engedélyezhetjük / tilthatjuk a felhasználó számára. Input változók esetén pl. az input oldal programból nem módosítható (mivel a PLC módosítja), ezért azt eleve le is tilthatjuk.

Változók

73

4.11. Többállapotú trendváltozók A többállapotú trendváltozók táblázatának kiválasztására az alábbi dialóg ablak jelenik meg:

3

Mint a több trendváltozó esetében, itt is szükséges a trend mintavételezés megadása. A dialógus többi mezője azonos a diszkrét változókéval. A megjelenő attribútum tábla itt sem szerkeszthető, csak a tipusszerkesztésnél. A többállapotú trend is rajzolható lépcsőzetesen és színsávként, ahogy a diszkrét változó, csak itt az alapértelmezett érték a színsáv, mivel az a praktikusabb. Ennek beállítása is a konfigurációban (Rendszer) dől el.

74

Változók

4.12. Konstansok Lehetőség van arra is, hogy olyan adatokat adjunk meg, amelyek a rendszer működése során biztosan nem változnak. Ilyenek lehetnek a különféle fájlnevek, paraméter konstansok, és saját színek. Legalábbis ezek a konstansok leggyakoribb felhasználásai.

3

A konstansok táblázatának kiválasztása az alábbi dialóg ablakot eredményezi:

A szerkesztőablakban a numerikus és a szöveges típusú konstansok közül válogathatunk, a típus legördülő menüben látható listából kiválasztva. Az automatikus típus esetén a megadott konstnasban szereplő karakterek alapján dönti el a rendszer, hogy milyen adattípust választ. Ez nyilván a legegyszerűbb megadás, ezért ez az alapértelmezett. Színkonstans megadása esetén most is lehetőség van a szabványos VISION színek, vagy a Windows színkeverője között választani.

Változók

75

5. Változók strukturálása A változókat strukturálhatjuk a VISION X rendszerben. Mégpedig úgy, hogy a struktúradeklarációnál megadott fa-struktúrák leveleihez rendeljük őket. Ezzel érhetjük el, hogy a trendek és az adatgyűjtés listázásánál ne az egész trend- és adatgyűjtési listából kelljen összeválogatni a szükséges változókat – ami lehetne akár többezer sor –, hanem egy szűkített listából a struktúra adott ágaihoz, leveleihez rendelten. Vagyis kiválasztás előtt előszűrést végezhetünk: Szűretlen lista:

Szűrt lista:

Magának a struktúrának a hozzárendelése részben a konfigurációnál, részben a változódeklarációnál történik. Először azt kell megmondanunk, hogy melyik struktúrát szánjuk a trend- és melyiket az adatgyűjtés számára. Ez természetesen lehet ugyanaz. A beállítás a megfelelő konfigurációs lapon történik. Ezután a változókat már hozzárendelhetjük a megadott struktúra leveleihez. A hozzárendelés a technológiai azonosítónál történik. Amiből egyúttal következik, hogy a strukturált változók technológiai azonosítója is foglalt, azt ettől kezdve más célra nem használhatjuk! Maga a hozzárendelés úgy történik, hogy a változó dialógus képeken a technológiai azonosító mellett látható gombot megnyomjuk.

76

Változók

3

Ekkor jelenik meg a következő dialógus: Ezen a képen a struktúra levelére katintva, majd a Rendben gombot megnyomva, vagy fa levelét dupla kattintással kiválasztva rendelhetjük hozzá a változót a struktúrához.

Struktúra kiválasztása

Levél hozzárendelése dupla kattintással

Előtte azt is ki kell azonban választanunk, hogy melyik struktúrát használjuk a három közül (Trend, Alarm, Adatgyűjtés). Ha megnézzük, a technológiai azonosító a struktúránál az ID-be gépelt szöveges azonosítót kapja meg egy $-jel után írva. Ebből tudja a program, hogy a technológiai azonosító struktúra azonosítóként van felhasználva. Például abban az esetben, ha a fa leveléhez rendelt ID = MAIN, a következőt kapjuk:

Változók

77

3

6. Változóreferenciák Amint az előző fejezetekben láthattuk, a változódeklaráció során számos kiegészítő adatot rendelünk hozzá az egyes változókhoz: technológiai azonosítót, leírást, min, max; és funkciókat: adatgyűjtés, trend, alarm. Ezek között több szöveges (azonosító, leírás, dimenzió,…) és numerikus kiegészítő adat (minimum, maximum, helyettesítési érték,…) is szerepelt. Célszerű ezekhez az adatokhoz való hozzáférést a felhasználói program számára is megengedni. Ezeket a speciális hivatkozásokat nevezzük változóreferenciáknak. Programnyelvi szinten a változóreferencia a változónév és a referencia összekapcsolásával jön létre (a pont karakterrel kapcsoljuk őket össze): VAR.MIN A változóreferenciák a programnyelvben szerepelhetnek a kifejezések bal oldalán is. Tehát a változódeklarációnál hozzájuk rendelt paraméterek programból megváltoztathatók. Sőt ezeket a módosításokat a program a legközelebbi bekapcsolásnál meg is őrzi a DATA.TAG fájlban. A változók valójában objektumok, azaz komplex elemek. Deklarációjuk a VISION telepítési könyvtára alatt a VAR.SDL leíró fájlban található. A változóknak tehát nemcsak az értékére hivatkozhatunk, de számos további mezőjére, amit a változódeklaráció során megadtunk. Például az analóg változók esetén létezik a .MIN, .MAX, vagy a .DIM referencia, ami rendre a változó minimumát, maximumát és a dimenzióját reprezentálja. A diszkrét változók legfontosabb mezője, referenciája pedig az .ATTR, ami az attibútum táblában megadott színt adja vissza. Maga az érték is egy ilyen referencia, mégpedig a .VALUE. Amikor egy változóra hivatkozunk, valójában a .VALUE-ra, mivel a rendszer ezt a változóreferenciát automatikusan az objektum neve mögé fűzi, ha nem adtunk meg ott semmit (mivel ő a default mező). Például az INT=INT+1 kifejezést a program az előfeldolgozás során INT.VALUE=INT.VALUE+1 kifejezésre cseréli (ill. INT.SCALEDVALUE-ra, amennyiben a változó analóg) és csak azután fordítja le. Változóreferenciába ágyazottan valósul meg az analóg változókkal kapcsolatban említett skálázási funkció is. Mégpedig úgy, hogy ott a .SCALEDVALUE referencia kerül hozzáfűzésre automatikusan, ami – ha megnézzük a VAR.SDL fájlt – egy property, azon belül pedig a következő kifejezés: olvasáskor: íráskor:

ScaledValue=Value*Factor+Offset Value=(ScaledValue-Offset)/Factor

ahol a Value, a Factor és az Offset egyaránt mezői a változónak. Az analóg változó tehát a VALUE és a SCALEDVALUE között végez átszámítást a FACTOR és az OFFSET alapján. Ha egy analóg változóra hivatkozunk a nevével, a rendszer a változó.SCALEDVALUE-t olvassa és elvégzi a nyersérték átszámítását. Amikor pedig írjuk a változót, a fordított művelet hajtódik végre. De mindig a forrással, azaz a nyersértékkel (ez a VALUE) dolgozunk. Itt jegyezzük meg, hogy ciklusváltozóként használva és bithivatkozások előtt a változó .VALUE referenciáját explicite szerepeltetni kell, mert valójában ő az analóg változó egész értéke (és egy ciklusváltozó nem lehet lebegőpontos szám, de a lebegőpontos számok bitjei sem értelmezettek). Vegyük észre: ezzel a megoldással bármilyen összetett változótípusok is létrehozhatók, BCD kódolású számok, speciális időformátumok, speciális lebegőpontos számok, hiorder (PC-vel ellentétes belső sorrendű) szavak, duplaszavak, stb. Típusuk szerint az egyes változókhoz a következő változóreferenciák kapcsolhatók:

78

Változók

3

6.1. Analóg- és analóg trendváltozók referenciái Hivatkozás a változó nyersértékére .VALUE .SCALEDVALUE Hivatkozás a skálázott értékre (default) Változó elnevezése .IDEN Változó technológiai azonosítója .TECH Alarm állapotok (0-ás bit = 1. alarm .ALARM csoport, 1-ső bit = 2. csoport, stb.) Változó leírása .MEAN Változó leírása összekapcsolva az .INFO értékével és a dimenzióval Minimum .MIN (.LL) Maximum .MAX (.HH) Előminimum .L .H Előmaximum Skálázó faktor .FACTOR Skálázó eltolás .OFFSET Dimenzió .DIM Előmaximumot meghaladó jelszint .HI Előminimumot meghaladó jelszint .LO Maximumot meghaladó jelszint .TOOHI Minimumot meghaladó jelszint .TOOLO Input/output állapot bitek .IO

3

Trendváltozóknál ezekhez hozzájönnek a .TOTAL, .WINDOW és .SAMPLE mezők.

6.2. Lebegőpontos- és lebegő-trendváltozók referenciái Változó értéke .VALUE .SCALEDVALUE Hivatkozás a tényleges értékre (a változó letiltható!) Változó elnevezése .IDEN .TECH Változó technológiai azonosítója .ALARM Alarm állapotok (0-ás bit = 1. alarm csoport, 1-ső bit = 2. csoport, stb.) Változó leírása .MEAN Változó leírása összekapcsolva az .INFO értékével és a dimenzióval Minimum .MIN (.LL) Maximum .MAX (.HH) Előminimum .L Előmaximum .H .DIM Dimenzió .HI Előmaximumot meghaladó jelszint Előminimumot meghaladó jelszint .LO Maximumot meghaladó jelszint .TOOHI Minimumot meghaladó jelszint .TOOLO Input/output állapot .IO

Változók

79

6.3. Diszkrét és többállapotú változók referenciái .VALUE .IDEN .TECH .ALARM .MEAN .ATTR .TEXT .IO

Változó értéke (default) Változó elnevezése Változó technológiai azonosítója Alarm állapotok (0-ás bit = 1. alarm csoport, 1-ső bit = 2. csoport, stb.) Változó leírása Attribútum tábla színrésze Attribútum tábla szöveges része Input/output állapot

6.4. Szövegváltozók referenciái .VALUE .IDEN .TECH .ALARM .MEAN .IO

80

Változó értéke (default) Változó elnevezése Változó technológiai azonosítója Alarm állapotok (0-ás bit = 1. alarm csoport, 1-ső bit = 2. csoport, stb.) Változó leírása Input/output állapot

Változók

3

3

Változók

81

Képek, képszerkesztés Előszó: A technológia állapotát képeken jelenítjük meg. A képek objektumokból épülnek fel, amelyek éppúgy VAL nyelvű (XSDL) struktúrákat tartalmaznak, mint az alarmok, az adatbázisok, változók, stb. Ebből következik, hogy a képek ugyanolyan szövegfájlok, mint a rendszer bármely más komponense.

Tartalomjegyzék: 1. Bevezetés.............................................................................................................................. 83 2. Képszerkesztés ..................................................................................................................... 84 2.1. Képszerkesztés alapjai................................................................................................... 85 2.1.1. Normál és skálázázott kiválasztás .......................................................................... 85 2.1.2. Objektum-blokk létrehozása .................................................................................. 85 2.1.3. Képszerkesztő üzemmódjai.................................................................................... 86 2.1.4. Kép nagyítása és mozgatása................................................................................... 86 2.1.5. Rácshoz igazítás ..................................................................................................... 87


82

Képek, képszerkesztés

4

1. Bevezetés A képek objektumokból épülnek fel. Például egy bár felrajzolása, a BR objektum elhelyzését, majd a tulajdonságok (szín, kitöltés, mintázat, stb.) beállítását igényli. A képen látható objektumok valamennyi tulajdonsága függővé tehető a globális változóktól, amelyek vagy számítások, vagy a kommunikáció révén kapnak értéket (külső eszközöktől, PLC-től, vagy a hálózati szervertől) – ezáltal pedig közvetlenül befolyásolják a megjelenített képelem viselkedését. A képek használhatóságát az előre gyártott objektumok relatív nagy száma biztosítja (bárgráf, trend, szöveg, számkijelző, skála, fájlnéző, legördülő- és beviteli menü, checkbox, rádiógomb, menük, stb.), de a fejlesztő maga is készíthet új objektumokat – szimbólumként, vagy alacsonnyabb szinten, XSDL objektumok megalkotásával. A képek persze nemcsak saját rajzelemekből állhatnak, megjeleníthetők rajtuk Windows bitmapek (bmp, jpg), clipartok (wmf), animációk (gif, ani, flc, fli) és még nagyon sokféle külső forrásból származó képtipus. Az OLE (Object Linking and Embedding) interface-en keresztül pedig Windord dokumentumok, Excel táblázatok, Powerpoint ábrák, Autocad, vagy Corel rajzok is megjeleníthetők – önálló objektumként. További lehetőségként HTML (ill. DHTML) elemeket is felrajzolhatunk. A VISION képeknek alapvetően hatféle tipusa létezik: 7. Operátori képek (nem görgethető, a főablak teljes megjelenítési felületét használó kép) 8. Extradraw képek (görgethető, a főablak méreténél nagyobb kép) 9. Overdraw képek (különálló ablakok) 10. Szimbólum (ismétlődő képrészletek) 11. Keretek v. sablonok (képenként ismétlődő menük és egyéb keretinformációk) 12. Jelentések (vektorgrafikusan nyomtatható képek, listák) A “képek” gyűjtőszó valójában csak az első két képtípust tartalmazza, mivel önálló képként csak ezek jelennek meg a számítógép főablakában, a többi az operátori kép részeként (szimbólum, keret), vagy különálló ablakban (overdraw), vagy csak nyomtatásban jelenik meg (jelentés). Az operátori kép a leggyakrabban használt képtípus, mivel a megjelenítésnél nem szerencsés olyan képeket rajzolni, amelyeknek csak egy része látszik, a többi a megjelenítő felületen (ablakon) kívülre esik. Ezért van kisebb jelentősége az extradraw képeknek, habár ezekre is szükség lehet (nagyméretű térképek, nagykiterjedésű vonalábrák, atomerőművi rávezető indikátor, stb.) A görgető funkció ettől függetlenül bekapcsolható operátori képeken is. Erre akkor lehet szükség, ha az ablakot összenyomtuk.


83

4

2. Képszerkesztés Képszerkesztésbe most is a Ctrl+Alt+E billentyű megnyomásával, ill. a toolbox megfelelő ikonjára kattintva kerülhetünk, és ugyanezzel a paranccsal vissza online állapotba. A szekersztő látszik a következő ábrán:

Szerkesztő toolbar

4 Objektum választó Szerkesztett kép

Tulajdonság szerkesztő

Automatikusa n szerkesztett XSDL script

A képszerkesztőben új objektumokat egyszerűen a jobb oldali objektum választóból kihúzva, drag-and-drop technikával rajzolhatunk fel a képre, vagy úgy, hogy egyszer rákattintunk, majd a képen lerajzoljuk, ezután a tulajdonság szerkesztőben beállíthatjuk annak tulajdonságait: a színeket, a pozíciót, a méretet, a hozzárendelt változókat, stb. A már felrajzolt objektumok a szokásos módon változtathatók: rákattintás, majd a tulajdonság-szerkesztőben módosítás. A törlés kiválsztás után a Del billentyűvel történik, vagy jobb egérgomb menü és onnan törlés opciót választva. Ezek fölöttébb szokásos módszernek tűnnek, azonban van a képszerkesztőnek pár specialitása, amit nem árt tudni. Ezeket vesszük most sorra.

84


2.1. Képszerkesztés alapjai Miután felraktunk pár objektumot a képre (drag-and-drop), a képszerkesztőt is érdemes valamellyest megismerni. Annyira legalábbis, hogy a képünket rendezni tudjuk. Váltsunk ezért most vissza képszerkesztés üzemmódba.

2.1.1. Normál és skálázázott kiválasztás Amikor rákattintunk egy objektumra – próbáljuk ki ezt a VA-val –, egy vastagabb fekete színű négyszög veszi azt körül. Ez jelzi a normál kiválasztást. Normál kiválasztás állapotban azonban nem lehet megváltoztatni az objektum pozícióját, nem lehet véletlenül sem elmozdítani, sem átméretezni, csak az ún. skálázott kiválasztás üzemmódban, amit egy vékonyabb kijelölő négyszög jelez (szélein a szokásos átméretező boxokkal): Skálázott kiválasztás üzemmódba a jobb egrégomb rövid idejű megnyomásával válthatunk át, majd ugyanazzal vissza normál kiválasztásba. A jobb egérgomb tehát a két üzemmód között vált. Amennyiben az objektumaink átfedő (overlapping) területen vannak, vagyis a mélyebben fekvő objektumokat csak egy másik, fölötte elhelyezkedő objektumon keresztül lehet elérni, a normál kiválasztás üzemmódban addig kell kattintanunk, amíg a kérdéses objektumot ki nem választjuk. A jobb egérgomb megnyomása ilyenkor nemcsak a skálázást / mozgatást engedélyezi, de egyben fixálja is a kiválasztást. Azaz a bal egérgomb felengedése és ismételt lenynomása nem választ ki újabb objektumokat (ahogy történik az számos képszerkesztőben a bosszantásunkra), vagyis nem lehet véletlenül más objektumot elmozgatni / átméretezni. Ezért különböztetjük meg ezt a két üzemmódot a VISION-ben. A skálázott kiválasztás üzemmódba ezenkívül akkor is átvált a program, ha a kiválsztott objektumot legalább 6 pixel-el elmozdítottuk. Így az akaratlan elmozdítást kivédjük, de a kép átrendezése egyszerűbbé válik, amint az objektumokat a kép egyik feléből a másikba mozgatjuk, hiszen nem kell nyomkodni a jobb egérgombot. Próbájuk ki ezeket az funkciókat és közben figyeljük meg, hogy a VA (szelep) objektum méretezése hogyan befolyásolja a szelep alakját.

2.1.2. Objektum-blokk létrehozása A másik lényeges képszerkesztő funkció az objektum-blokk, vagyis az objektumok összeválogatása. Gyakran szükséges, hogy az objektumokat együtt mozgassuk, vagy csoportosan állítsuk bizonyos tulajdonságait. A blokk kijelölése a szokásos módszerekkel történik: 1. Kijelölő négyszög: adott területen található (teljesen befoglalt) objektumok összeválogatása 2. Lenyomott shift billentyűvel egyedi objektumok összeválogatása Itt is az átfedő területen elhelyezkedő objektumok blokkba rendezése érdemel külön figyelmet. A kijelölő négyszög használatához ui. olyan területre kell letennünk az egeret, ahol nincs objektum, mert különben az ott kiválasztott objektumot mozgatnánk el. Ez azonban nem mindig lehetséges. Képzeljük el, hogy a kép háttere egy nagyméretű bitmap, amit nem tudunk kikerülni. Ezen segít a toolbárban található forszírozott blokk kiválasztó gomb: Képek, képszerkesztés

85

4

Ha ezt megnyomjuk, a kijelölő négyszög sarkának a leszúrásakor biztosan nem választunk ki objektumot, s így a blokkba rendezés bármilyen kiinduló pontból elvégezhető. Az összeválogatott objektumok körül egy sárga színű négyszög jelzi, hogy mely objektumok vannak a blokkban. A blokkijelölés egyszerűen úgy törlődik, hogy a blokkon kívülre kattintunk (egy másik objektumra, vagy a háttérre).

2.1.3. Képszerkesztő üzemmódjai Kiválasztás

A képszerkesztőnek három üzemmódja van: 1. Kiválasztás (normál vagy skálázott) 2. Bevitel (insert mód) 3. Blokk

4 Bevitel

Blokk

Az elsővel és az utolsóval már foglalkoztunk, most csak jeleznénk, hogy a toolbár ezeket az üzemmódokat is megmutatja nekünk. Azonban a bevitel mód is érdemel némi figyelmet, lévén nagyban megkönnyíthetí az új objektumok felrajzolását. Nem célszerű ui. a kép összes objektumát drag-and-drop technikával felrajzolni, mivel az így elhelyezett objektumok tulajdonságait később meg is kell változtatnunk. Persze – mondhatnánk – Ctrl-C Ctrl-V technikával kell másolni. Azonban ekkor meg az objektum vezérparamétereinek a módosítása (ilyen az NU, BV, TD esetében a változónév) okoz némi többeltmunkát, de arra is emlékeznünk kell, hogy melyik objektumról van szó egyáltalán. Egyszerűbb és gyakorlatiasabb, ha a képen keresünk ki egy olyan objektumot, amihez hasonlót szeretnénk készíteni, vagyis a vezérparamétert leszámítva az összes tulajdonságát szeretnénk megtartani. Erre szolgál a bevitel üzemmód: •

Kiválasztjuk az objektumot, amihez hasonlót szeretnénk felrajzolni

•

Majd megnyomjuk a plusz gombot:

•

Letesszük az új, régihez hasonló objektumot

2.1.4. Kép nagyítása és mozgatása A kép nagyítása legegyszerűbben a görgetővel lehetséges. Ezzel a kurzor környezetének a nagyítását végezhetjük el. Maximálisan 20-szorosára lehet nagyítani az ábrát. Amennyiben nincs görgető az egerünkön, a toolbárt kell

használni:

A kép mozgatása szokás szerint a görgetősávokkal történik. Ez azonban nem a legkényelmesebb mód, mivel az egeret a gördítősávokra kell mozgatni. Azonban a lenyomva tartott jobb egérgombbal is mozgathatjuk a képtartalmat – egyszerűen arrébb lökhetjük a képet. Végül az egér görgetőjével és a jobb egérgombbal kényelmesen pozícionálhatunk a kép bármely részére.

86


Jobb egérgomb használata:

A jobb egérgombnak tehát van egy újabb funkciója, de van még további is. Foglaljuk össze: - Rövid idejű megnyomás (<400ms): váltás normál és skálázott kiválasztás között - Hosszabb idejű megnyomás: jobb egérgomb menü (benne a fontosabb objektum-opciókkal) - Mozgatás nyomvatartott állapotban: képtartalom mozgatása

2.1.5. Rácshoz igazítás Végül a rácshoz igazítás funkcióról kell még megemlékeznünk, lévén ezzel lehet a legkönnyebben egy vonalba / sorba rendezett objektumokat rajzolni. A rácshoz igazítás értéke a nagyítás mellett található a toolbárban, alapértéke: 0.5 A rácsméret a felhasználói koordinátarendszer 1 egész értéke, ami 8 pixelnek felel meg. A rácshoz igazítás konkrét értéke pedig ennek a 2 egész hatányával való szorzással, ill. osztással keletkezik: 0.125 (=1pixel), 0.25, 0.25, 1, 2, stb.


87

4

Kommunikáció Tartalomjegyzék: 1. Bevezetés.............................................................................................................................. 89 2. Kommunikációs programok készítése ................................................................................. 90 2.1. Kommunikációs objektumok beszúrása........................................................................ 91 2.2. Kommunikációs objektumok leírása............................................................................. 93 2.2.1. Interfész objektumok.............................................................................................. 93 2.2.2. Külső eszközök ...................................................................................................... 96 2.2.3. Driverek.................................................................................................................. 98 2.2.4. Csomópontok ......................................................................................................... 99 2.2.5. IO üzenetek (adatcsoportok) ................................................................................ 101 3. Esemény kezelés ................................................................................................................ 106 4. Kommunikáció online megjelenítése ................................................................................. 107 4.1. Driver üzenetek ........................................................................................................... 108 4.2. Adat, ill. driver monitor............................................................................................... 108 4.3. Modem monitor........................................................................................................... 109 4.4. OPC monitor ............................................................................................................... 109 5. Kommunikáció importálása Excel-ből............................................................................... 110 5.1. Kommunikációs varázsló ............................................................................................ 110 5.2. Az Excel fájl létrehozása............................................................................................. 113


88


4

1. Bevezetés A VISION-ben a kommunikációt önálló taszkok vezérlik, amelyek az adatbázisokhoz, az alarmokhoz és a ciklikus programokhoz hasonlóan külön szálon futnak. A kommunikáció az alarmokhoz és az adatbázisokhoz hasonlóan grafikusan szerkeszthető, az összes kommunikációhoz szükséges objektumot ugyanabban a taszkban adjuk meg. Nem kell tehát különféle konfigurációs és leíró modulok között ingadozni, minden ugyanott “rajzolható”. A kommunikációs modulban az objektumokat az alábbiak szerint csoportosítjuk: • • • • • •

Interfész objektumok (soros, párhuzamos, USB, TCP/IP, UDP interface, stb.) Driverek (SAIA, Siemens, Moeller, Omron, Festo, stb.) Külső eszközök objektumai (Modem) Csomóponti objektumok Bejövő adatcsoportok (üzenetek) Kimenő adatcsoportok (üzenetek)

5

Az egyes objektum-csoportokon belül persze többféle alternatíva közül választhatunk. A kommunikáció alapelvét a következő ábrán látható négyes összerendelés adja:

A fizikai kapcsolat (zöld) objektumai írják le a valódi összeköttetést a számítógép interfészei (soros- és parhuzamos vonalak, USB, TCP/IP, stb.), valamint a csomópontok (sárga) között, amelyek a legtöbb esetben a külső fizikai eszközöket, pl. PLC-ket reprezentálják. A PLC konkrét típusát annak kommunikációs protokollja adja meg, vagyis a logikai kapcsolat (piros).

Kommunikáció

89

Az adatokat adatcsoportokhoz rendeljük és csoportosan írjuk, olvassuk – külön a bejövő és külön a kimenő adatokat (kék). Ez a két csoport adja a négyes összerendelés másik két pólusát. Az OPC szerverrel való kommunikáció speciális OPC csomópontokon keresztül történik, amelyekhez OPC adatcsoportokat kötünk. A kommunikáció konfigurációja az objektumok felrakásából, összekötéséből és a tulajdonságok beállításából áll.

2. Kommunikációs programok készítése Ahogy a bevezetőben vázoltuk, a kommunikáció struktúráját a kommunikáció konfigurációjánál állítjuk össze interfész, driver, csomópont és IO adatcsoportok megadásával ill. azok egymáshoz rendelésével. Abban az esetben, ha a Default projekt készítés opciót választottuk, egy üres kommunikációs programunk már van. Ellenkező esetben (Üres projekt) azt először létre kell hoznunk (ez szükséges akkor is, ha új kommunikációs programot készítünk): Erre a következő dialógus jelenik meg:

A ciklusidőtól függ a kommunikációs objektumok kiértékelésének a gyakorisága

A beviteli mezőkkel kapcsolatban a következőket kell tudni:

90

•

A fájl nevében lehetőleg ne szerepeltessünk ékezetes karaktereket és semmiképpen se használjuk a magyar ‘ő’-t és ‘ű’-t, mert az bizonyos feltételek mellett (más, pl. angol nyelvi környezetben) gondot okozhat. Mindez ugyanakkor nem gond a rövidnév esetében. Ez utóbbi jelenik meg a projektmenedzserben is.

•

Az új kommunikációs program leírása opcionális, de nagyon hasznos.

Kommunikáció

5

•

A végrehajtási ciklusnak a kommunikáció futtatása során van jelentőssége. Lehetőleg ne állítsunk be feleslegesen nagy végrehajtási gyakoriságot, mert az nagyszámú kommunikációs távirat esetén a rendszer teljesítményét rontja. A legjobb értékek 10 és 100 ms közöttiek (100-nál nagyobbat ne állítsunk!).

Ha megnyomjuk a ‘Rendben’-t, létrejön az új kommunikációs program, amit immár a szokásos módon megnyithatunk – dupla egérkatintással, vagy jobb egérmenü, majd Megnyitás opciót választva. Új kommunikációs program esetén persze az ekkor megjelenő kép is üres, ha azonban már vannak konfigurált kommunikációs objektumaink, a működő kommunikációt szemlélhetjük a megfelelő online ábrán:

5

Szerkesztés Az itt látható kommunikációs objektumok konfigurációval keletkeznek. A szerkesztés itt is éppúgy a Ctrl+Alt+E gyorsító billentyűvel, vagy a legördülő menü Elem szerkesztése (ki-be), menüpontjával, vagy a Toolbox megfelelő ikonjával váltható ki a szokásos módon

2.1. Kommunikációs objektumok beszúrása Szekesztési állapotban azt láthatjuk, hogy a kommunikáció készítése is ugyanannak a grafikus szerkeszrőnek a használatát igényli, mint a képek, vagy az alarmok szerkesztése. Ez a kommunikáció esetében a következő objektumok összerendelésével történik:

Kommunikáció

91

1. Interfész objektumok

Objektum választó:

1.1. Soros vonal 1.2. Párhuzamos vonal 1.3. USB 1.4. TCP/IP Socket 1.5. UDP Socket 1.6. Interfész kártya (pl. Profibus) 1.7. Univerzális

5

2. Külső eszközök 2.1. Modem (MODEM) 3. Driverek 3.1. Driver (DRIVER) 4. Csomópontok 4.1. Csomópont (NODE) 4.2. OPC csomópont (OPCNODE) 5. IO üzenetek 5.1. Bejövő üzenet (INPUT) 5.2. Kimenő üzenet (OUTPUT) 5.3. OPC DA olvasás (OPCI) 5.4. OPC DA írás (OPCO) 5.5. Input szeparátor (ISEPARATOR) 5.6. Output szeparátor (OSEPARATOR) 5.7. Módosítás-érzékeny kimenet (MSOM) Az objektum beszúrása az objektum választóban való kijelölésből, majd a rajzoló felületre való kattintásból áll, de felrajzolhatjuk az objektumokat drag-and-drop technikával is, vagyis az objektumot egyszerűen a rajzfelületre húzzuk, majd ott elengedjük. Az objektum pozicionálása automatikus. A program az objektumokat a képháttérben látszó objektum-csoportokba helyezi el úgy, hogy szükség esetén azok méretét igazítja. Az egyes csoportokon belül az objektumok sorrendjét azok felrajzolási sorrendje határozza meg, ami utólag is módosítható a szokásos előre-hátra gombokkal:

92

Kommunikáció

A következő képen már magát a szerkesztőt láthatjuk, benne az egyes mezők magyarázatával. A grafikus szerkesztő részletes ismertetésétől itt eltekintünk, azt a grafikus képeknél elolvashatjuk.

Bekonfigurált interfészek

Objektum típus kiválasztása

5


Autoeditált XSDL forrás

2.2. Kommunikációs objektumok leírása A következőkben részletesen is megvizsgáljuk az egyes kommunikációs objektumok feladatát és azok legfontosabb mezőit, illetve eseményeit.

2.2.1. Interfész objektumok Az interfész objektumok a számítógép fizikai felületét írják le, a kommunikáció ezeken keresztül lehetséges. A legismertebb ezek közül a soros vonal és hasonlóan nyilvánvaló a párhuzamos port, vagy az USP, de a hálózati csatlakozón keresztül megvalósítható TCP/IP vagy UDP socket is lényegében ugyanilyen interfésznek minősül. Az interfész objektumok a tulajdonságaikon keresztül konfigurálhatók:

Kommunikáció

93

Soros vonal esetében a legfontosabb paraméter a baudrate, ill. a paritás és a bitek száma. Maga a kommunikációs port azonban az objektum nevéhez van rendelve, vagyis ennél az objektumnál kötelezően COM1…COM16 elnevezéseket kell választani. Természetesen az objektum az automatikusan felkínált COM1-ről szükség szerint átnevezhető pl. COM2-re. Változó COM-név esetén a Device név használandó (szövegváltozón keresztül). Az RTS vezérlés üzemmód arra szolgál, hogy a adás közben a program automatikusan be-, vételnél pedig kikapcsolja az RTS vonalat. Ezzel az unintelligens RS232 / RS485 átalakítók szolgálhatók ki. Arra azonban felhívjuk a figyelmet, hogy a szoftveres időzítés messze nem olyan korrekt, mint a hardveres, használjunk ezért inkább ún. Auto-RTS átalakítókat (ma már az összes eszköz ilyen). Az RTS vezérlésre azonban rádiomodem esetén is szükségünk lehet. Ilyenkor szerencsére valamivel jobb a helyzet, mivel az adás indításához és leállításához képest nem kell olyan exaktul vezérelni az RTS vonalat. Sőt kimondottan késleltetni kell azt az előidőzítés (RTS bekapcsolása mielőtt az első karakter kimenne a soros vonalon) és az utóidőzítés (RTS kikapcsolása az utolsó kiküldött karakter után) segítségével. A státusz nem írható, csak olvasható tulajdonság, a soros vonal eseménykiszolgálóiban innen olvashatjuk ki a vonal állapotát (Nyitva, Zárva Hibás), amennyiben szükséges. Párhuzamos vonalra viszonylag ritkán van szükségünk, mivel ez az interfész a folyamatirányításban nem igazán használt. Ahogy a soros vonalnál, itt is az objektum nevével azonosítjuk magát a párhuzamos portot, vagyis az objektumot kötelezően LPT1…LPT4-nek kell hívni és az automatikusan felkínált LPT1-et ennek megfelelően át is kell nevezni, ha szükséges. Az USB ma már egyre gyakoribb perifériája a folyamatirányító eszközöknek, ezért erre az interfész típusra valószínűleg mind gyakrabban lesz szükségünk. Egy szépséghibája azonban van a dolognak. Nevezetesen az, hogy az USB porton alapuló kommunikációhoz általában a gyártó még valamilyen külön meghajtót is ad, vagyis az adatok általában külön USB meghajtón keresztül érhetők el. Az elnevezéssel kapcsolatban most is ugyanazok a szabályok érvényesek, mint a soros, vagy a párhuzamos vonal esetében. Az USB port neve kötelezően USB1…USB8 kell, hogy legyen.

94

Kommunikáció

5

Az előbbieknél fontosabb a TCP/IP interfész objektum, amelyen keresztül az egyre gyakoribb IPs folyamatirányító eszközökhöz csatlakozhatunk. Ennél az objektum típusnál a név nem rendelődik össze semmilyen eszköznévvel, ezért azt szabadon változtathatjuk, vagy meghagyhatjuk úgy, ahogy a program felkínálta. A TCP/IP objektumnak két lényeges paramétere van: a host (gazda) és a portcím. Gyakori eset azonban, hogy ezt a két tulajdonságot mégsem töltjük ki, mivel a csak IPs kommunikációra alkalmas eszközök IP-címét a későbbiekben ismertetendő csomópontnál kell megadni, hiszen a készüléket valójában így címezzük. Annak érdekében, hogy az adott IP/port címet ne foglaljuk le duplán, a TCP/IP objektumban azt nem is töltjük ki – az objektum ilyenkor az IP és a port címet a hozzákötött csomóponttól fogja megkapni, örökölni. A TCP/IP objektum IP címének és portcímének a beállítására a legtöbb esetben akkor van szükség, ha a külső eszköz valamilyen TCP/IP – RS232 átalakítón keresztül csatlakozik. Vagyis az eszköz valójában nem IP-s, csak a hozzá vezető út az. A TCP/IP objektum valójában egy ún. Socket-et hoz létre, mégpedig stream típusút (van még a datagram, amit az UDP használ). Ennek az a jellegzetessége, hogy kapcsolat-orientált, vagyis a kommunikációt kapcsolatfelvétel előzi meg, továbbá az adatátvitelt garantált, akárcsak a táviratok sorrendje. Kétféle socket lehetséges: szerver és kliens. Az előbbi kapcsolatfelvételi kérésekre reagál – ilyenkor a host-ba 1 csillagot kell írni (*) ; az utóbbi pedig a kapcsolatfevevő socket – ennek host sorába kell a számítógép nevét, vagy az IP címét beírni. Az UDP nagyon hasolít az előzőekben vázolt TCP/IP objektumhoz, mindössze annyi a különbség, hogy a socket kapcsolat most nem stream, hanem datagram. Ennél a socket típusál nincs kapcsolatfelvétel és az üzenetek megérkezése, sőt sorrendje sem garantált. Mégis gyakran használjuk, mivel lényegesen gyorsabb a TCP/IP-nél és az adatok sorrendje és esetleges elmaradása ciklikus adatlekérdezés esetén nem számít. Interfész kártya alkalmazására akkor van szükség, ha a kommunikáció valamilyen speciális kommunikációs kártya felhasználásával történik. Tipikus példa a PROFIBUS. A rendszert azonban nem érdekli a kommunikációs kártya konkrét típusa, mivel ilyenkor azt feltételezzük, hogy a kártya gyártójától származó driver is rendelkezésre áll. A Siemens PROFIBUS esetében például az S7 Communication üzemmódot használva az adatok ún. VFD-ken (Virtual Field Device) keresztül férhetők hozzá. A külső gyártó által szolgáltatott driver illesztését a megfelelő VISION driver elvégzi, ezért az interfész kártya objektumon nem is kell semmit állítanunk.

Kommunikáció

95

5

Az előzőekben ismertett interfész típus, lévén annak nincs önálló funkciója, akár az ún. univerzális interfésszel is kihelyettesíthető lenne. Ez az interfész is azt feltételezi, hogy gyártótól származó driver végzi el az illesztést, de az nem kártya, hanem valamilyen egyéb, pl. külső átalakító, mint amilyen pl. egy USB-Lon konverter. Az univerzális interfész tehát inkább a funkcionális korrektséget szolgálja, azt, hogy a konfiguráció minél jobban tükrözze a valóságot, minél dokumentatívabb legyen.

2.2.2. Külső eszközök Jelenleg mindössze 1 előre definiált külső eszköz áll rendelkezésünkre, a modem. Gyakori eset, hogy egy soros kommunikációs eszközt nem közvetlenül, hanem modem-en keresztül illesztünk. A modem objektum szabványos Hayes (AT parancsok) modemet feltételez, aminek azonban szabadon konfigurálhatók a paraméterei. A szokásos modembeállító adatok a tulajdonságokon keresztül állíthatók a következőképpen: Az inicialkizáló parancs a modem csatkalkoztatásakor, ill. újracsatlakozásakor (kikapcsolt állapotból való visszakapcsoláskor) kerül kiküldésre. Ezt a stringet gyakran módosítjuk, mivel az ISDN modem-ek X75 protokolljának a beállítása általában készülékfüggő. Amennyiben automatikus kapcsolatfelvételt szeretnénk, az S0=1 parancsot is már az inicializáló stringben érdemes szerepeltetni, de megadható a külön e célra rendszeresített tulajdonságban is. A modem objektum a modemet rendszeresen megszólítja az AT paranccsal és minden 4-ik alkalommal kiküldi neki az automatikus kapcsolatfelvétel parancsot is, hátha egy gyors feszültségkimaradás miatt azt a modem elfelejtette. Ennek ciklusidejét határozza meg az ellenőrzési idő, s amennyiben válasz a passziválási időn belül a folyamatos AT-zásra nem érkezik, a modemmel a kapcsolatot offline-nak tekintjük. Ebből az állapotból való feléledés váltja ki az inicializáló parancs újraküldését. Végül a tárcsázási idővel egy timeout-ot állíthatunk be a kapcsolatfelvételi kezdeményezés számára. Az alapértelmezett 45 másodperc analóg és mobil modemekhez igazított, de ez az idő pl. ISDN estén csupán néhány másodperc. Feleslegesen sokat ne várakoztassuk a rendszert, mert az a hibából való visszatérést (pl. rossz telefonszám után) lassítja. A belső modem kapcsolóval jelezhetjük, hogy a modem nem valódi soros vonalon, hanem valamilyen emulált interface-en keresztül kapcsolódik. Ezt az objektumnak

96

Kommunikáció

5

azért fontos tudnia, mert a soros vonal újrainicializálási kéréseit ilyenkor elnyomja. Újrainicializálás hatására ui. a belső modem eldobja a kapcsolatot, márpedig a kommunikáció reszet állapota (az az állapot, amikor hiba történik, vagy a távirat timeout-ra “fut”) ilyen újrainicializálást okoz – hiszen a rendszer nem tudhatja, hogy a kommunikáció azért hiúsult-e meg, mert a készülék valóban nem válaszol, vagy azért, mert a Windows soros vonala meghalt. Azt emiatt újra kell inicializalni. Nem ez a helyzet viszont belső modem esetén. Ilyenkor valójában nincs semmilyen soros vonal, ami elpusztulhatna, ezért újrainicalizálni sem kell, sőt a fent említett okok miatt nem is szabad. A kapcsolat tulajdonság csoportnál a soros vonali interfész objektumot rendeljük hozzá a modemünkhöz. A modem objektum innen tudja, hogy neki melyik kommunicációs porton kell csatlakoznia. (A soros vonali paramétereket természetesen a megfelelő interfész objektumnál állítjuk be.) Végül a modem vezérlését sem ártana tisztázni, hiszen a kapcsolatfelvételi kérést is el kell juttatni valahogy a modemhez, ahogy a kapcsolat bontását és a változó telefonszámot is. A modem vezérlésnek az az elve, hogy a tárcsázás, felvétel, letétel és telefonszám tulajdonságokhoz egy-egy változót rendelünk a szokásos módon (tulajdonszágszerkesztő sorának bal oldalán látható gombjára kattintva). A telefonszám természetesen string típusú változó, míg a tárcsázás, felvétel és letétel diszkrét. Ez utóbbiak működtetése ezek után egyszerűen úgy lehetséges, hogy a hozzárendelt változóba ‘true‘ (1) értéket írunk. A modem objektum a változót automatikusan visszanulláza, ha a parancsot végrehajtotta. Egy kapcsolatfelvétel például a következő utasításokkal lehetséges – bárhol az alkalmazói programon belül: Telszam=”27812093”; Dial=1

‘Ahol a Telszam szövegváltozó, a Dial pedig ‘diszkrét típusú változó

Kommunikáció

97

5

2.2.3. Driverek Amint a bevezetőben említettük, a driver objektum a kapcsolat logikai aspektusát, vagyis az alkalmazott protokollt határozza meg. Ezzel ugyanakkor mindjárt a csomópont típusát is (ld. köv. pontot). Az alkalmazott protokoll egyszerűen a driver név tulajdonság legördülő menüjéből választható ki. Azonban ezt a tulajdonságot érdemes a fekete jobbra nyíllal kinagyítani, mivel ilyenkor a driverek leírását is megkapjuk, ráadásul a listát kedvünk szerint rendezhetjük:

5 Mintegy 100-féle driver közül válogathatunk. A listában megtalálható az összes elterjedt PLC, de számos speciális készülék, pl. mérleg is. A driver objektumban szerepel a kommunikáció timeout –ja, hogy ne kelljen azt az egyes üzeneteknél egyedileg megadni. A timeout ui. egy-egy rendszeren belül nem nagyon változik, az inkább a kommunikáció jellegétől és sebességétől függ. A driver üzemmódja master (comMaster), slave (comSlacve) és asynchron (comAsync) lehet. A master mindig kezdeményező – először küldeni, majd lekérdezni próbál – féltéve, hogy van mit –, a slave ezzel szemben alapban passzív és csak bejövő adatra küld választ. Vagyis először vesz és csak utána küld. Azaz a vételi és az adási táviratok sorrendjét befolyásolja, hogy a driver master, vagy slave. Pontosan ezt a függőséget oldja fel a harmadik, aszinkron üzemmód, amikor is az adásnak és a vételnek a sorrendje már nem kötött. A konkrét üzemmód azonban nem mindig választható szabadon, mivel sok esetben ez magától a drivertől is függ. Például a MODBUS protokoll esetén külön master (MODRTU) és külön slave (MODSRTU) driverek vannak. Az aszinkron kommunikáció is ugyanúgy protokoll függő, hiszen a protokoll pont az üzenetek szekvenciáját rögzíti. Aszinkron drivereket általában rádiókommunikációs és IP-s rendszerek számára fejlesztenek. A saját cím tulajdonságnak slave driverek esetén van jelentőssége. A master eszköznek ezt a célkészülék címet kell beállítania, amennyiben VISION-ös eszközzel kommunikál. Ez a helyzet pl. akkor is, ha próbaalkalmazásunkat a PLCTEST alkalmazással kötjük össze, ami pont egy Modbus slave drivert futtat és a driver saját címmezőjébe írt 1 érték miatt 1-es címen látható.

98

Kommunikáció

2.2.4. Csomópontok A csomópont a külső eszközöket, pl. PLC-ket reprezentálja. Két alaptípusa létezik: A csomópont egy általános eszköz vagy készülék, aminek a konkrét típusát az objektum nem rögzíti. A készülék azonosítása a hozzákapcsolt driver objektumon keresztül valósul meg, a driverben beállított protokoll által. Mindezt a kapcsolat tulajdonság csoporton belül a driver referenciával adhatjuk meg – egyszerűen a legördülő menüből kiválasztva a felkínált drivert. Hasonlóképpen adjuk meg az interfész referenciát is. Ezzel a két kapcsolattal állítható elő a kommunikációs rendszer bevezetőben említett négyes összerendelésének az első két eleme (a piros és a zöld vonal, összeköttetés). Abban az esetben, ha a külső készülék IP-s eszköz, a Host (gazda) és a Port beállítása is szükséges (ez utóbbi néhány esetben el is hagyható, mert maga a driver a default port címmel dolgozik). A TCP/IP interfész objektumnál említettük, hogy az IP-címet nem féltétlenül kell az interfész objektumban megadni, csak akkor, ha az eszköz egyébként nem IP-s, csak külső TCP/IP átalakítón keresztül kapcsolódik. Ennek egyszerűen az a magyarázata, hogy az IP-s eszközök IP címe, mint afféle készülékcím funkcionál, emiatt az eszköz ún. csomópont címe mellett a helye. Ez utóbbi megadása viszont akkor is szükséges, ha az eszköz egyébként IP-s, mivel az IP-s eszközök egy része képes az adott IP-címen belül több eszközt is címezni. Például a SAIA PLC esetén a csomópontszám a készülék konfigurációjánál az Sbus címnél beállított érték, míg az IP-cím ettől függetlenül állítható. Ezáltal viszont az is elérhető, hogy más, az adott master PLC-vel kapcsolatban álló készüléket is kicímezzünk a master PLC-n, mint gateway-en keresztül. Az IP-s csomópont most is lehet szerver vagy kliens, ahogy a TCP/IP objektumnál láttuk. Az előző hajlandó a kapcsolatfelvételi kérésekre reagálni, az utóbbi pedig a kapcsolatfelvételért felelős. Abban az esetben, ha a Host sorába csillagot írunk, a csomópont szerver lesz, egyébként kliens. Az esetek többségében az IP-s csomópont kliens, hiszen ez csatlakozik a PLC-re (ami a szerver). Előfordul azonban, hogy a szerepeken fordítani kell. Ez történik pl. abban az esetben, ha IP-s Modbus slave-et konfigurálunk, magát az alkalmazásunkat alakítva ezzel egyfajta PLC-vé, adatforrássá, hogy onnan a külső eszköz, pl. egy másik felügyeleti program adatokat tudjon lekérdezni. Ilyenkor van szükség szerver csomópont konfigurálására, ilyenkor kell a Host sorába *-ot írni. A passzív idő beállításával a kommunikáció állapotát készülékenként hangolathatjuk be a szükséges hibafigyelés érdekében. Mint az esemény kezelésnél látni fogjuk, a passziválás esemény pont ennek a timeout értéknek a lejártával fog aktiválódni.

Kommunikáció

99

5

Az OPC csomópont az OPC (Ole for Process Control) kommunikációs szabványhoz, pontosabban OPC szerverhez való illesztést szolgálja. Lényeges különbség, hogy ilyenkor nincsenek interfész és driver kapcsolódásaink, hiszen ezt a feladatot egy önálló eszköz, az OPC szerver látja el. Így a konfiguráció is egyszerűbb: mindössze a megfelelő OPC szerver kiválasztása szükséges:

5 OPC szerver kiválasztása a legördülő menüből

A VISION program OPC objektuma az összes OPC verziót támogatja (OPC DA 1, 2, 3) és képes távoli kapcsolatfelvételre, sőt ún. XML-kapun keresztül, interneten való kommunikációra is – amenyiben a távoli kapcsolat menüpontra kattintunk és az OPC szervert onnan választjuk ki, a saját gépre installált OPC szerverek helyett. Ez az eset látható bal oldalt. XML-kapu használata esetén tölti ki a program az OPC csomópont XML tulajdonság sorait az itt megadott adatok alapján:

100

Kommunikáció

2.2.5. IO üzenetek (adatcsoportok) Az IO üzenetek adatcsoportokat írnak le, amelyeket írunk, vagy olvasunk az adott csomópontokból. Az egyes adatcsoportok emiatt alapvetően inputra és outputra oszlanak, de a konfiguráció szempontjából nem különböznek egymástól, ezért az IO párokat együtt tárgyaljuk. A be és kimenő üzenetek alaptípusa a normál csomópontokhoz kötött adatokat, ill. üzeneteket írja le – egy-egy csoport több adatot, változót is tartalmaz strukturáltan. A konfigurálást itt is minden esetben a Kapcsolat tulajdonság-csoportnál kell kezdeni, mivel a többi tulajdonságot az befolyásolja. A legördülő menüből egyszerűen ki kell választanunk a megfelelő csomópontot, vagy egérrel össze kell kötnünk az üzenet objektum csonkját a csomóponttal. Ezután az adatcsoport objektum már tudja, hogy benne milyen adatok lehetnek – féltéve, hogy a csomópontot is összekötöttük előzetesen a driverrel. Hiszen a driver határozza meg a protokollt és ezzel a készüléket, az pedig az adatokat. Emiatt változik az Adattípus legörülő menü tartalma driverről driverre. Abban az esetben pl., ha Modbust használunk, az adattípus a Mobus keretformátumai szerinti 1(DO),2(DI),3(RR),4(AI),6(WR) és 16(WR) lesz, ha viszont valamilyen Siemens protokollt választottunk, akkor a Siemens konvencióknak megfelelő D (Datenbaustein), T (Timer), Z (Zähler), M (Merker) és C (Counter). Az adattípus az adat címével együtt határozza meg az adatcsoport helyét a PLC-ben úgy, hogy az adott címtől kezdődően olvasunk / írunk adatokat – annyit, amennyit a protokoll maximálisan megenged. Ez a szám lehet akár 1000 byte is, de a legtöbb esetben sajnos 256 byte, 128, vagy csupán 32 (SAIA). A maximális értékeket a VISION ismeri egy speciális leíró fájl alapján (DEF kiterjesztésű fájlok a COMM-ban). A cím is sokféle lehet, de leggyakrabban egy decimális szám. Például a 876 azt jelenti, hogy a 876-ik regisztert, flag-et, vagy be / kimenetek olvassuk / írjuk az adattípusnak megfelelően. Előfordul azonban, hogy a cím több részből áll. A Modbus Plus-nál például 5 részből (1.0.2.3.1), Siemens és DB olvasása / írása esetén pedig két részből, a DB számából és az offszetből azon belül. Például a 12.23 azt jelenti Siemens DB esetén, hogy DB12, DW23. Végül a Modbust érdemes még megemlíteni, mivel az olvasandó (előírt) adatbájtok száma a címben megadható opcionálisan: 1200:80 (1200as címről olvasunk, de csak akkor fogadjuk el, ha pontosan 80 bájt jött be). Erre extra védelem esetén van szükség ( pl. akkor, ha a válasz rendkívül lassú [szatelit] ). Adatok hozzárendelése: Ezek után az adatok hozzárendelése az adat tulajdonság sorára (bal oldali gomb), vagy magára az objektumra duplán kattintva adható meg a következő oldalon látható szerkesztőablakban, az ún. Bitstream editorban:

Kommunikáció

101

5

PLC bitfolytonos adatterület, amihez VISION változókat rendelünk az alsó listából

5

A Bitstream editor az adatokat az adott regiszter / bemenet / kimenet / flag kezdőcímétől (ami fent 123) bitfolytonosan ábrázolja. A VISION-ben ui. minden egyes PLC-beli bithez hozzárendelhetünk adatot, akár kombinációban is, mint az fent is látszik. Akkor is, ha az adatcsoport egyébként nem bites (vagyis nem DI/DO), hanem pl. regiszter. Ebből adódik, hogy egy adatcsoporton belül keveredhetnek az analóg változók diszkrétekkel, sőt lebegőpontos változókkal és még stringekkel is. Az egyes adattípusokat a szerkesztőben eltérő színek jelzik, hogy könnyebben megkülönböztethessük őket. A többállapotú változók értelemszerűen annyi bitet foglalnak el, amilyen szélesek (1-8 bit), azt azonban fontos rögzíteni, hogy e bitek csak szomszédosak lehetnek, amint egy szó típusú változónál sem szórjuk szét a szó egyes bitjeit. A bitek sorrendje is kötött, mégpedig: loorder. Ez azt jelenti, hogy mindig a legkevésbé szignifikáns bit van elől, vagyis a kisebb címen. Itt jegyezzük meg, hogy persze azoknál a külső eszközöknél, ahol ez másképp van (pl. Siemens), a driver maga végzi el a szükséges adatkonverziót, tehát a VISION-ben nem kell már azzal törődnünk, hogy a bitek / bájtok sorrendjét helyreállítsuk. Ez alól egyedül a kevert szó / duplaszó / lebegőpontos típusú adatsor kivétel, amint arra később még visszatérünk. Lehetséges viszont, hogy az egyes adatok között szünetek legyenek, vagyis a diszkrét és a többállapotú változóinkat tetszés szerinti bitcímekre igazíthatjuk a bitszerkesztőn belül. A hézagok beszúrására szolgál ez a gomb: Maga a hozzárendelés a változók alul megjelenő listájára való dupla katintással történik, vagy drag-and-drop technikával, ha azt engedélyeztük (alapban engedélyezett). Az üzemmódtól függően az adat beszúródik, vagy felülíródik: Beszúrás üzemmód

102

Felülírás üzemmód

Kommunikáció

A bitstream editor további beállításai a megjelenítést szolgálják. Állíthatók a színek, a reiszter méret és az oszlopszélesség (1-bit, 8-bit, 16-bit, 32-bit). A szerkesztőablak alsó sorában átválthatunk online megjelenítésre (kék gomb), de az adatok lekérdezhetők az egyes cellákon keresztül is dupla kattintással. A hézagok tömbbe szervezhetők a +1, -1 gombokkal – ez rövidíti a szöveggé konvertálást (Dnone,Dnone -> Dnone[2]). Visszatérve az üzenet-objektumok tulajdonságaira, a többállapotú adatok típusára is ügyelni kell (többállapotú bitek). Ez lehet mbInput, mbOutput és mbAll. Ettől függően kerül továbbításra az üzenetben a többálapotú változónak az alsó vagy a felső tetrádja, ill. a teljes byte. Természetesen annyi biten, amennyit a változónál deklaráltunk. Végeredményben a többállapotú bitek tulajdonság beállitásától függ, hogyan kezeljük a többállapotú változókat. Az input üzeneteknél az alapértelmezett az mbInput, az output üzeneteknél pedig az mbOutput. Ez azt jelenti, hogy az input üzenet nem írja felül a többállapotú változó felső tetrádját, tehát a ki- és bemenő adatok függetlenül kezelődnek – mintha csak külön változók lennének. mbAll beállítása esetén mindez megváltozik és a program többé nem tesz különbséget alsó és felső tetrád között – a többállapotú változó 1-8 bitet foglal el, olvasáskor pedig a teljes bájt felülíródik. Alaphelyzetben a kommunikációs üzeneteket ciklikusan továbbítjuk, ill. olvassuk – olyan sebességgel, amit a taszk ciklusa meghatároz (default = 10ms). Ezen változtat az engedélyezés és a szemafor tulajdonság. Ez utóbbi a hozzárendelt diszkrét változót 1-be állításával engedélyezi a kommunikációt, a kommunikáció sikeres végrehajtása pedig automatikusan nullázza a változót. A kommunikáció vezérlésére ezért a szemafor alkalmasabb, mint a fix engedélyezés, ill. tiltás, mivel ezáltal egyenként kérhetünk, küldhetünk adatokat (szemafor_változó = 1). A frissítési idő beállításával egyedi kommunikációs ciklusokat alakíthatunk ki. Ezt a tulajdonságot úgy érdemes használni, hogy kizárólag a gyakrabban, ill. ritkábban küldendő üzenetekben adjuk meg, vagyis az alacsonyabb, ill. magasabb prioritású adatoknál. A frissítési idő tulajdonságot csak a kivételekre használjuk! Abban az esetben, ha valamiért lassítani kell a teljes kommunikációt, állítsuk be inkább a driver várakozás küldéskor tulajdonságát. Ezáltal minden kiküldött üzenet után a program automatikusan várni fog. Hasonlóan a timeout értéke is az egyedi időzítésű üzenetek esetén állítandó, mivel egyébként a timeout alapértéke a driver objektumnál szerepel. Előfordulhat, hogy egyegy üzenet jóval hosszabb, mint a többi, vagy a célkészülékben speciális működést vált ki, s emiatt hosszabb várakozás szükséges. Ilyenkor kell beállítani az egyedi, üzenetfüggő timeout értéket. A lebegőpontos számok formátumáról, a real típusról is érdemes megemlékezni. Gyakori probléma, hogy az üzenetben továbbított lebegőpontos számokat a PC saját formátumára kell átalakítani. Néha ez csupán a byte-ok sorrendjének a megváltoztatását igényli (ahogy azt alább a duplaszavak kapcsán is látjuk). Az rtWordSwap szó-, az rtByteSwap teljes byte-cserét végez. A default rtFloat a PC saját 4-byte-os lebegőpontos formátuma, az rtSAIA pedig a SAIA PLC-éké. A lebegőpontos számok formátumának a beállításával elérhetjük, hogy az üzenetben vegyesen szerepeljenek a lebegőpontos és az analóg, ill. egész változók. Egyébként az üzenet típusát is változtatnunk kellene, hogy kizárólag egyféle adattípus szerepeljen benne. Ugyanez a funkciója a duplaszó konverzió mezőnek is, csak most 4 bájtos adatok konvertálásáról van szó (dcWordSwap, dcByteSwap).

Kommunikáció

103

5

A státusz tulajdonság nem írható, kizárólag a lehetséges értékek miatt szerepel a tulajdonság szerkesztőben. Viszont a később ismertetendő eseménykezelőben lekérdezhető, hogy ezáltal az üznetküldés állapotáról szerezzünk információt. Lehetséges értékei: msReady (kész), msProgress (folyamatban) és az msError (hibás). Végül az output adatcsoporba beírhatók konstansok is (az input-ba nem!). Ezek egyaránt lehetnek numerikus és string konstansok. Abban az esetben, ha az adat méretére is ügyelni kell, a konstans számot hexadecimálisan kell megadni, vagyis $ után (pl. $12AB). Ilyenkor úgy lehet a hosszt függetleníteni az adattól, hogy a számot mindig 2, 4, 8, vagy 16 helyiértéken adjuk meg; így lesz belőle byte, szó, duplaszó, stb. Az OPC DA input és output adatcsoportjait külön objektumokban állítjuk be. Itt is először a kapcsolat tulajdonság csoportot kell beállítani, az objektumot egy OPC csomóponthoz hozzá kell csatolni, vagy az egérrel bekötni (a csonkokat összehuzalozni). A timeout értéke itt is opcionális és egészen más az értelme, mint a normál üzenetek esetén, hiszen az olvasás nem interfész objektumok által, hanem memóriából, az OPC szerverből történik. Ez csak akkor futhat timeout-ra, ha az OPC szerver leállt. A frissítési idő adatcsoportonként tetszés szerint állítható, azonban az OPC szerver saját sebességénél hiába kívánunk gyorsabban kommunikálni. A frissítési idő minimuma általában 100ms körüli érték. Szemaforozásra ugyanúgy lehetőség van, mint a normál üzeneteknél. Pontosabban kimenő OPC adatcsoportoknál ez egyenesen szükséges is, mivel ciklikusan nem illik adatokat küldeni az OPC szerverbe, csak feltételesen. Ezt segíti a kimenő OPC adatcsoportok egy speciális tulajdonsága, a módosítás érzékenység. Ezzel elérhetjük, hogy csak akkor kerüljön továbbításra az adat, amennyiben azt módosítjuk, és csak az az adat, amit módosítunk. Tehát nem az egész adatcsoport, csupán annak egyetlen eleme kerül átadásra – az éppen módosított változó. A módosítás nem azonos a változásssal. Előfordul, hogy ugyanazt az adatot kell ismételten kiküldenünk, tehát nem biztos, hogy az adat közben változik. Képzeljük el, hogy egy motort egy adott flag-be írt 1-gyel indítunk el, amit a PLC úgy nyugtáz, hogy nullázza a flag-et. A motor újbóli elindítása tehát ugyanannak az értéknek az ismétlését igényli a PLC felé, vagyis az adat valójában nem változik a megjelenítő rendszerben. Emiatt a dolog némileg másképp működik. A módosítás – ebben az értelemben – egyszerűen a változóra kiadott értékadást jelenti, legyen az bár programutasítás, editbox, checkox, bárgráf, eljárás változó argumentuma, stb., és módosításnak minősül, ha a változó ugyanazt az értéket kapja. A szinkron írás a kimenő OPC adatok speciális üzemmódja. Ilyenkor a program megvárja, amíg az aktuális írási művelet befejeződik, s csak azután lép tovább. Ezzel szemben aszinkron üzemmódban puffereli a parancsokat és az OPC szervertől függ, hogy mikor, milyen bontásban hajtja azokat végre. Az adatok hozzárendelése ugyanúgy az adat sorára kattintva, vagy magára az objektumra duplán kattintva állítható be:

104

Kommunikáció

5

Itt már nem kell kiválasztani a legördülő menüből az OPC szervert, mivel azt az OPC csomópontnál elintéztük, viszont fel kell vele venni a kapcsolatot, mivel OPC tallózó egy önálló OPC szekció. Nyomjuk meg tehát a Kapcsolat gombot, hogy megjelenjenek az adatok az OPC intézőjében, illetve a Létező OPC elemek listájában:

5

Az OPC adathozzárendelés során először az OPC szerver tallózójából kikeressük a kívánt adatcsoportot, majd abból az egyes OPC elemeket egyesével, vagy csoportosan (shift-tel, ill. kontrollal összejelölve) adjuk át a kiválasztott OPC elemek listájához. Ahová a VISION változókat a kép alsó felében látható változólistából választjuk dupla kattintással, vagy drag-and-drop technikával. Érdemes arra törekedni, hogy az OPC elemek elnevezése azonos legyen a VISION változónévvel. Ebben az esetben az OPC elemek kiválasztása automatikus VISION változó hozzárendeléssel jár – végeredményben a teljes konfigurációs munka néhány másodperc kattintgatásra redukálódik. A be és kimenő szeparátornak csupán esztétikai szerepe van. Segítségükkel hézagokat szúrhatunk be az egyes üzenetcsoportok közé.

Kommunikáció

105

3. Esemény kezelés Eseményeket a tulajdonság-szerkesztő esemény fülén rendelhetünk hozzá az objektumainkhoz. Ezek legfontosabb feladata a rendszer állapotának, hibaállapotainak a lekérdezése. A kommunikációs objektumoknak futtatás- és átmenet vezérlő eseményei vannak, amiket a következő táblázat foglal össze: Futtatás Átmenet

Inicializálás az objektum aktivizálásakor egyszer fut le Frissítás ciklikusan futó program rész, állapot kiértékelés Driver és interfész objektumok Megnyit az objektum elindult Bezár az objektum leállt Hiba hibás működés Csomóponti objektumok Kapcsolat felépült Kapcsolat létrjött a külső eszközzel Szétkapcsolt Kapcsolat leállt Aktivál Csomópont aktiválódott Passzivál Csomópont passziválódott IO üzenetek objektumai Befejez Sikeres adatátvitel vége Idő lejárt Sikertelen adatátvitel vége (timeout)

5

Ezek közül talán a legfontosabb a csomóponti objektumok Aktivál, Passzivál eseménye, különösen ez utóbbi. Ugyanis ezeknél az eseménykiszolgálóknál lehet a legegyszerűbben letárolni, hogy az adott készülékkel kapcsolatban vagyunk-e. A jobb oldalon látható egyszerű példa beállításaival elérhető, hogy a dwork változó kizárólag akkor legyen 1, ha az adott csomópont aktív, vagyis működik a kommunikáció. Az esemény kiszolgáló programja (utasításai) begépeléssel, vagy a szokásos szervíz varázslóval állítható elő, ami az esemény sorának jobb oldali gombjára kattintva hívható. Például a fenti dword=1 parancsot sem kell begépelni, csupán a varázslóból kiválasztani (var = 1 utasításmodell), majd a varázsló következő lapján a változót hozzárendeljük. Ugyanígy adható meg üzenet képernyőre, képváltás, hangjelzés, stb. Az esemény-kiszolgálóba bármilyen hosszú kiszolgáló program is írható.

106

Kommunikáció

a

4. Kommunikáció online megjelenítése Új kommunikációs program esetén persze az ekkor megjelenő kép is üres, ha azonban már vannak konfigurált kommunikációs objektumaink, a működő kommunikációt szemlélhetjük a megfelelő online ábrán:

5

Ezen a képen a csomópontok állapotát a hozzárendelt szín jelzi: ha működik a kommunikáció, sárga, ha nem, fehér – ahogy a jelmagyarázatban is olvasható. Az egyes adatcsoportok mellett felvillanó kék, ill. hiba esetéb piros bár jelzi, hogy az adat beolvasása sikeres volt-e. A kommunikáció online megjelenítése a felhasználót is érdekelheti, ezért arra a runtime rendszerben is ráválthatunk – ugyanúgy az exec paranccsal. Működéssel kapcsolatos további információkat a driver- és az üzenetobjektumok jobb oldalán látható szükre gombra kattintva kérhetünk: Driver üzenetek megjelenítése

Adatmonitor megjelenítése

Modem monitor megjelenítése

Rákattintásra a következő ablakok jelennek meg:

Kommunikáció

107

4.1. Driver üzenetek A driver üzenetek ablak betekintést ad a kommunikációs rendszer belső működésébe, a táviratok adás-vételébe, továbbá itt jelennek meg a kommunikációs hibák és a kommunikációval kapcsolatos további információk. Az üzenetek ablak fixen 25x64 karakter méretű és közvetlenül a kommunikációs driver írja. Az ablak konkrét tartalma ezért driverről driverre változik. Azt nem is kell tudni, hogy az abban szereplő adatok mit jelentenek, feladata csak debuggolásnál, ill. hibakeresésnél van. Abban az esetben például, ha a kommunikáció nem működik, a driver üzenetek ablak részletes információkkal szolgál. A mellékelt képen egy CRC hibás távirat beérkezését láthatjuk. A hibás, timeout-os üzeneteket általában reset felirat kíséri. A driver akkor működik jól, ha az ablak tartalma folyamatosan pörög. Az az érdekes, amikor tehát nem így van – akkor lehetnek érdekesek a driver üzenetek ablakban közölt konkrét információk.

4.2. Adat, ill. driver monitor A driver monitor már a konkrét adattartalmat mutatja: A lekérdezett adatok típusától függően választhatunk byte-os (8-bit), word-os (16-bit), vagy long-os (32-bit) megjelenítést, az adatok dekódolása pedig decimális, hexadecimális, bool, vagy lebegőpontos lehet. Például digitális adatok beolvasása esetén célszerű először a regiszterméret szerint byte-os, vagy word-ös formátumot választani, majd a dump opcióknál a Boolean-t kijelölni. Ekkor az adatok bitesen, így jelennek meg:

108

Kommunikáció

5

4.3. Modem monitor A modem monitora a lokális üzemmódban lévő modemmel való kommunikációt mutatja. A modem parancssorában egyedi modem parancsokat is kiadhatunk. Az ablak alján pedig a pillanatnyi modem állapotot olvashatjuk le, a modemnek küldött parancsokat és annak válaszait. A rendszer a modemet folyamatosan is megkérdezi (5 másodpercenként), ez az AT> OK szekvencia.

5

4.4. OPC monitor Az OPC monitora ugyanúgy speciális, mivel az adatok itt szövegesen, az OPC elem nevének a feltüntetésével érkeznek, majd az egyenlőség jel után az érték látható. Ha azt szeretnénk, hogy ez a monitor is kövesse az adatokat, a kurzort az ablak végére kell mozgatunk. Ez a leggyorsabban az Ctrl+End billentyűkóddal végezhető el. Ebben az állapotban a monitor önmagától gördül és az ablakpozíciót mindig az utolsó OPC-üzeneten tartja. A sor elején az affektált változó neve olvasható, utána az adatok száma.

Kommunikáció

109

5. Kommunikáció importálása Excel-ből A kommunikációt nemcsak azzal a módszerrel lehet előállítani, amit ebben a fejezetben ismertettünk. Ez igazából csak kisszámú változót tartalmazó és új alkalmazásoknál előnyös, illetve meglévőek bővítésekor. Többezer jelet tartalmazó meglévő rendszerek teljes kommunikációs rendszerének az előállításakor már nem túl praktikus, mivel sok munkával és rengeteg hibalehetőséggel jár. Létezik ezért a VISION-ben egy Excel-re épülő technológia is. Ennek az a lényege, hogy az adatok címét és típusát egy Excel táblából veszi és ennek alapján állítja össze a szükséges – adott megköttéseknek, pl. maximális üzenetméretnek megfelelő – üzeneteket. Excel táblára épülő megoldás esetén az alábbi adatokra van szükségünk: Munkalap PLC munkalap

Változóleíró munkalapok

Információk A PLC leíró tábla tartalmazza: • a PLC nevét • a PLC csomópont címét (ha van) • az IP-címet (ha van) • és a portcímet (COM-port esetén pl.), ill. objektum nevét (TCP/IP esetén) A változónévhez kötve az alábbi információk szüségesek: • a PLC név (ez kapcsolja össze az adatot a PLC munkalappal) • kommunikáció iránya (input, output, inoutput) • adattípus és cím

Az adattípus és a cím megadása együtt történik és a szabadon konfigurálható. Például az R1000-es megadás (8, 16, 32-bites) regisztert jelenthet és 1000-es címet.

5.1. Kommunikációs varázsló A kommunikációs üzenetek előállítása a kommunikáció komponsben lehetséges szerkesztési üzemmódban. A projektmenedzserből tehát magát a komponenst kell kijelölni, szerkesztési üzemmódba menni, majd az Importálás Excel-ből menüre rákattintani. (ez a menü csak szerkesztés üzemmódban látszik. Az importálás a teljes kommunikációs taszkot felülírja, ill. létrehozza, tehát a kétféle módszer keverése (kézi konfiguráció és importálás) csak úgy lejetséges, hogy a kommunikációs varázslóban más fájlnevet adunk meg, mint amit kézzel készítettünk. Így végeredményben a kommunikációban több fájl jön létre, amelyek egy része kézzel, egy része pedig gépesítetten áll elő. A kommunikációs varázsló látható a következő ábrán:

110

Kommunikáció

5

5

Ez az első ránézésre talán komplikáltnak tűnő dialógus valójában az összes Excel adatnak a megadását tartalmazza, ezért ilyen összetett. Nézzük meg a legfontosabb részeket: Bemenet

Ebben a menücsoportban adjuk meg az Excel fájlt és a fájlformátum leírására szolgáló CFR konfigurációs fájlt. Ez utóbbi azért kell, mert az Excel fájl munkalapjai és az egyes mezők azonosítására szolgáló oszlopcímek szabadon konfigurálható (ld. alább).

PLC leíró

A menücsoport a fejezet elején említett PLC munkalap oszlopait definiálja. Ez az Excel tábla első sora lesz. Abban az esetben, ha a PLC név beviteli mezőbe “PLC”-t írunk, a program a PLC címmel ellátott oszlopban fogja keresni a PLC nevét. Magának a munkalapnak a neve is megadható (fent: PLC).

Kommunikáció leíró

A változóleíró munkalapokon belül adjuk meg a változó kommunikációs azonosításához szükséges adatokat – ugyanúgy az egyes oszlopok első sorába írt azonosítókat (fent: Name, Type, IO, PLC és Dir). De megadhatók maguk a munkalapok is – tetszés szerinti számban és névvel (munkalap törlése, hozzáadása). A PLC leíró és a kommunikációs leíró együtt kerül a bemenetnél meghatározott CFR konfigurációs fájlba. A VISION saját ExportImport formátumának, amit a változók exportálása állít elő, is van Kommunikáció

111

egy ilyen CFR leírója (VISION.CFR). Ezért ha nem térünk el a VISION formátumától, a fenti két leíróval már nem kell törődnünk. Elképzelhető azonban, hogy az adatok konvertálása a PLC IOlistájából valamilyen teljesen más felépítésű táblázatot eredményez. Ezért lehet szükség saját Excel formátum megadására (ld. bacsviz.cfr) IO leíró

Az IO leíró szolgál az adattípus-cím kombinációk megadására. Ehhez először egy drivert kell kiválasztanunk, vagy megadnunk a kép jobb-felső szélén látható dropdown box-ban. Itt begépelhetünk egy új nevet is, ha az még nem létezik, majd kitöltés után lementhetjük. Módosíthatóak tehát a meglévő IO leírók és készíthetők újak – tetszés szerint. Az IO leíró mindig a driver nevéhez kötődik; a megfelelő konfigurációs fájl, ami SPC kiterjesztéssel bír, a VISION telepítési könyvtára alatt a COMMban található. Magának a táblázatnak az előállítása sem túl bonyolult, ha megértjük a lényegét. Az adatokat a cím elé írt betűvel azonosítjuk, tehát arra kell ügyelnünk, hogy ez egyértelműen meghatározza az adatot. Ez az ún. szintaktika (pl. R#). Ezután megmondjuk, hogy az adott szintaktikájú adat (pl. R#) milyen VISION-PLC típust jelent (a VISION definíciós fájljaiban nyilvántartja az egyes PLC-k lehetséges adattípusait – pl. RR, RF, RC), majd meghatározzuk az adat tárolási típusát (LONG, BYTE, BOOL, stb.), regiszter offszet méretét bit-ben, valamint azt, hogy ebből az adattípusból a távirat legfeljebb mennyit tartalmazhat (pl. 32 db regisztert). Ezekből a relációkból áll össze a táblázat. A rendszer SAIA és MODBUS esetére tartalmaz példát.

Kimenet

Ez a menücsoport már a tényleges konvertálást végzi. Itt adhatjuk meg a projekt elérési útját és a kommunikációs fájl nevét. Természetesen ezeket a program feltölti induláskor a projektnek megfelelően, de a módosításra mégis szükség lehet. Emlékezzünk: az itt megadott kommunikációs fájlt (COMM) a konvertálás teljes egészében felülírja, ezért minden korábbi munkánk elvész. Ha ellenben módosítjuk ezt a mezőt COMM2-re, akkor a konvertáló program új fájlt fog létrehozni és azt hozzá is fűzi a projekthez. A kommunikációs csatornák szétválasztásával tagoltabbá tehetjük a rendszert, ami különösen nagyszámú adat esetén előnyös – nem célszerű minden adatot egy kommunikációs taszkba konvertálni. Ebben az esetben a Kom. fájl neve után a program egy sorszámot fűz (COMM1, COMM2, …).

A program használata ezek után rendkívül egyszerű: meg kell nyomni a Teszt, vagy az Alkalmaz gombot. Az előbbi azért lehet célszerű, mert akkor egy kis statisztikát is készít a program, amiben megadja, hogy hány üzenetet készítene, azok hány elemet tartalmaznának, stb. Az alkalmaz hatására történik meg a kommunikációs fájl tényleges előállítása és ezzel a kommunikációs varázsló is bezárul.

112

Kommunikáció

5

5.2. Az Excel fájl létrehozása A konvertálás előtt persze meg kell alkotnunk még az Excel fájlt is. Ez a legegyszerűbben a VISION változó-export funkciójával készíthető el, amit a változókról szóló fejeztben ismertettünk:

5

Ennek hatására a program nem egyszerűen állőállítja a kommunikációs varázslónak szükséges és a VISION.CFR leírónak megfelelő Excel fájlt, de azokat az oszlopokat, sőt PLC munkalapot is beszúrja, ami a kommunikáció beállításához kell. Mivel azonban a változódeklaráció és a kommunikáció a VISION-ben teljesen elválik egymástól, a változóexport nem tudja kitölteni a kommunikációs adatokat, csak előkészíteni tudja őket a begépelésre. Nézzük meg, hogyan. A PLC munkalap a következőképp néz ki (egy példát is begépelve a PLC-re): Látható, hogy az Excel tábla tényleg a VISION.CFR-ben megadott oszlopneveket tartalmazza – alá egyszerűen be kell gépelnünk a PLC-ket. A változó leíró munkalapok tárgyunk szempontjából fontos része pedig így néz ki: A PLC azonosítása a PLC oszlopban történik, az adat irányát a Dir határozza meg (I, O vagy IO), a címet és a PLC adattípust együtt pedig az IO. Amennyiben kitöltjük, a telejes kommunikációt előállíthatjuk ezekből az IO megadásokból – pár másodperc alatt. Az Excel fájl szerkesztése a kommunikációs varázslóból is elindítható: Fájl B Megtekintés Excel-ben. Kommunikáció

113

Események kezelése (alarm rendszer) Tartalomjegyzék: 1. Bevezetés............................................................................................................................ 115 2. Alarmok konfigurációja ..................................................................................................... 115 2.1. Alarm konfigurációs panel .......................................................................................... 115 2.2. Alarm adatbázis megváltoztatása ................................................................................ 119 3. Alarm programok készítése................................................................................................ 121 3.1. Alarm objektumok beszúrása ...................................................................................... 122 3.1.1. Egyedi alarm objektumok .................................................................................... 123 3.1.1.1. Egyedi alarm objektumok tulajdonságai ........................................................... 124 3.1.1.2. Speciális alarm feltételek .................................................................................. 125 3.1.1.3. Alarm eseménykiszolgáló ................................................................................. 126 3.1.2. Alarm csoport....................................................................................................... 127 3.2. Alarm programok tulajdonságai.................................................................................. 128 4. Eseménynapló .................................................................................................................... 129 4.1. Nyomtatás.................................................................................................................... 130 4.2. Keresés ........................................................................................................................ 130 4.3. Kiválasztás .................................................................................................................. 130 4.4. Események nyugtázása................................................................................................ 131 4.4.1. Nyugtázás a nyugtázatlan események listájában.................................................. 132 4.5. Eseménynapló törlése.................................................................................................. 132


114

Események kezelése (alarm rendszer)

6

1. Bevezetés A VISION-ben az események (alarmok) csoportokra és típusokra oszlanak. A nyolc fő alarm csoport tetszés szerint konfigurálható (elnevezés, szín, rendszerbeli kiszolgálás). A három típus pedig az események bekövetkezése, megszűnése és nyugtázása szerint jön létre. Így összesen 24-féle alarm létezik. Emellett az események tetszés szerint strukturálhatók. Az események keletkezhetnek a VISION-ben automatikusan (ld. rendszeresemények) és egyedi alarm feltételekkel: 1. Az automatikus alarmok közé tartozik a rendszerbe való be- és kilépés, az analóg változók értékhatár túllépése, a kezelői parancsok, a kezelő be- és kijelentkezése, a változások naplózása, stb. Mindez, az alarm csoportokkal együtt, az alarmok konfigurációjánál állítandó be (2. fejezet). 2. Az egyedi alarmok, egyedi feltételek kiértékelésének az eredményeként keletkeznek, s küldenek üzeneteket az eseménynaplóba. Mindez az alarm programok konfigurációjánál állítható be egyedi alarm objektumok beszúrásával, majd az alarm feltétel, ill. az üzenet megadásával (3. fejezet). Az eseményeket a rendszer SQL adatbázisban tárolja el, amelynek beállításai a rendszerkonfigurátor fájlrendszer menücsoportjában történik. Alaphelyzetben az eseménynapló Microsoft Access formátumú, de a fájlrendszer beállításánál bármilyen más SQL adatbázis is beállítható (MS-SQL, Oracle, Interbase, Informix, DB2, stb.). Külön érdekessége a rendszernek, hogy képes automatikusan új adatbázist nyitni – havonta, naponta, hetente, évente – beállítás szerint. Ezzel azt érjük el, hogy az esemény adatbázisunk ne legyen túl nagy, mert egy bizonyos méret felett a napló nagyon nehézkesen kezelhető. Az időtartam beállítása is a fájlrendszer konfigurációjánál történik, egyszerűen úgy, hogy fájl nevébe $Y (év), $M (hónap), $D (nap), vagy $W (hét) szövegrészeket szúrunk. Az alapbeállítás szerinti A$Y$M név pl. A200508 adatbázist eredményez, ami természetesen havonta megújuló eseménynaplót jelent. Az SQL adatbázisban eltárolt eseményeket jeleníti meg az eseménynapló, amelynek kezelésére, benne az események szűrésére, keresésére, nyomtatására külön VISION utility szolgál.

2. Alarmok konfigurációja Mielőtt az egyedi alarm objektumaink előállításához hozzákezdenénk, mely nem más, mint az ún. alarm program, az alarmok konfigurációját célszerű elvégezni. Hiszen az egyedi alarmoknál az alarm csoportot is meg kell majd adni, így nem árt tudni, hogy azok mit jelentenek. Elfordulhat továbbá, hogy az alarm adatbázis típusát is meg szeretnénk változtatni.

2.1. Alarm konfigurációs panel Az alarm konfiguráció paneljéhez háromféleképpen is eljuthatunk: (1) Projektmenedzser, azon belül Konfiguráció, majd Alarmok, vagy (2) a Konfiguráció kiválasztásánál a kép jobb oldalán mejelenő XP menün belül Alarmok, ill. (3) a Konfiguráció legörülő menüjéből Alarmok beállítása. Ez utóbbi az konfigurátort önnálló ablakban jeleníti meg, amíg az


115

6

előzőekben ismertetett megoldással a következő beállító képhez jutunk (mindhárom módszer ugyanazt a komponenst jeleníti meg, ezért mindegy, hogy melyiket használjuk):

6

Illetve főmenüből:

Ezután begépelhetjük a 8 alarm csoprot nevét, megadhatjuk a szín, az alarm prioritását és a bekövetkezésnél, megszűnésnél, ill. elfogadásnál a naplóba írandó szövegrészeket. Ez utóbbiak a gyors tájékozódást segítik, mivel az alarm szövege egyébként gyakran ugyanaz az esemény bekövetkezésekor és megszünésekor. Ezt érzékelteti a következő példa:

A szöveg ugyanaz, csak az érték és az alarm típusnak megfelelő rész különbözik

116

Alarm típusnak megfelelő kiegészítő szöveg


Nézzük ezek után a K-E-B-R mező beállításait (az egyes betűk jelentését a jelmagyarázatnál is olvashatjuk): K: A Kiválasztásnál bejelölt alarmcsoportok lesznek azok, amelyek alaphelyzetben megjelennek majd az eseménynaplóban. A kezelő a napló beállításainál eldöntheti, hogy mely alarm csoportokat kívánja vizsgálni, a beállítás csupán az alapértelmezést adja. E: Az Elfogadásra szánt eseménycsoportokat jelölhetjük ki ebben az oszlopban. Ezeket az eseményeket a kezelőnek nyugtáznia kell majd. B: Az esemény bekövetkezése járhat egy rövid hangjelzéssel, Beep-pel. R: A Rendszer által kezelt alarm csoportokat jelölhetjük ki ebben az oszlopban. A rendszer által kezelt események a következők: 1. A rendszer képes arra, hogy a Változásokat automatikusan naplózza. Ez a beállítás ugyanakkor ritkán célszerű, mivel így rengeteg naplóbejegyzés keletkezhet. Ritkán változó rendszerek esetében viszont (mint egy stratégiai tároló pld.) rendkívüli módon leegyszerűsítheti az alarmok konfigurációját. 2. A Parancsok naplózását a rendszer a többállapotú változók esetében automatizálja – akkor, ha a többállapotú változók felső 4 bitjét is használjuk (ld. többállapotú változók konfigurációját) 3. Az Analóg hibák az analóg változók Alarm beállító menücsoportjában adhatók meg az ott kijelölt HH (Max túllépés), H (előmax túllépés), L (előmin túllépés), LL (Min túllépés) szerint. 4. A Rendszer üzenetek közé a rendszerbe való be- és kilépés, a kezelői be- és kijelentkezések, valamint a rendszer hibaüzenetei tartoznak. Az automatikus rendszer események beállítása úgy történik, hogy a Rendszer alarm-kezelés menücsoportban hozzárendeljük az egyes rendszer eseményekhez tartozó alarm csoportokat: Az itt hozzárendelt alarm csoportok azonban csak akkor végzik el a nekik megfelelő események automatikus naplózását, ha azt az alarm csoportok beállításánál, a Rendszer oszlopban engedélyeztük is. Erre azért van szükség, mert a rendszer alarm kezelés csoportokhoz való hozzárendelését mindenképp meg kell adnunk, de az nem biztos, hogy valóban használt. Az alarmkonfiguráció további beállításai az események típusát (be, ki, elfogadva), azok elnevezéseit és az eseménynapló dátum / idő formátumát tartalmazzák. Mindezen beállítás az Egyéb paraméteknél lehetséges. A Kiválasztva opció az adott eseménytípus alaphelyzetnek megfelelő kiválasztását eredményezi Események kezelése (alarm rendszer)

117

6

az eseménynaplóban, amit azonban a kezelő ott megváltoztathat. Az alarmcsoport táblázatának Kiválaszt oszlopa, valamint ezek a checkbox-ok együtt adják meg a 24 alarm fajta alaphelyzet szerinti kiválasztását a naplóban. Végül az eseménynapló megjelenítendő oszlopai adhatók még meg:

Ha mindent kipipálunk, az eseménynapló a következőképpen néz ki:

A változó neve ritkán érdekli a felhasználót, ezért az alaphelyzetben nem látszik. Az is eldöntendő, hogy a rendszer használja-e a területet, amely az események strukturális rendszerbe való szervezése, tehát igen nagyszámú esemény esetén használt. Ennek részleteit a strukturák leírásánál ismertetjük. Az eseménynapló T oszlopában grafikusan jelenik meg a megfelelő alarm típus és csoport. A típus az ikon alakjához (teli = bekövetkezés, üres = megszűnés, kör alakú = nyugtázás), a csoport pedig az alarmkonfigurációnál megadott színhez kötődik. Mindez a a napló súgó -> jelmagyarázat dialógusában kiválóan látszik is:

118


6

2.2. Alarm adatbázis megváltoztatása Amint a bevezetőben említettük, az alarmok alaphelyzetben Microsoft Access adatbázisok, de ez átállítható bármilyen más adatbázis típusra, MS-SQL-re, Oracle-re, Interbase-re, stb. Ugyancsak szükséges lehet az alarm adatbázis nevének a dátum-időhöz való hozzákapcsolása, hogy ne keletkezzenek a rendszerben túl nagy adatbázisok, mert az megnehezíti az események kezelését (szűrését, keresését, nyomtatását, stb.) Az alarm adatbázis a rendszerkonfiguráción belül a fájlrendszernél állítható be:

Alarm adatbázis beállítása

6

Az Alarm menücsoportban adható meg az adatbázis neve, a magyarázatban pedig elolvasható, hogy az egyes speciális szövegrészeknek ($Y, $M, $W, $D) mi a jelentése (év, hó, hét, nap). Az adatbázis beállítása az erre szolgáló nyomógombbal lehetséges. Ezt megnyomva jelenik meg az op. rendszer Adatkapcsolat tulajdonságai panelje, ami bal oldalt látható. A beállító ablak ugyan mindjárt a Kapcsolat fülre ugrik, hiszen már van egy kiválasztott szolgáltatónk (MS-Access), de abban az esetben, ha az adatbázis típusát is meg akarjuk változtatni, vissza kell kattintanunk a Szolgáltató fülre. Először tehát a szolgáltatót, más szóval a provider-t (MS-Access esetén Microsoft Jet 4.0 OLE DB Provider) kell kiválasztani, majd a szolgáltatótól függően az adatbázist és annak paramétereit. Arra azért vigyázzunk, hogy a saját (felkínált) Access adatbázisát ne jelöljük ki a rendszernek ezzel a módszerrel, mert attól kezdve a rendszer összes eseménye ugyanabba az adatbázisba fog beíródni, egy idő után tehát kezelhetetlenül nagy lesz. Az adatbázis átirányításnak csak akkor van értelme, ha egy “valódi” SQL szerverre térünk át, pl. Oracle-re, vagy MS-SQL-re. Események kezelése (alarm rendszer)

119

Microsoft SQL servert választva pl. az alábbi beállító kép jelenik meg: Ennél a beállító panelnél a szervert kell először kiválasztani, majd az ún. autentikációs módot, ami az MS-SQL adatbázistól is függ, végül magát az adatbázist a legördülő menüből. Következésképp az adatbázisnak itt már léteznie kell, mielőtt azt a VISION-höz hozzárendelnénk. Új adatbázisokat MSSQL esetén a Microsoft Enterprise Manager-ével készíthetünk, de annak részletezése nem tárgya e dokumentáiónak. Befejezés előtt célszerű még megnyomni a Kapcsolat tesztelése gombot. Abban az esetben, ha a megadott adatbázison belül még nincs Log, Ack és Summary tábla (ezek szükségesek az alarmrendszer működtetéséhez), akkor azokat a VISION létrehozza számunkra, de előtte még megerősítést kér:

) Amenyiben eltérünk a Microsoft Access-től, a fájlnév beállítása sem működik többé, mivel új adatbázis készítésére a rendszer csak MS-Access esetén képes. Az adatok archiválását és karbantartását is máképp kell tehát ebben az esetben megoldani. Szerencsére az elterjedet SQL adatbázis kezelő rendszerek erre változatos lehetőséget kínálnak.

120


6

3. Alarm programok készítése A legtöbb eseményt természetesen nem képes a rendszer automatikusan előállítani, mivel az egyedi alarmfeltételekhez kötött, a vezérlőberendezésben keletkező, vagy a technológiai rendszer bejövő jelzései szeint. Ezeket az alarmokat készítjük el az alarm programban, egyedi alarm-objektumok hozzáadásával. Abban az esetben, ha a Default projekt készítés opciót választottuk, egy üres alarm programunk már van. Ellenkező esetben (Üres projekt) azt először létre kell hoznunk (ez szükséges persze akkor is, ha új alarm programot készítünk):

Erre a következő dialógus jelenik meg:

Ha nem sokszorozható, az alarm program a taszkrendszerben csak egyszer indulhat el

A beviteli mezőkkel kapcsolatban a következőket kell tudni: •

A fájl nevében lehetőleg ne szerepeltessünk ékezetes karaktereket és semmiképpen se használjuk a magyar ‘ő’-t és ‘ű’-t, mert az bizonyos feltételek mellett (más nyelvi környezetben) gondot okozhat. Mindez ugyanakkor nem gond a rövidnév esetében. Ez utóbbi jelenik meg a projektmenedzserben is.

•

Az új alarm program leírása opcionális, de nagyon hasznos.

•

A végrehajtási ciklusnak az alarmfeltételek kiértékelésénél van jelentőssége. Lehetőleg ne állítsunk be feleslegesen nagy végrehajtási gyakoriságot, mert az nagyszámú alarm esetén a rendszer teljesítményét rontja.

Ha megnyomjuk a ‘Rendben’-t, létrejön az új alarm program, amit immár a szokásos módon megnyithatunk – dupla egérkatintással, vagy jobb egérmenü, majd Megnyitás opciót választva. Új alarm program esetén persze az ekkor megjelenő kép is üres, ha azonban már van pár konfigurált alarmunk, egyfajta alarmtablót láthatunk:


121

6

Ebben az alarm állapotokat a hozzárendelt szín jelzi: ha bekövetkezik egy esemény, az előállításáért felelős objektum is színt vált. A piros lehet pl. a vész jele. Az alarm tabló on-line megjelenítése a felhasználót is érdekelheti, ezért arra a run-time rendszerben is ráválthatunk – ugyanúgy az exec paranccsal. Szerkesztés

6

Az itt látható alarm objektumok egyedi alarm konfigurációval keletkeznek. A szerkesztés itt is éppúgy a Ctrl+Alt+E gyorsító billentyűvel, vagy a legördülő menü Elem szerkesztése (ki-be), menüpontjával, vagy a toolbox megfelelő ikonjával váltható ki

3.1. Alarm objektumok beszúrása Szekesztési állapotban azt láthatjuk, hogy az alarmok készítése is ugyanannak a grafikus szerkeszrőnek a használatát igényli, mint a képek, vagy a kommunikáció szerkesztése. Ez ugyanakkor az alarmok esetében fölöttébb egyszerű is, lévén összesen 2 db alarm objektum létezik: 1. Egyedi alarm 2. Alarm csoport A következő képen már magát az alarm-szerkesztőt láthatjuk, benne az egyes mezők magyarázatával. A grafikus szerkesztő részletes ismertetésétől itt eltekintünk, azt a grafikus képeknél elolvashatjuk. Itt csupán annyi a különbség, hogy az egyes objektumok pozicionálása automatikus, akárcsak a kommunikáció, vagy az adatbázisok szerkesztésénél.

122


Bekonfigurált elemek

Objektum típus kiválasztása


6

3.1.1. Egyedi alarm objektumok Az egyedi alarm elhelyezése egyszerűen az objektum lerakását igényli. Ekkor a program megkérdezi, hogy azt melyik változónkhoz kössük azt:

Mint látható, a program automatikusan a diszkrét változókat listázza, mivel arra számít, hogy az itt kiválasztott változó egyben a feltétel is. Ez azonban nem kötelező, mivel az alarm feltétel lehet sokkal bonyolultabb is (pl. VALOZO
123

változó listája checkbox-szal esetenként az valamennyi változót láthatóvá kell tennünk, hogy abból választhassunk. Gyakori alarm feltétel megadási mód a direkt egész változók adott bitjének az állapota. Ez ugyancsak könnyen megadható a 0..3 bitek esetében, mivel elég a megfelelő rádió gombot kijelölni, az ennél nagyobb számokat azonban már be kell képelnünk (12). Az ábrán látható Lo alarm feltétel mellett hasonlóan adható meg még a Hi, a TooLo és a TooHi. Ezek a megfelelő (HH, H, L, LL) határértékek vizsgálatát végzik el. Ha most duplán kattintunk a felkínált változók megfelelő sorára, vagy megnyomjuk az Alkalmaz gombot, megtörténik az új alarm objektum beszúrása. Ezzel azonban még nem vagyunk kész, lehet, hogy meg kell változtatnunk az objektum tulajdonságait.

3.1.1.1. Egyedi alarm objektumok tulajdonságai Leggyakrabban az alarm csoporton (1..8), ritkábban az alarm feltételen kell módosítanunk, mert egyáltalán nem biztos, hogy az magának a változónak a neve. Lehet, hogy annak negáltja: not HIBA. De lehet más reguláris kifejezés is, mely adott esetben más változóktól is függ. Az alarmfeltétel előállítására semmiféle megkötés nincs, néhány példát már az előző pontban, a változó kiválasztásakor is láthattunk (bitcím, változóreferenciák). Ugyanez mondható el a hibaüzenetről is, az is lehet bármilyen szöveg, szövegfüggvény, változóreferncia (tipikusan: Info vagy Mean) és lehet változók szöveg típusú reguláris kifejezése is. Például: HIBA.MEAN+”: “+str(MERES)+” “+MERES.DIM Az Info változó referencia használata azonban a leghatásosabb, mivel az a változó leírását és az értékét egyesíti, analóg változóknál pedig még a dimenziót is hozzáfűzi az alarm üzenet szövegéhez: Gőzhőmérséklet mérés: 10.3 ۫ C. Ezért is használja a program a változó Info referenciáját default-ként. A Változó név hozzárendelésnek csupán az a jelentőssége, hogy ezen keresztül képes a rendszer az üzenetet és a feltételt is módosítani. Képzeljük el azt a helyzetet, hogy nagyszámú, de hasonló felépítésű alarmot kell megadnunk. Ekkor az a célszerű eljárás, hogy elkészítünk egyet, majd azt Ctrl+D-vel ۫lemásoljuk annyi példányban, amennyi szükséges. Ezután egyenként rákattintunk a változó tulajdonság módosító gombjára és kiválasztjuk az adott alarmhoz tartozó másik nevet, vagy egyszerűen begépeljük azt.

124


Ide kattintunk

6

Erre a program kicseréli a változó nevét, annak összes előfordulását az alarm feltételben és az alarm üzenetben is. Ez nagyon hasznos, ha a változó neve több helyen is szerepel, vagy több példányban. Például az alábbi alarm feltételben négyszer is: ValtozoValtozo.Max A változó hozzárendelése emellett akkor is szükséges, ha az aktuális alarm állapotot a képen is meg szeretnénk jeleníteni (pl. az adott szimbólum előtt megjelenik egy kis felirat, vagy egy H betű). Ez azáltal lehetséges, hogy minden változónak van egy Alarm változóreferenciája is, amelyben a rendszer az adott változóra érvényes alarm állapotokat gyűjti úgy, hogy az Alarm mező bitjeit az egyes csoportokkal rendeli össze. Ha a vészállapot pl. az 1-es csoport, akkor az Alarm mező 0-ik bitje fogja azt tartalmazni, a 2-es alarm állapotot (hiba) pedig az 1-es bit, stb. Ha most azt szeretnénk, hogy egy objektum a változó alarm állapotának függvényében jelenjen meg a képen (pl. egy „Hiba” felirat), akkor a láthatóság feltételeben a Valtozo.Alarm.0 kifejezést kell szerepeltetnünk. Ez felel meg majd a vészállapotnak. Ha azonban minden hiba számít, akkor elég ezt leírni:

6

Valtozo.Alarm Ugyanis a bool típusú kifejezések nem nullára vizsgáltak ( Valtozo.Alarm<>0 ).

3.1.1.2. Speciális alarm feltételek A speciális alarm feltételek közül, amelyek különféle függvények, valamint változók és változóreferenciák kiértékelésével keletkeznek, a change() függvényt érdemes külön is kiemelni. Előfordulhat ui., hogy egy alarm feltételeként egy változó megváltozását szeretnénk megadni. Ez különösen a többállapotú változók esetében lehet szükséges, mivel ezeknél többféle nem nulla állapot is lehetséges, márpedig a feltétel kiértékelése csak azt vizsgálja, hogy az oda begépelt kifejezés értéke nulla-e. Ezt a problémát küszöböli ki a change (változás) függvény, amelynek argumentumában bármilyen változó szerepeltethető. Például a Change(Valtozo) kifejezés, mint alarm feltétel, a Változo valamennyi változását naplózza. Többállapotú változó esetén ilyenkor a naplóban megjelenik az összes állapotváltozás (nyitva, zárva, hibás, távvezérelt, stb.).


125

3.1.1.3. Alarm eseménykiszolgáló Az eseménykiszolgáló az alarmok típusaihoz kapcsolódik. Külön kiszolgáló van az események bekövetkezésére, megszűnésére és nyugtázására. Megadásuk az Események fülnél lehetséges a tulajdonságszerkesztőn belül. Az esemény kiszolgáló általában arra jó, hogy megjegyezzük az egyes események bekövetkezését, képváltást idézzünk elő, vagy csupán egy hangjelzést. A legegyszerűbb esetben egy külön változóban jegyezzük meg, hogy egy adott esemény fennáll-e.

Esmény kiszolgáló varázsló elindítása

Az események egyedi kiszolgálása azonban nem mindig célszerű, hiszen akkor ugyanazt az esemény kiszolgálót kell mindenhová bemásolnunk, ami pedig a későbbi módosításokat nehezíti meg. Lehet persze az eseménykiszolgálóból eljárásokat is hívni, de még célszerűbb, ha az eseményeinket csoportokba rendezzük. Erre szolgál az alarm csoport objektum, amelyekhez az egyedi alarm objektumainkat (AL) a Kapcsolat tulajdonság csoporton belül, az Alarm csoport-hoz hozzáköthetjük (ld. bal oldalt alul). Törekedjünk arra, hogy az egyedi alarm objektumainknak ez a tulajdonság mezője már ki legyen akkor töltve, amikor az alarm objektumot lemásoljuk!

Egyedi alarm objektum összekapcsolása az alarm csoporttal

126


6

3.1.2. Alarm csoport Az alarm csoport objektum az egyedi alarmok közös eseménykiszolgálására és az alarm állapotok összesítésére szolgál. A tulajdonság szerkesztő Tulajdonságok fülénél nem is kell általában semmit beállítanunk, ugyanis az Összes alarm és az Új alarm tulajdonságokat már maga az objektum generálja, ahogy azt mindjárt el is magyarázzuk. Az események fülnél azonban magát a közös eseménykiszolgálást végezhetjük el, ami hasonló lista az egyedi alarmoknál megismerttel. A bekövetkezés esemény bármelyik, az adott csoporthoz tartozó egyedi alarm bekövetkezése esetén lefut, a megszűnés pedig azok megszűnésekor. Közös ágon intézhető el tehát az alarmok eseménykiszolgálása. A kiértékelés esemény azonban speciális. Ezt akkor hívja meg a rendszer, amikor a csoporthoz tartozó összes esemény kiértékelésével végzett. Nos, ekkor érvényesek az Összes alarm (AllAlarms) és az Új alarmok (NewAlarms) tulajdonságok, amelyeket magában a kiértékelő programban olvashatunk ki, dolgozhatunk fel. Például: SajatAlarmStatus=AllAlarms

‘ahol a SajatAlarmStatus egy globális változó

Az AllAlarms az összzes csoporthoz rendelt egyedi alarm összesített állapota, egy bájt, amelynek bitjei az egyes alarm csoportokat reprezentálják. Például abban az eseben, ha a csoport bármelyik objektumára vész esemény áll fenn, akkor az AllAlarms 0-ik bitje 1, ha hiba, akkor a 1-es is. Az AllAlarms-ból tehát azt tudhatjuk meg, hogy egy alarm csoportban generálisan milyen események vannak és a képeinken jelezhetjük azt – csoportokhoz rendelve. A NewAlarms annyiban különbözik az előzőtől, hogy benne mindig csak az adott kiértékelési ciklusban észlelt új alarmok jelennek meg. Ez az esemény generálta képre váltás esetén praktikus, hiszen a NewAlarms csak új hiba esetén nem 0, amikor is az alarm csoportnak megfelelő összesített alarmok vannak benne. Összességében az alarm csoport objektumaival kényelmesen elvégezhetők azok a közös feladatok, amelyeket az alarmrendszer működéséhez képzeltünk el: automatikus képre váltás, figyelmeztető ablak megjelenítése, új hiba esetén alarm objektum felrajzolása (pl. ugráló óra), majd arra kattintva az eseménynapló megjelenítése, hangjelzés, média ismételt lejátszása, duda jelzés a PLC felé, és még nagyon sok minden. Fontos alarm csoport tulajdonság az engedélyezés. Ezen keresztül ui. az alarm csoport összes egyedi alarm objektuma letiltható.


127

6

3.2. Alarm programok tulajdonságai Az alarm programok nemcsak objektumokból állnak, de vannak magának az alarm programnak is, mint önálló objektumnak, tulajdonságai. Ezeket a szerkesztőben akkor láthatjuk, ha az objektum “mellé” kattintunk (az a lényeg, hogy ne objektumot válasszunk ki). Ekkor jelennek meg az alarm tulajdonságok a tulajdonság-szerkesztőben: A legfontosabb tulajdonságok a következők: •

Az alarm program nevét lehetőleg ne, vagy csak nagyon körültekintően módosítsuk, mivel a név beépül az egyedi alarmok által generált üzenetek Tag-jébe (alr.al1). Így azok az alarm állapotok, amelyek a módosítást megelőzően keletkeztek az összesítő naplóban, soha nem törlődnek onnan. Az itt megadott név egyébként megegyezik az alarm fájl nevével is.

•

Az alarm programnak tetszőleges cím is adható, ami funkciójának azonosítását könnyíti meg.

•

A ciklusidő határozza meg, hogy az alarm program milyen gyakorisággal fut, vagyis e paraméter az alarm feltételek kiértékelésének a gyakoriságát szabályozza

•

Az ismételhetőséggel már az alarm program létrehozásakor is találkozhattunk, ezzel azt befolyásolhatjuk, hogy az alarm program ne induljon el több példányban a működő taszkrendszeren belül.

•

Végül a gyorsprocesszálás funckióra nagyszámú alarm objektumot tartalmazó rendszerben lehet szükségünk. Amennyiben ezt bekapcsoljuk, a rendszer csak azoknak az alarm objektumoknak a kiértékelését végzi majd el, amelyekhez tartozó változók bármelyike megváltozik. Ezzel nagyságrenddel gyorsabb rendszert kapunk, de az alarm programba kézzel begépelt programrészek ilyenkor nem futnak, hiszen az egész alarm program sem fut le egyben, csak az egyes objektumok. A gyorsprocesszálásra néhány ezer alarm objektum felett már szükség lehet, hacsak nem akarunk az alarm cikluson ritkítani. Ez fordítva is igaz: bekapcsolása esetén a ciklusidővel akár le is mehetünk egészen 10ms-ig. Lehet az alarm programoknak is inicializáló és a frissítés gyakoriságával kiértékelődő program ága. Ezeket az Események fülnél adhatjuk meg – célszerűen úgy, hogy az eseménykiszolgálót előtte kinagyítjuk. Erre szolgál a jobbra nyíl:

128


6

4. Eseménynapló Az eseménynapló egy speciális globális lista, amely a rendszer állapottörténetét dokumentálja. Az esemény tartalmazza a vonatkozó állapotváltozás bekövetkezésének (vagy megszűnésének) az időpontját, az állapotváltozás súlyosságát, vagy más szóval prioritását, valamint annak rövid leírását. Az alarmjelzés végén még egy kiegészítő szöveges információ is olvasható. Az eseménynaplóra láthatunk példát a következő ábrán. Csoport és típus

Információ

Dátum/idő Érték Jelzés oka

2006.04.12 2006.04.12 2006.04.12 2006.04.12

08:12:11 08:18:23 08:18:24 08:25:00

Hőmérséklet határ: túllépés Hőmérséklet határ: rendben Korlátozás bekapcsolva Új alapjel = 95 C

Hiba Hiba megszűnt Parancs

Az események diszken kerülnek eltárolásra egyetlen file-ban, ami alaphelyzetben Microsoft Access adatbázis. A file nevének dátumhoz kapcsolásával azonban elérhető, hogy pl. havonta új napló kezdődjön. A régi állományokat a naplókezelő legördülő menü Fájl almenüje alapján lehet visszaolvasni egyszerűen a kiválasztással, vagy a dátum begépelésével. Ugyanitt lehet az alarm fájlokat archiválni, törölni, stb. Az esemény bejegyzése a fent ismertetetteken kívül tartalmazza még a jelzést kiváltó alarm objektum (tag) és opcionálisan az alarm változó megnevezését is, ezt azonban a képernyőn a Nézet menü megfelelő beállításával elrejthetjük. Az esemény bekövetkezése nemcsak naplóbejegyzést eredményezhet, de kísérheti hangjelzés, külön üzenetablak, szirénahang vagy szintetizált emberi beszéd. További lehetőségként az események közvetlenül a nyomtatóra is átirányíthatók, bár a napló tetszés szerint később is kinyomtatható a kezelő által. Az egyes események az állapotlistán prioritásuktól függően eltérő színjelzést kapnak a sor elején található ikonban. A szín az alarm konfiguráció szerint készül az egyes fontossági csoportoknak megfelelően. Ugyanis a rendszerben az eseményeket csoportokba soroljuk. 8féle prioritási csoport lehetséges, a legfontosabbak: Alarmcsoportok

Csoport

Színkód

Megjelenítés módja

Vész Hiba Parancs Üzenet Analóg hiba Változás

Vörös Sárga Fehér Zöld Lila Kék

Színes négyszög Színes négyszög Színes négyszög Színes négyszög Színes négyszög Színes négyszög


129

6

Alarmtípusok

Típus

Megnevezés

Megjelenítés módja

Be Ki Elf

Bekövetkezik Teli négyszög Megszűnik Üres négyszög Nyugtázás Üres gyűrű

Mint látható, a csoportok az események fontosságát tükrözik, míg a típusok az esemény bekövetkezésének módja ill. elfogadása szerint változnak. Az csoportok és a típusok összesen 24-féle esemény megkülönböztetését teszik lehetővé. Az eseménynapló kezelésének legfőbb parancsait a következő pontokban ismertetjük.

4.1. Nyomtatás A leggyakrabban használt funkció az utolsó HH óra eseményeinek a kinyomtatása, mivel így időben szűkített naplót készíthetünk. Alapesetben ez az idő 12 órára van beállítva. Emellett adott poziciótól a file végéig, ill. a file elejétől az adott pozícióig is nyomtathatunk, vagy csak a képernyőn látható eseményeket. Az egyes parancsok a Nyomtat menün keresztül érhetők el. A nyomtatás itt is átirányítható PDF, HTML, vagy RTF (Word) fájlba.

6

4.2. Keresés Kereséssel adott szövegmintát tartalmazó sorra pozicionálhatunk az esemény naplóban. A keresés az aktuális pozíciótól indul és a lista végéig tart, vagy visszafelé, a lista elejéig – a keresés irányától függően. A megtalált listaelem a képernyőn látszik megkülönböztetett alapszínen. A keresés felhasználható pl. adott dátumú listabejegyzések megkeresésére. A fájl végén speciális hangjelzés keletkezik, ha a rendszer nem talál további mintákat és egy kisérő üzenet. Alternatívaként kereshetünk még prioritás és típus szerint is. Mindez a Keresés menü parancsai szerint történik.

4.3. Kiválasztás Lehetőség van arra is, hogy a naplót a legkülönfélébb szempontok alapján kiszelektáljuk. Így pl. kiválaszthatók a meghatározott prioritású (fontosságú) események, azok az események, amelyek meghatározott szövegmintát tartalmaznak vagy azok, amelyek az egyes eseményeknek csak a bekövetkezését mutatják. Természetesen mindez kombinációban is elkövethető. A kiválasztás lehetősége annál inkább fontos, mivel csak egyetlen alarm-file keletkezik. Tehát az összes jelzés, ritka állapotváltozások, vészálapotok, parancsok, stb. ugyanabba a file-ba kerülnek bejegyzésre. A különféle jelzések csoportok ill. típus szerinti kiválasztással szeparálhatók. Külön érdemes megemlíteni a kombinált szűrőt, amivel az összes kiválasztási opció egy ablakban állítható be (szövegrész, tag, érték, információ, csoport, típus):

130


Az egyes kiválasztási lehetőségeket a megfelelő Kiválasztás menü tartalmazza. Végül a kiválasztás elvégezhető interaktívan is, ami azt jelenti, hogy nem kell feltétlenül tudnunk, hogy mi a kiválasztandó esemény azonosítója (Tag), csoportja, típusa, stb., a következőképp is eljárhatunk: 1. Kiválasztjuk az alarm napló kívánt sorát dupla kattintással – erre megjelenik a jobb oldalt látható Alarm információs ablak: 2. Majd a felkínált ablakban kiválasztjuk azt az esemény napló elemet, amihez hasonló eseményeket keresünk (rádio gombok középen), és azokat az Összes ilyen kiválasztása gomb megnyomásával összeválogatjuk. 3. Az Összes esemény gomb megnyomásával visszakaphatjuk az eredeti listát, majd más elemet választva további szűréseket végezhetünk

6

Eközben a listában is mozoghatunk anélkül, hogy az interaktív szűrést becsuknánk. Erre szolgál a jobb-bal nyíl (léptetés). Az interaktív kereső emellett kiegészítő ingformációkat is képes megmutatni, ha az alkalmazásban ezt bekonfiguráltuk. Az alábbi példán az esemény (ajtó kinyitása) közelében egy perces kamerafelvételt játszik le a program nekünk: Ezt a “gombot” kell megnyomni

Az itt látható kamerakép valójában az alkalmazás egy megfelelően konstruált ablaka, amit a program a (+) gomb megnyomásakor dokkol a program az interaktív kiválasztás ablakába. Lehet tehát ez a kép adatbázis tábla, chart, szelektált trendkép, vagy bármi egyéb.

4.4. Események nyugtázása Az események nyugtázása a rendszerben igen egyszerűen elvégezhető. Erre a nyugtázatlan eseményeket tartalmazó osztott esemény-listát használjuk. Események kezelése (alarm rendszer)

131

4.4.1. Nyugtázás a nyugtázatlan események listájában 1. Válaszzuk ki a nyugtázatlan események táblát a rendszermenüből. Ezen az osztott táblán a nyugtázatlan események felül jelennek meg a sárga mezőben. 2. Keressük ki a táblázatból a nyugtázandó eseményt 3. Gépeljünk ENTER-t vagy duplán kattintsunk rá az egérrel a kijelölt sorra. Ezzel az esemény nyugtázását elvégeztük.

Nyugtázás dupla kattintással a lista sorain

6

A nyugtázott esemény bekerül a viszaigazolt események listájába és az eseménynaplóba, ami az osztott alarm táblán a tábla alsó felében mindjárt meg is figyelhető. A nyugtázott eseményt a speciális kör alakú ikon jelzi az esemény listában.

4.5. Eseménynapló törlése Az eseménynapló a Fájl menü megfelelő menüpontjával törölhető:

A törlés előtt a rendszer visszakérdez, de a törlés konfigurációtól függően kulcsszóhoz is köthető. A törlés mindig az aktuális alarm file-ra vonatkozik (a Fájl menüvel korábbi alarmok is visszaolvashatók).

132


6


133

Adatbázis kezelés SQL és táblázat kezelő rendszerek

Tartalomjegyzék: 1. Bevezetés............................................................................................................................ 135 2. Adatbázis kezelés elve ....................................................................................................... 135 3. SQL adatbázisok kezelése.................................................................................................. 136 3.1. Saját SQL parancsok ................................................................................................... 136 3.1.1. Saját SQL parancsok szintaktikája....................................................................... 137 3.1.2. Példák saját SQL parancsok alkalmazására ......................................................... 139 3.2. Általános SQL parancsok............................................................................................ 140 3.3. SQL rendszerváltozók ................................................................................................. 141 4. Nem SQL adatbázisok kezelése ......................................................................................... 142 4.1. Táblázat kezelő parancsok (FH).................................................................................. 142 4.2. File kezelő parancsok .................................................................................................. 144 4.3. Konvertáló parancsok.................................................................................................. 144 5. Adatbázisok és táblák konfigurálása .................................................................................. 146 5.1. Adatbázis kiválasztása és beállítása ............................................................................ 147 5.1.1. VISION adatbázis kezelők (dbVision)................................................................. 147 5.1.2. Microsoft adatbázis kezelők (dbOLE) ................................................................. 147 5.1.3. Borland adatbázis kezelők (dbBDE) .................................................................... 148 5.2. Táblák konfigurálása ................................................................................................... 149 5.3. Mezők megadása ......................................................................................................... 149 6. Adatbázis táblák megjelenítése .......................................................................................... 151 7. Adatbázis műveletek varázslóval ....................................................................................... 152 8. Adatbázis prototípusok....................................................................................................... 153


134

Adatbázis kezelés

7

1. Bevezetés A program lehetővé teszi az összes elterjedt adatbázis kezelő rendszerhez való csatlakozást: MS-SQL, Interbase, Informix, DB2, Oracle, dBase, Paradox, Foxbase, MS-Access, MSExcel, stb. Ezek egy része SQL, egy része pedig hagyományos, táblázat szerkezetű adatbázis. Azonban ez utóbbiakhoz is lehetséges SQL illesztőkön keresztül csatlakozni (pl. dBase-hez is). Az elterjedtséget is figyelembe véve ezért az univerzális SQL adatbázis kezelést preferáljuk. A program adatbázis kezelője háromféle rendszer kiszolgálására képes: • • •

VISION saját (natív) adatbázis kezelője (dBase, Adatgyűjtés, Trend) Microsoft OLE DB adatbázis kezelő (OLE DB v. ADO) Borland Database Engine alapú adatbázis kezelés (BDE)

Ezek a rendszerek tetszés szerinti kombinációban alkalmazhatók a későbbiekben bemutatott adatbázis kapcsolatfelvételi objektum megfelelő beállításával. A program saját adatbázis kezelő rendszere a dBase (III és IV) tipusú adatbázisok mellett az adatgyűjtéshez és a trendeléshez használt speciális adatbázis formátumokat támogatja még. A saját formátumra (SQL helyett) a relatív nagy adatmennyiség és sebességigény miatt van szükség. Ne felejtsük el, hogy a program történeti modulja képes miliszekundumos trendek készítésére is – akár 10ms-onként is képes az adatokat rögzíteni, s akár többszázat is egyszerre. Gyakorlatilag ugyanez mondható el az adatgyűjtésről is, ott is lehetséges többszáz, vagy akár többezer adatnak a másodperc léptékű tárolása. Mindez SQL alapokon nem volna lehetséges. Mivel azonban a program képes a különféle adatbázis kezelő rendszerek közötti konverzióra, így a trendek és az adatgyűjtés SQL adatbázisokba való átalakítására is. Ezért a szabványos adatbázisokba való átalakítás – különféle offline feldolgozások érdekében – a saját adatbázis kezelő rendszer alkalmazása esetén is megoldott. A konvertálás ilyenkor utólag, kezelői kérésre, vagy bizonyos időszakonként (pl. éjfélkor), automatikusan történhet. A gyors, saját atabázisok tehát egyfajta átmeneti tárként (cache) funkcionálhatnak.

2. Adatbázis kezelés elve A rendszer a különféle adatbázisokhoz való kapcsolódást adatbázis kezelő objektumok deklarásával és azok összekapcsolásával biztosítja. Ez három alapobjektum megadásával történik (adatbázis, tábla, mező), amelyek kapcsolatát szemlélteti a következő ábra: Adatbázis

Oszlopok= mezők/változók

Tábla 1

Mező 1

Mező 1

Változó 1

1

Mező 2

Változó 2

2

Mező 3

Változó 3

Mező 4

Változó 4

3 4

Mező 2

Mező 3 Mező 4

5 6

Tábla 2 Mező 1

Változó 1

Mező 2

Változó 2

Adatbázis kezelés

Adatbázis tábla

135

7

Az adatbázis magát az adatbázis kezelő rendszert írja le, illetve az adatbázis nevét határozza meg. Az egyes adatbázisokon belül táblák találhatók, amelyek oszlopait, mezőit kötjük össze az alkalmazás változóival. Az adatbázis kezelés úgy történik, hogy a VISION változóit – mint egy frame-et használva – vetítjük a táblázat soraira. Amikor pl. adatokat írunk az adatbázisba, először a változókat kell kitöltenünk (a külső eszközzel való kommunikáció, vagy különféle programozott számítások által, illetve beviteli objektumok kitöltésével), majd azokat beleírhatjuk a táblázat soraiba. Olvasáskor pedig az adatbázis egyes sorait olvassuk a megfelelő mezőkhöz rendelt változókba. Mindez két VISION programutasítással, SQL-lel, vagy FH-val történik, attól függően, hogy SQL alapú vagy hagyományos táblázat rendszerű adatbázisokról van szó. Az adatbázis kezelés ezért – alapfokon – rendkívül egyszerű, hiszen csupán a változókkal kell törődnünk, akárcsak a képi megjelenítés előkészítése során. Ha még ehhez azt is hozzávesszük, hogy az adatbázis kezelő rendszer ugyanannak a grafikus szerkesztőnek a felhasználásával készül, mint bármelyik kép, ahol az objektumok tulajdonságait a grafikus objektumokhoz hasonló tulajdonság-szerkesztővel állíthatjuk be, akkor az látszik, hogy a rendszer használata - az alapfogalmak megértésén túl - nem igényel további ismereteket.

3. SQL adatbázisok kezelése A VISION programból bármilyen szabványos SQL parancs kiadható SQl alapú adatbázisok kezelésére. Azonban annak érdekében, hogy a változók írása és olvasása egyszerű legyen, a VISION a legfontosabb műveletek elvégzésére saját SQL parancsokat használ. Először ezeket a saját parancsokat, majd a fejezet végén az általános SQL szintaktikát mutatjuk be.

3.1. Saját SQL parancsok A VISION saját SQL parancsai közül a legfontosabbak a következők (ugyanazok a parancsok, mint a táblázat kezelő FH parancs esetében): • • • • • •

Read (select) Write (update) Append (insert) Create (create) Delete (delete) Erase (drop)

- olvasás - írás - hozzáfűzés - tábla létrehozása - sor (rekord) törlése - tábla törlése

A zárójelben a megfelelő SQL parancsot tüntettük fel, aminek az adott VISION parancs megfelel. Hogy jobban érthető legyen, miért van szükség önálló parancsokra, s miért nem használjuk a zárójelben feltüntetett SQL-beli pandantját, nézzünk egy példát: Szabványos SQL parancs alkalmazásával a következőképpen lehet egy adatbázis táblázhoz adatokat fűzni: ”insert into Tadatok (datum, par1, par2) values (‘2005.06.27.’, 12.3, 4.5)” Tekintettel arra, hogy a values után felsorolt adatok változókból származnak, nem írhatjuk be őket az SQL parancsba szövegkonstansként. A kifejezést ezért szövegösszefűzéssel kell 136

Adatbázis kezelés

7

előállítani úgy, hogy a változók értéket az str() függvénnyel szöveggé konvertáljuk a kifejezésben (a szöveg tipusú változókat nem kell konvertálni): ”insert into Tadatok (datum, par1, par2) values (‘”+datum+”’,”+str(par1)+”,”+str(par2)+”)” Nagyszámú változó esetén ez bizony meglehetősen hosszú és áttekinthetetlen lesz, tele hibalehetőségekkel, hiszen ügyelnünk kell arra, hogy a mezőneveket ne rontsuk el, figyelnünk kell a sorrendre és az adatok tipusára is, mivel a szöveg tipusú adatokat (ld. Datum) szimpla idéző jelek között kell az SQL kifejezésben szerepeltetni. Ennek a bonyolult query-gyártásnak a feladatát veszi le vállunkról a Read, Write, Append, stb. VISION parancs. A program ui. a bekonfigurált mezőnevek és a mezőhöz rendelt VISION változók alapján összeállítja a megfelelő SQL parancsokat. Nézzük mindezt parancsonként külön-külön.

3.1.1. Saját SQL parancsok szintaktikája Az SQL parancs általános szintaktikája – saját SQL parancsokat használva – a következő: sql “.”,<parancs>{[,parameter lista]} ahol :

Adatbázis neve

:

Tábla neve

<parancs>:

Select, Read, Write, Create, Append, Recnum, Delete, Erase, ReadSelected, WriteSelected, DeleteSelected,Readsum,Readmax közül valamelyik

7

<paraméter lista>: Parancsfüggő paraméterek, pl. SQL where vagy order by kiegészítések Abban az esetben, ha a tábla neve menet közben változik (ez a helyzet pl. akkor, ha a tábla neve tartalmazza a dátumot és/vagy az időt), akkor az előre definált tábla név, mint valóságos táblanév nem használható többé, mivel az összes lehetséges név-kombinációt dőreség lenne felsorolni. Ehelyett az sql adatbázis táblájának fenti alapesetét finomítjuk: .| Ebben az esetben az és a prototipusként használt, vagyis csak arra szolgál, hogy definiálja az adatbázis szerkezetét, de a tábla neve lesz. ) Tipikus példa a változó táblanévvel operáló adatbázis kezelésre az az eset, amikor változó nevű dBase adatbázis fájlokat készítünk – például a dátumnak és az időnek a fájlnévben való szerepeltetésével. A dBase esetében ui. a táblanév nem más, mint maga a fájlnév (az adatbázis pedig az könyvtár). Az adatbázis hivatkozás ilyenkor valami ehhez hasonló kifejezés lesz: “DB.PROTOTABLE|”+filename+’.dbf”

‘ahol a filename = string tipusú változó

Adatbázis kezelés

137

Parancsok szintaktikája parancsonként: Tábla létrehozása: sql “.”,Create Sorok számának a megállapítása: sql “.”,Recnum{{,record}”,where…”} Eredményhalmaz előállítása: sql “.”,Select{”,where…”} Sorok olvasása: sql “.”,Read{{,record}”,where…”} Sorok írása: sql “.”,Write{,”where…”} Sorok törlése: sql “.”,Delete{,”where…”} Tábla törlése: sql “.”,Erase Új sor hozzáfűzése: sql “.”,Append Mező maximuma: sql “.”,Readmax,Variable ‘változónév = mezőnév Mező összegzése: sql “.”,Readsum,Variable Kiválasztott sor olvasása: sql “.”,ReadSelected Kiválasztott sor írása: sql “.”,WriteSelected Kiválasztott sor tölése: sql “.”,DeleteSelected A ReadSelected, WriteSelected és DeleteSelected parancsok a VX grafikus objektummal együtt használtak. Ilyenkor a táblázat éppen kiválasztott sorára vonatkozik az olvasás, írás, ill. a törlés - tehát e parancsok meglévő adatbázisok kényelmes, grafikus szerkesztésére használhatók. Látható, hogy a Recnum és a Read parancs után opcionálisan megadható még egy record változó is. Ez azonban a Recnum esetén output, vagyis felülíródik (ebbe a változóba kerül a sorok száma), Read esetén viszont input és arra szolgál, hogy a where által meghatározott eredményhalmazból megmondjuk, hogy melyik sorra vagyunk kíváncsiak. Abban az esetben pl. ha a Read parancsnál hiányzik a where feltételmegadás, a parancs az adott tábla összes sorát vizsgálja, amelyet ezek után a record változó révén tudunk soronként beolvasni. A Readmax és Readsum parancsok a szokásos SUM() és MAX() SQL függvények kiadását és kiértékelését végzik, eredményük a mezőnévvel kötelezően azonos Variable változóba kerül. Például: sql “ACCESS.Text”,Readmax,Recept_ID; ‘ahol Recept_ID a változó és a mező neve. Azonban az SQL adatbázis kezelő rendszerek esetén ez a megoldás nem preferált. Általános szabály, hogy az adattáblákat úgy kell előállítani, hogy annak legyen egyedi (azonosító jellegel) használt mezője. Az SQL adatbázis kezelő rendszerek az ilyen tipusú mezők automatikus előállítására támogatást is nyújtanak. A where megadásánál tehát egyértelműségre kell törekedni, és a record számláló nem kell: sql “.”,Read,”where ID=”+str(MyID) Ebben a példában az ID egy olyan mező, mely biztosítja a táblázat sorainak az egyértelmű azonosítását. Így kiolvasni is biztosan csak azt az egy sort fogjuk, ahol az ID mező értéke azonos a MyID változónk tartalmával (pl. adott azonosítóval rendelkező ügyfél adatainak a beolvasása), vagy egyet sem, ha az adott azonosító még nem szerepel a táblában. 138

Adatbázis kezelés

7

Az egyértelmű azonosítás a Write parancs alkalmazása esetén azonban már egyenesen szükséges is, hiszen abban az esetben, ha a where nem határozza meg egyértelműen a rekordot, az összes találati sort felül fogjuk írni. Például az sql “.”,Write parancs – where kiegészítés nélkül – az egész táblát töltené fel az adott mintával, annak minden egyes sorát! Lényegében ugyanez mondható el a Delete paranccsal összefüggésben is. A where kiegészítéssel kapcsolatban nem bocsájtkozunk további részletekbe, mivel az már az egyes adatbázis kezelő rendszerek területe. Általános használatát fent bemutattuk. A parancsok végén bármilyen SQL kiegészítés megadható a where feltételen kívül. A leggyakoribb ezek közül az order by (adott mező szerinti rendezés), de nagyon sok olyan kifejezés létezik, amelyekkel az SQL adatbázisok eredményhalmazait specifikálhatjuk. Javaslunk ezzel kapcsolatban egy SQL adatbázisokról szóló könyvet beszerezni.

3.1.2. Példák saját SQL parancsok alkalmazására Legyen az adatbázis neve DB, a tábla, amin dolgozunk legyen Recept, ennek azonosító mezője leften Recept_ID és legyen ugyanez a VISION változó neve is. Új recept hozzáfűzése az adatbázishoz:

sql “DB.Recept”,Append

Adott recept törlése:

sql “DB.Recept”,Delete, ”where Recept_ID=”+str(Recept_ID)

Adott Recept_ID-vel rendelkező record beolvasása:

7

sql “DB.Recept”,Read, ”where Recept_ID=”+str(Recept_ID) sql “DB.Recept”,Select

Adott Recept_ID-vel rendelkező record felülírása:

sql “DB.Recept”,Write, ”where Recept_ID=”+str(Recept_ID)

Recept_ID-k maximumának beolvasása:

sql “DB.Recept”,Readmax,Recept_ID

Összes recept törlése:

sql “DB.Recept”,Erase

Ezekben a példákban használtuk az str() függvényt, ami numerikus adat stringgé konvertálását végzi. Erre azért volt szükség, mert az SQL parancs harmadik argumentuma itt szöveges kell, hogy legyen, s ezért a megfelelő “where…” szövegrésszel összekatenáltuk a stringgé alakított Recept_ID-t. Amennyiben a Recept_ID például 13, a string futási időben így alakul: “where Recept_ID=13”. Vegyük észre azt is, hogy a Read parancs után kiadtunk még egy Select parancsot is. Ez azért szükséges, mert a Read valójában az adatok szelekálását végzi (belül Select parancs ez is) és ezért a táblát egy rekordra leszűri. Vagyis, amennyiben az adatokat egy VX tábla mutatja a képen, az a megfelelő Recept_ID-re fog szűkülni, a többi adat “eltűnik”. Mivel a Read parancs is a tábla aktuális eredményhalmazát módosítja, azt a halmazt, amiből a VX is dolgozik. A második paranccsal tehát a Read után visszaszelektáljuk a táblát.

Adatbázis kezelés

139

3.2. Általános SQL parancsok Az előző fejezetben bemutattuk a VISION program saját SQL támogató utasítasait. Nézzük ezek után az általánosakat: sql “.”,”<SQL parancs>”{[,SQL parancs i]} ahol <SQL parancs>: <SQL parancs i>:

általános SQL parancs általános SQL parancs további sorai

Vegyük észre, hogy az SQL parancs második (és többi) argumentuma most szöveg tipusú, szemben a saját SQL parancsokkal, amelyeknél itt még numerikus tipusú adat (parancs) szerepelt. A program ebből állapítja meg, hogy általános, vagy saját SQL parancsról van-e szó. Az opcionális sorok, ill. argumentumok arra szolgálnak, hogy a hosszú SQL parancsokat – márpedig az SQL parancsok tipikusan ilyenek – több argumentumra, ill. több sorra bontva lehessen megadni. A teljes SQL parancs, amit a rendszer kiad, az összes SQL parancsból, mint részből áll egyetlen SQL paranccsá össze. Például: sql "DB", "update Oras set TejporgozQ="+str(A044I)+”,”, "TejporgozP="+str(A045I)+”,”, "where Datum='"+DATUM+"'" Ügyelnünk kell a szintaktikára, tehát például arra, hogy a felsorolás (a vesszők) az eredmény SQL parancson belül is meglegyenek (”,”). Továbbá az SQL parancson belül szövegként megadott argumentumok szimpla idézőjelek között kell hogy szerepeljenek. Ilyen például a DATUM, mivel azt feltételeztük, hogy az varchar típusú SQL mező. Amikor a rendszer kiértékeli a harmadik sort, a következő string keletkezik: where Datum=’2007.06.12’ Ennek szimpla idézőjelekben látható „belseje” származik csupán a DATUM változóból. Vegyük észre, hogy az SQL parancs több string argumentumból is állhat, amiket a rendszer egyetlen SQL paranccsá katenál össze. Bármilyen hosszú SQL parancs kiadható tehát, amennyiben azt több sorra és argumentumra bontjuk (mint a fenti példában, ahol három argumentum adta meg a teljes SQL parancsot). Egyébként egy argumentum hossza legfeljebb 255 karakter lehet! Az SQL parancsok felbontása több argumentumra tehát nemcsak azért szükséges, hogy áttekinthető legyen, másképp hosszú SQL parancsokat nem is tudunk bevinni.

140

Adatbázis kezelés

7

3.3. SQL rendszerváltozók Az SQL rendszerváltozók arra szolgálnak, hogy az SQL kezelő program hibakezelését a programból megváltoztassuk, ill. az egyes SQL parancsok eredményét lekérdezzük. A rendszerváltozók a következők: ShowSQLError: FileError:

Ha ennek értéke true (ez a default érték), a hibás SQL parancsok hibatáblát eredményeznek, ha false, akkor a hibatábla nem jelenik meg. Értéke 0, ha a művelet sikeres, egyébként a hiba kódját tartalmazza

Az SQL rendszerváltozók megfelelő használatával azt érhetjük el, hogy a már kialakított és letesztelt rendszerünk ne küldjön hibatáblát a képernyőre abban az esetben, ha egy SQL adatbázis műveleti hiba mégis bekövetkezik, mert a kezelő azzal valószínűleg nem tud mit kezdeni. Ehelyett a FileError függvényt használva megállapíthatjuk, hogy a művelet sikeres volt-e, majd lenaplózhatjuk, ill. a hiba kijavításáról saját Overdraw kép kirajzolásával, vagy más módon, pl. SMS-t küldve intézkedhetünk. Tipukus példa az SQL hibaüzenet elfedésére a create parancs. Előfordulhat, hogy egy programban dinamikusan hozunk létre táblákat, viszont nem szeretnénk azt tesztelni, hogy az adott táblá létezik-e, mielőtt kiadjuk a create parancsot. Ezt a következőképpen érhetjük el: ShowSQLError=false Sql “data.tabla”,Create ShowSQLError=true

‘hibakiiratás tiltása ‘create ‘hibakiiratás engedélyezése

7

Az alkalmazás-fejlesztés során az SQL táblák hiba-kiiratása rendkívül hasznos, mivel ebből állapíthatjuk meg, hogy milyen hibát vétettünk az SQL parancs összeállítása során. Jobb oldalt az SQL hibatábla látszik: A hibatábla amúgy 30 mp múlva automatikusan eltűnik a képről, ezért, amennyiben a hibás SQL parancsot vizsgálni kívánjuk, a hibatábla tartalmát vágólapra kell mentenünk (kijelölés, majd Ctrl-C).

Adatbázis kezelés

141

4. Nem SQL adatbázisok kezelése Mint a bevezetőben említettük, a program saját natív adatbázis kezelő motorral szolgálja ki a a hisztorikus adattárolást, ami a trendek és az adatgyűjtés esetén szükséges. Ezek nem SQL adatbázisok, hanem speciális adatbázisok, amelyek azonban éppúgy átkonvertálhatók SQL adatbázisokba. A trenden és az adatgyűjtésen kívül azonban van még egy adatbázis típus, amit a program ugyanezen az elven támogat: a dBase. Azt hozzátéve, hogy a dBase kezelése persze SQL alapokon is lehetséges, hiszen úgy a Microsoft, mint a Borland is támogatja ezt az adatbázis típust, sőt ODBC driverek is készültek hozzá. A saját natív driver használata most is a sebességigény miatt lehet szükséges. Végeredményben a nagy sebességigényű adatbázisok kiszolgálása táblázat kezelőkkel történik.

4.1. Táblázat kezelő parancsok (FH) A táblázat kezelés parancsa az FH (File Handling). Elnevezését onnan kapta, hogy ez a parancs – mint azt később látni fogjuk – nemcsak táblázat kezelésre alkalmas, de mindenféle fájlművelet elvégzésére is (fájlmásolás, átnevezés, keresés könyvtárban, stb.). Mint táblázat kezelő parancs, szintaktikája a következő: FH “.”,<parancs>{[,parameter lista]} ahol :

Adatbázis neve

:

Tábla neve

<parancs>:

Read, Write, Create, Append, Recnum, Delete, Erase, Select, Search közül valamelyik

<paraméter lista>: Parancsfüggő paraméterek Az adatbázist most is ugyanaz a mechanizmus írja le, mint az SQL parancsok esetében: .. A táblázat azonban gyakran jelent konkrét fálnevet, például DATA.DBF-et. Vagyis az adatbázis specifikációja lehet akár DB.DATA.DBF. (az első tag az adabázis, a második a tábla). Vegyük észre, hogy az FH egyebekben is kísértetiesen hasonlít az saját SQL parancsokhoz. Ez nem véletlen, hiszen valójában ugyanazokat a műveleteket kell most is elvégezni – néhány apró különbséget leszámítva. Ezen “apró” különbségek közül a “where…” feltételrész elmaradása a legszembetűnőbb, mivel itt mindig egy táblázat soraira hivatkozunk. A Read-nél és a Write-nál is szükséges tehát a rekord megadása – ezzel azonosítjuk a rekordot –, ahelyett, hogy a célrekordot meghatározó más feltételt fogalmaznánk meg, mint történt ez az SQL parancsok esetében (where Recept_ID=13). Egyebekben az SQL és a táblázat kezelő rendszer azonos.

142

Adatbázis kezelés

7

A saját táblázat kezelő parancsokat foglalja össze a következő táblázat: Tábla létrehozása: fh “.”,Create Sorok számának a megállapítása: fh “.”,Recnum, Táblázat szűrése, szelektálása: fh “.”,Select,, {,[]} Keresés adott feltételre: fh “.”,Search,,{,[]} Sor olvasása: fh “.”,Read, Sor írása: fh “.”,Write, Sor törlése: fh “.”,Delete, Törölt sorok megszűntetése: fh “.”,Pack Fájl törlése: fh “.”,Erase Új sor hozzáfűzése: fh “.”,Append{,} Rendezés: fh “.”,Sort,”<mezőnév>{,<mezőnév>} ahol :

Numerikus VISION változó

:

Változókból és függvényekből felépített bool eredményű kifejezés

<mezőnév>: Bármelyik mező, amelyikre sorrendezni kívánunk A record változót vagy előre be kell állítani – ez határozza meg, hogy melyik sort akarjuk a olvasni / írni / törölni a táblázatból –, vagy felülíródik a parancs hatására. Ez utóbbi történik az Append opcionális harmadik argumentumaként (ilyenkor a program azt adja vissza, hogy az új sor hozzáfűzése után mennyi sor van a táblázatban), a Serarch-nél, a Select és a Recnum parancs esetén (rekordok számának a lekérdezése). A Select (kiválasztás) és a Search (keresés) érdemel a fentiek közül külön figyelmet. Ezek a parancsok ugyanis sokkal kényelmesebben fogalmazhatók meg táblázat kezelés (FH) esetén, mint az SQL parancsoknál, mivel nem kell stringgé konvertálni a feltétel részt. Következésképp VISION kifejezés-szintaktikát alkalmazhatunk bennük. Például:

fh “DB.Recept.DBF”,Select,0, Recept_ID=13 fh “DB.Recept.DBF”,Select,0, Packtime(Datum)>Packtime(“2007.06.01”)

Ez utóbbi példát érdemes kivesézni. Először is itt a record változó helyére 0-át írtunk, ezzel ignoráljuk a record kezelését – egyébként a program a kiválasztott rekordok számát adná vissza benne. Ebben a példában a Datum egy VISION stringváltozó és ugyanez a neve a recept adatbázis valamelyik string típusú mezőjének is. A parancs úgy szűri le az adatbázist, hogy soronként beolvassa azt, majd a harmadik argumentum szerinti feltételrészt végrehajtva megvizsgálja, hogy a datum mező aktuális tartalma a packtime() függvénnyel egész számmá alakítva (a packtime a 2000 óta eltelt másodpercek számát adja vissza) nagyobb-e, mint a 2007.06.01 dátumnak megfelelő érték, vagyis az adat későbbi-e ennél az időpontnál. Ez utóbbi kifezésben is szerelhet persze változó, sőt más függvény is (Currentpacktime, Datetime, Date, Time, stb.). Lehet a parancsnak több feltétel argumentuma is – ezek ÉS apcsolatát értékeli ki. A Select eredménye egy Selected(“.”) adatbázis, ami dBase esetén egy DBS kiterjesztésű fájl. Minden esetben édemes azonban a Selected() függvényt használni: Selected(“DB.Recept.DBF”).

Adatbázis kezelés

143

7

Ugyanez a működési elve a Search parancsnak. Ebben az esetben nem szűri az adatbázist a program, csupán keres benne, és a record változóban visszaadja a megtalált record sorszámát. Hiba esetén a FileError rendszerváltozó jelzi, hogy nincs találat és nincs szűrés (ha 0, nincs hiba).

4.2. File kezelő parancsok Mint emlitettük, az FH nemcsak táblázat kezelésre alkalmas, de fájl kezelésre is. Ezeket foglaljuk össze az alábbi táblázatban: File másolása: File átnevezése: Könyvtár létrehozása: Könyvtár tölése: Keresés könyvtárban: Következő fájl keresése: Hozzáadás egy ZIP-hez: Kibontás ZIP-ből: Törlés ZIP-ből:

fh “”,Copy,”” fh “<átnevezendőfájl>”,Rename,”<újnév>” fh “”,Makedir fh “”,Deldir fh “”,FindFist,”<scan-név>”,” fh “”,FindNext,” fh “”,ZipAdd,”” fh “”,ZipExtract,”” fh “”,ZipDelete,””

ahol ,: bármilyen fájl :

eredmény fájl (ebbe íródik az eredmény - blank, ha nem talált)

:

egy ZIP tömörítésű fájl

4.3. Konvertáló parancsok Sok szó eset arról, hogy a saját, gyors adatbázisokat SQL adatbázisokká alakíthatjuk, vagy más formátumú táblázatokká. Ezeket a lehetőségeket foglalja össze a következő táblázat: Időbeli szűrés: Konvertálás:

fh “.”,Timefilter,,, fh “.”,DataConvert,

ahol :

időszűrés kezdete

:

időszűrés vége

:

idószűrésnél használt időlépték másodpercben, mely a táblázat sorainak időbeli távolságát fogja meghatározni

:

Fájlnév vagy . szerkezetű adatbázis tábla. Amennyiben fájlnevet adunk itt meg, a fájl kiterjesztéséből próbálja megállapítani a program, hogy milyen konvertálást kell végrehajtania.

E parancsok egymással, sőt a Summary és az Append parancsokkal is kombinálhatók. Ezeket példákon keresztül mutatjuk be.

144

Adatbázis kezelés

7

Példák adatbázisok konvertálására: Tegyük fel, hogy az ACQ az adatgyűjtés adatbázisának a neve (tehát az egyik natív VISION adatbázisé) és abban az adagytűjtés táblája Uzemorak, valamint létezik egy SQL adatbázisunk is, aminek a neve DB és azon belül egy tábla az UZEM: Konvertálás dBase-be:

fh “ACQ.Uzemorak”, ConvertData,”D.DBF”

Konvertálás Excel-be:

fh “ACQ.Uzemorak”, ConvertData,”X.XLS”

Konvertálás SQL-be:

fh “ACQ.Uzemorak”, ConvertData,”DB.UZEM”

Konvertálás SQL-be összesítő résszel:

fh “ACQ.Uzemorak”, ConvertData +Summary,”DB.UZEM”

Konvertálás SQL-be a hiányzó minták hozzáadásával:

fh “ACQ.Uzemorak”, ConvertData +Append,”DB.UZEM”

Külön is kiemeljük ez utóbb parancs jelentősségét, hiszen éppen ez valósítja meg az adatgyűjtés saját, nagysebességű adatbázisának bevezetőben már említett átkonvertálását SQL-be úgy, hogy abba mindig csak hiányzó sorokat másol, tehát akár ciklikusan is kiadható. Ráadásul a fenti parancsok a Timefileter-rel is kombinálhatók, így végül egyetlen paranccsal lehet leszűrni a forrás adatbázist, majd átkonvertálni azt pl. Excel-be. Ilyenkor először a timefiler argumentumait kell leírni, majd a célfájlt.

7

fh “ACQ.Uzemorak”,TimeFiler+ConvertData,from,too,3600,”D.DBF” ahol from,too:

Packtime típusú VISION változók az időtartomány kezdetére és végére (a konvertálás időléptéke pedig 1 óra)

A fentieken kívül az FH-val lehet még adatokat olvasni adatgyűjtésből trendbe (ReadTrend), valamint kérhető segítségével ezen adatokról statisztika is (ReadTrendStat), de ezeket a specialitásokat a dokumentáció adatgyűjtésről szóló fejezetében ismertetjük. Jelen összeállításunkkal az adatbázisok világához kapcsolódó FH parancsokat kívántuk összefoglalni, arról áttekintést adni.

Hogy jön azonban létre az a bizonyos . specifikáció, amire annyi helyen hivatkoztunk már? Nézzük meg hát az adatbázisok konfigurálását!

Adatbázis kezelés

145

5. Adatbázisok és táblák konfigurálása Az adatbázisok és táblák konfigurálása ugyanazzal a grafikus szerkesztővel történik, mint a képek rajzolása, vagy akár a kommunikáció beállítása. A grafikus szerkesztő kezelésével ebben a fejezetben nem foglalkozunk, csak az egyes objektumok tulajdonságaival és azok beállításával. Annak érdekében, hogy az adatbázisokat be tudjuk konfigurálni, először egy adatbázis taszk (leíró) előállítására van szükség. Amennyiben az alkalmazást default alkalmazásként hoztuk létre (a default alkalmazás tartalmaz egy üres fájlrendszert), egy adatbázis taszkunk már van; ha üres alkalmazásként, akkor a taszkot először le kell gyártanunk a projektmenedzser Adatbázisok sorára jobb egérgombbal kattintva, majd onnan Új adatbázis leíró-t választva: Ide kattintva specifikálhatjuk az új adatbázis leírót

7 Ugyanez az eljárás akkor is, ha a meglévőeket új adatbázissal szeretnénk bővíteni. A bővítésnek semmilyen technikai korlátja nincs, annyi adatbázis taszkot hozhatunk létre, ammennyit a feladat megkíván. Ha megnyitjuk, az adatbázis leíró már a konkrét konfigurációt tartalmazza, grafikusan azt mutatja:

Adatbázis

Tábla

Mezők

146

Adatbázis kezelés

A grafikus szerkesztő kiválóan dokumentálja az adatbázisok és táblák konfigurációját, hiszen a teljes tervezői nézetet megjelenítni. Szerkesztési állapotba kerülve pedig az egyes objektumokra kattintva tudjuk azokat állítani a tulajdonság-szerkesztő által, de lehet másolni, törölni, vagy új objektumokat bevinni – mintha csak képet rajzonlánk. Csupán annyi a különbség, hogy most az objektumoknak egy egész más halmazával kell dolgoznunk, mint a grafikus képek esetében: Négyféle objektum áll a rendelkezésünkre: • • • •

Adatbázis Tábla Mező SQL Query

5.1. Adatbázis kiválasztása és beállítása Első lépésként elhelyezünk egy adatbázis objektumot a szerkesztő ablakban, majd kiválasztjuk és beállítjuk a tulajdonságait:

7

A tulajdonságok közül először az Adatbázis tipusa-t kell beállítanunk, mivel a további lépések ettől függenek. Itt háromféle lehetőség közül választhatunk: • • •

dbVision (VISION saját adatbázis kezelői) dbOLE (Microsoft adatbázis kezelők) dbBDE (Borland adatbázis kezelők)

5.1.1. VISION adatbázis kezelők (dbVision) A program a dBase formátumú adatbázisok, a trendek és az adatgyűjtés adatbázisainak a kezelésére kínál megoldásokat. Kiválasztása után a driverek-nél csak a VISION-t választhatjuk.

5.1.2. Microsoft adatbázis kezelők (dbOLE) Ebben az esetben a Microsoft MDAC adatbázis kezelő komponensét használjuk, amelynek MSSQL és MSAccess providerét maga a VISION is feltelepíti. Szükség estén azonban a legfrissebb programok a Microsoft honlapjáról ingyen letölthetők (pl. 2.7-es változat), a VISION program azokkal is tökéletesen működik.

Adatbázis kezelés

147

Microsoft OLE DB adabázisok esetén a beállítás a ‘Kapcsolat’ (connection string) tulajdonsággal történik. Ha a sor bal oldali gombjára kattuntunk, az op. rendszer adatbázis konfiguráló képe jelenik meg. Itt választhatjuk ki a megfelelő ún. provider-t. A beállítás további lépései attól függnek, hogy milyen adatbázis kezelőt választottunk. Talán annyit érdemes megjegyezni, hogy az MS-Access adatbázisokat a Microsoft Jet adatbázis kezelők illesztik és az ODBC drivereket pedig lehetőség szerint kerüljük. Az ODBC driverek egyébként egy DSN felvételét is szükségessé teszik, amit az op. rendszer konfigurációs lapján, az ‘Felügyeleti eszközök’ között találunk. A beállító panelt érdemes tesztelés után bezárni.

5.1.3. Borland adatbázis kezelők (dbBDE) A Borland saját adatbázis kezelői a BDE (Borland Database Engine) modulra épülnek. Ezt a programot azonban a VISION nem telepíti fel automatikusan – ugyanabból a megfontolásból, amiért az MDAC legújabb változatát sem. Előfordulhat ui., hogy a számítógépen már telepítve van annak valamelyik korábbi verziója, amit egy VISION-től független program használ, és nem biztos, hogy az képes futni ezen programok legújabb, VISION által telepített változatával. Ugyanakkor a VISION-nek mindegy! Abban az esetben, ha a BDE még nincs telepítve, a VISION CD-ről, a VisDB könnyvtárból azt megtehetjük. A telepítés eredményeként megjelenik a konfigurációs panelen belül a BDE Administrator itt látható ikonja: A továbbiakban többféle lehetőség közül is választhatunk. Talán az a legjobb, ha magának a BDE adminisztrátornak a segítségével hozzuk létre az adatbázisunkat, mivel a program sokféle paraméter-beállítást és tesztelést is biztosít számunkra – hasonlóan az előző pontban bemutatott Microsoft rendszerhez. A BDE Administrator által előállított adatbázisok – az ODBC DSN mintájára – ún. alias-t, álnevet kapnak, amit a rendszer valamennyi programja ugyanezen a néven “lát”. Maga az álnév megjelenik persze a VISION-ben is.

148

Adatbázis kezelés

7

Az előző oldalon látható ‘Pelda’ és ‘Geza‘ ilyen adminisztrátorban létrehozott álnevek. Annak sincs semmi akadálya, hogy a BDE helyett magában a VISION-ben hozzuk létre a szükséges új (lokális) adatbázist a Driver, a Path, a Szerver, a Felhasználó és a Kulcsszó megfelelő beállításával. Ezek ugyanazok az adatok, amelyeket a BDE-ben is meg kell adnunk. Talán érdemes megemlíteni, hogy az Interbase alapú adatbázisokat a SYSBDA felhasználóval és a masterkey kulcsszóval érjük el. A Path beállítására pedig az adatbázis fájl helyének a meghatározása miatt van szükség. A BDE egyébként ugyanúgy támogatja az Access-t és az Excel-t is, de számos, Microsoft által nem támogatott adatbázis kezelőt, így az Interbase-t, az Informix-ot és az IBM DB2-t. Végezetül egyetlen feladatunk maradt csupán: az adatbázis nevének és leírásának a meghatározása. Ne hagyjuk a programot Noname adatbázissal dolgozni!

5.2. Táblák konfigurálása Az előző fejezetben bemutatott adatbázisokhoz táblákat rendelhetünk.Ennek első lépéseként felrajzolunk egy táblát, majd a Kapcsolat tulajdonságcsoporton belül hozzákötjük az adatbázishoz. Ettől kezdve a táblánk „látja” az adatbázis meglévő tábláit, tehát a Táblanév meghatározásakor választhatunk a legördülő listából. Persze akár új táblaneveket is megadhatunk, annak nevét egyszerűen be kell gépelni a Táblanév tulajdonság sorába.

5.3. Mezők megadása Ez az utolsó fázisa az adatbázisok konfigurálásának. Lényegében ugyanazt az eljárást ismételjük meg, amit a táblák kapcsán elmondtunk, azzal a különbséggel, hogy a mezőket nem az adatbázishoz, hanem a táblához kötjük – ugyanúgy a Kapcsolat tulajdonság-csoporton keresztül. Abban az esetben, ha a meglévő táblák közül választottunk, a mezőnév megadásánál csak a meglévő mezőnevek közül választhatunk. Új mezőneveket csak új tábla létrehozásával (ill. az ALTER TABLE parancs kiadásával) generálhatunk. Meglévő mezőnevek közül választva persze a mező tulajdonságai (adattipus és hossz) is automatikusan adódnak. Új mezőnevek esetén pedig célszerű mindjárt a változó kiválasztásával kezdeni, mivel ilyenkor a mező tulajdonságait a program a változó tipusából származtatja. De attól a mező tipusa még átírható, (választhatunk pl. integer-t float helyett), a program pedig az itt megadott tipusnak megfelelően fogja azt kezelni (pl. a float egész részét tárolva az integer mezőben),

Adatbázis kezelés

149

7

Akárhogyan specifikáltuk is, a mezőneveket végül a VISION változókkal is össze kell rendelnünk, ahogy a fejezet elején látható ábra mutatja. A VISION változókat pirossal jeleníti meg a program. Mindezektől teljesen függetlenül állítható a VX-szel megjelenített adatbázis táblákon az oszlopok felirata. Nem biztos, hogy a változónév, vagy az ékezetes karaktereket nem tartalmazó mezőnév a legmegfelelőbb oszlopnév. Arról nem is beszélve, hogy az még nyelvfüggő is lehet. Ezért az ‘Oszlop’ tulajdonságot is érdemes kitölteni: Megjelenített oszlop feliratának beállítása

Megjelenített oszlop szélessége = Oszlopszélesség * ‘e’ betű szélessége

VX táblánk fejlécében az itt beállított szövegek fognak megjelenni:

7 Saját oszlop feliratok

A tábla egyes oszlopainak a szélességét alaphelyzetben a következő algoritmus állitja be: Az adott oszlopból - annak fejlécét és összes celláját beleértve - a program kiválasztja a legszélesebbet és annak szélességét beszorozza az ‘e’ betű szélességével. Ez lesz az oszlop szélessége. Az algoritmusból következik, hogy a legszélesebb cella lehet valójában hosszabb és rövidebb is, mint amit a program kiszámított – hiszen a ‘W’, ‘M’ és ált. a nagybetűk jóval szélesebbek, mint az ‘e‘, az ‘i’, ‘l’, stb. pedig jóval rövidebbek. A cellatartalom néha nem fér bele a cellába. Cserébe az algoritmus nagyon gyors (nagyságrendekkel gyorsabb, mintha az egyes cellák szélességét pixel pontossággal számítanánk ki) és adaptív (a mindenkori cellatartalomhoz igazított). Könnyedén megoldható ugyanakkor az is, hogy a cellák szélességét hosszabbra, vagy rövidebbre válasszuk a program által kiszámítottnál. Ezt egyszerűen a mező Oszlopszélesség (ColumnWidth) tulajdonságának a beállításával érhetjük el. Ha ez a tulajdonság nem 0, a prgoram nem keresi többé a cellák leghosszabbikát, hanem az általunk megadott értéket használja – úgy, hogy ettől kezdve az itt megadott értéket szorozza be az ‘e‘ betű szélességével. A betűmértet változtatása tehát továbbra sem gond, a cellaszélesség mégis szabadon állítható.

150

Adatbázis kezelés

6. Adatbázis táblák megjelenítése A megjelenítés alavetően kétféle onjektummal történhet: VX DG

- Tábla néző (soronkénti kiválasztás) - Tábla szerkesztő (cellánkénti kiválasztás)

Tulajdonképpen mindkét objektum ugyanúgy a tábla tartalmát mutatja, csak ez utóbbi objektummal a táblát még szerkeszthetjük is – persze csak akkor, ha engedélyeztük. Az adabázis rács (Database Grid) azonban jóval gyorsabb is, mint a VX, mivel ún. kurzorként funkcionál. Vagyis mindig csak a képernyőn látható adatokat olvassa be az sql szerverből, és azokat mutatja meg. Legfeljebb néhány tucat sort – legyen bár a táblának egyébként több ezer sora – s ahogy az ablakot görgetjük, úgy olvassa be a továbbiakat. Ezzel szemben a VX az összes sor beolvasásával inicializálódik, ezáltal viszont jóval gyorsabban görgethető. A következő két kép az adatbázisok két fajtáját szemlélteti ugyanarra a táblára: DG:

7

VX:

A VX táblát használjuk a jelentéseken is, ha szerkesztett táblázatokat szeretnénk nyomtatni. A jelentésekben a táblát a rendszer automatikusan a nyomtatóra formázza és annyi oldalra elosztva nyomtatja ki, amennyi csak szükséges. Ugyanez DG-vel nem lehetséges.

Adatbázis kezelés

151

7. Adatbázis műveletek varázslóval Miután létrehoztuk az adatbázisainkat, hozzáláthatunk a bevezetőben említett SQL és táblázat kezelő FH parancsok kidolgozásához. Például szükségünk lehet arra, hogy a VX tábla valamelyik sorára kattintva kiolvassuk onnan az adatokat. Ez az sql .,ReadSelected parancs kiadását igényli, amint azt korábban megmutattuk. Azonban ezt a parancsot nem kell begépelnünk a VX kattintás eseményéhez, mivel a varázslóval is bevihetjük: A 19-es utasítás modellt választva a varázslóból a szükséges SQL parancs egyszerűen kiválasztható. Külön

Mezőnevek a feltételrészhez

7

az előre definiált SQL parancsok és az általános SQL parancsok. Még egy kis query-builder is van itt az adott táblázathoz tartozó mezőnevekkel, hogy azokat se kelljen begépelni. A feltétel részt idézőjelek között kell megadni, vagyis mint egy string kifejezést. Hiszen általában változóneveket is szerepeltetni kell bennük (pl. "where Datum='"+DATUM+"'"). A varázsló Fájlnév mezője igényel egyedül magyarázatot. Elképzelhető ugyanis, hogy a táblának, ill. az adatbázis fájlnak valójában nem az a neve, amit az Adatbázis táblák-nál kivásztottunk, mivel ezek előre definiált nevek, nem tudnánk thát változó adatbázis táblákat és neveket kezelni. Ezért a rendszer által definiált adatbázisoktól, mint struktúráktól meg kell különböztetni a tényleges, változó táblaneveket. Ez adható meg a Fájlnév helyén. Ha begépelünk ide egy nevet, pl. ”FILE”-t, a következőképp módosul az SQL parancs: sql "ACCESS.AnalogVariables|FILE", ReadSelected

152

Adatbázis kezelés

A deklarált és a valódi neveket tehát egy függőleges vonal választja el egymástól és az a jelentése, hogy a FILE nevű táblát kell kezelni úgy, ahogy az AnalogVariables táblában le lett írva. A FILE változó név, az AnalogVariables fix név. A vonal előtti részt ezért nevezzük ilyenkor prototípusnak. Fontossága miatt ezt a megadást külön fejezetben ismertetjük.

8. Adatbázis prototípusok Az adatbázis prototípus az adatbázis struktúráját rögzíti, mint egy típusmegadás, de nem jelent valódi táblát. A teljes adatbázis hivatkozás felépítése – protípus alkalmazásával – a következő: .<prototípus>| Az eddigi példákban bemutatott „DB.Recept” adatbázis akár így is megadható lenne: „DB.Recept|Recept”. De ebben az esetben a Recept már prototípus név és amennyiben a függőleges vonal után más string-et írunk, nem Recept-et, a rendszer már azt a táblát (fájlt) kezeli. Létrehozhatunk például két különböző nevű, de azonos struktúrájú táblát, ami egyaránt a Recept-nél deklarált struktúrát használja: sql ”DB.Recept|Recept1”,Create sql ”DB.Recept|Recept2”,Create Ennek az elvnek persze akkor van igazán értelme, ha a függőleges vonal utáni részt változóból származtatjuk: sql ”DB.Recept|”+ReceptName,Create ahol a ReceptName egy string típusú változó, a létrehozott tábla neve pedig a benne foglalt (változó) tartalom. A következő példa azt szemlélteti, hogyan lehet adatokat gyűjteni a rendszerrel úgy, hogy az adabtázis tábla (dBase fájl) neve az évet és a hónapot tartalmazza, tehát havonta változzon: fh ”DBASE.DATA|D”+Year+”_”str(Month)+”.DBF”,Append A DBASE itt az adatbázis neve, a DATA pedig egy dBase adatbázis prototípus tábla. A tényleges adatbázis fájl neve azonban D2007_5.DBF májusban, D2007_6.DBF júniusban, stb. Ezen a példán jól látható, miért van szükség prototípus deklarációra, hiszen a táblákat eleve képtelenség és értelmetlen is lenne előre száz évre hónapokra bontva megadni.

Adatbázis kezelés

153

7

Adatgyűjtés a VISION beépített adatbázis kezelőjével

Tartalomjegyzék: 1. Bevezetés............................................................................................................................ 155 1.2. Az adattárolás elve ...................................................................................................... 156 2. Tárolt adatok lekérdezése................................................................................................... 158 2.1. Adatok kiválasztása..................................................................................................... 159 2.2. Válogatások, táblázatok .............................................................................................. 160 2.3. Grafikon rajzolása ....................................................................................................... 161 2.4. Pásztázás...................................................................................................................... 162 2.5. Eloszlás diagram ......................................................................................................... 163 2.6. Adatok lekérdezése ..................................................................................................... 163 2.7. Adatok konvertálása.................................................................................................... 163 2.8. Regisztrátumok készítése ............................................................................................ 164 2.9. Archiválás.................................................................................................................... 164 2.10. Legördülő menü leírása............................................................................................. 165 3. Adatgűjtés deklarációja ...................................................................................................... 168 4. Kapcsolt adatbázisok.......................................................................................................... 170 5. Adatgyűjtés kezelése programból ...................................................................................... 172


154

Adatgyűjtés

8

1. Bevezetés A VISION program az adatok időbélyeges tárolására saját adatbázis-motorral rendelkezik. Az adatgyűjtés egyrészt magában foglalja az adatok ún. göngyölítését, vagyis az adatokon elvégzendő számításokat (átlagképzés, üzemórák és mennyiségek integrálása, számlálók kezelése), másrészt adatbázisban tárolja el őket. A gyűjtött adatokból azután tetszőleges időtartamra (műszak, napi, heti, havi, stb.) vonatkozó listák, összesítések és ebből diagrammok készíthetők, ill. exportálhatók szövegfájlba, Excel-be és SQL adatbázis táblákba. A gyűjtött adatokat előre összeválogathatjuk táblázatokba, hogy megkönnyítsük a kezelő munkáját. A kezelő azonban maga is készíthet táblázatokat, válogatásokat és az abból készített listákat, görbéket pedig külön lementheti. A táblázatok összeállítása általában a technológiai szempontokat követi. Az adattárolás lehet automatikus, előre beállított ciklusidőt követkeve (pl. óránként), vagy eseményhez kötött. Az esemény lehet maga a változás (ami digitális jelek esetén praktikus), de lehet egy folyamat indítása, vagy leállítása is. Ilyen esemény pl. egy szivattyú, vagy egy batch folyamat (pl. hőkezelési eljárás) elindítása. Megjegyezzük, hogy az adatgyűjtési rendszer nem az egyetlen lehetőség adatok időbélyeges tárolására, hiszen a VISION programból bármilyen adatbázis kezelő (táblázat vagy SQL) utasítások is kiadhatók. Az adatgyűjtés használata azonban rendkívüli mértékben leegyszerűsítheti a programozói munkát és kényelmes, gyors szolgáltatás nyújt a felhasználónak. További részleteket az alábbi fejezetekben talál:

8

Adattárolás elve Tárolt adatok lekérdezése Adatgyűjtés deklarációja Kapcsolt adatbázisok Adatgyűjtés kezelése programból

Adatgyűjtés

155

1.2. Az adattárolás elve Mint említettük, az adatokat a VISION program saját adatbázisában tárolja el. Az önálló adatbázis-kezelő motor szükségességét számos körülmény indokolja. Egyrészt az adattárolás így sokkal gyorsabb, mintha pl. SQL szerverre bíztuk volna. A sebességkülönbség akár a két nagyságrendet is meghaladhatja, aminek egyszerűen az a magyarázata, hogy a gyűjtött adatok adatbázisában bináris adatokat és közvetlen VISION változó-referenciákat találhatunk, de az időbélyeg is megfelel a VISION packtime formátumának, ami az időbeli kereséseket és kiválasztást gyorsítja. Akár 100Mbyte méretű adatbázis is visszaolvasható „egér sebességgel”. Az önálló motor mellett szól ezenkívül a teljeskörű feladatmegoldás (complete solution) követelménye is, vagyis az az igény, hogy a program mindenféle külső támogatás nélkül is használható legyen. Megjegyezzük, hogy a VISION adatgyűjtés közvetlenül átirányítható SQL táblákra is, ami végül kielégíti a külső adatbázis használatát - ha úgy tetszik, pont a teljeskörű feladatmegoldás jegyében. Ez a feladat azonban a már említett adat-exporttal is megvalósítható, amellyel Excel, szövegfájl vagy SQL táblák számára adhatunk át adatokat. Ez utóbbi esetben az adatgyűjtés átmeneti tárnak tekinthető. A konverzió történhet programból, vagy a gyűjtött adatok kezelésére szolgáló ablakból a kezelő által. Az adatgyűjtés általában egyetlen nagyméretű adatbázisba történik, amelynek alapesetben DATA.DAT a neve. Hasonlóan a trendhez, ennek az adatbázisnak is fix a hosszúsága, az adatok tárolása pedig az ún. gyűrű-pufferben történik; vagyis a teljes tárolási hosszon kívüleső, legrégebbi adatok törlődnek. Más szóval, az adatgyűjtés a változónként beállított utolsó n időbélyeges adat tárolására képes. Ennek a tárolási elvnek a következő előnyei vannak: • • •

•

Biztosítja az adatbázis automatikus karbantartását, mivel a régi adatok automatikusan törlődnek Az adatbázis hossza menet közben nem változik, a diszk megtöltésétől tehát nem kell tartani Mivel a fájlt a rendszer adatbázisának lefordításakor hozza létre, az a diszken folytonos területet foglal el, ami a Windows page fájlhoz hasonlóan a leggyorsabb diszkkezelést (ui. az adatok folytonos track-sector területen találhatók) és a legnagyobb védelmet biztosítja Biztosítja a külső programokkal szembeni védettséget, mivel a kereskedelmi forgalomban hozzáférhető programokkal ez az adatformátum nem olvasható. Az adatok csak a VISION programon keresztül nyerhetők ki.

Mint látható, a fájlformátum kidolgozásakor az automatikus karbantartás és a sebesség optimuma volt a meghatározó. Ennek a tárolási elvnek azonban van egy fontos hátránya: •

A régi adatok tárolását - ha szükséges - külön archiválási eljárással kell biztosítani

Az archiválási eljárásokra később még visszatérünk. Előljáróban annyit, hogy az legegyszerűbben az adatfájl lemásolásával (automatikusan programból, vagy kezelői aktivitásra) oldható meg, ill. az adatok regisztrátumokba való lementésével. Az is előfordul, hogy az archívum maga az adatexport révén keletkező állomány. Az adatfájlt praktikusan 1 év adatának a tárolására célszerű alkalmassá tenni. Hogy érzékeltessük, mekkora adatmennyiséget jelent ez, végezzünk el egy rövid számolást: 156

Adatgyűjtés

8

Legyenek kiindulási adataink a következők: - Adatgyűjtésre használt változók száma: - Automatikus tárolási idő: - Cirkuláris puffer mérete ebből kiszámítható: - DATA.DAT fájl mérete: - Összes tárolt adat:

500 (analóg és digitális jelek) 15 perc 35040 141 MByte (1 regiszter tipikusan 8 byte) 17,5 millió

Ekkora adatmennyiség még kényelmesen kezelhető (pl. archiválható) és gyors hozzáférést biztosít a VISION programban (8192 adatra készítünk változónkét egy gyorsítótárat). Mindez SQL adatbázis használata esetén - a többszörös tárolási igény mellett - reménytelenül lassú lenne, mivel egy select akár több másodpercig is tartana. A VISION esetén azonban ez csak néhány ms.

8

Adatgyűjtés

157

2. Tárolt adatok lekérdezése Az adatgyűjtés a legördülő menüből vagy a toolbárból választható ki:

Adatgyűjtési lista

Az adatgyűjtő rendszer által eltárolt adatokat az alábbi VISION ablakban kérdezhetjük le:

A kép bal oldalán az adatgyűjtéshez rendelt változók listája látható (ezek adatait kérdezzük), a jobb oldalon pedig az aktuálisan kiválasztott adat(ok) táblázata, ill. grafikona. 1. Adatok kiválasztása 2. Táblázatok 3. Grafikon rajzolása 4. Pásztázás 5. Eloszlás-diagramm 6. Adatok lekérdezése 7. Adatok konvertálása 8. Regisztrátumok készítése 9. Archiválás 10. Legördülő menü

158

Adatgyűjtés

8

2.1. Adatok kiválasztása A listán dupla kattintással válogathatjuk össze a megjelenítendő adatokat, egyszerre legfeljebb 32-őt. A kiválasztott adatok az ablak alján látható kiválasztó-listában jelennek meg. Ennek a listának az elemeire, vagy a már kiválasztott adat sorára kattintva az adat a kiválasztásból törlődik - vagyis ugyanazzal a művelettel helyezhetünk el új adatokat (új oszlopokat), mint amivel töröljük azokat. Az adatok kiválasztása egyébként megfelel a trendablaknál leírtaknak. Az időbeli kiválasztást az időszelektor végzi. Műszakos, napi, heti, havi, negyedéves, éves vagy időtartomány szerinti listázás közül választhatunk. A kívánt időtartamot léptetéssel kereshetjük meg (le-fel nyilakkal), vagy egyszerűen begépelve a megfelelő napot hetet, hónapot, stb.. Az adott időszakor megelőző időtartomány a legutolsó teljes adat (teljes műszak, nap, hét, stb.) Néhány időtartomány a legfontosabbak közül: Műszakos adat:

Napi adat:

Havi adat:

8 Negyedév:

Időtartomány:

Időtartománynál a le-fel nyilak annál az időelemnél találhatók, ahová legutoljára kattintottunk. Léptethetjük tehát az órákat, napokat, vagy a hónapokat is.

Adatgyűjtés

159

2.2. Válogatások, táblázatok Annak érdekében, hogy ne kelljen mindig összeválogatni a táblázatba szánt adatokat, előre konfigurálhatunk táblázatokat. Ezek általában a technológiai szempontokat tükrözik. Például külön táblázatba kerülhetnek az egyes alrendszerek üzemórái, az elszámolási adatok, a statisztikai adatok; üzemegységenként, gépcsoportonként, stb. Az előre konfigurált táblázatok jelennek meg a második fülre kattintva. Ennek a táblázatnak az elemei tehát adatcsoportokat reprezentálnak, így az előző fejezetben ismertetett kiválogatást megsprórólhatjuk. A jobb oldalon pedig az éppen kijelölt táblázat adatai láthatók. Lehetőség van arra, hogy az előre konfigurált táblázatokon túl a felhasználó maga is készíthessen táblázatokat. Ennek a következő a módja: 1. A változók listájából válasszuk ki a táblázatba szánt adatokat. 2. A fájl menüből, vagy a jobb egérgomb megnyomására előugró menüből válasszuk ki a “válogatás mentése” opciót. 3. Adjuk meg a táblázat nevét és leírását (v. funkcióját).

8

160

Adatgyűjtés

Új tábla

A felhasználó által készített táblázat is megjelenik a táblázatok között, de eltérő színű ikon különbözteti meg őt a többi (előre konfigurált) táblázattól. A felhasználó természetesen módosíthatja és törölheti az általa készített táblázatokat - ugyancsak a fájl-, vagy a jobb egérgomb menü válogatás opciói által (módosítás, törlés).

2.3. Grafikon rajzolása Abban az esetben, ha az adatok táblázatának a fejlécére kattintunk, alul megjelenik a kiválasztott adatsor grafikonja. Ide kattintunk

8

A beállítás opciók, ill. az eszközmenü nyomógombjai segítségével különféle grafikonformátumok között válogathatunk: bárgráf sor vagy szalag diagramm, 3D vagy 2D megjelenítés. A grafikonra bárhány adatsort elhelyezhetünk a fejlécre (változó nevére) kattintással. Ugyanezzel a művelettel le is vehetjük az adatot a grafikonról. Néha előfordul, hogy csak 1 adat megjelenítése szükséges, és azt az egér mozgatásával kényelmesen változtatni kívánjuk. Ilyenkor van szükség arra, hogy a beállítás menü 'többszörös kiválasztás' opcióját kikapcsoljuk. Adatgyűjtés

161

A grafikon automatikusan az adat minimuma és maximuma között rajzolódik fel, 0-bázison. A 0-bázis azt jelenti, hogy a pozitív értéktartományt [0,max], a negatívat pedig [min,0] tartományban ábrázoljuk. Abban az esetben, ha a minmum negatív a maximum pedig pozitív, a tartomány [min,max] lesz. Ez utóbbi kijelzési forma azonban előírható a program számára. Erre szolgál a beállítás menü 'ábrázolás min-max között' opciója. Ilyenkor a megjelenítés mindig a [min,max] tartománynál 10%-kal nagyobb sávban történik, vagyis az adatokat kellően kinyújtva jeleníti meg. A 3D-ben ábrázolt grafikonon az adatok egymás utánisága, vagyis sorrendje a változó név mozgatásával változtatható meg. Mindig az a görbe van legelöl, amelyiknek azonosítója első a sorban. Ha a változó nevét az egérrel megragadjuk és jobbra vonszoljuk (drag), a grafikon is hátrébb kerül, felcserélve helyét az utána következővel. A hátsó adatokat pedig ellentétes irányban mozgatva hozhatjuk előre. Az azonosító drag-&-drop mozgtásával tetszőleges görbesorrendet állíthatunk elő. Fontos tudni, hogy a grafikon és a táblázatok találkozásánál ún. splitter-ek vannak. Ez egy láthatatlan sáv, ami azonban megragadható és segítségével az ábra arányai megváltoztathatók. A 'nagyítás' eszközmenü eltünteti az ablak bal oldalán található táblát, ezáltal még több helyet hagy a grafikonnak. A teljes ablak emellett nagyítható, ill. maximalizálható. A grafikon nyomtatására külön opció szolgál (ld. nyomtat menü).

2.4. Pásztázás A grafikon adatai pásztázással kérezhetők le. (Pásztázás: lenyomott bal egérgombbal a grafikon teljes hosszában végrehajtott mozgás.) A grafikon pozíciójának megfelelő, pásztázott adatsort a program a táblázatban is megmutatja, a számszerű értékek tehát ott olvashatók. A dolog fordítva is működik. Ha a táblázat sorára kattintunk, akkor a megfelelő grafikai pozíciót jeleníti meg a program.

162

Adatgyűjtés

8

2.5. Eloszlás diagram Statisztikai jellegű adatok esetén lehet érdekes az eloszlás diagram, ami a grafikon jobb sarkában látható nyomógombra, vagy a beállítás menü 'eloszlás diagram' opciójára kattintva jelenik meg. Az eloszlás a minták adott értéktartomány-beli előfordulási gyakorisága alapján készül. Adott középértékű, fizikai mérésekből készült statisztikák esetén az eloszlás Gauss-görbéhez közelít.

2.6. Adatok lekérdezése A lekérdezés dupla kattintással történik akár az adattáblára, akár a grafikonra. Ilyenkor jelenik meg a harmadik fülnek megfelelő lista, ami nem más, mint a pásztázott teljes adatsor, külön táblázatba írva. Ez a további bonyolítás azért szükséges, mivel ebben a táblázatban a kiválasztott adatok egyéb tulajdonságai is megjelennek: jelentés, minimum, maximum, átlag, szórása. A szükséges tulajdonságok a beállítás menü alapján válogathatók össze. A lekérdezett adat végeredményben tartalmazhatja a pásztázott adatokat, a változó jelentését és az adott időtartamra kiszámított statisztikai jellemzőket (mimum, maximum, átlag, szórás). A lekérdezés külön ki is nyomtatható.

2.7. Adatok konvertálása Az adatgyűjtés kiválasztott táblázatai időtartomány és adat szerint átkonvertálhatók más adatbázis formátumba. A következő lehetőségek vannak: 1. Szövegfájl 2. Excel tábla 3. SQL adatbázis tábla

Adatgyűjtés

163

8

A konvertálás indításához mindössze a kimenő fájl nevét kell megadni a mentés dialóg ablakban, ill. az SQL adatbázis tábla esetén a felkínált (bekonfigurált) SQL adatbázisok és táblák közül lehet kiválasztani a megfelelőt, vagy megadni az új tábla nevét.

2.8. Regisztrátumok készítése Lehetőség van arra is, hogy a kiválasztott táblázatokat, mint regisztrátumot, külön DAT formátumú adatbázisba mentsük. Ez a legegyszerűbb (és leggyorsabb) mentés, mivel megőrzi a VISION belső adatformátumát. Erre szolgál a fájl menü Regisztrátum mentése opciója. A mentés során készíthetünk új regisztrátumot, de arra is lehetőség van, hogy folytassunk egy meglévőt. Legtöbbször arra van szükség, hogy a regisztrátum ne csak egy, hanem több táblázat adatait is tartalmazza. Ezt úgy oldjuk meg, hogy sorra kiválasztjuk a táblázatokat, majd a regisztrátum mentése során feljövő figyelmeztetés ablakban (fájl létezik, felülírjuk?) a folytatás opciót választjuk. A regisztrátumok persze vissza is olvashatók (fájl menü: Adatbázis kiválasztása). Ez ugyanaz az eljárás, mint amikor az archivált DAT adatbázisokat olvassuk vissza. A regisztrátum azonban csak bizonyos táblázat(ok) adatait tartalmazza.

2.9. Archiválás Archiválásra azért lehet szükség, mert az adattárolás elvéből adódóan a régi adatok egy idő után elvesznek. Ha úgy lett beállítva, a rendszer csak az utolsó 1 év adatait őrzi. Szükség lehet az adatok mentésére vagy azért, hogy a régebbi adatokat is megőrizzük, vagy csak egyszerűen biztonsági okból. Erre szolgál a fájl menü 'Mentés más néven (archivál)' opciója. Az így archivált adatok a 'Adatbázis kiválasztása' opcióval vissza is olvashatók - ugyanazzal az eljárással, ahogy a regisztrátumokat töltjük vissza.

164

Adatgyűjtés

8

2.10. Legördülő menü leírása A fájl menü tartalmazza a gyűjtött adatok táblazatba való összeválogatásával, adatbázisaival és az adatok konvertálásával összefüggő műveleteit. A konvertálás során lehetőségünk van arra, hogy az adatgyűjtő változókról, vagy azok táblázatairól, a kiválasztott időtartamnak megfelelő mentést végezzünk; csakhogy ezúttal nem DAT formátumban, hanem szövegfájlként, Excel, vagy SQL táblába konvertálással. Ez a művelet éppúgy használható archiválásra is - a 3.7. pontban részletezett módon. A válogatással kapcsolatos menüpontok szolgálnak a felhasználó által készített táblák kezelésére. Amint a 3.2. pontban vázoltuk, a kezelő legfeljebb 32 adatgyűjtő változót foghat össze egyetlen táblázatba és külön néven lementheti azt. Az új táblázat azután megjelenik az előre konfigurált táblázatokkal együtt. A kezelő persze módosíthatja és törölheti is az általa kreált táblázatokat, hacsak a felhasználói jogosultság konfigurálásakor másként nem rendelkeztünk. A kiválasztott adatokat a Regisztrátum mentése opciója által menthetjük le egy különálló (kisebb) DAT fájlba, melyet azután az Adatbázis kiválasztása opcióval kérhetünk vissza az ablakba. Ez utóbbi műveletet használjuk az archív adatok visszaolvasására is, amelyet a Mentés más néven (archiválás) opcióval készítettünk. A nyomtatás menü a gyűjtött adatok lekérdezésekor megjelenített táblázatok, grafikonok és adatlekérdezések nyomtatására szolgál a következők szerint:

A táblanyomtatás végzi a gyűjtött adatok (adatcsoport és idő szerint) kiválasztott táblázatát. A Grafika nyomtatás az adatok táblázatából kiválasztott grafikonok nyomtatását végzi örökölve a képernyőn látható formátumot (3D, szalagdiagramm, oszlopdiagramm). A Kiválasztott adat nyomtatása pedig a pásztázás során kiválasztott adat, ill. a teljes táblázatra vonatkozó statisztikai adatok (minimum, maximum, átlag, szórás) nyomtatását végzi. Amennyiben villámnézet is be van jelölve, a program a nyomtatást először a villámnézet (preview) ablakára irányítja. A nyomtatás innen folytatható, amennyiben a villámnézet tartalma megfelel. Ennek az ablaknak azonban van még pár fontos funkciója, mivel a villámnézet, mint adatbázis is kezelhető, továbbá innen át lehet konvertálni a nyomtatott dokumentumot HTM, PDF, vagy akár Richtext formátumba is.

Adatgyűjtés

165

8

A képernyőn való megjelenítés során számos opció közül választhatunk. Itt kiválaszthatjuk a lekérdezett adat táblázatában megjelenő statisztikai adatokat. A Szélsőérték összesítés a minimum és maximum, a Statisztikai összesítés pedig az átlag és a szórás engedélyezésére szolgál. Külön menüpontot használunk ezenkívül az Eloszlás diagramm megjelenítésére, ill. törlésére. Az Ábrázolás min-max között opció a grafikon nulla-bázisú alapbeállítását kapcsolja ki azáltal, hogy az adatokat az aktuális minimum-, maximumnál 10%-kal nagyobb tartományban ábrázolja, vagyis kellőképp széthúzza. A Többszörös kiválasztás opció kikapcsolásával gyorsíthatjuk a grafikon-rajzolást, ha mindig csak egy adat megjelenítésére van szükség. A különféle nagyítások, grafikon-rajzolás, eloszlás diagramm rajzolása során animált ablakműveleteket láthatunk. Ezt lassú számítógépeken célszerű kikapcsolni az Animált megjelenítés törlésével. A 3D ábrázolás akkor nem praktikus, ha az adatok túlságosan sűrűek. Végül a görbeformátum menü opcióival választhatjuk ki a kívánt megjelenítési módot. Alapvetően a szalag(vonal)diagramm és az olszlopdiagramm közül választhatunk. Abban az esetben, ha a 3D-t kikapcsoltuk, a vonal vastagításával is operálhatunk. A nézet opció az ablak részeit kapcsolja ki-be, valamint a megjelenítés módját szabályozza. Itt kapcsolható be az animált nagyítás és a 3D megjelenítés is.

A súgóval a gyűjtött adatok használatáról kaphatunk részletes tájékoztatást, többek között ezt a dokumentumot is olvashatjuk.

166

Adatgyűjtés

8

A névjegy tartalmazza a program verziószámát és funkcióját:

8

Adatgyűjtés

167

3. Adatgűjtés deklarációja Maga az AGY adatbázis most is táblázatok rendszere, ahol az egyes táblázatok a unitonként és projektenként generált változótáblák adatgyűjtési változóit fogják össze. Minden egyes tábla több AGY struktúrákból áll összhangban a táblázatban szereplő, adatgyűjtésre kijelölt változók számával. A tárolás most is cirkulárisan történik, tehát az adatgyűjtésre felhasznált adatbázis mérete sem növekszik az idő előrehaladtával. Azt viszont nem lehet megmondani, hogy mekkora az adatgyűjtés időbeli átfogása, mivel az adatok letárolása lehet akár teljesen rapszodikus is. Abban az esetben, ha az adatbázis feltöltése a kommunikációhoz igazodik, akkor az adatok tárolási gyakorisága a kommunikáció ciklikusságának felel meg, s ezzel a teljes tárolási idő már megbecsülhető. Fontos tulajdonság, hogy az adattárolás mindig időben rendezett módon történik, tehát nem okoz időrendiségi problémát az, ha a kommunikáció révén a későbbi adatok előbb érkeznének meg a rendszerbe. Ehhez persze az is szükséges, hogy a telepekről származó adatok korrekt időbélyeggel együtt érkezzenek. Hangsúlyozzuk, hogy a gyűjtött adatok nem equidisztánsak, mivel minden egyes regiszter önálló időbélyeggel van ellátva. Az adatbázis még csak nem is relációs szerkezetű, mivel minden adatsor önálló időléptékkel rendelkezik. Ezekből az adatsorokból viszont a VISION program képes táblázatokat előállítani úgy, hogy az időléptéken (pl. 1 óra) belüli adatokat soronként összesíti, így hozva létre a 24 sorból a teljes napi táblázatot. Az időlépték és a táblázat által megjelenített tartomány egyaránt paraméter. Az adatgyűjtésből készült táblázatok tehát nem a tárolt adatok közvetlen megjelenítései, hanem bonyolult adatösszesítési eljárások eredményei. Hogy miért olyan bonyolultak, azt az adatgyűjtés adattipusának az ismertetésénél elmagyarázzuk. A gyűjtött adatok deklarációja éppúgy a rendszerleíró adatbázisból adódik, mint a trendek esetében (változódeklaráció). A következő ábra a AGY mezőt szemlélteti.

168

Adatgyűjtés

8

A kiválasztott AGY adattipus meghatározza az alkalmazott számítási algoritmust, az adat triggerelését és az összesítés módját: Tipus Pillanatérték Átlagérték

Algoritmus átlagérték számítás

Mennyiség

idő szerinti integrálás

Integrált érték Számláló

léptetés egyenként v. beolvasott számláló modulo értéke alapján másodpercenkénti inkrementálás

Üzemóra

Triggerelés számítás engedélyezése kumuláció engedélyezése diszkrét léptető jel v. modulo számláló

Összesítés átlagképzés

üzemel jel

összeadás Formátum:OR:MP

összeadás különbségképzés összeadás

Látható, hogy az adattipus és a trigger jel a legkülönfélébb feladatok megoldását teszi lehetővé. Az is világos, hogy egészen másképp kell az átlagokat, üzemórákat és pl. az integrál adatokat összesíteni. Ez utóbbi esetben az összesítés nem más az időszak végének és kedtetének - pontosabban a megelőző időszak végének - a különbsége, amíg a mennyiségi adatokat egyszerűen összeadjuk, az átlagolt méréseket pedig átlagoljuk. Ezért mondtuk korábban, hogy a táblázatos megjelenítéshez szükséges soronkénti összesítés nem olyan triviális dolog. Nem szükségszerű, hogy a VISION program maga végezze el a gyűjtött adat előállításához szükséges számítási algoritmust. Abban az esetben pld., ha az üzemóra a külső forrásból érkezik, az alkalmazott algoritmus és a triggerelés egyaránt hatástalan. Erre akkor lehet szükség, ha a PLC maga számítja a berendezések üzemóráját. Lényegét tekintve az adatgyűjtés funkció kiválóan használható adatok időbeli letárolására és abból különféle táblázatok és összesítések, valamint grafikonok előállítására. Ahogy a trendek esetében, most is létezik a megfelelő VISION utility kép. Megjegyezzük, hogy a gyűjtött adatokból (mint általában minden időadattal ellátott adatbázisból) is készíthető trend.

Adatgyűjtés

169

8

4. Kapcsolt adatbázisok Ahogy az előző 3 pontban bemutattuk a VISION program a dinamikus adatokból többféle saját adatbázist állít elő, amelyekből optimális sebesség és tárolási hely mellett képes grafikonokat, táblázatokat és különféle időszakos jelentéseket készíteni. Lehetőség van azonban arra, hogy a rendszerleíró adatbázis felépítéshez igazodó tábázatokból (unit/projekt) tetszés szerinti további táblázatokat készítsünk az adatok összeválogatásával. Ez látható az adatbázisok és konfigurálásuk című következő ábrán. Lehetőség van pld. arra, hogy az összes telep, vagy valamely telepcsoport összes gyűjtött üzemóráját egy külön táblába foglaljuk bele. Ez a témakör még látszólag az előző fejezethez kapcsolódik. A konfiguráció eredményeképpen azonban egy új adatbázis tábla, egy ún. kapcsolt tábla jön létre. A kapcsolt tábla azonban már egyáltalán nem biztos, hogy a VISION saját adatbázisának a segítségével készül. Amit a kép alsó felén látható, ezeket a pótlólagos táblákat 4-féle adatbázis tipusból, külön-külön további 10-12 féle adatbázis fajtából választhatjuk ki. A következő lehetőségeink vannak: Adatbázis tipusok: 1. VISION saját (natív) adfatbázis kezelői trend adatgyűjtés 2. ADO: Microsoft OLE DB adabázisok ODCB (dBase, Excel, Access ...) SQL Microsoft Jet Oracle 3. BDE: Borland Database Engine alapú adatbázisok ODCB (dBase, Excel, Access ...) Interbase (SQL) Infromix (SQL) Microsoft (SQL 7, 2000) Oracle, Oracle8 DB2 Access dBase Paradox ... 4. Lokális dBase Lokális BDE alias-ok Látható, hogy a rendszer lényegében az összes elterjedt adatbáziskelő rendszert is támogatja, a legtöbbet még többféleképpen is (Access adatbázisokat pl. háromféleképpen is bekonfigurálhatunk).

170

Adatgyűjtés

8

A fenti listából kiemeljük még a dBase adatbázisok támogatását, mivel ezeknek az adatbázisoknak a kezelésére a VISION saját (natív) adatbáziskezelő motorral rendelkezik. Az összes többi adatbázishoz már a megfelelő ODBC drivert, vagy BDE adatbázis motort veszi igénybe. A natív adatbázisok alkalmazását különben a lényeges (kb. 5-szörös) sebességkülönbség miatt célszerű preferálni. A kapcsolt adatbázisok kétféleképpen tötlhetők fel adatokkal: 1. VISION VAL nyelvű programjából táblázatkezelő v. SQL parancsok útján 2. Az adatgyűjtési- vagy trend adatbázisokra való átirányítás útján Ez utóbbi azért érdekes, mivel így automatikusan készíthetünk a gyűjtött adatokból táblázatokat pl. Excel-ben, vagy MS-SQL adatbázisban is. Ehhez még VAL nyelvű programra sincs szükség.

8

Adatgyűjtés

171

5. Adatgyűjtés kezelése programból A gyűjtött adatok részben a gyűjtött adatok listázása képen, részben pedig a VX utasításnál jeleníthetők meg. Az VX tábla szűrő tulajdonságához lehet hozzárendelni egy időszűrő objektumot, ami az TY paranccsal hozunk létre. Tehát összerendelhető a TY időszűrő és a VX objektum, ezzel tetszőleges alkalmazásbeli naplókat hozva létre. Ezek azután közvetlenül rárakhatók a jelentésekre is. Van néhány FH parancs az adatgyűjtés táblázatos megjelenítésén és listázásán túlmutató feladatok programozott megvalósítására. Ezek a következők: 1. TimeFilter: Időszűrő programból való beállítása: FH "AGY_tábla_neve",TimeFilter, idő_kezdete, idő_vége{, idő_lépték}; A parancs hatására időben szelektálódik az előre bekonfigurált AGY-tábla, amelyet pld.a VX paranccsal meg is nézhetünk. Az idő_kezdete argumentum egyaránt lehet LONGINT (packtime) és STRING tipusú. Ez utóbbi esetben a program által értelmezett 20-féle idő-string kombináció közül kell választanunk, tipikusan: "2003.01.29 12:34:56" - formában kell az időt előállítani. Az idő_lépték opcionális, másodpercben értendő. 2. ConvertData: AGY táblázat átkonvertálása DBF formátumba: FH "AGY_tábla_neve",ConvertData,"DATA.DBF"; 3. ReadTrend: AGY táblázat átkonvertálása trendbe, valamint statisztika készítés: FH "AGY_tábla_neve",ReadTrend, AGY1, TRN1, AGY2, TRN2, ….; ill. FH "AGY_tábla_neve",ReadTrendStat, AGY1, TRN1,MIN1,MAX1,ATL1,SZORAS1, AGY2, TRN2,MIN2,MAX2,ATL2,SZORAS2, …; Az utóbbi trendolvasás elvégzi a statisztikai feldolgozás feladatás is. A ConvertData parancsnak az adatok archiválása szempontjából van jelentőssége. A tábla az éppen aktuális időszelekció szerint konvertálódik - pl. a TimeFilter parancsot követve. A TimeFilter és a ConvertData, ill. ReadTrend parancsok egybe is írhatók, hogy az időbszűrést és a konvertálást egyetlen paranccsal is el tudjuk végezni: FH "AGY_tábla_neve",TimeFilter+ReadTrend, idő_kezdete, idő_vége, idő_lépték, AGY1, TRN1, AGY2, TRN2,…;

172

Adatgyűjtés

8

Hálózati szolgáltatások Tartalomjegyzék: 1. Bevezetés............................................................................................................................ 174 2. Egyszerű szerver-kliens hálózatok ..................................................................................... 175 2.1. Kliens alkalmazás létrehozása egyszerű hálózat esetén.............................................. 176 2.1.1. Telepítés nélküli kliens......................................................................................... 176 2.1.2. Telepített kliens .................................................................................................... 177 2.2. Kliens működése ......................................................................................................... 178 2.3. Autokliens hálózat kezelő ........................................................................................... 180 3. Összetett hálózatok............................................................................................................. 181 3.1. Összetett hálózatok típusai .......................................................................................... 181 3.1.1. Csomópontok tipusa............................................................................................. 181 3.1.1.1. Szerver............................................................................................................... 182 3.1.1.2. Kliens ................................................................................................................ 182 3.1.2. Hálózati szolgáltatások......................................................................................... 182 3.1.2.1. VISION hálózat................................................................................................. 182 3.1.2.2. DFS hálózat ....................................................................................................... 183 3.1.2.3. Web ................................................................................................................... 185 3.2. Összetett hálózatok kialakításának szempontjai ......................................................... 186 4. Hálózatkonfigurálás a hálózat-menedzserrel ..................................................................... 188 4.1. VISION hálózati szerver beállítása ......................................................................... 189 4.2. VISION hálózati kliens beállítása ........................................................................... 190 4.3. DFS hálzóati szerver beállítása ............................................................................... 192 4.4. DFS hálózati kliens beállíása .................................................................................. 195 4.5. Web szerver beállítása............................................................................................. 196 5. Tűzfal beállítása ................................................................................................................. 203 6. Hálózat-menedzser használata ........................................................................................... 205 6.1. Csatlakozás egy másik számítógépen futó VISION szerverhez ................................. 205 6.2. Indítás, leállítás............................................................................................................ 206 6.3. Mentés ......................................................................................................................... 207 7. Összetett hálózatok kezelése programból .......................................................................... 208 7.1. Példák hálózati parancsokra ........................................................................................ 210


Adatgyűjtés

173

8

1. Bevezetés Az új VISION rendszer rendkívül változatos hálózatok kialakítását biztosítja, segítségével teljeskörű szerver-klisens rendszereket hozhatunk létre. Egy rendszerben lehet akár több szerver is – részben a redundancia, részben az elosztott hálózati szolgáltatások előmozdítása érdekében. Ez utóbbi a független alrendszerekből felépülő, óriás hálózatok esetén szükséges – pl. teljes üzemirányítási, vagy távfelügyeleti rendszerek esetén –, ahol funkcionálisan teljesen eltérő szerver alkalmazásokat kell integrálnunk. Nyilvánvaló, hogy e független csomópontok közül egyik sem lehet kiválasztott, egyiktől sem függhet a többi alrendszer működése. A VISION alapú hálózatok kulcstulajdonságai a következők: • • • • • • •

Többszintű, hierarchikus hálózati rendszerek, óriás hálózatok Teljeskörű szerver-kliens hálózatok Adatgyűjtő rendszerek Sebesség- és tranzakció optimalizált rendszerek – akár 10ms-os átviteli sebességgel Redundáns rendszerek Többféle Web-technológia, Internet/Intranet Könnyű használat, megbízhatóság, egyszerű menedzselhetőség

A VISION rendszer lehetővé teszi saját, nagysebességű- és az ún. tranzakció-optimalizált (kis sávszélesség igényű) hálózatok kialakítását, de a Web-es (Internetes/Intranetes) rendszereket is támogatja – akár kombinációban a saját hálózati szolgáltatásokkal. Fontos e szó: teljeskörűség. Lényegét tekinteve arról van szó, hogy a kliensek a VISION esetében a szerverekkel azonos hatáskörrel ruházhatók fel; nemcsak parancsokat lehet kiadni a kliensből, de lehet alkalmazást is fejleszteni, képeket rajzolni, új változókat, alarmokat felvenni, s lehet azt saját szolgáltatásokkal, vagyis szerver funkciókkal bővíteni. Ebből a szempontból a VISION kliens maga is lehet szerver, sőt akár egyszerre lehet szerver az egyik hálózaton és kliens a másikon, mert a VISION hálózati csomópontok persze többféle hálózat összekapcsolására, gateway funkciók ellátására is alkalmasak – még mindig a teljeskörűség jegyében. A tisztán Web-es megjelenítőkre ez nem jellemző, hiszen a Web kliensre, egy Web böngészőbe nem helyezhetők ki szerver funkciók, egy ilyen állomás nem képes kommunikációs kapcsolatot kialakítani – mondjuk Profibus-on. Hiszen arra a számítógépre nincs is feltelepítve a kommunikációs driver, sem a fejlesztőrendszer, és pontosan ezért nem lehet konfigurálni az alkalmazásokat sem. Arról nem is beszélve, hogy egy Internet böngészőtől ez mennyire idegen feladatkör. Mint annyi minden, a VISION Web-szolgáltatása ebből a szempontból is többletszolgáltatást nyújt. Az alkalmazásfejlesztő kollégák ui. felruházhatják a VISION Web-klienseket az alkalmazásfejlesztés képességével, de letölthetők oda szolgáltatások, önálló taszkok is. Az viszont nem lehetséges, hogy a telepítés nélküli kliensek képesek legyenek önállóan kommunikálni, vagy éppen trend-, ill. alarm szerver funkciókat ellátni. Az effajta megközelítés ui. távol áll az Internet filozófiájától, s ezért a VISION rendszer sem támogatja azt.

174

Hálózati szolgáltatások

9

Mindebből kitűnik, többféle hálózati megoldás kombinált használatára van szükség, hogy a bevezetőben említett teljeskörűség is kielégítést nyerjen, s hogy képesek legyünk elosztott hálózatokat kialakítani – független szerverek együttműködő rendszerére alapozva –, amelyek adatai azután megjeleníthetők a Net-en is úgy, hogy egy távoli munkaállomásról, egy Internet-böngészőből mégis képesek legyünk az egyszerűbb konfigurációs feladatok ellátására, a rendszer távfelügyeletére, szervízelésére, karbantartására. Nézzük a részleteket.

2. Egyszerű szerver-kliens hálózatok A VISION rendszerrel nagyon könnyen készíthetünk szerver-kliens hálózatot az alapértelmezett beállítás felhasználásával. Annyira könnyen, hogy praktikusan nem is kell csinálni semmit, csak elindítani a távoli programot. A program ui. az alkalmazás projektfájljának az elérési útjából dönti el, hogy kliensként, vagy szerverként funkcionáljon-e. Amennyiben a programot azon a számítógépen indítjuk el, amelyik a projektet tartalmazza, szervert aktiválunk, ha pedig egy távoli gépről indítjuk el a projektet, akkor klienst. Ehhez pedig mindössze az szükséges, hogy megőrizzük a hálózatkonfigurátor következő ábrán látható alapbeállításait:

9

Az alapértelmezett az elérési út alapján való megkülönböztetés – ahogy az ábrán is látható. Abban az esetben, ha a projekt elérési útja \\ - el kezdődik (ez a lokális hálózati elérés alapesete), akkor a gép kliens lesz, ellenkező esetben szerver (pl. c:\Program Files\Vision…). Külön menücsoport szolgál a szerver és a kliens feladatainak a meghatározására (szerver további beállításai, kliensek egyéb paraméterei). Azért kell mindkettőt szerepeltetni, mivel a projekt ugyanazt a konfigurációt használja a szerver és a kliens oldalon, lévén ugyanarra a Hálózati szolgáltatások

175

projektre kapcsolódik mindkettő. Amennyiben szerver (mivel az elérési út a helyi gépre mutat, tehát nem \\ - el kezdődik), akkor a szerver beállításai menücsoport érvényes, ha pedig kliens (mivel az elérési út egy távoli gépre mutat és ezért \\ - el kezdődik), akkor a kliensek egyéb paraméterei. Itt határozhatjuk meg azt, hogy a kliensen akarjuk-e a ciklikus programot, vagy az alarmokat futtatni, akarunk-e kommunikálni. Alapesetben ez utóbbi két taszktipus a klienseken tiltott. Viszont a cilikus program engedélyezett, mivel elképzelhető, hogy a kliensnek is szüksége van programozott kiszolgálásra, pl. időzítőkre. Arra természetesen ügyelnünk kell, hogy a számítások csak a szerveren legyenek elvégezve, mivel egyébként az adataink hazárdossá válhatnak. Ennek érdekében esetenként a MasterVision (szerver lekérdezése programból), vagy a NetServer (aktív szerver lekérdezése programból multiszerveres környezetben) függvények segítségével a programban feltételes programágakat készíthetünk (if MasterVision then … else … fi). Emellett figyeljünk arra, hogy milyen a változók hálózati publicitása. Például egy dátum-idő típusú adat vagy a felhasználó nevét horodozó változó sose legyen published, mivel az a hálózat szerver és kliens oldalán óhatatlanul eltér és ezért nem lehet változás alapon továbbítani őket. A csomópont azonosítására szolgáló NumVision függvény csak kompatibilitási okokból szerepel, mivel a kliensek és a szerverek ezen paramétere lehet azonos is (a VISION program régebbi változataiban ezeknek még különbözőnek kellett lenniük). Konkrétan az egyszerű hálózat alkalmazása esetén nem is lehet különböző, mivel a szerver és a kliens is ugyanazokat a beállításokat használja. A konfigurációban látható “további hálózati csomópontok” menücsoport segítségével készíthetünk ún. összetett hálózatokat, amiket a későbbiekben részletesen ismertetünk. Nézzük meg azonban, hogyan hozhatjuk létre a távoli számítógépen a kliens alkalmazást ezen „egyszerű” esetben.

2.1. Kliens alkalmazás létrehozása egyszerű hálózat esetén Két lehetőség is van az egyszerű hálózat kialakítására: telepítés nélküli és telepített.

2.1.1. Telepítés nélküli kliens A feladat a legegyszerűbb esetben egy parancsikon létrehozása, ami a távoli gépen található projektre mutat. Nem elég azonban a parancsikonunkat pusztán a VPR kiterjesztésű projektfájlra irányítani, mivel az adott számítógépen nem feltétlenül, sőt általában nincs feltelepítve a VISION (telepítés nélküli hálózat), ezért ott a társítás sem érvényes. A parancsikon parancsora ezért tartalmazza a távoli gépen található VPR.EXE elindítását és annak parancssorában a projekt fájl nevét. Például: Parancsikon parancssora:

\\server\vision\bin\_vpr.exe \\server\vision\project\alk\alk.vpr

A két argumentumot egy szőköz választja el – a szóközt is tartalmazó elérési utat idézőjelek közé kell tenni. Vigyázat: hálózati meghajtót ne használjunk, mert abból a program nem tudja megállapítani, hogy kliensként kell-e üzemelnie. Ne felejtsük el, hogy ez az elérésí út első két karaktere alapján dől el: \\... Mi több, a standard hálózati elérés univerzális a lokális hálón. Megjegyezzük, hogy az indító ikont akkor is így érdemes megadni, ha a szerver alkalmazás elindítására készítünk önálló parancsikont, csak akkor nem \\ - el kezdjük a parancsot. Ezt az ikont azután behúzhatjuk az indítópultba, hogy az alkalmazásunk a gép elindításával automatikusan elinduljon. 176


9

Végül érdemes tudni, hogy a parancsikont a VISION program is le tudja gyártani: Indítsuk el a VISION-t a távoli gép valamilyen böngészőjéből, majd menjünk el a projekt lapjára (vagyis kattintsunk a projektmenedzser legelső sorára) és kapcsoljunk szerkesztés üzemmódba:

Íme a menü, ami parancsikont készít a telepítés nélküli kliensen

2.1.2. Telepített kliens A másik lehetőséget a telepített hálózat adja. Ez azért lehet előnyös, hogy legalább a VISION program összetevőit ne kelljen a távoli gépről beolvasni. A másik ok, amiért telepített klienst használunk, hogy különbséget tegyünk az egyes kliensek között. Erre használható a NumVision paraméter, ami tehát az egyes klienseken különböző lehet. A telepített hálózati kliens egyszerűen a program Új projekt opciójával készíthető: Ebben az esetben – az Előre gomb megnyomása után – a szerver keresés opcióval kell megkeresnünk a szerver alkalmazás projekt fájlját, tehát végeredményben ugyanúgy létrejön majd az egyszerű szerver-kliens hálózat, csak ezúttal nem parancsikonból, hanem magában a helyi VISION alkalmazásban (helyi konfigurációt használva). Ha jobban megvizsgájuk, láthatjuk, hogy a kliens az ún. LinkPrefix konfigurációs paramétert állítja rá a távoli gépre; ezt a prefixet fűzi azután az összes – relatív elérési úttal megadott – fájlnév elé. Fontos továbbá, hogy a kliens és a szerver alkalmazásnak azonos legyen a neve.


177

9

2.2. Kliens működése Tekintettel arra, hogy a kliens fájlrendszere éppúgy a szerver alkalmazás fájlrendszerét használja – akár telepített, akár telepítés nélküli a kliens –, a képek és az adatbázisok ugyanabból a szerver adatbázisból töltődnek fel. Természetes hát, hogy a kliens induláskor ugyanazt az állapotot mutatja, mint ami a szerveren is látszik. A betöltés után azonban a kliens számítógép TCP/IP socket-en keresztül megpróbál kapcsolatot teremteni a szerverrel és ettől kezdve a változásokat TCP/IP-n továbbítja. A TCP socket port alapesetben 1700, 1701, 1702, stb. egészen a maximális egyidejű kliens terminálszámig (a hálózati licence-től függően). Ez tűzfalakat, vagy más védelmet tartalmazó hálózati rendszerek esetén lehet hasznos tudnivaló. Ellenőriznünk kell, hogy a TCP/IP kapcsolat létrejött-e, mert különben nincs dinamikus adatcsere és csak a kezdeti betöltési állapot látszik. Például ez történik abban az esetben, ha a telepített hálózati klienset mégis eltérő névvel hoztuk létre (ilyenkor ui. a szerver elutasítja a kliens rákapcsolódását), vagy ha a tűzfal nem engedi meg a kapcsolat felvételét az 1700+ porton. A hálózat működésének ellenőrzésére szolgál a hálózati monitor, amit a rendszer lehördülő menüből – Szervíz B Hálózati monitor – hívhatunk.

A hálózati monitort mutatja a következő ábra. Ha a TCP/IP kapcsolat felépítése sikeres, a kapcsolt terminál és annak neve is megjelenik rajta:

Kliens számítógép a szerveren

9

178


Ugyanez a szervíz képernyő a kliensen is megjeleníthető, csak ott a két számítógép fordított,

Szerver számítógép a kliensen

hiszen a monitor a képernyő bal oldalán mindig a saját gépünket mutatja és jobbra a hozzá kapcsolódókat. Ebből az is következik, hogy a kliensen mindig csak egy kapcsolt szerver gép látszik (hiszen 1 kliens csak 1 szerverrel tud kapcsolatba lépni), a szerver oldalon viszont annyi kliens, amennyi épp rácsatlakozott. A hálózat monitor kommunikációs része mutatja a kapcsolatfelvételt (1701-es port) és a kezdeti azonosítási procedura végén, amit a Server ready felirat terminál, a folyamatos adatcserét. Az R távirat a vétel, az X és az S a küldés (az X azt jelenti, hogy delta-távirat küldésére került sor, azaz csak különbségek vannak benne és az lett azután tömörítve). A kék színű felirat mindig vétel, a piros adás. Látszik a kommunikációs monitoron az is, ahogy a rendszer az alarmok és a trendek változásait is továbbítja, ugyancsak tömörítve. Egyébként a monitor konkrét üzenetei érdektelenek, az csak hibakeresés esetén hasznos. A klienseket lehet vezérelni a szerverről és lehet üzenetet is küldeni a kliensnek, illetve a kliens is küldhet üzenetet a szervernek. Ez úgy lehetséges, hogy rákattintunk a kapcsolt számítógép ábrájára; ekkor jelenik meg a jobb oldalt látható kép: Mint látható, leállítást, felfüggesztést és a felfüggesztett kliens újraindítását kezdeményezhetjük itt, illetve küldhetünk üzenetet. Például ezt az üzenetet küldhetjük el a kliensnek, mielőtt a szervízből felfüggesztenénk azt. A kliens képernyőjén a következő jelenik meg:

Üzenet küldése lehetséges fordítva is.

Végül minden hálózat-menedzselési művelet elérhető a jobb egérgomb menüből is a számítógép ikonjára a jobb egérgombbal kattintva.


179

9

2.3. Autokliens hálózat kezelő Abban az esetben, ha a hálózati klienset felfüggesztettük, a rendszer betölti az egyszerű hálózat különálló kezelőjét. Ez azért szükséges, mert a felfüggesztett kliens lekapcsolódik a szerverről, azt akár le is állíthatjuk, a felfüggesztett kliens mégsem veszítheti el a kapcsolatot a szerver géppel, hiszen különben nem tudnánk azt újrindítani és nem tudnánk oda további üzeneteket küldeni – legalábbis a VISION-nel nem. Ezt a program következő üzenete is megerősíti, az Autokliens hálózat kezelő pedig betöltődik:

Felfüggesztés, újraindítás szerver kibekapcsolással automatikusan

A felfüggesztett kliens ebben a listában jelenik meg tehát és innen is lehet azt újraindítani, végleg leállítani, vagy annak további üzeneteket küldeni. A menüpontok önmagukért beszélnek. Mi történik azonban a felfüggesztett kliensen?

Ezt mutatja a következő ábra. A képernyő jobb alsó sarkában megjelenik egy kis ablak, amely mutatja a felfüggesztés tényét, a rendszer állapotát és tartalmazza a legfontosabb menüket is: • • • • •

Üzenet küldése Kliens újraindítása Kapcsolat bontása Kapcsolat felépítése Kilépés (bezárás)

Végül az autokliens hálózat kezelő képes a kliensek automatikus újraindítására és felfüggesztésére is, amennyiben ez a két checkbox engedélyezett. Vagyis a visszaindított szerver elindítja az összes klienst (egymástól a Késl.-nél megadott másoderccel eltolva, hogy ne egyszerre kapcsolódjon valamennyi, hanem soran egymás útán). Egyébként a kliens menüből indítható újra – egyenként.

180


9

3. Összetett hálózatok Ahogy a bevezetőben említettük, a VISION programmal készíthetünk olyan hálózati szerverkliens rendszereket is, ahol többféle hálózati kommunikációs elvet alkalmazunk (sebességoptimalizált hálózat, tranzakció-optimalizált hálózat és Web), azokat tetszés szerint rendelve hozzá az összevont alkalmazás (szuperprojekt) egyes projektjeihez. Az összetett hálózatoknak tehát elsősorban összevont projekteknél van jelentősége, de akkor is használnuk kell, ha a szerverhez pl. Web szervert kívánunk illeszteni, vagy lassú, kapcsolt hálózatot. Ezeket az extra hálózatokat azután dinamikusan építhetjük fel, vagy statikusan és használhatjuk adatlekérdezésre, távszervízelésre, stb. Az összetett hálózatnak tehát nagyon sokféle oka és szempontja lehet.

3.1. Összetett hálózatok típusai A hálózatokat a VISION rendszerben csomópontként (node) képzeljük el. Egy munkaállomás tartalmazhat akár több hálózati csomópontot is, tehát a node nem a fizikai, hanem a logikai feladatok szétválasztására szolgál. Pontosan így hozhatók létre azok a hálózati terminálok, amelyek gateway feladatokat látnak el (kliens az egyik hálózaton és szerver egy másikon), de a kliens és a szerver funkciók hozzárendelhetők projektekhez is - az egyikhez kliensként, a másikhoz szerverként – igény szerint. Mivel pedig a projekteket egy-egy alkalmazásban összevonhatjuk, triviális, hogy szerver- és kliens alkalmazások egyszerre vannak jelen. A csomópont tipus és szolgáltatás szerint választható az alábbiak közül: A) Csomópont tipusa: • •

Szerver Kliens

B) Szolgáltatás • • •

VISION hálózat DFS hálózat Web-es hálózat

9

A típus és a szolgáltatás persze kombinálható, így jönnek létre a VISION hálózati szerverek és kliensek, vagy a Web-szerverek és kliensek. A tranzakció-optimalizált (kis sávszélességigényű) hálózat kapta a “DFS hálózat” nevet. A “VISION hálózat” pedig a nagysebességű lokális hálózatok ideális rendszere, ahol a kellő sávszélesség a rendelkezésünkre áll, s ugyanazt a hálózatot nemigen használják üzemviteli, adminisztrációs feladatokra, vagyis a hálózat szabad kapacitásai korlátlanul kihasználhatók.

3.1.1. Csomópontok tipusa A csomópont lehet szerver, vagy kliens.


181

3.1.1.1. Szerver A szerver olyan hálózati csomópont, amely kapcsolat felépítésére kínálja magát más hálózati csompópontok felé és azok számára valamilyen szolgáltatást nyújt. A szerver szolgáltathat adatokat - amelyeket a vele kommunikációs kapcsolatban álló ipari alrendszerből, PLC-kből szerez -, szolgáltathat számításokat, trendeket, alarmokat és adatbázisokat, ill. magát az alkalmazást is. A Web-kliensen látható képeket a Web-szerver hozza létre, s tölti le a hozzá szükséges adatokat, táblázatokat, trendeket, stb. Lényegében ugyanez a helyzet a VISION saját hálózatai esetében is.

3.1.1.2. Kliens A kliens olyan hálózati csomópont, amely kapcsolatot próbál felépíteni a szerverrel (szerverekkel), hogy onnan letöltse az alkalmazás megjelenítéséhez szükséges képeket, adatokat, táblázatokat, trendeket, alarmokat, stb. Amint felépül a kapcsolat, a kliens maga is képes szolgáltatásokat nyújtani, hiszen a hálózati kommunikációnak az az alapelve, hogy változásokat továbbítunk a többi szerver és kliens gép felé. Mindegy, hol keletkezik az adat, ha publikus, valamennyi csomóponton látszik. Természetesen a kliens által kiadott parancsok is megjelennek nemcsak a szerveren, de a többi kliensen is, s lényegében ugyanez a helyzet a kliens által elvégzett számítások eredményeivel, az általa létrehozott adatbázisokkal, vagy a klienshez kapcsolódó más kommunikációs csatornákon érkező adatokkal, amelyeket a kliens ilyenformán a többi hálózati csomópont felé továbbít. A VISION kliens emellett képes az alkalmazások megváltoztatására, konfigurálására is – hacsak az alkalmazásfejlesztő kollégák e jogokról másképp nem rendelkeznek.

3.1.2. Hálózati szolgáltatások A hálózati szolgáltatás egy driver, vagy driver-rendszer részeként a hálózati kapcsolat módját határozza meg a következők szerint:

3.1.2.1. VISION hálózat

9

A VISION program rendelkezik saját hálózati kommunikációs driverrel - elosztott hálózati rendszerek kialakítása céljából. A VISION hálózat a nagysebességű kapcsolatok rendszere. Azt feltételezzük, hogy a hálózati szerver csomópontoknak “látszik” a fájlrendszere, tehát az adatbázisokat, képeket, alarmokat, trendeket nem szükséges onnan letölteni a kliensre, hiszen azok - oszott fájlrendszerként - hozzáférhetők a hálózat szerverén. Ilyenkor csak a változások továbbítására van szükség, amit a VISION képes akár 10ms sebességgel is vezényelni. A VISION hálózat csomóponjai tehát gyakorlatilag egyidejű megjelenítést végeznek, végezhetnek. A VISION hálózat képes kihasználni a helyi hálózat teljes rendelkezésre álló kapacitását, tehát abban az esetben, ha a hálózatot mások is használják (pl. üzemi adminisztráció), korlátozásokat kell bevezetni (pl. csökkenteni kell a sebességet), esetleg más hálózati megoldást kell választani. A VISION hálózat felépítését és működését szemlélteti a következő ábra:

182


Lokális hálózat (TCP/IP) Változások

Kliens #3

Változások

Kliens #2

Változások

Kliens #1

(Link)

Szerver Osztott file-rendszer Képek Eseménynapló Trend Adatbázis

(Link) (Link) Kapcsolódás az osztott file-rendszerhez

Hálózat elve: - Osztott file-ok kezelése - Változások átvitele Socket-en (TCP/IP)

1.ábra - Vision hálózat

3.1.2.2. DFS hálózat A VISION program rendelkezik egy speciális hálózati driverrel tranzakció-optimalizált (alacsony sávszélesség-igényű) hálózatok kialakítasára. Erre akkor lehet szükség, ha a hálózati csomópontokat alacsony sávszélességű médium (pl. 64 Kbps bérelt vonal, vagy telefonos modem) köti össze, ill. akkor, ha a hálózat egyébként más célokat, pl. vállalatirányítási feladatokat is ellát. Felépítése a következő ábrán látható: Lokális hálózat (TCP/IP) Szerver, vagy kliens

Változások

Szerver, vagy kliens

9

File-rendszer Képek Eseménynapló Trend Adatbázis

Képek Eseménynapló Trend Adatbázis

Replikáció

Hálózat elve: - File-rendszer megismétlése (replikáció), szinkronizálása Socket-en - Változások átvitele Socket-en (TCP/IP) 2.ábra - DFS hálózat


183

A leglényegesebb különbség abban áll, hogy a DFS hálózatok esetén nem látszik a szerver fájlrendszere, az alkalmazás adatbázisából, a trendekből, az alarmokból a kliens maga is kópiákat (replikátumokat) őriz, s a kapcsolatfelvétel alkalmával ezeket frissíti. A DFS hálózati csomópont tehát a saját számítógép háttértárolójáról olvassa az adatokat, ezért az rendkívül gyors, és persze akkor is elindítható, ha épp nincs kapcsolatban a szerverrel. Csupán annyi történik, hogy ilyenkor régebbi – a legutóbbi kapcsolatfelvétel alkalmával letöltött – adatokat látunk. A kapcsolatot nem szükséges fenntartani, elegendő azt olyan gyakorisággal elindítani, amennyire friss adatokra szükségünk van. Ezáltal pedig az előfizetéses (pl. telefonos) médiumok optimális kihasználására nyílik lehetőség – rendkívül alacsony sávszélesség mellett. Hiszen óránkénti kapcsolatfelvétel esetén is pár másodperc alatt letölhető a szerverről az összes változás, utána a kapcsolat bontható. Így a hálózat kihasználtsága szinte nem is mérhető (óránként pár másodperc!). A tranzakció optimalizált hálózat kiválasztásának a fentiek mellett van még egy triviális szempontja. Egyszerűen arról van szó, hogy nem akarjuk megosztani a szerver adatbázisokat a hálózaton (a VISION hálózatnak ugyebár erre szüksége van), amire különösen akkor van igény, ha a hálózaton más tevékenységek, pl. üzemirányítási feladatok is zajlanak. Az adatok elrejtése ugyanakkor kiválóan egybevág azzal az igénnyel is, hogy ezeket a vállalatirányítási hálózatokat a VISION hálózat ne terlhelje. A DFS alapú hálózatoknak egy érdekes felhasználása az adatgyűjtés ami egyszerűen e hálózati megoldás replikációs képességére épít – arra, hogy a hozzákapcsolt szerverek trendjeit, adatbázisait, eseménynaplóit, stb. letölti a saját munkaterületére.

9

184


3.1.2.3. Web A VISION program többféle Web-technológiát is támogat. Segítségével Internetes/Intranetes hálózatokat is létrehozhatunk – akár kombinációban az előző pontban ismertetett egyéb hálózati technikákkal. Erre a kombinációra különben nagy szükség is van, hiszen egy tisztán Internet böngészőre alapuló rendszer eleve nem is képes ellátni olyan komplex feladatokat, amelyeket az előző pontokban ismertettünk, s amelyekre egyébként majd minden alkalmazásban szükség is mutatkozik. A Web-es hálózatok felépítését szemlélteti a következő ábra:

Web-szerver Internet Intranet

VISION szerver (ek) File-rendszer Képek Eseménynapló Trend Adatbázis

Web-kliensek Hálózat elve: - File-kezelés nincs, a Web-komponens (trendablak) a szervertől kapja adatait - Változások átvitele Web-szolgáltatásokkal (SOAP)

3.ábra - Web hálózat

A VISION Web-kliensek nem képesek szerver funkciók integrálására, és a szerver-kliens szerepek sem kombinálhatók. A Web-kliens nem képes kommunikálni külső eszközökkel, ő csupán egy megjelenítő, egy ablak, amit a világhálót használva a szerver irányába nyitunk. Ettől függetlenül adatokat persze közölhet a szerverrel, tehát kiadhatunk parancsokat, sőt a VISION esetében még az alkalmazás konfigurálására is lehetőségünk van. A Web-kliensnek rendkívül egyszerű a használata, hiszen semmilyen program telepítésére és konfigurálásra sincs szükség. Csupán az alkalmazás URL-jét (Universal Resource Locator) kell ismernünk és begépelnünk kedvenc internet-böngészőnkbe, pl. az Internet Explorer-be. A Web kliens a Web szerverhez kapcsolódik, magát a Web klienset pedig nem is kell konfigurálni, hiszen az alkalmazás honlapjára (startlapjára) kapcsolódva az automatikusan jön létre. A Web szerver konfigurációjától függ az, hogy a Web-kliens milyen módon fog kapcsolódni a VISION hálózati szerverekkel, és hogyan fog működik. Itt alapvetően kétféle megoldás Hálózati szolgáltatások

185

9

jöhet szóba: (1) aktív komponens letöltésére alapuló megoldás – ilyenkor a kép felrajzolása és animálása a Web-böngészőben történik és a VISION összes látványeleme (object fading, árnyék, megvilágás) is működik –, és (2) HTML-bázisú, “hagyományos” megjelenítés. Ez utóbbi a gyengébb képességű böngészők, pl. mobil-telefon, vagy PDA esetén használandó, amelyek nemhogy ActiveX-et, de legtöbbször még Java scripting-et sem nagyon támogatnak. Ezzel szemben az aktív komponens használata a Microsoft-os (pl. IE) és Netscape böngészők (Linux alatt: Wine) esetén optimális. Egy mindössze párszáz kilobyte méretű fájl letöltésére van szükség (egyszer), amit az internet böngésző automatikusan (felhasználói megerősítésre) végez el. Ettől kezdve olyan színvonalú megjelenítésben van részünk, mintha csak a távoli szerver gép előtt ülnénk. Az aktív komponensre alapuló Web-es megjelenítés – szolgáltatásait és sebességét tekintve – a párját ritkítja. A Web-es megjelenítőket az ún. telepítés nélküli megjelnítők között szokták emlegetni, hiszen a böngésző ma már az oprációs rendszernek része. Ez a kategorizálás azonban megtészvesztő, hiszen a VISION példája is azt mutatja, hogy hagyományos hálózati környezetben is megvalósítható a “telepítés-nélküliség”. Mivel a VISION alkalmazói fájlrendszer elemei dokumentum vezéreltek, egy képre, vagy az alkalmazás projekt-fájljára kattintva elindul és betöltődik a társított (nem feltétlenül az adott gépre, hanem egy hálózati drive-ra telepített) alkalmazás is. Ráadásul ilyenkor a hálózati szerver-kliens kapcsolatok is automatikusan felépülnek, vagyis önmagában a szerver-kliens alapú megjelenítéshez nem szükséges feltelepítenünk semmit. Még az Internet Explorer-t sem.

3.2. Összetett hálózatok kialakításának szempontjai Ahogy az előzőekben többször is utaltunk rá, nagy rendszerekben általában kombinált hálózati megoldások alkalmazásával érhető el az optimális hatás. Egy diszpécser központ jellemzően fix telepítésű kliens- és szerver számítógépekből áll. E rendszereknek általában önnállóan és függetlenül kell működniük a külvilágtól, kialakításukra pedig a VISION hálózat konfigurálása a legmegfelelőbb. Előfordulhat azonban, hogy a meglévő rendszer adatait egy felsőbb üzemirányítási, vagy szervíz szinten szeretnénk megjeleníteni, vagy más alrendszerek, telepek felé továbbítani. Általában ilyenkor kell megfontolásokat tennünk, hogy tranzakció-optimalizált, Web-es, vagy továbbra is VISION-ös hálózatot alkalmazunk-e. Az előnyöket és a hátrányokat az 1. pontban részletesen ismertettük, itt csupán arra szeretenénk felhívni a figyelmet, hogy pont ezeknek a kiegészítő hálózatoknak a konfigurálásával jönnek létre a korábban ismertetett “kombinációk”. Például a diszpécseri szerver egy másik hálózati csomóponton klienssé válhat a vele távoli kapcsolatban álló másik alrendszerrel való kommunikáció során, vagy éppen szerverré, amennyiben a másik alrendszer felé adatokat szolgáltat. Az egymással azonos szintet elfoglaló alrendszerek közötti hálózati kommunikációra talán a DFS tranzakció-optimalizált hálózat a legmegfelelőbb, mivel ez terheli legkevésbé a médiumot (pl. bérelt vonalat, telefonos összeköttetést). A felsőbb üzemirányítási szintek, vagy a karbantartás, szervizelés számára pedig a Web szolgáltatás tűnik a legmegfelelőbbnek, mivel ez a legrugalmasabb és talán a legkényelmesebb megoldás is – amellett, hogy ezzel a módszerrel a világhálóra is kimehetünk. Azt azonban már meg kell fontolnunk, hogy mindezt milyen óvintézkedések mellett tesszük (adatvédelem); egyáltalán, milyen adatokat, képeket továbbítunk. Egyáltalán

186


9

nem biztos, hogy mindent meg akarunk jeleníteni, minden adathoz hozzá akarunk férni az Interneten keresztül. Az Internetes kapcsolat kialakításához szükség van még a Web szerver telepítésére is, ami a VISION hálózati rendszer intergráns része, tehát elvben bármely csomópontra feltelepíthető. Az a számítógép azonban, ami ennek a “hosting”-nak helyet biztosít, általában nem az a gép, ami egyébként a VISION szerver feladatait látja el (kommunkáció, trendkezelés, alarmkezelés). Hiszen ez lesz az a gép, amit az Internet felé kinyitunk, amire a megfelelő Internet-szervert (pl. IIS: Internet Information Services) is fell kell telepítenünk – esetleg tűzfalakkal, ISA szerverrel és más internet szolgáltatásokkal együtt. E programok pedig egészen más gépkapacitást és biztonsági kialakítást (pl. routert, tűzfalakat) igényelnek, mint egy “sima” VISION szerver. A legtöbb nagyvállatnál az Internet-es domain-ek ezért önálló számítógépek, amelyeket rendszergazdai felügyelettel, esetleg valamilyen külső Internet szolgáltatóval üzemeltetnek. A VISION szerver és a Web szerver szerepek tehát a legritkább esetben esnek egybe – világosan mutatva ezzel a kombinált hálózatkialakításra való alapvető igényt. A Web-es hálózatok kapcsán azt is meg kell említenünk, hogy az Internet böngésző nem képes arra a grafikai sebességre, mint a VISION saját megjelenítője – habár éppúgy működik rajta a kép- és objektum fading, valamint a metamorfózis, vagyis az összes effekt, ezzel önmagában is egyedi szolgáltatást nyújtva. Viszont nem hardware támogatással, hanem tisztán software-ből, ezért lassabban. A másik nagy különbség az átvitel sebesség-igénye. Természetes, hogy az ún. sebességoptimalizált VISION hálózat már azáltal is gyorsabb, hogy az adott esetben óriási trend, adatgyűjtés és alarm adatbázisok átvitelére nincs szükség, hiszen a VISION hálózat közvetlenül a szerver fájlrendszerét használja. A Web-kliens Internet böngészőjébe ellenben ezeket az adatokat is le kell tölteni, ami nagyméretű adatbázisok esetén időigényes lehet. A VISION most is mindent elkövet, hogy ezt a nyilvánvaló különbséget a Web és a VISION hálózat között minimalizálja. Egyrészt azzal, hogy csak az új adatokat továbbítja, ill. azokat, amelyek a konkrét képen látszanak, másrészt a különbségeket is tömöríti (ZIP-peli). Nagy rendszerek esetén mégis nagy a sebességkülönbség, hiszen az adatfrissítés eltarthat akár néhányszot tíz másodpercig is, miközben a sebesség-optimalizált hálózatban ez a várakozás nincs. A leglényegesebb különbséget mégis a vegyes hálózatok alapozzák meg. Tisztán Web-re épülő hálózatok esetén a társtelepi kapcsolatokat – amelyek alternatív szervereket és gatewayt igényelnek – csak speciális szerverek telepítésével valósíthatnánk meg, miközben ezeket a funkciókat a VISION alapból támogatja. Ne feledjük, hogy összevont alkalmazások esetén ezt projektenként lehet meghatározni, nem munkaállomásonként. Előfordulhat, hogy egy összevont (több projekt egyesítésével keletkező) alkalmazás valamelyik projektje szerver, mivel az adatai helyben keletkezik, a másik kliens, mivel az adatait egy távoli szerver gépből kapja, esetleg dinamikus (kapcsolt) kliens, mivel a kapcsolat iránya is változhat (ld. adatgyűjtő rendszerek). Ezek a fontos kombinációk egy internet böngészőben eleve nem lehetségesek, hiszen az IE soha nem lehet szerver. Végül az internet böngésző megbízhatósága sem mérhető egy Desktop alkalmazás robosztusságához – mégha le is számítjuk a támadhatóságot.


187

9

4. Hálózatkonfigurálás a hálózat-menedzserrel Egy rendkívül egyszerűen használható, különálló program segítségével lehet bekonfigurálni a hálózati szolgáltatásokat. A hálózatmenedzser tehát függetlenül fut az egyes alkalmazások projektjeitől, s persze önállóan, külön számítógépen is működhet (Web server). A program elindítható a start menüből a VISION X9 menücsoportból, vagy a hálózat konfigurálási képen a csomópontok varázslóból gombra kattintva:

A program elindításakor a következő képpel jelentkezik be:

9

Az adott pillanatban érvényes konfiguráció a kép bal oldalán, az intézőben látszik. Új csomópontokat egyszerűn a jobb egérgombra megjelenő popup menüből adhatunk a hálózatkezelőhöz. Ez a művelet egy varázsló használatát igényli.

188


Ez az első kép, amiből a csomópont előző fejezetekben részletezett tipusát (szerver v. kliens) és a hálózati szolgáltatás tipusát kell kiválasztani. A varázsló további pontjai e kiválasztástól függnek.

4.1. VISION hálózati szerver beállítása A szerver konfigurációja lesz a következő beállítandó kép. Minden csomópontnak önálló névvel kell rendelkezni. Ezenkívül – dokumentációs célból - adható egy részletesebb leírás is.

9

A ciklusidők megadásával az adatátvitel és a standby időciklust adhatjuk meg. Ez utóbbi él abban az esetben, ha a csomópontnak egyébként küldendője van a kliensek felé.


189

Megjegyezzük, hogy automatikus kliens ciklus beállítás esetén, ezt az időt használja a kliens csomópont is. Ezután jöhet a projektek hozzárendelése:

Egy csomóponthoz több projekt is hozzáadható, tetszés szerinti számban. Az egyes projekteken belül pedig az átvinni kívánt XDO adatbázisok és egyéb, elsősorban a kompatibilitást szolgáló fájlok adhatók meg, olyanok, mint a VISION korábbi változataiban megismert erőforrás fájlok (rco). Megjegyezzük, hogy az új rendszerben a nyelvek LDB (Language Database) fájlokban vannak tárolva, amelyet egy XLS űrlapon állíthatunk elő. Ha a befejezés gombra kattintunk, a konfigurációnak vége és az új csomópont – annak rendje és módja szerint – megjelenik az intézőben: Íme

4.2. VISION hálózati kliens beállítása A hálózati kliensnél kell megadni a szerver elérésének a módját. Fontos tudni, hogy az új rendszerben nem kell már az egyes klienseket önálló sorszámmal ellátni (NumVision), habár e lehetőség – kompatibilis okoból – továbbra is fennáll. Csupán arra van szükség, hogy a szervernek megadjuk az IP címét, vagy – amennyiben a rendszer látókörében van névszolgáltató (DNS) – a számítógép nevét. Lehetőség van emellett automatikus szerver választásra is, de a fix telepítésű rendszerek esetében ez nem annyira praktikus, mert ezáltal előfordulhat, hogy egy kliens számítógép a tényleges szerver helyett a szervízelés céljára üzembe állított notebookunkra csatlakozzon.

190


9

A ciklusidők itt ugyanazt a célt szolgálják, mint a szerver esetében, és itt látható az automatikus időátvételre szolgáló checkbox is, amiről az előző fejezetben szóltunk. A továbbiakban felkínált projekt-választó rész is hasonló a szerverhez, annyi csupán a különbség, hogy fájl (adatbázis) megadással itt nem kell bíbelődnünk, mivel a szerver beállításától függ, hogy a kliens milyen adatokhoz férhet hozzá. Ugyanakkor lehetőség van arra, hogy a projekteknek egy, a szervertől eltérő halmazát adjuk meg a kliens számára. Triviális példa az az eset, ha a kliens a szerver által kezeltek közül csak egy projekthez fér hozzá; de bármilyen más részhalmaz is hozzárendelhető.

9


191

A projektről részletes információt kaphatunk, ha a projekt sorára duplán kattintunk:

Itt egyúttal megváltoztathatjuk a projekt bejelentkező képét is – külön a szerver és külön a kliens esetében.

4.3. DFS hálzóati szerver beállítása A VISION előző változataiból megismert DFS beállítások sem nagyon különböznek az eddigiektől. A DFS szerver nevének és leírásának a megadására szolgáló panel pl. pont ugyanaz, mint a VISION hálózati szerver esetében:

9

A projektek kijelölésére szolgáló ablak nem kevésbé:

192


DFS használata esetén azt is meg kell mondanunk a programnak, hogy a trendeket, az adatgyűjtést és az alarmokat frissíteni akarjuk-e a kliensen. Alaphelyzetben ezek átvitelére nem kerül sor, csak akkor, ha az ablak alsó felében látható fájl-listájhoz hozzáadjuk a következőket: $TREND $ACQ $ALARM

- Trendek átvitele - Adatgyűjtés átvitele - Alarmok átvitele

Azért így kell megadni, mert ezen fájlok neve változhat és a rendszer az átvitelüket egyébként is másképp kezeli, mint a többiét. A trendek, az adatgyűjtés és az alarmok különbségeinek az átvitele ui. speciális megoldást kíván, hogy mindig csak az új adatok továbbítására kerüljön sor (replikáció). Megjegyezzük, hogy erre VISION hálózat esetén azért nincs szükség, mivel a trendeket és az alarmokat a rendszer egyaránt a szerveren keresi. Viszont szükség lehet rá Web használatakor is, amennyiben a trend, adatgyűjtés és esemény naplózást is használni kívánjuk a Web-en. Abban az estben, ha a nyelvi adatbázist is használni kívánjuk, a LANGUAGE.LDB fájl átküldésére van szükség, annak XLS forrására nem. Ezt az LDB adatbázist is hozzá kell teha;t adni az átküldendő fájlok listájához. A teljesség kedvéért megjegyezzük, hogy a dBase típusú adatbázisok replikációját is intelligensen kezeli a program. Ahogy a $TREND, $ACQ és $ALARM esetén, úgy a dBase fájloknak is csak a különbségeit továbbítja a program, ezáltal gyorsítva a letöltést. A dBase fájlokat megadhatjuk akár ebben a formában is: *.DBF.

Innen kezdve már új menüpontokkal találkozunk, amit korábban “telefonos hálózat beállítása” menüben lehetett megtalálni. Most ugyanazok az információk új elrendezésben jelennek meg:


193

9

Abban az esetben, ha itt Socket helyett mondjuk modem-et választunk, a következő képen annak paramétereit is be kell állítanunk:

9

Amennyiben a “direkt” kapcsolat mellett döntöttünk, a soros vonal kiválasztása és paraméterezése az elvégzendő feladat:

194


4.4. DFS hálózati kliens beállíása A DFS hálózati kliens pontosan ugyanazok a lépéseket tartalmazza, mint a szerver, csak a csomópont funkciója lesz eltérő.

9


195

4.5. Web szerver beállítása A Web szerver beállítása igényli a legtöbb megfontolást. Az alább látható legelső képen már nemcsak a megszokott csomópont nevet, ciklusidőket és leírást kell beállítanunk, hanem a Web-kiszolgáló ún. virtuális könyvtárát és alkalmazásunk internetes/intranetes elérési útját is, amit konvencionálisan URL-nek (Universal Resource Locator) neveznek.

A virtuális könyvtár helyi elérési útja és az URL valójában ugyanazt a fizikai helyet azonosítja, csak ez utóbbi az internetes HTTP kiszolgálón keresztül. A VISION program feltelepítésével keletkező Web könyvtár (a program telepítési könyvtára alatt található) egy lehetséges virtuális könyvtárnak ad helyet. Ebben megtalálható az összes szükséges közzétételi komponens (kezdőlap, hibaoldalak, CGI/ISAPI Web-szerverek, stb.) A virtuális könyvtárat előzetesen számítógépünk Web-kiszolgálójával, pl. az Internet Information Services programmal be kell állítanunk. Itt adunk nevet, pontosabban álnevet (alias) a virtuális könyvtárunknak, ami azután az URL-ben szerepel. A fenti példában ez a vision. Az URL-ben úgy hivatkozunk a virtuális könyvtárra, hogy a http://, majd az IP cím (domain név) és egy per-jel után beírjuk a virtuális könyvtár álnevét, amit az IIS-ben megadtunk. Például: http://localhost/vision http://192.168.2.1/vision http://www.provicon.net/vision

Virtuális könyvtár: vision

A virtuális könyvtár (vision) beállítása az IIS programmal a következőképpen történik (itt részletekbe nem bocsájtkozunk, a szükséges tudnivaló megtalálható a Microsoft operációs rendszerének a leírásában):

196


9

1. lépés: IIS (Internet Information Services) program elindítása Vezérlőpult B Felügyeleti eszközök B Internet Information Services 2. lépés: új virtuális könyvtár előállítása:

3. lépés: virtuális könyvtár nevének (álnevének) megadása:

9


197

4. lépés: virtuális könyvtár fizikai helyének a megadása:

5. lépés: hozzáférési engedélyek megadása:

9

Az ISAPI / CGI parancsfájlok engedélyezése is szükséges, mert a beállítástól függően a program ezt is igényelheti. Ezzel az új virtuális könyvtárat előállítottuk, de még nem vagyunk teljesen kész, mert mint látni fogjuk, a dokumentumok megadása is szükséges. Kérdezzük le ezért a jobb egérgomb menüvel a Webhely tulajdonságait.

198


Végeredményben a virtuális könyvtár helyi elérési útját (a példában c:\Program Files\Vision\Web) két helyen kellett megadnunk: egyszer az IIS-ben (ld. fent), másrészt a VISION-ben (ld. fejezet elejét). Azonban honlapunk engedélyezett dokumentumait is meg kell még adnunk a Dokumentumok fülnél. Ezek lehetnek a VISION előre gyártott példányai (Xsimple.html, Xvision.html), vagy bármilyen általunk készített html, aspx dokumentum. Vigyázat, a virtuális könyvtár létrehozásakor a Dokumentumok rosszul vannak inicializálva, mivel hiányzik belőlük az Xsimple.html, vagy az Xart.html. Ezért ezt még módosítanunk kell. Ha a kezdő oldalt nem írjuk be ide, rejtélyes hibaüzeneteket fogunk kapni a böngészőtől (mintha nem lenne hozzáférési jogunk a saját oldalunkhoz), pedig csak a kezdőoldal hiányzik.

9

A kövekező képernyő már ismerős, a projektek és az átküldendő XDO adatbázisok, ill. egyéb fájlok adatai adhatók meg itt. (Természetesen interneten is szükség van a működtető adatbázis átvitelére, ami SOAP Webszolgáltatást alkalmazva XML formátumban, közvetlen socket esetetén, pedig XDO formátumban történik). Ahogy a DFS hálózatnál láttuk, szükség lehet a $TREND, $ACQ és $ALARM megadására, ha ezeket az adatokat a Web-en listázni kívánjuk.


199

A következő ablakban a tömörítési módot határozzuk meg:

9

A két tömörítési mód közötti különbséget a kép tartalmazza. Ha más szempont nincs, hagyjuk a választást RLE-n (ez gyors és kellően tömör). Ezzel el is érkeztünk az utolsó párbeszédpanelhez, az ún. közzétételi (deployment) adatok beállításához. A közzététel az interneten/intraneten való közzétételt jelenti, s valójában nem egyéb, mint a kezdő HTML oldal előállítása, a megfelelő fájloknak a virtuális könyvtárba való átmásolása. Persze nemcsak egyszerű másolásról van itt szó, hiszen pl. a kezdőlapunk (Xsimple.html) belsejében is ki kell cserélni a hivatkozásokat, az előző menüpontban megadott URL-re, hogy a képeinken megmutatott bitmap-ek, aminációk és egyéb linkek (pl. képváltás), az interneten is láthatók, hozzáférhetők legyenek.

200


Ide kattintva másoljuk adatainkat a kezdőlapra (Xsimple.html)

Host, vagy domain – ált. ugyanaz az adat, mint amit az URL-ben is megadtunk!

A közzététel egy fontos részlete a bejelentkezés módjának a megadása. Itt kétféle módszer közül választhatunk: • •

User autentikáció (felhasználó szintű bejelentkezés) Specifikus autentikáció (domain szintű bejelentkezés)

Ez utóbbi tulajdonképpen az alkalmazásunk elé fűzött plusz védelem; hogy a VISION képeket egyáltalán valaki megnézhesse, a rajtuk felkínált szolgáltatásokhoz pedig hozzáférjen (pl. szerelvényeket indíthasson), ennek bejelenkezési kulcsszavát is itt, a Web-szerver közzétételének pillanatában kell megadnunk. Hatására stratlapunk az alábbi képpel fog elindulni (Internet Explorer-ben indítva):

9


201

Lehetőségünk van arra is, hogy a Web-alkalmazás ne kérjen semmilyen kulcsszót, hanem azonnal bejelentkezzen a VISION Web-szerverére. Erre szolgál az “automatikus kapcsolatfelvétel a szerverrel” opció. Emellett a felhasználó kiléptetése is automatizálható. Erre szolgál az időkorlátos kiléptetés opció, ahol másodopercben mondhatjuk meg, hogy a magára hagyott Web-alkalmazás mennyi idő elteltével lépjen ki a szerverből. Web-es környezetben ez rendkívül hasznos funkció. A továbbiakban választhatunk nyelvet (mely eltérhet az alkalmazás saját nyelvétől), felbontást (mely eltérhet az alkalmazás saját felbontásától – ld. PDA) és stílust. Ez utóbbira jelenleg kétféle lehetőség van: egy egyszerű (XSimple.html) és egy kissé cizelláltabb (XArt.html) konténer közül választhatunk, amely VISION alkalmazásunk keretéül szolgál. Természetesen csinálhatunk magunknak saját konténereket is úgyszólván bármilyen HTML szerkesztővel. Végül azt kell még eldöntenünk, hogy a VISION képek hozzáférhetők legyenek-e különböző URL-ek alatt. Ha ezt választjuk, minden egyes VISION kép önálló http linket kap, melynek felépítése valami ilyesmi lesz: http://localhost/vision/getvision.dll/image?name=fokep Ez a link pl. a fokep-nevű képfájlra fog váltani. Természetesen a HTTP után a korrekt URL-t kell megadni. A GETVISION.DLL nevű program pedig nem egyéb, mint a VISION Webszerverének az a része, amelyik a szolgáltatások dinamikus közzétételéért felelős (képek, trendek, alarmok, adatbázisok). Ez egy ISAPI Web-szerver (a GETVISION.EXE pedig annak CGI változata) – nem tévesztendő össze a VISION Web-szerverével, amelyet épp konfigurálunk. Általában az a célszerű, ha az alkalmazások képei önálló linkkel rendelkeznek. Azt azonban tudnunk kell, hogy önmagában a képek váltogatásához ez nem szükséges, hiszen a képtartalom éppúgy XDO (ill. XML) formátumban kerül továbbításra, mint az adatok. Ezért a képváltás a dinamikus adatcseréhez hasonlóan, “csendben” is végrehajtható, mintha csak egy számkijelző értéke változna meg. Erre a beállításra a következő esetekben lehet szükség: 1. Szeretnénk kihasználni a VISION látványos képáttérési módszereit (Explode, Zoom, Fade, stb.). A Web böngészők nem rendelkeznek ezekkel a képességekkel, melyek az igényesebb VISION alkalmazásokban már oly természetesek. 2. Egy HTML oldalon több, független VISION képet, ill. projektet is meg akarunk mutatni. Ebben az esetben a böngésző nem tudná eldönteni, hogy hová kell navigálni, hiszen többen, többféle dolgot szeretnének. 3. Végül, de nem utolsó sorban, szeretnénk gyorsítani a képváltásokat, és mentesíteni alkalmazásunkat és a Web-szervert a képváltással járó felesleges tranzakcióktól. Ezek alapján úgy tűnik, nemigen van értelme a képek önálló URL-hez való hozzárendelésének; mivel az látszólag rengeteg hátránnyal jár. Ám abban az esetben, ha a képeket nem rendeljük külön URL-hez, az előző, a vissza és a home gombok sem működnek a böngészőn, hiszen valójában (böngésző-szintű) képváltás sem történt. De nem készíthetünk praktikus parancsikonokat sem, amelyek közvetlenül egy-egy képre ugranának. Az előnyök és a hátrányok mérlegelése alapján kell döntenünk a “képek különböző URL alatt való megjelenítése” dolgában.

202


9

5. Tűzfal beállítása Az előző fejezetben ismertetett VISION hálózatok és a DFS-Socket hálózatok TCP/IP alapon kommunikálnak, ill. Web szerver esetén HTTP és TCP/IP alapon. Ezeket a szolgáltatásokat azonban tűzfal védheti. Nézzük meg ezért a tűzfal szükséges beállításait. A következőkben az XP saját tűzfalára szorítkozunk, azonban más tűzfalak is hasonló fogalmakkal operálnak. A VISION Network Management System engedélyezése a legelső lépés. Ez a VISNET.EXE program, amiről az egész összetett hálózatok fejezet szól. Amennyiben az XP tűzfala be van kapcsolva, az első szolgáltatás elindításakor az op.rendszer megkérdezi, hogy feloldhatja-e a programra vonatkozó tiltást:

Még egyszer: ez az üzenet csak akkor jelenik meg, amikor az első TCP/IP konfigurációt elindítjuk (ezt ismertetjük a hálózat-menedzser használata című, következő fejezetben). és természetesen a Tiltás feloldása gombbal kell rá válaszolni. Ennek hatására a Windows felveszi a “VISION: Network Management System” programot a tűzfal ún. Kivétel listájába, ami azt jelenti, hogy a program felé irányuló külső kéréseket az op.rendszer ezentúl korlátozás nélkül elfogadja.

9

A Windows tűzfalában mindez így jelenik meg:


203

Alternatív megoldásként fel lehet venni két engedélyezett portot (Port hozzáadása), az 1600at és az 1601-et: 1600-as port

1601-es port

Az 1600-as port a bekopogtatás portja, itt jelentkezik be minden új kliens, az 1601-es pedig a kiszolgálásé. De természetesen a szerver szintű engedélyezés a kényelmesebb, hiszen azt a tűzfal automatikusan elvégzi. Tehát teljesen egyenértékű beállítást ad, ha csak a VISION Network Management System van engedélyezve és a VISION Web Knocker, valamint a VISION Web Services nem, vagy fordítva. Nem vagyunk még teljesen kész, mert a kiszolgáltási csoportot is engedélyezni kell a Speciális fülnél:

majd:

9

Ezzel a tűzfallal felszerelt XP Webkiszolgálóvá válik, ami a 80-as porton érkező HTTP kéréseket fogadja és a VISNET.EXE program felé az 1600-as és 1601-es porton továbbítja. Persze ki lehet kapcsolni a tűzfalat en bloc, csak az nem javasolt.

204


6. Hálózat-menedzser használata A következőkben a hálózatmenedzser további parancsait vesszük sorra, azt, hogyan kell a konfigurációt lementeni, visszaolvasni, ill. a szolgáltatásokat elindítani, leállítani.

6.1. Csatlakozás egy másik számítógépen futó VISION szerverhez Gyakori eset, hogy a VISION szerver és a Web szerver nem ugyanazon a számítógépen fut, hiszen az internetre nem szívesen teszünk ki hálózati szervereket. Minimum egy routert érdemes a szerver és az internet/intranet hálózat közé iktatni. Ezenkívül a VISION szerver gyakran maga is diszpécser állomás, amíg a Web szerver szinte soha. Ez utóbbi gépnek nincs akkora kapacitás-iténye sem, mint a VISION szervernek. Továbbá a Web szervereket gyakran más szakemberek felügyelik (rendszergazda), mint az ipari rendszer szervereit és külön helységben is tárolják őket. Emiatt szükség lehet a Web szerver és a VISION szerver közötti kapcsolat kialakítására. Mindez a legyegyszerűbben a Beállítások menüpont alatt található Projekt direktori beállításával eszközölhető. Egyszerűen arról van szó, hogy a konfigurált projekteket és annak fájljait a rendszer nem a saját gépen keresi, hanem egy távoli szerver gépen és onnan is továbbítja majd a Web szerverre csatlakozó kliensek felé. Tehát a Web szerver adatfájlokat nem tárol, csak továbbít, s mint ilyen, egyfajta gateway-ként funkcionál. Ezt az üzemmódot szemlélteti a következő ábra: VISION kliensek

Lokális hálózat

VISION szerver

Web szerver

Web kliens (IE)

9

Trendek Eseménynaplók Gyűjtött adatok Adatbázisok Projektek, képek és egyéb rendszerkomponensek

Internet Intranet


205

Miután a projekt könyvtárat megváltoztattuk, a már ismertetett módon bekonfigurálhatjuk a szerverünket. Hangsúlyozzuk, hogy a konfigurációt meg kell, hogy előzze a projekt direktori kiválasztása, amely paramétert a rendszer majd a megfelelő .net konfigurációs fájlban el is tárol. Ebből következik, hogy ahány hálózati konfiguráció, annyi különböző VISION szerver is megadható. Magának a konfigurációs .net fájlnak a tárolási helye azonban már lehet a Web szerver is.

6.2. Indítás, leállítás A legfontosabb természetesen magának a szolgáltatásnak az elindítása:

Ide kattintva indíthatjuk el a hálózati szolgáltatást

Kibejelentkezések naplója

A szolgáltatás elindítása előtt természetesen be kell olvasni annak konfigurációs fájlját. Ha ezt automatizálni akarjuk, a VISNET.EXE programot (ez a hálózat-menedzser program neve) egy parancsikonnal kell elindítanunk, aminek parancssorában megadhatjuk a kívánt konfigurációs fájl teljes nevét. Példa parancssorra: c:\Program Files\Bin\Visnet.exe c:\Program Files\Vision\Settings\Visnet.net Így a program nemcsak betölti, de aktivizálja is a konfigurációt, vagyis az indítóikon egyszerűen az indípultba húzható. Abban az esetben, ha vannak aktív kapcsolatok (amint az ábrán is látszik) megjelennek grafikusan. A kép alján olvasható naplófájl pedig a bejelentkezéseket, kijelentkezéseket, elutasításokat és a hibákat gyűjti. A leállítás értelemszerűen a STOP gombbal történik (vagy egyszerűen kilépéssel):

206


9

6.3. Mentés A konfigurációt NET kiterjesztésű fájlokban tároljuk, ami egy szabványos Windows INI fájl. Amennyiben a hálózat menedzsert a VISION-ből indítjuk, a konfigurációs fájl nevét is a VISION adja (hálózat konfiguráció), ellenkező esetben nekünk kell megadni és a Konfiguráció mentése másként opcióval lementeni. A konfigurációs fájlok tárolási helye, amennyiben az nem a projekthez kötődik, a VISION telepítési könyvtára alatt található Settings direktori. Egyébként a projekt könyvtár. A konfigurációs fájlra mutat példát a következő ábra: [Config] PrjPrefix= ConfigCount=1 [Cnf1] Name=Features Web Description=Features Demo Web Server Host=vision Password=vision StartPage=Xsimple.html URL=http://vision/vision VirtualDir=e:\vision\web Active=1 Server=1 Web=1 DFS=0 AutoClient=0 AutoServerSelect=0 TotalSuperProject=1 ZipSuperProject=0 BasePort=1600 SlowCycle=5000 Cycle=100 DFSMode=Modem DFSDirection=Duplex DFSDefaultDial= DFSTimeSync=0 Baudrate=38400 Channel=COM1 DialPrefix=ATDT InitString=ATE0V1S0=1 ProjectCount=1 [Cnf1_Prj1] ID=2200478339 StartImage=Fokep File=Features\Feature.vpr Files=huser.rco; global.xdo; library.xdo

Ezt a fájlt persze kézzel is kitölthetjük, módosíthatjuk – különösen nagyszámú projekt vagy egyszerűbb módosítások esetén. Ilyenkor a paraméterek értelmét célszerű a hálózat menedzserben végrehajtott módosítással, beállítással ellenőrizni. A legfontosabb szekciók struktúrája a következő: [Config] [Cnf1] <1-es konfiguráció paraméterei, projektek száma> [Cnf1_Prj1] <1-es konfiguráció 1-es projekt beállításai> [Cnf1_Prj2] <1-es konfiguráció 2-es projekt beállításai> … [Cnf2] <2-es konfiguráció paraméterei, projektek száma > [Cnf2_Prj1] <2-es konfiguráció 1-es projekt beállításai> [Cnf2_Prj2] <2-es konfiguráció 2-es projekt beállításai> … stb.

A konfiurációs fájlon kívül lementhető még a hálózat menedzser naplója és a kommunikáció üzenetei. Ez utóbbi hibakeresés esetén lehet szükséges.


207

9

7. Összetett hálózatok kezelése programból A 3-ik fejezetben ismertetett és a 4-ik, 5-ik fejezetekben konfigurált összetett hálózatokat a VISION programból, tehát alkalmazásból is aktiválhatjuk. Erre a dinamikusan felépített hálózatok esetén van szükség, vagyis akkor, amikor a hálózat-menedzserrel való statikus elindítás nem lehetséges. Előfordulhat, hogy a kapcsolatfelvételre egy ábrán elhelyezett gombbal adunk parancsot, miután kiválasztottuk, begépeltük a telefonszámot / IP-címet, vagy hiba hatására kell felhívnunk egy távfelügyeleti állomást, ahol – a hálózati kapcsolatfelvételt követően – rá is kell váltanunk a hibát okozó alrendszer képére.

Az összetett dinamikus hálózat kezelés VISION parancsai a következők: Parancs NetListen NetClose NetConnect

NetDisconnect NetClear NetState

208

Paraméterek, leírás Szerver típusú hálózati aktivitás elindítása Kapcsolatok bontása (ha vannak), majd az adott szerver hálózati aktivitás leállítása ,{,<paraméter>{,}} Kapcsolat felépítése kliens hálózati csomópontból opcionálisan megadott telefonszám, IP-cím, domain vagy hálózati név irányába. Ez a kapcsolati string. A további paramétereknek modemes kapcsolatfelvétel esetén van szerepe, így kérhető a callback-ben megadott telefonszámra visszahívás. Kapcsolat bontása kliens hálózati csomópontból Hibák törlése és kapcsolat alaphelyzetbe állítása – egyfajta reszet ,<status>,, Hálózati csomópont állapotának a lekérdezése. A hívás a status byte változóban, vagy többállapotú változóban adja vissza a hálózati csomópont állapotát, a nettext-ben, valamint a netnum-ban pedig az aktuális állapothoz kapcsolódó szöveges és numerikus adatokat (ezeket a képernyőre írva a felhasználót informálhatjuk, hogy épp milyen adat frissítése zajlik és az hol tart). Részleteiben: <status>: 0 – csomópont idle 1 – kapcsolatfelvétel (tárcsázás, connecting) 2 – online állapot (kapcsolatban) 3 – hiba kapcsolatfelvétel közben 4 – hálózatfigyelés (listening) : épp továbbított fájl neve, vagy NETSEND / NETRECV attól függően, hogy épp ad vagy vesz a program a hálózaton : Épp továbbított adat aktuális mérete (byte szám, ill. hossz) Hálózati szolgáltatások

9

NetSetModem

NetSendFile

,,<ellenőrzési_ciklusidő> Ezzel a hívással a modemet paraméterezhetjük parancsból. A csendes üzemmód a kapcsolatfelvételi sistergést némítja el, az ellenőrzési ciklusidő pedig azt határozza meg, hogy milyen gyakran küldjük ki az AT parancsot – a program ezzel teszteli, hogy él-e a modem, alapértéke = 5 másodperc , Ezzel a paranccsal fájlokat küldhetünk át a network_node-dal meghatározott hálózati asszociáción az ellenoldali számítógép felé.

Az összetett dinamikus hálózat kezelés VISION függvényei a következők: Függvény Értéke NetConnectCount Integer NetConnectName

String

NetConnectAct

Bool

NetReady

Bool

NetProject

Integer

Paraméterek, leírás Az összes aktív dinamikus csomópont számának a lekérdezése Aktív kapcsolati nevek lekérdezése 1-től a NetConnectCount által megadott aktuális aktív csomópont számig Adott hálózati csomópont aktivitásának a lekérdezése (true = aktív). Például a képernyőn ettől függően szeretnénk színezni a távoli eszközt reprezentáló szimbólumot A kapcsolatfelvételt követően akkor lesz true ennek a függvénynek az értéke, ha a fájlszinkronizáció véget ért. Emlékezzünk, hogy a tranzakció-optimalizált hálózatok egy adatbázis replikációval kezdik a működésüket, ami az adatmennyiségtől függően eltarthat pár másodpercig, sőt pár percig is. Ezalatt a NetReady = false Az adott aktív csomóponton érvényes projektek számát adja vissza

ahol :

A hálózat-menedzserben megadott hálózati csomópont név

Látható hát, hogy a rendszer egységes parancsfelületet biztosít a dinamikus hálózatok kezeléséhez, amelyben a hálózati csomópontot névvel azonosítja. Jószerivel csak azt kell tudnunk, hogy az illető csomópont szerver, vagy kliens, mivel a parancsok egy része csak szerverre (NetListen, NetClose), más része csak kliensre (NetConnect, NetDisconnect) hatásos. Vannak ezenkívül kimondottan modem kezeléssel kapcsolatos speciális parancsaink. De az már nem számít, hogy a csomópont egyébként VISION, DFS vagy Web-es hálózati csomópont-e. A Web-es hálózati kliensek esete tér el egyedül a fentiektől, hiszen ezeket a klienseket nem VISION-ből, hanem egy Internet Browser-ből indítjuk. Ezért nem is írtunk a Web-kliens konfigurálásáról. Habár lehet ilyen csomópontot is készíteni, a Web klienseket nem így kezeljük.


209

9

7.1. Példák hálózati parancsokra Tegyük fel, hogy egy távfelügyeleti rendszert konfigurálunk, ami a projektünk feladata alapján TFR (TávFelügyeleti Rendszer) nevet kapott. Annak érdekében, hogy ne kelljen külön szerver és kliens konfigurációt őriznünk (és arra emlékezni, hogy mikor melyiket kell betölteni), egyetlen konfigurációt készítünk csupán, és abban külön létrehozzuk a szerver és külön a kliens csomópontot:

De csak az egyiket indítjuk el: a szerveren a szerver_TFR-t, a kliensen pedig a kliens_TFR-t. Tipikus parancsok: Szerver odal

Kliens oldal

NetListen “szerver_TFR” NetClear “szerver_TFR“

NetConnect “kliens_TFR”,“192.168.2.12“ NetDisconnect “kliens_TFR“

Természetesen annak feltételét, hogy mikor melyik parancsot kell kiadni, meg kell konstruálnunk. Pl. a NetConnect parancsot egy kapcsolatfévételi nyomógomb kattintás eseményéhez rendelhetjük, a NetDisconnectet pedig egy kapcsolat bontási nyomógomb kattintás eseményéhez:

9

De éppúgy beírható egy adott alarmcsoport bekövetkezés eseményéhez, vagy egyszerűen a ciklikus programba egy adott IF THEN szekvencia után. Az is megoldaható, hogy a kiszolgáló programból se kelljen több példányt készíteni. Erre használható a NumVision függvény, ami az egyszerű hálózati konfigurációnál állítandó be. Amennyiben ez 0, az eszközünk szerver, egyébként kliens, de lehetne persze fordítva is. A program pedig, ami a NumVision szerint tesz különbséget: if NumVision=0 then NetListen… else NetConnect… fi

210


Az XVAL programozási nyelv alapjai Tartalomjegyzék: 1. Bevezetés............................................................................................................................ 212 2. Az XDSL nyelv alapjai ...................................................................................................... 213 2.1. Egységes szintaktika ................................................................................................... 213 2.2. Struktúrált deklarációk ................................................................................................ 214 2.3. Halmazok .................................................................................................................... 215 2.4. Egymásba ágyazott struktúrák .................................................................................... 216 2.5. Hova tovább ?.............................................................................................................. 218 2.6. Eltérések más magas szintű nyelvektől....................................................................... 218 3. az XVAL programozási nyelv............................................................................................ 219 3.1. Változó deklaráció....................................................................................................... 222


10

VISION X programozás

211

1. Bevezetés Ebben a fejezetben azon programozók számára adunk információkat, akiket az XVAL (Extensible Vision Application Language) nyelv belső felépítése és háttere is érdekel, ill. saját struktúrákat szeretnének létrehozni, s ezért szeretnék megérteni a felhasználói program könyvtárelemeit és azok összefüggéseit. Ehhez sajnos olyan fogalmakkal kell operálnunk, amelyek egyetlen más programozási nyelvben sem használatosak (pl. kompozíció), tekintettel az XSDL (Extensible Structure Declaration Language) nyelv és a benne foglalt elméleti megoldások eredetiségére. Ugyanakkor a programozói előismeretek sem nélkülözhetők, mivel az alapelvek hamar elvezetnek bennünket más magas szintű programozási nyelvekből ismert fogalmakhoz, a tipusokhoz, változókhoz, struktúrákhoz, objektumokhoz, tulajdonságokhoz, metódusokhoz, stb.. Az XSDL önálló, leíró nyelv, amely egyaránt lehet XML (Extensible Makrup Language) és hagyomásos programozási nyelvekhez hasonló szintaktikájú (Pascal, Visual Basic, C, stb.) – az implementációs környezettől függően. Ahogy az XML, az XDSL is egymásba ágyazott struktúrák rendszerével írja le a feladatokat. Az XML azonban rendkívül áttekinthetetlen, olvashatatlan szövegfájlokat eredményez, ha bonyolult rendszereket írunk le vele. Az XSDL ezzel szemben jól olvasható, más magas szintű programozási rendszerekből ismert megoldásokat használ, s közben az XML nyújtotta flexibilitást, a magasabb szintű struktúrák létrehozását is támogatja. Hogy ez a VISION esetében pontosan mit is jelent, hamarosan kiderül. Ami az XSDL és a XVAL összehasonlítását illeti, sok hasonlóságot láthatunk azzal a lényegi különbséggel, hogy az XSDL nem határozza meg a rendszer alaptipusait, objektumait, de még a struktúrákat sem, szemben a XVAL-lal, ahol nagyszámú előre definiált függvény, taszktipus, objektum, és változótipus (integers, discretes, stb.) létezik. Az XSDL néhány alaptipust tartalmaz csupán és erre alapozva, segítségével létrehozhatunk tetszőleges objektumstruktúrákat, változótipusokat. Általánossága miatt az XSDL nem is használható programozási nyelvként (ahogy az XML sem), csak valamilyen implementációs környezetbe ágyazva, mint például az XVAL. Az XVAL nyelv tehát az XSDL leíró nyelv egy lehetséges implementációja. Azért célszerű megismerkedni vele, mert az XSDL szolgáltatásokat felhasználva rendkívül érdekes bővítéseket és kiegészítéseket készíthetünk az XVAL nyelvű programjainkhoz. Ugyanis az XSDL nemcsak arra alkalmas, hogy segitségével leírjuk az objektumaink viselkedését és elkészítsük az alkalmazói programunkat, hanem magának a projektnek a komponenseit is e nyelv segítségével hozzuk létre, sőt, a projekt osztályokat és a rendszer konfigurációs állományokat is. Pontosan az XSDL szolgáltatásainak köszönhető, hogy a rendszer összes magas szintű komponense (formok, adatbázisok, táblák, kommunikációs struktúrák, unitok, stb.) is mind ugyanazon a nyelven fogalmazódjanak meg, s végül csupán egyetlen fordítóprogramra legyen szükségünk. Ez az egyik pillére a nyelv eredetiségének. Ahogy említettük, az XSDL nyelv az általunk definiált alapelemekből vezeti le a nyelv összes többi elemét - még a parancsokat, sőt, a kulcsszavakat és a rekord-strukturákat is. Az XSDLben nincs IF-THEN-ELSE, nincsenek programhurkok, nincsenek cimkék. A nyelv csak a szintaktikát rögzíti és az elvet, amelyre építve létrehozhatók a programstruktúrák, így az IFTHEN-ELSE struktúra, vagy a FOR ciklus. Ebből adódódik az XSDL nyelv rendkívüli

212


10

variabilitása és sokrétűsége, amelynek csak egy szűk alkalmazása a folyamatmegjelenítő rendszerek témaköre. Ez az eredetiség másik fontos pillére. Ismerkedjünk most meg az elvekkel, részleteiben.

2. Az XDSL nyelv alapjai Az XSDL nyelv lényegét a struktúrált deklarációban lehet megragadni. Az XSDL minden sora, minden utasítása deklarációnak minősül - a végrehajtó programjaink is. Az XSDL nyelv nem tesz különbséget adat és program között, annak értelmezése teljes egészében az implementációs környezetre van bízva. Ezért lehet programot írni a változók belsejébe, változót a programok belsejébe, vagy programot a programok belsejébe. Az adatoknak és a programoknak ez az újfajta megközelítése egységes szintaktika kialakításához vezetett.

2.1. Egységes szintaktika Hogy megértsük a nyelv lényegét, nézzük a következő deklarációt. Tételezzük fel, hogy az integer előzetesen definiált numerikus tipus. (A deklarátum nevét a következőkben pirossal, a tipust zölddel, az értékhozzárendelést kékkel jelöljük.) I: integer

'deklaráció kezdeti érték megadás nélkül

I: integer 0

'deklaráció kezdeti érték megadással, kezdeti értek = 0

vagy A deklarált objektumok értékadás révén kapnak (új) értéket a programból: I = 12 Az XSDL nyelv lehetővé teszi, hogy adatstruktúrákat hozzunk létre. A struktúra deklaráció mikéntjét később ismertetjük, most csak annyit tételezzünk fel, hogy az integer tipusnak ezúttal három tagja, más szóval mezője van és mindhárom numerikus tipusú. Így a deklaráció a következőképpen módosul: I: integer

'deklaráció kezdeti érték megadás nélkül

I: integer 1,2,3

'deklaráció kezdeti érték megadással, kezdeti értékek:

vagy 1,2,3 Az értékadás pedig egy felsorolással lehetséges: I = 12,23,34 Legyen most az adattipus a BR, amelynek legyen két paramétere (az XVAL nyelvben a szélesség és a magasság). A BR-objektum deklarációja a következő: B: BR 10,20 VISION X programozás

213

10

Ugyanez FH-val és annak három paraméterével: F: FH "Data.DBF",Append,0 Vegyük észre, hogy ez pontosan ugyanaz a szintaktika, mint fent az I változó esetén (I: integer 1,2,3). Ha ehhez még hozzávesszük, hogy a B: és az F: nevek megadása sem feltétlenül szükséges az XDSL-ben, a következő szintakitikát kapjuk: FH "Data.DBF",Append,0 Ezzel eljutottunk VAL (az XVAL nyelv elődje) nyelvű parancsaink ismert szintaktikájához. A lényeg az, hogy az utasitások éppúgy deklarációk, mint a változódeklarációk, csak az értelmezésük tér el attól. De mi a helyzet az értékadással? Vajon az F objektumnak - ami FH tipusú volt – adható-e értékadással új érték? A válasz: igen. Ezeknél sokkal bonyolultabb struktúrák, egész deklarációs rendszerek is pont értékadással kapják meg a valódi tartalmukat. Itt már nem is igazán értékadásról, inkább egyfajta tartalom-szolgáltatásról van szó. Az XSDL-ben minden kulcsszó egy korábban deklarált struktúra értékadása - de ne szaladjunk ennyire előre. Inkább rögzítsük még egyszer: az XSDL nyelvben a parancsaink valójában objektum tipusok. Így az integer-hez hasonló tipus a BR és az FH is! Rögzitsük azt is, hogy minden XSDL-beli objektumunknak - így a BR és az FH deklarátumoknak is - adható deklarációs név, csakúgy, mint a változóink esetében. Azonban a névadás sem kötelező (nem feltétlenül kell a programunk összes sorára külön névvel hivatkoznunk, csak az objektumok esetében). A lényeget tekintve az a helyzet, hogy az XSDL nyelvű program minden sora ugyanolyan szintektikájú sorokból áll – legyenek azok bár változók, utásítások, vagy program-struktúrák: {Deklarátum:} Tipus {kezdetiérték [,kezdetiérték]}

‘deklaráció

A deklarátum neve és bizonyos esetekben a tipus is elhagyható. Ezeket később részletezzük.

2.2. Struktúrált deklarációk A struktúrált deklaráció ezek után a deklarációk egymásba ágyazását jelenti. Az XSDL nyelvben a következőképpen hozhatunk létre összetett deklarációs struktúrákat: DeclarationStruc::

Begin Part1: Declaration of integer Part2: Declaration of integer … End

Ez a példa tulajdonképpen egy speciális új tipusnak, a deklaráció-tipusú DeclarationStruc-nak a bevezetését is szemlélteti (a tipusmegadás jele a dupla kettőspont). A Declaration egy előre definiált tipus és azt jelenti, hogy a DeclarationStruc tipusú objektum Part1 és Part2

214


10

tagjainak a megadásához is még deklarálnunk kell, amikor a DeclarationStruc tipusú objektumainkat létrehozzuk: ObjectStruc: Begin Part1=

Part2=

Begin i1: integer i2: integer End Begin i2: integer End

End Íme a struktúrált deklaráció és az értékadás (Part1=...) kapcsolata, amiről az imént szóltunk. Vegyük észre, hogy a Part1=

Begin i1: integer i2: integer End

megadás nem más, mint egy hagyományos struktúra deklaráció (Pascal-ban record, C-ben struct) - beágyazva egy magasabb szintű objektum belsejébe. Látszólag tehát nincs semmi új a fenti tipus megadásban. A különbségek akkor jelentkeznek, ha az eddigiekhez hozzávesszük a halmazok fogalmát.

2.3. Halmazok Az XSDL-ben nem akármit deklarálunk, hanem csak megadott tipusú objektumokat. Az előző fejezet végén arra láthattunk példát, hogy csak integer tipusokat deklaráltunk. A gyakorlatban persze az a helyzet, hogy a deklarációben többféle adattipusra van szükség (a képeken például rajzelemekre). Ehhez először halmazokat kell létrehoznunk a korábban készített tipusainkból. Például: Commands:: [FH, BR] Ez a sor azt jelenti, hogy a Commands vagy FH, vagy BR tipus lehet - tetszőleges sorrendben és kombinációban. A halmaz konkrét reprezentációja ebben az esetben FH-k és BR-ek sorozatából áll. De miféle a sorozat ez? Mindjárt kézzelfogható lesz, ha az alábbi sorra vetünk egy pillantást: Part1:

Declaration of Commands


215

10

Nem deklarálhatók tehát akármilyen tipusú objektumok a Part1=Begin...End blokkon belül, csak Commands tipusúak. Ettől válik eltérővé a Pascal-ban, vagy C-ben megismert struktúradeklarációtól. Végeredményben a Part1 csak FH-k és BR-ek deklarációs sorozata lehet.

2.4. Egymásba ágyazott struktúrák Az egymásba ágyazott deklarációs struktúrák segítségével lényegében minden objektumstruktúra leírható. Nézzük példaként a következő deklarációt: Object:

Declaration Begin Property: Declaration of [Item,Node] Event: Declaration of Item Method: Declaration of Item End

ahol Item:: Node::

[long,int,short...] List of Item

Ez a példa már a tényleges XVAL nyelvű implementációból lett kiemelve, tehát a VAL nyelvű objektumok valódi deklarációs szerkezetét szemlélteti. Új elem a lista tipus, ami a paraméterében megadott tipusú (halmazú) elemekből szerveződik. Ha most megnézzük az Object fenti megadását, azt vehetjük észre, hogy az semmi felesleges dolgot nem tartalmaz; az objektumok tényleg tulajdonságokból, eseményekből és metódusokból állnak. Az XSDL-ben viszont ezt konkrétan meg is fogalmazzuk. A BR deklarációja ezután a következő lehet: BR::

Object Begin Propety=

Event{=

Begin Size: Color: End Begin} Click: {End}

Node Long OnEvent

End Az {=Begin} és az {End} azért szerepel zárójelben, mert a megadása opcionális. Ha nem adjuk meg, a rendszer éppúgy értékadásként értelmezi, viszont egyszerűsíti az írásmunkát, mi több, a kulcsszavak használatához vezet el minket... Azt láthatjuk, hogy a BR objektum konkrét megadásakor már deklaráljuk a konkrét tulajdonságokat is; ebben az esetben a méretet és a színt. Hasonlóan deklaráljuk az eseményeket is, azonban az OnEvent tipus maga is egy deklaráció tipusú objektum: OnEvent=

Declaration of [Commands]

Ezért a BR tipusból épített tényleges BR objektumok készítesekor még az OnEvent esemény kiszolgálóját is deklarálnunk kell: 216


10

BR1:

BR Begin Size= Color= Click=

12.5,27.25 Red Begin 'Click deklarációja FH "Data.DBF",Append,0 End

End Valójában most jött lére a tényleges objektum, aminek most már valamennyi eleme deklarálva van. Sőt, még a korábban deklarált Size és Color tulajdonságok is új értéket kaptak. Ám éppúgy tekinthetjük értékadásnak a Click=Begin ... End utasítást is, mely - ha jobban megfigyeljük - ugyanolyan felépítésű, mint a BR1: BR Begin ... End deklaráció, vagy a Event=Begin ...End, vagy akár a BR1:Begin...End, ill. BR::Begin..End deklarációk. Annyi különbség van csupán, hogy vagy tipust adunk meg (jele: '::'), vagy objektumot deklarálunk (jele: ':'), vagy érteket adunk át a már deklarált objektumnak (jele: '='). Ezen felbátorodva építsünk most magasabb szintű deklarációs struktúrákat. Image::

Begin Property: Event: Static: Do: Service: End

Declaration of Item Declaration of Item Declaration of Object Declaration of Object Declaration of Command

Amint látható, egy kép is tartalmazhat tulajdonságokat (kép neve, címe, skálája, stb.), grafikus objektumokat, köthetők hozzá esemenyek (pl. inicializálás, kilépés) - külön szervezve a statikus és dinamikus elemeket (készíthetünk akár több layer-t). Ezek mind külön is deklarációk, adott esetben további deklarációkat innoválva. Itt például azt láthatjuk, hogy a Static=Begin...End blokkban objektumokat kell deklarálnunk. De az előbb, a BR példáján láttuk, hogy a BR deklarációja maga is összetett (Click=Begin...End). Végeredményben az új Image tipus is egy többszörösen összetett deklarációs struktúra lesz. Ne álljunk meg itt, hozzunk létre a képeinkből komplett projekteket: Project::

Declaration of Images

majd ebből alkalmazásokat (az alkalmazás a VISION-ben több projektből áll!): Application::

Declaration of Project

és így tovább. Látható, hogy az alkalmazásfejlesztés egész problémaköre visszavezethető az XSDL struktúrájú deklarációk rendszerére. Különösen, ha azt is figyelembe vesszük, hogy eltérő képtipusaink léteznek (overdraw kép, report, szimbólum), vagy taszkok (ciklikus program, alarm program), amelyeknek egyetlen közös jellemzőjük van csupán, hogy ti. valamennyien


217

10

az objektumok eltérő halmazával operálnak. Pontosan ezért kellett halmazokat képeznünk az alacsonyabb szinten deklarált elemekből.

2.5. Hova tovább ? Az XSDL még az eddigieknél is több lehetőséget rejt magában, hiszen a rendszer konfiguráció valamennyi elemét felölelheti: az adatbázisok és táblák megadását, a fájlrendszert, az alarm-konfigurációt, a kommunikációs struktúrákat, stb.. Ez utóbbi esetben például az objektum a számítógép (PC), annak tulajdonságai között szerepelhet a soros portok száma, a hálózati csatlakozó; objektum továbbá a PLC, s abból is annyi tulajdonság-csoport, ahány létezik. Az adatbázisok és táblák éppúgy objektum csoportokat képeznek, egy-egy konfiguráció pedig ezek deklarációjából áll. Végeredményben az XSDL-lel minden leírható, amire szükségünk lehet.

2.6. Eltérések más magas szintű nyelvektől Az XSDL nyelvet számos egyedi tulajdonsága különbözteti meg a többi magas szintű nyelvtől. Összefoglalva a következőket mondhatjuk el: • • •

Minden tipusdeklaráción belül is létrehozhatók újabb tipusok, de más objektumok és konstansok is. Ezeket a belső tipusokat csak a velük azonos szinten dekralált objektumok “látják”. Tulajdonság (proprety) mezők szerepeltethetők eljárások és függvények paraméterei között – akár változó-paraméterekben is. A változók bármely bitje is lehet önálló adat, amely sdlBool tipusként átadható függvényeknek és eljárásoknak.

10

218


3. az XVAL programozási nyelv Az XVAL nyelv a VISIONTM folyamatmegjelenítő rendszer programozási nyelve. A XVAL nyelv nagyon hasonló az összetett programozási nyelvekhez, bizonyos szempontból azonban egyszerűsítése, más szempontból pedig azok továbbfejlesztése ─ a korszerű, szabadon skálázható, összetett adadbázisokat kezelő folyamatmegjelenítő és folyamatirányító rendszerek rendkívül magas igényeinek a kielégítésére. A legfontosabb különbségek ─ az általános programozási nyelvekhez hasonlítva ─ a következők: • •

•

•

•

•

Taszkok Nyelvi szinten létezik a taszk fogalma, mely önálló processzként, önálló szálon fut. Objektum utasítások Objektumokat (amelyeknek nemcsak a paraméterit adhatjuk meg, de a tulajdonságait is és eseménykezelést is rendelhetünk hozzájuk) a VAL nyelvben utasítás szinten hozhatunk létre. Vagyis nincs szükség külön objektum-deklarációra és bonyolult hivatkozásokra, mivel az objektumok a VAL nyelvbe ágyazottak. Például egy időzítő objektum azáltal jön létre, hogy leírjuk a TR utasítást. Objektum szintű változódeklaráció A VAL nyelvben a változó nem egyszerűen csak memória rekesz, de kapcsolódhatnak a változókhoz különféle feldolgozó programok is. Például a változók olvasása és írása, mint esemény, egyaránt hozzárendelhető függvényekhez ─ hasonlóan a korszerű programozói rendszerek objektumaihoz (ez a property). Adatbázis változók A VAL nyelvű változók közvetlenül összekapcsolhatók adatbázisokkal. Léteznek előre definiált adatbázis tipusok és szabadon konfigurálható adatbázisok. Az előbbi csoportba tartozik az on-line adatbázis, a trend és az adatgyűjtés, mint a VISION folyamatmegjelenítő rendszer speciális adatbázis tipusai, az utóbbi kategória pedig a táblázat szerkezetű, ún. relációs adatbázisokat takarja. Hangsúlyozzuk, hogy a változó szintű adatbázis kezelés nem helyettesíti, csupán praktikus szolgáltatásaival kiegészíti az adatbázis kezelés hagyományos, programozott módszereit, az SQL alapú, vagy táblázat kezelő rendszereket. Változó szintű taszk-taszk kommunikáció A VAL publikus változói nemcsak az adott programban, vagy még általánosabban: az adott taszkban látszanak, de az összes többi taszkban is, amely ugyanahhoz az adatbázis erőforráshoz kapcsolódik. Ez a szolgáltatás rendkívül kényelmessé teszi a folyamatmegjelenítő rendszer taszkjai (képek, alarmok, feldolgozó programok, stb.) és a szerver-kliens felépítésű rendszer távoli számítógépei közötti kommunikációt, amennyiben a változók pubished publicitásúak Dinamikus változó azonosítás A VAL nyelvű taszkokat nem kell újrafordítani ahhoz, hogy a változódeklarációban végrehajtott módosításokat “észrevegyék”. Ennek egy automatikus deployment (közzétételi) eljárás a magyarázata, amelyet e dokumentáció végén ismertetünk. Röviden ez lokalizálja a taszk számára a globális változókat, objektumokat és az adatbázis hivatkozásokat. Ugyanis a taszk, futása közben, a saját címterületére másolt változókkal dolgozik. Részben ennek a szolgáltatásnak köszönhető a VISION rendszer talán legérdekesebb szolgáltatása: a hálózati változók kezelése.


10

219

•

•

Hálózati változók A taszkok dinamikus változó-lokalizációs eljárása és az adatbázis változók bevezetésének köszönhetően lehetővé vált, hogy a közös adatbázishoz tartozó változók tartalmát a hálózat távoli számítógépein is láthatjuk és akár meg is változtathatjuk. XSDL A XVAL nyelv a legújabb (X sorozatú) VISION változatokban egy önálló leíró nyelv alatt lett implementálva. Ennek elnevezése az XSDL. Szerencsére az XSDL azt is lehetővé teszi, hogy speciális program struktúrákat, változótipusokat, képtipusokat, adatbázisok, jelentéseket, stb. hozzunk létre. Tehát, az XVAL nyelv ismert szemantikáját is ez a magasabb szintű nyelv határozza meg. Az XSDL bevezetésének számos érdekes hozadéka van, amivel önnálló fejezetben foglalkozunk.

Amint látható, az objektum-orientált XVAL nyelv rendkívül érdekes szolgáltatásokat nyújt, ha akárcsak a változókat hasonlítjuk össze a magas szintű programozási nyelvekben megismert lehetőségekkel. Hiszen a VISION változók maguk is objektumok, amellett, hogy változó szinten válik lehetővé a közös erőforrás kezelés és a távoli-, vagyis hálózati adatkezelés. A VAL nyelvű programokkal kapcsolatos legfontosabb fogalmak összefoglalása ) A változó deklarációs részben hozzuk létre a VISION változóit és azok adatbázis hivatkozásait (trend, adatgyűjtés). A deklaráció konstansok, tipusok és változók megadásából áll ─ tetszőleges sorrendben. ) A taszkok önálló processzként (önálló aktivitásként) futtatható programok. Tipikus példája ennek a kép (form), amely a VISION rendszer esetén éppúgy programozott. Önálló taszkként fut azonban az eseménykezelés és az összes többi feldolgozó program is. ) Az eljárások ─ mint látható ─ csak annyiban különböznek a taszkoktól, hogy nem tartalmazzák a DO utasítást. Ezért csak egyszer futnak le ─ végrehajtva a paraméterek által meghatározott feladatot. Ők a hagyományos szubrutinok. A másik lényeges különbség, hogy amíg a taszkok önálló szálon futnak, s így egymást akár meg is szakíthatják, végrehajtásukat párhuzamosítják, addig a szubrutinok az adott processzbe ágyazottan hajtódnak végre ─ szekvenciálisan. ) Végül az objektum deklarációs rész határozza meg a taszkokon és a tipusdeklaráción belül, hogy a taszkokban definiált objektumoknak milyen tulajdonságai vannak és milyen eseményeket aktiválnak. Például mi a teendő akkor, ha az adott objektumra kattintunk, vagy bekövetkezik egy esemény, lejár egy időzítő, stb. Amint a bevezetőben utaltunk rá, objektumokat a változó deklarációs részben is megadhatunk, más érdekes adattipusokkal, pl. tulajdonsagokkal (property) együtt. Erről részletesen a változó deklarációról szóló fejezetben írunk. A VAL nyelvű program felépítése általában a feladatok fenti szétválasztását követi, de ez nem kötelező, hiszen pl. a változódeklaráció egy része akár be is építhető a taszk belsejébe, és a változók, konstansok, tipusok megadási sorrendje sem kötött.

220


10

Példa: #pub Global #lib Library Published Variables Types String= Char[31] Widestring= Char[127] Integers i: Int End

‘Default global VISION database `Default set of system functions

‘31-char-long string ‘127-char-long string 0

‘Sample int variable

Img: Image Begin Scale= 0,0,128,96 BR1:BR 10,10 Begin Position= 100,100 End Do LD1: LD Begin Position= 100,100 End End

Nézzük a részleteket.

10


221

3.1. Változó deklaráció A változók deklarációja az alábbi alapszintaktikát követi: {[]}: {} { {‘<megjegyzés>}} Tipus

Tipusdeklarációval keletkezik (ld. köv. fejezet), ill. az alaptipusok közül lehet kiválasztani. A változó tipusa meghatározza a változó

• Tárolási méretét és értéktartományát: o Alaptipusok esetén:

Alaptipus Ushort Short Word Integer Dword Long Float (Real) Double Char

Értéktartomány 0 .. 255 -128 .. 127 0 .. 65535 -32767 .. 32768 0 .. 4294967296 ± 2147483647

Alfabetikus karakter

Hossz 1 1 2 2 4 4 4

Pointer Pbyte Pshort Pword Pint Pdword Plong Pfloat

Hossz 4 4 4 4 4 4 4

8 1

Pdouble Pchar

4 4

o Struktúrák és tömbök esetén: a megadott mezők mérete összegződik a tömbszámnak, ill. a struktúrában felsorolt mezőváltozóknak megfelelően o Felhasználói adattipusok esetén: a deklarációtól függően eltérő lehet; általában változó méretű struktúrák és tömbök, akár kombinációban

• Helyét: o Pointerek (Pbyte,Pint,stb.) esetén az on-line adatbázisban o Egyébként memóriában (memória-változó)

• Publicitását (láthatóságát, hozzáférhetőségét): Published Public Local

Private

Publikus adattipus, mely az összes taszk és felhasználó számára hozzáférhető, írható és olvasható, valamint listázható. Ez a default érték. Publikus adattipus, mely az összes taszk és felhasználó számára hozzáférhető, írható és olvasható, de a listákban nem jelenik meg. Lokális adattipus, mely az összes taszk számára hozzáférhető, írható és olvasható, de csak az adott local account-ra bejelentkezett felhasználó számára. A listákban sem jelenik meg. Csak az adott taszkban használt változó, így a neve is ismétlődhet más taszkokban. Értelemszerűen lokális a felhasználó számára is. A listákban ez sem jelenik meg.

(A listázás azt jelenti, hogy a változó megjelenik a változólistában)

222


10

változó

A változó neve max. 32 karakter hosszú lehet. A listázások áttekinthetősége érdekében azonban ne használjunk hosszabb szövegeket 18 karakternél (ennél hosszabb név sok listában nem látszik). Célszerű emellett a változónévnél betartani a szimbolikus azonosítókra érvényes konvenciókat, vagyis a változó nevét betűvel kell kezdeni és alfabetikus karaktereken kívül más karakterket nem tartalmazhat (így pl. kötőjelet sem, hiszen ez a karakter a kivonás jele). Azonban ez a szabály a VISION X9 változatától kezdve nem kötelező érvényű, csupán ajánlás. Abban az esetben, ha a változónévben mégis meg kívánunk adni speciális karakterket, pl. space-t, ékezetes karaktert, vagy kis-nagy betüt, akkor az egész nevet kapcsos zárójelek közé kell írni: {Kezdő hőmérséklet}

tömbszám:

A változó számossága, tömbmérete. A tömbváltozók elemeire indexelten hivatkozhatunk. A maximális index = tömbszám – 1 (0 az első elem indexe)

kezdeti_értékek

Ez az opcionális mező határozza meg a változó kezdeti értékét, mely gyakran egy felsorolás (struktúrált változók esete). Ha nem adjuk meg, az adott tipusnál definiált kezdeti érték(ek) lesz(nek) érvényes(ek), ill. alaptipusok esetén a nulla.

megjegyzés

Ez a fontos, de opcionális mező a változó funkciójának a leírására szolgál. Mindenképp érdemes megadni, mert ezzel a későbbi változóazonosítást könnyíthetjük meg, de ugyanez a mező jelenik meg pl. az alarm üzenetekben is. A megjegyzés mező tehát nem teljesen ugyanaz, mint ált. egy comment.

Példák:

B1: {Kezdő hőmérséklet}:

Public Byte Local Float

12 0

‘Példa byte változóra 12 értékkel ‘Hőmérséklet változó

Az első példában az új változó neve B1, a VAL kifejezésekben ezzel operálhatunk (pl. B1=2*B1;). A második példában szereplő változónév azonban speciális karaktert tartalmaz, ezért programbeli hivatkozásnál kapcsos zárójelek között kell szerepeltetni (pl. {Kezdő hőmérséklet} = 20;). A tipusmegadás (itt: Byte és Float) nem mindig szükséges, ahogy a tipus deklarációról szóló következő fejezetben részletesen is kifejtjük. A tipusmegadásnál láthattuk, hogy a változók igen sokfélék lehetnek ─ még az adott tipuson belül is. A published és a public tipusok megkülönböztetésével elérhetjük, hogy csak azok a változók jelenjenek meg a változólistánkban, melyeket erre felhatalmaztunk, a belső változók, számlálók, időzítők, stb., nem. A lokális (local) és a publikus (public v. published) között pedig a felhasználói hatáskör tesz különbséget, miközben mindkettő változótipus közös az adott felhasználói account-on futó taszkok számára. Hogy ezt megértsük, tudni kell, hogy egy szerver-kliens felépítésű hálózaton egyszerre több felhasználó is hozzáférhet az adatokhoz. A folyamatjellemzők általában


223

10

publikusak, mivel minden felhasználónak ugyanazokat a technológiai adatokat (hőmérsékletet, szelepállapotokat, stb.) kell látnia, és ugyanez a helyzet a technológia felé küldött parancsokkal is. Azonban létezhetnek olyan változók is, amelyek törvényszerűen különböznek az egyes felhasználóknál. Ilyen a felhasználó neve, a helyi idő változója, a napló ideje és fájlneve, egy adatbeviteli kép változói, vagy az alkalmazói program felhasználóra szabott, egyedi beállításai (pl. az, hogy váltson-e automatikusan képre alarm esetén). Ezeket a változókat lokálisan kell eltárolni. Azonban az adott felhasználó hatáskörében futó többi taszknak éppúgy szüksége lehet ezekre az adatokra (pl. az alarmrendszernek azért, mert ezeket felhasználva kell naplóznia); ezért e változóknak osztottaknak kell lenniük. (Megjegyezzük, hogy a különféle felhasználói account-ok nem feltétlenül különböző számítógépek; pl. a VISION internet szervere egy számítógépen belül futtatja a szerver oldali kliens kiszolgálót). Ez a lényeges különbség a privát (private) változókkal összehasonlítva, amelyeknek viszont csak az adott taszkban szabad hozzáférhetőnek lenniük. A program törzsében (Begin után) megadott változók automatikusan privát változónak számítanak. Tipikus példa egy belső ciklisszámláló. Fontos, hogy értsük a különbséget a memória-változók és az adatbázis-változók között. Bár mindkét változó tipus lehet lokális és publikus is, lényeges különbség, hogy az adatbázis változókban a változó értéke (ill. a története) is el van tárolva, s így kikapcsolás, ill. újraindítás után is megtartják a legutolsó értéküket; trend és adatgyűjtés esetén pedig a teljes archívumot. A memória-változók ezzel szemben 0-val inicializálódnak. Tehát az adatbázisváltozók értékét (ill. történetét) a rendszer a háttértárolóra másolja ─ pont ettől adatbázisváltozók. Amikor pedig egy távoli számítógépen, vagy Internet Explorerben indítunk el egy taszkot, vagy a komplett VISION alkalmazást, ami ugyanerre az adatbázisra hivatkozik, akkor ugyanazokkal a legutoljára letárolt adatokkal kerülünk kapcsolatba. A P előtag az alaptipusú változóknál arra utal, hogy ilyenkor a memóriában egy pointert tárolunk el (a változó konkrét értéke helyett), ami az on-line adatbázis megfelelő rekeszére mutat. A pointerek a kezelésével nincs dolgunk, azt teljes egészében a rendszer végzi. A trend- és az adatgyűjtés adatbázisok esetén persze némileg bonyolultabb a helyzet, mivel ezek az adatbázisok speciális kiszolgálást igényelnak, nem lehet őket egyszerűen pointerrel megadni. Ehelyett objektumokat deklarálunk ─ felhasználva a VAL nyelv objektum deklarációs szolgáltatását. Ennek részleteivel a felhasználónak nem kell igazán foglalkoznia ─ azt leszámítva, hogy megadja ezen objektumok paramétereit, pl. a teljes tárolási hosszt, a változó deklaráció sorában. A VISION objektumok felépítését és referenciáit ez a dokumentum nem tartalmazza. További eligazodásért (és ötletekért) édemes tanulmányozni a VISION program alaptipusainak a definícióját tartalmazó VAL.SDL fájlt, mely megtalálható a VISION telepítési főkönyvtárában a SYSTEM alatt. Új projekt készítésekor ez a fájl határozza meg az adatbázisok (XDO) kezdeti értékeit; ebben adjuk meg a VISION struktúrált adattipusait (Bytes, Integers, stb.). A későbbi változó deklarációk pedig ehhez a VAL.SDL fájlhoz épülnek hozzá, felhasználva az itt megadott alap adattipusokat. A System SDL fájljai jól szemléltetik, hogyan készíthet valaki saját változó tipusokat, hogyan lehet a változókat külső programokhoz kapcsolni (library), mit jelent a tulajdonság (property), a struktúra (begin..end), stb.

224


10

Jogosultsági rendszer, felhasználó kezelés

Tartalomjegyzék: 1. Bevezetés.............................................................................................................................. 226 2. Jogok .................................................................................................................................... 226 3. Felhasználók......................................................................................................................... 228 4. Szolgáltatások....................................................................................................................... 228 5. Opciók .................................................................................................................................. 229 6. Hatóságok............................................................................................................................. 229 7. Adatforrás............................................................................................................................. 230

PROVICON Kft. 2005.08.26.

11

Felhasználó kezelés

225

1. Bevezetés A jogosultsági rendszerek áttekintésével azért foglalkozunk részletesen, mivel a diszpécser, felügyeleti és a rendszergazda szerepkörök éppen a hozzáférési szintek konfigurálásával, tehát logikailag választhatók szét egymástól a VISION programrendszeren velül. Más szóval, ugyanaz a futtató- ill. fejlesztõrendszer képes minden egyes alkalmazási kör lefedésére a megfelelõ jogosultság beállítása után. Vagyis a diszpécser, a megjelenítés, a felügyelet és a rendszergazda szerepek akár ugyanazon a gépen is váltogathatók menet közben. A felhasználó hozzáférési rendszer azonban ennél sokkal többre is képes a következõkben leírtak szerint.

2. Jogok A felhasználók jogosultsági rend-szere a jogosultsági osztályok elõállításán alapul. A jogok lapon deklarálható jogosultsági osztályok szintek, rendszerjogosultságok, alkalmazás függõ jogosultságok és extra jogok összerendelésével adhatók meg. A rendszerjogosultság a szerkesztési, konfigurálási és adatmódosítási mûveletekhez való hozzáférést engedélyezi a felhasz-nálók egy adott csoportjának, továbbá a saját kulcs átírásának a lehetőségét biztosítja.

Ezek a jogosítványok rendszer szinten vezérlik, hogy az adott felhasználó átprogramozhatja-e az alkalmazást (online szerkesztés), vagy csak konfigurálhatja, esetleg minden adatmódosítás eleve tiltott a számára. Mint látni fogjuk, emellett további alkalma-zással összefüggõ jogosítványok is specifikálhatók (extra jogok). Minden további jog alkalmazás-függõ módon rendelhetõ a felhasználói csoporthoz. Ezek a jogosultsági osztály oszlopai, amelynek elnevezése az oszlop tetejére kattintva módosítható (új jog). A sorok a jogosultsági szintet határozzák meg úgy, hogy a nagyobb sorszámú jogok az "erõsebbek". A táblázat legelsõ sora tehát a legalacsonyabb, ún. alapjogosultságot határozza meg, amelyre a rendszer a védelmi idõ leteltével (ld. opciók) mindig visszatér. Az extra jogok a jogosultsági osztály melletti nyomógombbal hívható le.

226


11

Extra jog megadás

Az extra jog dönti el többek között, hogy az adott felhasználói csoport milyen rendszermenüket érhet el. Ez a szerkesztõ ablak láthatók a következõ ábrán. Mint látható, a VISION rendszer legördülõ menüje és eszközmenüje, ill. a hozzá kapcsolódó funkciók felhasználónként változtathatók. Akár az is beprogramozható, hogy adott felhasználó ugyan rendelkezik rendszergazda jogokkal, de új változót és mondjuk felhasználót nem vehet fel, továbbá az alkalmazásból nem léphet ki (ablakkezelés).

11

Érdemes áttekinteni, hogy a felhasználói jogosultsági rendszer konfigurációjára milyen további opciók lehetségesek. Elképzelhetõ pl., hogy valaki csak az ún. jogosultsági mátrixot modosíthassa, de ne vehessen fel új jogosoltsági osztályt, felhasználót, szolgáltatást, stb. A jogosultsági rendszer teljes konfigurációja a VISION programban többmillió kombinációt jelent.


227

3. Felhasználók A felhasználók ezen jogosultsági osztályokkal rendelhetõk össze az elsõ lapon. Itt kell megadni a felhasználó teljes nevét, rövid (ún. nick) nevét, valamint a kulcsszavát, amit a joghatóság függvényében a felhasználó az elsõ belépés alkalmával módosítani lehet köteles. Minden felhasználóhoz kapcsolódó jog a felhasználói csoport jogosítványaiból adódik.

4. Szolgáltatások A szolgáltatás felhasználótól független feladatok kulcsszóval védett elérésére szolgál. lyen lehet pl. egy speciális paraméterezõ ablak, vagy alkalmazói konfigurációs képernyõ (lekérdezések rendszerének a konfigurálása, számítások, stb.)

11

228


5. Opciók Az opciók lapon a bejelentkezéssel, hibaüzenettekkel és a naplózással kapcsolatos feladatok állíthatók be. Itt adhatjuk meg továbbá a védelmi idõket is, emelyek a felhasználó vagy a szolgáltatás automatikus kiléptetésére szolgálnak, amennyiben a rendszert magára hagyják. Ha a védelmi idõ lejár, a rendszer automatikusan visszaáll az alap jogosultságnál megadott szintre.

6. Hatóságok A hatóságok a felhasználókezeléssel kapcsolatos elõírások rendszerét határozzák meg. A kiválasztható szabvány elõre definiált tulajdonságokat, ill. megszorításokat tartalmaz. Ezek az elõírások nem módosíthatók és a programból az Auditor bármikor lekérdezheti õket. A joghatóság elõirást tartalmazhat pl. a kulcsszó minimális hosszára, a felhasználók automatikus törlésére, az új felhasználónévvel kapcsolatos egyediség kérdésére, stb. A rendszer lehetõvé teszi a 21 CFR szabvány használatát, ami egyre gyakoribb elõírás informatikai rendszerek esetében. Ez a szigorú elõírások mellett biztosítja a felhasználókezelés nyomkövetését is, az ún. Audir Trail funkció alkalmazásával. Mindezek a nemzetközi szabványok a VISION programban is használhatók.


229

11

7. Adatforrás A felhasználókezelés adatbázisa többféle forrásból is származhat. Alapesetben az adatbázis az alkalmazói program saját könyvtárában foglal helyet (user.dat). Szerver-kliens hálózati rendszerekben elõfordulhat, hogy a felhasználó-kezelés adatbázisa a szerveren taláható, vagy más közös elérésû hálózati tárhelyen. Ilyenkor az egész alkalmazás közös felhasználókezelést valósít meg. Összevont alkalmazás esetében ezenkívül eldöntendõ, hogy az egyes projektek egy közös adatbázist használnak-e (ilyenkor a fõprojekt adatait öröklik), vagy saját, önálló adatbázissal, ill. védelmi rendszerrel rendelkeznek. Így különböztethetjük meg pl. a diszpécseri és felügyeleti munkaállomásokat jogosultsági rendszerét egymástól. Azonban akár össze is vonhatjuk a teljes rendszert, s így egyetlen közös felhasználólkezelés alakítható ki. A projektek integrációjánál ugyancsak eldöntendõ, hogy az egyes projektek az alrendszer hozzáférési rendszét vagy a közös rendszert alkalmazzák-e. Még az is lehetséges, hogy az egyedi projekt más jogosultsági rendszerrel induljon, mint a teljes integrált rendszer.

11

230



Tartalomjegyzék: 1. Bevezetés............................................................................................................................ 232 2. Konfigurációs oldalak .................................................................................................... 233 2.1. Kezdőkép..................................................................................................................... 234 2.2. Rendszer ...................................................................................................................... 236 2.3. Fájlrendszer ................................................................................................................. 238 2.4. Hálózat kezelés............................................................................................................ 240 2.5. Alarmok....................................................................................................................... 241 2.6. Alarm nyomtatás ......................................................................................................... 242 2.7. Jelentés nyomtatás....................................................................................................... 243 2.8. Felhasználói profil....................................................................................................... 244 2.9. Duál monitor ............................................................................................................... 246 2.10. Audit Trail ................................................................................................................. 247 2.11. Képek alapbeállításai................................................................................................. 248 2.12. Redundancia .............................................................................................................. 250 2.13. Adat struktúrák.......................................................................................................... 251 2.14. Multiprocesszálás ...................................................................................................... 253


11


231

1. Bevezetés A VISION alkalmazások és részben a rendszer konfigurálása külön komponensben, a Konfigurációban történik. Ez egy többlapos beállító dialógus, aminek egyes lapjai rendszerfunkciók szerint vannak szétválogatva.

A rendszerkonfiguráció külön ablakban is lekérdezhető, amenyiben az XP-stílusban kialakított konfiguráció helyett hagyományos dialógust szeretnénk használni. Ez a rendszer legördülő menüből Konfiguráció B Konfiguráció-t választva érhető el:

12

232


A rendszer alapbeállításai úgy vannak kialakítva, hogy közülük csak a legszükségesebbeket kelljen módosítani. Ez legtöbbször a kezdőkép beállítását és az alarmokat érinti, a többi paraméter az esetek többségében alapbeállításon hagyható.

2. Konfigurációs oldalak A konfiguráció az alábbi feladatcsoportokból tevődik össze: Kezdőkép

A kezdőkép és a főablak részeinek a beállítása: legördülő menü, projektmenedzser, eszközmenü, rendszer üzenetek és státuszsor

Rendszer:

Gyorsító billentyűk beállítása, időszelekció, képernyő védő, azonosítási mód, ciklikus mentés, felhasználói opciók, stb.

Fájlrendszer:

A program fájlrendszerének és adatbázisainak a beállítása, benne az online adatokkal, trenddel, adatgyűjtéssel és esemény-naplókkal

Hálózat kezelés:

A szerver-kliens hálózati rendszer szerver és kliens elemeinek a konfigurálása, hálózat üzemmód, többszerveres rendszerek és extra hálózati csomópontok bekonfigurálása

Alarmok:

A csoportokra és típusokra bontott esemény kezelő rendszer elnevezéseinek, prioritásainak és színeinek a beállítása

Alarm nyomtatás:

Az eseménynapló nyomtatási oldalainak az elrendezése, magának a nyomtatónak a megadása és a lap formázásával összefüggő egyéb adatok

Felhasználói profil:

A felhasználói profil elsősorban az alkalmazott menürendszert érinti, de a program prioritási szintjeit is itt lehet beálltíani

Duál monitor:

A 2-4 monitort kezelő rendszerekben a monitorok elhelyezkedésének és számának a beállítása

Audit Trail:

A 21 CFR szabvány szerinti adatnyomkövetés alkalmazásfejlesztéssel, azaz verifikálással összefüggő részei

Képek alapbeállításai: A képek alap (default) ciklusideje, skálája és gyorsítótára, valamint a számok és az idő ábrázolásának a módja Redundancia:

A többszörös tárolású, nagybiztonságú rendszerek konfigurálásának oldala, mely tartalmazza az adattárolás cikikusságát, módját és a tárolt adatokat

Adat struktúrák:

Rendszer adatbázisok és struktúrák összerendelése, valamint a unitkonfigurációs képek és az alarm ablak ún. információs része

Multiprocesszálás:

A Windows többszálú működésének engedélyezése / tiltása taszktípusonként

12

Az egyes konfigurációs oldalak legfontosabb paramétereit ismertetjük a következő fejezetekben.


233

2.1. Kezdőkép

Amint látható, a kezdőkép konfigurációja tartalmazza az alkalmazás indítási opcióit, vagyis annak beállítását, hogy melyik képpel induljon a program, eilinduljon-e automatikusan, s hogy a kezdőképen milyen rendszer-információk legyenek láthatóak kezdetben. Amikor egy alkalmazás elindul, betöltés közben a VISION program saját háttérképe látszik. Ezt azonban lecserélhetjük és helyette inkább az üzem fényképét, vagy saját társaságunk jelképeit ábrázolhatjuk. Ez a kezdő bitmap opció. Ilyenkor lehet szükség arra, hogy ezen az új háttérképen megadhassuk a renszer által rárajzolt cím és szöveg színét (pl. a fehéren nem mutat túl jól a fehér), ill. hogy egyáltalán látható legyen-e azon a szöveg. Ez a szövegszín opció és előtte az engedélyező checkbox. Az automatikus indítás opció arra szolgál, hogy az elindított fejlesztő- vagy futtató rendszer automatikusan betöltse és elindítsa a default alkalmazást. Egy idő után természetesen, hogy azért legyen lehetőség a változtatásra. Ez az idő a fenti konfigurációs képen 10 másodperc. A főablak részeinek a beállítását egy konfigurációs táblázatban végezhetjük el. Az első ránézésre talán bonyolult táblázat azt határozza meg, hogy ezeknek a részeknek (pl. a legördülő menünek) mi legyen az indulási állapota, s hogy az megváltoztatható-e futás közben. Így elérhető, hogy menü nincs a képen, de nem is tehető fel, vagy rajta van és nem vehető le. Az alapbeállítás szerint mindig a legutolsó állapot szerint van a képen a menü, és levehető / felrakható az F2 gombbal. Mégpedig úgy, hogy első megnyomásra csak az eszközmenü, majd utána a legördülő menü tűnik el, ismét megnyomva pedig fordítva, először megjelenik a legördülő menü, utána az eszközmenü. Erre a körbenforgó le-felvételre utal a táblázatba írt F2/1, F2/2, ami azonban ugyanúgy megváltoztatható. A konfigurációnak ezt a részét azonban nem érdemes változtatni, mert mint a felhasználó függőség beállításából is látszik, ezeket a menüket inkább a felhasználóhoz érdemes kötni. Például az adminisztrátor hozzáfér a menühöz, de a kezelő már nem. E lehetőségeket a felhasználó kezelésnél ismertetjük.

234


12

Ugyanúgy körbenforgó elven vehető le / rakható fel a státuszsor és a rendszer üzenet terület, csak most az F12-őt használjuk. A projektmenedzser gyorsító billentyűje az F11. Megjegyezzük, hogy a funkció billentyűk közül az F1, az F9 és az F10 használt még a rendszer által. Az F1 a súgó, az F9 mindig az előző kép, az F10 pedig a főkép. Így a felhasználói program számára csak az F3-F8 billentyűk maradnak – ezek oszthatók szét a funkció menü sávon. Abban az esetben, ha a gyorsító billentyűket kivesszük a táblázatból, a főablak ezen részei még feltehetők / levehetők a képről. Mégpedig a szokásos módon, a jobb egérgomb menüvel (ahogy pl. az Office-ban is). A főmenü, eszközmenü, vagy a státuszsorra kattintva jelenik meg a jobb oldalt látható menü, benne a főablak részeivel és az eszközmenü nyomógombcsoportjaival. Ez a jobb egérgomb menü azonban ugyanúgy külön letiltható, mint minden egyéb. Erre szolgál a változtatás engedélyezése opció.

A rendszer attól függően jegyzi meg és állítja vissza a desktop előző állapotát – benne a fenti menüben látható checkbox-okkal –, hogy a mentés kilépéskor opciót bekapcsolva hagytuk-e. Végül a kezdőkép, ill. a főablak beállításához tartozik még az óra megjelenítése a fejlécben opció:

12


235

2.2. Rendszer

Gorsító billentyűk:

Ebben a menücsoportban a súgó (F1) és a programból való kilépés (Ctrl-Q) gyorsító billentyűit engedélyezhetjük.

Trend index mód:

Az indexelt trendek időbélyeg képzését határozza meg, ami lehet abszolút és relatív; ez utóbbi az index, az előbbi az időbélyeg

Időszelekció:

Ez a menücsoport határozza meg, hogy az eseménynaplóban, a trendek listájában és az adatgyűjtésben milyen opciók szerepeljenek az időszelektor menüjében. Előfordulhat, hogy egy rendszerben nincs szükség a negyedév és a félév szerinti szűrésre, máskor meg a műszak szükségtelen.

Műszakok:

Amennyiben a műszakokat engedélyeztük az időszelektorban, a műszakok számát és kezdeteit is beállíthatjuk. Arra is lehetőség van, hogy valamilyen időeltolással adjuk meg a műszak-zárás pontos idejét plusz-mínusz percben. Például, ha a 14 órás műszak valójában 13:50kor fejeződik be, a késleltet-be -10-et kell írni, és a rendszer mégis 14órás zárásként fogja azt figyelembe venni, habár 13:50-kor hajtja majd végre.

Azonosítás:

A rendszer a változók (tag-ek) azonosítására két azonosítót is használ, a szimbolikus azonosítót és a technológiait. Ebben a menücsoportban azt dönthetjük el, hogy e kettő közül melyiket használjuk. A technológiai azonosítónak az lehet az előnye, hogy ebben bármilyen string szerepelhet, tartalmazhat kis-nagybetűt, sőt lehet benne szóköz és még ismétlődhet is. Ezzel szemben a szimbolikus azonosítóra a számítástechnikában szokásos szabályok vonatkoznak (pl. nem kezdőthet számmal), s ezért az megkötést jelent. A technológiai azonositható ezenkívül változhat is működés közben, tehát még az online tag-változtatás lehetőségét is magában hordozza.

236


12

Változó-igazítás:

Abban az esetben, ha a rendszerünkhöz külső programokat kapcsoltunk (Külső kapcsolat komponens), akkor azt is meg kell mondanunk, hogy a változókat szóhatárra kell-e igazítani. Speciális igazítást igényel ezenkívül a Visual Basic. A tömbinterfész opció arra szolgál, hogy a tömbként felvett változókat is át lehessen küldeni a külső programba. Erre a beállításra azonban nem csak emiatt lehet szükség. A töminterfész akkor is szükséges, ha a tömb-adatokat a hálozaton is mozgatni kívánjuk, vagy program újraindításkor szeretnénk őket visszatölteni a diszkről.

Automatikus mentés: A program az online adatokat nemcsak akkor képes diszkre menteni, ha kilépünk a programból, de menet közben is, ciklikusan. Ennek idelye adható meg itt másodpercben. Így a rendszer akkor is az előző állapottal tér vissza, ha a kikapcsolásra mondjuk feszültség-kimaradás miatt került sor. Így legfeljebb csak az elmúlt 5 perc adata veszhet el (300 sec). Képernyő védő:

A VISION program tartalmaz egy érdekes és rendkívül hasznos képernyő védőt, ami úgy működik, hogy lesötétíti a képet. Vagyis a kép valójában akkor is látszik, amikor a képernyő védő aktív, csak nem teljes fényerővel. A lesötétítés mértéke és a képernyő védő ideje állítható be ennél a menücsoprtonál.

Felhasználói opciók: A felhasználó kezelésnél az alapadatokon túlmenő felhasználói jogokat és adatokat írhatjuk itt elő a program számára. Alaphelyzetben a programot csak a felhasználó neve érdekli, mivel ez szükséges a belépéshez. Ha engedélyeztük az extra felhasználói adatokat, akkor ezentúl a felhasználó telefonszámát és email címét is megadhatjuk, valamint küldhetünk is email-t erre a címre. Hasonlóképpen a felhasználó jogai sem korlátozottak csupán a szerkesztés és a konfiguráció engedélyezésére, de megadható minden egyes menüpony (pl. a trendek és az eseménynapló menüi), valamint a felhasználó kezelés összes saját opciója (pl. hogy törölhet-e az illető felhasználót, vagy módosíthatja azok adatait) is, amenyiben az extra felhasználói jogokat engedélyeztük. Egyéb beállítások:

Az egyéb beállításoknál a diszkrét és a többállapotú trendek ábrázolását érdemes megemlíteni; itt dől el, hogy a trendben lépcsőábrát látunk-e, amikor ezeket a kettő- vagy többállapotú változókat megjelenítjük, vagy egy színsávot, amely a változó trendbéli értéke szerint változtatja a színét. A többszörös indíthatóság beállításával azt érhetjük el, hogy a VISION képes legyen több példányban is futni. Ez a legtöbb alkalmzásban nem túl praktikus, nehogy a felhasználó véletlenül több taszkot is aktiváljon, mert nem veszi észre, hogy minimalizálva már fut a program. Végül a rendszer automatikus frissítésével azt kérhetjük a rendszertől, hogy meghatározott időpontban (amikor a rendszert épp nem kezelik és nincs más feladata) elvégezzen egy ún. szemétgyűjtést és frssítse a taszkokat. Ám erre az opcióra az esetek 99%-ban nincs szükség.


237

12

2.3. Fájlrendszer

A fájlrendszernél a rendszer adatbázisok nevét és tárolási helyét változtathatjuk meg a következők szerint: A rendszer adatbázisok (DATA.TAB, DATA.TAG, DATA.TRN, DATA.DAT) neve az alarm naplófájlok nevével együtt egyaránt tartalmazhat speciális jelöléseket: Így az adatbázis fájlok neve változhat naponta, hetente, havonta vagy évente, és ezáltal automatikus archiválást végez. Ráadásul azokban a naplókban, ahol időszelektort használunk (trend, adatgyűjtés, esemény napló) a fájlokat a program az idő szerint automatikusan visszaolvassa, tehát még a korábbi adatfájlok megnyitásával sem kell bajlódnunk, csak az időt kell meghatároznunk. A végeredmény egy rendkívül egyszerű és kényelmes archiválási eljárás a maga automatizmusaival. $Y $M $D $W

Év Hónap Nap Hét

Alaphelyzetben ezen fájlok tárolása a kép jobb oldalán látható alkönyvtárakban történik, amelyek az alkalmazás alatt találhatók. Ez a DATA, az ALARM és a MISC. Természetesen ezek is megváltoztathatók, de törekedjünk arra, hogy a rendszer relatív könyvtárszerkezetét megőrizzük, azaz lehetőleg ne tegyük át a DATA-kat a c:\-re, vagy más fix könyvtárba. Ez ui. nagyon megnehezítené az alkalmazás mozgatását (pl. átmásolását a notebook-ra), hálózati környezetben pedig még további bonyodalmakat okoz. Előfordulhat, hogy az esemény naplót (és esetleg az Audit Trail-t) MS-SQL, vagy Oracle alá szeretnénk átteni, mert az sokkal gyorsabb és megbízhatóbb, valamint nagyobb adatmennyiség tárolására alkalmas. Ez a művelet végezhető el az adatbázis beállítása menüponttal. Ezt megnyomva jelenik meg az op. rendszer Adatkapcsolat tulajdonságai panelje, ami alább látható.

238


12

A beállító ablak ugyan mindjárt a Kapcsolat fülre ugrik, hiszen már van egy kiválasztott szolgáltatónk (MS-Access), de abban az esetben, ha az adatbázis típusát is meg akarjuk változtatni, vissza kell kattintanunk a Szolgáltató fülre. Először tehát a szolgáltatót, más szóval a provider-t (MS-Access esetén Microsoft Jet 4.0 OLE DB Provider) kell kiválasztani, majd a szolgáltatótól függően az adatbázist és annak paramétereit. Arra azért vigyázzunk, hogy a saját (felkínált) Access adatbázisát ne jelöljük ki a rendszernek ezzel a módszerrel, mert attól kezdve a rendszer összes eseménye ugyanabba az adatbázisba fog beíródni, egy idő után tehát kezelhetetlenül nagy lesz. Az adatbázis átirányításnak csak akkor van értelme, ha egy “valódi” SQL szerverre térünk át, pl. Oracle-re, vagy MS-SQL-re. Microsoft SQL servert választva pl. az alábbi beállító kép jelenik meg: Ennél a beállító panelnél a szervert kell először kiválasztani, majd az ún. autentikációs módot, ami az MS-SQL adatbázistól is függ, végül magát az adatbázist a legördülő menüből. Következésképp az adatbázisnak itt már léteznie kell, mielőtt azt a VISION-höz hozzárendelnénk. Új adatbázisokat MSSQL esetén a Microsoft Enterprise Manager-ével készíthetünk, de annak részletezése nem tárgya e dokumentáiónak. Befejezés előtt célszerű még megnyomni a Kapcsolat tesztelése gombot. Abban az esetben, ha a megadott adatbázison belül még nincs Log, Ack és Summary tábla (ezek szükségesek az alarmrendszer működtetéséhez), akkor azokat a VISION létrehozza számunkra, de előtte még megerősítést kér: Ezután létrehozza a szükséges Log, Ack és Summary táblákat az új adatázisban és az esemény naplónkat átteszi ide. ) Amenyiben eltérünk a Microsoft Access-től, a fájlnév beállítása sem működik többé, mivel új adatbázis készítésére a rendszer csak MS-Access esetén képes. Az adatok archiválását és karbantartását is máképp kell tehát ebben az esetben megoldani. Szerencsére az elterjedet SQL adatbázis kezelő rendszerek erre változatos lehetőséget kínálnak.


239

12

2.4. Hálózat kezelés

A hálózat kezelés automatizmusait tartalmazza ez a konfigurációs ablak. Az alaphelyzeti beállítás ui. egy automatikusan konfigurált szerver-kliens rendszer jelent úgy, hogy attól függően lesz szerver, vagy kliens a programunk, hogy annak elérési útja a lokális diszkre, vagy egy távoli számítógépre mutat. Konkrétan abban az esetben, ha a projekt elérési újta \\rel kezdődik (ez a lokális hálózati címzés alapesete), akkor a program kliensként fog elindulni, és a kliensek egyéb paraméterei beállítás vonatkozik rá, egyébként szerverként és a szerver további beállítása opciókat használja. Érdemes ezeket a beállításokat megtartani, s így az alkalmazásunk automatikusan szerverkliens rendszerű lesz: elegendő megkeresni egy tallózóval az alkalmazásunkat tartalmazó számítógépet a hálózaton, abban kikeresni a _VPR.EXE indítóprogramot (\bin), majd kiválasztani a projektet. Ezzel elindul a kliens és – amennyiben már fut – össekapcsolódik a szerverrel. Ez az ún. telepítés nélküli hálózatok esete, amiről részletesebb információkat a hálózat kezelésről szóló dokumentációban talál. További részletezés nélkül, ezen a konfigurációs képen adható meg a dupla-szerveres konfiguráció két számítógépe, valamint az ún. extra hálózati csomópontok, amelyek az alaphálózati konfiguráción felül ún. tranzakció-optimalizált (modem-es) hálózatokat és Webes hálózatokat takarnak. Ezek részletes ismertetését is a már említett dokumentumban találhatja meg. Még annyit, hogy az extra hálózatok egyben dinamikusak is, tehát nem feltétlenül aktívak a program teljes futása alatt. Tipikus példa a Web, ahol a felhasználó bármikor ráléphet a rendszerünkre egy browser-ből, de a modem-es hálózati kapcsolat sem folyamatos általában, hanem adott feltételekkel építjük fel, megadva egy telefonszámot, vagy az IP címet. Ezekre a hálózati műveletekre a VISION-ben külön parancskészlet szolgál (NetListen, NetConnect, NetClear, NetDisconnet, stb.).

240


12

2.5. Alarmok

A VISION program az alarmokat 8 csoportra és 3 típusra osztja. A 8 csoport szabadon konfgurálható, megadható a csoport neve, ikonszíne (ami az eseménynaplóban mutatja az esemény prioritását), valamint az esemény három típusához (bekövetkezés, megszűnés, nyugtázás) tartozó szöveges megnevezéseket. Lényegében ezt adja meg az alarm konfguráció táblázata. Ezen kívül tartalmazza a csoportok kiválasztását (azokat az esemény-csoportokat, amelyek az esemény naplóban látszanak), azt, hogy szükséges-e őket nyugtázni, legyen-e hangjelzés, s hogy kezelje-e az egyes eseményeket a rendszer automatikusan. Ez utóbbival kapcsolatban kell rögzíteni, hogy a VISION rendszer maga is képes pár esemény-típus automatikus naplózására. Ilyenek a rendszerbe való be- és kilépés, a felhasználó be- kiléptetése, a programból kiadott parancsok, a változások, valamint az analóg mérések minimum-maximum vizsgálata. Ezen felül az eseményeket egyedileg kell konfigurálni a rendszer számára, megadva a feltételt, az esemény csoportját és a naplóba írandó üzenetet. Természetes, hogy a rendszer által automatikusan kezelt eseményekkel van a legkevesebb munka, ezért érdemes is őket használni. A következőket kell tudni: Amennyiben az analóg változók min-max figyelésének a naplózását engedélyezni akarjuk, választanunk kell egy alkalmas alarm csoportot. Alaphelyzetben ez az 5-ös csoport. Ezután a táblázat utolsó oszlopában (R) engedélyeznünk kell (kék pipa), majd a Rendszer alarmkezelés menücsoportban az Analóg hibához beírni az 5-öt. A program ebből tudja, hogy melyik csoportban kell kezelnie az analóg változók értéktartomány túllépését, külön engedélyezni pedig azért szükséges, mert nem biztos, hogy az analóg hibák rendszer általi kezelését egyáltalán használni akarjuk. A csoportok, típusok és a rendszer alarm-kezelésen kívül a napló időformátumát és a kiválasztás alapértékét állíthatjuk még be az alarm-konfigurációs lapon. Az alarmok részletes leírását a 9-ik fejezet (Események kezelése) tartalmazza.


241

12

2.6. Alarm nyomtatás

Az alarmok nyomtatása lapon adhatjuk meg a nyomtatót, állíthatjuk be a betűtípust és és a lap formátumát. Ezek rendre a lapszámozás, sorszámozás, fejléc és lábléc opciók. Ahogy illik, állítható a margó, valamint az eseménynapló egyes oszlopainak a szélessége (alarm oszlopok). Ezt azért kell külön beállíthatóvá tenni, mert a leghosszabb esemény, ami meghatározza a legszélesebb oszlop, a szöveg szélességét (fent 75 mm), erősen változhat alkalmazásonként. Ugyanez a helyzet a dátum-idővel is. Attól függően, hogy milyen időformátumot választottunk, a helyigénye is lehet jóval kisebb, mintha egyébként az évezredet is kiírjuk és a másodpercet. Mindez ráadásul attól is függ, hogy az egyes oszlopok közül melyeket kívánjuk megjeleníteni a nyomtatási lapon. Például a változó név és a struktúra-hozzárendelésért felelős terület nem nyomtatódik alaphelyzetben, de levehető a tagis, ami inkább az események azonosításáért felel, nyomtatásban nincs sok haszna. A konkrét beállítást a méretarányos nyomtatási lapon ellenőrizhetjük. Ha valamelyik oszlopra rámutatunk, vagy épp az adott mező szélességét állítjuk (up-down kontrollok), akkor a neki megfelelő oszlop kékre színeződik a nyomtatási lapon. Végül választhatunk álló és fekvő lap beállítást is, szükség szerint.

12

242


2.7. Jelentés nyomtatás

Kiválasztott jelentés-nyomtatók

A jelentés nyomtatás nagyon hasonló beállításokat tartalmaz, mint az előző fejezetben részletezett alarm nyomtatás; itt is állítható a margó, valamint a lapszámozás, a sorszámozás, a fejléc és a lábléc. Külön ki kell azonban emelni a nyomtatók hozzárendelhetőségét. Abban az esetben, ha egyszerre több jelentés-nyomtatót kell használni, valahogy hivatkozni is kell rá, hogy épp melyiket. Az alkalmazásban azonban nem célszerű szerepeltetni a nyomtatónak a nevét, mert az megnehezítené az alkalmazás mozgatását, és az alkalmazást is módosítani kellene, ha a nyomtatót kicserélik. Ezért a nyomtatás során csak egy index-et adunk meg, a nyomtató sorszámát, ahogy ezen a konfigurációs lapon szerepel. A fenti beállítás például két nyomtatót tartalmaz, egy fekete-fehér és egy színes HP nyomtatót. Az elsőre az 1-es, a másodikra a 2-es index-szel hivatkozunk. Megjegyezve, hogy az alkalmazás szerkesztése során a szervíz varázsló persze nem az index-re, hanem magára a nyomtatóra kérdez rá, így nem kell emlékeznünk, hogy mi a nyomtatók sorrendje. De az alkalmazásba már csak az index íródik. Amennyiben egy nyomtató is elég az adott alkalmazáshoz, lehetőleg ne rendeljünk nyomtatót a konfigurációhoz sem. Használjuk ehelyett az alapértélmezett (default) nyomtatót. Ez a konfiguráció alaphelyzete is egyébiránt (ld. default nyomtató használata checkbox).

12


243

2.8. Felhasználói profil

A felhasználói profilban állíthatjuk be a kívánt menürendszert és programunk sílusát. A VISION program rendkívül sokféleképpen beállítható. Ezt foglalja össze a következő táblázat: Megjelenítés Klasszikus Stilizált

Menüstílus Nem választható, formátuma attól függően változik, hogy XP-t vagy Windows 2000-et használunk-e, ill. XP-t, de klasszikus stílusban. Ez a beállítás felel meg az általánosan használtnak Klasszikus: Klasszikus menürendszer még akkor is, ha egyébként XP témákat választottunk Office 2000: Microsoft Office 2000 stílus Office 2003: Microsoft Office 2003 stílus, színátmenetes, színes menük; a leggyakoribb kék beállításnál ilyenkor maga a menü is kék, egyébként követi az XP témák színkonvencióit. Office 2003 Gray: A Microsoft legújabb színbeállítása, visszatérés a szürke árnyalatokhoz, függetlenítve a menü színét az XP témáktól, de marad a színátmenet

Állítható ezenkívül a menü transzparenciája és készíthetünk animált menüt, ami a szokásos megoldás szerint Slide, Fade és Unfold lehet, ill. default, ha a Windows-ban érvényes beállítást kívánjuk használni. Érdemes ezeket a beállításokat kipróbálni. Annál is inkább, mivel a program nem igényel újraindítást, az egyes beállításokat azonnal megtekinthetjük és eldönthetjük, hogy melyik tetszik közülük. A többi menü-csoport funkciója a következő: 244


12

Windows stílus:

A menürendszeren kívül állítható még az alkalmazás stílusa is. Ahogy a menük, a VISION ablakai is lehetnek klasszikus, vagy XP stílusúak. Tehát XP témákra állított op. rendszeren is megjeleníthetünk klasszikus stílusú képeket a VISION-ben, de állíthatjuk az XP stílusú ablakok színét is függetlenül a Windows beállításaitól.

Eszközmenü:

A Win2K sík / színátmenetes nyomógomboknak csak klasszikus stílusban van jelentőssége és ugyanez a helyzet a bontott eszközmenüvel is. Ez utóbbi azt jelenti, hogy az eszközsáv egyes nyomógomb-csoportjait önállóan mozgathatóvá tesszük, ugyanúgy, mint az office-ban például. A bontott eszközmenüt átcsoportosíthatjuk és átdokkolhatjuk a főablakon belül, de a stilizált eszközmenünél ez a funkció nem engedélyezett.

Funkció menü:

Ezzel az opcióval engedélyezhetjük a funkció menük megjelenítését a főablak alsó sorában, F1-től F10-ig. Bekapcsolása / kikapcsolása után a programot úra kell indítani, hogy a beállítás érvényre jusson. A funkciómenük ma már elavult megoldásnak számítanak, hiszen az F3-F8 gomokra nem lehet feltenni az összes menüt és egyébként is struktúrákat használunk, valamint ablakokat. A funkció menükhöz a képek hozzárendelése a VPR fájlban, szöveges szerkesztéssel lehetséges úgy, hogy a rövid név után felsoroljuk a képek nevét elsőként az F3-hoz, majd az F4-hez, stb. Például az alábbi megadásnál az F3 funkciója képenként változik (mindig a sorban következő kép), míg az F4-é fix (GYTD). Képnév

Rajzmód Rövidnév

F3

F4

Fokep: Audit: GYTD:

Redraw, "Fõkép", ”Audit”, ”GYTD” Redraw, "Audit Trail", ”GYTD”, ”GYTD” Redraw, "ms-os trendek", ” Fokep”, ”GYTD”

stb.

Alarm SQL:

A hibaüzenet engedélyezése opció arra szolgál, hogy hibás alarm SQL művelet esetén kajunk-e hibajelzést.

Processz prioritás:

A VISION program háromféle prioritási szinten képes futni: alacsony, normál és magas. Főleg ez utóbbinak van értelme: a magas prioritásra állított program taszkjai sokkal egyenletesebben „ketyegnek”, mint a normál beállítású programé. Ezenkívül magasabb prioritáson, ami a gyakorlatban azt eredményezi, hogy a kommunikáció, a ciklikus feldolgozás, a trendkészítés, stb. akkor is érvényre jut, ha egyébként a Windows-nak épp más dolga van, például egy vírusellenőrzés, vagy egy archiváló utility fut rajta. Magas prioritást azonban csak erősebb gépeken érdemes beállítani – sajnos ezáltal pont azokon a masinákon, ahol a gyorsabb processzor miatt annak nincs is olyan nagy jelentőssége. Különben előfordulhat, hogy a Window más taszkjai nem jutnak érvényre (pl. nyomtatás, hálózati kiszolgálás). Fontos az is, hogy a VISION se fogja a processzort. Optmálus hatást 20% alatti processzor kihasználtság alatt remélhetünk.


245

12

2.9. Duál monitor

A rendszer képes többmonitoros megjelenítésre, amennyiben a grafikus kártyánk is támogatja azt. Manapság könnyen beszerezhetőek az ún. dual-head (két meghajtós) grafikus kártyák – innen is kapta ez az opció a nevét. Azonban a monitorok száma 4-ig bővíthető. A beállításhoz egyszerűan arra a másodlagos feliratú boxra kell kattintani, amelyik a kívánt irányban áll. A plusz monitorok számát pedig 1-től 3-ig. A program csak vonalba rendezett monitorokat kezel – vízszintesen vagy függőlegesen. Többmonitoros üzemmódban a program indítása után minden monitoron megjelenik a főkép, de onnan monitoronként eltérő további képekre mehetünk át, vagy rendszerképeket választhatunk (pl. trendet, alarmlistát, adatgyűjtést, stb.). Így a különböző monitorok végül különböző alrendszereket és információkat mutatnak. Gyerek ablak, ez

Megjegyezzük, hogy a másodlagos sokszorozható a másodlagos monitorok képkerete nem teljesen monitorokon ugyanaz, mint a főmonitoré, mivel azok a főablaknak csak a gyerekeit mutatják, vagyis azokat az ablakokat sokszorozzák, ami a főablakon belül látszik. A VISION projekt egy MDI alkalmazás (Multiple Document Interface), ami főablakból és gyerek 12 ablakokból áll (a főablakban ezeket a gyerek ablakokat lehet kaszkádosítani, függőlegesen, vízszintesen elrendezni, maximalizálni, stb.). Mármost a projektmenedzser, a legördülő menü, az eszközmenü, az eseménylista utolsó pár sora és a státuszsor ennek a főablaknak képezik a részét, ami a fentiekből következően csak az elsődleges monitoron látszik. 246


2.10. Audit Trail

Az Audit Trail egy adat nyomkövetési eljárás, ami a 21 CFR szabvány része (Part 11). Ez a szabvány beépült a VISION programba is és elsősorban arra szolgál, hogy az adatok története visszakövethető legyen. Amikor a felhasználó átír egy paramétert, a program képes rögzíteni a régi és az új értéket, az adatmódosításért felelős személy nevét, a módosítás okát, idejét és opcionálisan egy megjegyzést. Ezek az információk azután eltárolódnak az Audit naplóban, ami az eseményekhez hasonlóan visszaolvasható és idő, adatbázis név, valamint felhasználó szerint szelektálható, majd nyomtatható, vagy konvertálható Excel-be, PDF-be, HTML formátumba, stb. A fent látható konfigurációs lapon mindez az alkalmazás fájlrendszerére korlátozódik, s mint ilyen, az alkalmazói fájlrendszer módosításának a nyomkövetésére szolgál. Ezt nevezzük verifikálásnak. Az Audit Trail tehát egy elektronikus építési napló, amiben rögzülhet az alkalmazás képeinek, változóinak, programjainak a módosítása is, bennük az előző állapotokkal, valamint a módosítás okával, idejével, felelősével, stb., csakúgy, mint az adatmódosítások esetében. A konfigurációs lap betekintést enged ezenkívül magába a szabványba is (részletes informáiók a CFR szabványról).

12


247

2.11. Képek alapbeállításai

A képek alapbeállításainal a ciklusidők játszák a legfontosabb szerepet: Képfrissítési ciklus: A képprogram lefutásának gyakorisága azt határozza meg, hogy az objektumok milyen gyorsan frissüljenek, az új adatok milyen gyorsan jelenjenek meg rajtuk. Az alaphelyzet szerinti 100ms az alkalmazások zömének megfelel, sőt lehet akár 500ms-re is állítani, mivel a legtöbb rendszerben a kommunikáció ennél jobban korlátoz. Szerencsére a folytonos mozgást igénylő mozgó kitöltések és animációk más ciklus szerint frissülnek: Animációs ciklus:

A képen található mozgó kitöltési minták és animációk frissítési idejét adja meg. A 30ms alapbeállítás nagyjából 33 frame/másodperc sebességnek felel meg, ami az emberi szem számára folyamatos mozgást jelent. Előfordulhat azonban, hogy még ezt is lassítani kell, vagyis 50-re esetleg 100ms-ra felmenni, mert a képeinken nagyszámú animáció fut és gép teljesítménye véges.

A ciklusidőkkel kapcsolatban az az alapszabály, hogy a program lehetőleg ne terhelje jobban a processzort 50%-nál. Mivel pedig az esetek döntő többségében a grafika korlátoz, épp ezekkel a ciklusidőkkel állítható be a kívánt sebesség. A ciklusidők képenként külön is beállíthatók, vagyis esetenként eltérhetünk az itt megadott értékektől. Villogtatás ciklusa:

248

A villogó objektumok villogási sebessége állítható be itt. Alapértéke 500 ms.


12

Gyorsítótár:

A képeket a rendszer memóriában cache-eli, hogy gyorsabb legyen a felrajzolásuk a képek közötti lépegetés során. A cache idővel is ürül (1 perc) és korlátozott a memóriában tárolt képek száma. Ebben a menücsoportban a gyorsítótár engedélyezése és mérete állítható be.

Generátor nyelv:

A VISION programmal többnyelvű alkalmazásokat is készíthetünk. Ez a legegyszerűbben úgy valósítható meg, hogy a szövegek elé egy ‘@’ karaktert gépelünk. A program ebből tudja, hogy az adott szöveget fel kell vennie egy Excel táblába és le kell fordítania egy abban megadott másik nyelvre. A szótárat tehát a programból hozzuk létre, automatikusan. A generáló nyelv megadására azért van szükség, hogy a program tudja, hogy az általunk bevitt szövegek milyen nyelven íródnak, vagyis az Excel melyik oszlopába kell azt beírni. Hogy jobban megértsük az Excel-re épülő többnyelvűség mechanizmusát, egy rövid példát mutatunk a rendszer saját, többnyelvű adatbázisából:

Képskálázás:

A VISION képek vektorgrafikus képződmények, egy adott felhasználói koordináta rendszer van leképezve a fizikai képsíkra. A rendszer mindezt automatikusan számítja ki úgy, hogy a megadott fizikai felbontás 8-ad részét rendeli a felhasználói koordináták végértékéhez. A képen az 1024x768 felbontáshoz tartozó 128x96 látható. Azért oszt 2 hatványával, mert ezáltal biztosítható, hogy ne legyen kerekítési hiba. A képskálázásnál ez az alapérték változtatható meg.

Területi beállítások: A számok és az idő konverziós formátuma adható meg ebben a menücsoportban. Beállíthatjuk az ezresek ábrázolásának a módát (ezresek szétválasztása), a tizedes karakterét, valamint a dátumot és az időt. Azt gondolhatnánk, hogy a dátum és az idő beállítását érdemes inkább a Windows-ra bízni, hiszen a vezérlőpultban ugyanúgy megtalálhatók ezek a lehetőségek. De ez mégsem mindig praktikus, hiszen előfordulthat, hogy az alkalmazást több számítógépen is nézni akarják, az ugyanakkor nem kívánatos, hogy a képeken eltérő formátumú számok és idő jelenjen meg. Ezért lehet hát szükséges a Windows-tól független beállítás.


249

12

2.12. Redundancia

A VISION program képes az adatok replikálására és a szerver funkciók megosztására is két vagy több számítógép között. A leggyakrabban alkalmazott beállításnál két szerver számítógépet üzemeltetünk, amelyek közül az egyik az aktív, a másik pedig az ún. befigyelő állomás. A befigyelő állomás valójában egy hagyományos kliens, ami azonban folyamatosan másolja is a szerver adatbázisait a saját, lokális könyvtárába. Amennyiben a szerver számítógép leáll, vagy nem válaszol, a befigyelő kliens átveszi a szerver funkciókat és a legutoljára lemásolt adatbázisokkal folytatja a szerver működését. A kliensek pedig átkonnektálnak az új szerverre. Amikor a szervert kijavítják és újraindítják, az lép rá a rendszerre befigyelő kliensként és kezdi másolni az új szerver adatbázisait a saját, lokális könyvtárába. A redundancia alapesetben a rendszer saját adatbázisait foglalja magában, de a konfigurációban további fájlokkal bővíthető, pl. Access adatbázisokkal, vagy napló-fájlokkal és a ciklusideje is szabadon állítható, sőt beállítható órás, napi, heti, stb. ciklikusság is, amint az a konfigurációs lapon látszik. A tükörkönyvtár megadására akkor van szükség, ha nem duplaszerveres a rendszerünk, csak redundáns (többszörös, avagy biztonságos adattárolású). Ebben az esetben tehát azt is meg kell mondanunk, hogy az adatokat milyen célkönyvtárba másolja a rendszer.

12

250


2.13. Adat struktúrák

Mint ismeretes, struktúrák alkalmazásával a felhasználó igényeihez tudjuk igazítani alkalmazásunkat, visszaadva annak szerkezetét, feladatát, az állomások, üzemek geografikus elhelyezkedését, az alá- és föléredeltségi viszonyokat, stb. A struktúrákról szóló fejezetben bemutattuk, hogy az nemcsak menürendszerek megalkotására alkalmas, de az alarmok, a trendek és az adatgyűjtés strukturálására is. Nos, ez az összerendelés végezhető el az Adat struktúrák konfigurációs lapon, az Adatbázisokhoz rendelt struktúrák menücsoportban. A Unit-struktúra hozzáadásával elérhetjük, hogy a unit-ok szerkezete is láthatóvá váljék ezekben a leírókban, azokhoz mintegy hozzáfűzve a unit-ok fa-szerkezetét. Végül az alarm információs ablakról a következőket érdemes tudni. Lehetőség van arra, hogy az esemény naplóhoz külön kiértékelő képet, táblázatot, listát rendeljünk. Amikor kiválasztunk egy eseményt, annak környezetében a program felrajzolhat egy trendet, készíthet egy szelektált SQL adatbázis táblát, vagy megjeleleníthet egy video felvételt. Így az ajtónyitás esemény sorára kattintva megnézhetjük, hogy ki jött be az ajtón. Az alarm információs ablak valójában egy overdraw kép (window), amibe azt rajzolunk, amit csak akarunk: szelektált trendet, táblát vagy videoképet, akár kombinációban és feltételesen. Majd ezen a konfigurációs oldalon hozzárendeljük képünet a naplóhoz.

12


251

Íme egy példa arra, hogyan jelenik meg az alarm információ az eseménynaplóban, amikor annak soraira duplán kattintunk: Ezt a “gombot” kell megnyomni

12

252


2.14. Multiprocesszálás

Alapban a rendszer a Windows-ra bízza a kommunikáció, a vezérlések, a ciklikus taszkok, az esemény-kezelés, valamint a trendelés, az adatgyűjtés és a naplózás végrehajtását. A VISION tehát egy ún. multithreading alkalmazás. Sajnos azonban az a helyzet, hogy a számítógépek nem mindegyike végzi megbízhatóan ezt a műveletet - a fejlesztő tapasztalatai, ill. a rendszerintegrátoroktól érkező visszajelzések alapján 100-ból. kb. 1 esetben van baj ezzel a Windows működéssel: a különálló szálak elhalnak, vagy leállnak egy idő után. Valószínűsíthető, hogy ez nem HW és nem is SW hiba – hiszen a számítógépek többségén nem jelentkezik –, hanem egy szerencsétlen op.rendszer – számítógép kombináció. Néhány esetben ezeken a gépeken a Hyperthreading kikapcsolása segít, de még jobb, ha magában a VISION-ben tiltjuk le ilyenkor a többszálúságot, s bízzuk a Windows helyett a VISION-re a taszkok indítását. A kommunikáció Watchdog funkció és biztonságot növelő további beállítás, amely képes arra, hogy amennyiben a kommunikációs taszk leáll, azt újra betölti és újraindítja, mintha csak magát a programot indítottuk volna újra. Erre alapesetben 1 perc leállás után kerül sor. Az esetek túlnyomó többségében erre az opcióra sincs szükség, de nem csinálunk semmi bajt, ha mégis meghagyjuk. Végül az automatikus adat exporttal át lehet küldeni az adatokat bármilyen SQL szerverbe, s ezáltal más gyártótól származó adatfeldolgozó, felügyeleti programba, ill. a VISION-höz tartozó CMMS karbantartás-menedzselő rendszerbe. Ez úgy történik – amennyiben engedélyeztük –, hogy a rendszer ciklikusan átmásol egy meghatározott mennyiségű változót a táblánál megadott SQL táblába. Ennek ciklusidejét és az egy lépésben frissíett változómennyiséget (léptetés) adhatjuk meg a konfigurációban. Emellett a rendszer képes az adatfrissítésre változásra is. Ilyenkor a ciklikus beállítás nem hatásos.


253

12

Amenyiben a transzfer táblát nem adtuk meg, a rendszer T_Vision tábla nevet használ. Egyébként az általunk megadottat. A tábla szerkezete pedig a következő (MS-SQL Enterprise Manager-ből ollózva):

Amennyiben a tábla nem létezik, a rendszer az itt látható táblát hozza létre. Az itt feltüntetett mezőnevektől lehet eltérő is az adatbázis – ezzel megkönnyítve a meglévő rendszerekhez való illesztést –, de akkor a mezők sorrendje számít (idő – változónév – leírás – érték – mértékegység). Például hasonló a szerkezete a DeltaV transzfer tábláinak is, a mezők sorrendje pedig azonos.

12

254


Video kliens

Tartalomjegyzék: 1. Bevezetés............................................................................................................................ 256 2. Video kliens komponensek ................................................................................................ 256 2.1. Video szerver............................................................................................................... 256 2.2. Video stream ............................................................................................................... 258 2.3. Csatlakozás a Video szerverre és kapcsolat bontása ................................................... 259


A1

VISION Video kliens

255

1. Bevezetés A program tartalmaz olyan komponenseket, amelyek segítségével IP-alapú Video kliens programot készíthetünk. A komponens jelenleg az Xperts cég által fejlesztett és forgalmazott NetAVIS video szerverekhez képes csatlakozni. A NetAVIS eszközök a SNAP (Simple NetAVIS Access Protocol) protokollt használják, a SNAPI.DLL illesztő (Provider) pedig ezt illeszti a VISION-höz. Maga a konfiguráció és a használat rendkívül egyszerű. Ezt ismertetjük a következő fejezetekben.

2. Video kliens komponensek A rendszerhez a következő Video kliens komponensek tartoznak Video szerver (NetAVIS) Video stream megjelenítő (VS) Idővonal (TLN) A Video szervert az adatbázisoknál kell beállítani, az ott található szerver objektum-csoporton belül. A Video stream és az idővonal pedig egyaránt grafikus komponensek

2.1. Video szerver A Video szerver az adatbázisoknál kerül beállításra, ezért először egy adatbázis-leírót kell létrehozni, amennyiben még nem létezik. Az eljárás ugyanaz, mint az adatbázisok ismertetésénél. Amennyiben az alkalmazást default alkalmazásként hoztuk létre (a default alkalmazás tartalmaz egy üres fájlrendszert), egy adatbázis taszkunk már van; ha üres alkalmazásként, akkor a taszkot először le kell gyártanunk a projektmenedzser Adatbázisok sorára jobb egérgombbal kattintva, majd onnan Új adatbázis leíró-t választva: Ide kattintva specifikálhatjuk az új adatbázis leírót

A1 Az új adatbázis képen szerkesztés állapotban az alábbi objektumok látszanak:

256

VISION Video kliens

Innen kell kiválasztanunk a szervert – a legegyszerűbben drag-&-drop technikával felhelyezhetjük a grafikus képernyőre:

Maga a beállítás ezek után pontosan ugyanazon az elven, a tulajdonságszerkesztő segítségével történik, mint a többi objektumnak. A legfontosabb (mindenképp beállítandó) mezők a következők: URL:

A NetAVIS szerver internetes elérési útja Felhasználó név: Itt kell megadnunk a szerver adminisztrátora által rendelkezésünkre bocsájtott felhasználó nevet és Kulcsszó: kulcsszót, ami a belépéshez szükséges Kamerafa: Egy általunk korábban létrehozott prototipus struktúra leíró címe, ami tartalmazza majd az adott szerverről leolvasható kamera fát. A kamera fa előállítása automatikus, a szerverre történő kapcsolódáskor megtörténik, ezért ezzel a struktúrával nem kell bajlódnunk. A többi mező elvileg úgy áll, ahogy kell, azokat nem kell módosítanunk. • • •

•

Az Adatszolgáltató magának a drivernek a nevét adja meg, ami a NetAVIS protokoll esetében SNAPI.DLL. A Path pedig a NetAVIS szervereken belüli elérési útja jelenleg a szerver adatforgalmának. A Kezdőszint beállításával azt érhetjük el, hogy a kamera fa ne a gyökérnél, hanem annál valamivel bejjebb kezdődjön. Ugyanis van még két, bennünket nem feltétlen érdeklő további szint is a kamera fában (Cameras + Európa), és csak az után következik a lényegi struktúra. Az Autobelépéssel elérhető, hogy a program indításakor automatikusan rákapcsolódjon a szerverre, de ezt az üzemmódot nem ajánljuk. Mint később látni fogjuk van erre egy külön VISION parancs (ConnectServer). Így a felhasználói képernyőn köthetjük hozzá a belépésünket egy nyomógombhoz.

Amennyiben mindent beállítottunk, kimentjük, és a rendszer máris kész, hogy üzeneteket fogadjon a szervertől.

VISION Video kliens

257

A1

2.2. Video stream A Video stream komponens jeleníti meg az adott kamerát. Ez a komponens természetesen valódi grafikus elem, ezért a képszerkesztésnél találjuk meg. A megfelelő VS objektumot innen tehetjük fel a képernyőre. Normál esetben a VS-t nem kell skálázni, mivel a képméret automatikusan adódik a streamer megfelelő tulajdonságából, hiszen ne felejtsük el, hogy az adat interneten (intraneten) keresztül érkezik, s ezért eleve az elvárásainknak megfelelő képmeret szerint kell azt kérni, nem pedig utólag zsugorítani (s ezzel értékes képtartalmat veszíteni), vagy nagyítani (s ezzel feleslegesen torzítani). Mindazonáltal lehet a VS-t kicsinyítani, nagyítani – proporcionálisan - sőt eltorzítani is, amennyiben egy meghatározott helyre kell beigazítani a képünket. Persze ilyenkor is törekedni kell az eredeti képtartalomnek megfelelő közelítő méretre. A legfontosabb VS-tulajdonságokat mutatja a következő ábra. Ezek között található meg a szerver kiválasztására szolgáló legördülő menü, ahol az általunk korábban felvett NetAVIS szerverek nevei láthatók (ennek defaultja a NetAVIS), valamint a lejátszást vezérlő tulajdonságok. A kamera tartalmazza magának a kamerának az azonosítóját, ami egy egész érték. Ezt azonban persze változóhoz kell rendelnünk, mivel a kamerát a felhasználónak célszerű hozzárendelnie a VS-hez. Pontosan erre szolgál a kamera fa struktúra, amit a legegyszerűbben egy Popup menüvel rendelhetünk a VShez. Ez látható a Popup menü sorában. A VS felhelyezése után, vagy után tehát egy Popup menü objektumot is fel kell raknunk a képre, majd a Popup menü sorában összekapcsolni a VS-sel. Na ehhez a menüobjektumhoz kell hozzárendelnünk a kamera fa struktúrát. Ezek után a program a következőképpen fog működni. Amikor a jobb egérgombbal rákattintunk a VSre, akkor a popup menu objektumnál megadott kamera fa struktúra láthatóvá válik. Maga a kiválasztás a popup menü kiválasztás eseményét aktiválja, tehát a a konkrét kamerát innen kell kiolvasni a SelectedItem tulajdonságon keresztül (ez egy string, noha csak számot tartalmaz, ezért azt át kell konvertálnunk numerikus változóvá). Mivel azonban popup menüből csak egy van, VS-ből viszont annál több, annyi kamera változó szükséges, amennyi VS. Ezt a hozzárendelést tehát már célszerű a VS Popup kiválasztás eseményénél megadni: A megértést elősegítendő összefoglaljuk a popup menü eseményszekvenciáját:

258

VISION Video kliens

A1

1. Jobb egérgomb a VS-en, lefut a VS Kontext eseménye, majd a kamera fa megjelnik 2. Kiválasztjuk a megfelelő kamerát, ekkor lefut a Popup objektum kiválasztás eseménye (ez a közös eseménykiszolgálója az egyetlen kamera fa struktúrának) 3. Lefut a VS Popup kiválasztás eseménye, ami viszont már ismét a Popup gazdájának az eseménye, ahol a Popup közös eseménykiszolgálója által kiolvasott kamera index került letárolásra. Nézzük a VS további fontos tulajdonságait: Lejátszási sebesség: Képméret: Minőség: Video formátum:

Ez a frame-per-second érték hatásozza meg, hogy a szerver milyen sebességgel fog nekünk képeket küldeni, tipikusan 10 és 30 között változik Lehet vsSmall (160x120), vsMedium (320x240) és vsLarga (640x480) A video szerver által küldött kép minősége lehet vqLow (alacsony minőség), vqMedium (átlagos minőség) és vqHigh (magas minőség) vfJpeg és vfMbeg közül választhatunk

Magának a képnek a megjelenítése automatikus, amennyiben a video szerverre csatlakozunk.

2.3. Csatlakozás a Video szerverre és kapcsolat bontása A kapcsolat felépítését – mint említettük – célszerű a programból, pl. egy nyomógombról vezérelni. A szerverre való kapcsolódás parancsa: ConnectServer ServerName, URL, UserName, Password Ahol ServerName: URL: UserName és Password:

A szerver NetAVIS szervernél megadott neve. Defaultja: NetAVIS Opcionális argumentum, a szerver URL-je Belépési adatok, ugyancsak opcionális

Amenyiben az opcionális paraméterek valamelyikét nem adtuk meg, a program a szerver objektumnál megadott adatokat veszi. A lekapcsolódás parancsa: DisconnectServer ServerName A Video kliens működése és a tulajdonságok megadása, ill. együttműködése tanulmányozható a program Features demóján.

VISION Video kliens

259

A1

A1

260

VISION Video kliens

VISION Kommunikációs driver-ek működése és illesztése A kommunikációs driverek DLL-ek formájában csatolhatók a VISION-höz, felépítésüket a VISION telepítési könyvtára alatt, a COMM-ban található megannyi példa szemlélteti, Delphi-ben megírva. A driver működtetéséért a SERVICE.PAS forrásfájl felel, ez tartalmazza az ún. szervíz hívásokat. Az összes hívást a VISION kezdeményezi, adott sorrendben adva ki őket. A hívási sorrendek a következők:

1. Hívási sorrendek 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 1.7.

Csak egyszer hívódik meg a driver betöltése után - ebben a sorrendben: SETUP_SERVICE, CONFIG_SERVICE Ugyancsak egyszer hívódik meg, de egyben a kommunikációs VAL program valamennyi módosítása után is az INIT_SERVICE Ezután a szekvencia: SEND_SERVICE, STATUS_SERVICE, POLL_SERVICE, STATUS_SERVICE (majd RECEIVE_SERVICE v. RESET_SERVICE) Közben mindig - függetlenül az aktuális állapottól - CYCLE_SERVICE A státusztól függően (MR) hívódik meg a RECEIVE_SERVICE Ha nincs válasz a timeout idején belül (a DR nem állítódik egybe és sem RR, sem MR nem történik): RESET_SERVICE Program bezárásakor hívódik meg - csak egyszer: CLOSE_SERVICE

Természetesen a SEND_SERVICE meghívásának feltétele még, hogy az adott pillanatban legyen engedélyezett output üzenet (Enable ill. Szemafor), a POLL_SERVICE meghívásának pedig ugyanez a feltétele input-ra (Enable ill. Szemafor). Normális esetben a SEND_SERVICE meghívása után a DR-t törölni kell a státuszból, majd az adás végén visszaírni 1-be (ebből tudja a VISION, hogy az adás sikeresen befejeződött), a POLL_SERVICE befejeződését pedig az RR, vagy az MR bit jelzi. Az RR-t akkor lehet kiadni, ha már a POLL_SERVICE-en belül átadható a lekérdezett adat, egyébként az MR-t kell kiadni, mire a program meghívja a RECEIVE_SERVICE-t, ahol az adat a VISION-nek feladható.

2. Szervízhívások funkciója 2.1. SETUP_SERVICE 2.2. CONFIG_SERVICE

2.3. INIT_SERVICE 2.4. RESET_SERVICE 2.5. CYCLE_SERVICE 2.6. CONNECT_SERVICE 2.7. MESSAGE_SERVICE 2.8. SEND_SERVICE 2.9. POLL_SERVICE 2.10. STATUS_SERVICE 2.11. RECEIVE_SERVICE 2.12. CLOSE_SERVICE

Program saját allokációinak , instance-ainak a létrehozása, inicializálása Esetlegesen szükséges inicialilzáló fájl felolvasása. A fájl elérési útja – amennyiben az az alkalmazás könyvtárában található – a SETUP_SERVICE-nél átadott Parentdir könyvtár alapján állítandó elő, mivel a default könyvtár egyébként nem definiált. A kommunikácís driver saját működésének az initicializálása Az egyes tranzakciók közös hibaága, ahol magának a küldésnek, ill. a vételnek az inicializálásáról kell gondoskodni Ciklikusan (10ms) meghívott szolgáltatás, ami elsősorban magának az adási- és a vételi protokollnak a levezénylésére szolgál. Extra csomópont azonosító adatok (Host, Port – pl. IP cím és Port) Extra üzenet azonosító adatok (DataType, DataAddr – szövegként) A VISION ezen a híváson keresztül jelzi, hogy adatot kíván küldeni, közvetlenül ez előtt azonban még meghívja a CONNECT- és a MESSAGE szervízeket A VISION ezen a híváson keresztül jelzi, hogy adatot kíván venni, közvetlenül ez előtt azonban még meghívja a CONNECT- és a MESSAGE szervízeket A driver ezen keresztül adja át a VISION-nek a státuszát, amelyből az eldöntheti, hogy az adás (DR), ill. a vétel (RR v. MR) véget ért. Amennyiben a VISION a státuszban MR-t “lát”, meghívja ezt a szolgáltatást, hogy a drivertől felkérje az aktuális adatokat. Program befejezésekor meghívott szolgáltatás, ahol minden instance, thread lezárható

VISION kommunikációs driver-ek

261

A2

3. Paraméterek átadása VISION-ből a driver-nek Két adatcsoport van: 3.1.

MessageType, benne a forrás (sour) és célállomás (dest) címével, az adat azonosítójával (mess) és az adattal, mely outputnál tartalmazza az elküldendő adatokat (data), hosszát pedig a long tartalmazza; vételkor pedig ide kell betölteni a forrásállomástól felolvasott adatokat feltöltve a data-t és a long-ot. A hossz bájtos. A MessafeType tipusú adatstruktúra a SEND-, POLL- és a RECEIVE_SERVICE-ek paraméterei között egyaránt szerepel.

3.2.

A kiterjesztett címzési módok miatt került bevezetésre az X-ben a CONNECT_SERVICE és a MESSAGE_SERVICE. Ez minden egyes SEND- és POLL_SERVICE előtt meghívódik (mindkettő) és bennük átadásra kerül az állomás kiterjesztett címe (Host), mint string (pl. IP cím), a Port, ill az üzenet kiterjesztett azonosítója - ugyancsak stringként: az adat tipusa (DataType) és az adat címe (DataAddr). Ezek azért kellettek, hogy ne legyen szükséges konfigurációs fájlokat gyártani, amelyek az egyes üzenetazonosítókhoz (mess) tartozó kiegészítő adatokat tartalmaznák. Ráadásul ezek az adatok ettől kezdve lehetnek dinamikusak is, mivel a tulajdonságoknal változók és azok kifejezései is generálhatják.

Az Host, Port, DataType, DataAddr teljesen szabadon használható a kért szolgáltatás azonosítására. Megadásukat szemlélteti a következő ábra:

Csomópont tulajdonságai:

CONNECT_SERVICE – Node MessageType.sour / dest – irányfüggően

CONNECT_SERVICE - Host

CONNECT_SERVICE - Port

Üzenet tulajdonságai MessageType.mess

MESSAGE_SERVICE - DataType

MESSAGE_SERVICE - DataAddr

A2

262

VISION kommunikációs driver-ek

VISION X Szimbólumok COMPRESS Air compressor

Compressor #1

Compressor #2

Compressor #3

Compressor #4

AIRCOMP1

COMP1

KOMP2

KOMP3

KOMP4

Input device

Hub

Panel

Monitor 1

Monitor 2

FISHER

HUB

KARTE

MONITOR1

MONITOR2

Mouse

Pc

Printer

Platina Pt100

Sound 1

MOUSE

PC

PRINTER

PT100

SND1

COMPUTER

Sound 2

SND2

A3 VISION X szimbólumok

263

CONSTR Chimney #1

Chimney #2

Tower #1

Tower #2

Tower #3

CHIM1

CHIM2

TOWER1

TOWER2

TOWER3

Travern #1

Travern #2

Travern #3

Travern #4

Travern #5

TRAV1

TRAV2

TRAV3

TRAV4

TRAV5

Travern #6

Travern #10

TRAV6

TRAV10

COOLER Air cooler

Horizontal Cooler #1

Vertikal Cooler #1


Vertikal Cooler #2

AIRCOOL1

COOL1H

COOL1V

COOL2H

COOL2V


Vertikal Cooler #3


Vertikal Cooler #4


COOL3H

COOL3V

COOL4H

COOL4V

COOL5H

Vertikal Cooler #5


Vertikal Cooler #6

Inline Cooler

Surrounding Cooler

A3 264

VISION X szimbólumok

COOL5V

COOL6H

COOL6V

COOLIL

SCOOLER

Oil burner

Cog-wheel 1

Cog-wheel 2

Filter

Flange

BURNER

COG1

COG2

FILTER

FLANGE

Flotator

Flotator 1

Level control

Horiz. manometer

Vert. manometer

FLOT

FLOT1

LEVCON

MANOH

MANOV

Control turbine

Settle

Tap

MTURBINE

SETTLE

TAP

Machine #1

Machine #2

Machine #3

Machine #4

Machine #5

MACH1

MACH2

MACH3

MACH4

MACH5

Machine #6

Machine #7

Machine #8

Machine #9

Transformator 1

DEVICE

MACHINE


265

MACH6

MACH7

Transformator 2

Transformator 3

TRAFO2

TRAFO3

MACH8

MACH9

TRAFO1

METER Flow #1

Flow #2

Meter

Meter #1

Minipond

FLOW1

FLOW2

METER

METER1

MINIPOND

Scale #1

Scale #2

Scale #3

Scale #4

Scale #5

SCALE1

SCALE2

SCALE3

SCALE4

SCALE5

Scale #6

Scale #7

SCALE6

SCALE7

MIXER Mixer #1

MIX1

A3 266


MOTOR M1

M2

M3

M4

M5

M1

M2

M3

M4

M5

M6

Motor #1

Horizontal motor #1

Vertical motor #1

Motor #2

M6

MOTOR1

MOTOR1H

MOTOR1V

MOTOR2

Horizontal motor #2

Vertical motor #2

Motor #3

Horizontal motor #3

Vertical motor #3

MOTOR2H

MOTOR2V

MOTOR3

MOTOR3H

MOTOR3V

Motor #4

Motor #5

Motor #6

Motor #7

Motor #8


267

MOTOR4

MOTOR5

MOTOR6

MOTOR7

MOTOR8

Motor #9

Motor #10

Motor #11

Motor #12

MOTOR9

MOTOR10

MOTOR11

MOTOR12

Pipe #1

Horizontal pipe #1

Vertical pipe #1

Pipe #2

Horizontal pipe #2

PIPE1

PIPE1H

PIPE1V

PIPE2

PIPE2H

Vertical pipe #2

Horizontal pipe #3

Vertical pipe #3

Horizontal pipe #4

Vertical pipe #4

PIPE2V

PIPE3H

PIPE3V

PIPE4H

PIPE4V

Horizontal Stub

Vertical Stub

MOVE Conveyer-belt (up)

CONVUP

PIPES

A3 268


STUBH

STUBV

POWER Electric tower

Horizontal switch #1

Vertical switch #1


Vertical switch #2

ELTOWER

SWITCH1H

SWITCH1V

SWITCH2H

SWITCH2V


Vertical switch #3


Vertical switch #4


SWITCH3H

SWITCH3V

SWITCH4H

SWITCH4V

SWITCH5H

Vertical switch #5

Transformator

SWITCH5V

TRANS

PUMP Horiz. motor pump

Vert. motor pump

Plungered pump

Pump

P1 horizontal

MPUMPH

MPUMPV

PPUMP

PUMP

PUMP1H

P1 vertical

P2 horizontal

P2 vertical

P3 horizontal

P3 vertical


269

A3

PUMP1V

PUMP2H

PUMP2V

PUMP3H

PUMP3V

Horizontal pump Vertical pump #4 #4

PUMP4H

PUMP4V

SAJAT Hypo-tartály

Vízmennyiségmé rő

Csigás szvrács

Szippantóautó

Nyitott zsilip

HYPOTART

MERO

RACS2

SZKOCSI

ZS_NYIT

Nyitott zsilip

Zárt zsilip

Zárt zsilip

ZS_NYIT2

ZS_ ZART

ZS_ZART2

Colhf

Colhs

Colvf

Colvs

SHAPES Arrow 45

A3 270


ARROW45

COLHF

COLHS

COLVF

COLVS

Conehf

Conehs

Conevf

Conevs

Cornh

CONEHF

CONEHS

CONEVF

CONEVS

CORNH

Cornv

Octf

Octs

Parelnd

Parelpd

CORNV

OCTF

OCTS

PARELND

PARELPD

Poolh

Poolv

Rhomf

Rhoms

Sixf

POOLH

POOLV

RHOMF

RHOMS

SIXF

Sixs

Tank2f

Tank2s

Tankf

Tanks

SIXS

TANK2F

TANK2S

TANKF

TANKS

Trifh

Trifv

Trish

Trisv

TRIFH

TRIFV

TRISH

TRISV


271

SIEVE Sieve #1

Sieve #2

Sieve #3

Sieve #4

Sieve #5

SIEVE1

SIEVE2

SIEVE3

SIEVE4

SIEVE5

Silo #1

Silo #2

Silo #3

Silo #4

Silo #5

SILO1

SILO2

SILO3

SILO4

SILO5

Silo #6

Silo #7

Silo #8

Silo #9

Silo #10

SILO6

SILO7

SILO8

SILO9

SILO10

Sieve sorter

SIEVSORT

SILO

Silo #11

SILO11

A3 272


SNAIL Vertical Crane #1

Vertical Crane #2

CRANE1V

CRANE2V

Vertical Snail #2

SNAIL2V

Horizontal Snail Horizontal Snail Vertical Snail #1 #1 #2

SNAIL1H

SNAIL1V

SNAIL2H

Diagonal arrow

Horizontal arrow

Horizontal Snail Vertical Snail #3 #3

SNAIL3H

SNAIL3V

SYMBOLS Diagonal arrow #1

Horizontal arrow Vertical arrow #1 #1

ARROW1D

ARROW1H

ARROW1V

ARROWD

ARROWH

Vertical arrow

Truck

Camion

Fire

Garbage

ARROWV

AUTO1

AUTO2

FIRE

GARBAGE

Hammer

Hand

Hand 1

Heater #1

Heater #2


273

HAMMER

HAND

HAND1

HEATER1

HEATER2

Consumer #1

Consumer #2

Electric

Measure

Around arrow #1

LAMP1

LAMP2

LIGHTING

MEASURE

RARROW1

A3 274


Around arrow #2

Showbox

Showbox

Work

Work and computer

RARROW2

SHBOX

SHOWBOX

WORK

WORKPC

Chemie #1

Chemie #2

Nitrogen tank

Gastank

Slantank

CHEM1

CHEM2

GAS1

GAS2

SCOLON

T1

T2

T3

T4

T5

T1

T2

T3

T4

T5

Tank #2

Tank #3

Tank #4

Tank #6

Tank #7

TANK2

TANK3

TANK4

TANK6

TANK7

Tank #8

Tank #9

Tank #10

Tank #11

Tank #12

TANK8

TANK9

TANK10

TANK11

TANK12

Tank #13

Tank #14

Tank #15

Tank #16

Underground tank

TANK


275

TANK13

TANK14

TANK15

TANK16

TANK17

A3 276


Bigtank

Tank inside #1

Tank details #1

Tank inside #3

S_6

XTANK

XTANK1

XTANK2

XTANK3

XTANK4

Ball'n tap

Ball'n white tap

Vertiacal tap

Vertical white tap

Control valve

BTAPH

BTAPHW

BTAPV

BTAPVW

CALVEH

Vert control valve

Vert control valve

CALVEVL

CALVEVR

VALVE

Vertical valve #2

VALVE2V

Horizontal valve Horizontal valve Vertical valve #1 #1 #2

VALVE1H

VALVE1V

VALVE2H

Horizontal valve Horizontal valve Vertical valve #3 Vertical valve #4 #3 #4

VALVE3H

VALVE3V

VALVE4H

VALVE4V

Horizontal valve Horizontal valve Horizontal valve Vertical valve #5 Vertical valve #6 #5 #6 #7

VALVE5H Vertical valve #7

VALVE5V

VALVE6H

VALVE6V

VALVE7H

Horizontal valve Horizontal valve Vertical valve #8 Vertical valve #9 #8 #9


277

VALVE7V

VALVE8H

VALVE8V

VALVE9H

VALVE9V

A3 278


Horizontal valve #10

Vertical valve #10


Vertical valve #11


VALVE10H

VALVE10V

VALVE11H

VALVE11V

VALVE12H

Vertical valve #12


Vertical valve #13

T'valve #1

T'valve #2

VALVE12V

VALVE13H

VALVE13V

VALVET1

VALVET2

T'valve #3

T'valve #4

Valve Simple

VALVET3

VALVET4

YVALVE


279

MIXED SYMBOLS Bontó

Router 1

Router 2

Exercise book

Garat 1

S_BONTO

S_FOLY

S_FOLYI

S_FUZET

S_GARAT1

Garat 2

Garat 3

Steam

Radiator 1

Radiator 2

S_GARAT2

S_GARAT3

S_GOZ

S_HUTO

S_ HUTO2

Mixer

Weighingmachine

Pellet

Silo 1

Silo 2

S_KEVER

S_MERLEG

S_PELLET

S_SILO1

S_SILO2

Silo 3

Silo 4

Silo 5

Silo 7

Silo 8

S_SILO3

S_SILO4

S_SILO5

S_SILO7

S_SILO8

Silo 11

Hopper

Switch 1

Switch 2

Switch 3

S_SILO11

S_SURR

S_V1

S_VALTO

S_VK

Switch 4

Switch 5

Búvárszivattyú

S_isz

Iszapsűrítő

S_VKFORD

S_VKNORM

S_BUVAR

S_ISZ

S_ISZAP

A3 280



281

Kompresszor tartály

Aer

Tüzivíz ny.fokozó

Polimer

Reaktor

S_KOMP

S_LUFT

S_NYOMF

S_POLI

S_REAKT

HCl

Talajvíz akna

Tartály

Tüzivíz tároló

Dortmundi ülepítő

S_SOSAV

S_TAKNA

S_TART2

S_TUZI

S_ULEP

Ventillátor

Víztelenítés

S_VENT

S_VIZTEL

A3 282


VISION X 9 Folyamatmegjelenítő rendszer

Recommend Documents