Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. Monitor sběrnice Profibus s HW podporou - SW část

Za´padoˇceska´ univerzita v Plzni Fakulta aplikovanyćh vˇed Katedra informatiky a vy´poˇcetn´ı techniky

Diplomov´ a pr´ ace Monitor sbˇ ernice Profibus s HW podporou - SW ˇ c´ ast

Plzeˇ n 2013

Jan Krahulec

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou práci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 13. kvˇetna 2013 Jan Krahulec

Abstract The Profibus Monitor with the HW Support - the SW Part This diploma thesis deals with the question of current fieldbuses with an emphasis on the Profibus (especially its PA variant). The modern fieldbuses are introduced and briefly described in the first part of the thesis. Profibus PA is described more in detail because it is an important part of the practical realization. The applied hardware is closely described in the next part. Two units are used: FintT410 from the Norwegian company Fieldbus International AS (it implements the interface between protocols Ethernet and Profibus PA) and FNL (Fieldbus Network Link) from German company COMSOFT (it implements the interface between protocols Profibus PA and Modbus). The very realization of the practical part follows. At first, the communication chain was created from the units mentioned above. At second, the application, which captures data from Profibus and filters this data appropriately, was implemented. The graphical user interface with the option of some parameters configuration is the part of the application.

Obsah ´ 1 Uvod

1

2 Pr˚ umyslov´ e sbˇ ernice 2.1 Modbus . . . . . . . . . . . . . . . 2.1.1 Obecné informace . . . . . . 2.1.2 Vys´ılac´ı reˇzimy . . . . . . . 2.1.3 Typy dat a základn´ı funkce 2.2 Profibus . . . . . . . . . . . . . . . 2.2.1 Obecné informace . . . . . . 2.2.2 Profibus PA . . . . . . . . . 3 Hardwarov´ e vybaven´ı 3.1 Popis komunikace mezi moduly . 3.2 Fieldbus Network Link (FNL) . . 3.2.1 Rozhran´ı Dual-Port RAM 3.2.2 Knihovn´ı funkce . . . . . . 3.3 FintPROFI T410 . . . . . . . . . 3.3.1 Popis . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

2 . 4 . 4 . 4 . 6 . 8 . 8 . 11

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

16 17 18 19 22 29 29

4 Realizace monitoru sbˇ ernice Profibus PA ´ 4.1 Uvod . . . . . . . . . . . . . . . . . . . . . 4.2 Návrh aplikace . . . . . . . . . . . . . . . 4.3 Aplikace - ˇreˇsen´ı . . . . . . . . . . . . . . . 4.3.1 Start aplikace . . . . . . . . . . . . 4.3.2 Naˇcten´ı GSD souboru . . . . . . . 4.3.3 Pˇripojen´ı a inicializace spojen´ı . . . 4.3.4 Zadán´ı adresy . . . . . . . . . . . . 4.3.5 Zmˇena parametr˚ u. . . . . . . . . . ˇ ı dat . . . . . . . . . . . . . . 4.3.6 Cten´ 4.3.7 Otestován´ı aplikace . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

32 32 32 34 34 35 37 40 40 44 51

. . . . . .

. . . . . .

. . . . . .

. . . . . .

5 Z´ avˇ er

52

6 Pˇ rehled zkratek

53

Literatura

54

A Pˇ r´ılohy A.1 Uˇzivatelská pˇr´ıruˇcka . . . . . . . . . . . . . . . . A.1.1 Spuˇstˇen´ı programu a naˇcten´ı GSD souboru A.1.2 Pˇripojen´ı k jednotce a naˇcten´ı adresy . . . A.1.3 Nastavován´ı parametr˚ u. . . . . . . . . . . A.1.4 Cyklická komunikace . . . . . . . . . . . . A.2 GSD soubor . . . . . . . . . . . . . . . . . . . . .

56 57 57 59 61 62 64

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

´ 1 Uvod V souˇcasné dobˇe jsou pr˚ umyslové sbˇernice ned´ılnou souˇcást´ı systém˚ u pro sbˇer, distribuci a vyhodnocen´ı dat r˚ uzného informaˇcn´ıho charakteru. S pr˚ umyslov´ ymi sbˇernicemi se m˚ uˇzeme setkat prakticky ve vˇsech technick´ ych odvˇetv´ıch – automobilov´ y pr˚ umysl, stroj´ırenstv´ı, energetika a mnoho dalˇs´ıch. Oproti star´ ym analogov´ ym rozvod˚ um maj´ı pr˚ umyslové sbˇernice nˇekolik v´ yhod - mezi ty hlavn´ı patˇr´ı pˇredevˇs´ım moˇznost vyuˇzit´ı star´ ych rozvod˚ u (uˇsetˇren´ı náklad˚ u) a také schopnost pˇrenáˇset mnohonásobnˇe v´ıce dat po jednom veden´ı. Od poˇcátku 80. let, kdy zaˇcal v´ yvoj pr˚ umyslov´ ych sbˇernic, aˇz do dneˇsn´ı doby vzniklo mnoho pr˚ umyslov´ ych standard˚ u, které byly vytváˇreny s ohledem na prostˇred´ı, v nˇemˇz mˇely b´ yt uplatnˇeny. Tato diplomová práce se zab´ yvá modern´ımi pr˚ umyslov´ ymi sbˇernicemi, pˇredevˇs´ım pak sbˇernic´ı Profibus a jej´ı variantou PA. Prvn´ım c´ılem této práce je nastudován´ı potˇrebn´ ych informac´ı o sbˇernici Profibus PA, pˇredevˇs´ım pak základn´ı vlastnosti komunikaˇcn´ıho protokolu. Dalˇs´ı fáze této práce spoˇc´ıvá v sestaven´ı a oˇziven´ı komunikaˇcn´ıho ˇretˇezce z dostupného hardwaru, jehoˇz hlavn´ı ˇca´st vyuˇz´ıvá pro komunikaci sbˇernici Profibus PA. Po d˚ ukladném zváˇzen´ı byly jako hlavn´ı souˇca´sti ˇretˇezce poˇr´ızeny jednotky FintT410 od norské spoleˇcnosti Fieldbus International AS a Fieldbus Network Link od nˇemecké spoleˇcnosti COMSOFT. Hlavn´ım tématem posledn´ı, ale nejd˚ uleˇzitˇejˇs´ı ˇcásti práce je vytvoˇren´ı aplikace, která dokáˇze monitorovat data pˇrenáˇsená po sbˇernici Profibus PA. Kromˇe vlastn´ıho zachytáván´ı dat je v aplikaci moˇzné nastavovat základn´ı komunikaˇcn´ı parametry tak, aby byl v´ ysledn´ y program co nejv´ıc univerzáln´ı, ˇcili aby byl kompatibiln´ı i s jin´ ymi zaˇr´ızen´ımi, neˇz jaká byla pouˇzita v této práci. Souˇca´st´ı vytvoˇrené aplikace je také uˇzivatelské rozhran´ı, jeˇz umoˇzn ˇuje uˇzivateli jednoduch´ y a intuitivn´ı pˇr´ıstup ke konfiguraci a vlastn´ım pˇrenáˇsen´ ym dat˚ um.

1

2 Pr˚ umyslov´ e sbˇ ernice Pr˚ umyslové sbˇernice jsou digitáln´ı sériové sbˇernice, které zajiˇst’uj´ı s´ıt’ovou komunikaci v pr˚ umyslov´ ych provozech, pˇredevˇs´ım pak slouˇz´ı ke komunikaci mezi inteligentn´ımi zaˇr´ızen´ımi. Zaˇca´tek v´ yvoje pr˚ umyslov´ ych sbˇernic sahá do ran´ ych 80. let, kdy vznikla potˇreba nahradit starˇs´ı analogové rozvody, u kter´ ych byly vysoké nároky na reˇzii. [8] V následuj´ıc´ım textu budou struˇcnˇe popsány souˇcasné nejpouˇz´ıvanˇejˇs´ı sbˇernice, v dalˇs´ım textu jsou pak podrobnˇe popsány sbˇernice Modbus a Profibus, nebot’ jejich podrobnˇejˇs´ı popis je pro tuto práci zcela zásadn´ı. Mezi souˇcasné nejpouˇz´ıvanˇejˇs´ı sbˇernice patˇr´ı: • FOUNDATION Fieldbus: Protokol byl vyv´ıjen od roku 1970, jako standard byl pˇrijat o 30 let pozdˇeji. Jedná se o ˇc´ıslicovou sbˇernici s poloduplexn´ım sériov´ ym pˇrenosem, která byla navrˇzena tak, aby byly zachovány základn´ı v´ yhody analogov´ ych systém˚ u s proudovou smyˇckou 4 - 20 mA, ˇcili aby bylo moˇzné pˇri instalaci zachovat p˚ uvodn´ı kabeláˇz. Pro pomal´ y pˇrenos dat v segmentech H1 je jako médium pouˇzita kroucená dvojlinka, pˇrenosová rychlost je 31,25 kb/s. Vysokorychlostn´ı pˇrenos je realizován na bázi rychlého Ethernetu, pˇrenosová rychlost je 100 Mb/s.[8][12] • ControlNET: Sbˇernice, která umoˇzn ˇuje uˇzivatel˚ um sd´ılet data prostˇrednictv´ım protokolu CIP (Common Industrial Protocol) - tento protokol vyuˇz´ıvaj´ı téˇz s´ıtˇe EtherNet/IP, DeviceNet a CompoNet. ControlNet umoˇzn ˇuje realizovat vysokorychlostn´ı pˇrenos ˇcasovˇe kritick´ ych vstupn´ıch a v´ ystupn´ıch dat a souˇcasnˇe i upload a download program˚ u, pˇrenos nastaven´ı parametr˚ u a zas´ılán´ı zpráv peer-to-peer jedn´ım jednoduch´ ym nebo zdvojen´ ym (redundantn´ım) fyzikáln´ım médiem. V dneˇsn´ı dobˇe je souˇca´st´ı sdruˇzen´ı ODVA (Open DeviceNet Vendors Association)[9] • HART (Highway Addressable Remote Transducer): Sbˇernice HART umoˇzn ˇuje digitáln´ı pˇrenos dat po analogové proudové smyˇcce 4 - 20 mA, ˇcili souˇcasn´ y pˇrenos digitáln´ıch a analogov´ ych dat. Kaˇzdé zaˇr´ızen´ı, které implementuje protokol HART m˚ uˇze kromˇe vlastn´ı namˇeˇrené hodnoty poskytovat také napˇr. statistické vyhodnocen´ı efektivity v´ yrobn´ıho procesu, plánován´ı u ´drˇzby, dálkovou diagnostiku závad, nastaven´ı a kalibraci pˇr´ıstroj˚ u. Komunikace mezi nadˇrazen´ ymi systémy 2

Pr˚ umyslové sbˇernice a procesn´ımi zaˇr´ızen´ımi je typu master - slave, data jsou pˇrenáˇsena konstantn´ı rychlost´ı 1200 b/s.[10] • CAN (Controller Area Network): CAN je sériov´ y komunikaˇcn´ı protokol, vyvinut´ y firmou Bosh (p˚ uvodnˇe pro nasazen´ı v automobilech), kter´ y umoˇzn ˇuje distribuované ˇr´ızen´ı systém˚ u v reálném ˇcase s pˇrenosovou rychlost´ı do 1Mbit/s a vysok´ ym stupnˇem zabezpeˇcen´ı pˇrenosu proti chybám. Jedná se o protokol typu multi-master, kdy kaˇzdá stanice m˚ uˇze pˇrevz´ıt ˇr´ıd´ıc´ı u ´lohu na sbˇernici (komunikace je tak velmi bezpeˇcná, protoˇze po v´ ypadku jedné stanice m˚ uˇze pˇrevz´ıt ˇr´ızen´ı jiná). Komunikace mezi zaˇr´ızen´ımi prob´ıhá pomoc´ı zpráv, které jsou pˇrij´ımány vˇsemi uzly na sbˇernici (neobsahuj´ı adresu, pouze identifikátor d˚ uleˇzitosti zprávy). Jednotlivé uzly mohou zprávy filtrovat podle identifikátoru.[11]

3

Pr˚ umyslové sbˇernice

2.1

Modbus

Modbus

Protoˇze je protokol Modbus implementován v jednotce T410, která je souˇca´st´ı systému pouˇzitého v této diplomové práci, je urˇcitˇe na m´ıstˇe uvést základn´ı informace o tomto protokolu.

2.1.1

Obecn´ e informace

Modbus je otevˇren´ y protokol, kter´ y funguje na principu komunikace klient (slave) - server (master). Na sbˇernici je vˇzdy pˇr´ıtomen jeden server a jeden nebo v´ıce klient˚ u. Protokol byl vyvinut firmou Modicon v roce 1979 pro vyuˇzit´ı v programovateln´ ych logick´ ych automatech (PLC). Jednalo se o otevˇren´ y standard, kter´ y definoval pouze strukturu pˇrenosu zpráv, fyzickou vrstvu bylo moˇzné dodefinovat v závislosti na podm´ınkách, v kter´ ych mˇel b´ yt protokol vyuˇzit. Mezi hlavn´ı pˇrednosti standardu Modbus patˇr´ı jistˇe jeho jednoduchost, s ˇc´ımˇz je spojená i moˇznost snadné implementace.[13][14]

2.1.2

Vys´ılac´ı reˇ zimy

Protokol Modbus definuje dva základn´ı vys´ılac´ı reˇzimy: • Modbus RTU, • Modbus ASCII

Modbus RTU Pokud je zaˇr´ızen´ı nastaveno do módu RTU (Remote Terminal Unit), kaˇzd´ ych 8 bit˚ u zprávy obsahuje 2 4-bitové znaky. Oproti ASCII módu jsou pˇrenáˇsená data v´ıce nahuˇstˇena a t´ım pádem docház´ı k pˇrenesen´ı vˇetˇs´ıho objemu dat za stejné rychlosti (baudrate). Na obrázku 2.1 je znázornˇena struktura Modbus RTU rámce, v tabulce 2.2 jsou pak jednotlivé poloˇzky popsány.[13][14]

4


Modbus

