A CI4A driver program

A driver program feladata, hogy kapcsolatot tartson a hardver és a vezérlő program(ok) között, úgy, hogy elfedje a viszonylag bonyolult hardverkezelési protokollt, egy egységes és egyszerű kezelő felületet biztosítva a vezérlő program írójának. A driver a vezérlő program felé két interfésszel rendelkezik. Az egyik az IO interfész, amin OUT parancsok és INPUT updatek közlekednek, a másik a CEI interfész amin vezérlő parancsokat adhatunk a hardvernek, és amin információkat és hibajelzéseket kapunk vissza. A legegyszerűbb és a leg szoftver és oprendszerfüggetlenebb interfész szerintem a TCP/IP ASCII TEXT. Ez megnyitja azt a lehetőséget, hogy a most egyelőre csak W2K, WXP oprendszereken futó driverhez bármilyen más oprendszerből kapcsolódhassunk különösebb nehézségek nélkül, az az például egy a munkahelyünkön futó REDHAT LINUX-ból python-ban írt script segítségével becsukhatjuk otthon a garázskaput. A TEXT interface-nek persze van egy hátránya is, mégpedig az, hogy a szövegekben levő információkat parszolni kell, és ezután az adatokat még valódi számmá is kell alakítani. Ez azonban minden programozónak a saját kedvenc programnyelvén történik, így valószínüleg nem okoz majd semmiféle nehézséget.
A driver program nemcsak az interfészeket biztosítja, és a kezelést egyszerűsíti, hanem egy ablakot is kitesz a képernyőre, melyben a hardver vizualizált képe látható. Itt a kártyákon nem csatlakozók vannak mint a valóságban, hanem ki és bemeneti értékek. A digitális csatornák LED szimbólumokkal jelzik az állapotukat. A motorok sebességei a szervók kitérései pedig százalékos számértékekekel kerülnek megjelenítésre.



A ci4adrv.exe nem klasszikus értelemben vett windows driver, még nem is service, így a vezérlő program futtatása elött kell elindítani. Indítás után megnyitja az IO és a CEI interfészt, majd felveszi a kapcsolatot a hardverrel, ekkor lekérdezi, hogy milyen kártyák melyik slotba vannak bedugva. Amint a hardver lekérdezése, az input scannelés és egyéb paraméterek beállítása megtörténik, a driver kész az adatok küldésére és fogadására. A drivernek van az alsó toolbar-on egy animált trayicon-ja, amelynek segítségével az ablakát rejthetjük, vagy elővarázsolhatjuk, illetve kiléphetünk belőle. A driver státuszbárján mindig kiírja, hogy az adott pillanatban milyen állapotban van. Ha akarod a program debug logot is ír, amiből a működésre vonatkozó további információkat nyerhetsz ki. A program ablakát a képernyőn tetszőleges helyre tolhatjuk, ezt a helyet illetve a kilépéskori rejtett állapotát a kilépés után is megjegyzi.

A program telepítése a gépedre rém egyszerű. Az installáláshoz rendszeradminisztrátori jogosultság szükséges. Húzd le a letöltések oldalról a ci4adrvinstall.zip állományt, csomagold ki, és indítsd el a ci4adrvinstall.exe-t. Amikor a program elindult, a következő ablakot jeleníti meg:



Ebben az ablakban kiválaszthatod, hogy milyen indítási lehetőségeket csináljon (desktop icon és/vagy Startmenu item), a Select path nál megadhatod, hogy a program hova installálódjon, ha a default programs könyvtárad nem felel meg. Az Install gomb megnyomásával egy újabb ablakot kapsz, ezen nyomon követheted az installálás menetét:



A felinstallált cuccokat szép zöld pipa jelzi, ha nem kértél desktop icon-t vagy Startmenu item-et, akkor ezek elött fekete X látható. Ha az installálás sikeres akkor az "Installation is complete. Ready to use." felirat jelenik meg az alsó hosszú gomb belsejében. A gomb megnyomásával az install program kilép. Ha az "Installation is unsuccessful" felirat tűnik elő, akkor valami hiba történt. Legtöbbször a hiba oka az, hogy vagy nem voltál rendszeradminisztrátor, vagy a megadott könyvtár jogosultságai nem megfelelőek, vagy nincs legalább 500 Kbyte szabad hely a gépeden.

