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!

USB-GPIB csatoló V2.1

 

Ez egy némi javítás, hibakezelés a korábbi ATMEGA32U4 alapú USB-GPIB csatolómhoz. Az előzőnek volt néhány baja. Ütközött a bootloader LED-jeinek a konfigurációja a GPIB jelekkel. Teljesen újradefiniáltam az eredeti Arduino jelekhez képest, hogy ki tudjam használni az interrupt kezelést. Továbbá egy teljes 8 bites portot használtam adatbuszként, hogy egyben írható/olvasható legyen és ne bitenként.

Az új verzióban kicsit más lett a megközelítés:

• Próbáltam az Arduino Leonardo lábkonfigurációjánál maradni, amennyire tudtam.
• Feladtam az interrupt kezelést az SRQ vonalat leszámítva
• Megtartottam a 8 bit adatbuszt
• Konfigurálhatóvá tettem - lehet választani az AR488 által használt konfiguráció és a fenti 8 bites egybe adatbusz között (az AR488 verziónak nem kell speciális bootloader)
• Megtartottam az állapot LEDeket
• Hozzáadtam egy hibakeresésre használható soros portot

Később ez a terv lesz az alapja a teljes GPIB csatolónak, megfelelő vonalmeghajtókkal együtt. Ez a verzió, csak egy műszer vezérlésére használható (lehet, bírna többet is, de inkább nem próbálom ki). 

A kapcsolási rajz:

A nyák terv:

A robbantott 3D model:

Igen tudom, hogy a csatlakozó neme, nem a megfelelő (bár ki tudja ma már, hogy mi a megfelelő nem), de sajnos nem találtam megfelelő 3D modellt, és annyira nem volt fontos, annyi volt a lényeg, hogy reprezentálja a megfelelő méretet a 3D modell tervezéshez.

A teljes terv itt található:

https://gitlab.com/measurementcontrol/gpibinterfacehardware

Ezzel az a témában elkészült új tervek száma kettőre emelkedett, szóval itt az ideje, hogy megrendeljem a paneleket.

USB-RS232 Csatoló

 

A műszervezérlés tervem megvalósításaként, először megterveztem az USB-RS232 csatolómat. Lehet, hogy ez még nem az utolsó verziója, de egyenlőre végeztem a tervezési fázissal.

A szerkezet a CH340G chipen alapul, amit korábban az ESP8266-os programozómon is sikeresen használtam, ugyanez van egy rakás kínai USB-Soros kábelben, Arduino-kban, 3D nyomtató vezérlőkben. Sosem volt semmi bajom ezekkel az eszközökkel. A megfelelő jelszintek előállítására hozzáadtam még egy MAX232-es tokot.

Valószínüleg ez a megoldás nem optimális, miután nincs meg rajta az összes RS232 jel, de azt hiszem, egyenlőre jó lesz így (nem igazán akarok most több energiát belerakni ebbe).

A kapcsolási rajz:

A nyák terv:

Esetleg észreveheted a kapcsolási rajzon és a nyák terven, hogy "kettős" USB csatlakozás van rajta. Ez azt jelenti, hogy az USB jelek mind egy mikro USB csatlakozón, mind pár forszemen elérhetőek. Ez a megoldás azt a lehetőséget kínálja, hogy akár USB csatlakozóval, akár kábellel szereljük össze az eszközt.

Ennek a koncepciónak megfelelően két különböző dobozkát terveztem hozzá.

USB csatlakozóhoz:

Kábelhez:

Megfigyelhető, hogy a panel maga a 3D terven szürke. Az ok, hogy nem tudtam a színes 3D modellt beimportálni az OpenSCAD-be, amit a 3D modellezéshez használok (lehet, nem is tud ilyet).

Az eredeti 3D nézet, ilyen:

Jelenleg még nem akarom a panelt legyártani, mert a GPIB csatoló következő verzióján dolgozom és össze akarom montírozni egy panelre a gyártási költségek csökkentése miatt.

A tervek itt találhatóak:

https://gitlab.com/measurementcontrol/rs232interfacehardware

Nekiálltam a mindenféle műszervezérlős dolgom átszervezésének is. A kapcsolódó repók itt lesznek majd elérhetőek:

https://gitlab.com/measurementcontrol

Műszervezérlés - újrakezdve

 

Bevezető

Az elmúlt években rengeteg munkát raktam a különböző műszereim számítógépes vezérlésébe. A terv az volt, hogy valami hozzáadott értéket teremtsek vele, úgy mint logolás, jobb láthatóság, több - integrált - funkció, stb.