Obrázek 2.1: Struktura Modbus RTU rámce Název V´ yznam Zaˇ c´ atek, Konec Indikace zaˇca´tku i konce rámce je v reˇzimu RTU stejná a jde o sekvenci klidu na sbˇernici, která mus´ı m´ıt délku minimálnˇe 3,5 znaku. Adresa Adresa c´ılového zaˇr´ızen´ı (0: Broadcast, 1 - 247: Adresa konkrétn´ıho zaˇr´ızen´ı, 248 - 255: Rezervováno). Funkce Kód pouˇzité funkce (ˇcten´ı, zápis, viz dále). Data Poˇzadovaná data (v závislosti na pouˇzité funkci, mohou b´ yt i prázdná). CRC Kontroln´ı CRC souˇcet na bázi polynomu x16 +x15 +x2 + 1. Tabulka 2.1: Struktura Modbus RTU rámce - v´ yznam poloˇzek Modbus ASCII Na rozd´ıl od módu RTU je osmice bit˚ u zprávy dekódována jako dvojice ASCII znak˚ u. V´ yhoda tohoto pˇr´ıstupu je v tom, ˇze mezi odvys´ılan´ ymi znaky m˚ uˇze b´ yt aˇz 1 sekundu dlouhá prodleva. Obrázek 2.2 znázorˇ nuje strukturu rámce, tabulka popis jednotliv´ ych poloˇzek.[13][14]

Obrázek 2.2: Struktura Modbus ASCII rámce

5


Modbus

Název V´ yznam Zaˇ c´ atek, Konec Zaˇcátek je indikován znakem ’:’, konec pak dvojic´ı ˇr´ıdic´ıch znak˚ u CR a LF, coˇz umoˇzn´ı delˇs´ı prodlevy mezi vys´ılan´ ymi znaky. Adresa Adresa c´ılového zaˇr´ızen´ı (0: Broadcast, 1 - 247: Adresa konkrétn´ıho zaˇr´ızen´ı, 248 - 255: Rezervováno). Funkce Kód pouˇzité funkce (ˇcten´ı, zápis, viz dále). Data Poˇzadovaná data (v závislosti na pouˇzité funkci, mohou b´ yt i prázdná). LRC Kontroln´ı LRC (Longitudinal Redundancy Check) souˇcet. Tabulka 2.2: Struktura Modbus ASCII rámce - v´ yznam poloˇzek

2.1.3

Typy dat a z´ akladn´ı funkce

Kaˇzdá skupina dat je podle v´ yznamu zaˇrazena do jedné ze ˇctyˇr tabulek, které maj´ı sv˚ uj definovan´ y adresn´ı prostor (prostory se mohou pˇrekr´ yvat, ale z d˚ uvodu zpˇetné kompatibility se obvykle vol´ı oddˇelené prostory, kaˇzd´ y o velikosti 10000 poloˇzek). V tabulce 2.3 jsou uvedeny názvy tabulek spolu s typick´ ym rozsahem adres a struˇcn´ ym popisem.[13][14] Tabulka C´ıvky (Coils) Diskrétn´ı vstupy (Discrete Inputs) Vstupn´ı registry (Input Registers)

Uchovávac´ı registry (Holding Registers)

Rozsah adres 0 ÷ 9999

Popis Jeden bit (boolean) urˇcen´ y pro ˇcten´ı i zápis. 10000 ÷ 19999 Jeden bit (boolean) urˇcen´ y pouze ke ˇcten´ı. 30000 ÷ 39999 16-bitové registry urˇcené pouze pro ˇcten´ı. Typické vyuˇzit´ı je reprezentace analogov´ ych vstupn´ıch dat. 40000 ÷ 49999 16-bitové registry urˇcené pouze ˇcten´ı i zápis. Tabulka 2.3: Modbus - typ dat

6


Modbus

Pro ˇcten´ı a zápis dat jsou definovány základn´ı funkce, které jsou souˇcást´ı rámce poˇzadavku. Kromˇe tˇechto funkc´ı maj´ı uˇzivatelé moˇznost také nadefinovat své vlastn´ı funkce. V tabulce 2.4 je uveden v´ yˇcet vˇsech základn´ıch funkc´ı spolu s jejich kódem a popisem: Název funkce Kód Read Coils 01 Read Discrete Inputs 02 Read Holding Registers 03 Read Input Registers 04 Write Single Coil 05 Write Single Register 06 Write Multiple Coils 15 Write Multiple Registers 16

Popis ˇ ı c´ıvek Cten´ ˇ ı diskrétn´ıch vstup˚ Cten´ u ˇ ı uchovávac´ıch registr˚ Cten´ u ˇ Cten´ı vstupn´ıch registr˚ u Zápis jedné c´ıvky Zápis jednoho registru Zápis v´ıce c´ıvek Zápis v´ıce registr˚ u

Tabulka 2.4: Modbus - funkce ˇ ı uchoNa obrázku 2.3 je pro ilustraci znázornˇeno pˇreˇcten´ı dat funkc´ı Cten´ vávac´ıch registr˚ u, jeˇz prob´ıhá na principu poˇzadavek → odpovˇed’:

Obrázek 2.3: Modbus - ˇcten´ı dat

7


2.2

Profibus

Profibus

V pˇredcházej´ıc´ı kapitole t´ ykaj´ıc´ı se Modbusu bylo ˇreˇceno, ˇze je tento protokol implementován v jednotce T410, která se chová jako Modbus master. Jednotka T410 ovˇsem také implementuje protokol Profibus PA, s jehoˇz vyuˇzit´ım komunikuje s jednotkou FNL (Fieldbus Network Link). Na následuj´ıc´ıch nˇekolika stránkách je nejprve obecnˇe popsán protokol Profibus a poté ponˇekud konkrétnˇeji Profibus PA spolu s obecn´ ymi principy cyklické a acyklické komunikace, nebot’ ty jsou pro tuto práci vpravdˇe zásadn´ı.

2.2.1

Obecn´ e informace

Na u ´vod je tˇreba zm´ınit, ˇze Profibus (Process Field Bus) nen´ı jeden komunikaˇcn´ı systém, jedná se sp´ıˇse o mnoˇzinu protokol˚ u, které jsou postaveny na stejném základu technologie Fieldbus. V´ yhodou tohoto pˇr´ıstupu je, ˇze kaˇzdá konkrétn´ı aplikace m˚ uˇze zm´ınˇené protokoly kombinovat na základˇe sv´ ych specifick´ ych poˇzadavk˚ u.

Historie Historie Profibusu sahá do konce osmdesát´ ych let minulého stolet´ı, kdy byla v Nˇemecku vysoká poptávka ze strany pr˚ umyslov´ ych spoleˇcnost´ı a vlády po standardu pro pr˚ umyslovou automatizaci. V roce 1987 tak spojilo 21 nˇemeck´ ych spoleˇcnost´ı a instituc´ı s´ıly, vznikla skupina Centráln´ı asociace pro elektrotechnick´ y pr˚ umysl (ZVEI) a v´ ysledkem jejich snahy bylo vytvoˇren´ı standardu Profibus FMS (Fieldbus Message Specification). V roce 1993 pˇredstavila skupina ZVEI nov´ y standard, Profibus DP (Decentralized Periphery). Hlavn´ı vylepˇsen´ı nové verze byla vˇetˇs´ı jednoduchost, moˇznosti snadnˇejˇs´ı konfigurace a rychlejˇs´ı komunikace. Standardy Profibusu jsou udrˇzovány (a zlepˇsovány) nˇekolika organizacemi. V roce 1989 zaloˇzili uˇzivatelé skupinu PROFIBUS User Organization (PNO). C´ılem této nekomerˇcn´ı organizace je pˇredevˇs´ım podpora a vzdˇeláván´ı, coˇz zahrnuje napˇr´ıklad uvolˇ nován´ı technické dokumentace tak, aby uˇzivatelé mohli vyuˇz´ıvat stávaj´ıc´ı technologii pro své specifické potˇreby. Dalˇs´ı organizace vznikla v roce 1995 pod názvem PROFIBUS International (PI), 8


Profibus

která je nyn´ı nejvˇetˇs´ı Fieldbus asociac´ı na svˇetˇe. C´ıle PI jsou podobné jako u PNO, zab´ yvá se ovˇsem také ovˇeˇrován´ım kvality a tvorbou nov´ ych Profibus technologi´ı.[1]

Verze protokolu V souˇcasné dobˇe existuj´ı 3 varianty protokolu Profibus[2]: • Profibus-DP pro automatizaci v´ yroby: – pˇrenosová rychlost aˇz 12 Mb/s, – linka RS-485 nebo optické vlákno, s urˇcen´ım pro rychlou v´ ymˇenu relativnˇe mal´ ych objem˚ u dat • Profibus-FMS: – pˇrenosová rychlost do 500 kb/s, – linka RS-485 nebo optické vlákno, s urˇcen´ım pro vˇetˇs´ı objemy dat – v hierarchii ˇr´ızen´ı pˇredstavuje u ´roveˇ n nad Profibus-DP. • Profibus-PA: – konstantn´ı pˇrenosová rychlost 31,25 kb/s, – fyzická vrstva podle IEC 61158 (napˇet’ov´ y reˇzim, jiskrová bezpeˇcnost).

Architektura Norma Profibus vycház´ı z modelu ISO/OSI (viz obrázek 2.4) s t´ım, ˇze z d˚ uvodu ˇcasové optimalizace definuje pouze 3 vrstvy - fyzickou, linkovou a aplikaˇcn´ı.

9


Profibus

Obrázek 2.4: Profibus - ISO/OSI model Fyzick´ a vrstva se liˇs´ı podle pouˇzité varianty protokolu Profibus[3]: 1. RS-485(H2) - Profibus DP/FMS, 2. Optick´ e vl´ akno - Profibus DP/FMS, 3. EC 1158-2 (H1) - Profibus PA. Linkov´ a vrstva, jeˇz je oznaˇcována jako FDL (Fieldbus Data Link) je u vˇsech variant témˇeˇr shodná. Pˇr´ıstup na sbˇernici je hybridn´ı, jin´ ymi slovy kombinuje klasické uspoˇra´dán´ı master→slave s distribuovan´ ym ˇr´ızen´ım pˇr´ıstupu prostˇrednictv´ım pˇredáván´ı povˇeˇren´ı (viz obrázek 2.5).

10


Profibus

Obrázek 2.5: Profibus - pˇr´ıstup na sbˇernici

2.2.2

Profibus PA

Profibus PA je ze zmiˇ novan´ ych variant nejmladˇs´ım standardem (v roce 1996 byl zaˇclenˇen do evropského standardu EN 50170 Volume 2[4]), ve vˇetˇs´ı m´ıˇre se zaˇcal pouˇz´ıvat aˇz v posledn´ıch letech. V souˇcasné dobˇe je aktuáln´ı verze 3.02. Mezi nejzaj´ımavˇejˇs´ı realizované aplikace vyuˇz´ıvaj´ıc´ı Profibus PA patˇr´ı: • Automatizace chemiˇcky Wacker Chemie v Kol´ınˇe nad R´ ynem, • Automatizace skladovac´ıch tank˚ u firmy Shell v Hamburgu, • Aplikace mˇeˇren´ı hustoty pohonn´ ych hmot na letiˇsti v Ostravˇe.

Fyzick´ a vrstva Fyzická vrstva protokolu Profibus PA je navrˇzena v souladu s normou IEC 1158-2 a má tyto vlastnosti: 1. St´ınˇená nebo nest´ınˇená kroucená dvojlinka zakonˇcená sériov´ ym RC ˇclánkem (Rt = 100Ω, Ct = 1µF ), 2. Napájen´ı stanic pˇr´ımo ze sbˇernice. Napájec´ı napˇet´ı v rozmez´ı 9V – 32V (v prostˇred´ı s nebezpeˇc´ım v´ ybuchu maximálnˇe 15 V), 3. Volitelná jiskrová bezpeˇcnost – vys´ılaj´ıc´ı stanice má pasivn´ı charakter, jin´ ymi slovy nedodává na sbˇernici proud, pouze mˇen´ı sv˚ uj odbˇer, 11


Profibus

4. Synchronn´ı pˇrenos s konstantn´ı rychlost´ı 31,25 kbit/s, kódován´ı Manchester, 5. Délka segmentu m˚ uˇze b´ yt maximálnˇe 1900 m, na jeden segment je moˇzné pˇripojit nanejv´ yˇs 32 stanic (v pˇr´ıpadˇe jiskrové bezpeˇcnosti nejv´ yˇse 10 stanic) V praxi vˇetˇsinou neb´ yvá Profibus PA nasazován samostatnˇe, ale jako prodlouˇzen´ı Profibusu DP do m´ıst, kde hroz´ı nebezpeˇc´ı v´ ybuchu. Existuj´ı 2 moˇznosti jejich propojen´ı: 1. Vazebn´ı ˇ clen (DP/PA Coupler) – provád´ı pouze pˇrevod mezi odliˇsn´ ymi fyzick´ ymi vrstvami a pˇrevád´ı data pˇrenáˇsená asynchronnˇe rychlost´ı 45,45 kbit/s na data pˇrenáˇsená synchronnˇe rychlost´ı 31,25 kbit/s. Nev´ yhodou je skuteˇcnost, ˇze komunikace na sbˇernici DP je zpomalena. 2. Spojov´ y ˇ clen (DP/PA Link) – v˚ uˇci zaˇr´ızen´ım na sbˇernici DP se chová jako podˇr´ızená stanice (slave), v˚ uˇci zaˇr´ızen´ım na PA segmentu pak jako ˇr´ıd´ıc´ı stanice (master).

Cyklick´ a komunikace Cyklická komunikace je u protokolu Profibus PA (stejnˇe tak i DP) realizována mezi ˇr´ıd´ıc´ı stanic´ı tˇr´ıdy 1 (DPM1) a ˇr´ızen´ ym zaˇr´ızen´ım. Pˇred t´ım, neˇz zaˇcne cyklická v´ ymˇena dat (Data Exchange), je tˇreba provést parametrizaci a konfiguraci ˇr´ızené stanice. Stanice pˇri tˇechto ˇcinnostech procház´ı nˇekolika stavy, coˇz znázorˇ nuje diagram na obrázku 2.6:

12


Profibus