A driver telepítése után a megadott telepítési könyvtárban keletkezik egy ci4a.cfg nevű file. Ez az a nyúlfarknyi konfiguráció, ami tartalmazza a hálózati kapcsolatokat a hardver illetve a vezérlő program irányába, valamint itt lehet beállítani a debuggolást is. Felépítése a következő:

Ebből kiderül, hogy a driver kliensként csatlakozik a hardverre, és szerver socketeket nyit a vezérlő program számára. Ez az első verzió pillanatnyilag egy konnekciót fogad el, tehát egyszerre csak egy vezérlő program használhatja az interfészeket. A [HARDWARE] IP_ADDRESS és a [DRIVER] IO_PORT valamint CEI_PORT paraméterek szabadon átállíthatók. A [HARDWARE] PORT paraméterét csak akkor szabad piszkálni, ha a DS manager segítségével azt a LAN modulban is átállítottuk. A [SOFTWARE] DEBUG paraméterébe ha ON-t írsz, akkor debug log fog keletkezni a program futása közben. a LOGNAME-ben kell megadni a log nevét és elérési útját. A letöltések oldalon megtalálod a tail.zip állományt ami tartalmazza a tail.exe nevű programot, amivel a debug log real-time olvasható.

A telepítő feltesz egy hardver szimulátort is, erről bővebben a 4. pontban olvashatsz.

A hardverrel való kapcsolattatásra a driver porgramon keresztül nyitott két kommunikációs interfész szolgál.

Az IO (INPUT, OUTPUT) interfészen keresztűl frissithetjük a hardver fizikai kimeneteit, illetve a vezérlő programunk bemenetét. A hardverben összesen 8 slot van, ezekbe egy-egy kártya dugható. Minden kártyán 12 kimeneti és 12 bemeneti blokk van. Egy ilyen blokk tulajdonképpen egy 8 bites tároló. A kártyák csak a valódi fizikai ki és bemeneteiknek megfelelő számú blokkot használják a lehetséges 12-ből. Van olyan kártya ami bitenként értelmezi a blokkot, van olyan ami egészben használja el.
Ehhez az adatmegadási módhoz egy könnyen parszolható fix hosszúságú parancs string szolgál, aminek a felépítése a következő:

Ahol S B V chr(13) fixen mindig ott vannak a stringben. A chr(13) egyetlen lezáró karakter (C és unix rajongóknak \r). A paraméterek jelentése pedig a következő:

• n annak a slotnak a száma amiben levő kártyára hivatkozunk (értéke 0..7 lehet)
• d az adatáramlás iránya a hardver szemszögéből (értéke kimenet esetén O, bemenet esetén I)
• bb annak blokknak a száma aminek az értékét írni vagy olvasni akarjuk (értéke 01..12 lehet)
• vvv a ki vagy bemenet konkrét értéke (000..255 lehet)

Nézzünk egy példát. Ha az első slot-ban van egy DIO kártya, aminek egy led van az OUT1 kimenetére bekötve, és ezt be akarod kapcsolni, akkor az S0OB01V002 ha ki, akkor az S0OB01V000 parancsstringet kell küldened. Ha ugyanennek a kártyának az IN2 bemenetére egy mikrokapcsolót kötöttél és megnyomod, akkor az S0IB01V004 stringet kapod a driver felöl. Ha a harmadik slot-ban van egy SC kártya, és annak az SO7 kimenetére kötött RC szervót középállásba akarod tekerni, akkor az S2OB07V128 parancsstringet kell küldened. / Természetesen mindegyik végén ott a lezáró karakter is, csak az nem látszik. :) /
A példákból asszem kitűnik, hogy logikusan sorban használjuk fel a ki és bemeneti blokkokat, illetve az azokban elhelyezkedő biteket is. Sajnos a sorszámozás nem konzekvens (történelmi okokból) de ha megjegyezzük hogy a slot-oknál nullával, a blokkoknál egyel, a blokkok bitjeinél meg szintén nullával kezdődik, akkor baj nem lehet.

A CEI (COMMAND, ERROR, INFO) interfészen keresztül adhatunk vezérlő parancsokat a drivernek a hardver alaplapnak és egyes kártyáknak, itt kapunk információkat a hardver működési állapotáról, és a hibákat a vezérlő program itt tudja nyomon követni. Használata nem kötelező, de elkerülhetetlen a komolyabb vezérlések esetén, amelyek már kezdeni tudnak valamit az innen érkező információkkal (ilyen pl. a hardwer lekapcsolódása a hálózatról). A CEI interfészen érkező információk kategóriákba vannak sorolva ezzel megkönnyítve a parszolásukat. A kategóriák a következők:

• INF: működési státuszinformáció
• ERR: működési hiba
• CER: parancs hiba
• CAN: parancs válasz

Minden válaszsor végén van chr(10)chr(13) / unixosoknak \r\n /, így akár egy winfosos telnet ablakból is használhatjuk.

A drivernek kiadható parancsok:

• GETWORKSTATUS Ezzel tudjuk megnézni, hogy a driver normálisan működik-e. Nyilván, ha NOT WORKING állapotban van, akkor hiába adunk neki bármilyen kimenetváltoztatást az IO interfészén keresztül, azt úgy sem tudja leküldeni a hardvernek. Lehetséges válaszok: INTERFACE WORKING, INTERFACE NOT WORKING



• GETSLOTMAP Ezzel tudjuk lekérdezni, hogy melyik slotban milyen kártyák helyezkednek el. Válasz a kártyák típusa slotonként, illetve empty ha a slot üres. Pl.:
  S0=DIO Card,S1=DMC Card, S2=SC Card, S3=EMPTY, S4=EMPTY, S5=EMPTY, S6=EMPTY, S7=EMPTY

A hardver alaplapnak kiadható parancsok:

• STOPSCAN Megállítja az inputok scannelését. Erre akkor lehet szükség, ha inputot egyáltalán nem fogadunk vagy csak az egyik kártyáról akarunk fogadni. Válasz: SCAN STOPPED



• STARTSCAN Elindítja az inputok scannelését. Válasz: SCAN STARTED



• SELECTSLOT:n Ezzel lehet az egyik slotban levő kártyát állandó bemenetnek definiálni. Erre akkor lehet szükség, ha a mondjuk logikai analizátort készítünk egy input kártya segítségével és számit a baromi gyors olvasási sebesség. Az n paraméter a slot száma. Válasz: SLOT SELECTED



• SETSCANTIME:hhhh Ezzel lehet beállítani az inputkártyák scannelésének sebességét. A hhhh egy hexa szám, ami ha minél kisebb annál kevesebb idő telik el az inputok adásengedélyezése között. Válasz: SCANTIME SET OK



• RECONFIGAUT Ha a fenti parancsokkal sikerült teljesen szétcincálni az optimális beállításokat, akkor kell ezt használni. Lekérdezi a slotokat, beállítja a legmegfelelőbb scantime-ot, és el is indítja a scannelést. Válasz: START RECONFIG

Az SC kártyának kiadható parancs:

• SETPULSEWIDTH:n; m, m, m, m, m, m, m, m Az RC szervó teljes kitérése attól függ, hogy mekkora maximális impulzus szélességet kap a bemenetén. Ezzel a paranccsal lehet három előre definiált érték közül kiválasztani a legmegfelelőbbet. Az n paraméter a slot száma amiben az SC kártya van, m pedig csatornánként beállitható (mind a nyolc csatornára lehet más ás más) és értéke 1 2 vagy 3 lehet. Az 1 a legkisebb, a 3 a legnagyobb impulzus szélességnek felel meg. A default beállítás 2. Válasz: SC PULSEWITH SET OK ha a beállítás megtörtént, hibajelzés ha valami nem stimmel.

Bejövő információk:

• HW CONNECTED információt akkor kapunk, amikor a driver rákonnektált a hardverre



• HW DISCONNECTED információt akkor kapunk, amikor a driver lekapcsolódott a hardverről



• INIT IN PROGRESS információt akkor kapunk, amikor a hardver inicializálási folyamata megkezdődik



• INTERFACE WORKING információt akkor kapunk, amikor a driver mindkét irányban működésre kész

Bejövő hibajelzések:

• HW SOCKET ERROR hibajelzést akkor kapunk, amikor a driver hardver netkapcsolatban valami hiba lép fel



• COMMAND NOT KNOWN hibajelzést akkor kapunk, amikor a driver számára ismeretlen paranccsal próbálkozunk a CEI interfészen



• INVALID OUT ADDRESS hibajelzést akkor kapunk, amikor a driver számára értelmezhetetlen kimeneti slot címet adtunk meg az IO interfészen



