Mým hlavním úkolem je zhotovit komunikační modul, který umožní ověřování a vývoj složitých regulačních algoritmů pomocí počítače PC v prostředí Matlabu. Vzhledem k existenci vhodného RT systému Real Time Toolbox distribuovaného firmou Humusoft se jedná o vytvoření driveru pro tento systém.

	Vzhledem ke stavu modelu v době zahájení práce a těsné vazbě mého úkolu na HW část jsem po konzultaci s vedoucím diplomové práce přesunul těžiště svého úsilí i na řešení této problematiky. Zde spolupracuji s Pavlem Krskem, řešitelem obvodové části celého zařízení.

	Tato práce společně s prací Pavla Krska navazuje na diplomovou práci ing. Pavla Beneše. Ten nemohl pro velký objem prací, vysokou složitost dílčích částí a dlouhé výrobní časy mechanických dílů celý model úspěšně dokončit.

	V průběhu řešení projektu bylo potřeba řešit větší množství různorodých problémů. Jednotlivé problémy vznikaly postupně při snaze uvést celý model do provozuschopného stavu. Proto se práce skládá z většího počtu popisů dílčích úkolů, navrhnutých a realizovaných řešení uvedených problémů. Diskuse o jednotlivých částech projektu je obsažena v první kapitole.

	V zadní části textu je obsaženo několik příloh s výpisy programů, jež byly napsány v rámci projektu. V textu jsou obsaženy odkazy na tyto programy. Čtenářům této práce, kteří nejsou z laboratoře automatického řízení, doporučuji nejprve začít četbu přílohou Realizovaná zařízení. V ní jsou obsaženy fotografie vyrobených částí, jež umožní snazší získání přehledu o celém projektu.

Hlavní řešené úkoly:
a)	Dokončení konstrukce trenažéru.
b)	Řízení modelu RC soupravou z počítače.
c)	Snímání polohy helikoptéry (stavu systému).
d)	Přenos informací o poloze k počítači.
	e)	Konstrukce napájecího zdroje s velkým výkonem.
f)	Softwarový interface modelu. V tomto případě se jedná o interface pro matematický program Matlab.
	g)	Testovací program pro ověření funkčnosti celé sestavy.

	Rád bych na tomto místě poděkoval panu ing. Janu Houškovi za podporu při tvorbě komunikačního driveru, panu ing. Zoltánu Tankó a ing. Štefanu Jedlikovi za cenné informace o obvodech Xilinx a panu ing. Petru Horáčkovi CSc. za finanční a organizační zajištění celého projektu. Dále bych chtěl poděkovat panu ing. Hábovi za zhotovení mechanických dílů konstrukce trenažéru.

Tento text není původní, ale vznikl sloučením s diplomovou prací Pavla Krska. Tímto obsahuje ucelený popis problematiky vývoje modelu vrtulníku v celé její šíři.

1.	

Předmluva:	  1

1. Obsah	  3

2. Úvod do problematiky	  9
2.1. Popis modelu	  9
2.1.1. Hlavní části helikoptéry	 10
2.1.2. Nosný rotor	 10
2.1.3. Trup vrtulníku a pohonná jednotka	 10
2.1.4. Ocas a vyrovnávací rotor	 12
2.1.5. Řídící a přistávací systémy	 12
2.2. Způsob řízení helikoptéry	 12
2.2.1. Letové režimy	 13
2.3. Souřadný systém	 14
2.4. Funkční bloky	 16
2.4.1. Řízení modelu RC soupravou z počítače	 16
2.4.2. Snímání polohy helikoptéry (stavu systému)	 17
2.4.3. Přenos informace o poloze k počítači	 17
2.4.4. Softwarový interface modelu	 17

3. Konstrukce trenažéru	 19
3.1. Uchycení modelu k trenažéru	 19
3.2. Návrh konstrukce trenažéru	 20
3.3. Snímání polohy modelu	 21
3.3.1. Možnosti pro určení polohy modelu	 21
3.3.2. Umístění snímačů polohy na trenažeru	 22
3.3.3. Použité inkrementální snímače	 23
3.4. Snímač otáček nosného rotoru	 24
3.5. Napájení modelu	 25
3.5.1. Napájecí baterie	 25
3.5.2. Alternativní přívod energie	 26
3.5.3. Způsob propojení napájecích kabelů	 26

4. Bezdrátové řídící systémy	 29
4.1. Komunikace v průmyslových systémech	 29
4.2. Přenosová cesta a přenosový kanál	 30
4.3. Přenosové cesty	 30
4.3.1. Akustická přenosová cesta	 30
4.3.2. Elektromagnetická přenosová cesta	 30
4.3.3. Optická přenosová cesta	 31
4.3.4. Metalická přenosová cesta 	 32
4.4. Přenos v základním a přeloženém  pásmu	 32
4.5. Modulace pro přenos analogových signálů	 32
4.5.1. Amplitudová modulace	 32
4.5.2. Frekvenční modulace	 33
4.5.3. Fázová modulace	 34
4.5.4. Impulsové analogové modulace	 35
4.5.5. Pulsně kódová modulace (PCM)	 35
4.6. Přenos digitálních signálů	 36
4.7. Kódování	 36
4.7.1. Kódová reprezentace zpráv	 36
4.7.2. Elektrická reprezentace	 37
4.7.3. Kódy pro přenos v lokálních sítích	 37
4.7.4. Vyšší úroveň kódování	 37
4.8. Modulace pro přenos datových signálů	 38
4.8.1. Amplitudová modulace ASK (Amplitude-shift keying)	 38
4.8.2. Frekvenční modulace FSK (Frequency-shift keying)	 39
4.8.3. Fázová modulace PSK (Phase-shift keying)	 39
4.8.4. Kvadraturní amplitudová modulace QAM (Quadrature amplitude modulation)	 39
4.9. Způsoby přenosu dat	 40
4.9.1.  Simplexní, duplexní přenos	 40
4.9.2. Paralelní, sériový přenos	 40
4.9.3. Synchronní, asynchronní přenos	 40
4.10. Shrnutí	 41

5. HW část modelu	 43
5.1. Celková koncepce	 43
5.2. Způsob připojení k PC	 44
5.3. Komunikace PC-model	 46
5.3.1. Funkce původní RC soupravy	 46
5.3.2. Úprava pro řízení počítačem	 47
5.3.2.1. Adresování vysílacích čítačů	 48
5.3.3. Propojovací kabely	 48
5.3.4. Propojení sběrnic	 49
5.4. Komunikace Model-PC	 49
5.4.1. Výchozí předpoklady a způsob řešení	 49
5.4.2. Komunikace z hlediska počítače	 50
5.4.3. Časování obvodů	 51
5.4.4. Sériový přenos dat 	 53
5.4.5. Časování sériového vysílače	 54
5.5. Bezdrátový datový spoj	 54
5.5.1. Úkoly a koncepce přenosu	 54
5.5.2. Vysílač	 55
5.5.3. Přijímač	 55
5.5.4. Anténní systém	 55

6. Programovatelná pole Xilinx	 59
6.1. Co je to integrovaný obvod XILINX	 59
6.2. Vnitřní struktura obvodu	 59
6.3. Nahrávání programu	 60
6.4. Předdefinované části schématu	 61
6.4.1. Primitiva kombinačních funkcí	 61
6.4.2. Primitiva vstupů a výstupů	 62
6.4.3. Primitiva klopných obvodů	 62
6.4.4. Primitiva oscilátoru a hodinových bufferů	 62
6.5. Programování obvodu Xilinx	 63
6.6. Způsob překladu schématu	 63
6.6.1. Cleanup	 63
6.6.2. Annotate	 65
6.6.3. Ercheck	 65
6.6.4. Netlist	 65
6.6.5. Pin2Xnf	 66
6.6.6. CorrXno	 66
6.6.7. XNFMerge	 67
6.6.8. XNFDRC	 67
6.6.9. XNFMAP	 68
6.6.10. MAP2LCA	 69
6.6.11. CorrLca	 69
6.6.12. APR	 70
6.7. Formáty a struktury datových souborů	 71
6.7.1. Formát .SCH	 72
6.7.2. Formát .VST	 72
6.7.3. Formát .XNF	 73
6.7.3.1. Starý soubor XNF	 74
6.7.4. Formát LCA	 74
6.8. Použité obvody	 75
6.9. Základní zapojení obvodů XILINX	 76

7. Napájecí zdroj	 79
7.1. Popis zdroje	 79
7.2. Soupis součástek	 82
7.3. Zkušenosti s provozem	 83
7.4. Zhodnocení činnosti zdroje	 83

8. Systémy reálného času	 85
8.1. Návrh číslicového regulátoru	 85
8.2. Požadavky kladené na RT systém	 86
8.3. Diskrétní versus spojitá simulace	 86
8.4. Výběr platformy pro RT systém	 87

9. Programové rozhraní s RT Toolboxem	 89
9.1. Vzorkovací perioda a prostupnost jádra	 89
9.2. Používání hardwarových ovladačů	 89
9.3. Driver pro DOSový Matlab	 90
9.4. Struktura hlavičky	 91
9.5. Komunikační funkce rozhraní	 92
9.5.1. HWDisable	 92
9.5.2. HWEnable	 92
9.5.3. InWord	 93
9.5.4. OutWord	 93
9.5.5. InScan	 93
9.6. Driver pro Matlab pod Windows	 94
9.6.1. Rozšíření funkcí rozhraní	 94
9.6.1.1. Disable	 94
9.6.1.2. Enable	 94
9.6.1.3. Input	 94
9.6.1.4. Output	 94
9.6.1.5. InScan	 95
9.6.2. Změny ve struktuře hlavičky	 95
9.6.3. Grafická nadstavba ovladače	 95
9.7. Komunikace s Matlabem	 96
9.7.1. rtload	 96
9.7.2. rtrd	 97
9.7.3. rtstart	 97
9.7.4. rtstop	 97
9.7.5. rtunload	 97
9.7.6. rtwho	 98
9.7.7. rtwr	 98
9.8. Ladění a diagnostika driveru	 98
9.8.1. Ladění Driveru pod Windows	 98

10. Programová část projektu	 99
10.1. Propojení z hlediska PC	 99
10.2. Komunikace s vnějším zařízením	100
10.2.1. Vstupní registry	100
10.2.2. Výstupní registry	102
10.3. Komunikace s driverem	103
10.3.1. Předzpracování naměřených údajů	104
10.3.2. Předávání výsledků do Matlabu	104
10.3.2.1. Konfigurace ovladače	104
10.3.2.2. Konfigurace ovladače pomocí GUI	105
10.3.2.3. Vstupní kanály	106
10.3.2.4. Výstupní kanály	106
10.3.3. Omezení vzorkovací periody	107
10.4. Diagnostický program	108
10.4.1. OvládÁní programu	108
10.4.2. Popis prováděných testů	108
10.4.3. Monitorování činnosti kanálů	109

11. Závěr	111

Příloha A Výpis RT driveru	112
A.1 Výpis RT driveru pro DOS	112
A.2 Výpis RT driveru pro Windows	117
A.3 Výpis grafické nadstavby driveru	122

Příloha B Programy pro konverzi schémat	128
B.1 Výpis programu CorrXNO	128
B.2 Výpis programu CorrLCA	133

Příloha C Výpis testovacího programu	135

Příloha D Popis desky XV1 a zdroje ZD1	149
D.1 Ovládací prvky a obsluha	149
D.2 Obvodové zapojení	149
D.3 Připojení desky XV1	151
D.4 Vnitřní zapojení obvodu XILINX na desce XV1	153
D.5 Zdroj napájení ZD1	162