Obrázek 2.6: Profibus - stavov´ y diagram 1. Stav po zapnut´ı nebo resetu zaˇ r´ızen´ı - pro pˇrechod do dalˇs´ıho stavu je nutné, aby mˇela stanice validn´ı adresu (0-125), kterou nastavuje Master telegramem Set_Slave_Add. 2. Stav Parametrizace - v tomto stavu ˇceká zaˇr´ızen´ı na jeho parametrizaci, kterou provede Master telegramem Set_Prm. Ostatn´ı telegramy, kromˇe dotazu na diagnostiku (Slave_Diag) a konfiguraci (Get_Cfg) jsou ignorovány. 3. Stav Konfigurace - po parametrizaci je nutné specifikovat poˇcet vstupn´ıch a v´ ystupn´ıch byt˚ u datov´ ych telegram˚ u, které budou souˇcást´ı datové v´ ymˇeny mezi ˇr´ıd´ıc´ı a ˇr´ızenou stanic´ı. Pro konfiguraci slouˇz´ı telegram Chk_Cfg. 4. Cyklick´ a komunikace - v tomto okamˇziku je jiˇz moˇzné zahájit cyklickou komunikaci mezi stanicemi. Komunikace je velmi jednoduchá, na principu poˇzadavek-odpovˇed’, kdy ˇr´ıd´ıc´ı stanice poˇsle ˇr´ızené stanici telegram Data_Exch.req se sv´ ymi v´ ystupn´ımi daty a ˇr´ızená stanice odpov´ı telegramem Data_Exch.resp, jenˇz obsahuje jej´ı v´ ystupn´ı data. Tento 13


Profibus

zp˚ usob komunikace se naz´ yvá Send and Request Data with Reply (SRD). Na obrázku 2.7 je struˇcnˇe znázornˇeno, jak vypadá cyklická komunikace vˇcetnˇe formátu telegramu.

Obrázek 2.7: Profibus PA - pˇrenos dat

14


Profibus

Acyklick´ a komunikace Acyklická komunikace patˇr´ı mezi rozˇs´ıˇrené funkce DPV1. Tento typ komunikace se dále dˇel´ı na: • MSAC1 (Master/Slave Acyclic C1) - prob´ıhá mezi ˇr´ızenou stanic´ı a DPM1 (DP master class 1), coˇz je ˇr´ıd´ıc´ı stanice slouˇz´ıc´ı k cyklické v´ ymˇenˇe dat, • MSAC2 (Master/Slave Acyclic C2) - prob´ıhá mezi ˇr´ızenou stanic´ı a DPM2 (DP master class 2), coˇz je ˇr´ıd´ıc´ı stanice realizuj´ıc´ı diagnostické a monitorovac´ı funkce. Pro zahájen´ı acyklické komunikace je nejprve nutné vytvoˇrit a otevˇr´ıt acyklick´ y komunikaˇcn´ı kanál (v pˇr´ıpadˇe vytvoˇren´ı cyklického spojen´ı je vytváˇren automaticky). Parametry, které maj´ı b´ yt pˇrenáˇseny acyklickou komunikac´ı, jsou identifikovány jednoznaˇcnou dvojic´ı slot a index. Podrobnˇejˇs´ı informace o ˇcten´ı parametr˚ u je moˇzné nalézt dále v textu v sekci 4.3.5 Dalˇs´ı informace o protokolu Profibus PA lze dohledat ve zdroj´ıch [2], [4], [5] a [6].

15

3 Hardwarové vybaven´ı V této kapitole bude nejprve obecnˇe popsáno, jak cel´ y hardwarov´ y systém, kter´ y byl pro u ´ˇcely diplomové práce sestaven, funguje a následnˇe budou d˚ ukladnˇeji popsány jeho jednotlivé souˇca´sti. Na obrázku 3.1 je znázornˇeno struˇcné schéma pouˇzitého systému:

Obrázek 3.1: Schema systému

ˇ ıd´ıc´ı jednotka – slouˇz´ı ke konfiguraci komunikace, zachytává a ukládá 1. R´ data pˇreˇctená z jednotky ˇc. 5 (Modbus slave). V této práci je jako ˇr´ıd´ıc´ı jednotka pouˇzit stoln´ı poˇc´ıtaˇc, 2. FNL (Fieldbus Network Link) – jednotka pracuje jako rozhran´ı mezi protokolem Profibus a protokolem Ethernet. Uˇzivateli jsou k dispozici rozliˇcné funkce, které je moˇzné z ˇr´ıd´ıc´ı jednotky volat, 3. FintPROFI T410 – jednotka slouˇz´ıc´ı jako rozhran´ı mez´ı protokolem Profibus a Modbus, 4. Pˇ revodn´ık RS485/USB, 5. Modbus slave – simulátor Modbus slave bˇeˇz´ıc´ı na stoln´ım poˇc´ıtaˇci (pouˇzita shareware verze programu MOD RSsim)

16

Hardwarové vybaven´ı

3.1

Popis komunikace mezi moduly

Popis komunikace mezi moduly

Pro u ´plnou pˇredstavu je tˇreba zm´ınit, jak celé zaˇr´ızen´ı funguje, ˇcili jak jednotlivá zaˇr´ızen´ı mezi sebou komunikuj´ı. Blokové schema komunikace je znázornˇeno na obrázku 3.2:

Obrázek 3.2: Schema komunikace

1. Na stranˇe Modbus slave jsou v tzv. uchovávac´ıch registrech (Read Holding Registers) uloˇzena poˇzadovaná data. Jednotka T410, která v této komunikaci funguje jako Modbus slave, periodicky ˇcte a ukládá data, 2. Aby v´ yˇse zm´ınˇená komunikace prob´ıhala podle pˇredstav uˇzivatele, je nutné ji nˇejak´ ym zp˚ usobem parametrizovat (adresa Modbus slave, timeout mezi jednotliv´ ymi dotazy, atd.). K´ yˇzené parametry jsou pˇrenáˇseny acyklickou komunikac´ı mezi jednotkou FNL a T410. Dále je nutné data z jednotky T410 nahrát do pamˇeti jednotky FNL, k ˇcemuˇz slouˇz´ı tzv. cyklická komunikace (data je ovˇsem moˇzné pˇreˇc´ıst téˇz acyklicky), 3. Komunikace mezi ˇr´ıd´ıc´ı jednotkou a FNL je vpravdˇe zásadn´ı, nebot’ slouˇz´ı ke konfiguraci veˇskeré komunikace, tj. nastaven´ı parametr˚ u sbˇernice Profibus, jednotky T410, atd. a také k ˇr´ızen´ı komunikace mezi FNL a jednotkou T410 (pro tyto u ´ˇcely je k dispozici obsáhlá API). 17


Fieldbus Network Link (FNL)

V dalˇs´ıch kapitolách budou podrobnˇeji popsány obˇe jednotky – FNL a FintPROFI T410.

3.2


FNL je zaˇr´ızen´ı, které umoˇzn ˇuje propojen´ı s´ıt´ı typu ethernet (10/100 Mbit/s) a Profibus, v tomto pˇr´ıpadˇe verze PA (existuje ovˇsem také verze DP). Blokové schéma této jednotky, obsahuj´ıc´ı informace o napájen´ı a pouˇzit´ ych rozhran´ıch, je zobrazeno na následuj´ıc´ım obrázku (viz obr. 3.3).

Obrázek 3.3: Schema jednotky FNL Jednotka FNL je nejd˚ uleˇzitˇejˇs´ı souˇca´st´ı systému z hlediska programátora, nebot’ je v n´ı implementováno uˇzivatelské rozhran´ı, pˇres které je moˇzné volat r˚ uzné sluˇzby slouˇz´ıc´ı k parametrizaci s´ıtˇe a pˇrenosu dat do poˇc´ıtaˇce. Nutno podotknout, ˇze komunikace mezi poˇc´ıtaˇcem (ˇci jinou ˇr´ıd´ıc´ı jednotkou) prob´ıhá pˇres protokol TCP/IP (jednotka má pˇridˇelenu statickou IP adresu, v tomto pˇr´ıpadˇe 192.168.1.75) Uˇzivatelské rozhran´ı je navrˇzeno jako Dual-Port RAM (DPR), coˇz je, jak jiˇz název napov´ıdá, typ pamˇeti, kter´ y umoˇzn ˇuje v jeden okamˇzik zapisovat nebo ˇc´ıst data z obou port˚ u.[15]

18


3.2.1


Rozhran´ı Dual-Port RAM

Rozhran´ı lze rozdˇelit na dvˇe samostatné ˇcásti: 1. Command Interface - pˇrenos funkc´ı nebo sluˇzeb s poˇzadovan´ ymi parametry, 2. Process Data Image – obsahuje uˇzivatelská data a stavové informace o jednotliv´ ych zaˇr´ızen´ı. Struktura DPE je znázornˇena v tabulce 3.4:

Obrázek 3.4: Struktura DPE

Command Interface Jak jiˇz bylo zm´ınˇeno, Command Interface je rozhran´ı, které vzájemnˇe propojuje firmware FNL (jeˇz implementuje Profibus PA profil) s uˇzivatelem. Pro zv´ yˇsen´ı rychlosti pˇrenáˇsen´ı dat jsou k dispozici dva pamˇet’ové prostory pro odes´ılán´ı (Send-Box 1 a 2) a pˇr´ıjem (Receive-Box 1 a 2) dat.[15] Dostupné sluˇzby lze rozdˇelit do nˇekolika skupin jako pˇr´ıkazy pro: • lokáln´ı inicializaci a konfiguraci firmware, • acyklickou komunikaci, • cyklickou komunikaci, 19



• komunikaci typu Master-Master, • pˇr´ıjem lokáln´ıch indikac´ı. Pˇr´ıkazy lze dále dˇelit na potvrzované resp. nepotvrzované a pˇr´ıkazy inicializované uˇzivatelem (odes´ılány jako poˇzadavek na firmware) a inicializované firmwarem (odes´ılány uˇzivateli jako indikace). Pˇr´ıkazy jsou odes´ılány a pˇrij´ımány v tzv. mailboxech. Kaˇzd´ y mailbox se skládá z hlaviˇcky (mailbox header) a tˇela pˇr´ıkazu (mailbox-body), viz tabulka 3.1: Byte Vstup 0 Service 1 Group Mailbox header 2 Result 3 CommandID Mailbox body 4 ... n ... Tabulka 3.1: Mailbox - struktura

Service Hodnota pˇredstavuje kód volané sluˇzby, napˇr. 0x0A pro funkci load_bus_par

Group Veˇskeré volané sluˇzby lze rozdˇelit celkem do ˇctyˇr skupin: • inicializaˇcn´ı (0x04) – napˇr. restart_fdl • komunikaˇcn´ı (0x08) – napˇr. init_dp_master • lokáln´ı (0x07) – napˇr. get_live_list (jediná sluˇzba v této skupinˇe) • asynchronn´ı události vyvolané firmwarem (0x42) 20



Posledn´ı bit tohoto parametru (MSB) urˇcuje smˇer odes´ılán´ı poˇzadavku: • 0: smˇer uˇzivatel → firmware • 1: smˇer firmware → uˇzivatel

Result V´ ysledek volán´ı sluˇzby uloˇzen´ y firmwarem po zpracován´ı poˇzadavku. V pˇr´ıpadˇe odpovˇedi na poˇzadavek obsahuje informaci, zda volán´ı funkce probˇehlo bez problém˚ u nebo doˇslo k nˇejaké chybˇe. V pˇr´ıpadˇe, ˇze firmware odeˇsle indikaci nˇejaké události, obsahuje kód tzv. status message (viz pˇr´ıloha, kde jsou vˇsechny tyto zprávy popsány)

Command ID Tento parametr nen´ı pro firmware d˚ uleˇzit´ y, tud´ıˇz je z hlediska uˇzivatele nepodstatn´ y. Je moˇzné do nˇej uloˇzit napˇr. poˇrad´ı volán´ı sluˇzeb, ˇc´ımˇz se program stane pˇrehlednˇejˇs´ım. Pˇri potvrzován´ı má parametr stejnou hodnotu jako pˇri volán´ı funkce.

Obrázek 3.5: Pˇrehled komunikace v rámci FNL 21



Obrázek 3.5 pˇrehlednˇe ilustruje, jak prob´ıhá komunikace mezi uˇzivatelem, Command Interface a firmwarem.

Process Data Image Druhá ˇcást DPR se naz´ yvá Process Data Image a obsahuje: • Slave status - pole o velikosti 126 byt˚ u, kde kaˇzd´ y byte odpov´ıdá jednomu koncovému zaˇr´ızen´ı (slave), • Semafory - semafory jsou nezbytné pro zachován´ı konzistence vstupn´ıch resp. v´ ystupn´ıch dat. Rozliˇsuj´ı se ˇctyˇri druhy semafor˚ u: – UserLockInputs – uzamˇcen´ı pˇr´ıstupu k vstupn´ım dat˚ um uˇzivatelem, – FWLockInputs – uzamˇcen´ı pˇr´ıstupu k vstupn´ım dat˚ um firmwarem, – UserLockOutputs – uzamˇcen´ı pˇr´ıstupu k v´ ystupn´ım dat˚ um uˇzivatelem, – FWLockOutputs – uzamˇcen´ı pˇr´ıstupu k v´ ystupn´ım dat˚ um firmwarem. • Uˇ zivatelsk´ a data - data, která jsou pˇrenáˇsena bˇehem cyklické komunikace (MSCY_C1). Data jsou ukládána od adresy 0x484 s t´ım, ˇze jejich pˇresné um´ıstˇen´ı je specifikováno offsety, jeˇz jsou uˇzivatelem zvoleny pˇri volán´ı sluˇzby load_slave_parameters. V dalˇs´ıch ˇcástech této kapitoly nebudou popisovány jednotlivé sluˇzby, nebot’ vysvˇetlen´ı ˇcásti s nich i s konkrétn´ımi parametry je souˇca´st´ı praktické ´ y seznam vˇsech sluˇzeb vˇcetnˇe jejich kód˚ ˇcásti této diplomové práce. Upln´ u lze nalézt v [15].

3.2.2

Knihovn´ı funkce

