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.

HP E1300A előlapi csatlakozók 1.

Kerültél-e valaha olyan helyzetbe, hogy azt hitted a projectről, egyszerű lesz és pillanatok alatt megcsinálod, majd egyszercsak rájöttél, hogy rengeteg idődet ölted bele?

Ez egy ilyen project.

De vissza az elejére. Azon dolgozom, hogy javítsam, programot írjak a HP E1300A VXI kereteimhez (konkrétan 3 db van belőle). Az előlap kinézete egy vicc. Egy nagy bézs panel, amin nagyjából nincs semmi.

Ezen túl, még az is bajom vele, hogy a beépített multiméterének, csak a hátlapon van csatlakozója.

Semmi olyan módosítást sem szeretnék tenni a szerkezeten, ami nem visszafordítható, de szeretnék csatlakozókat az előlapra.

Amiben nagyjából teljesen biztos vagyok, hogy a floppy meghajtó helyét semmire sem fogom használni. Az előlapja, meg egy mozdulattal kipattintható, és lehet tenni valamit a helyére.

Tehát terveztem egy kis panelt, előlapot, szerelőkeretet a helyére. Hiányoztak alkatrészek, 3D modellek a KiCAD-ból, először használtam a FreeCAD-et a végső összeszereléshez, csináltam egy miliméteres hibát, amitől nem állt össze az egész és alig találtam meg, belefutottam még egy rakás mindenféle problémába. Ez az eredetileg egy esete összedobom projectből, csinált egy hetes szenvedést.

Itt az eredmény:

Azt hiszem erről sok több dolgot nem lehet írni.

A tervek, itt találhatóak:

https://gitlab.com/suf/suf-electronics-E1326-Front

Hangosan gondolkodom. Vajon van-e igény erre a modulra? Vajon ez lehet-e pár év után újra a próbálkozásom arra, hogy áruljak valamit mondjuk az eBay-en vagy a Tindie-n?

HP E1300A - Csúnya bukta

Az elmúlt napokban a műszervezérlő szoftveremen dolgoztam. Ki akartam próbálni, amit összeraktam SCPI képes eszközön is (mostanában leginkább egy Keithley 199 multimétert használok a tesztekhez) .

Az első SCPI képes eszköz ami hirtelen a kezembe akadt az egy HP E1300A B méretű VXI keret volt multiméterrel és relékártyával (ebből a cuccból van három darabom).

Először ki akartam takarítani, javítani, ha szükséges.

(Olvasd tovább, a szöveg folytatódik az első adag kép után)

Minden letakarítva, a halott akksi csomagot lecseréltem egy elemtartóra. Ami maradt és még cserélnem kéne, az a Papst ventilátor. Az eredeti típus még ma is gyártásban van, de az árá elképesztő. 20.000Ft-ot kérnek érte (Ezt a két E1300A keretet ajándékba kaptam, van mégegy azért kemény 5000Ft-ot fizettem). Ennek a ventillátornak a zajszintje 36dB, ha új. Találtam egy Noctua modelt, ami azonos légszállítás mellett kemény 17dB-t produkál. Tudom, hogy ez nem "ipari" kivitel, de ezek az eszközök, csak ritkán lesznek használva a műhelyemben, tehát nekem ez a ventillátor is pont jó lesz bele. Egyenlőre még nem cseréltem le.

Csak próbaképpen bekötöttem a cuccot ráraktam egy GPIB adaptert és kipróbáltam, hogy tudok-e beszélgetni vele. Minden rendben levőnek tűnt az összeszerelés után.

Kikapcsoltam (!!!) a cuccot, elmentem a mosdóba. Onnan valami furcsa zajt hallottam. Vissza a szobába. Sűrű füst dőlt ki belőle és iszony büdös volt. Kirántottam a hálózati kábelt és nyomokban sem értettem, hogy mi történt.

Szétszedtem az egészet megint:

A szűrő a hálózati aljzatban kb. felrobbant.

Ez arra enged következtetni, hogy talán a cuccnak nincs további baja.