Příloha E Popis desky XV2	163
E.1 Ovládací prvky a obsluha	163
E.2 Obvodové zapojení	163
E.3 Připojení desky XV2	163
E.4 Vnitřní zapojení obvodu XILINX na desce XV2	164

Příloha F Popis desky XRI a UN	168
F.1 Ovládací prvky a obsluha	168
F.2 Ovodové zapojení	168
F.3 Připojení desky XRI a celého interface	171
F.4 Vnitřní zapojení obvodu XILINX na desce XRI	171

Příloha G Bezdrátový datový spoj
	180
G.1 Deska Tx (vysílač)	180
G.2 Deska Rx (přijímač)	180

Příloha H Mechanické řešení desek	182
H.1 Desky plošných spojů 	182
H.2 Umístění desek 	182

Příloha I Realizovaná zařízení	186
I.1 Přijímač s vnějšími registry	186
I.2 Model vrtulníku	189
I.3 Vysílač pro řízení modelu	190
I.4 Přistávací plošina vrtulníku	191

Příloha J Použitá literatura	193

Příloha K Rejstřík	194

2.	

	V této kapitole jsou popsány hlavní části projektu, které bylo potřeba dokončit pro uvedení modelu do provozuschopného stavu. Celá práce je členěna do kapitol, z nichž každá se zabývá jedním funkčním celkem.

2.1.	

	Základem se stal RC továrně vyráběný  model helikoptéry EP CONCEPT s průměrem rotoru 890mm, jehož pohonná jednotka je tvořena SS elektromotorem LE MANS AP36 (maximální odběr 20A při 10V). Model byl vyroben firmou KYOSHO. Původně byl model řízen čtyřkanálovou  RC soupravou firmy Robbe pracující v modelářském pásmu 40Mhz. Jedná se o vrtulník klasické koncepce s jedním nosným rotorem o průměru 892mm s Bell-Hillerovým ovládáním a vyrovnávacím rotorem o průměru 175mm umístěným na konci ocasu. Celková vzletová hmotnost modelu je 1200 až 1300g.
	Model s elektromotorem byl zvolen pro tišší a čistější provoz. Musí  však být vyřešen přívod elektrické energie do motoru. Modely vybavené spalovacím motorem mají větší rozměry a jsou uvnitř laboratoře nepoužitelné. Jejich hlavní výhodou je větší užitečná hmotnost.
	Helikoptéra představuje z hlediska regulace nelineární mnoharozměrový ( MIMO) systém vyššího řádu. Takový reálný systém se hodí pro praktické ověřování moderních způsobů regulace složitých dynamických systémů, protože i přes rozvoj výpočetní techniky a simulačních metod nemůže žádná simulace nahradit reálný systém. Teoreticky by bylo možno odvodit diferenciální rovnice celého modelu a provádět regulaci na simulovaném modelu. Tato úloha je však velmi komplikovaná a představovala by pro jednoho člověka práci na několik let. Vzhledem k extrémní složitosti systému by rovnice musely být odvozeny odborníkem v oboru, což by si vyžádalo vysoké náklady na jeho práci. Při odvozování rovnic vždy dojde k některým zjednodušením a vliv některých faktorů není možno vůbec předem odhadnout (např. Turbulence vzduchu v místnosti).
	Naším úkolem je vytvořit dostatečně bezpečný reálný model helikoptéry, který by co nejvěrněji napodoboval chování skutečného vrtulníku a který by bylo možné řídit počítačem. K řízení je nutné vybavit model systémy pro snímání polohy a pro řízení helikoptéry.
	Helikoptéra je těžko řiditelný systém a přitom lze model lehce poškodit. Proto je bezpečnost modelu zajištěna jeho umístěním na trenažéru. Trenažér se skládá ze dvou Cardanových kloubů spojených výsuvnou tyčí. Kloub I (pod vrtulníkem) zajišťuje kromě náklonu ve dvou osách i možnost otáčení helikoptéry kolem svislé osy. Kloub II (pod heliportem) zajistí opět náklon ve dvou osách a navíc vysouvání spojovací tyče. Dohromady je tak zajištěn prakticky volný pohyb helikoptéry v kuželu nad heliportem. Kloub II s heliportem je umístěn na konstrukci tak, aby se model nemohl dostat do blízkosti překážek. Bezpečnost modelu je vykoupena omezením pracovního prostoru modelu a bohužel i menší změnou dynamických vlastností modelu.

2.1.1.	

Obr.   Hlavní části helikoptéry

	Byl vybrán typ vrtulníku s jedním nosným rotorem. Proto je další popis vrtulníku zaměřen právě na tento typ. Na listech otáčejícího se nosného rotoru vzniká vztlaková síla, která představuje nosnou sílu celé helikoptéry. Působením odporu prostředí na listy je vytvářen ještě reakční moment. Jeho působením by došlo k rotaci trupu helikoptéry, a proto je nutno provést kompenzaci reakčního momentu. Kompenzace je prováděna vyrovnávacím momentem, který vzniká otáčením vyrovnávacího rotoru. Vyrovnávací rotor je obvykle umístěn na zádi vrtulníku, přibližně v ose souměrnosti stroje a v rovině nosného rotoru tak, aby se eliminovala nevyvážená síla vzniklá jeho tahem a velký sklon trupu. Pohon obou rotorů je zajištěn motorem přes rozvodnou soustavu. Jednotlivá ústrojí jsou v trupu rozmístěna s ohledem na těžiště, které by mělo být v optimálním případě umístěno pod středem nosného rotoru. Rozmístění základních částí vrtulníku je ukázáno na .

2.1.2.	

	Dvoulistý nosný rotr má průměr 892mm. Rotor je opatřen tuhými závěsy rotorových listů a pomocným řídícím rotorem aerodinamického Hillerova stabilizátoru, který tvoří dva krátké listy na koncích opatřené řízenými ploškami. Nastavování listů nosného rotoru, jak cyklické, tak kolektivní zajišťuje systém s řídící deskou ovládaný třemi servy řídícího systému přes pákové mechanismy.

Obr.   Rozměrový náčrt helikoptéry

2.1.3.	

	Trup vrtulníku má délku asi 200mm a šířku 60mm. Je tvořen základnou na níž stojí konstrukce, která spojuje základnu trupu s ocasní částí a slouží k ukotvení hřídele hlavního rotoru. Základna tvoří plochou krabičku v níž je umístěn převodový systém pro pohon rotorů. V zadní třetině trupu je ukotven hřídel hlavního rotoru spojený s převodovou soustavou přes jednosměrnou spojku (tzv. cvrčka). Spojka zaručuje otáčení hlavního rotoru i v případě, že dojde k výpadku hnací jednotky a umožňuje tak nouzové 

přistání autorotací. A naopak, běží-li motor, pohání přes spojku nosný rotor bez omezení.
	V ose trupu před hlavním hřídelem je vertikálně umístěn elektromotor s osou směřující směrem dolů, kde je v základové desce spojena s převodovým ústrojím. Pohon vyrovnávacího rotoru je řešen hřídelem v zadní části trupu spojeným přímo s převodovkou. Tento hřídel pohání přes řemenový převod vyrovnávací rotor. Taková konfigurace náhonu rotorů je nevýhodná tím, že v případě letu autorotací není vyrovnávací rotor poháněn, ale je dokonce brzděn zablokovanou pohonnou soustavou. Tím se značně zhorší řiditelnost celého vrtulníku.

2.1.4.	

	Ocas je tvořen duralovou trubkou o průměru 15mm a délce asi 470mm. Jejím středem prochází gumový pás, který pohání vyrovnávací rotor. Ten spolu s mechanikou pro ovládání náběhu jeho listů je upevněn na konci duralové trubky. Servo je spojeno s mechanismem zadního rotoru lankem. V zadní části ocasu jsou vertikální a horizontální stabilizační plochy.

2.1.5.	

	Akčními členy řídící soupravy jsou čtyři modelářská serva přimontovaná po obou stranách ke konstrukci trupu, vždy dvě a dvě na jedné straně. Řízení modelu zajišťuje čtyřkanálová RC soprava ATTACK-4 (FP T4NBL) firmy Robbe, která pracuje s kmitočtem 40,695MHz. Přijímač RC soupravy je umístěn v přední části trupu před hnacím motorem, kde je pro jeho umístění prostor o ploše 50x60mm. Přistávací zařízení (podvozek) tvoří dvě ližiny vytvarované z duralových trubiček o průměru 4mm.

2.2.	

	Klasický vrtulník je ovládán změnou směru a velikosti vektoru tahu nosného rotoru a změnou velikosti tahu vyrovnávacího rotoru.
	Změna velikosti tahu vyrovnávacího rotoru způsobí momentovou nerovnováhu a tím otáčení stroje kolem svislé osy, tedy změnu směru letu. Velikost momentu ovládá pilot pedály nožního řízení, které mění úhel náběhu listů vyrovnávacího rotoru, a tak mění i jeho tah.
	Změnou velikosti tahu nosného rotoru se dociluje stoupání či klesání helikoptéry. Protože tah se řídí nastavením náběhu všech listů rotoru společně, nazývá se tento způsob kolektivní řízení či kolektiv. Páka kolektivu je podobná páce automobilové ruční brzdy, ale umisťuje se vlevo od sedadla pilota.
	Obvykle na páce kolektivu bývá otočná rukověť, která ovládá přípusť motoru. Její pomocí lze nastavit otáčky motoru a tím i nosného rotoru. Pro chod motoru se však obvykle požaduje udržení otáček v oblasti, kdy motor dodává maximální výkon či má největší účinnost. Přípusť se tak většinou nepoužívá k přímému ovlivňování letu.
	Změnou náběhu listů v průběhu jedné otáčky se docílí vzniku kroutícího momentu, který naklání celý vrtulník. Spolu s nakloněním roviny nosného rotoru se nakloní i vektor tahu a vytvoří se tak vodorovná síla, která způsobuje posuvný pohyb vrtulníku. Náklon je možno provést jak v podélné tak v příčné ose podle toho, kde se v otáčce zvětší či zmenší úhel náběh listů rotoru. Protože ke změně úhlu náběhu dochází cyklicky v průběhu otáčení rotoru, nazývá se toto řízení cyklické či zkráceně cyklika. Cyklika se ovládá pohybem řídící páky , která je umístěna před sedadlem pilota.
	Helikoptéra je mnohem méně stabilní než klasické letadlo. Nestabilita při řízení vyžaduje zvýšenou pozornost pilota a zvětšuje nebezpečí havárie. Pro zvýšení stability jsou helikoptéry vybaveny stabilizátory, které mají za úkol tlumit naklánění vektoru tahu nosného rotoru a jsou vřazeny mezi pilota a cyklické řízení. Nejznámější jsou stabilizační systémy Bellův a Hillerův. Podstatou Bellova systému je mechanický setrvačník, zatímco Hiller doplnil rotor o pomocné řídící plošky. Dnes se tyto systémy nahrazují hydraulickými posilovači, nebo přímo autopilotem.
	Vrtulníky jsou také citlivější na vítr a turbulenci, než klasická letadla. Situace je lepší při rychlém dopředném pohybu, kdy se chování helikoptéry blíží chování letounu s pevnými křídly. Obecně se dá říci, že řízení vrtulníku je složitý a náročný úkol.

2.2.1.	

	V této části uvedené režimy představují možná zadání budoucích experimentů s řízením modelu. Použitý model se snaží co nejvěrněji se  přiblížit chování skutečného vrtulníku, a proto většina režimů přímo vychází z provozních režimů běžných vrtulníků.