Pro programátora je vskutku zásadn´ı otázka, jak´ ym zp˚ usobem se pˇripojit k jednotce FNL, jak odes´ılat resp. pˇrij´ımat vybrané sluˇzby, atd. Pro tyto u ´ˇcely dává v´ yrobce k dispozici knihovnu TMGnet.dll. S pomoc´ı funkc´ı z této

22



knihovny je moˇzné odes´ılat pˇr´ıkazy Command Interface a pˇristupovat k Process Data Image. V tabulce 3.2 jsou uvedeny vˇsechny funkce spolu se struˇcn´ ym popisem jejich ˇcinnosti, v dalˇs´ım textu jsou pak tyto funkce popsány ponˇekud podrobnˇeji.[15] N´ azev ConnectBoard ResetBoard DisconnectBoard GetRequestBlock a SendRequestBlock GetReceiveBlock a FreeReceiveBlock PutProcessData GetProcessData TransferProcessData GetTMGErrorMessage

Popis ˇcinnosti Pˇripojen´ı k jednotce Reset jednotky Odpojen´ı od jednotky Odeslán´ı pˇr´ıkazu jednotce Pˇr´ıjem dat z jednotky Uloˇzen´ı dat do Process Data Image ˇ ı dat z Process Data Image Cten´ Uloˇzen´ı/ˇcten´ı dat do/z Process Data Image Textová podoba chybov´ ych kód˚ u

Tabulka 3.2: Knihovn´ı funkce - struˇcn´ y popis

ConnectBoard Prototyp short USER_FUNCTION ConnectBoard (const char *BoardName, short ProtocolID);

Parametry : Jméno pˇridˇelené jednotce FNL (jméno je zaregistrováno v aplikaci TMG Net Series) short ProtocolID : Indentifikátor pouˇzitého protokolu char *BoardName

Popis Funkce ConnectBoard slouˇz´ı k pˇripojen´ı aplikace k FNL a mus´ı b´ yt vˇzdy volána jako prvn´ı. Zároveˇ n je po u ´spˇeˇsném pˇripojen´ı zaruˇceno, ˇze ˇza´dná dalˇs´ı aplikace nebude m´ıt k jednotce pˇr´ıstup (funkce vrát´ı chybov´ y status CONNECT_BOARDINUSE). Aplikace z˚ ustává pˇripojena do té doby, neˇz je zavolána funkce DisconnectBoard (viz dále) nebo dojde k ukonˇcen´ı aplikace (DLL tuto událost rozpozná a automaticky se odpoj´ı).

23



N´ avratov´ e hodnoty SUCCESS (0x00) CONNECT_BOARDINUSE (0x01) CONNECT_UNKNOWNBOARDNAME (0x02)

: : :

PROTOCOL_NOTSUPPORTED (0x0A) LOAD_BOARDNOTFOUND (0x14)

: :

LOAD_TIMEOUT (0x15)

:

LOAD_FILENOTFOUND (0x16) LOAD_FILECORRUPT (0x17) APP_ALREADYCONNECTED (0x1F) SYSTEM_DLLBLOCKED (0x28) SYSTEM_DEVICEDRIVERFAILED (0x29) SYSTEM_REGISTRYCORRUPTED (0x2A)

: : : : : :

Aplikace byla u ´spˇeˇsnˇe pˇripojena k FNL Jednotka je pouˇz´ıvána jinou aplikac´ı Jméno registrované aplikac´ı TMG Net Series nesouhlas´ı se jménem zadan´ ym jako parametr funkce ConnectBoard Jednotka nepodporuje zadan´ y typ protokolu Jednotka neexistuje (pravdˇepodobnˇe nebyla korektnˇe zaregistrována v systému) Pˇri nahráván´ı firmwaru doˇslo k vyprˇsen´ı ˇcasového limitu Firmware neexistuje Firmware je poˇskozen´ y Aplikace je jiˇz pˇripojena k jinému zaˇr´ızen´ı DLL knihovna je zablokována nˇekter´ ym z uˇzivatel˚ u ˇ c jednotky selhal Radiˇ Poˇskozené systémové registry

ResetBoard Prototyp short USER_FUNCTION ResetBoard (void);

Parametry Bez parametr˚ u. Popis Vyresetován´ı firmwaru jednotky FNL. N´ avratov´ e hodnoty SUCCESS (0x00) LOAD_BOARDNOTFOUND (0x14)

: :

LOAD_TIMEOUT (0x15)

:

LOAD_FILECORRUPT (0x17) APPL_NOT_CONNECTED (0x1E)

: :

Aplikace byla u ´spˇeˇsnˇe pˇripojena k FNL Jednotka neexistuje (pravdˇepodobnˇe nebyla korektnˇe zaregistrována v systému) Pˇri nahráván´ı firmwaru doˇslo k vyprˇsen´ı ˇcasového limitu Firmware je poˇskozen´ y Aplikace nen´ı pˇripojena k jednotce FNL

24



DisconnectBoard Prototyp short USER_FUNCTION DisconnectBoard(void);

Parametry Bez parametr˚ u. Popis Odpojen´ı aplikace od jednotky FNL. N´ avratov´ e hodnoty SUCCESS (0x00) APPL_NOT_CONNECTED (0x1E)

: :

Aplikace byla u ´spˇeˇsnˇe odpojena od FNL Aplikace nen´ı pˇripojena k jednotce FNL

GetRequestBlock a SendRequestBlock S vyuˇzit´ım tˇechto funkc´ı je aplikace schopna odeslat pˇr´ıkaz firmwaru pˇres Command Interface. Pˇr´ıkazy jsou pˇrenáˇseny ve tˇrech kroc´ıch: 1. V prvn´ım kroku je nutné z´ıskat ukazatel na prázdn´ y mailbox, ˇcehoˇz se dosáhne (v pˇr´ıpadˇe, ˇze je nˇejak´ y voln´ y) zavolán´ım funkce: short USER_FUNCTION GetRequestBlock (PTCommand *PSendBox);

kde PTCommand *PSendBox je ukazatel na strukturu, jeˇz bude po u ´spˇeˇsném dokonˇcen´ı funkce GetRequestBlock k dispozici pro uloˇzen´ı odpov´ıdaj´ıc´ıch parametr˚ u 2. V pˇr´ıpadˇe, ˇze funkce nevrátila nulov´ y ukazatel, je struktura naplnˇena daty, coˇz je ukázáno v následuj´ıc´ı ukázce funkce get_slave_diag: PTCommand m; m->GetSlaveDiag.Header.Service = 0x09; m->GetSlaveDiag.Header.Group = 0x08; m->GetSlaveDiag.SlaveAddress = 2;

3. V posledn´ım kroku docház´ı k odeslán´ı dat Command Interface funkc´ı: short USER_FUNCTION SendRequestBlock(PTCommand SendBox);

25



kde PTCommand SendBox je struktura (jeˇz odpov´ıdá struktuˇre mailboxu, viz v´ yˇse) obsahuj´ıc´ı konkrétn´ı parametry.

GetReceiveBlock a FreeReceiveBlock Tyto dvˇe funkce, na rozd´ıl od pˇredeˇsl´ ych dvou, slouˇz´ı k z´ıskán´ı dat, které dává k dispozici firmware. Operace je opˇet provedena ve tˇrech kroc´ıch: 1. Pro z´ıskán´ı ukazatele na mailbox naplnˇen´ y firmwarem je tˇreba zavolat funkci: short USER_FUNCTION GetReceiveBlock(PTCommand *PreceiveBox);

kde PTCommand *PreceiveBox je ukazatel na strukturu, jeˇz bude po u ´spˇeˇsném dokonˇcen´ı funkce GetReceiveBlock naplnˇena daty. 2. Dekódován´ı pˇrijat´ ych dat, jin´ ymi slovy podle hlaviˇcky, která obsahuje kód skupiny a funkce, poznáme, o jak´ y pˇr´ıkaz se jedná: short result; if (pm->GetSlaveDiag.Header.Group = CM_DP && pm->GetSlaveDiag.Header.Service = GET_SLAVE_DIAG) { result = pm->GetSlaveDiag.Header.Result; }

3. Na závˇer je tˇreba navrátit pˇrijat´ y mailbox zpátky firmwaru funkc´ı: short USER_FUNCTION FreeReceiveBlock(void);

PutProcessData Prototyp short USER_FUNCTION PutProcessData (short DataOffset, short DataLen, BYTE *ProcessDataPtr, short UserLock );

Parametry Popis Funkce slouˇz´ıc´ı k uloˇzen´ı dat (Output Data) do Process Data Image.

26



: Offset adresy pro uloˇzen´ı dat (0x484 + DataOffset) short DataLen : Délka pˇrenáˇsen´ ych dat (v bytech) BYTE *ProcessDataPtr : Ukazatel na data k pˇrenesen´ı short UserLock : Uzamˇcen´ı pˇr´ıstupu k v´ ystupn´ım dat˚ um v Process Data Image

short DataOffset

GetProcessData Prototyp short USER_FUNCTION GetProcessData (short DataOffset, short DataLen, BYTE *ProcessDataPtr, short UserLock);

Parametry : Offset adresy pro uloˇzen´ı dat (0x484 + DataOffset) short DataLen : Délka pˇrenáˇsen´ ych dat (v bytech) BYTE *ProcessDataPtr : Ukazatel na m´ısto v pamˇeti, kam se maj´ı uloˇzit data z Process Data Image short UserLock : Uzamˇcen´ı pˇr´ıstupu k vstupn´ım dat˚ um v Process Data Image

short DataOffset

Popis Funkce slouˇz´ıc´ı k pˇreˇcten´ı dat (Input Data) z Process Data Image.

TransferProcessData Prototyp short USER_FUNCTION TransferProcessData (TPDTransferPrm* PDPrm);

Parametry TPDTransferPrm* PDPrm – data, která maj´ı následuj´ıc´ı strukturu:

27