Úgy néz ki, hogy ezzel kicsit megbuktam, miután semmi sem jutott el, a használhatósági állapotba.

Az egészet, hónapokkal ezelőtt félretettem. Most úgy érzem, ideje leporolnom és újrakezdenem, hogy valami "működő" állapotig eljussak vele.

Tervek

A forrás repók újraszervezése

Ez azért szükséges, mert rengeteg dolgot tanultam az elmúlt években a munkám kapcsán a gitről (branch stratégiák, release kezelés, etc.)

USB-RS232 interfész tervezés

Van egy pár eszközöm ami RS232 interfésszel rendelkezik a GPIB helyett/mellett. Igen, vehetsz USB-Soros átalakítót gombokért. Miért kell egy másik? A legtöbb darab amit kapsz, nem tudja a megfelelő jelszinteket. TTL szintet használnak RS232 helyett. A legtöbb professzionális műszernek szüksége van a megfelelő jelszintekre. A megfelelő csatoló nem olcsó, vagy azt kockáztatod, hogy veszel valami vackot az Aliexpressen ami azt állítja magáról, hogy megfelelő, közben nem.

USB-GPIB hardver újratervezése

Az ATMEGA32U4 alapú interfészem tökéletesem működik. Az elmúlt években ugyanakkor kiderült pár dolog ami arra késztet, hogy szükség van pár módosításra:

• Olyan fizikai terv kialakítása, hogy 3D nyomtatott dobozba lehessen tenni.
• Elhagyni azokat a csatlakozókat amiket későbbi továbbfejlesztésre terveztem bele mint kijelző plusz eszközök vezérlése, stb.
• Soros debug lehetőség (az AR488-nak megfelelően)
• Az Arduino Leonardo bootloaderrel való kompatibilitás
• Megtartani a teljes 8bites buszból adódó adat transzfer előnyöket (módosított bootloader szükséges)
• Az AR488 szoftverrel való kompatibilitás megtartása (https://github.com/Twilight-Logic/AR488)
• Aktivitás LED-ek hozzáadása (az eredeti Arduino Leonardo-nak megfelelően)
• Teljes GPIB meghajtó TI ICkkel (másik hardver verzió szükséges)

Az AR488 kompatibilitás megtartása nem jelenti azt, hogy a saját firmware-emet ki tervezném dobni. Változatlanul nem békéltem megy a 3000+ sor kóddal egyetlen forrásfájlban. Az AR488 még mindíg nem támogatja a GPIB másodlagos címzést. Van egy rakás eszközöm (VXI keretek, moduláris labortáp keret), amiknek szüksége van erre. A másik oldalon támogatja a device üzemmódot, a TI GPIB IC-it, amik az enyémből hiányoznak, továbbá megvan a szoftver támogatása olyan eszközökben mint a sigrok.

Proper bootloader for USB-GPIB

Csináltam egy bootloadert a v2.0-ás panelhez. Ez egy annak a mellényúlásnak az eredménye volt, hogy újrahasznosítottam az Arduino Leonardo USB visszajelző LEDjeit, ami megölte a GPIB kommunikációt. A problémát akkor megoldottam, de az eredménye egy rosszul dokumentált (https://it-pro-hu.blogspot.com/2020/04/gp-ib-5-v20-panel.html), nehezen reprodukálható állapot lett. Ráadásul ez kinyírja a LED-eket és nem áthelyezi más uC lábakra. Most létre akarok hozni egy karbantartható, újrafordítható, megfelelően telepíthető megoldást. Ezen túl szeretnék a szabályoknak megfelelő PID/VID páros kérni a pid.codes-tól.

Tápegység vezérlő szoftver

A virtuális műszer szoftverem sok dologra lenne alkalmas, de rájöttem, hogy túl magasra tettem a lécet, első nekifutásra. Sok mindent megcsináltam már benne, a jelenlegi újrakezdéshez kisebbet akarok fogni.

Tehát megtartva a cserélhető driver támogatást akarok csinálni egy tápegység vezérlő szoftvert a rengeteg tápegységemhez (ráadásul a HP 66000A moduláris tápegység nem is használható szoftver nélkül, mert nincs hozzá meg a saját billentyűzete). Ebbe egyenlőre nem akarom magasabb szintű funkciókat rakni.

Továbbiak...

Természetesen, nem akarok itt megállni, újra akarom indítani a virtuális műszer fejlesztésem, a karakterisztika rajzolót, stb.

Ezek a dolgok egyenlőre homályosak, és ha elveszítem a fókuszt ezem megint, annak csak egy polcra rakott project hegy lesz az eredménye. Megint.

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.