Naklánění a otáčení trupu:
	Režim je umožněn mechanickou konstrukcí trenažéru a spočívá v pevné fixaci pohyblivé tyče ve spodním Cardanově kloubu. Hlavní výhodou je značné zjednodušení celého systému vhodné v přípravných fázích návrhu regulátoru. Při fixaci tyče však vznikne pevný bod, který způsobí změny v dynamice modelu. 

Start:
	V každé z následujících regulačních úloh musí být vyřešen start vrtulníku. Při startu se projevuje tzv. přízemní jev, který mění chování vrtulníku a tím celý manévr komplikuje. Při použití malé přistávací plošiny, umístěné ve větší vzdálenosti od podlahy a stěn než je průměr rotoru, by se přízemní jev neměl podstatně projevovat. 

Přistání:
	Operace přistání je obdobná startu. Při klesání se mění způsob obtékání rotoru a spolu s přízemním jevem je značně komplikováno přiblížení k přistávací plošině.

Visení:
	Vrtulník zůstává na jednom místě a udržuje si konstantní výšku. Dopředný let zlepšuje stabilitu vrtulníku. Při jeho absenci se zhoršuje stabilita celého modelu. Tento způsob letu představuje obvyklý režim činnosti vrtulníků. Předpokládám, že udržení modelu v režimu visení bude představovat nejčastější regulační úlohu.

Přímý let:
	Při naklonění trupu vrtulníku v režimu visení provedeného pomocí změny cykliky se vrtulník začne pohybovat ve směru náklonu. Míra naklonění určuje rychlost letu. Při použití trenažéru je dosah vrtulníku omezen délkou vodící tyče. Proto lze provést přímý let jen po velmi krátké dráze.

Plynulá zatáčka:
	Zatáčka je prováděna z režimu přímého letu plynulou změnou cykliky při součinnosti zadní vrtulky. Dochází k natáčení vrtulníku do strany. Vzhledem ke zvolené konstrukci závěsu bude pro zvládnutí diskutovaného režimu vhodný pohyb po kruhové trajektorii.

Přistání autorotací:
	Je obdobou nouzového přistání letadel a provádí se většinou při vysazení motoru. Provedení autorotace vyžaduje určitou výšku. Volnoběžka odpojí hřídel rotoru od motoru a pilot nastaví negativní náklon listů. Klesáním vrtulníku dojde k prudkému nárůstu otáček. V blízkosti země pilot nastaví zpět kolektivní řízení a setrvačná energie rotoru postačí ke zpomalení klesání. Tento režim nemůže být zkoušen pomocí trenažéru. 

2.3.	
	V letectví se pro popis pohybu letadla používá různých soustav souřadnic. Pro navigaci se užívá souřadná soustava odvozená od kartografické soustavy poledníků a rovnoběžek. Jedná se vlastně o sférickou souřadnou soustavu, kde je poloha popsána zemskou délkou, šířkou a výškou nad povrchem země. Při studiu dynamiky letu je většinou zbytečné uvažovat zaoblení země a komplikovat si tak výpočty, když rozdíly jsou prakticky zanedbatelné. To platí obzvláště pro náš model helikoptéry pohybující se pomalu a na velmi malém prostoru. Pro popis dynamiky letu se proto užívá pravoúhlé soustavy souřadnic.
	Systém pro popis letu letadla se skládá z několika sořadných systémů, které jsou spolu provázány. Vztahy mezi těmito systémy pak popisují polohu letadla v prostoru a polohu vůči proudu vzduchu, která je pro let velmi důležitá.
	Základní soustavou souřadnic je zemský souřadný systém (Og;xg,yg,zg), jehož rovina xg,zg je vodorovná a představuje povrch země. Polohová souřadnice yg pak odpovídá výšce nad zemí. Pro zjednodušení se tento souřadný systém považuje za inerciální.
	Těžiště letadla tvoří počátek letadlové soustavy souřadnic (O;x,y,z). Osa x je orientována od zádi k přídi trupu, tedy v předpokládaném směru letu, osa y směřuje kolmo vzhůru a tvoří tak rovinu symetrie letounu. Osa z je kolmá k rovině x,y a směřuje do strany vpravo od osy x.
	Z hlediska letu je důležitá aerometrická sostava souřadnic (Oa;xa,ya,za), jejíž osa xa je rovnoběžná s vektorem rychlosti vzduchu obtékajícího letadlo a je orientována opačně, nebo-li odpovídá vektoru vzdušné rychlosti. Osy ya,za jsou pak orientovány obdobně jako u letadlového souřadného systému.

Obr.   Souřadné systémy pro popis pohybu letadla

	Vztah mezi zemským souřadným systémem a souřadným systémem letadla udává obecnou polohu letadla v prostoru. Polohu letadla v prostoru popisujeme šesti parametry:
x, y, z ...	Poloha těžiště letadla
		ψ .........	Kurz - pootočení kolem osy y souřadného systému letadla
		ϑ .........	Podélný náklon - pootočení kolem osy z
		γ .........	Příčný náklon - potočení kolem osy x letadla.

	Následující rovnice popisují vztah letadlové a zemské souřadné soustavy:

	()

 BOLD {x_g} ~=~[ x_g ` ,y_g`,y_g`,1 ]^T ~~~~~ BOLD x ~=~[ x ,y ,z ,1 ]^T 

	(

 BOLD {x_g} ~=~ LEFT[ ` MATRIX {0&0&0&x # 0&0&0&y # 0&0&0&z # 0&0&0&1} ` RIGHT]
~ LEFT[ ` MATRIX { cos psi&0&- sin psi&0 # 0&0&0&0 # sin psi&0& cos psi&0 # 0&0&0&1} ` RIGHT]
~ LEFT[ ` MATRIX { cos vartheta &- sin vartheta &0&0 # sin vartheta & cos vartheta &0&0 # 0&0&0&0 # 0&0&0&1} ` RIGHT]
~ LEFT[ ` MATRIX { 0&0&0&0 # 0& cos gamma & sin gamma &0 # 0&- sin gamma & cos gamma &0 # 0&0&0&1} ` RIGHT]
~ BOLD {x}
	Vztah mezi souřadnou soustavou aerometrickou a letadlovou popisuje aerodynamické podmínky vzhledem k letadlu. Aerodynamické podmínky se popisují omezeným počtem parametrů a není tak určena úplná transformace souřadných soustav, jak je tomu při udávání polohy letadla, protože nemá smysl udávat náklon letadla příčně k proudu vzduchu, ani jeho absolutní polohu vůči tomuto proudu. Aerodynamická situace je tak popsána třemi parametry:
		α .........	Úhel náběhu - úhel svíraný vektorem vzdušné rychlosti a osou letadla x v rovině symetrie letadla x,y
		β .........	Úhel vybočení - úhel svíraný vektorem vzdušné rychlosti a osou letadla x v rovině křídel letadla x,z.
		v .........	Vzdušná rychlost - rychlost letadla vůči okolnímu vzduchu. Jedná se o vektorovou veličinu, ale zde je myšlena pouze absolutní hodnota, protože její směr je dán parametry α,β.
	Následující rovnice popisují vztah letadlové a aerometrické souřadné soustavy:

	(

 BOLD {x_a} ~=~[ x_a ` ,y_a`,y_a`,1 ]^T ~~~~~ BOLD x ~=~[ x ,y ,z ,1 ]^T 

	(

 BOLD {x_a} ~=~ LEFT[ ` MATRIX { cos beta &0&- sin beta &0 # 0&0&0&0 # sin beta &0& cos beta &0 # 0&0&0&1} ` RIGHT]
~ LEFT[ ` MATRIX { cos alpha &- sin alpha &0&0 # sin alpha & cos  alpha &0&0 # 0&0&0&0 # 0&0&0&1} ` RIGHT]
~ BOLD {x}
	Lepší představu o popisu polohy letadla a vzdušné situace si můžeme udělat z  a výše uvedených rovnic.

Obr.  Rozdíl orientace os normy GOST a ISO

Obr.  Konstrukce se závěsem

Tab.   Umístění inkrementálních snímačů

Číslo
snímače	Typ	Přesnost
[per/ot]	Snímaná veličina (Umístění)	
1	IRC 450.1/512/BZ	512+Index	Příčný náklon vrtulníku (Kloub I)	
2	IRC 450.1/512/BZ	512+Index	Podélný náklon vrtulníku (Kloub I)	
3	IRC 450/540/B	540	Otočení kolem osy spojovací tyče
(Kloub I)	
4	IRC 450.1/512/BZ	512+Index	Příčný sklon spojovací tyče (Kloub II)	
5	IRC 450.1/512/BZ	512+Index	Podélný skon spojovací tyče (Kloub II)	
6	IRC 450/540/B	540	Vysunutí spojovací tyče (Kloub II)	

	Trenažér byl za účelem snímání polohy opatřen rotačními inkrementálními snímači úhlu natočení. 
Po dvou snímačích jsou umístěny v každém kloubu, kde snímají náklon v jednotlivých pohybových rovinách kloubů. Jeden snímač, umístěný těsně pod kloubem helikoptéry, zaznamenává otáčení kolem spojovací výsuvné tyče. Vysouvání tyče je pogumovanou kladkou převedeno na otáčení, které je registrováno posledním šestým inkrementálním snímačem polohy. Snímač pro snímání vysunutí spojovací tyče je součástí kloubu pod heliportem. Umístění snímačů, jejich typ a snímanou veličinu přehledně ukazuje  a .

3.3.3.	

	Vzhledem k tomu, že model bude po celou dobu své činnosti připoután, lze jeho polohu snímat podle náklonů kloubů konstrukce. Snímací členy by měly dosáhnout dostatečného rozlišení při malé hmotnosti. Nejhorší situace nastane v případě měření náklonů tyče. Tam se nepřesnost měření úhlu násobí délkou tyče, což způsobí značnou nepřesnost určení pozice vrtulníku pro větší délku tyče.

Obr.  IRC snímač

	Protože není možný přenos v základním pásmu, byla pro jednoduchost realizace vybrána amplitudová modulace (AM). Při hloubce modulace 100% je možné realizovat modulátor jediným hradlem, které je uvnitř obvodu XILINX. Za nosný signál byl zvolen signál s kmitočtem řídícího krystalu 18,432MHz. Zapojení vysílače se tím velice zjednoduší.
	Důležité je poznamenat, že vysílací výkon je pouze asi 10 až 20mW. Tak malý výkon je dostatečný pro přenos na krátkou vzdálenost a přitom z hlediska předpisů spadá mezi pomocné vysílače. Mezi ně řadí vysílač i absence antény s větším ziskem. Protože pomocné vysílače nemají žádná frekvenční ani modulační omezení a nepodléhají registraci, je celkem pochopitelná snaha, aby vysílač patřil mezi vysílače pomocné. Malý výkon a použitá anténa samozřejmně také zajistí, že vysílač nebude rušit jiné zařízení a hlavně nebude rušit ani původní RC soupravu, kterou využíváme pro povelové řízení a jejíž antena je v těsné blízkosti tohoto vysílače.

5.5.2.	

	Vysílač se skládá z modulátoru, který je tvořen hradlem NAND. Aplitudově modulovaný signál z výstupu hradla je zaveden do výstupního zesilovače. Zesilovač tvoří tranzistor PNP s resonančním obvodem v kolektoru laděným na kmitočet nosného signálu. Cívka resonančního obvodu tvoří i vysílací anténu. Napájecí napětí vysílače je 10V z hlavního napájecího zdroje. Průběh modulačního signálu je volen tak, aby v době kdy se nemá vysílat byl vysílací tranzistor určitou dobu otevřen a rychleji zatlumil anténní resonanční obvod. Dojde tak k zrychlení přechodu mezi dvěma stavy použité digitální amplitudové modulace, což zlepší situaci při zpracování sériového signálu v přijímačovém obvodu XILINX.

5.5.3.	

	Přijímač tvoří vstupní resonanční obvod jehož cívka je i přijímací anténou. Signál z tohoto obvodu je zesilován jednotranzistorovým odporovým VF zesilovačem. Z jeho výstupu přichází signál přímo na detekci (usměrnění a filtrace) a pokračuje dál do Nf zesilovače, kterým je tranzistor určený k úpravě napěťových úrovní. Výstupem přijímače je přímo sériový signál v úrovních TTL, jako byl před modulátorem. Přijímač není vybaven žádným systémem AVC, protože se předpokládá dostatečná síla signálu při libovolné pozici modelu a nepředpokládám ani větší změnu síly signálu jak 20dB, při čemž amplitudové omezení signálu nevadí, nebo je dokonce výhodné.

5.5.4.	

	Obě antény tvoří cívky resonančních obvodů. Toto řešení je pravděpodobně nejjednodušší pro daný nosný kmitočet. Je nutno si totiž uvědomit, že délka vlny je asi 16,3m.

Obr.   Umístění antén datového spoje

6.	

	Protože vytvářené zařízení je velice obvodově náročné, rozhodl jsme se použít moderních velkokapacitních programovatelných logických polí firmy XILINX. Následující odstavce mají dát základní informace o obvodech XILINX a způsobu jejich programování. V zařízení jsou osazeny tři obvody XILINX stejného typu. Protože se jejich základní zapojení shodují s doporučením katalogu, je popsáno použité základní konfigurační zapojení pro všechny najednou.

6.1.	

	Každý obvod Xilinx se navenek chová jako uživatelsky programovatelný LSI obvod podobně jako hradlové pole. Obvody Xilinx jsou snadno znovu přeprogramovatelné. Základní stavební jednotkou logického pole je konfigurační logický blok (CLB = configurable logic block), jehož zjednodušené vnitřní zapojení je na .
	Firma XILINX přivedla na trh programovatelná logická pole s velkou integrací. Ekvivalentem každého obvodu je několik tisíc hradel. My jsme se rozhodli pro střední třídu těchto obvodů, kterou představuje řada XC3000. Tato řada je pro daný účel vhodná jak svými možnostmi tak i svou cenou (600 až několik tisíc Kč).

Obr.   Zapojení konfiguračního logického bloku (CLB)

	Následuje popis jednotlivých kroků při překladu. Vzhledem k obtížné dostupnosti literatury je každý použitý program podrobně rozebrán. Příkazy jsou popisovány v tom pořadí, v jakém jsou při překladu volány. U každého příkazu je uvedeno i několik dalších možných parametrů.
	Uvedené informace by měly posloužit pouze pro toho, kdo bude vyžadovat drobné úpravy ve vnitřním zapojení obvodů. Pak nebude muset pracně řadit jednotlivé programy a může se věnovat pouze překladu upravených schémat. Navíc byly některé korekční programy dodatečně napsány autorem této diplomové práce. 

6.6.1.	
Spuštění:	CLEANUP %1.SCH

	Program zabezpečí odstranění duplicitního umístění součástek, spojových čar a návěští ve schématu. Ty mohou být nakresleny vícekrát přes sebe, což normálně na obrazovce není vidět. V lepším případě je hlášena chyba v některé další fázi překladu. Někdy uvedená skutečnost může způsobit naprosto nečekané chování navrhnutého zařízení.

Parametry:	/h	Schémata vícekrát volaná v komplexní hierarchii se zpracovávají jen 1x.
		/r	Více průchodů. Tato volba je vhodná pro velká schémata.

6.6.2.	

Spuštění:	ANNOTATE %1.SCH /M/U

	Prohlíží buď hierarchie schémat nebo navzájem související soubory na stejné úrovni (FLAT soubory) a přepisuje reference součástek. Reference součástek je možno aktualizovat buď přírůstkově nebo bezpodmínečně. Anotovaný soubor je možno buď použít pouze pro další programy nebo je možno s ním pracovat místo původního schématu.
	Reference jsou použity v dalších krocích algoritmu pro označení součástek jako jejich jména. Při zpracování hierarchických schémat tímto programem je na aktuální disk nahráno větší množství swap souborů. Je potřeba si dát pozor na dostatečnou kapacitu (několik Mb) a na rychlost anotace. Při pokusu anotovat soubor na disku vzdáleném přes 4 síťové segmenty trval celý proces kolem půl hodiny. U ostatních programů tento problém nenastává.

Parametry:	/d	Vstupuje i do podschémat, které mají ve schématu vytvořenou grafickou značku.
		/h	Spouští v každém schématu číslování referencí od 1. Využívá se u hierarchických schémat. 	
		/m	Přesměruje výstupní soubor do vstupního schématu.
		/o	Zpracuje pouze zadané schéma bez hierarchického řazení.
		/u	Bezpodmínečná změna referencí. Změní se i ty reference, které už byly uživatelem ručně zadány.

6.6.3.	

Spuštění:	ERC %1.SCH /s

	Vykonává kontrolu zapojení a výpis chybových hlášení v případě nalezení nezapojeného vstupu, uzeměného výstupu, zkratovaného zdroje atp. Zjišťuje také chybějící návěští vodičů vstupujících do sběrnice a nezapojené Module porty.
	Výstupní chybová hlášení je potřeba prověřit, protože mohou vzniknout i při správném návrhu zapojení.

Parametry:	/l	Vytváří seznam všech návěští.
		/s	Provádí v celé hiererchii schémat kontrolu shody I/O bodů (Module porty).
		/u	Výpis nepřipojených vývodů.

6.6.4.	

Spuštění:	NETLIST %1.SCH %1.PIN FUTURENET /S
		NETLIST %1.SCH %1.PIN VSTMODEL /S

	Vytvoří seznam propojení mezi jednotlivými komponentami, který je vhodný pro další zpracování. V podstatě se jedná o výstupní bod OrCADu. V našem případě je pak spojový .PIN konvertován do tvaru .XNF akceptovatelným vývojovým prostředím Xact.

Parametry:	/o	Zpracuje se pouze zadané schéma bez hierarchického řazení.
		/u	Zapíše seznam nezapojených výstupů do .NC souboru.
		/q	Vypne generaci výpisů při nahrávání.
		/s<formát>	Výstup pro program PCB.

6.6.5.	

Spuštění:	PIN2XNF -O -P 3042pc84-70 %1

	Provádí konverzi souboru ve formátu .PIN do formátu .XNF. Při konverzi umožňuje rozložení hierarchické struktury podobně jako program XNFMerge. Pouze jednotlivé dílčí elementy musí být ve formátu .PIN. Tohoto způsobu je využito při práci s bloky, uloženými v knihovnách OrCadu. Při tomto způsobu práce není nutno schémata z knihoven znovu překládat.
	Jedná se pravděpodobně o starší verzi programu. Výsledný vygenerovaný soubor .XNF je nekompatibilní s ostatními programy. Z tohoto důvodu musí být dodatečně upraven programem CorrXno. Protože program neumožňuje definovat adresář s popisy jednotlivých bloků, musí být všechny použité .PIN soubory nakopírovány do stejného adresáře, což značně komplikuje překlad schémat.

Parametry:	-p <typ>	Umožní definovat cílový obvod.
		-m	Provedení rozkladu hierarchicky řazených částí schématu. Nelze-li popis symbolu nalézt, pak je na obrazovku vypsáno varování.
		-x	Rozložitelné symboly budou rozkládány až v dalších fázích překladu. Parametry x a m se navzájem vylučují.
		-o	Použito pro FutureNet pinlist soubory vytvořené v OrCadu.
 
6.6.6.	

Spuštění:	CORRXNO %1.XNF %1.XXX %1.VST %1.PIN

	Uvedený program není součástí programového balíku OrCad ani Xilinx. Byl dodatečně napsán a byl vložen do této fáze překladu pro odstranění nekompatibilit mezi verzemi jednotlivých programů. Program je napsán v Pascalu a jeho výpis je uveden v příloze.
	Protože OrCad ve verzi 3.0 není schopen do formátu .PIN vyexportovat informace o umístění nožiček na schématu, musí být tyto informace získány z přídavné tabulky. Všechny důležité informace pro tvorbu tabulky jsou obsaženy pouze ve formátu .VST. Z tohoto důvodu program umožňuje i automatické vytvoření tabulky ze souboru .VST.
	Soubor *.XXX představuje vlastně opravený .XNF soubor. V tomto typu souboru však nejsou již uvedena označení jednotlivých pinů ve schématu, ale pouze čísla externích signálů. Pozice pinu je reprezentována atributem jednotky pinu (z hlediska OrCadu Part field). Signál spojující pin s vnitřní logikou má své pevné jméno, které je obsaženo v souboru .PIN. Podle tohoto jména signálu pak lze jednoznačně určit ke kterému pinu je připojen a přiřadit mu správnou pozici. Pokud není pozice pinu překladači známa, zvolí si ji náhodně.
	Další zjištěnou nekompatibilitou je špatná reprezentace invertovaných signálů. Programem je opravena i tato nekorektnost v souboru .XNF. Pokud by zůstal .XNF soubor v původním tvaru, je činnost dalších fází překladu znehodnocena. Podrobnější informace o struktuře jednotlivých souborů jsou uvedeny v kapitole: Formáty a struktury datových souborů.

Parametry:	xxx.XNF	Opravovaný vstupní soubor.
		xxx.XXX	Výstupní opravený soubor.
		xxx.PIN	Soubor s dodatečnými informacemi potřebnými pro korekci.
		xxx.VST	Soubor s informacemi o umístění vnějších pinů.

6.6.7.	

Spuštění:	XNFMERGE %1 $

	Odstraňuje hierarchickou strukturu v návrhu při zachování identického chování celé struktury. Program přihrává XNF nebo MAP soubory z hierarchicky nižších úrovní do jediného souboru, který neobsahuje žádné odkazy na jiné soubory MAP nebo XNF.
	Nejprve je načten a prohledán soubor popisující nejvyšší úroveň hierarchické struktury. Jako rozložitelný je považován každý symbol jehož jméno není obsaženo v množině primitivních symbolů. Po nalezení složeného symbolu, je vyhledán soubor s popisem jeho struktury. Je-li nalezen současně jak .XNF tak .MAP soubor pro popis jednoho elementu, je vybrán nejnovější z nich.
	Při rušení hierarchické struktury dochází k modifikaci jmen signálů a symbolů v návrhu. Kde je to možné, tam zůstávají původní jména signálů v kombinaci s prefixem. Tímto je odstraněn konflikt jmen, ke kterému by docházelo při vícenásobném použití jednoho souboru. Pouze jména v nejvyšší hierarchické vrstvě zůstávají zachována.

Parametry:	vstupní_soubor
		výstupní_soubor
		-d <adresář>	Jméno adresáře s podřízenými soubory. Lze použít i vícenásobně.
		-p <typ>	Umožní definovat cílový obvod.
		-q	Používání nerozložených souborů. Není-li tento parametr zadán, pak je na obrazovku vypsáno varování.
		-x	Zpracování pouze souborů XNF. MAP soubory jsou ignorovány.

6.6.8.	

Spuštění:	XNFDRC $

	Kontroler pravidel návrhu projektu je určen pro nalezení a identifikaci možných problémů na počátku překladu. Provádí také test konzistence souboru .XNF a vyjímání 'mrtvé' logiky z celého projektu (např. hradlo s nezapojeným výstupem).
	Při běžném překladu je obyčejně hlášeno velké množství různých varovných hlášení. Ty pouze upozorňují na možné zdroje chyb, nebo doporučují lepší techniku návrhu, ale struktura zapojení není jakýmkoliv způsobem transformována.

Parametry	-p <typ>	Umožní definovat cílový obvod.
		-o <file>	Výstupní soubor obsahující všechna hlášení. Implicitně má jméno kontrolovaného souboru s koncovkou .DRC.

6.6.9.	

Spuštění:	XNFMAP -N $

	Program XNFMAP přiřadí logiku definovanou v souboru XNF do jednotlivých  LCA elementů ( CLB,  IOB a  TBUF). Soubor .XNF představuje vstupní bod programu. Na výstupu je vytvořen .MAP soubor, který popisuje rozčlenění logiky. Dále program XNFMAP generuje soubor .CRF, který obsahuje seznam křížových referencí, informace o vyřazené nepoužité logice, nesprávně použitých symbolech a shrnující informace o návrhu.
	V každém CLB bloku jsou obsaženy dva klopné obvody (dále jen KO). Pro minimalizaci počtu vnějších spojů je nejvýhodnější provést sloučení dvou vzájemně vázaných KO (např. dělič 8). Program XNFMAP porovnává jména jednotlivých KO. Pro porovnání je z konce názvu odtržena poslední číselná část s výjimkou znaku '_' (např. REGA09 a REGA10 budou sloučeny). Vyšší prioritu při párování mají přímé požadavky na umístění KO do předem definovaného CLB.
	Pro číslování bloků používá OrCad dvojici čísel oddělenou '_'. První číslo udává pořadí elementu ve schématu a druhé definuje číslo schématu v hierarchii. Proto budou sloučeny KO s označením REG34_20 a REG35_20.
	Informace o umístění LCA elementů lze uchovat v průvodním souboru .PGF a použít pro další iteraci návrhu projektu. Při každém spuštění programu je soubor . PGF obnovován a korigován. Pro zanesení informací ze souboru .LCA je nutno nejprve použít program LCA2XNF. Použití průvodního souboru však musí být povoleno parametrem -k a program by měl nalézt soubor . AKA popisující křížové reference mezi původními a zkrácenými jmény signálů.

Parametry:	-e	Zakáže vyjímání nepoužité logiky. Vhodné pro odhad počtu vyjmutých CLB.
		-f	Vytváření hustšího návrhu. Může způsobit větší počet nepropojených pinů v další fázi překladu.
		-i	Umožní přímé řízení vstupů KO ze vstupních pinů.
		-k	Napodobuje rozmístění LCA elementů podle .PGF souboru z předchozí iterace.
		-p <typ součástky>	Umožňuje předefinovat popř. zvolit typ použitého obvodu.

6.6.10.	

Spuštění:	MAP2LCA $

	MAP2LCA překládá .MAP soubor do pole logických jednotek (LCA Logic Cell Array), které je využíváno vývojovým prostředím XACT. Program vykonává poslední krok konverze XNF->LCA.
	Výstupem je .LCA soubor, který popisuje rozdělení schématu do vnitřních bloků. Neobsahuje však zatím informace o vzájemném propojení jednotlivých bloků. Tento soubor je možno nahrát a dále ručně zpracovávat programem XACT, nebo provést automatickou optimalizaci umístění a spojování bloků programem APR. Dalším výstupním souborem je upřesňující soubor .  SCP, který popisuje omezení pro umísťování a spojování bloků (např. specifikaci umístění jednotlivých pinů).

Parametry:	/a	Zakáže vytváření .AKA souboru, který obsahuje hierarchická jména symbolů a signálů.
		/i	Přikáže programu, aby ignoroval všechna omezení nalezená v .MAP souboru.
		/p <typ součástky>	Umožňuje předefinovat popř. zvolit typ použitého obvodu.

6.6.11.	

Spuštění:	CORRLCA $.lca $$.lca

	Tento program podobně jako CORRXNO byl napsán dodatečně a není součástí standardního balíku. Je zapsán v jazyce P ascal a jeho výpis je uveden v příloze.
	Při automatické konverzi schémat do prvků LCA jsou programem MAP2LCA do souboru LCA přidány i upřesňující informace o rozložení třístavových budičů T BUF. Umístění těchto budičů je velmi omezeno vnitřní strukturou obvodu. Z každého bloku CLB mohou vycházet pouze dva budiče, které mohou být připojeny pouze k některým Long line. Program APR je schopen si takovéto rozmístění sám poměrně uspokojivě navrhnout.
	Pokud má však zadánu pevnou pozici budičů, nemůže být měněna jejich pozice. Při menším počtu sběrnic uvedená skutečnost způsobí pouze horší umístění, které se na vnější funkci vůbec neprojeví. Při větším počtu však docházelo k "záhadným" chybám, kdy při přidání jednoho invertoru schéma najednou nebylo možno programem APR přeložit.
	Na výstupu se v takovém případě objevilo hlášení "Invalid block name TBUF=xx". Nabízí se jednoduché řešení provést inicializaci parametrem /i u programu MAP2LCA. Překlad proběhne bez jakýchkoliv chyb, avšak všechny informace o pevném umístění nožiček jsou definitivně ztraceny.
	Při nahlížení do souboru .LCA byly nalezeny položky nesoucí informace o umístění  třístavových budičů. Program CorrLCA takovéto položky automaticky v souboru .LCA vyhledává a následně ruší. Jejich uvedení totiž není ve formátu LCA povinné. Po korekci pak může vlastní překlad proběhnout bez jakýchkoliv problémů.

Parametry:	vstupní_soubor
		výstupní_soubor

6.6.12.	

Spuštění:	APR -w -A 99 $ %1

	Zautomatizuje většinu (v mnoha případech všechnu) práci s umísťováním a vzájemným spojováním bloků v .LCA projektu. Pro zlepšení optimality návrhu provádí při své práci cyklicky metodu simulovaného žíhání.
	Nejprve je načten projekt uložený v .LCA souboru, který může nebo nemusí obsahovat informace o vzájemném spojení bloků. Poté je vytvořeno nové umístění bloků, spojů a uzlů v návrhu, které je zapsáno do jiného .LCA souboru. Při dokončení operace je vytvořen soubor .RPT, který obsahuje informace o provedených činnostech.
	
Překlad je prováděn ve třech po sobě následujících fázích:
 Simulované žíhání (annealing):
	V této části je spotřebována většina času. Činnost algoritmu lze ovlivnit nastavením počáteční a koncové teploty žíhání, rychlostí ochlazování a semínkem generátoru náhodných čísel. Při nastavení nízké výchozí teploty podobně jako při vysoké koncové teplotě většinou nebude nalezeno optimální rozmístění bloků. Není-li přímo specifikována rychlost ochlazování, je vypočítána optimální hodnota v rozmezí 5% až 50%.
	Implicitně jsou parametry nastaveny tak, aby výsledný návrh byl optimální. Pro potřeby ladění, pokud je využito méně než 50% CLB je velmi výhodné čas podstatně zkrátit (při plné optimalitě se může na stroji 486/33 jednat i o hodiny). Zkrácení lze provést nastavením počáteční teploty na nulovou hodnotu (tím se žíhací fáze úplně přeskočí) nebo zvýšením rychlosti ochlazování.

Vyhlazení (quenching):
	Představuje druhý krok fáze umísťování bloků. V této fázi jsou prováděny jen malé změny výsledného návrhu. Odpovídají nízké konstantní teplotě žíhání.

Spojování ( routing):
	Provádí vzájemné spojování bloků, jejichž pozice se již nemění. Router je opakovaně spouštěn pouze v případě, že se nepodaří pospojovat všechny signály. Celkem jsou k dispozici 3 routery:
r3	Router optimalizující zpoždění. Je ze všech všech tří nejpomalejší (jedná se o zlomek doby žíhání). Většinou nachází optimální spojení již při první iteraci a větší množství iterací již výsledek nezlepší.
r2	Optimalizuje spojení. Pokud r3 nemůže vzájemně spojit méně než 5 uzlů, je vhodné ještě zkusit r2.
r1	Nejrychlejší router. Pro úspěšnou činnost potřebuje, aby bylo nejméně 20% CLB volných.

Parametry:	-a počet	Specifikuje počet pokusů o spojení jednotlivých bloků. Implicitní hodnota je 3.
-b teplota	Zadání výchozí teploty pro algoritmus simulovaného žíhání.
		-f		Použití rychlého algoritmu žíhání. Zmenší se počet provedených přesunů a tím i celková doba činnosti.
		-k rychlost	Nastaví rychlost ochlazování procesu simulovaného žíhání.
		-q		Zakáže žíhací fázi překladu a přeskočí rovnou do vyhlazovací fáze.
		-r router	Definuje typ routeru.
		-w		Přepíše výstupní soubory bez předchozího varování.

6.7.	

	V této části jsou rozebrány struktury jednotlivých formátů používaných pro reprezentaci elektrických schémat. Schéma nakreslené v OrCadu prochází při svém překladu do logického pole postupně konverzními programy přes jednotlivé formáty. Diskutovanou konverzi zachycuje obrázek:  - 'Struktura datových toků při překladu schématu'.
	V ideálním případě by se uživatel nemusel vnitřní strukturou níže popisovaných formátů vůbec zabývat. K něčemu takovému však dochází jen velmi zřídka. Uvedené informace byly získány metodou zpětného inženýrství při hledání chyb ve špatně přeloženém schématu.
	Jednotlivé formáty nejsou dostatečně standardizovány a jsou u každé nové verze modifikovány. Případná nekompatibilita pak může způsobit zastavení překladu nebo v horším případě dojde k zanesení chyb do výsledné matice spojů programovatelného logického obvodu. Popisované chyby jsou pak velmi špatně zjistitelné a projevují se nekorektním chováním navrhovaného zařízení.

Obr.  Testovací pokusné schéma

	Vstupních i výstupních kanálů je staticky definováno 256. Před zavedením ovladače jsou všechny označeny jako nepoužité. To znamená, že vstupní kanál vždy vrací nulovou hodnotu a data poslaná do výstupního kanálu se ztrácí. Do paměti lze současně zavést maximálně 8 ovladačů. Číslo ovladače 9 je interně využito pro označení nepoužitých kanálů.
	Za povšimnutí stojí skutečnost, že vstupní a výstupní kanály jsou číslovány odděleně. Nepoužité kanály, které nejsou vázány k fyzickým vstupům/výstupům přes ovladač, lze výhodně využít pro definování vazby s jiným objektem.
	Odkaz na kanál je prováděn přes číslo kanálu. Způsob číslování je absolutní a začíná od čísla 1. První kanál dalšího driveru daného typu bude mít pořadí 1+(počet kanálů prvního ovladače stejného typu). V ovladači je interně zavedeno číslování kanálů od 0. V nové verzi RT Toolboxu v.2.0 je povoleno navíc ještě relativní číslování. Číslo kanálu se v tomto případě skládá ze dvou číslic oddělených tečkou. První z nich definuje číslo ovladače a druhé určuje kanál ovladače. Pro zrychlení činnosti jádra je relativní číslování odvozeno od absolutního během příkazu rtdef. Před použitím relativního číslování je potřeba nejprve nahrát všechny ovladače a definovat časovače. Jinak nebude tento způsob pracovat korektně.

9.3.	

	Celý driver představuje fragment kódu, který začíná od adresy 0. Na uvedené adrese musí být nalezena tabulka s přesně definovaným významem jednotlivých položek. Na konci tabulky jsou obsaženy odkazy na jednotlivé procedury. Vlastní kód může zabírat maximálně 64kB paměti. Při volání HWEnable lze volat i služby DOSu.
	Je možné psát zdrojový text i v jazyce C. Pro diskutovaný případ je nutno zapsat v Assembleru pouze vyplněnou hlavičku s odkazy do výkonné části. Při překladu jazyka C je nutno volit takový paměťový model, který má kód a data v jednom společném segmentu. Avšak všechny výkonné procedury musí být v překladači definovány jako vzdálené. Slovem výkonné jsou označeny ty, které jsou přímo volány z jádra RT Toolboxu.
	Drivery pro Matlab a pro Matlab 386 mají totožnou strukturu. Pokud nejsou uvnitř použity speciální funkce, je možno stejný driver zavést z obou prostředí. Je také možné při zavolání funkce HWEnable otestovat režim, ve kterém je driver spuštěn a podle výsledku testu vybrat vhodnou část kódu. Nejjednodušší test lze provést porovnáním registrů DS a CS. V reálném režimu musí mít samozřejmě stejnou hodnotu, protože ukazují na stejné místo v paměti.
	V Matlabu 386 běží RT Toolbox v okruhu 0 procesoru. S touto úrovní oprávnění jsou spouštěny i všechny drivery.

9.4.	

	Na počátku hlavičky je obsažen název zařízení zakončený znakem 0. Nemá vliv na funkci driveru a slouží pouze pro informaci uživatele při zadání příkazu RTWho.
	Při volání inicializační procedury HWEnable lze předat driveru maximálně 2 parametry. V případě jejich zadání z Matlabu jsou již v okamžiku volání procedury HWEnable nastaveny žádané hodnoty. Oba parametry nemají žádný vliv na další činnost RT Toolboxu s jednou výjimkou: nelze zavést 2x stejný driver se shodnou adresou. Parametr Address by měl nějakým způsobem popisovat adresu zařízení. Při psaní zdrojového textu je vhodné oba parametry nastavit na implicitní hodnoty.
	Parametry inchn respektive outchn udávají počet vstupních respektive výstupních kanálů. Jejich hodnota je definitivně platná až po provedení inicializační procedury HWEnable. V této proceduře lze podle zadaných hodnot parametrů nastavit požadovaný počet vstupních a výstupních kanálů. Pak by se již počty kanálů neměly měnit.
	Položka functions obsahuje odkazy na následující funkce: HWdisable, HWenable, inword, outword, inscan (jejich popisu je věnována následující kapitola). Funkce jsou uvedeny v požadovaném pořadí. Všechny ukazatele musí ukazovat do platné části kódu.

Celou strukturu hlavičky popisuje následující tabulka:

Položka	Délka	Popis	
Hwname	32 byte	Logické jméno zařízení	
option	1 word	Parametr předaný při zavádění	
inchn	1 word	Počet vstupních kanálů	
outchn	1 word	Počet výstupních kanálů	
adress	1 word	Fyzická adresa zařízení	
dmarq	1 word	Adresa kanálu DMA	
dmaspeed	1 word	Rychlost DMA kanálu	
reserved	4 byte		
functions	5 word	Ukazatale na jednotlivé funkce	

9.5.	

	Odkazy na funkce jsou uvedeny v tabulce functions. Přes to, že funkce jsou definovány způsobem Far, jsou v tabulce uvedeny pouze jejich offsety. Segmenty kódu musí být vzhledem k použitému modelu shodné pro celý driver a jsou doplněny podle volaného driveru.
	Jednotlivé funkce jsou volány jako procedury z jazyka C, a proto je potřeba dodržet určitá pravidla při práci s registry. Nemělo by dojít ke změnám segmentových registrů ES a DS. Dále by měly být zachovány hodnoty indexových registrů SI, DI a BP. Všechny ostatní registry je možno libovolně měnit.

Příklad zápisu procedury:
inscan	proc	c far uses bp si di
		mov	ax,-1
		ret
		endp

9.5.1.	

Vstupy:	-
Výstupy:	-

	Zruší činnost ovladače karty. V praxi se může jednat o vypnutí elektronicky ovládaných zařízení. Může provést i odalokování programových zdrojů využívaných ovladačem karty. Procedury HWEnable a HWDisable by měly být při korektní práci s RT Toolboxem volány v páru po sobě.

9.5.2.	

Vstupy:	AX = Datový segment driveru
		DX = Údaj o rychlosti procesoru
Výstupy:	AX =  0 Instalace proběhla v pořádku
		     != 0 Nastala chyba při instalaci

	Provede inicializaci a popřípadě i detekci přítomnosti obsluhovaného hardware. Vzhledem ke stejné struktuře driverů pro Matlab a Matlab 386 lze v tomto bodě přepínat potřebné části kódu. Podle nastavení proměnných Option, Adress a DMArq lze modifikovat činnost ovladače a dodatečně nastavit počet vstupních a výstupních kanálů.
	Rychlost procesoru je měřena podle počtu průběhů jednoduchou smyčkou Loop za 1mS při zakázaném přerušení. Tento údaj by měl být kontrolován zejména výpočetně náročnějšími drivery (např. pro rozpoznávání obrazu). Nedostatečná rychlost hostitelského počítače pak povede k odmítnutí instalace.
	Datový segment ukazuje na hlavičku driveru a je v reálném režimu totožný se segmentem kódu. 

9.5.3.	

Vstupy:	AX = Číslo kanálu
Výstupy:	AX = Přečtená hodnota z kanálu

	Funkce přečte jedno slovo ze specifikovaného kanálu. Přečtená hodnota se může pohybovat v rozsahu +maxint -maxint. Při znalosti maximálních a minimálních možných hodnot by tento interval měl být převeden do celého rozsahu slova. Uvedený rozsah je následně konvertován v prostředí Matlabu do rozsahu +1 -1.

9.5.4.	

Vstupy:	AX = Číslo kanálu
		DX = Zapisovaná hodnota
Výstupy:	-

	Zapíše jedno slovo do výstupního kanálu. Interval -1 +1 je konvertován do rozsahu  -maxint +maxint v registru DX. Je-li z prostředí Matlabu zapsáno číslo mimo uvedený rozsah, je výstupní hodnota limitována a do registru DX zapsána maximální hodnota.

9.5.5.	

Vstupy:	AX = Číslo kanálu
		DX = Vzorkovací perioda v μS
		BX = Počet vzorků
		ES:DI -> Ukazatel na data
		CX:SI -> Fyzická adresa dat (pro  DMA kanál)
Výstupy:	AX =  0 Činnost proběhla v pořádku
		      = -1 Funkce není driverem podporována

	Účelem této funkce je sejmout co možná nejrychleji definovaný počet po sobě následujících vzorků. V praxi nalezne použití při měření velmi rychlých přechodových charakteristik, kde nelze vystačit s použitím historických proměnných. U driveru nemusí být tato funkce implementována. V takovém případě by procedura InScan měla vždy vracet hodnotu -1 v registru AX.
	Pokud připojené vnější zařízení je schopno pracovat přes DMA kanál, tak jej lze využít. Při volání v chráněném režimu nabývá fyzická adresa dat a ukazatel na data rozdílných hodnot.

9.6.	

	RT Toolbox od verze 2.0 podporuje pouze platformu Windows. Jedná se o novou verzi ve které došlo k větším změnám i ve struktuře ovladačů. Změny jsou hlavně způsobeny kompletním přechodem na podporu jazyka C. Všechny funkce nyní mají definován způsob předávání parametrů přes zásobník, jak je tomu obvyklé u použitého kompilátoru jazyka C. Parametry komunikačních funkcí však zůstaly z větší části zachovány.
	Zdrojový text je nyní vhodné psát v jazyce C. Pro překlad byl vybrán 32 bitový kompilátor  Watcom C++, který podle zkušeností generuje poměrně úsporný kód.

9.6.1.	

	V této kapitole jsou popsány pouze změny a vylepšení, která přináší nová verze RT Toolboxu. Všechny ostatní informace zůstaly nezměněny a byly již popsány v kapitole Komunikační funkce rozhraní.

9.6.1.1.	
void Disable(void)
	Zruší činnost ovladače karty.

9.6.1.2.	
int Enable(int np, double *parm, int (*callback) (int fn,...))
	Provede inicializaci HW vnějšího zařízení. Nyní lze předat v proměnné options libovolnou strukturu Matlabu tzn. číslo, vektor nebo matici. Proměnná *parm pak obsahuje ukazatel na celou strukturu a do proměnné np je uložen počet položek. Takto lze ovladači předat libovolné množství informací.
     Ukazatel *callback zpřístupňuje vnitřní funkci jádra, která poskytuje určité služby.

9.6.1.3.	
double Input(int ch)
	Přečte hodnotu z kanálu ch. Nová verze neomezuje zapisovanou hodnotu na jedno slovo a nechává konverzi přímo na samotném ovladači. Přečtená hodnota z kanálu nyní není omezena intervalem <-1;1> a může nabývat libovolné hodnoty (v povoleném rozsahu typu  double). 

9.6.1.4.	
void Output(int ch, double val)
	Zapíše hodnotu předanou v proměnné val do kanálu ch. Na rozsah zapisovaných hodnot, podobně jako u procedury Input, se nevztahují žádná omezení. Z toho vyplývá nutnost ošetřit nevhodné hodnoty mimo povolený rozsah zpřístupňovaného vnějšího zařízení.

9.6.1.5.	
int InScan(int ch, int len, double *spec, double *buf, int *cols)
	Sejme ze zařízení co možná nejrychleji z kanálu ch definovaný počet vzorků s udanou periodou vzorkování. Navzorkovaná data budou následně uložena do pole *buf. V této verzi není již předávána fyzická adresa paměti, protože OS Windows již v sobě obsahuje funkce pro práci s kanály  DMA.
	Proceduře InScan lze předat jako parametr namísto jednoduché proměnné matici libovolné velikosti. V proměnné len je obsažen počet položek struktury na kterou ukazuje parametr *spec. První číslice v předávané struktuře spec[0] je již vyhrazena pro periodu vzorkování.
	Použitelné návratové hodnoty jsou předdefinovány v souboru RT.H. V jádře RT Toolboxu není proveden test povoleného intervalu hodnot příčin chybových hlášení a v případě použití hodnoty mimo interval dojde pravděpodobně k pádu OS (to se týká i hodnoty -1).

9.6.2.	

	Vzhledem k orientaci na jazyk C je hlavička definována jako strukturovaná proměnná. Na první adrese driveru je pevně umístěn ukazatel na strukturu hlavičky. Pozice hlavičky v driveru pak již může být libovolná. Datová struktura je definována v souboru RTDSTUB.H. Význam jednotlivých položek zůstal zachován. Odkazy na jednotlivé funkce popisují i jejich parametry.

typedef struct
	{
	char Name[MAXDRVNAME];
	int Inputs;
	int Outputs;
	unsigned short Address;
	void (*Disable) (void);
	int (*Enable) (int pn, double *parm, int (*callback) (int fn,...));
	double (*Input) (int ch);
	void (*Output) (int ch, double val);
	int (*InScan) (int ch, int len, double *spec, double *buf, int *cols);
     	} Driver;

9.6.3.	

	Matlab od verze 4.0 zpřístupňuje vytváření uživatelských oken s dialogy přímo pomocí příkazů svého vnitřního jazyka. Po zadání příkazu  figure je vytvořeno nové okno a příkazem  uicontrol lze vytvářet jednotlivé ovládací prvky. Nastavení ovládacích prvků je možno zjistit příkazem get popřípadě změnit příkazem set.
	Většinu parametrů a nastavení RT Toolboxu lze měnit přes grafické rozhraní GUI (Graphics User Interface). Rozhraní může zpřehlednit a usnadnit komunikaci s ovladačem.
	Pro ovládání pomocí GUI  musí mít každý ovladač HW navíc .M soubor, který umožní jeho inicializaci v dialogovém režimu. Spustitelný .M soubor je až na koncovku pojmenován stejně jako vlastní ovladač. Po spuštění vykreslí okno s ovládacími tlačítky na obrazovku a reaguje na všechny události. V okénku je vhodné umístit řádek s aktuálním příkazem, který by bylo možno zadat i z dialogové řádky pro vykonání stejné akce. Zavádění ovladače přes grafické rozhraní tedy nepřináší oproti dialogové řádce žádné podstatné výhody.
	Požadavek na zobrazení konfiguračního panelu driveru vznikne při použití příkazu Rtload bez parametrů. Ten otevře okno umožňující výběr ovladače. Druhou možnost představuje přímé zadání jména ovladače z dialogové řádky.
	Každý .M soubor obsahující definici funkce Matlabu může obsahovat nápovědu ke své činnosti. Nápověda je zobrazena po zadání příkazu  HELP JMÉNO_SOUBORU. V souboru je za nápovědu považována souvislá část komentáře následující po definici funkce. Stručné informace o driveru lze získat příkazem HELP JMÉNO_DRIVERU.

9.7.	

	Prostředí Matlabu představuje interpreter vlastního jazyka optimalizovaného pro vědecké výpočty. Je umožněno volání vnějších procedur tzv .M souborů, nebo volání přímo spustitelných . MEX souborů přeložených do speciálního formátu.
	Verze pro Matlab a Matlab 386 je založena na volání .MEX souborů. Nejnovější verze RT Toolboxu pro Windows má dvouúrovňové volání. Nejprve je interpretován .M soubor s definicemi grafického uživatelského rozhraní. Všechny požadavky jsou následně přesměrovány do spustitelného souboru  RTTOOL.MEX, který provádí komunikaci s jádrem. Jádro je zavedeno do paměti již při spouštění Windows jako  VxD ovladač. Zájemce o podrobnější informace odkazuji na literaturu  [Humusoft: RT Toolbox for Matlab User's manual].

9.7.1.	

	Zavede jádro RT Toolboxu do paměti a provede jeho inicializaci. Většinu ostatních funkcí je možné volat až po inicializaci jádra. V okamžiku zavádění ovladače je volána procedura Enable.
	Parametry opt, addr a dma (dma pouze v DOSové verzi) jsou interpretovány pouze zaváděným ovladačem. Není prováděna žádná kontrola předávaných hodnot. Zadání špatných hodnot může způsobit neočekávané katastrofální výsledky. HW ovladače komunikují přímo přes porty s připojeným zařízením. Nevhodně zvolené adresy portů totiž mohou odpovídat např. řadiči HD, CMOS paměti, grafickému displeji atd. Všechny ovladače v sobě již mají předdefinovány implicitní hodnoty, čímž lze uvedenému problému částečně předejít.
	Ve verzi pro DOS lze podruhé zavést stejný ovladač pouze s jinou hodnotou adresy. Ve verzi pod Windows již toto omezení neplatí a při dvou stejných zavedených ovladačích může dojít ke kolizi v přístupu k vnějšímu HW.

Modifikace:	rtload
		rtload(Základní_perioda)	Pouze pro verzi běžící pod DOSem.
		rtload('Jméno_ovladače')
		rtload('Jméno_ovladače',parametr)
		rtload('Jméno_ovladače',parametr,adresa)

9.7.2.	

	Přečte obsah proměnné RT Toolboxu a zapíše jej do ordinální proměnné Matlabu. Časovač obsahuje větší množství proměnných. Většina z nich může být přepsána příkazem rtwr.
	Pro práci je nejdůležitější stínová proměnná označená písmenem y. Umožňuje čtení výstupů systému a jsou v ní uloženy výstupní hodnoty posílané do vnějších vstupů. Obsah je aktualizován při každém hodinovém intervalu časovače a způsob aktualizace závisí na jeho typu. Všechny ostatní proměnné mají pouze upřesňující význam.
	Příkaz rtrd je určen také pro čtení historické proměnné. Počet řádek vstupní proměnné odpovídá počtu dosud zpracovaných vzorků. Je-li zadána druhá vstupní proměnná, je do ní zapsán celkový počet zpracovaných vzorků. Ten může být i větší než je délka proměnné.

9.7.3.	

	Spustí všechny definované časovače. Od tohoto okamžiku budou opakovaně prováděny všechny předem definované akce včetně volání inicializovaných ovladačů. Po inicializaci příkazem rtdef jsou časovače zastaveny a musí být popisovaným příkazem spuštěny.
	Ve verzi 2.0 je vyžadováno zadání parametru all. Pokud není alespoň jeden časovač spuštěn, VxD ovladač pouze pasívně komunikuje s okolím. Po zadání rtstart all jsou spuštěny všechny časovací a vyhodnocovací procesy, čímž se zvýší riziko pádu OS Windows. Proto není vhodné při spuštěném RT Toolboxu zavádět do paměti další programy a pracovat s nimi.

9.7.4.	

	Zastaví všechny definované časovače a dočasně zruší provádění všech definovaných akcí. Hodnoty časovačů zůstanou zmrazeny až do jejich opětovného spuštění příkazem rtstart. Pak se budou vyvíjet přesně od toho místa, kde byl časovač zastaven. 

9.7.5.	

	Uvolní všechny ovladače z paměti počítače. Před uvolněním ovladače je volána procedura Disable. Všechny spuštěné časovače jsou zastaveny a historické proměnné smazány.
	Ve verzi pod DOSem je při opuštění Matlabu proveden pokus o automatické uvolnění RT Toolboxu z paměti. To nemusí ve všech případech pracovat korektně a proto je lepší použít příkaz rtunload. U driveru pro Windows běží VxD driver dál bez možnosti ovládání (je možno s ním i nadále komunikovat přes vyhrazené přerušení, což je prakticky těžko proveditelné) a v nejlepším případě pouze zpomaluje činnost ostatních programů.

9.7.6.	

	Vytiskne zajímavé informace o stavu jádra RT Toolboxu na obrazovku. Jsou vypsána jména zavedených HW driverů, definované časovače spolu s jejich periodami, definované historické proměnné včetně jejich délky, vazby mezi objekty, zátěž systému v % atd.

9.7.7.	

	Zapíše obsah ordinální proměnné Matlabu do proměnné RT Toolboxu. U většiny proměnných lze přepsat jejich hodnotu. Zápis historické proměnné začíná vždy od jejího prvního vzorku. Operace rtwr přepisuje vždy celou proměnnou. Pokud je potřeba modifikovat její část, její obsah musí být nejprve přečten, modifikován a následně zapsán.

9.8.	

	Testovnání jakékoliv části kódu běžícího v reálném čase je obecně velmi obtížné. Krokování již nemůže být prováděno v reálném čase. Proto je možno pouze staticky otestovat komunikační procedury s vnějším zařízením.
	Do části kódu, kterou je potřeba ověřit, se přímo vloží instrukce INT 3 a ovladač se znovu přeloží. Spustí se  debugger  TD 286 ( TD popř. TD 386 zabírá v paměti příliš mnoho místa). Z něho je zaveden do paměti program Matlab, který se spustí klávesou F9 (run). V Matlabu normálně pracujeme s RT Toolboxem. V okamžiku, kdy procesor zpracovává námi vloženou instrukci INT 3, dojde k zastavení Matlabu v trasovacím okně debuggeru. Krokování probíhá od této chvíle analogicky jako u ostatních programů.
	Ladění ovladačů pro Matlab 386 probíhá obdobně. Pouze místo TD 286 je nutno použít  Metaver Debugger nebo W atcom Debugger. Je-li použit ovladač paměti  QEMM je potřeba před laděním zadat příkaz QDPMI off, jinak může dojít ke kolizi rozšiřujících služeb správce paměti s debuggerem.
9.8.1.	

	Ovladač pro Windows běží jako proces v jádře systému Windows. Pro ladění vnitřních procesů musí být zavedeno speciální ladící jádro. Pak je možné přes sériovou linku nebo síť z jiného počítače ladit vyvíjený program.
	Vzhledem k obtížnosti výše popsané metody doporučuji odladit jednotlivé procedury v testovacím programu. Když pracují správně, pak je lze snadno zkopírovat do zdrojového kódu ovladače a provést jeho opětovný překlad.
	Protože procesy v jádře nelze nijak chránit, jakákoliv chyba v ovladači se projeví pádem OS. Pokud lze ještě zavolat DOS, Windows okamžitě ukončí svou činnost a přejdou do DOSu. V opačném případě je nutno provést restart počítače.

10.	

	V této kapitole je obsažen popis a rozbor realizovaných programů, které komunikují s HW částí a provádějí její diagnostiku. Jedná se zejména o ovladače pro RT Toolbox, jejichž struktura byla diskutována v předchozí kapitole.

10.1.	

	Propojení je realizováno přes rozšiřující kartu číslicových a analogových vstupů a výstupů  PCL-812. Ta je zasunuta do rozšiřujícího slotu sběrnice   ISA v základní desce počítače. Komunikace je prováděna přes skupinu 15 portů, jejichž číslování začíná od adresy Base.
	Bázovou adresu umístění portů lze volit pomocí konfiguračních přepínačů na desce rozšiřující karty. Při připojení k počítači s jiným nastavením této adresy by pak mohl nastat problém. V takovém případě by se však nepodařilo ovladač vůbec zavést do paměti.
	Před zavedením ovladače helikoptéry je prováděn test na přítomnost karty PCL-812. Test je založen na měření doby A/D převodu z libovolného kanálu.

Pozice jednotlivých portů ukazuje následující tabulka:
Umístění	Čtení	Zápis	
Base +0	Čítač 1	Čítač 1	
+1	Čítač 2	Čítač 2	
+2	Čítač 3	Čítač 3	
+3	 -	 -	
+4	A/D nižší byte	D/A nižší byte, kanál 1	
+5	A/D vyšší byte	D/A vyšší byte, kanál 1	
+6	D/I nižší byte	D/A nižší byte, kanál 2	
+7	D/I vyšší byte	D/A vyšší byte, kanál 2	
+8	 -	Zrušení žádostí o přerušení	
+9	 -	 -	
+10	 -	Multiplexer A/D vstupů	
+11	 -	Řízení PCL-812	
+12	 -	A/D Trigger	
+13	 -	D/O nižší byte	
+14	 -	D/O vyšší byte	

	Pro připojení k vnější sběrnici jsou využity následující kanály: D/O_Hi - adresa+řídící signály, D/O_Lo - datová sběrnice výstupní, D/I_Lo - vstupní datová sběrnice. Zájemce o podrobnější informace o I/O rozšiřující kartě odkazuji na literaturu:[PCL-812 Enhanced multi lab card user's manual].

10.2.	

	Pro komunikaci jsou využity dvě výstupní a jedna vstupní brána, čímž vznikne simulovaná sběrnice procesoru 8080. Tato část již byla detailně rozebrána v kapitole Způsob připojení k PC. Jednotlivé signály řídící sběrnice jsou zobrazeny na .
	Veškerá komunikace je následně prováděna pomocí čtení a zápisu paměťových registrů připojených k vnější sběrnici. Registry v sobě obsahují všechny důležité informace o poloze vrtulníku a všechny řídící signály. Komunikace pomocí registrů je výhodná pro stejný způsob práce s jednotlivými registry.
	V této části jsou vstupní respektive výstupní registry chápány z hlediska nadřízeného počítače. To znamená, že ze vstupního registru lze pouze číst a výstupní registr je určen výhradně pro zápis.

Obr.  Umístění signálů řídící sběrnice

10.2.1.	

	Vstupní registry obsahují všechny potřebné informace o stavu modelu včetně několika dalších určených pouze pro diagnostiku.

Obsazení vstupních registrů:

Číslo	Význam registru	
0	Kurs vrtulníku	
1	Příčný náklon modelu	
2	Podélný náklon modelu	
3	Rychlost otáčení rotoru	
4	Příčný náklon vodící tyče	
5	Podélný náklon vodící tyče	
6	Délka vysunuté tyče	
7	 -	
8	Kontrolní registr 1.kanálu	
9	Kontrolní registr 2.kanálu	
10	 -	
11-15	Kontrolní identifikátor 'PK&JF'	

	Standardní  sběrnice 8080 vyžaduje předstih adresy před aktivací signálu RD. Obvod Xilinx je však naprogramován takovým způsobem, že mu nevadí snížení předstihu na nulovou dobu. Tím se podaří ušetřit v programu jeden sběrnicový cyklus zápisu do rozšiřující karty, který trvá velmi dlouhou dobu z hlediska CPU 1.4μS (za tuto dobu vykoná procesor 486/50 přibližně 280 instrukcí).
	S uvedenou dobou je počítáno při vytváření vnějšího sběrnicového cyklu. Obvod Xilinx dodá data na sběrnici přibližně za 500nS. Při použití výkonnější IO karty by pak bylo nutno vložit odpovídající časové zpoždění mezi požadavek na čtení a vlastní čtení příslušného registru.
	Registry 11-15 slouží pouze pro identifikaci připojeného zařízení nadřazeným počítačem. Vedlejším efektem jejich čtení je vynulování kontrolních registrů kanálů.

Čtení registru provádí následující funkce:
int read_channel(char kanal)
{
 int i;
 outp(baze+14,0x90|kanal);
 i=inp(baze+6);
 outp(baze+14,0xD0|kanal);
 return(i);
}

	Přečtená hodnota ze snímače polohy je pouze osmibitová. Avšak rozsah možných hodnot je podstatně větší. Jedná se o nejnižších 8bitů registru polohy. Vyšší bity tohoto registru nejsou ani registrovány ani přenášeny.
	Tímto způsobem je možno snížit množství dat přenášených po sériové lince. Při použití 16 bitových registrů by navíc došlo k podstatnému zvětšení počtu CLB, což by si vyžádalo větší a tedy i dražší programovatelné pole.
	Řídící procesor však musí provést  rekonstrukci zbylých bitů. Rekonstrukce se provádí po vyčíslení rozdílu mezi aktuální a minulou hodnotou. Je-li rozdíl větší než polovina rozsahu registru (v našem případě 128), pak je nutno provést korekci vyššího řádu. Jediným omezením pro rekonstruktor je určitá maximální doba, za kterou je potřeba provést opětovné čtení registru.
	Uvedená doba je závislá na dynamice systému. Pokud vzorkovací perioda překročí uvedenou dobu, dojde k selhání rekonstrukce a všechny další údaje budou od tohoto okamžiku chybné až do opětovné inicializace celého systému.

Činnost rekonstruktoru ukazuje následující funkce:
unsigned char OldValues[7];
signed char Leaders[7]={0,0,0,0,0,0,0};
int check_channel(int ch)
{
int j;
j=read_channel(ch);
if(abs(j-OldValues[ch])>128)
	{
        if(j>OldValues[ch]) Leaders[ch]-=1;
        	else Leaders[ch]+=1;
        }
OldValues[ch]=j;
return(((256*Leaders[ch]+j)));
}

10.2.2.	

	Jedná se o registry dvou programovatelných čítačů/ časovačů realizovaných obvodem 8253. Adresy obvodů jsou mapovány do rozsahu 0-7 externí sběrnice. Všechny z těchto níže popsaných registrů jsou určeny pouze pro zápis. Při čtení je přečten obsah vstupního registru umístěného na stejné adrese.

Obsazení vstupních registrů:
Číslo	Význam registru	
0	 Podélná cyklika	
1	 Příčná cyklika	
2	 Kolektivní řízení	
3	  CWR řídící registr 1. čítače	
4	 Nastavení listů ocasního rotoru	
5	 Výkon motoru	
6	  -	
7	 CWR řídící registr 2. čítače	

	Je třeba si dát pozor na skutečnost, že vnitřní registry jsou 16 bitové. Zápis do obou částí se provádí pomocí dvou po sobě následujících sběrnicových cyklů. Vzhledem ke zvolenému režimu činnosti musí být vyšší polovina registru vždy naplněna hodnotou 1 a nižší polovina určuje pohyb akčního členu. Délka výstupního pulsu se pohybuje od 1mS do 2mS a řídící hodinový kmitočet je nastaven na 256kHz. 

Způsob zápisu do registru ukazuje následující funkce:
void write_channel(char kanal,char hodnota)
{
kanal=trans[kanal];
outp(baze+14,0xC0|kanal);
outp(baze+13,hodnota);
outp(baze+14,0x40|kanal);
outp(baze+14,0xC0|kanal);
outp(baze+13,1);
outp(baze+14,0x40|kanal);
outp(baze+14,0xC0|kanal);
}

	Komunikace s výstupními registry pracuje korektně až po nutné inicializaci řídících registrů! Při používání driverů je tato činnost prováděna automaticky, ale při testování modelu z jiných programovacích jazyků nemůže být vynechána. Po jedné inicializaci pracují registry korektně až do výpadku napájecího napětí.
	Inicializaci je nutné provést u všech 6 registrů. Řídící registry pracují v režimu 1 v binárním módu. V režimu 1 se celý obvod chová jako programovatelný generátor monostabilního impulsu. Dále je nastaveno přepisování celého 16 bitového registru prováděné při každé operaci čtení nebo zápisu. Přepis registru je proveden během dvou sběrnicových cyklů. Při prvním je čtena nižší a při druhém vyšší slabika.
	Po inicializaci řídících registrů je velmi vhodné okamžitě nastavit ostatní registry časovačů na počáteční hodnoty. Nejkritičtější je registr výkonu motoru, který by měl být nastaven na nulovou hodnotu. Jinak by mohlo dojít k nežádoucímu vzlétnutí modelu následovaného pádem. Ani poslední 6 registr nesmí být opomenut, i přes to, že není využit. Při zapnutí v něm může zbýt v podstatě libovolná hodnota. Časový interval delší než je délka rámce přenosu způsobí rozpad synchronizace s následkem selhání celé komunikace! Synchronizace a dekódování je prováděno v továrně vyrobeném přijímači pro RC ovládané modely a její rozpad není možno ani programově detekovat. Na venek lze výše popisovanou situaci poznat podle trhavých náhodných pohybů ovládacích servomotorů.

O zápis do řídících registrů se stará funkce:
int write_ CWR(char kanal,char hodnota)
{
 outp(baze+14,0xC0|kanal);
 outp(baze+13,hodnota);
 outp(baze+14,0x40|kanal);
 if(inp(baze+6)!=hodnota) return(1);
 outp(baze+14,0xC0|kanal);
 return(0);
}

	V této funkci je navíc proveden test správné činnosti HW. Chyba je hlášena v případě špatného propojení datových kabelů. Úspěšné provedení tohoto testu však ještě nezaručuje skutečný zápis dat do řídícího registru.
	Při použití driveru jsou již všechny výše uvedené problémy ošetřeny a uživatel se nemusí zabývat jejich řešením.

10.3.	

	Driver pro helikoptéru v žádné své verzi nepodporuje DMA a s podporou DMA př enosu není počítáno ani pro další verze. Toto omezení je způsobeno sériovým přenosem dat mezi blokem snímačů a blokem registrů pro počítač.
	Popisy všech modifikátorů vylepšujících činnost driveru jsou platné pouze pro verzi 2.0 pod Windows. Driver pro DOS pracuje stále v režimu dílků od IRC snímačů. Na tuto nekompatibilitu upozorňuji při přechodu z jedné verze RT Toolboxu do druhé.

10.3.1.	

	Speciálním způsobem vyhodnocení se podařilo 4x zvýšit přesnost oproti nominální hodnotě. Na výstupu z RT driveru je výhodné mít údaje již normované do vhodného tvaru. Jako nejvýhodnější se mi jeví transformace úhlů do radiánů a délek do mm.
	V modelu trenažéru jsou však použity dva různé typy  IRC snímačů. Proto je potřeba každý sejmutý údaj transformovat příslušnou konstantou do správného tvaru.
alpha~=~{2*pi}over{4*540}*Dc~=~0.002908882*Dc~=~k sub 1*Dc#
alpha~=~{2*pi}over{4*512}*Dc~=~0.0030679615*Dc~=~k sub 2*Dc#
l~=~{pi*d}over{2*512}*Dc~=~{pi*35}over 1024*Dc~=~
0.107378655*Dc~=~k sub 3*Dc 
	Konstanta k1 platí pro snímač typu BZ (540 dílků/otáčku) a konstanta k2 pro typ B (512 dílků/otáčku). Vzdálenost vrtulníku od heliportu, tedy v podstatě délka vysunuté tyče, je měřena také IRC snímačem opatřeným snímacím kolečkem o φ35mm. Pro přepočet délky tyče platí konstanta k3. U snímače délky je přesnost 2x snížena, protože nemá smysl měřit s přesností větší než 0.1mm, kterou není schopna udržet ani mechanická část trenažéru.

10.3.2.	

10.3.2.1.	
	Ovladači zaváděnému do paměti může být předáno několik parametrů. Ty jsou určeny pro modifikaci jeho činnosti. Způsob předávání parametrů byl již rozebrán v kapitole Rozšíření funkcí rozhraní.
	Zde popisovaný ovladač umožňuje změnu pozice jednotlivých registrů a volbu transformace souřadného systému. Činnost je zjištěna podle délky modifikačního vektoru.
Délka vektoru	Význam jednotlivých položek	
0	 []	
1	 [režim]	
3	 [D/O_Hi,D/O_Lo,D/I]	
4	 [režim,D/O_Hi,D/O_Lo,D/I]	

	Všechny ostatní vektory předané v položce Option nemají na činnost ovladače vliv a jsou ovladačem ignorovány. Pouze při zadání chybné transformace nebude ovladač zaveden do paměti.
	Při inicializaci driveru je možné též nastavit bázovou adresu karty. Po jejím nastavení je provedena korekce adres komunikačních registrů. Nulová hodnota adresy má speciální význam. Sděluje ovladači, že není použita pro připojení karta  PCL-812. Informace o umístění portů jsou v takovém případě dodatečně definovány v položce Option. 

Kde:	režim	Způsob transformace souřadnic (viz následující kapitola).
	D/O_Hi,D/O_Lo,D/I	Přímá hodnota komunikačních portů.

10.3.2.2.	

Obr.  Konfigurace pomocí GUI

Obr.  Časová základna pro vysílač

	Středem zapojení příjmacího obvodu XRI je datová (8b) a adresová sběrnice (4b). Ke sběrnicím jsou připojeny paměťové registry, v nichž se uchovávají přijatá data. Nutnou součástí jsou dva přijímací obvody složené z majoritního filtru a přijímacího registru. Tyto obvody jsou stejné a liší se pouze adresou, na níž zapisují přijatá data (0 až 3 a 4 až 7). Přístup počítače je zajištěn přes takzvaný výstupní registr a vnější obvody, které byly popsány již dříve. Blokové zapojení je na .

Obr.   Časování sběrnice s požadavkem na přenos (využito jen v XRI)