typedef { short DataOffset; short DataLen; BYTE *ProcessDataPtr; short UserLock; } TPDPrm; typedef struct { short SlaveAdd; short SlaveCount; BYTE *Pstatus; TPDPrm Write; TPDPrm Read; TPDTransferPrm;

Popis Funkce, která de facto kombinuje funkce GetProcessData a PutProcessData (struktura TPDPrm odpov´ıdá parametr˚ um tˇechto funkc´ı), nav´ıc je také pˇrijat Status stanice specifikované poloˇzkou SlaveAdd.

GetTMGErrorMessage Prototyp const char * USER_FUNCTION GetTMGErrorMessage( short ErrorCode, short Language);

Parametry short ErrorCode : Kód návratové hodnoty nˇekteré z v´ yˇse zm´ınˇen´ ych funkc´ı. short Language : Lokalizace (0 – nˇemˇcina, 1 – angliˇctina)

Popis Funkce vracej´ıc´ı textovou podobu chyb, které jsou reprezentovány kódem ErrorCode. Dalˇs´ı informace o jednotce FNL je moˇzné nalézt v [15].

28


3.3

FintPROFI T410

FintPROFI T410

Druh´ y modul, jenˇz byl pouˇzit pro vytvoˇren´ı komunikaˇcn´ıho ˇretˇezce, je jednotka T410 od norské spoleˇcnosti Fint (Fieldbus International AS). V modulu jsou implementovány dva protokoly - Modbus a Profibus PA, jedná se tedy o jakési rozhran´ı mezi tˇemito protokoly. Na sbˇernici se zaˇr´ızen´ı chová na stranˇe protokolu Modbus jako master, na stranˇe protokolu Profibus PA jako slave. Na obrázku 3.6 je znázornˇeno, jak vypadá zapojen´ı jednotky T410 do komunikaˇcn´ıho ˇretˇezce.

Obrázek 3.6: T410 - zapojen´ı do komunikaˇcn´ıho ˇretˇezce

3.3.1

Popis

Kaˇzdé Profibus PA zaˇr´ızen´ı obsahuje bloky, které obsahuj´ı r˚ uzné parametry. Jedná se o bloky: 29


FintPROFI T410

• fyzick´ y (Physical, PB) - zastˇreˇsuj´ıc´ı blok, • pˇ revodn´ıkov´ y (Transducer, TB) - zajiˇst’uje kontakt s mˇeˇric´ım ˇcidlem, provád´ı napˇr´ıklad linearizaci, • funkˇ cn´ı (Function, FB) - zprostˇredkovává namˇeˇrenou hodnotu (z´ıskána z pˇrevodn´ıkového bloku) na pˇripojenou sbˇernici, pˇri pˇrekroˇcen´ı nˇejakého limitu generuje alarmy. Jednotka T410 obsahuje 1 fyzick´ y blok, 4 funkˇcn´ı a 4 pˇrevodn´ıkové bloky. V pˇrevodn´ıkovém bloku jsou v pˇr´ıpadˇe jednotky T410 kromˇe parametr˚ u dan´ ych standardem také parametry, kter´ ymi se nastavuje chován´ı komunikace Modbusu. Jedná se o tyto parametry: Parametr PV Scaling

PV Unit PV’s Modbus register PV type Periodic Measurement Modbus address Modbus inbound data package Modbus inbound data package register address No of registers for inbound data Modbus outbound data package Modbus outbound data package register address No of registers for outbound data

V´ yznam Pˇreˇctenou hodnotu (PV = Primary Variable, dynamická promˇenná, hodnota ˇcteného Modbus registru) je moˇzné uloˇzit s ohledem na poˇcet desetinn´ ych m´ıst, napˇr. pro uloˇzen´ı na jedno desetinné m´ısto bude hodnota parametru 0.1. Jednotka pˇreˇctené hodnoty. Ukazatel na Modbus registr, z kterého má b´ yt PV ˇctena. Datov´ y typ promˇenné, napˇr. pro Float s bytov´ ym poˇrad´ım 1 2 3 4 je hodnota parametru 3. Perioda ˇcten´ı PV, udává se v sekundách. Adresa Modbus zaˇr´ızen´ı. Prostor, do nˇehoˇz jsou zaznamenávány hodnoty z Modbus registr˚ u (z´ıskané acyklick´ ym ˇcten´ım). Ukazatel na prvn´ı Modbus registr pro acyklické ˇcten´ı. Poˇcet Modbus registr˚ u, které se maj´ı pˇreˇc´ıst pˇri acyklickém ˇcten´ı. Prostor, pˇres kter´ y je moˇzné acyklicky zapsat data do Modbus zaˇr´ızen´ı. Ukazatel na prvn´ı Modbus registr pro acyklick´ y z´ apis. Poˇcet Modbus registr˚ u, do nichˇz se maj´ı zapsat data pˇri acyklickém zápisu.

Tabulka 3.3: Parametry pˇrevodn´ıkového bloku

30


FintPROFI T410

Ve fyzickém bloku je pak moˇzné nastavovat tyto parametry: • Poˇcet stop bit˚ u, • Baudrate, • Poˇrad´ı byt˚ u v CRC souˇctu, • Paritu. Dalˇs´ı informace o jednotce T410 je moˇzné nalézt v [7].

31

4 Realizace monitoru sbˇernice Profibus PA 4.1

´ Uvod

Po z´ıskán´ı vˇsech potˇrebn´ ych informac´ı o hardwarovém vybaven´ı a pouˇzit´ ych protokolech bylo dalˇs´ım krokem vytvoˇren´ı návrhu monitoru pˇrenáˇsen´ ych dat a jeho následná realizace. Na zaˇca´tku je jistˇe na m´ıstˇe zm´ınit, jaké prostˇredky byly pro aplikaci pouˇzity. Pro naprogramován´ı vlastn´ı logiky aplikace (komunikace s moduly) byl pouˇzit jazyk ANSI C a to hlavnˇe z toho d˚ uvodu, ˇze volán´ı knihovn´ıch funkc´ı je tomto jazyce pomˇernˇe jednoduchá záleˇzitost. Dalˇs´ı souˇcást´ı aplikace je grafické uˇzivatelské rozhran´ı (GUI) – pro jeho vytvoˇren´ı byla vyuˇzita knihovna QT verze 4.8.4. (potˇrebné informace byly ˇcerpány z [16]) Aplikace byla vyv´ıjena v prostˇred´ı NetBeans verze 7.1.2. Na dalˇs´ıch ˇrádc´ıch bude postupnˇe popsáno, jak´ ym zp˚ usobem aplikace funguje. Zvláˇstn´ı d˚ uraz pak bude kladen na ˇcten´ı parametr˚ u z jednotliv´ ych blok˚ u jednotky T410, nebot’ bylo této problematice vˇenováno znaˇcné mnoˇzstv´ı ˇcasu a jedná se bez nadsázky o základn´ı kámen vytvoˇrené aplikace. Zdrojové soubory jsou k dispozici na pˇriloˇzeném CD této práce.

4.2

N´ avrh aplikace

V kapitole 3 byl popsán systém, na jehoˇz zaˇca´tku je poˇc´ıtaˇc (ˇci jiné zaˇr´ızen´ı) slouˇz´ıc´ı jako ˇr´ıd´ıc´ı jednotka a na jehoˇz konci je zaˇr´ızen´ı, které na sbˇernici funguje jako Modbus Slave. Na obrázku 4.1 je pro pˇripomenut´ı tento systém znovu znázornˇen:

Obrázek 4.1: Schema systému 32

Realizace monitoru sbˇernice Profibus PA

Návrh aplikace

Z obrázku 4.1 je patrná hlavn´ı funkce vytváˇrené aplikace – ˇr´ıd´ıc´ı jednotka (na n´ıˇz monitor bˇeˇz´ı) by mˇela umˇet ˇc´ıst a interpretovat data, které odes´ılá Modbus Slave. Dalˇs´ı vˇec, která z obrázku také vypl´ yvá, je to, ˇze z´ıskat tato data nen´ı záleˇzitost triviáln´ı. Prvn´ım u ´kolem pˇri návrhu aplikace bylo zjiˇstˇen´ı, jak´ ym zp˚ usobem se v˚ ubec bude moˇzné do celého systému pˇripojovat. Jako základn´ı prostˇredn´ık pro pˇr´ıstup do systému byla z logick´ ych d˚ uvod˚ u zvolena jednotka FNL, s jej´ımˇz firmwarem je moˇzné komunikovat pˇres dostupné API (v´ıce informac´ı o jednotce FNL a knihovn´ıch funkc´ıch je moˇzné zjistit z kapitol 3.2 a 3.2.2). Dostupné knihovn´ı funkce se staly tedy kamenem u ´razu celé aplikace – jejich vhodn´ ym volán´ım a parametrizac´ı by na konci mˇelo b´ yt moˇzné ˇc´ıst data z jednotky Modbus Slave, coˇz bylo hlavn´ım u ´kolem této diplomové práce (spolu s vytvoˇren´ım vhodné filtrace tˇechto dat). V dalˇs´ı ˇca´sti bude nejprve ukázáno schéma popisuj´ıc´ı chován´ı navrˇzené aplikace v jednotliv´ ych kroc´ıch, v dalˇs´ım textu budou pak tyto kroky popsány d˚ ukladnˇeji.

33


4.3

Aplikace - ˇreˇsen´ı

Aplikace - ˇ reˇ sen´ı

ˇ Obrázek 4.2: Zivotn´ ı cyklus aplikace Obrázek 4.2 znázorˇ nuje, jak´ ymi stavy aplikace procház´ı v pr˚ ubˇehu jej´ıho ˇzivotn´ıho cyklu. Jednotlivé stavy budou nyn´ı podrobnˇe popsány (ˇca´st t´ ykaj´ıc´ı se zmˇen parametr˚ u je pak rozˇs´ıˇrena o popis ˇcten´ı parametr˚ u z blok˚ u jednotky T410).

4.3.1

Start aplikace

Po spuˇstˇen´ı aplikace je uˇzivateli nab´ıdnuto okno (viz obr. 4.3), kde jedinou dostupnou moˇznost´ı je nalezen´ı konkrétn´ıho GSD souboru. Uˇzivatelsk´ y manuál aplikace je k dispozici v pˇr´ıloze tohoto dokumentu.

34



Obrázek 4.3: Vstupn´ı okno aplikace

4.3.2

Naˇ cten´ı GSD souboru

Prvn´ı u ´kon, kter´ y je nutné udˇelat pˇred samotn´ ym pˇripojen´ım k jednotce FNL, je pˇreˇcten´ı a zpracován´ı tzv. GSD souboru. General Station Description (GSD) je soubor obsahuj´ıc´ı informace o kaˇzdé jednotce, která vystupuje v s´ıti Profibus. Soubor je v´ yrobcem standardnˇe dodáván ke kaˇzdému zaˇr´ızen´ı a má standardizovan´ y formát. Vznik GSD souboru mˇel ryze praktické d˚ uvody – kaˇzdé zaˇr´ızen´ı má své specifické parametry (Baudrate, adresa, ˇcasové konstanty, atd.), které jsou dostupné v manuálu. Aby byla práce se zaˇr´ızen´ım co nejjednoduˇsˇs´ı, obsahuje GSD tyto parametry, které pak staˇc´ı s vyuˇzit´ım nˇejakého nástroje naˇc´ıst a zpracovat.[6]

35



Kaˇzd´ y GSD soubor má následuj´ıc´ı strukturu: • Hlaviˇcka – napˇr.: #Profibus_DP • Parametry ve formátu = – napˇr.: Ident_Number = 0xa002 • Konfigurace ve formátu: Module = <poradi> EndModule – napˇr.: ;Modules for Analog Input Module = "Analog Input (AI)short"0x94 2 EndModule Konfigurace specifikuje mnoˇzstv´ı a uspoˇrádán´ı cyklicky pˇrenáˇsen´ ych dat. Je urˇcena pˇres tzv. identifikátor a vyskytuje se ve dvou formátech - jednoduch´ y (velikost 1 byte) a speciáln´ı (velikost minimálnˇe 2 byty). Z GSD souboru pro jednotku T410 lze vyˇc´ıst, ˇze jsou pro ni k dispozici 2 konfigurace - 0x94 (jednoduch´ y formát) a 0x42 0x84 0x08 0x05 (speciáln´ı formát). Pro zaj´ımavost si na zm´ınˇeném jednoduchém formátu dále pop´ıˇseme, jak tyto hodnoty interpretovat (viz obr. 4.4). Dalˇs´ı informace o konfiguraci a GSD souborech lze naj´ıt v [6].

Obrázek 4.4: Konfigurace - jednoduch´ y formát

36



Zpracován´ı GSD souboru ve vyv´ıjené aplikaci je pomˇernˇe jednoduché. Po otevˇren´ı je soubor procházen ˇra´dek po ˇra´dku. Z kaˇzdého ˇrádku jsou odstranˇeny komentáˇre (text za znakem ’;’) a mezery. Protoˇze známe pˇresnou strukturu dokumentu, nen´ı sloˇzité následnˇe z´ıskat kl´ıˇcové slovo a odpov´ıdaj´ıc´ı hodnotu v pˇr´ıpadˇe parametr˚ u a název modulu s identifikátorem v pˇr´ıpadˇe konfigurace. Kaˇzdá tato dvojice je uloˇzena do struktury a ta je následnˇe uloˇzena do pole: struct info char name[80]; char value[80]; object_info; Kompletn´ı obsah GSD souboru pro jednotku T410 je moˇzné nalézt v pˇr´ıloze v kapitole A.2, samotn´ y soubor pak na pˇriloˇzeném CD.

4.3.3

Pˇ ripojen´ı a inicializace spojen´ı

Po naˇcten´ı GSD souboru je uˇzivateli zpˇr´ıstupnˇeno tlaˇc´ıtko pro pˇripojen´ı k jednotce FNL. Po jeho stisknut´ı dojde sekvenˇcnˇe k vykonán´ı tˇechto operac´ı: 1. pˇripojen´ı k jednotce FNL funkc´ı ConnectBoard (popsána v kapitole 3.2.2), 2. nahrán´ı parametr˚ u sbˇernice pˇr´ıkazem load_bus_parameters, 3. inicializace firmwaru pˇr´ıkazem init_dp_master tak, ˇze poté bude firmware na sbˇernici pracovat jako Profibus Master. V následuj´ıc´ım textu bude nejprve popsán krok 2 spolu s vysvˇetlen´ım, jak vypadá vykonán´ı urˇcitého pˇr´ıkazu, následnˇe bude jiˇz struˇcnˇeji popsán krok 3, protoˇze princip práce s pˇr´ıkazy je totoˇzn´ y.

Parametry sbˇ ernice Pro správné fungován´ı celé aplikace je nutné zajistit korektn´ı chován´ı komunikace na sbˇernici, coˇz je zajiˇstˇeno jej´ı vhodnou parametrizac´ı. Nˇekteré z para37



metr˚ u byly v pˇredchoz´ım kroku pˇreˇcteny z GSD souboru jednotky T410 a staticky uloˇzeny v ˇr´ıd´ıc´ı jednotce. Následnˇe je tˇreba parametry pˇredat dál jednotce FNL. K odeslán´ı parametr˚ u sbˇernice slouˇz´ı pˇr´ıkaz load_bus_parameters. V tabulce 4.1 jsou shrnuty odes´ılané parametry vˇcetnˇe jejich struˇcného popisu. Parametr Baudrate

Popis ˇ ıslo na stupnici od 0 do 10 urˇcuje hodnotu Baudrate C´ (viz tab. 4.2). ˇ Slot-Time Casov´ yu ´sek, bˇehem nˇehoˇz ˇceká Master na odpovˇed’ od Slave pˇredt´ım, neˇz odeˇsle dalˇs´ı telegram. Minimum Tsdr Minimáln´ı doba, po kterou Slave mus´ı ˇcekat s odeslán´ım odpovˇedi. Hodnota mus´ı b´ yt menˇs´ı neˇz maximum Tsdr. Maximum Tsdr Maximáln´ı doba, po kterou Slave m˚ uˇze ˇcekat s odeslán´ım odpovˇedi. Hodnota mus´ı b´ yt menˇs´ı neˇz Slot-time. Maximum Tsdr Maximáln´ı doba, po kterou Slave m˚ uˇze ˇcekat s odeslán´ım odpovˇedi. Hodnota mus´ı b´ yt menˇs´ı neˇz Slot-time. ˇ Casov´ yu ´sek, po kter´ y mus´ı vys´ılaj´ıc´ı stanice po odeslán´ı Quiet Time dat ˇcekat, neˇz bude moci data pˇrij´ımat. Setup Time Doba mezi pˇr´ıchodem události (napˇr. pˇreruˇsen´ı) a reakc´ı na ni. GAP Factor Hodnota specifikuje poˇcet cykl˚ u, bˇehem niˇz jsou hledána nová zaˇr´ızen´ı snaˇz´ıc´ı se pˇripojit do systému. HSA Nejvyˇsˇs´ı adresa zaˇr´ızen´ı, jeˇz operuje na segmentu. Max-Retry-Limit Specifikuje poˇcet opakován´ı telegramu, pokud adresovaná stanice neodpov´ıdá. Tabulka 4.1: Parametry sbˇernice Hodnota Baud Rate[kBaud]

0 9,6

1 19,2

2 93,75

3 187,5

4 500

5 1500

6 3000

7 6000

8 12000

9 45,45

Tabulka 4.2: Mapován´ı ˇc´ısel na Baud Rate S vyuˇzit´ım funkc´ı, jeˇz byly popsány v kapitole 3.2.2, je nyn´ı moˇzné odeslat pˇr´ıkaz firmwaru. Postup odes´ılán´ı pˇr´ıkazu je ve vytvoˇrené aplikaci následuj´ıc´ı:

38

10 31,25



1. Zavolán´ı aplikaˇcn´ı funkce GetSendBox: Ve smyˇcce je nejprve volána knihovn´ı funkce GetReceiveBlock, která zjiˇst’uje, zda nedoˇslo na sbˇernici k nˇejaké asynchronn´ı události (napˇr. time out, indikace duplicitn´ı adresy, atd.) Pokud je událost zachycena, je následnˇe volána funkce FreeReceiveBlock pro navrácen´ı pˇrijatého mailboxu zpátky firmwaru. Pˇred otáˇckou cyklu je nakonec zavolána funkce GetRequestBlock, která v pˇr´ıpadˇe u ´spˇechu vrát´ı nenulov´ y ukazatel(m) na mailbox, ˇc´ımˇz ukonˇc´ı smyˇcku. 2. Naplnˇen´ı mailboxu daty: Pro uloˇzen´ı dat jsou pouˇzity struktury, a to takov´ ym zp˚ usobem, aby odpov´ıdaly uspoˇrádán´ı mailboxu (viz 3.2.1). Pro pˇr´ıkaz load_bus_parameters vypadá naplnˇen´ı dat takto: m->LoadBusParameter.Header.Service = LOAD_BUS_PARAMETER; /*0x0A*/ m->LoadBusParameter.Header.Group = CM_DP; /*0x08*/ m->LoadBusParameter.Baudrate = 10; /*31,25 kBaud*/ m->LoadBusParameter.BusParameter.SlotTime = 4094; m->LoadBusParameter.BusParameter.MinTsdr = 22; m->LoadBusParameter.BusParameter.MaxTsdr = max_tsdr; /*pˇ reˇ cteno z GSD souboru*/ m->LoadBusParameter.BusParameter.QuietTime = 0; m->LoadBusParameter.BusParameter.SetTime = 55; m->LoadBusParameter.BusParameter.GapFactor = 10; m->LoadBusParameter.BusParameter.HighestStationAdress = 126; m->LoadBusParameter.BusParameter.MaxRetryLimit = 1;

3. Odeslán´ı dat funkc´ı sendRequestBlock, ˇ an´ı prob´ıhá opˇet 4. Po odeslán´ı dat je tˇreba poˇckat na reakci firmwaru. Cek´ ve smyˇcce, kdy se opakovanˇe volá funkce GetReceiveBlock. Znovu se testuje, zda nedoˇslo k asynchronn´ı události, a také to, zda odpovˇed’, kterou v tento okamˇzik odeslal firmware, odpov´ıdá odeslan´ ym dat˚ um (ˇcast´ y pˇr´ıpad, kdy napˇr´ıklad firmware odpov´ı pˇr´ıkazem ddlm_abort). Pokud funkce vrát´ı správnou odpovˇed’ (parametry Service a Group odpov´ıdaj´ı odeslan´ ym dat˚ um), skonˇc´ı smyˇcka a dojde k otestován´ı parametru Result, zda pˇr´ıjem dat na stranˇe firmwaru skonˇcil u ´spˇechem.

39



Inicializace firmwaru Po nahrán´ı parametr˚ u sbˇernice je jiˇz moˇzné, aby doˇslo k inicializaci tzv. Class-1-master jádra, jin´ ymi slovy, aby se firmware jako master pˇripojil do s´ıtˇe Profibus. Do okamˇziku zavolán´ı tohoto pˇr´ıkazu bylo zm´ınˇené jádro ve stavu OFFLINE, po u ´spˇeˇsném zavolán´ı inicializaˇcn´ıho pˇr´ıkazu init_dp_master pˇrejde do stavu STOP.

4.3.4

Zad´ an´ı adresy

Firmware uˇz v tomto okamˇziku pracuje na sbˇernici jako master, ale nemá ˇzádné informace o okoln´ıch stanic´ıch, které se na sbˇernici mohou vyskytovat. Pro navázán´ı spojen´ı s nˇekter´ ym zaˇr´ızen´ım potˇrebuje master znát jeho adresu, coˇz ovˇsem nen´ı informace, která by se vyskytovala v GSD souboru, a proto je tˇreba vyuˇz´ıt pˇr´ıkazu get_live_list. V pˇr´ıpadˇe, ˇze skonˇc´ı volán´ı pˇr´ıkazu u ´spˇechem, je k dispozici pole o 127 bytech. Indexy poloˇzek v poli odpov´ıdaj´ı jednotliv´ ym adresám a data, která tyto poloˇzky obsahuj´ı, se interpretuj´ı takto: • 0 → stanice je slave, • 3 → stanice je master, • 4 → ˇzádná stanice s touto adresou nen´ı na sbˇernici pˇr´ıtomna.

4.3.5

Zmˇ ena parametr˚ u

Na sbˇernici je moˇzné pˇripojit mnoho r˚ uzn´ ych zaˇr´ızen´ı s mnoha r˚ uzn´ ymi parametry. Od zaˇca´tku byla snaha vytvoˇrit aplikaci, která bude nav´ ysost univerzáln´ı, a proto je moˇzné jeˇstˇe pˇred zaˇcátkem cyklické komunikace nˇekteré d˚ uleˇzité parametry zmˇenit. Jedná se o tento v´ ybˇer: • Poˇcet stop bit˚ u, • Baudrate, • CRC poˇrad´ı, 40



• Parita, • Adresa Modbus zaˇr´ızen´ı, • Typ pˇrenáˇsené promˇenné (napˇr. float, integer, atd.), • Adresa Modbus registru. ˇ Cten´ ı blok˚ u z jednotky T410 V u ´vodu kapitoly 4 bylo zm´ınˇeno, ˇze v sekci t´ ykaj´ıc´ı se ˇcten´ı parametr˚ u bude popsán postup ˇcten´ı blok˚ u z jednotky T410. Toto zaˇrazen´ı se ukázalo nakonec jako jediné smysluplné, protoˇze zmˇena parametr˚ u je v celé aplikaci jediné m´ısto, kde ke ˇcten´ı resp. zápisu do blok˚ u docház´ı. Kaˇzdé Profibus PA zaˇr´ızen´ı obsahuje jeden fyzick´ y blok (Physical block) a alespoˇ n jeden blok funkˇcn´ı (Function) a pˇrevodn´ıkov´ y (Transducer). Pˇr´ıstup k tˇemto blok˚ um je zajiˇstˇen pˇres dvojici slot-index. Kaˇzdé konkrétn´ı zaˇr´ızen´ı má tyto bloky jinak adresované, a proto je nejprve nutné zjistit, kde se tyto bloky v adresn´ım prostoru nacház´ı. Jednotka Fint T410 obsahuje 1 fyzick´ y blok (PB), 4 funkˇcn´ı (FB) a 4 pˇrevodn´ıkové (TB) bloky. Prvn´ım krokem je pˇreˇcten´ı tzv. adresáˇre objekt˚ u. Adresáˇr se skládá z hlaviˇcky (Directory Object Header), souhrnn´ ych informac´ı o bloc´ıch (Composite List Directory) a z ukazatel˚ u na jednotlivé bloky (Composite Directory). Hlaviˇcku adresáˇre objekt˚ u je moˇzné nalézt u kaˇzdého Profibus PA zaˇr´ızen´ı na pozici slot = 1 a index = 0 a má tuto strukturu (viz tabulka 4.3, která obsahuje parametry pˇreˇctené z jednotky T410): 2B DIR ID 0 NO DIR ENTRIES 12

2B DIR REV NO 1 FIRST COMP LIST DIR ENTRY 1

2B NO DIR OBJ 1 NO COMP LIST DIR ENTRY 3

Tabulka 4.3: Hlaviˇcka adresáˇre objekt˚ u

41



Jednotlivé poloˇzky pak maj´ı tento v´ yznam: • DIR_ID: Identifikaˇcn´ı ˇc´ıslo adresáˇre, ˇ ıslo revize, • DIR_REV_NO: C´ • NO_DIR_OBJ: Poˇcet dalˇs´ıch index˚ u pouˇzit´ ych ze slotu ˇc´ıslo 1, • NO_DIR_ENTRIES: Celkov´ y poˇcet poloˇzek v Composite List Directory a v Composite Directory, • FIRST_COMP_LIST_DIR_ENTRY: Index prvn´ı poloˇzky Composite List Directory, jeˇz se nacház´ı vˇzdy ve slotu ˇc´ıslo 1, • NO_COMP_LIST_DIR_ENTRY: Poˇcet poloˇzek v Composite List Directory (poloˇzkou se mysl´ı trojice Index, Offset a NO PB, ˇcili celkem 4B, viz dále). Po pˇreˇcten´ı hlaviˇcky je moˇzné pˇreˇc´ıst zároveˇ n Composite List Directory a Composite Directory, nebot’ hodnoty obou skupin se nacház´ı ve slotu 1 a na indexu pˇreˇcteném z tabulky (pro jednotku T410 je tento index 1). Po pˇreˇcten´ı celé této skupiny dat je nutné nejprve zjistit hodnoty obsaˇzené v adresáˇri Composite List Directory, kter´ y má tuto strukturu (viz 4.4): 1B 1B Index PB Index Offset

2B NO PB

1B 1B Index TB Index Offset

2B NO TB

1B 1B Index FB Index Offset

2B NO FB

Tabulka 4.4: Composite List Directory Pro kaˇzd´ y typ bloku jsou udány tyto parametry: • Index: Pozice zaˇca´tku dat bloku, • Offset: Pozice dat na daném indexu (Offset × 4B), • No_PB/TB/FB: Poˇcet blok˚ u daného typu. Pro jednotku Fint T410 vypadá Composite List Directory takto (viz tabulka 4.5):

42

Realizace monitoru sbˇernice Profibus PA 1B 1B Index PB Index Offset 1 4

2B NO PB 1

1B 1B Index TB Index Offset 1 5

Aplikace - ˇreˇsen´ı 2B NO TB 4

1B 1B Index FB Index Offset 1 9

2B NO FB 4

Tabulka 4.5: T410 - Composite List Directory Nyn´ı je moˇzné pˇreˇc´ıst konkrétn´ı informace o vˇsech bloc´ıch (Composite Directory), které se nacház´ı ve stejném slotu (1) a na indexu a offsetu pˇreˇcteném z Composite List Directory. Pokud chceme napˇr´ıklad zjistit, kde se nacház´ı vˇsechny informace o fyzickém bloku, pˇreˇcteme data ze slotu 1, indexu 1 a ukazatel na data zv´ yˇs´ıme o 4B. Tabulka 4.6 znázorˇ nuje, jak vypadá struktura Composite Directory fyzického bloku (pro ostatn´ı bloky je struktura stejná): 1B 1B 2B Physical Block ˇ ıslo Slot Index C´

Tabulka 4.6: Composite Directory Pro fyzick´ y blok jednotky T410 vypadá obsah Composite Directory takto: Index = 0, slot = 0, poˇcet = 38. Nyn´ı jsou k dispozici potˇrebné u ´daje k tomu, aby bylo moˇzné pˇreˇc´ıst poˇzadované informace z jednotliv´ ych blok˚ u. Pro ˇcten´ı resp. zápis dat jsou k dispozici pˇr´ıkazy ddlm_read resp. ddlm_write s tˇemito parametry (viz tabulka 4.7): Parametr Handle

Popis Identifikace spojen´ı, slouˇz´ı pouze k informativn´ım u ´ˇcel˚ um Slot number Hodnota slotu (ˇc´ıslo od 0 do 255) Index Hodnota indexu (ˇc´ıslo od 0 do 255) Length Poˇcet byt˚ u dat k pˇreˇcten´ı Data (pro ddlm write) data, která maj´ı b´ yt zapsána na dané um´ıstˇen´ı Tabulka 4.7: Parametry pˇr´ıkaz˚ u ddlm read a ddlm write V pˇr´ıpadˇe pˇr´ıkazu ddlm_read obsahuje odpovˇed’ firmwaru k´ yˇzená data (parametr odpovˇedi Data).

43


4.3.6


ˇ Cten´ ı dat

Po pˇripojen´ı a inicializaci spojen´ı, zadán´ı adresy a pˇr´ıpadné zmˇenˇe parametr˚ u je dalˇs´ım krokem ˇcten´ı dat, která jsou k dispozici v zaˇr´ızen´ı vystupuj´ıc´ı na sbˇernici jako Modbus Slave. V této ˇca´sti se také zmˇen´ı vzhled aplikace, coˇz demonstruje obrázek 4.5

Obrázek 4.5: Aplikace - zachytáván´ı dat Proces ˇcten´ı dat je doslova kapitolou sama pro sebe. Po stisknut´ı tlaˇc´ıtka pro zahájen´ı cyklické komunikace dojde opˇet k vykonán´ı sekvence pˇr´ıkaz˚ u: • naˇcten´ı dalˇs´ıch parametr˚ u (konkrétn´ı informace o slave, ˇcili o jednotce T410) pˇr´ıkazem load_slave_parameters, • zahájen´ı cyklické komunikace pˇr´ıkazem start_data_exchange, • ˇcten´ı Modbus dat z Process Data Image. V následuj´ıc´ım textu budou struˇcnˇe popsány prvn´ı zm´ınˇené kroky (jedná se o standardn´ı volán´ı pˇr´ıkaz˚ u), vˇetˇs´ı d˚ uraz bude kladen na ˇcten´ı dat z Process Data Image, protoˇze to bylo zat´ım zm´ınˇeno pouze v teoretické ˇcásti v kapitole 3.2.1.

44



Parametry zaˇ r´ızen´ı Modbus slave GSD soubor obsahuje kromˇe informac´ı o sbˇernici také parametry, které se pˇr´ımo vztahuj´ı k hardwaru dané jednotky. Pˇred zaˇca´tkem cyklické komunikace je tedy nezbytné dodat tyto parametry jednotce Modbus Master (inicializovan´ y firmware jednotky FNL). Tabulka 4.8 obsahuje kromˇe názvu také konkrétn´ı hodnoty pro jednotku T410 (spolu s vysvˇetlen´ım jejich v´ yznamu). Parametr: Slave Address Hodnota: Address V´ yznam: Promˇenn´ a address obsahuje adresu Modbus Slave zaˇr´ızen´ı, jeˇz byla pˇreˇctena v kroku ˇcten´ı parametr˚ u. Parametr: Sl_Flag Hodnota: 0x80 V´ yznam: Zaˇr´ızen´ı bude aktivováno po zapsán´ı parametr˚ u, ˇcili se bude moci z´ uˇcastnit cyklické komunikace. Parametr: WDFact1, WDFact2 Hodnota: 0x00; 0x00 V´ yznam: Watchdog je deaktivován. Parametr: Identification Number Hodnota: 0xA002 V´ yznam: Identifikaˇcn´ı ˇc´ıslo zaˇr´ızen´ı (pˇreˇcteno z GSD). Parametr: Freeze Requested Hodnota: 0x00 V´ yznam: Zaˇr´ızen´ı nepodporuje tzv. Freeze Mode (zamrznut´ı hodnoty na vstupu). Parametr: Sync Requested Hodnota: 0x00 V´ yznam: Zaˇr´ızen´ı nepodporuje tzv. Sync Mode (zamrznut´ı hodnoty na v´ ystupu). Parametr: User Parameters Length Hodnota: 0x03 V´ yznam: Délka User_Prm_Data v bytech (viz dále). Parametr: Minimum Slave Interval Hodnota: 0x7D0 ˇ (200µs) mezi dvˇema ˇctec´ımi cykly (Master→Slave). V´ yznam: Cas Parametr: Group Identification Hodnota: 0x00 V´ yznam: Slave nen´ı pˇriˇrazen do ˇzádné skupiny Slave zaˇr´ızen´ı. Parametr: Group Identification Hodnota: 0x00 V´ yznam: Slave nen´ı pˇriˇrazen do ˇzádné skupiny Slave zaˇr´ızen´ı. Parametr: Maximum Diagnostic Data Length Hodnota: 0x0E V´ yznam: Maxim´ aln´ı délka diagnostick´ ych dat, které odes´ılá slave masteru. Parametr: Offset Inputs Hodnota: 0x2 V´ yznam: Offset v Process Data Image - od tohoto offsetu budou ukládána pˇr´ıchoz´ı Modbus data pˇri cyklické komunikaci.

45



Parametr: Offset Outputs Hodnota: 0x1A V´ yznam: Offset v Process Data Image - od tohoto offsetu budou ukládána odchoz´ı Modbus data pˇri cyklické komunikaci. Parametr: Config Length Hodnota: 0x01 V´ yznam: Délka konfiguraˇcn´ıch dat (viz kapitola A.2). Hodnota: Parametr: Config And User Parameter Data 0x94;0x00;0x00;0x00 V´ yznam: Podle parametru Config Length je prvn´ı byte konfiguraˇcn´ı, ostatn´ı byty jsou poté uˇzivatelsk´ ymi parametry (pˇreˇctené z GSD souboru).

Tabulka 4.8: Parametry pˇr´ıkazu load_slave_parameters

Zah´ ajen´ı cyklick´ e komunikace Po naˇcten´ı vˇsech potˇrebn´ ych parametr˚ u je jiˇz moˇzné zahájit cyklickou komunikaci Master→Slave, k ˇcemuˇz slouˇz´ı pˇr´ıkaz start_data_exchange. Na následuj´ıc´ıch ˇrádc´ıch je pro ilustraci uveden pˇrepis metody, v n´ıˇz je pˇr´ıkaz start_data_exchange volán: void MainWindow::startDataExchange() { short result; PTCommand m; bool success; m = Communication::GetSendBox(); m->StartDataExchange.Header.Group = CM_DP; m->StartDataExchange.Header.Service = START_DATA_EXCHANGE; result = Communication::sendRequestBlock(m); success = Communication::testResult("StartDataExchange", result); if (success) { m = Communication::WaitRecBlock(CM_DP | CM_READY, START_DATA_EXCHANGE); result = m->StartDataExchange.Header.Result; success = Communication::testResult("StartDataExchange", result); } if (success) { result = Communication::freeReceiveBlock(); success = Communication::testResult("StartDataExchange", result); } }

46



ˇ Cten´ ı dat z Process Data Image

Obrázek 4.6: Schema procesu pˇrenosu Modbus dat k ˇr´ıd´ıc´ı jednotce Na obrázku 4.6 je pˇrehlednˇe znázornˇeno, jak vypadá komunikace napˇr´ıˇc cel´ ym systémem. Konkrétnˇe se dá komunikace rozdˇelit na tyto ˇca´sti: 1. Pˇ renos dat mezi Modbus Slave a Modbus Master (T410) - data jsou ˇctena z Modbus zaˇr´ızen´ı, jehoˇz adresa a adresa ˇcteného registru byly nastaveny v prvn´ı ˇcásti aplikace (viz kapitola 4.3.5), 2. Cyklick´ a komunikace - cyklická komunikace byla zahájena pˇr´ıkazem start_data_exchange, jenˇz byl popsán v pˇredchoz´ı kapitole. Pˇri této komunikaci docház´ı k pˇrenosu tzv. primárn´ı promˇenné (hodnota v´ yˇse uvedeného Modbus registru) mezi jednotkou T410 (pracuj´ıc´ı jako Profibus Slave) a jednotkou FNL (jej´ıˇz firmware funguje jako Profibus Master). Data jsou na stranˇe FNL ukládány do Process Data Image, konkrétnˇe do m´ısta, jeˇz urˇcuje parametr Offset Inputs definovan´ y v pˇr´ıkazu load_slave_parameters. ˇ 3. Cten´ ı dat z Process Data Image - tato ˇca´st je z hlediska implementace nejzaj´ımavˇejˇs´ı, a proto bude na následuj´ıc´ıch ˇrádc´ıch bl´ıˇze popsána. Pro pˇrenos dat z Process Data Image je k dispozici nˇekolik pˇr´ıkaz˚ u, jeˇz byly popsány v kapitole 3.2.2. V aplikace je pro tento u ´ˇcel pouˇzit pˇr´ıkaz get_process_data, protoˇze pro u ´ˇcel aplikace je potˇrebná pouze funkce ˇcten´ı. Vstupn´ımi parametry jsou: • data_offset - offset do adresn´ıho prostoru Process Data Image. Mus´ı b´ yt shodn´ y s parametrem Offset Inputs pˇr´ıkazu load_slave_parameters, 47



• data_len - poˇcet pˇrenáˇsen´ ych dat (v bytech). V aplikaci je nastavena na 24 byt˚ u (konstanta MAX_COMM_DATA_LEN), ovˇsem k´ yˇzenou primárn´ı promˇennou lze naj´ıt na prvn´ıch pˇeti bytech, • process_data_ptr - ukazatel na pole byt˚ u, do nˇehoˇz budou data uloˇzena (má tedy statickou velikost MAX_COMM_DATA_LEN). Ve zdrojovém kódu vypadá volán´ı pˇr´ıkazu takto: void MainWindow::getProcessData() { BYTE InputData[MAX_COMM_DATA_LEN]; /* inicializace pole na sam´ e nuly */ memset(&InputData, 0x00, sizeof (InputData)); /* INPUT_OFFSET = 0x02, MAX_COMM_DATA_LEN = 0x18 */ short result = GetProcessData (INPUT_OFFSET, MAX_COMM_DATA_LEN, InputData, TRUE); }

Do pole InputData jsou po u ´spˇeˇsném zavolán´ı funkce GetProcessData nakop´ırována data z Process Data Image, jak ilustruje i obrázek 4.7.

Obrázek 4.7: Pr˚ uchod dat z registr˚ u Modbus Slave do pole v ˇr´ıd´ıc´ı jednotce

48



Spolu s daty je z Process data Image pˇreˇcten také tzv. Status Byte (SB). Pro pochopen´ı v´ yznamu SB je nejprve nutné pochopit, jak u protokolu Profibus PA funguj´ı tzv. kontroly limit˚ u. Princip kontroly limit˚ u je pomˇernˇe jednoduch´ y - kaˇzdé zaˇr´ızen´ı má pˇrednastaveny limity, po jejichˇz pˇrekroˇcen´ı dojde k nastaven´ı odpov´ıdaj´ıc´ı promˇenné. Celkem jsou v PA zaˇr´ızen´ıch rozliˇsovány 4 druhy limit˚ u: • Upper Alarm Limit (HI_HI_LIM), • Upper Warning Limit(HI_LIM), • Lower Warning Limit (LO_LIM), • Lower Alarm Limit (LO_LO_LIM) V´ yznam limit˚ u je demonstrován na obrázku 4.8:

Obrázek 4.8: Limity Vytvoˇrená aplikace umoˇzn ˇuje uˇzivateli nastavovat tyto limity, coˇz je patrné z obrázku 4.5. Limity jsou nastavovány standardn´ım procesem ˇcten´ı a zápisu do funkˇcn´ıho bloku.

49



Nyn´ı je jiˇz moˇzné vysvˇetlit v´ yznam Status Bytu. Status Byte je pˇriˇrazen ke kaˇzdé namˇeˇrené hodnotˇe a má následuj´ıc´ı formát (viz obr. 4.9):

Obrázek 4.9: Status Byte

• Kvalita - informace o namˇeˇrené hodnotˇe, • Podrobnosti o kvalitˇ e - rozˇsiˇruj´ıc´ı informace o namˇeˇrené hodnotˇe, • Limity - informace, zda byl pˇrekroˇcen nˇekter´ y z limit˚ u. Nab´ yvá tˇechto hodnot: – 00 - namˇeˇrená hodnota je validn´ı, nepˇrekraˇcuje ˇzádn´ y limit, – 01 - namˇeˇrená hodnota je menˇs´ı neˇz doln´ı limit, – 11 - namˇeˇrená hodnota je vyˇsˇs´ı neˇz horn´ı limit. Ve vytvoˇrené aplikaci je kaˇzd´ y Status Byte zaznamenáván do zvláˇstn´ıho sloupce. Jednotlivé statusy jsou interpretovány takto: Status Byte Interpretace 0x80 Quality: Good, Quality Status: OK, Limits: Not Limited 0x89 Quality: Good, Quality Status: Active Advisory Alarm, Limits: Low limited 0x8A Quality: Good, Quality Status: Active Advisory Alarm, Limits: High limited 0x8D Quality: Good, Quality Status: Active Critical Alarm, Limits: Low limited 0x8E Quality: Good, Quality Status: Active Critical Alarm, Limits: High limited

50



Quality: Uncertain, Quality Status: Last Usable Value, Limits: Not Limited 0x51 Quality: Uncertain, Quality Status: Sensor Conversion not Accurate, Limits: Low limited 0x52 Quality: Uncertain, Quality Status: Sensor Conversion not Accurate, Limits: High limited 0x08, 0x09, 0x0A Quality: Bad, Quality Status: Device Failure 0x10, 0x11, 0x12 Quality: Bad, Quality Status: Sensor Failure 0x14, 0x15, 0x16 Quality: Bad, Quality Status: No Communication 0x44

4.3.7

Otestov´ an´ı aplikace

Aplikace bohuˇzel nebyla otestována na ˇzádném konkrétn´ım Modbus zaˇr´ızen´ı, k základn´ım test˚ um byla vyuˇzita shareware verze programu MOD_RSsim, která plnohodnotnˇe nahrazuje k´ yˇzen´ y hardware.

51

5 Závˇer Tato diplomová práce se zab´ yvá pr˚ umyslov´ ymi sbˇernicemi, pˇredevˇs´ım pak sbˇernic´ı Profibus a jej´ı variantou PA. Hlavn´ım c´ılem bylo s vyuˇzit´ım dostupného hardwaru vytvoˇrit aplikaci, která um´ı zachytávat pˇrenáˇsená data, vhodnˇe tato data filtrovat a zobrazovat je uˇzivateli. V prvn´ı, teoretické ˇca´sti jsou nejprve struˇcnˇe popsány modern´ı pr˚ umyslové sbˇernice s d˚ urazem na sbˇernice typu Modbus a Profibus PA, nebot’ tyto dvˇe sbˇernice jsou hlavn´ı souˇca´st´ı komunikaˇcn´ıho ˇretˇezce, jenˇz byl pro u ´ˇcely této diplomové práce sestaven. Druhá ˇca´st práce se zab´ yvá zmiˇ novan´ ym komunikaˇcn´ım ˇretˇezcem. Jako základn´ı stavebn´ı kameny ˇretˇezce byly vybrány 2 jednotky – FintT410 (implementuj´ıc´ı rozhran´ı mezi protokoly Ethernet a Profibus PA) a Fieldbus Network Link (implementuj´ıc´ı rozhran´ı mezi protokoly Profibus PA a Modbus). V této ˇcásti jsou tedy popsány obˇe jednotky, pˇredevˇs´ım pak jednotka Fieldbus Network Link, která skrz své API poskytuje pˇr´ıstup na sbˇernici Profibus PA. Dalˇs´ım krokem byla jiˇz vlastn´ı praktická ˇca´st, ˇcili vytvoˇren´ı monitoru pˇrenáˇsen´ ych dat. Nejprve vˇsak bylo nutné nauˇcit se pracovat s dostupn´ ym API, které je souˇcást´ı firmwaru jednotky Fieldbus Network Link. S vyuˇzit´ım dostupn´ ych manuál˚ u byla jako prvn´ı vytvoˇrena aplikace, která umˇela ˇc´ıst data z pamˇet’ov´ ych blok˚ u jednotky T410. Tento program, jeˇz byl následnˇe podle poˇzadavku pˇrepsán z programovac´ıho jazyka ANSI C do jazyka C#, byl zaˇrazen do projektu V´ yzkum a v´ yvoj v´ıcepaprskov´ ych ultrazvukov´ ych pr˚ utokomˇer˚ u kapalin (FR-TI1/137). V dalˇs´ı fázi v´ yvoje pak byla vytvoˇrena aplikace, která um´ı monitorovat data, která jsou pˇrenáˇsena mezi jednotkami v rámci cyklické komunikace, ˇcili dokáˇze cyklicky ˇc´ıst data z registr˚ u Modbus zaˇr´ızen´ı. Souˇcást´ı aplikace je také moˇznost konfigurace, která umoˇzn ˇuje mˇenit parametry sbˇernice s ohledem na pˇripojená zaˇr´ızen´ı. Pro pohodlnou manipulaci s programem bylo vytvoˇreno jednoduché uˇzivatelské rozhran´ı. V dalˇs´ı fázi v´ yvoje by bylo vhodné rozˇs´ıˇrit aplikaci o nové funkˇcnosti jako je napˇr´ıklad manuáln´ı nastavován´ı adresy nebo z´ıskáván´ı diagnostick´ ych dat pˇripojen´ ych zaˇr´ızen´ı. Dalˇs´ı uˇziteˇcné vylepˇsen´ı by mohlo napˇr´ıklad b´ yt ukládán´ı pˇrenáˇsen´ ych dat do databáze pro moˇznost zpˇetného vyhodnocován´ı.

52

6 Pˇrehled zkratek CIP ODVA HART CAN RTU CRC ASCII LRC PROFIBUS FNL ZVEI FMS DP PA PNO PI MBP FDL DPV FDL IEC DPM1 SRD MSAC1 MSAC2 API RAM DPR MSB PV GUI GSD HSA SB

Common Industrial Protocol Open DeviceNet Vendors Association Highway Addressable Remote Transducer Controller Area Network Remote Terminal Unit Cyclic Redundancy Check American Standard Code for Information Interchange Longitudinal Redundancy Check Process Field Bus Fieldbus Network Link Zentralverband Elektrotechnik und Elektronikindustrie Fieldbus Message Specification Decentralized Periphery Process Automation PROFIBUS User Organization PROFIBUS International Manchester Bus Powered Fieldbus Data Link Decentralized Periphery Version Fieldbus Data Link International Electrotechnical Commission DP Master Class 1 Send and Request Data with Reply Master/Slave Acyclic C1 Master/Slave Acyclic C2 Application Programming Interface Random Access Memory Dual-Port RAM Most Significant Bit Primary Variable Graphical User Interface General Station Description Highest Station Address Status Byte Tabulka 6.1: Pˇrehled zkratek

Literatura [1]

Real Time Automation [online]. 2010 [cit. 2013-05-01]. Dostupné z:

[2]

BURGET, Petr. Profibus-PA – ˇreˇsen´ı pro automatizaci proces˚ u. AUTOMA. 2001, ˇc. 1. [online] [cit. 1. 5. 2013] Dostupné z:

[3]

´ HANZALEK, Zdenˇek a Pavel BURGET. Hw.cz [online]. 2004 [cit. 2013-05-01]. Dostupné z:

[4]

PROFIBUS-PA: Part 4 Communications line]. 1999 [cit. 2013-05-01]. Dostupné