• INVALID OUT BLOCKNUMBER hibajelzést akkor kapunk, amikor a driver számára értelmezhetetlen kimeneti blokkszámot adtunk meg az IO interfészen



• INVALID OUT VALUE hibajelzést akkor kapunk, amikor a driver számára értelmezhetetlen kimeneti értéket adtunk meg az IO interfészen



• INVALID PARAMETER hibajelzést akkor kapunk, amikor a driver számára olyan IO vagy CEI parancsot adtunk, amit hibásan paraméterezünk fel



• NOT SC CARD hibajelzést akkor kapunk, amikor nem SC kártyán akarunk impulzusszélességet beállítani

Kedvcsinálónak elkészült egy hardver szimulátor is, ami települ a driver installálásával együtt. Ez a szimulátor eljátsza, hogy ő a CI4A hardver, így a driver azt hiszi, hogy egy valódi dobozzal van összeköttetésben és így minden funkciója működik. A szimulátor kártyái csak bemeneteket tartalmaznak, hiszen a kimenetek értékét a driver GUI-ján úgy is látod. A kimenetek duplikálásának csak akkor volna értelme, ha egy 3D-s szimulátor készülne el, ami egy kis fizikával fűszerezve valóban mutatja a szervókat, meg a motorokat is működés közben. Ehhez pedig grafikus, ODE vagy PhysX mahinátor, meg egy DirectX guru is kell, én pedig sajnos egyik sem vagyok. Amit viszont biztosítani tudok ezzel a kis nyamvadt szimulátorral az az, hogy a bemeneteket lehet vele piszkálni. Egyelőre csak a DIO kártya az amin valamiféle inputok vannak. Ezeket a digit inputokat buttonok és checkboxok helyettesítik. A buttonok a mikronyomógombokat, a checkboxok a mikrokapcsolókat szimbolizálják, és virtuálisan csatornánként párhuzamosan vannak kötve. A gombok nyomogatásával tehát valódi inputot vihetsz a rendszerbe.

A szimulátorhoz is tartozik egy kis konfig file, ami leírja, hogy melyik portot nyitja meg a driver számára, illetve, hogy melyik slotban milyen kártyát akarsz elhelyezni. A lehetséges kártyák pillanatnyilag:

• DIO Card      - digitális IO kártya
• DMC Card      - DC motor vezérlő kártya
• SC Card       - RC szervó vezérlő kártya

A telepítéskor a megadott telepítési könyvtárban létrejövő hwsim.cfg nevű alap konfigurációs file pedig így néz ki:

 [DRIVER]
 PORT=12345

 [SLOT CONFIGURATION]
 SLOT0=DIO Card
 SLOT1=DMC Card
 SLOT2=SC Card

Ebben a konfigurációban a szimulátor ablaka ilyen lesz:



Ha a kártyákat másik sorrendben akarod beledugdosni, vagy egyik-másik kártyából több is kell, akkor írd át annak megfelelően a konfigurációt és a hardverszimulátor olyan lesz mint DévényiTibiBácsi, és teljesíti a kívánságodat. Mondjuk egy SC két DMC és három DIO kártya esetén a konfiguráció:

 [DRIVER]
 PORT=12345

 [SLOT CONFIGURATION]
 SLOT0=SC Card
 SLOT1=DMC Card
 SLOT2=DMC Card
 SLOT3=DIO Card
 SLOT4=DIO Card
 SLOT5=DIO Card

A hozzá tartozó szimulált kép így néz ki:



Ezt a hardver kombinációt meg így látja a driver:

A drivernek biztos nem ez lesz az utolsó verziója. Ez amolyan bemutató, vagy inkább ellenőrző jellegű programocska aminek egy igazi célja van: a használatából derüljön ki, hogy a koncepció valóban működőképes. Nyilván rengeteg ötletem van még a továbbfejlesztésre, amik idő hiányában egyelőre váratnak magukra. Minden esetre meg kéne ezt írni igazi winfos driverként, unixra device drivernek, sokkal okosabbá lehetne tenni az interfészeket, több felhasználót (vezérlő szoftvert) is kiszolgálhatna egyszerre, meg ilyesmik. Biztos rejtett bugok is vannak még benne, amik az én teszteléseim során eddig nem jöttek elő, ezeket is idővel ki kell majd írtani belőle.