Dimag - PowerShell

Remélem ezért nem leszek keresztre feszítve.

Szóval: Használom a Dimag-ot, előfizetéses elektronikus újságok olvasására, de nem szeretem. Az alkalmazás is a hozzáállás is csapnivaló.

Szeretem, ha az éveken évtizedeken keresztül olvasott szaklapok megvannak a gépemen pdf-ben. Ez amolyan gyűjtőszenvedély féle (biztos orvoshoz kéne fordulnom).

Persze a Dimag-ból kiszedni a dolgokat nem igazán lehet. Elvégre arra szántak rengeteg energiát, hogy a holnapi napot is titkosítsák, arra meg nullát, hogy egy értelmezhető felhasználói élményt nyújtsanak.

Arra jutottam, hogy képernyőfotóként lementem az oldalakat, majd ebből csinálok pdf-et.

Ennek az első része mechanikus, igényel némi rendszeres precizitást. Szóval:

• Dimag Chrome-ban megnyit.
• Bal oldali oldalankénti navigáció kikapcsol
• Teljes képernyőre kirak (F11)

Így minden oldal, minden esetben ugyanoda kerül a képernyőn (az egyes oldalak középre, az oldalpárok két oldalra). A képeket egyes oldalnál <oldalszám>.jpg, oldalpárnál <páros oldal>-<páratlan oldal>.jpg néven mentem. Minden oldalszám szigorúan három számjegy.

Na eddig van a mechanikus munka (még gondolkozom, tudom-e tovább automatizálni). A lementett jpeg-ekre megy ez a PowerShell + ImageMagick script, és már kész is a friss ropogós pdf:

$srcfiles = Get-ChildItem "./*.jpg" | Sort-Object -Property Name

$dstlist = ''

foreach($jpg in $srcfiles) {

    if($jpg.Name -match '[0-9]{3}-[0-9]{3}\.jpg') {

        magick $jpg.Name -crop '1483x2081+436+7' "p$($jpg.Name.Substring(0,3)).jpg"

        $dstlist += "p" + $jpg.Name.Substring(0,3) + ".jpg "

        magick $jpg.Name -crop '1483x2081+1920+7' "p$($jpg.Name.Substring(4,3)).jpg"

        $dstlist += "p" + $jpg.Name.Substring(4,3) + ".jpg "

    }

    else {

        if($jpg.Name -match '[0-9]{3}\.jpg') {

            magick $jpg.Name -crop '1483x2081+1178+7' "p$($jpg.Name.Substring(0,3)).jpg"

            $dstlist += "p" + $jpg.Name.Substring(0,3) + ".jpg "

        }

    }

}

$dstlist += "result.pdf"

Start-Process -NoNewWindow -FilePath "magick.exe" -ArgumentList $dstlist -Wait

Remove-Item p*.jpg

A fenti kód az én 4K monitorommal működik. Más monitorhoz át kell írni a méreteket.

Továbbá:

• Nem árulom el, melyik magazinnál használom.
• A saját infrastruktúrám az elkészült pdf-ek nem hagyják el.
• Amivel dolgozom, azt előfizettem, nincs benne semmi hack

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.

Új műhely

Végre hivatalos. Nagy harc volt a helyi önkormányzat bürokráciájával, hogy ezt sikerüljön elérni. Van egy új műhelyem. Még rengeteg pénz és munka lesz vele, amíg be tudok költözni (jópár hónapra számítok).