Systémové rámce VXI a knihovna VISA

Systé mové rámce VXI a knihovna VISA - další krok
ve standardizaci mě řicích systé mů
Ing. Igor Luhan, CSc.
IPP measure, Praha
Anotace
Tak, jak se vyvíjí počítačovátechnologie, stávají se automatizované měřicí systé my
stále složitějš ími a komplexnějš ími. Přijaté průmyslové standardy, např. GP-IB a VXI,
umožňují kombinovat do jednoho integrované ho systé mu přístroje a počítače řady výrobců.
Dalš ím postupným úkolem bylo standardizovat programové komponenty měřicích systé mů
tak, aby jejich integrace do jednoho systé mu byla stejně snadná.
Standard VXIplug&play, jako řeš ení tohoto úkolu, normalizuje způsob integrace
programových komponent jednoho měřicího systé mu. Systé mový rámec WIN, jakožto součást
standardu, definuje nutnou a postačující množinu komponent a rozhraní, které umožní, aby
programy vytvořené různými výrobci mohly být integrovány do jediné ho systé mu. Navíc
definuje minimální požadovanou úroveň funkcionality jednotlivých částí, takže konečný
uživatel obdrží vš echny nástroje potřebné pro sestavení funkčního systé mu.
Jednou z nejdůležitějš ích částí standardu VXIplug&play je knihovna VISA, zajiš ťující
transparentní přenos dat mezi programy a fyzickými měřicími moduly. V příspěvku je
naznačena vnitřní architektura knihovny a její použítí ilustrují vybrané programové
segmenty.
Ú vod
Automatizované měřicí systé my sestá vají z měřicích přístrojů různý ch typů, z počítačů
a z programů. Jsou vytvá řeny tak, aby umožňovaly prová dět měření, která jsou standardním
přístroji nerealizovatelná . Přístrojová technika poskytuje nezbytný fyzický interfejs na měřené
zařízení. Počítač a programy zajišťují systé movou koordinaci, zpracová ní a zobrazení
naměřený ch dat. Měřicí systé my jsou zpravidla sestavová ny z komponent řady vý robců.
Pro usnadnění integrace přístrojů do jednoho systé mu bylo vypracová no několik
standardů. Standard GP-IB (IEEE488, IMS-2 atd.) definuje interfejs, který využívá společnou
komunikační strukturu; komunikace probíhá na propojovacích zřetězitelný ch kabelech. VXI jde
dá le a definuje komunikační strukturu i mechanické uspořádá ní, takže jednotlivé moduly jsou
umístěny v jednom rá mu. Využití přístrojů, vyhovujících některé z těchto norem, vý razně
redukuje úsilí nutné pro sestavení, naprogramová ní a využití systé mu.
Systé my GPIB a VXI vý razně zjednodušují integraci přístrojů do systé mu. Avšak
neexistují-li programové standardy, integrace programů a počítačový ch komponent je i nadá le
problematickou a systé mový integrá tor má k vý běru pouze omezenou množinu programový ch
komponent, schopný ch vzá jemné spoluprá ce.
Standard VXIplug&play řeší problé m integrace programové čá sti systé mů GPIB a VXI.
Na systé mové úrovni definuje především programová rozhraní, vý sledkem čehož je podpora
ná vrhu, integrace a odladění systé mu jako celku.
Standard VXIplug&play je organizová n do sé rie dokumentů, označovaný ch VPP-n.
Každý z dokumentů řeší jiný komponent systé mu či aspekt jeho integrace. Dokumentů je celkem
10, přičemž první z nich, VPP-1, slouží jako zá kladní charta aliance VXIplug&play. Každý z
dokumentů může sestá vat z několika revizí a může bý t doplněn té ž doplňkový mi dokumenty.
Systémové rámce
Systé mové rá mce VXIplug&play kompletně definují prostředí pro vý voj a běh
programový ch modulů. Programový modul vytvořený pro určitý rá mec bude pracovat korektně
na libovolné m počítači, vyhovuje-li tento počítač zvolené mu rá mci. Vyvine-li vý robce měřicího
přístroje či programá tor programový modul pro zvolený systé mový rá mec, má jistotu jeho
přenositelnosti na libovolný systé m podporující tento rá mec.
Specifikací VPP-2 je definová no několik systé mový ch rá mců, takže obsá hnou řadu
populá rních, i když vzá jemně nekompatibilních, prostředí. Každý ze systé mový ch rá mců je
identifiková n jmé nem. V současné době jsou definová ny rá mce DOS, WIN a GWIN. Současně
se pracuje na definici dalších systé mový ch rá mců, jako jsou rá mce podporující prostředí UNIX
na SUN či HP-UX, nebo rá mce podporující 32-bitové verze operačního systé mu Windows a
Windows NT.
Definice každé ho z rá mců je doplněna číslem poslední revize. Rá mec WIN má číslo
poslední revize 3.0. Každá nová revize dokumentu zachová vá zpětnou kompatibilitu
s předchozími revizemi. Proto např. program vytvořený pro rá mec WIN 2.0 je kompatibilní
s kontrolé rem, který podporuje rá mec WIN 3.0. Revizní číslo rá mce kontrolé ru musí bý t větší
nebo rovno nejvyššímu reviznímu číslu všech instalovaný ch modulů.
Ná vrhá řsysté mu si nejprve vybere jeden ze systé mový ch rá mců a na něm založí další
ná vrh. Vý běr se prová dí podle požadované ho typu počítače a operačního systé mu (především
UNIX versus PC), dostupnosti př
ístrojů a komponent podporovaný ch zvolený m rá mcem
a v neposlední řadě i podle zvolené ho prostředí pro vý voj měřicích programů. Teprve po vý běru
systé mové ho rá mce lze vybírat komponenty systé mu, a to podle požadavků konkré tní úlohy
a musí se pouze dbá t, aby komponenty podporovaly zvolený rá mec.
Je samozřejmé , že je možno použít i moduly VXI, které kompatibilitu s některý m z rá mců
VXIplug&play nedeklarují. Takové moduly však nejsou vybaveny standardním ovladačem
a musí bý t ovlá dá ny přímo, využívajíc knihovnu VISA a vlastní sestavu příkazů přístroje. To, že
v tomto případě není k dispozici standardní programová podpora, vede k větší pracnost při
integraci a údržbě systé mu. I když, jak bude v dalším textu ilustrová no, ná růst není kritický .
Ačkoliv již nyní jsou definová ny tři systé mové rá mce (a v budoucnu jistě přibudou další),
v centru pozornosti hlavních vý robců (jako jsou Tektronix, Hewlett Packard či National
Instruments) je rá mec WIN. Tento rá mec je založen na dostupné a populá rní architektuře IBM
PC a operačním systé mu Microsoft Windows 3.1. Podporuje celou řadu programovacích
prostř
edí.
Systémový rámec WIN
Tento systé mový rá mec představuje vý hodný vý chozí bod pro případnou migraci k dalším,
ná ročnějším a ná kladnějším rá mcům, např. WIN32 nebo Unix. Rá mec definuje zá kladní
požadavky na počítač : minimá lně počítač 486/33MHz, disk 120 MB, disketu 31/2", rozlišení
monitoru VGA a minimá lní velikost paměti 8 MB. Vyžaduje se přítomnost klá vesnice i myši.
Leccos jde nad požadavky, dané samotný m operačním systé mem MS-Windows, protože počítač
musí bý t adekvá tně vybaven pro využití vý vojový ch prostředí a aplikací používajících grafické
rozhraní.
Sá m operační systé m Windows 3.1 poskytuje řadu funkcí, které jsou využívá ny pro
tvorbu spolupracujících programů. Důležitý je standardizovaný přístup programů k myši,
klá vesnici, displeji a tiská rně. Nejvyužívanějším a nejdůležitějším mechanismem poskytovaný m
operačním systé mem je dynamické propojová ní podprogramů s programy při běhu, označované
DLL. Pracuje tím způsobem, že operační systé m zjišťuje, zda program vyžaduje přístup k určité
knihovně podprogramů. Pokud ano, zjistí, zda je již v paměti a pokud ne, automaticky ji do
paměti načte. Systé m si udržuje přehled o běhu programů vyžadujících přístup ke knihovně
a v okamžiku, kdy poslední z nich ukončí činnost, knihovnu uvolní z paměti. Z popisu vyplý vá ,
že jednu knihovnu lze sdílet několika programy stejně jako že vý měnou knihovny lze změnit
vlastnosti programů, které ji využívají, aniž by bylo je potřeba jakkoliv měnit. Navíc lze
používat měřicí programy s knihovnami podprogramů či funkcí různý ch vý robců.
Například programově tvořené čelní panely přístrojů, vytvá řené na obrazovce počítače,
využívají knihovnu VISA pro komunikaci s měřicím přístrojem. Knihovnu VISA dodá vá
vý robce počítače v rá mci programů VXIplug&play. Vý voj čelního panelu naopak zajišťuje
vý robce měřicího modulu. Ten pochopitelně neví, jaký počítač a jaké rozhraní budou
v konkré tní aplikaci použity. Potažmo tedy neví, jakou knihovnu VISA bude používat. Po startu
programu "čelní panel přístroje" si tento program prostřednictvím služeb operačního systé mu
vyžá dá přístup ke knihovně VISA (tj. k té , která je prá vě dostupná v paměti nebo na disku, tedy
k té , která reprezentuje rozhraní použité v té které konkré tní aplikaci). Jakmile se program s
knihovnou propojí, využívá jejích služeb pro přístup k měřicímu modulu. Popsaný postup
spojová ní za běhu programu umožňuje přenositelnost virtuá lních čelních panelů VXIplug&play
na všechny kontrolé ry podporující rá mec WIN.
S každý m měřicím přístrojem, vyhovujícím rá mci WIN, je dodá no několik programový ch
komponent, a to na disketě 31/2". Na té to disketě nalezneme především instalační program
SETUP.EXE. Programy různý ch vý robců mají jednotný vyhled a instalují komponenty do
standardní adresá řové struktury na disk počítače.
Nejdůležitější komponentou na disketě je program pro rozhraní na měřicí modul (API). Je
realizová n ve dvou formá ch, jednak v rá mci knihovny VISA a jednak jako programový ovladač.
Aplikační programy tedy mohou komunikovat s fyzický mi měřicími přístroji prostřednictvím
knihovny VISA, nebo přes přístrojový ovladač (ten však pé či o vlastní komunikaci stejně
přenechá vá knihovně VISA). Možné způsoby komunikace zná zorňuje obrá zek. Přístrojový
ovladač je povinně dodá vá n ve dvou formá tech : jako dynamicky linkovatelná knihovna DLL
i ve zdrojové m tvaru v jazyce C. Jak bylo uvedeno, formá t DLL je standardem. Zdrojový tvar je
vý hodný pro úpravy uživatelem, případně pro přenos ovladače do nestandardního prostředí.
Standard VXIplug&play požaduje, aby programový ovladač vytvořil a dodá val vý robce
měřicího modulu. Ovladač poskytuje jednak řadu standardních funkcí, jaký mi jsou např. open
či close, jednak i řadu funkcí specifický ch pro měřicí techniku, např. autotest nebo zpracová ní
chybový ch zprá v.
Dalším komponentem je virtuá lní čelní panel přístroje. S ním se uživatel setká
pravděpodobně nejdřív. Jedná se o kompletní aplikační program včetně grafické ho rozhraní,
který se spouští v prostředí MS-Windows. Program nahrazuje čelní panel klasické ho měřicího
přístroje jeho zobrazením na monitoru počítače.
Včetně zobrazovačů, ovlá dacích tlačítek,
přepínačů a nastavovacích prvků. Umožňuje
aplikace
aplikace
interaktivní ovlá dá ní modulů VXI (které samy
o sobě žá dný panel nemají) aniž by bylo třeba
studovat syntaxi příkazů modulu a vytvá řet
program. Virtuá lní čelní panel se používá pro
ovladač
sezná mení s vlastnostmi modulu a jeho
vyzkoušení. Neocenitelný je té ž pro ověření
VISA
sprá vné instalace a funkčnosti modulu. Většina
modulů VXI je vybavena autotestem, který lze
interaktivně prové st z virtuá lního čelního panelu.
Komunikač ní knihovna VISA
přístroj
Jak je z předchozího textu zřejmé , jednou z
nejdůležitějších specifikací VXIplug&play je
VPP-4.1, definující knihovnu zajišťující
transparentní komunikaci mezi aplikačním
programem (případně přístrojový m ovladačem) a fyzický mi moduly. Knihovna je nazý vá na
VISA (Virtual Instrument Software Architecture) a její vý voj a dodá vku zajišťuje vý robce
komunikačního prostředku (počítače do rá mu VXI, ovlá dací desky GP-IB, atd.).
VISA představuje vstupně / vý stupní funkce vytvá řené nejmodernějším způsobem, které se
nepochybně stanou standardem nejen v oblasti systé mů VXI, ale i ve spojení s dalšími
propojovacími soustavami, hlavně GP-IB a RS232.
Vzhledem k důležitosti definice knihovny VISA se jí budeme v ná sledujícím textu věnovat
podrobně. Na jednoduchý ch programový ch segmentech si uká žeme způsob jejího použití i to, že
používá ní vychá zí z běžný ch a používaný ch konceptů. Vnitřní architektura knihovny je však
založena na nejmodernějším objektově orientované m modelu, což jí dá vá , ve srovná ní s dosud
používaný m ovlá dacím software, možnost větší konfigurovatelnosti, rozšiřitelnosti a užitečnosti.
Ačkoliv nynější verze specifikace VISA definuje knihovnu pro ovlá dá ní vstupních a vý stupních
operací, VISA je plně rozšiřitelná daleko za tyto hranice. Vzhledem k velké flexibilitě vložené
do vnitřní architektury knihovny představuje knihovna VISA, ve smyslu funkčnosti a
použitelnosti, sjednocení všech dosud používaný ch programový ch knihoven pro ovlá dá ní
vstupně / vý stupních operací. I přes to má ale programové rozhraní, ve srovná ní s obdobnou
knihovnou o srovnatelné funkcionalitě, nízký počet operací (operace je termín používaný
specifikací VISA, vícemé ně je ekvivalentní volá ní funkce). Knihovna VISA je proto lehce
použitelná pro začá tečníky a pro běžné jednoduché úlohy. Avšak VISA knihovna je navíc
značně konfigurovatelná , což využije zkušený programá tor, který chce plně využít všechny její
možnosti. A je třeba konstatovat, že nové a leckdy uniká tní vlastnosti rozšiřují rozsah použití
knihovny za hranice, které vytyčily ovlá dací programy předchozích generací.
Zmiňme se o tom, co ná vrhu VISA předchá zelo. Jak bylo uvedeno, ovlá dací software
zajišťuje přenos příkazů a dat mezi počítačem a měřicím přístrojem (přes GP-IB, RS232, VXI
atd.). Tak, jak se v minulosti rozšiřovalo využití měřicí techniky řízené počítačem, objevovala se
i řada implementací podprogramů a knihoven podprogramů, které by tyto činnosti zajišťovaly.
Některé z nich si vyvinuli sami uživatelé , zatímco ostatní připravili vý robci hardware a
prodá vali je s ním. Některé implementace jsou vhodné pro širokou šká lu běžný ch úloh, některé
jsou naopak určeny pro použití s omezený m počtem typů přístrojů ve specifický ch aplikacích.
Různé implementace ovlá dacích podprogramů mají vý razně odlišné vlastnosti i aplikační
rozhraní. Je to proto, že každou z nich navrhoval někdo, kdo svý m produktem oslovoval určitou
skupinu uživatelů. Někteříná vrhá ři se např. soustředili na běžné uživatele, požadující ovlá dá ní
na co nevyšší úrovni pomocí jednoduchý ch ná strojů. Na druhé straně někteříse soustředili na
kompletní funkcionalitu a flexibilitu při ovlá dá ní na nižší úrovni a na kó d vyladěný na co
nejvyšší vý kon, tedy na uživatele s dostatečný mi zkušenostmi. Ani jeden z těchto přístupů
samozřejmě není špatný - pouze každý z nich zdůrazňuje jiné priority.
Všeobecně se ví, že ná klady na programy a programová ní představují vý znamný díl
z ná kladů na vý voj, použití a údržbu automatické ho měřicího systé mu. Modularita navržené ho
programu je nutností, další úspory mohou přiné st přístrojové ovladače a především grafická
vý vojová prostředí. Důležitá je přenositelnost programů, proto mnoho uživatelů dnes vyžaduje
programy hardverově nezá vislé . Zastavme se na chvíli u posleního požadavku.
Automatický měřicí systé m sestá vá typicky z počítače, nějaké ho stykové ho obvodu
a měřicích přístrojů. Každá z položek má svůj vliv na vytvá ření hardverově nezá vislý ch
programů. Zatímco nezá vislost na typu měřicího přístroje čá stečně řeší dnes již běžný standard
SCPI, knihovna VISA napomá há vytvá řet programy nezá vislé na operačním systé mu počítače
a na použité m interfejsu.
Nezá vislost na použíté m interfejsu, či chcete-li na použité m komunikačním prostředku, je
podle mé ho ná zoru vůbec nejdůležitější ze všech. Například vytvoří-li uživatel aplikační
program, který bude spolupracovat s určitou sestavou přístrojů, pak jistě uvítá , bude-li mít
možnost pracovat s několika typy interfejsový ch desek, pokud možno od různý ch vý robců.
Většina dosavadních ovlá dacích knihoven byla v tomto smyslu transparentní již dosud, ale
pouze v rá mci řady vý robků konkré tního vý robce (některé řady jsou však značně široké , takže
pokrý vají většinu požadavků; některé jsou dokonce rozšířeny do několika počítačový ch
standardů; navíc někteřívý robci interfejsový ch desek navrhli jejich ovlá dá ní tak, aby kopírovalo
ovlá dá ní jiný ch, v té době populá rních typů - především to pomohlo vytvořit de facto standardy,
které v té to oblasti existují). Nicmé ně uživatelům, který m tyto standardy nevyhovují, nezbý vá
nic jiné ho než čá st ovlá dací knihovny vytvořit znovu. S rozvojem technologie VXI se však
objevuje důraz na jiný aspekt nezá vislosti na hardverové m rozhraní. Je vyžadová n transparentní
přístup programů k měřicí technice, ať je počítač součá sti šasi VXI, je propojen sběrnicí MXI či
prostřednictvím GP-IB. Jako jiný příklad může sloužit přístroj, který lze připojit po sé riové lince
RS232 i přes GP-IB. V neposlední řadě je na trhu několik př
ístrojový ch ekvivalentů dodá vaný ch
jak v provedení klasické ho přístroje (propojení přes GP-IB), tak i ve tvaru modulu VXI
- i v tomto případě je možnost ná hrady přístroje jeho ekvivalentem v jiné m provedení vysoce
žá doucí, protože umožní "bezbolestný " přechod existujících systé mů od morá lně již zastará vající
propojovací soustavy GP-IB na systé my VXI. Všechny uvedené požadavky na přenositelnost
byly respektová ny při ná vrhu VISA.
Stá le populá rnější se stá vají distribuované měřicí systé my. Nehraje při tom roli, zda se
jedná o samostatné přístroje s vestavěnou podporou sítě, nebo o několik procesorů v rá mu VXI.
Vždy je pro komunikaci používá n některý ze standardů (Ethernet, sběrnice VXI). Moderní
objektově orientovaná podstata knihovny VISA poskytuje přímé mechanismy pro distribuci
programový ch modulů, např. modulů pro vstupně vý stupní operace, po síti libovolné ho typu.
Volá ní knihovních funkcí je zcela stejné , ať jsou programové moduly kdekoliv. Tato vlastnost
umožňuje snadnou migraci od dnešních, většinou nedistribuovaný ch, systé mů využívajících
VISA technologii k budoucím plně distribuovaný m.
Metodologie návrhu knihovny
Nejpřirozenější způsob, jak postupovat při vytvá ření podobné knihovny, spočívá ve
vytvoření interfejsu sestá vajícího ze dvou čá stí. První čá st interfejsu (nazý vaná já dro) je
společná pro všechna hardverová rozhraní. V té to čá sti jsou shrnuty funkce, které jsou společné
(nebo podobné ) pro několik hardverový ch rozhraní. Např. čtení nebo zá pis z/do přístrojů GPIB
používají stejné funkce jako čtení a zá pis sběrnicí RS232. Druhá čá st interfejsu pak obsahuje
podprogramy specifické pro určitý typ hardverové ho rozhraní. Popsaná metoda ná vrhu je
nazý vána interfejsovou nezávislostí.
Nevý hody aplikačních rozhraní založený ch na interfejsové nezá vislosti jsou mnohé . Má -li
bý t vytvořený aplikační program skutečně nezá vislý , může používat pouze jednoduché řídicí
algoritmy založené na zprá vá ch (např. dle normy IEEE488.2). To samozřejmě snižuje
použitelnost i efektivnost programu. Pouze jediný přerušovací mechanismus, spočívající
v použití zprá vy Service Request (definované v IEEE488.2), je společný několika hardverový m
rozhraním. Nezá vislost tohoto typu má skutečný smysl pouze tehdy, přená šíme-li program z
jednoho hardverové ho rozhraní na jiné při zachová ní přesně stejné ho typu implementace, tzn.
shodné ho způsobu generová ní přerušení, trigrová ní, atd. Navíc tento typ nezá vislosti má
i omezené možnosti rozšiřová ní, protože má smysl jej rozšiřovat pouze o takový typ
hardverové ho rozhraní, které je konzistentní s již zahrnutý mi rozhraními a umožní realizovat
všechny funkce já dra interfejsu.
Tvůrci normy VISA proto definovali novou metodologii tvorby aplikačních interfejsů na
ovladače (API) a nazvali ji nezávislost přístrojových zdrojů - device resource independence.
Zdrojem je nazý vá na zá kladní a nedělitelná vlastnost měřicího přístroje ovladatelná
prostřednictvím hardverové ho rozhraní. Např. přístroj může obsahovat paměťové úseky
přístupné sběrnicí GPIB, do nichž lze zapisovat, které lze číst, které mohou obsahovat stavové
informace atd. Nebo VXI modul obsahuje paměťově mapované porty, pomocí nichž lze řídit
spouštění převodů, vyvolá vat přerušení či komunikovat prostřednictvím znakový ch povelů.
Spouštění, přerušení či čtení stavové informace představují příklady jednotlivý ch zdrojů. Každý
zdroj může mít sadu charakteristik, nazý vaný ch atributy. Např. GPIB port, určený pro zá pis,
může mít atribut EndOfTransferMode (vyslá ní zprá vy EOI souběžně s posledním bajtem dat).
Lze najít určitou analogii s objekty používaný mi v programová ní. Zdroj je obdobou
objektu, metodá m odpovídají již dříve zmíněné operace.
Proces vytvá ření aplikačního interfejsu API sestá vá ze tříčá stí. V první čá sti je vytvořen
zdroj, určený pro ovlá dá ní ostatních zdrojů v API. Musí bý t schopen vytvá řet konkré tní instalace
zdrojů, tedy je vytvá řet podle obrazu, konfigurovat, nastavit atributy. Dá le je musí umět zrušit,
měl by umět lokalizovat přístroje v systé mu, třídit a zpracová vat přerušení a řídit paralelní běh
procesů. Tento zdroj se ve VISA nazý vá Resource Manager.
Ve druhé etapě jsou realizová ny vlastní zdroje, tvořené všemi vlastnostmi různý ch typů
měřicích přístrojů, přičemž jsou spojová ny obdobné vlastnosti různý ch hardverový ch rozhraní
(např. různé typy předá vá ní zprá v, různé typy mapová ní či různé typy spouštění odměrů). Ve
VISA jsou definová ny ná sledující zdroje :
zá pis (obsahuje operace zá pisu, asynchronního zá pisu a zá pisu stavové ho slova)
ètení (obsahuje operace ètení, asynchronního ètení a ètení stavové ho slova)
formá tovaný vstup/vý stup (obsahuje operace nastavení bufferu, formá tovaný zá pis v nìkolika
variantá ch, formá tované ètení v øadìvariant i dvojici formá tované ho zá pisu a ètení)
spouštìní (spouštìcí signá l, namapová ní a odmapová ní spouštìcích signá lù)
vyžá dá ní obsluhy (ètení stavu, vyžá dá ní obsluhy)
inicializace (clear)
pøístup k registrùm na vyšší úrovni (po 8, 16, 32 i 64 bitový ch slovech) a obdobný pøístup
na nižší úrovni
zdroj pro specifické funkce zá vislé na hardverové m rozhraní (napø. pøedá ní øízení v GPIB,
pøepíná ní dá lkový / místní režim v GPIB, operace pro èinnost slotu 0 ve VXI, asynchronní
ètení a zá pis na RS232, atd.)
Zá věrečná etapa spočívá ve vytvoř
ení zdroje, který je určen pro komunikaci s aplikačním
programem na nejvyšší úrovni. Tento zdroj skrý vá veškeré detaily a poskytuje co nejjednodušší
pohled na ovlá dá ní přístroje. Ve VISA je tento objekt nazý vá n Instrument Control Organizer
Resource.
Bliž ší pohled na způsob použ ití knihovních funkcí
Pro pochopení použití knihovny VISA si prohlé dněme jednoduchý příklad, v němž jsou
zahrnuty zá kladní instrukce pro ovlá dá ní měřicího přístroje. V první řadě uvedeme běžný
příklad ovlá dá ní měřicího přístroje typu message-based, tzn. přístroje ovlá dané ho příkazy ve
formě textový ch řetězců a nikoli pomocí manipulace v registrech přístroje.
První čá st je vždy deklarační. Povšimněme si, že všechny datové typy jsou definová ny
v rá mci VISA. To má značný vý znam, neboť odkazy na všechny proměnné jsou reprezentová ny
konzistentně. Především ale definice zá kladních datový ch typů (např. 32-bitové číslo jako
ViUInt32) dá vá možnost přenosu programu na jinou počítačovou platformu.
va r
rdResponse : ViCha r;
sta tus : viSta tus;
retCo unt : ViUInt32;
vi : ViSession;
procedure Messa ge_Ba sed _Com m unica tion;
const
a ddre sString : ViRsrc = ': : na tinst.co m : : VICO{GPIB1: : 5 }';
com m a ndString : ViBuf = '*IDN?';
Pro inicializaci přístupu ke všem typům přístrojů vystačí knihovna VISA s jedinou funkcí.
Jedná se o funkci viOpen. Jako jeden z parametrů se používá řetězec znaků (v příkladu nazvaný
addresString), vytvá řený podle pravidel daný ch té ž normou VISA. Pravidla umožňují otevírá ní
přístupu k zařízením, interfejsům nebo dokonce jen k interfejsový m funkcím. Čá st znakové ho
řetězce "GPIB1::5" označuje, že měřicí modul je přístupný přes sběrnici GP-IB. Zaměníme-li
přístroj modulem VXI, je v celé m uvedené m příkladu třeba změnit jedinou čá st, a to uvedený
řetězec znaků např. na tvar "VXI1::20".
begin
sta tus : = viOpen( viD ef a ultRM, a ddresString, 0, 0, @vi );
Další čá st představuje dvojici funkcí pro zá pis příkazu přístroji a pro přečtení odpovědi:
sta tus : = viW rite( vi, com m a ndString,
Length( com m a ndString^ ), @retCount );
{ ... . }
GetMe m ( rdResponse, R ESPONSE_LENGT H ) ;
sta tus : = viRea d( vi, rdResponse, RES PONSE_LENGT H,
@retCo unt );
Zbý vá uzavírací čá st, v níž se používá jediná funkce, nezá visle na použité m rozhraní.
sta tus : = viClose( vi );
FreeMem ( rdResponse, RESPONSE_LENGT H );
end;
Co se stane, je-li ovlá daný m modulem VXI modul register-based? To znamená modul,
který není ovlá dá n pomocí příkazů, ný brž do jehož registrů je třeba zapisovat hodnoty a odečítat
z nich odezvy? Ná sledující příklad ukazuje, že ovlá dá ní zůstá vá konzistentní a prakticky se
nezměnilo :
procedure Register_Ba se d_Com m unica tion;
va r
ptr : ViBuf ;
va lue : ViUInt32;
const
a ddre sString : ViRsrc = ': : na tinst.co m : : VICO{VXI1: : 12 8}';
com m a ndString : ViBuf = '*IDN?';
begin
sta tus : = viOpen( viD ef a ultRM, a ddresString, 0, 0, @vi );
sta tus : = viMa p( vi, ADDR_SPACE, ADDR _BASE,
Předchozí řádek slouží k namapová ní ukazatele na registry modulu do proměnné ptr.
Operace viMap vytvá říloká lní adresní okno přímo mapující adresní prostor přístroje. Mapovaný
region může mít řadu atributů. Po namapová ní lze přístupovat k registrům přístroje
jednoduchý mi příkazy Peek a Poke.
sta tus : = viPeek32( vi, ptr, @va lue ) ;
{ ... . }
sta tus : = viPoke32( vi, ptr, $1234567 8 );
sta tus : = viClose( vi );
{obsa huje viUnm a p(vi)}
end;
Uzavírací funkce viClose automaticky odmapuje adresní okno pro přístup k registrům
přístroje. Kromě představené ho způsobu nabízí VISA té ž přístup k paměti na vyšší úrovni,
zajišťující jednak plně transparentní funkce Peek a Poke (tj. takové , které nevyžadují
mapová ní), jednak blokový přenos dat.
VISA definuje standadní mechanismus zpracová ní udá lostí. Udá losti jsou asynchronní
vý skyty informací, které knihovna zpracová vá nebo které generuje. Přitom je rozlišová na
dvojice hlavních mechanismů jejich zpracová ní - řazení do front nebo zpětné volá ní.
Při řazení udá lostí do front je důležité vědět, že VISA uschová vá informace o udá lostech
ve své interní frontě, takže aplikace je mohou zpracovat kdykoliv později. Nastavení tohoto
mó du vyžaduje prové st dva zá kladní kroky. V prvním z nich je třeba vyžá dat u VISA
zachycová ní udá lostí dané ho typu. To zajistí funkce viEnableEvent s parametrem VI_QUEUE.
V našem příkladě parametr VI_EVENT_SERVICE_REQ stanovuje sledová ní udá lostí na
přístrojové úrovni (např. SRQ na sběrnici GP-IB).
procedure Event_Queuing ;
va r
tim eo ut : ViUInt32;
conte xt : ViPEvent;
const
a ddre sString : ViRsrc = 'VICO{GPIB1: : 5}';
com m a ndString : ViBuf = 'VOLT : MEAS?';
event Def : ViUInt16 = VI_EVENT _SERVIC E_REQ;
begin
rdResponse : = nil;
sta tus : = viOpen( viD ef a ultRM, a ddresString, 0, 0, @vi );
sta tus : = viEna bleEve nt( vi, eventDef , VI_QUEUE,
Funkce viWaitOnEvent slouží pro čeká ní na příchod udá losti do fronty. Hodnota timeout
určuje maximá lní dobu čeká ní na příchod udá losti. Je-li hodnota nulová , funkce nečeká .
sta tus : = viW rite( vi, com m a ndString, Length(
com m a ndString^), @retC ount );
sta tus : = viW a itOnEve nt( vi, @eventDe f , tim eout,
@conte xt );
if st a tus = VI_SUCCES S then
beg in
G etMem ( rdResponse, RESPONSE_LENG T H );
sta tus : = viRea d( vi, rdResponse,
RESPON SE_LENGT H, @retC ount );
Další podporovaný mechanismus používá takzvaný ch zpětný ch volá ní. Metoda tedy
spočívá v tom, že knihovna VISA vyvolá uživatelem vytvořenou funkci v okamžiku, kdy přijde
udá lost. Vše by měl objasnit ná sledující příklad, rozdělený do trojice čá stí.
V první je vytvořena funkce, která bude obsluhovat udá losti přichá zející z knihovny
VISA. Funkce má fixně definované parametry s vý jimkou posledního, který je zá znamem
s variantní dé lkou a formá tem. Jeden z parametrů (context) je určen pro hodnotu, definovanou
při registraci podprogramu (je popsá na dá le). Smyslem tohoto parametru je rozlišení zdroje,
odkud byla funkce registrová na - vzhledem k reeentrantnosti kó du totiž nic nebrá ní tomu
registrovat funkci několikrá t a pak pouze z tohoto parametru může funkce usoudit, ke které
registraci se volá ní vztahuje (knihovna VISA si hodnotu pamatuje z registrace).
procedure Event_Ca llba c ks;
f unct ion SRQHa ndlerFunc( vi : ViSession;
eventT ype : ViEventT yp e; context : ViE vent;
userHa ndle : ViAddr ): ViSta tus; f a r;
begin
{ here com es user interrupt ha ndler code, e.g. : }
if rdResponse = nil then GetMem ( rd Response,
RESPON SE_LENGT H );
sta tus : = viRea d( vi, rdResponse, R ESPONSE_LENGT H,
@retCo unt );
SRQ Ha ndlerFunc : = V I_SUCCESS;
end;
V dalším kroku je třeba proceduru registrovat v knihovně VISA. To se dělá zavolá ním
funkce viInstallHandler :
const
a ddre sString : ViRsrc = 'VICO{VXI2: : 2 0}';
com m a ndString : ViBuf = 'VOLT : MEAS?';
event Def : ViUInt16 = VI_EVENT _SERVIC E_REQ;
begin
rdResponse : = nil;
sta tus : = viOpen( viD ef a ultRM, a ddresString, 0, 0, @vi );
sta tus : = viInsta llHa ndler( vi, @eventDef ,
@SRQHa ndlerFunc, VI_NU LL );
V posledním kroku je potřeba zavolá ním funkce viEnableEvent s parametrem VI_HNDLR
vyvolat zpětná hlá šení při příchodu udá losti :
sta tus : = viEna bleEve nt( vi, eventDef , VI_HNDLR,
VI_NUL L );
sta tus : = viW rite( vi, com m a ndString, Length(
com m a ndString^), @retC ount );
end;
Při obou mó dech činnosti lze, pro ukončení příjmu udá lostí, použít funkci viDisableEvent.
V některý ch aplikacích však může bý t vý hodné dočasné pozastavení zpětný ch volá ní bez ztrá ty
informace. V těchto případech se použije funkce viEnableEvent s parametrem
VI_SUSPEND_HNDLR. Udá losti jsou pak zaznamená vá ny do interní fronty knihovny (tato
fronta je oddělena od fronty pro první mó d) a jsou zde uschová ny až do obnovení činnosti
zpětný ch volá ní. Pak knihovna VISA provede zpětné volá ní tolikrá t, kolik udá lostí bylo
v mezidobí nastřádá no. Žá dná z udá lostí se tedy nemůže ztratit.
VISA v praxi
I když byl standard VISA akceptová n většinou vý robců modulů VXI, příprava
kompletních komerčních produktů zabere určitý čas. Aby bylo možno využívat vý sledků
vykonanané prá ce již nyní, definovala aliance VXIplug&play klíčovou podmnožinu knihovny
VISA, která je pod ná zvem VTL (VISA Transition Library) definová na specifikací VPP4.2.
VTL představuje podmnožinu omezenou, nicmé ně postačující pro prá ci s měřicími moduly.
Nevychá zí však z robustního zá kladu definované ho specifikací VISA, ný brž naopak umožňuje
začlenění již existujících knihoven obsluhy I/O operací. Nicmé ně specifikace garantuje možnost
budoucí migrace programů, vytvořený ch pro knihovnu VTL, ke knihovně VISA.
Knihovna VTL se již dodá vá , a to jako součá st kontrolé rů systé mů VXI. V rá mci aktivit
firmy IPP measure vznikl objekt určený pro snadné začlenění knihovny VTL do vý vojové ho
prostředí TestPoint. Objekt realizuje všechny metody definované ve VTL, včetně zpětné ho
volá ní (je realizová no vyvolá ním akčního listu). Vytvořený objekt umožňuje bezproblé mové
vytvá ření měřicích programů pro systé my VXI ve vý vojové m prostředí TestPoint, které se velice
osvědčilo.
Kontakt :
IPP measure s.r.o.
Prá čská 53
106 00 Praha 10
tel./fax : (02)755926
e-mail : [email protected]