[5]

HLAVA, Jaroslav. Prostˇredky automatického ˇr´ızen´ı II: analogové a ˇc´ıslicové regulátory, elektrické pohony, pr˚ umyslové komunikaˇcn´ı ˇ systémy [online]. Vyd. 1. Praha: Ceské vysoké uˇcen´ı technické, 2000 [cit. 2013-05-01]. ISBN 978-800-1022-214.

[6]

DIEDRICH, Christian a Thomas BANGEMANN. Profibus PA: Instrumentierungstechnologie f¨ ur die Verfahrenstechnik. 2. Aufl. M¨ unchen: Oldenbourg Industrieverl, 2006. ISBN 978-383-5630-567.

[7]

LIAN, Odd. FintPROFI T410 module specification. 2009.

[8]

¨ BOHM, Pavel. Komunikaˇcn´ı modul pro pr˚ umyslovou sbˇernici Foundation Fieldbus. Plzeˇ n, 2012. Diplomová práce. Západoˇceská univerzita v Plzni, Fakulta Aplikovan´ ych vˇed, Katedra informatiky a v´ ypoˇcetn´ı techniky.

[onz:

[9]

ControlNet je plnou souˇcást´ı ODVA. AUTOMA [online]. 2008, ˇc. 8 [cit. 2013-05-05]. Dostupné z:

[10]

HART – jednoduchá a spolehlivá komunikace. AUTOMA [online]. 2004, ˇc. 7 [cit. 2013-05-05]. Dostupné z:

[11]

MAHALIK, N. Fieldbus technology: industrial network standards for real-time distributed control. New York: Springer, 2003, xxv, 590 p. ISBN 35-404-0183-0.

[12]

´ HANZALEK, Zdenˇek a Pavel BRONEC. Profibus a Foundation Fieldbus: konkurenti v oblasti pr˚ umyslov´ ych sbˇernic. AUTOMA [online]. 2000, ˇc. 2 [cit. 2013-05-05]. Dostupné z:

[13]

ˇ A, ´ Andrea. Pˇrehled protokolu MODBUS. [onRONESOV line]. 2005 [cit. 2013-04-28]. Dostupné z:

[14]

MODICON, Inc., Industrial Automation Systems. Modicon Modbus Protocol Reference Guide. 1996. Dostupné z:

[15]

TMG I-TEC GMBH. PROFIBUS FNLDPE Interface. 2003.

[16]

QT Project [online]. 2013 [cit. 2013-04-01]. Dostupné z:

A Pˇr´ılohy

A.1

Uˇ zivatelsk´ a pˇ r´ıruˇ cka

Program je dostupn´ y na pˇriloˇzeném CD, k dispozici je jak zkompilovaná aplikace, tak zdrojové soubory. Pro start aplikace staˇc´ı spustit soubor monitor.exe, kter´ y se nacház´ı ve sloˇzce /Program/Bin/ Uˇzivatel má také moˇznost vlastn´ıho sestaven´ı programu. Souˇca´st´ı pˇriloˇzeného CD (ve sloˇzce /Program/Src/) je kompletn´ı projekt vytvoˇren´ y ve v´ yvojovém prostˇred´ı NetBeans verze 7.1.2.

A.1.1

Spuˇ stˇ en´ı programu a naˇ cten´ı GSD souboru

Po spuˇstˇen´ı programu je uˇzivateli zobrazeno u ´vodn´ı okno aplikace Monitor, viz obrázek A.1.

Obrázek A.1: Monitor - u ´vodn´ı okno

Z obrázku A.1 je patrné, ˇze uˇzivatel nemá prozat´ım pˇr´ıstupné témˇeˇr ˇza´dné funkce, k dispozici je pouze ˇcten´ı GSD souboru. Po stisknut´ı tlaˇc´ıtka Open je uˇzivateli zobrazeno okno pro v´ ybˇer souboru (soubory jsou filtrovány podle pˇr´ıpony .GSD nebo .gsd), viz obrázek A.2

Obrázek A.2: Monitor - naˇcten´ı souboru Po nalezen´ı souboru a potvrzen´ı okna pro v´ ybˇer mohou nastat 2 moˇznosti: 1. Soubor nen´ı validn´ı GSD soubor, uˇzivateli je zobrazena hláˇska viz obr. A.3 a), 2. Soubor je validn´ı GSD soubor, uˇzivateli je zobrazena hláˇska viz obr. A.3 b)