Rendeltem új csatlakozót, majd befejezem az összeszerelést, ha megjött.

Műszervezérlés - irányok

 

A dolgok változnak.

Amikor újrakezdtem a műszervezérlő projectemet, világos volt az irány előttem. Majd rájöttem pár dologra, ami arra késztetett, hogy újragondoljam a projectet, és hogy az egészet én hogyan látom.

Először is, ezt találtam: https://github.com/xyphro/UsbGpib

Ez pontosan az amire szükségem van. 90%-ban biztos vagyok, hogy a firmware amit fejlesztettem a saját panelemhez szükségtelen (meglepetések persze érhetnek, amikor ezt a saját panelemre a és a szoftverkörnyezetemhez próbálom adaptálni, de ennek kicsi az esélye).

A vezérlő szoftverembe bekerült egy plusz réteg a VISA fölé (alapvetően a soros-GPIB megoldásom miatt). Gondolkodtam rajta, hogy ez esetleg most kidobható lenne, de rájöttem, hogy vannak eszközök amik HID-t, vagy saját protokolt használnak, amiket nem tudok a VISA esernyő alá begyömöszölni.

Van egy nagy dilemmám a további fejlesztéssel kapcsolatban. A desktop műszervezérlő alkalmazásra gondolok itt.

A helyzet:

Ma a szoftver fejlesztés világában minden a mobilról a webről és a felhőről szól. Teljesen tiszta, hogy a világ ebbe az irányba halad. Még én is DevOps szakiként, felhő alapú web projecteken dolgozom, már jó pár éve.

De...

Mindig az a zavaró "de".

De a műszervezérlés világa, egy kicsit különbözik. Amit látok, érzek a műszer vezérlő és megjelenítő szoftverekről, hogy elsősorban nem web technológiák köré épültek. Ezek, változatlanul desktop alkalmazások. Én ezt nem akarom megváltoztatni. Kényelmesebb ezeket így használni, egyszerűbb közvetlenül kommunikálni a hardverrel, stb.

A saját szoftverem C#-ban kezdtem el fejleszteni .NET Framework-ön Visual Studioban, WinForms-al. Ez az a platform, amiben a legtöbb saját tapasztalatom van. Ha megtartom a lusta hozzáállásom, csak egyszerűen folytatom ezt és elfelejtem a dilemmám. Alapvetően magamnak fejlesztek, így nem igazán kell törődnöm ezzel.

De valami állandóan viszket a fejemben. A fenti technológia kezd túlhaladott lenni. A saját projectjeimet (a feladat megoldása mellett) tanulásra is használom. Szóval a kérdés: Milyen irányba menjek?

A másik dolog ami izgat ebben, a Linux. Kéne egy több platformon futó eszközt írnom? Saját magamnak, nem feltétlenül. Ha más is akarja használni ezt, akkor ez szükségessé válhat.

A lehetőségek, amiket látok:

• Tartsam ezt meg, folytassam a fejlesztést és csak felejtsem el a dilemmám?
• Költöztessem át a .NET 6, WPF, MVVM megoldásra, hogy újabb platformom legyen? Ez még mindige nem jelent Linux platformot, csak remélhetem, hogy valaki csinál egy használható verziót a MAUI-ból Linuxra.
• Költözzek át .NET 6-ra és használjak valami harmadik gyártó UI-t (Avalonia, UNO Platform, QT, vagy más)?
• Felejtsem el az egész C# és .NET vonalat és használjak mást?
• A Python-hoz van a PyVISA műszervezérló könyvtár. Nem igazán szeretem a Python-t és még mindig kell találnom valami UI-t.
• A Java-hoz vannak desktop framework-ök, de mi lesz a műszerekkel?
• A Node.js-hez ott az Electron, de a VISA-t támogató könyvtárak minősége, eléggé kérdőjeles.
• Bármi más ami nem jutott eszembe?

Próbáltam összegyűjteni (legalább részben) a követelményeket:

• Natív desktop alkalmazás
• Hardver kommunikáció (Soros, USB-HID, IVI réteg, mint a Keysight IO Library Suite, USB-TMC, stb.)
• Grafikai elemek - Dialógus ablakok, Data grid, szöveg mezők/vezérlők, és ami a legfontosabb, diagrammok.
• Valami plug-in architektúra (plugin kell a műszerekhez, kommunikációs platformokhoz, stb. - az egésznek bővíthetőnek kell maradnia)
• Hálózat kezelés
• Fájl rendszer kezelés

Biztos van még más is. Egyenlőre ezeket látom.

Szóval, ha vannak gondolataid erről, kérlek oszd meg velem!

HP 8903B Audio Analyzer - Javítás 1.

Hónapokkal ezelőtt elkezdtem dolgozni a műszervezérlő programomon (http://it-pro-hu.blogspot.com/2020/09/muszer-vezerles-1-kezdetek.html). Amikor az audio analizátorral kapcsolatos dolgok elkezdtek működni, akkor derült ki, hogy a készülék már nem teljesíti a saját specifikációját, tehát nem igazán tudok tovább dolgozni vele, ahogy szerettem volna. Ezzel az egész projectet félretettem egy időre.

Most úgy érzem, hogy itt az ideje a folytatásnak.

Az eszköz funkcionálisan hibátlan, csak némi kalibrációt (esetleg kondi cserét igényel). A kalibrációhoz szükségem lenne néhány kiemelő kártyára, hogy tudjak mérni a paneleken. Az eredeti kiemelő kártyák (08901-60084, 08901-60085, 08903-60018) beszerezhetetlenek. Az utolsóhoz még rajz sem igazán létezik. Miután a vezérlésnek nincs baja, ez utolsó kártya nélkül meg tudom oldani a dolgokat (az a processzor kártyához kellene).

Miután a kártyák nem kaphatóak, rendeltem megfelelő 44 és a 30 pólusú 3.96mm osztású élcsatlakozókat az aliexpressen, és terveztem kiemelő kártyákat. Hogy a munkát könnyebbé tegyem, még két dolog rákerült a kártyákra:

Egy plusz 44 (33) pólusú 2,54mm-es csatlakozó, hogy könnyebb legyen mérni a buszon.

Egy plusz 44 (33) pólusú csatlakozó, hogy a kártyákat 90 (a 180 helyett) fokos szögben is be lehessen rakni (nem tudom, van-e értelme, meglátjuk)

A panelek, már a jlcpcb-nél vannak gyártásra:

A fentieken túl, még fenntartásaim vannak az EPROM-okban lévő program hosszútávú stabilitásával kapcsolatban. Sajnos ezeket a 2k x 8-as EPROM-ok a szokásos beszállítóknál már nem kaphatóak. Tehát az eBay-ről rendeltem egy marékkal.

Várom, hogy megjöjjenek a dolgok, hogy tudjam folytatni.

Műszer vezérlés 1. - A kezdetek

Konvergencia

Ez a szó jut eszembe, amikor erre a projectre gondolok.

Úgy érzem, hogy ez az a pont ahol a műhely építés, műszer gyűjtés, mérő interfész (GP-IB) építés és mérés erőfeszítéseim összekapcsolódnak, hogy valami magasabb szintű képességet produkáljanak a dolgok amikkel rendelkezem.

Hol is kezdődött?

Gyerekkoromban audio cuccokat építettem. Később (nem kis kihagyás után) újraindult ez a hobbi, az volt a terv, hogy folytatom a munkát az audio elektronikán. Nem volt mérőeszközöm (egy döglődő digitális multimétert leszámítva). Építeni akartam, ahelyett, hogy veszek valamit. Ez térített el a digitális elektronika irányába.

Később rengeteg műszert vettem (kattant idióta). Egy ponton vettem egy HP 8903B audio analizátort, hogy képes legyek grafikonokat rajzolni az erősítők képességeiről. A gond ott volt, hogy a XY rögzítőt csatlakoztatni számomra, egy igencsak túlhaladott megoldás lett volna. Ahhoz, hogy számítógépre kösd, meg szükséged van egy interfészre. Nem voltam elégedett a jelenleg kapható GP-IB interfészekkel, itt született meg a saját tervezésű GP-IB csatolóm.

Később kerestem vezérlő szoftvert a HP 8903B-hez, és nem szerettem amit találtam. Ezen túl még az is a fejemben volt, hogy más műszereimet is hozzákössem a PChez, miután más ötelteim is vannak, nem csak az audio analizátor vezérlése. Néhány kísérlet után megszületett a "Virtual Instrument" projectem.

Két év után, rengeteg szenvedéssel, újrakezdéssel és újratervezéssel, úgy tűnik, a rendszer elkezdett működni.

A koncepció:

Valami rugalmas megoldást akartam, aminek a használata, ugyanakkor nem igyényel programozási ismereteket. Valami olyasmit akartam, ami mérési sorozatokhoz használható, és működik a saját cuccaim nagy részével, kompatibilis sokféle kommunikációs interfésszel. Az egész rendszernek beépülő modulokon kell alapulnia, a jövőbeli fejleszthetőség érdekében.

Létrehoztam pár objektum típust a fentiekhez:

Vezérlő (controller):

Valami ami az egészet viszi a hátán. Elindítja a mérési sorozatot, esetleg még valami alapadatot is produkál. Egyenlőre ezek készültek el:

- Folyamatos vezérlő (continuous controller): Csak lefuttatja a méréseket egymás után, majd újra és újra, amíg meg nem állítod. Ez a szokásos működési módja a legtöbb műszernek, mint pl. a multimétereknek.

- Single shot vezérlő (képtelen vagyok értelmes magyar nevet találni neki): Lefuttat egyetlen mérést, majd megáll.

- Változó vezérlő (variable controller): Beállítható a mérési sorozatokhoz. Ad egy vagy lineáris, vagy logaritmikus forrás adat sorozatot. Eredetileg a HP8903-ra gondolva készült. Az első kísérletekben logaritmikus frekvencia forrásként használtam a beépített szinusz generátorhoz.

Műszer (instrument):

Eszköz (tipikusan műszer), ami mér valamit. Képes a láncban korábbi mérés eredményét használni, és/vagy mérési eredményt produkálni a láncban utána lévőknek.

Eddig két műszer típus készült el: HP8903 Audio Analizátor, HP3478A 5,5 digites multiméter (a többi folyamatban)

A műszerek minden esetben külső (szoftver) trigger üzemmódban működnek. Az ok: a fenti szoftver vezérlők intézik a mérést és nem a műszer belső vezérlése.

Szűrő (Filter):

Eredetileg arra terveztem, hogy eredményeket lehessen velük szűrni, matematikai számításokat végezni, adatokat konvertálni. A fejlesztés közben kiderült, hogy ehhez hasonló funkciókra, a műszerek között is szükség van. Rájöttem, hogy a szűrő plug-in-ek külön tartása semmilyen hozzáadott értékkel sem rendelkezik.

A szűrő funkciótól meg fogok szabadulni és a szűrőket műszerként fogom létrehozni.

Cél (target):

Valami ami meg tud jeleníteni, vagy el tud menteni mért eredményeket. Jelenleg két cél eszköz érhető el:

- Digitális megjelenítő: ki tudja írni a mért értéket, továbbá minimum, maximum és átlag értéket is kijelez, változtatható helyiértékkel (pontossággal)

- Grafikon megjelenítő: A mért értéksorozatot grafikonként jeleníti meg, több különböző mérési sorozat megjelenítésére alkalmas, lineáris vagy logaritmikus skálát használva (még nincs teljesen kész)

Kapcsolatok (connections):

Ez nem része a mérési láncnak. Ez a műszerek és a PC közötti kommunikációs interfész. Ami jelenleg elérhető:

- AvrGPIB - Az én saját tervezésű GPIB csatolóm (a fejlesztésről írtam pár cikket korábban)

- IVI VISA - Az iparági szabvány csatoló. Én a Keysight szoftver könyvtárával és egy Keysight USB/GPIB csatolóval próbáltam. Ez egyenlőre még eléggé instabil. További fejlesztés szükséges.

- Soros - Ezt meg is valósítottam meg nem is. Az AvrGPIB ezt használja mint legalsó szoftver réteg, de közvetlenül egyenlőre próbáltam, így ilyenkor lehetnek vele gondok.

Tehát, itt tartok jelenleg. Kipróbáltam a HP 3478A-val:

Majd később a HP 8903B-vel is:

Ez csak egy váltakozó feszültségű szint mérés, a kimenet és a bemenet közvetlenül összekötve, 20-20000Hz-es pásztázás, 1V jelszint. Sajnos ezen látható némi hiba:

Némi módosítással a grafikon (még mindig nem végleges):

Látszik egy 2% körüli hiba. A műszer némi javításra szorul (minimum a táp kondenzátorok cseréjére).

Folytatni akarom a fejlesztést, hozzáadva további műszerek támogatását. Ezen túl is rengeteg ötletem van a program továbbfejlesztésére.

A kód C#.Net-ben készült Visual Studio 2019-el. A kód itt található:

https://gitlab.com/suf/suf-electronics-VirtualInstrument

Bárki akinek tetszik a project, van szabadideje, némi programozási tudása, és szeretne segíteni a fejlesztésben, jelentkezzen nálam, minden segítséget szívesen fogadok.

GP-IB 4.

Kilenc hónap. Ma napra pontosan kilenc hónappal ezelőtt írtam utoljára a GP-IB adapteremről (http://it-pro-hu.blogspot.com/2019/07/gp-ib-3.html). Nehéz szülés volt.
Büszkén jelentem be, mint apa a működő GP-IB interfész szoftverem. Még nőnie és tanulnia kell. A tudásából még hiányoznak képességek, mint a device üzemmód és a USBTMC.
Mind az apa:

Az anya:

És a gyermek:
https://gitlab.com/suf/suf-electronics-gpib

Jó formában vannak:

És várják hosszú és eredményes életét.

HP 3488A

Ez egy hosszú gondolatlánc lesz. Csak kövesd! :-)
Az egész egy képpel kezdődött a facebookon. Megláttam egy kétcsatornás analog Kenwood AC feszültségmérő műszert. Ez jól használható sztereo eszközök csatorna együttfutásának vizsgálatára. Tetszik a koncepció, de nem vagyok az analog műszerek nagy barátja.
Elkezdtem gondolkodni. Mi van, ha megfogom az egyik asztali multiméterem, írok hozzá valami PC programot a saját (még mindig fejlesztés alatt álló) GPIB USB adapterem köré, mellé téve, egy vezéreletlen mikrovezérlő alapú csatorna kapcsolót. Uff, ez gusztustalanul hangzik, ráadásul ez a bejegyzés nem is ennek a magyarázatáról szól. Csak, hogy értsd, valami ilyesmit fejlesztek és hamarosan publikálom.
Visszatérve az eredeti gondolathoz: Kiválasztottam az egyik HP 3478A 5,5 digites multiméterem a fenti projecthez. És itt felmerült egy pár dolog:

• Szükségem van egy jelválasztó kapcsolóra
• A 3478A kijelzője, egy minősíthetetlen hulladék a háttérvilágítás hiánya miatt
• Nem akarom a multiméter eredeti kijelzőjét kinyírni egy átalakítási kísérletben, ezért kerestem valami hasonlót és olcsóbbat.

Szokásom szerint körbenéztem az eBay-en. És nézd csak, mit találtam: két HP 3488A-t. Ezek tele vannak kártyákkal (általában csak üreseket lehet találni), €102-ért házhoz szállítva. Gyorsan meg is vettem.
Jó lesz gyakorolni a kijelző módosításhoz, ha működnek (az eladó hibásnak, teszteletlennek árulta), kapcsolóként is használható a fenti projecthez, és más célokra. Továbbá jól beleillik a tesztműszer gyűjteményembe.
Itt is vannak:

Először is kipakoltam az összes kártyát, letakarítottam a dobozokat (megszabadultam az összes matricától, kosztól)
Íme a "leltár":

• Két HP 3488A. Az egyikről hiányzik a hálózati kapcsoló gomb. Egyiknek sincsenek lábai.
• Két 44471A általános célú relé kártya. Az egyikhez van csatlakozó blokk, a másikhoz nincs.
• Két 44470A mátrix relé kártya. Mindkettőhöz van csatlakozó blokk, csak az egyikből hiányzik a kábel rögzítő műanyag betét.
• Egy titokzatos HP jelzésű kártya, mindez hekkelt kiadásban -némi (nem épp szépen kivitelezett) módosítással, amit valamelyik korábbi tulajdonos követett el.

Itt van a titokzatos kártya. Szívesen vennék bármi információt róla, mert én semmit sem találtam:

A tisztítás után kipróbáltam a szerkezeteket: Az első felületes teszt szerint mindkettő működik. A saját tesztje hibátlanul lefut, hallom a relé kattanását akár az előlapról, akár távoli GPIB parancsokkal próbálom vezérelni.
Egy ideje benne vagyok a 3D tervezésben és nyomtatásban.
Itt szükségem volt két műanyag alkatrészre. Az egyik a hálózati kapcsoló cseredarabja:

A másik a hiányzó csatlakozó blokk betéte.
Mindkettőt megterveztem a szokásos OpenSCAD-ben:

Íme kinyomtatva:

A bal az eredeti, a jobb a nyomtatott:

Helyére került a hálózati kapcsoló:

A HP 3488A rendberakási project ezzel elkészült. :-)

