Műszervezérlés - irányok 2.

Sokminden (hívhatjuk semminek is) történt mióta utoljára írtam a műszervezérlő alkalmazásról.

Név

Nem szeretem a random neveket amiket ennek a rendszernek adtam idáig. Nem látszott, éreztem professzionálisnak. Végülis találtam neki nevet: MeasureFlow

Regisztráltam egy domaint is hozzá:

measureflow.org

(még nincs rajta semmi)

Készült egy github és egy gitlab csoport:

https://github.com/MeasureFlow

https://gitlab.com/MeasureFlow

Szoftver

Azt hiszem (legalábbis részben) megvan az irány. A szoftver plug-in alapú volt idáig, de más szempontból nem volt moduláris. Úgy döntöttem, hogy architekturálisan szétválasztom a frontend-et és a backend-et. A backend egy minimális REST API dotnet 6 alapon. A frontend még mindig kérdéses.

Elkezdtem a backend fejlesztését. A kódbázis nem ígényel túl sok portolási munkát amíg csak egy műszer folyamatos méréséről beszélünk és nem valami komplex munkafolyamatról. Tehát a dolog nagyjából már működik (csak az utolsó kódrészleteket még nem próbáltam ki)

Hardver

A megrendelt panelek megérkeztek (mind az USB-GPIB mind az USB-RS232). Voltam olyan szerencsés, hogy ebben a chiphiányos időszakban találtam 10db ATMEGA32U4-et egy helyi kereskedőnél.

Egyelőre még nem volt időm beforrasztani és tesztelni. Amúgyis, még kell rá firmware, szóval amíg a firmware-el kapcsolatos kérdéseket nem oldom meg, az egész használhatatlan.

Firmware

Elérkeztünk arra a pontra, ami jelenleg a legnagyobb fejfájást okozza az egész képben.

Az elmúlt két hétben, amikor időm volt ezzel foglalkozni, próbáltam megérteni azt az USBTMC implementációt, amit találtam a github-on. Nem lettem nagy rajongója. Sajnos nem egy megfelelő, újrahasznosítható USBTMC implementáció, ami betartaná a LUFA tervezési elveit. Egy félkész, nem túl jó LUFA demo-n alapul, rosszul kezeli a az AVR lábait, nagyon fura a konfiguráció kezelése (A szabványban nem létező, az USBTMC-n kívüli konfigról beszélek).

Próbáltam megérten, hogyan működik, hogyan tudom átültetni a saját hardveremre. Eredetileg, csak a lábkiosztást akartam megváltoztatni a saját terveimhez, de már tudom, hogy nem állhatok meg itt.

A múlt vasárnap, végül rájöttem, hogy mi a legnagyobb probléma az egész dologgal. Sokkoló felismerés volt. A probléma gyökere, nem a megvalósításban keresendő, hanem a szabványban magában.

A szabványosító testület teljesen másképp gondolkodott mint én.

Az ő céljuk: kialakítani egy olyan megoldást ami műszer oldalon be tudja "csomagolni" a meglévő GPIB csatolót az USB-be, időt adva a natív USBTMC megvalósítás előállítására.

Az én célom: kialakítani egy olyan megoldást ami a (akár több) műszer GPIB csatolója és az USB közé tehető, becsomagolva a meglévő GPIB csatolót. Ezen túl kezeli a műszer oldalon a másodlagos címzést is.

Első olvasásra talán nem tűnik úgy, hogy túl sok különbség lenne a kettő között. A különbség, hogy a szabvány nem tartalmaz semmit ami a GPIB címzésre vonatkozik. Feltételezi, hogy az USB488 kiterjesztéssel rendelkező USBTMC eszköz, egy USB eszközként jelenik meg és nem többként.

Ha másodlagos GPIB címzés nélküli eszközökkel szeretnék csak foglalkozni, akkor talán együtt lehetne élni ezzel, de sajnos, nem ez a helyzet. Vannak VXI kereteim, valamint egy moduláris tápegységem másodlagos címzéssel.

Ha kicsit tovább ások kiderül, hogy sem a HP (Agilent/Keysight), sem a National Instruments nem valósította meg az USB488-al kiegészített USBTMC szabványt a saját USB-GPIB csatolóiban (HP 82357B, NI GPIB-USB-HS). Az egyikük "standard base device"-t használ a másik meg "vendor specific device"-t. Ezek meg cégen belüli zárt megoldások.

Visszatérve az eszközre magára. El kell döntenem, milyen irányba haladjak tovább a firmware fejlesztéssel. Itt vannak azok az irányok amik elképzelhetőek:

1. Újraindítom az USB-CDC alapú megvalósításomat (Prologix parancskészlet alapú). Ennek megvannak a maga hátrányai, mint a CDC lassabb mint a natív USB "bulk" végpontok, a PC oldalon portolnom kell a saját meghajtómat a MeasureFlow alá, az eredmény egyetlen meglévő PCs software csomaggal sem lesz kompatibilis.
2. Az AR488 firmware-t használom. A fenti hátrányokon túl, még a másodlagos címzést is meg kell valósítanom, az ő kódbázisukon miután az ott még nincs meg.
3. Lemásolni a HP vagy az NI csatoló működését. Ez több szempontból is problémás. Rengeteg USB kommunkáció elemzéssel, jogi problémákkal, stb. jár.
4. Fejleszteni egy USB kompozit eszközt (meg kell nézni egy móricka programban, hogy a Keysight IO library kezeli-e). Szóval a koncepció: fogni egy CDC eszközt amin keresztül lehet az egész cuccot vezérelni (úgy mint manuális beállítások, vagy SCPI emuláció). Csinálni dinamikusan készülő USBTMC eszközt minden GPIB műszerhez (elsődleges és másodlagos cím), ami vagy az automatikus felderítésen, vagy a CDC manuális beállításokon alapul.

Egyelőre ez az utolsó tűnik a célnak, ha nem futok bele valami megoldhatatlan gondba.