(a) Nevalidn´ı GSD soubor

(b) Validn´ı GSD soubor

Obrázek A.3: Monitor - validace GSD souboru

A.1.2

Pˇ ripojen´ı k jednotce a naˇ cten´ı adresy

Po naˇcten´ı validn´ıho GSD souboru je uˇzivateli zpˇr´ıstupnˇeno tlaˇc´ıtko Connect pro pˇripojen´ı k jednotce FNL (viz obr. A.4)

Obrázek A.4: Monitor - pˇripojen´ı Po stisknut´ı tlaˇc´ıtka Connect mohou nastat 2 situace: 1. Doˇslo k u ´spˇeˇsnému pˇripojen´ı k jednotce, uˇzivateli je zobrazena hláˇska viz obr. A.5 a), 2. Jednotka nen´ı pˇripojena k poˇc´ıtaˇci (ˇci má odpojené napájen´ı), uˇzivateli je zobrazena hláˇska viz obr. A.5 b) Aplikace se nijak nezmˇen´ı, uˇzivatel má moˇznost pokus o pˇripojen´ı znovu opakovat.

(a) Korektn´ı pˇripojen´ı

(b) Problém s pˇripojen´ım

Obrázek A.5: Monitor - hláˇsky po pokusu o pˇripojen´ı Po u ´spˇeˇsném pˇripojen´ı jsou uˇzivateli zpˇr´ıstupnˇeny dalˇs´ı funkce (viz obr. A.6).