Mi érkezett?

Folyamatosan rendelgetek mindenféléket különböző helyekről, csak sokszor nem írok róluk.
Itt van három dolog ami valamilyen szempontból érdekes.
Nemrég elkezdtem dolgozni a műszereim PC intergrációján. Ez egyre fontosabb kezd lenni, ahogy olyan méréseket forgatok a fejemben amelyekhez erre szükség van.
A műszereim változatos csatolókkal rendelkeznek: USB, RS232, GP-IB, Ethernet. Az első háromról beszélve, mire a PC-hez érünk, ígyis-úgyis USB lesz belőlük. Ehhez pedig USB portra van szükség. Sok USB portra.
Tehát rendeltem egy USB hub-ot az AliExpress-en.
Remélem, 16 port elég lesz:

Folytatva a műszer témát: Ahogy látom, mindenki tényként kezeli, hogy a méréstechnika folyamatiránytása a National Instruments LabView termékén alapul. Ezt a szoftvert sok mindenre használják. Még a Lego is ezt használja a Mindstorms robotok programozására.
Jó sok ideje leginkább ingyenes és nyílt forráskódú szoftvereket használok, ami meg ilyen formában nem elérhető, azt megveszem.
A LabView mint olyan egy horrorisztikus árcédulával rendelkező szoftver. Csak most vettem észre (te már biztosan tudod), hogy az NI évekkel ezelőtt elérhetővé tett egy Home Bundle verziót. Igen, ez nem a legutolsó kiadás, igen, ez nem használható profit szerzésre, csak otthoni használatra. Viszont $50-ba kerül ami egy elkötelezett hobbista által kifizethető. Tehát én beszereztem:

Remélem segíteni fog automatizálni a méréseimet.
Elindult egy promoció/verseny a Microsoft és az Avnet szervezésében
(https://www.element14.com/community/docs/DOC-92683/l/sensing-the-world-challenge). Az Azure IoT-hez való kapcsolódásról szól.
Ráadásul van egy MAPS előfizetésem, tehát van havi $100 szabad felhasználású keretem az Azure-ban.
Az elmúlt 6+ évben AWS gyerek lett belőlem. Úgy érzem, hogy ez a verseny egy jó lehetőség, hogy szélesítsem a látóköröm és egy kicsit többet tanuljak meg az Azure-ról.
Tehát megrendeltem az ingyen kitet. Tegnap meg is jött:

Még ötletem is van, hogy mire akarom használni.