Obrázek A.6: Monitor - stav po u ´spˇeˇsném pˇripojen´ı Po pˇripojen´ı je samozˇrejmˇe k dispozici moˇznost odpojen´ı, k ˇcemuˇz slouˇz´ı tlaˇc´ıtko Disconnect. Po jeho stisknut´ı jsou opˇet deaktivována vˇsechna pole, která byla aktivována po u ´spˇeˇsném pˇripojen´ı. Dalˇs´ı funkc´ı je urˇcen´ı adresy pˇripojeného Profibus PA zaˇr´ızen´ı. Uˇzivatel má 3 moˇznosti, jak s tou funkc´ı naloˇzit: 1. Uˇzivatel zná adresu zaˇr´ızen´ı, m˚ uˇze ji tedy ruˇcnˇe zadat do pˇripraveného pole (defaultn´ı moˇznost), 2. Uˇzivatel nezná adresu zaˇr´ızen´ı, po stisknut´ı tlaˇc´ıtka Get Address List je zavolána funkce, která nalezne vˇsechna pˇripojená zaˇr´ızen´ı a jejich adresy pˇridá do rozbalovac´ıho seznamu. Nutno podotknout, ˇze volán´ı funkce nˇejakou dobu trvá (maximálnˇe 1 minutu),

3. Adresa zaˇr´ızen´ı se shoduje s tou pˇrednastavenou (1), uˇzivatel m˚ uˇze nastavován´ı adresy ignorovat a pokraˇcovat postupem ze sekce A.1.3, eventuálnˇe ze sekce A.1.4.

A.1.3

Nastavov´ an´ı parametr˚ u

Uˇzivatel má moˇznost nastavit nˇekolik parametr˚ u, které jsou d˚ uleˇzité pro korektn´ı chován´ı pˇri cyklické komunikaci, jedná se o tyto parametry: • Poˇcet stop bit˚ u (Number of Stop Bits) - defaultn´ı hodnota: 1, • Baudrate (Baudrate) - defaultn´ı hodnota: 9600, • Poˇrad´ı byt˚ u v CRC souˇctu (CRC Order) - defaultn´ı hodnota: 0, • Parita (Parity) - defaultn´ı hodnota: 2, • Adresa Modbus zaˇr´ızen´ı (Address) - defaultn´ı hodnota: 3, • Datov´ y typ primárn´ı promˇenné (PV Type) - defaultn´ı hodnota: 7, • Adresa Modbus registru (Register Address) - defaultn´ı hodnota: 0. Jedná se o nepovinnou moˇznost, pokud uˇzivatel nechce nastavovat parametry, m˚ uˇze pokraˇcovat postupem, jenˇz je popsán v sekci A.1.4. Pokud se tak stane, jsou pro parametrizaci pouˇzity defaultn´ı hodnoty. Pokud uˇzivatel chce nˇejak´ ym zp˚ usobem zmˇenit paremetry, mus´ı stisknout tlaˇc´ıtko Read Parameters. Po jeho stisknut´ı jsou aktivována jednotlivá pole pro zmˇenu konkrétn´ıch parametr˚ u (viz obr. A.7). Kaˇzd´ y konkrétn´ı parametr se aktualizuje aˇz po stisknut´ı tlaˇc´ıtka Set. V pˇr´ıpadˇe, ˇze uˇzivatel nezadá validn´ı hodnotu, je zobrazen hláˇska viz obr. A.8.

Obrázek A.7: Monitor - nastavován´ı parametr˚ u

Obrázek A.8: Monitor - nevalidn´ı hodnota parametru

A.1.4

Cyklick´ a komunikace

Obrázek A.9: Monitor - okno cyklické komunikace

Po stisknut´ı tlaˇc´ıtka Start Cyclic Communication je p˚ uvodn´ı okno deaktivováno a zároveˇ n je zobrazeno okno nové, viz. obr. A.9. Data jsou zaznamenávána do tabulky, kde v prvn´ım sloupci jsou konkrétn´ı data, v druhém sloupci pak Status Byte spolu s jeho interpretac´ı. V pravé ˇcásti je moˇzné nastavovat hodnoty alarm˚ u a to stejn´ ym zp˚ usobem, jako se nastavovali parametry v sekci A.1.3. V pˇr´ıpadˇe, ˇze byly správnˇe nastaveny parametry a zároveˇ n je na konci ˇretˇezce pˇripojeno Modbus zaˇr´ızen´ı, zaˇcnou se cyklicky pˇrenáˇset data (do tabulky je zaznamenána kaˇzdá zmˇena). Obrázek A.10 znázorˇ nuje nˇekolik cyklicky pˇrenesen´ ych hodnot.

Obrázek A.10: Monitor - pˇrenesená data Po stisknut´ı tlaˇc´ıtka Disconnect je aplikace ukonˇcena.

A.2

GSD soubor

#Profibus_DP GSD_Revision = 3 Vendor_Name = "Fieldbus International AS" Model_Name = "T410" Revision = "1.0" Ident_Number = 0xa002 Protocol_Ident = 0 Station_Type = 0 FMS_supp = 0 Hardware_Release = "T410 1.01" Software_Release = "T410 1.01.00" Bitmap_Device = "T410" 31.25_supp = 1 45.45_supp = 1 93.75_supp = 1 MaxTsdr_31.25 = 100 MaxTsdr_45.45 = 250 MaxTsdr_93.75 = 1000 Redundancy = 0 Repeater_Ctrl_Sig = 0 24V_Pins = 0 Freeze_Mode_supp = 0 Sync_Mode_supp = 0 Set_Slave_Add_supp = 1 Min_Slave_Intervall = 250 Modular_Station = 1 Max_Module = 4 Max_Input_Len = 20 ; maximum Input Length Max_Output_Len = 0 ; maximum Output Length Max_Data_Len = 20 ; maximum In-Output Length Slave_Family = 12 Max_Diag_Data_Len = 14 Max_User_Prm_Data_Len = 3 Ext_User_Prm_Data_Const(0) = 0x00, 0x00, 0x00 ;------- Description of extended DP features: -------------; DPV1_Slave = 1 C2_Read_Write_supp = 1 C2_Max_Data_Len = 128

C2_Read_Write_required = 1 C2_Max_Count_Channels = 1 Max_Initiate_PDU_Length = 52 C2_Response_Timeout = 4000 DPV1_Data_Types = 1 ;-- Description of physical interface for async. and sync. transmission: -Physical_Interface = 0 ; RS-485 Standard Copper Transmission_Delay_45.45 = 0 Reaction_Delay_45.45 = 0 Transmission_Delay_93.75 = 0 Reaction_Delay_93.75 = 0 End_Physical_Interface ; Physical_Interface = 1 ; IEC61158-2 Transmission_Delay_31.25 = 0 Reaction_Delay_31.25 = 0 End_Physical_Interface ;------- Description of device related diagnosis: -------------; Unit_Diag_Bit(16) = "Error appears" Unit_Diag_Bit(17) = "Error disappears"

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. Monitor sběrnice Profibus s HW podporou - SW část

Recommend Documents