A legutóbbinál szentül megfogadtam, hogy nem lesz 3. rész. Egyszerűen azért, mert nem nyúlok többet vízvezetékhez. Hívok szakembert és kész.
Sajnos az élet, nem így alakult. A mai, karanténos időkben, sokmindent magadnak kell megoldanod, mert nem igazán tudsz szakembert hívni. Az én bejáratott gépészem, sem működik igazán most.
Előzmények
Van egy Grundfos JP6-os házi vízmű itthon, ami ellátja a kerti öntözőt. Pár évvel ezelőtt volt némi szivárgás a rendszerben. Ez legalább egy fél évig fennált, mire egy szakember megszüntette. Ez azt jelentette, hogy a szivattyú, pár prcenként be- és kikapcsolt, hogy feltöltse a szivárgást.
Sajnos mire a probléma megszűnt, a szivattyú maga is elkezdett minimálisan ereszteni. A fenti szakember azt mondta rá, hogy egy ilyen típusú hiba javítása 60-70eFt (az új szivattyú 93eFt), így javítás helyett, alá került egy műanyagtálca, amiből pár hetente ki kellett szedni a vizet.
Az idő előrehaladtával, egyre jobban eresztett, és az egész egyre rosszabbul nézett ki.
Rászántam magam a cserére.
Megrendeltem a szerkezetet (ugyanilyet) a Megathermnél. Megérkezett hozzájuk. Én pedig nem mentem el érte időben, így visszakerült a raktárba.
Eltelt egy újabb fél-egy év.
Újra megrendeltem.
Gyanítom az előző esetnél feketelistára kerülhettem náluk, mert az volt a válasz, hogy a készülék megszűnt és már nem beszerezhető. Értem én, hogy én vagyok a feketeseggű, de könyörgöm miért kell a pofámba hazudni? Én úgy gondolom, hogy ez róluk állít ki némi bizonyítványt.
Tavaly valamikor ősszel, szóltam a gépészemnek, hogy hozzon egy ilyen szivattyút, és oldja meg a helyzetet. Szerintem elfelejthette.
Mire jött idén az öntözési szezon, már karantén volt. Tehát rám maradt az ügy.
Megrendeltem a szivattyút. Immár egy másik helyen. Szerdán el is mentem érte.
Okulva az előzőkből, Szilvi azt kérte, hogy valamelyik reggel álljak neki, hátha kell valami a boltból hozzá.
Szombat délelőtt (nem is annyira reggel) nekiálltam.
Kihúztam a konnektorból, leszedtem a ki és bemenő hollandert. Gondoltam sínen vagyunk. Már csak a nyomáskapcsolót kell leszednem a régiről.
Na az nem mozdult. Semmilyen itthon lévő szerszámmal sem tudtam megmozdítani (kis csőfogó, svédkulcs). WD-40 az eredmény annyi, hogy a hollander el kezdett forogni (nem a menetnél).
Barkácsbolt - első fejezet
Vettem egy méretes csőfogót. Persze csak Knipex volt húszezerért, meg vettem egy 36-os csillagvilláskulcsot (volt egy érzésem, hogy kicsi lesz, de nem volt nagyobb). Vettem továbbá egy új hollander szetet, a régit, ha le is jön, akkor sem akartam visszarakni.
Hazajöttem. A villáskulcs tényleg kicsi lett, Végül is a régi csőfogómmal, meg a nagy böszme Knipexxel sikerült szétszednem a hollandert.
A kicsifiam nekiállt, hogy amennyire lehet, kiszedje a kócot a menetből.
Nem segített. Szilvi ötletére felakasztottam a kábeleinél fogva a nyomáskapcsolót a szárítóra, úgy, hogy a maradék hollander darab egy Cillit Duo-val teli csészébe lógott (viccesen nézett ki, de sajnos erről nem készült fotó)
Pár órával később, leszedtem a szárítóról. Fényesebb, vízkőmentes az lett, de nem mozdult.
Végül megfogtam a legnagyobb asztalos szorítóm, abba belefogtam az egész nyomáskapcsolót, és nekiugrottam a Knipexxel. Végre engedett.
Mire ide jutottam, világossá vált, hogy a hollander amit vettem a Bauhausban, nem jó. Apa - Anya menetes. Nekem meg Anya-Anya kell.
Barkácsboltok zárva, project elnapolva.
Vasárnap
Irány a Praktiker. A Bauhausban nem rémlett, hogy lett volna megfelelő hollander, Így kapásból a Praktikerben kezdtem.
Megvettem a hollandert és nekikezdtem a cucc elektromos részének.
Tegnap ugyanis amikor széthúztam a csatlakozót, ez a horror fogadott:
Ebből egyértelművé vált, hogy a nyomáskapcsolóból kijövő lengő aljzat sincs jobb állapotban. Még jó, hogy a házat nem gyújtotta ránk.
Miután a lengő aljzat öntött vizzáró, azt javítani nem lehet. Így még tegnap vettem egy hosszabbítót, amiről le tudom vágni az aljzatot. Szétszedtem a nyomáskapcsolót, kicseréltem a kábelt.
Ehhez legalább értek, pár perc alatt megvolt.
Na akkor mostmár minden megvan. Rakjuk össze.
Hollander szétszed, anyáz, megy vissza a Praktikerbe. A nyamvadt hollanderbe nem voltak képesek belerakni egy tömítőgyűrűt. 1"-os hollanderhez, meg persze nem volt itthon.
Újabb kísérlet.
Összerak, bekapcsol, folyik.
Szétszed, összerak, bekapcsol, nem folyik, viszont nyomás sincs, nyomáskapcsoló letilt.
Itt kezdtem el kiakadni. Erre megkaptam a beosztásom, hogy miért nem olvasom el a doksit.
Mer orosz.
Ok, fel a netre, második próbálkozásra előkerül az ezer oldalas, ezernyelvű izé.
Olvas, kiderül, hogy nem raktam be az ejektorszelepet (hogy ez meg mi a szar?). Kiszedtem a fedelét, nem fér bele. Itt bekapcsol az őrjöngő idegbeteg őrült. Arra gondoltam, hogy valami bekapcsolásnál elfordult, azért nem tudom berakni a szelepet. Vagy tönkrevágtam a vadi új szivattyút, vagy szedhetem szét az egészet, hogy be tudjam rakni a nyamvadt ejektorszelepet.
Kimegyek a kuka mellé, ahova a régi szivattyút tettem. Kiderül, hogy abban sincs ejektorszelep.
Haha, a gépészek sem olvasnak doksit. Az őrjöngésem az egekbe csap.
Persze van, aki tovább olvassa a doksit. Fel kell tölteni a szivattyút vízzel (önfelszívó, ja).
Minden összerak, működik, de folyik.
Szétszed, összerak, folyik.
Szétszed, összerak, folyik.
Sokadszorrá rájövök, hogy a sokak által istenített loctite 55-öt, hogy is kell használni.
Összerak. Nem folyik. kész.
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz,
Nem nyúlok többet vízcsőhöz, ...
2020. április 26., vasárnap
2020. április 25., szombat
GP-IB 5. - V2.0 Panel
Amikor az előző részét írtam ennek a bejegyzésnek, az egyik barátom megjegyezte, hogy túl rövid lett. Megígérhetem. Ez nem lesz az.
Előzmény
Már van egy pár GPIB modul az asztalomon. Van a saját fejlesztésem 1.0-ás, az 1.1-es (és mostmár a 2.0-ás) verziójából. Az egyik 1.0-ás modul nem működik jól. Arra gondoltam, szükségem van némi diagnosztikára a szoftverbe, hogy könnyebben megtaláljam a probléma forrását. Tehát írtam némi diagnosztikai kiegészítést a jelenlegi parancskészlet mellé. Ez képes közvetlenül manipulálni a GPIB lábakat (ezzel meg is próbáltam megtalálni a hibát, de eredménytelenül).
V2.0-ás modul
Hogy továbblépjek a projecttel, beforrasztottam egyet a következő generációs panelből. Ehhez némi szoftver módosítás is tartozik miután ATMEGA32U4-et használtam hozzá az ATMEGA328P helyett.
Minden könnyen ment. Túl könnyen
Az ISP programozás azonnal sikeres volt. A szoftver módosítások nem tartottak tovább öt percnél. A modul azonnal működött egyetlen könnyen javítható szoftver hiba kezelése után.
Hozzákötöttem a tesztre használt HP3478A multiméteremhez. Lefuttattam egy scan parancsot. Azonnal megtalálta a multimétert és jött is vissza a válasz. Az egyetlen pici probléma annyi volt, hogy a visszajövő karakterek egyesével, igen lassan jelentek meg a terminálon.
Következő nap - hibakeresés
Azt gondoltam, hogy a hibát, egy rosszul beforrasztott láb, és ebből következő időtúllépés okozza.
Elindítottam a diag üzemmódot, és azt tapasztaltam, hogy a D1, IFC, SRQ és ATN lábak mindenképp magas logikai szinten vannak, bármit csinálok.
A probléma gyökerére nézve - a többi, működő modullal játszva - kiderült, hogy a diag mód bizonyos lábakat nem korrektül kezel. Módosítottam a diag mód kódját. Ez megoldotta a problémát az 1.0-ás és 1.1-es modulon, de ezen nem. A D1 és az ATN probléma megmaradt.
Később, valahogy rájöttem, hogy ezeket a lábakat az Arduino Leonard panel (aminek a konfigurációját és bootloaderét használtam) az USB kommunikáció RX és TX LEDjének meghajtására használja.
Anyám.
Újratervezés vagy harc?
Itt jött a dilemma. Két lehetőségem van:
Vagy újratervezem a panelt és újra elküldöm gyártásra, vagy megküzdök az Arduino bootloaderrel, a core-al, vagy bármivel, ami szembe jön. Azt választottam, hogy harcolok. Okok:
Okoljuk a bootloadert
Tulajdonképpen nem is tudom miért, talán olvastam valamit az egyik fórumon, azt gondoltam, módosítanom kell a bootloadert és ez megoldja a problémát (talán a soros kommunikáció a bootloader kódját használja, nem tudom)
Új bootloader
Először is megkerestem a bootloader forráskódját. Itt található (https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/caterina). Belenéztem a Makefile-ba, a forráson kívül szüksége van a LUFA könyvtárra az USB kommunikációhoz. Ezt is kiszedtem a git-ből. Hozzácsaptam a legutolsó Win64 kompatibilis avr-gcc-t és a make-et.
Több dolgot is kipróbáltam, hogy a Makefile megtalálja a LUFA-t, minden kísérletem zátonyra futott. Továbbá a grep-et is hiányolta. Úgy éreztem, a Windowsos kísérletem zsákutcába jutott.
Irány a Linux
Nem akartam Linux gépet építeni, vagy Hyper-V alapú Linux gépet telepíteni. Ezért beüzemeltem a Windows Linux alrendszerét és felraktam rá egy Ubuntu 18.04LTS-t a Microsoft Store-ból.
Felraktam rá az avr-gcc-t, build-tools-t, make-et, stb.
A Windows fájlrendszeren keresztül bemásoltam a forrásokat.
Nem működött. Mindenféle jogosultsági bajaim voltak a másolt fájlokkal, tehát feladtam ezt és inkább lehúztam mindent újra a gittel.
Amikor megpróbáltam lefordítani, a grep-et leszámítva ugyanazok a hibák jöttek elő, mint a Windows-on. Jónéhány elérési út módosítás és az USB VID és PID megadása után végül elindult a fordítás. Az eredmény katasztrófa:
A kérdéses bootloaderhez 8 éve senki sem nyúlt. Mind az avr-gcc, mind a LUFA könyvtár fejlődött azóta.
Kiderítettem, hogy melyik LUFA repo tag-gel fordították eredetileg és átkapcsoltam arra. Így, gond nélkül lefordult a bootloader.
Bootloader próba
Nem akartam belehekkelni a bootloadert az Arduino IDE-be, tehát manuálisan raktam fel a panelra.
Feltöltöttem a saját kódom is. És...
Nem működött. Az eredeti hiba maradt.
Hekkeljük meg a core-t?
Nem. Ugyan kiderítettem, hogy a probléma az USBCore.c-ben van. Nem akartam belepiszkálni. Nem lenne egy jövőálló megoldás.
Körülnézve és gondolkozva arra jutottam, hogy egy Arduino board specifikációt kell gyártanom a projectemhez.
Új board konfiguráció? - még nem
Először is akartam valamit, amiből tanulhatok. Találtam egy ATMEGA32U4 alapú módosított panelt az ArachnidLabs-tól (http://www.arachnidlabs.com/tsunami/), és a hozzá tartozó git repót https://github.com/arachnidlabs/arachnidlabs-boards
Azonnal világossá vált, hogy szükségem van egy stabil helyre a json és a package zip tárolására/megosztására. Valamire, amire számíthatok, hogy hosszútávon ott lesz. Valamire, ami elérhető, mindenféle authentikációs vudu (lásd OneDrive) nélkül.
Az AVR-GPIB projectem a GitLab-on lakik, így ott néztem körül. Ahogy a GitHub-on van GitHub pages, úgy a GitLab-on van GitLab pages - milyen meglepő.
Elolvastam a dokumentációját, nem lett tőle érthetőbb, hogyan kell a GitLab pages-t összerakni.
Csináltam egy suf.gitlab.io nevű repót, és belepakoltam a fájljaim. Semmi sem történt.
Rendben, úgy tűnik, hogy szükségem van a gitlab-ci.yml-re az oldal összerakásához. Ez nem meglepő koncepció számomra, miután az elmúlt pár évemet DevOps mérnökként éltem. Jenkins CI/CD scripteket írok nap mint nap.
Megírtam a scriptet, bepakoltam a repóba, hiba. Valami elnevezési probléma. Javítottam.
Következő. Most lefordul hiba nélkül. Az oldal még mindig 404-et ad vissza.
Sok próbálkozás után rájöttem, hogy a GPIB alkönyvtár tartalma a weboldal gyökérkönyvtárában landol. Arra gondoltam, hogy az lehet az ok, hogy a gyükér könyvtár üres, nincs benne fájl, csak a GPIB könyvtár. Így hozzáadtam egy index.html-t.
A korábban sikeres fordítás, most elhasalt.
Sok dolgot elolvasva, több próbálkozás után kiderült, hogy az egyetlen módszer, ami működik, átpakolni mindent egy újonan generált átmeneti könyvtárba és átnevezni (mv) public-ra, ami a publikációra kijelölt könyvtár.
Végül megszületett a GitLab pages oldalam: https://suf.gitlab.io
Kicsi is, sárga is, savanyú is, de a miénk.
Új board konfiguráció? - mostmár tényleg
Megírtam a json fájlt, módosítottam a pins_arduino.h-t (a LED-ek, most két olyan MCU lábra mutatnak, amik nincsenek a tokból kivezetve), összeraktam a csomagot, legeneráltam a hash-t, hozzáadtam a json-hoz, feltöltöttem az egészet a GitLabra, hozzáadtam a json-t az Arduino IDE-hez, bementem a board manager-be és...
semmi sem történt.
Megjavítottam két dolgot, ami bugnak látszott: a json fájl nevét. Mint kiderült ez követelmény, valamint a package fájl hosszát a json-on belül.
Fel a gitre, be az Arduino-ba. Mostmár megjelent a cuccom a board manager-ben.
A telepítés - elszállt. A package.zip-en belül egy db gyökér könyvtárnak kell lennie.
Javítottam, újra végigmentem a procedúrán. Mostmár működik a telepítés.
Megpróbáltam feltölteni a saját kódomat.
Kaptam mindenféle össze-vissza hibát, kommunikációs problémák. Visszamentem az Arduino Leonardo-ra. A hibák maradtak. Windows COM probléma szaga volt. Gép újraindít, a kommunikációs hibák eltűntek.
Megint megpróbáltam feltölteni. avrdude paramétereket hiányolt. Mindenféle paraméter jellegű dolog jött elő később.
Végülis beraktam mindent a package.txt-be amit találtam és értelmesnek tűnt. Úgy tűnik, az ArachnidLabs féle konfiguráció egy korábbi Arduino IDE verzióhoz készülhetett, ami még nem igényelte ezeket a paramétereket.
Végre a feltöltés működik.
Próbáljuk ki
A GP-IB diagnosztika funkció végre úgy működik, ahogy kell. Készen vagyunk!!!!
Neeeeeeeeeeem.
A diagnosztika megy, a kommunikáció az eszközökkel, na az nem. Elég! Alvás!
Másnap
Valami viszketett az agyamban. Kipróbáltan a korábban működő modulokat is. Azok is megszűntek működni.
Vagy a tesztekhez használt HP 3478A multiméterem döglött meg, vagy a diagnosztika szoftver módosítás belekavart a kommunikációba.
Gyorsan kiderítettem: a diag volt a bűnös. Javítottam. Mostmár működik a v2.0 modul.
Vége a történetnek.
További hardver és szoftver fejlesztés következik a GP-IB adapterhez.
Előzmény
Már van egy pár GPIB modul az asztalomon. Van a saját fejlesztésem 1.0-ás, az 1.1-es (és mostmár a 2.0-ás) verziójából. Az egyik 1.0-ás modul nem működik jól. Arra gondoltam, szükségem van némi diagnosztikára a szoftverbe, hogy könnyebben megtaláljam a probléma forrását. Tehát írtam némi diagnosztikai kiegészítést a jelenlegi parancskészlet mellé. Ez képes közvetlenül manipulálni a GPIB lábakat (ezzel meg is próbáltam megtalálni a hibát, de eredménytelenül).
V2.0-ás modul
Hogy továbblépjek a projecttel, beforrasztottam egyet a következő generációs panelből. Ehhez némi szoftver módosítás is tartozik miután ATMEGA32U4-et használtam hozzá az ATMEGA328P helyett.
Minden könnyen ment. Túl könnyen
Az ISP programozás azonnal sikeres volt. A szoftver módosítások nem tartottak tovább öt percnél. A modul azonnal működött egyetlen könnyen javítható szoftver hiba kezelése után.
Hozzákötöttem a tesztre használt HP3478A multiméteremhez. Lefuttattam egy scan parancsot. Azonnal megtalálta a multimétert és jött is vissza a válasz. Az egyetlen pici probléma annyi volt, hogy a visszajövő karakterek egyesével, igen lassan jelentek meg a terminálon.
Következő nap - hibakeresés
Azt gondoltam, hogy a hibát, egy rosszul beforrasztott láb, és ebből következő időtúllépés okozza.
Elindítottam a diag üzemmódot, és azt tapasztaltam, hogy a D1, IFC, SRQ és ATN lábak mindenképp magas logikai szinten vannak, bármit csinálok.
A probléma gyökerére nézve - a többi, működő modullal játszva - kiderült, hogy a diag mód bizonyos lábakat nem korrektül kezel. Módosítottam a diag mód kódját. Ez megoldotta a problémát az 1.0-ás és 1.1-es modulon, de ezen nem. A D1 és az ATN probléma megmaradt.
Később, valahogy rájöttem, hogy ezeket a lábakat az Arduino Leonard panel (aminek a konfigurációját és bootloaderét használtam) az USB kommunikáció RX és TX LEDjének meghajtására használja.
Anyám.
Újratervezés vagy harc?
Itt jött a dilemma. Két lehetőségem van:
Vagy újratervezem a panelt és újra elküldöm gyártásra, vagy megküzdök az Arduino bootloaderrel, a core-al, vagy bármivel, ami szembe jön. Azt választottam, hogy harcolok. Okok:
- A tervezés és gyártás pénzbe kerül, és jópár napig (vagy hétig) eltart amíg az új panel ideér
- Az ATMEGA32U4-nek két teljes 8 bites kívülről elérhető portja van. Ezeket tudom gyorsabb párhuzamos kommunikációra használni közvetlen port manipulációval. Sajnos a két LEDet pont belerakták egy-egy lábára a két portnak. Tehát, ha azokat a lábakat nem használom, sebességet vesztek.
- Ásni ez esetben, szórakoztató. Tudok tanulni belőle
Okoljuk a bootloadert
Tulajdonképpen nem is tudom miért, talán olvastam valamit az egyik fórumon, azt gondoltam, módosítanom kell a bootloadert és ez megoldja a problémát (talán a soros kommunikáció a bootloader kódját használja, nem tudom)
Új bootloader
Először is megkerestem a bootloader forráskódját. Itt található (https://github.com/arduino/ArduinoCore-avr/tree/master/bootloaders/caterina). Belenéztem a Makefile-ba, a forráson kívül szüksége van a LUFA könyvtárra az USB kommunikációhoz. Ezt is kiszedtem a git-ből. Hozzácsaptam a legutolsó Win64 kompatibilis avr-gcc-t és a make-et.
Több dolgot is kipróbáltam, hogy a Makefile megtalálja a LUFA-t, minden kísérletem zátonyra futott. Továbbá a grep-et is hiányolta. Úgy éreztem, a Windowsos kísérletem zsákutcába jutott.
Irány a Linux
Nem akartam Linux gépet építeni, vagy Hyper-V alapú Linux gépet telepíteni. Ezért beüzemeltem a Windows Linux alrendszerét és felraktam rá egy Ubuntu 18.04LTS-t a Microsoft Store-ból.
Felraktam rá az avr-gcc-t, build-tools-t, make-et, stb.
A Windows fájlrendszeren keresztül bemásoltam a forrásokat.
Nem működött. Mindenféle jogosultsági bajaim voltak a másolt fájlokkal, tehát feladtam ezt és inkább lehúztam mindent újra a gittel.
Amikor megpróbáltam lefordítani, a grep-et leszámítva ugyanazok a hibák jöttek elő, mint a Windows-on. Jónéhány elérési út módosítás és az USB VID és PID megadása után végül elindult a fordítás. Az eredmény katasztrófa:
A kérdéses bootloaderhez 8 éve senki sem nyúlt. Mind az avr-gcc, mind a LUFA könyvtár fejlődött azóta.
Kiderítettem, hogy melyik LUFA repo tag-gel fordították eredetileg és átkapcsoltam arra. Így, gond nélkül lefordult a bootloader.
Bootloader próba
Nem akartam belehekkelni a bootloadert az Arduino IDE-be, tehát manuálisan raktam fel a panelra.
Feltöltöttem a saját kódom is. És...
Nem működött. Az eredeti hiba maradt.
Hekkeljük meg a core-t?
Nem. Ugyan kiderítettem, hogy a probléma az USBCore.c-ben van. Nem akartam belepiszkálni. Nem lenne egy jövőálló megoldás.
Körülnézve és gondolkozva arra jutottam, hogy egy Arduino board specifikációt kell gyártanom a projectemhez.
Új board konfiguráció? - még nem
Először is akartam valamit, amiből tanulhatok. Találtam egy ATMEGA32U4 alapú módosított panelt az ArachnidLabs-tól (http://www.arachnidlabs.com/tsunami/), és a hozzá tartozó git repót https://github.com/arachnidlabs/arachnidlabs-boards
Azonnal világossá vált, hogy szükségem van egy stabil helyre a json és a package zip tárolására/megosztására. Valamire, amire számíthatok, hogy hosszútávon ott lesz. Valamire, ami elérhető, mindenféle authentikációs vudu (lásd OneDrive) nélkül.
Az AVR-GPIB projectem a GitLab-on lakik, így ott néztem körül. Ahogy a GitHub-on van GitHub pages, úgy a GitLab-on van GitLab pages - milyen meglepő.
Elolvastam a dokumentációját, nem lett tőle érthetőbb, hogyan kell a GitLab pages-t összerakni.
Csináltam egy suf.gitlab.io nevű repót, és belepakoltam a fájljaim. Semmi sem történt.
Rendben, úgy tűnik, hogy szükségem van a gitlab-ci.yml-re az oldal összerakásához. Ez nem meglepő koncepció számomra, miután az elmúlt pár évemet DevOps mérnökként éltem. Jenkins CI/CD scripteket írok nap mint nap.
Megírtam a scriptet, bepakoltam a repóba, hiba. Valami elnevezési probléma. Javítottam.
Következő. Most lefordul hiba nélkül. Az oldal még mindig 404-et ad vissza.
Sok próbálkozás után rájöttem, hogy a GPIB alkönyvtár tartalma a weboldal gyökérkönyvtárában landol. Arra gondoltam, hogy az lehet az ok, hogy a gyükér könyvtár üres, nincs benne fájl, csak a GPIB könyvtár. Így hozzáadtam egy index.html-t.
A korábban sikeres fordítás, most elhasalt.
Sok dolgot elolvasva, több próbálkozás után kiderült, hogy az egyetlen módszer, ami működik, átpakolni mindent egy újonan generált átmeneti könyvtárba és átnevezni (mv) public-ra, ami a publikációra kijelölt könyvtár.
Végül megszületett a GitLab pages oldalam: https://suf.gitlab.io
Kicsi is, sárga is, savanyú is, de a miénk.
Új board konfiguráció? - mostmár tényleg
Megírtam a json fájlt, módosítottam a pins_arduino.h-t (a LED-ek, most két olyan MCU lábra mutatnak, amik nincsenek a tokból kivezetve), összeraktam a csomagot, legeneráltam a hash-t, hozzáadtam a json-hoz, feltöltöttem az egészet a GitLabra, hozzáadtam a json-t az Arduino IDE-hez, bementem a board manager-be és...
semmi sem történt.
Megjavítottam két dolgot, ami bugnak látszott: a json fájl nevét. Mint kiderült ez követelmény, valamint a package fájl hosszát a json-on belül.
Fel a gitre, be az Arduino-ba. Mostmár megjelent a cuccom a board manager-ben.
A telepítés - elszállt. A package.zip-en belül egy db gyökér könyvtárnak kell lennie.
Javítottam, újra végigmentem a procedúrán. Mostmár működik a telepítés.
Megpróbáltam feltölteni a saját kódomat.
Kaptam mindenféle össze-vissza hibát, kommunikációs problémák. Visszamentem az Arduino Leonardo-ra. A hibák maradtak. Windows COM probléma szaga volt. Gép újraindít, a kommunikációs hibák eltűntek.
Megint megpróbáltam feltölteni. avrdude paramétereket hiányolt. Mindenféle paraméter jellegű dolog jött elő később.
Végülis beraktam mindent a package.txt-be amit találtam és értelmesnek tűnt. Úgy tűnik, az ArachnidLabs féle konfiguráció egy korábbi Arduino IDE verzióhoz készülhetett, ami még nem igényelte ezeket a paramétereket.
Végre a feltöltés működik.
Próbáljuk ki
A GP-IB diagnosztika funkció végre úgy működik, ahogy kell. Készen vagyunk!!!!
Neeeeeeeeeeem.
A diagnosztika megy, a kommunikáció az eszközökkel, na az nem. Elég! Alvás!
Másnap
Valami viszketett az agyamban. Kipróbáltan a korábban működő modulokat is. Azok is megszűntek működni.
Vagy a tesztekhez használt HP 3478A multiméterem döglött meg, vagy a diagnosztika szoftver módosítás belekavart a kommunikációba.
Gyorsan kiderítettem: a diag volt a bűnös. Javítottam. Mostmár működik a v2.0 modul.
Vége a történetnek.
További hardver és szoftver fejlesztés következik a GP-IB adapterhez.
2020. április 14., kedd
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.
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:
És a gyermek:
https://gitlab.com/suf/suf-electronics-gpib
Jó formában vannak:
És várják hosszú és eredményes életét.
2020. április 9., csütörtök
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:
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":
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. :-)
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. :-)
2020. április 1., szerda
2kW Labortáp 2.
Kérlek ezen a néven, ne keresd a cikk első részét! Ezt Néhány történet ... néven publikáltam.
Eltartott egy ideig, hogy tovább tudjak haladni ezzel a projecttel.
Megépítettem és leteszteltem a késleltető áramköröm, amiről itt volt szó.
Úgy működik, ahogy vártam.
Elkészült a teljes kábelezés, és a mechanikai munka, ami szükséges volt az összerakáshoz.
A szokásos C14-es csatlakozó helyett C20-ast választottam. A két tápegység maximum 3kW-ot vehet fel, ezért úgy éreztem, hogy jobb a nagyobb csatlakozót választani.
Nagyjából egy év kihagyás után, újra beüzemeltem a 3D nyomtatómat. Így, 3D nyomtatott hátlapot kapott a tápegység:
Készítettem egy rövid videót, a két modul késleltetett bekapcsolásáról:
Tehát a szerkezet mostmár működik. Az egyetlen dolog, ami hiányzik, az a számítógépes vezérlés.
A két modul eredetileg két, optikailag leválasztott USB - Soros átalakítóval rendelkezik. Ezt én egy USB porttal akartam megoldani. Rendeltem egy kétcsatornás FTDI modult, ami sajnos még nem érkezett meg. Az USB csatlakozót már felszereltem a hátlapra. A teljes befejezéshez még ide kell érnie az FTDI modulnak, valamint terveznem és építenem kell egy optocsatoló modult hozzá. Ez lesz majd a project második fázisa.
Eltartott egy ideig, hogy tovább tudjak haladni ezzel a projecttel.
Megépítettem és leteszteltem a késleltető áramköröm, amiről itt volt szó.
Úgy működik, ahogy vártam.
Elkészült a teljes kábelezés, és a mechanikai munka, ami szükséges volt az összerakáshoz.
A szokásos C14-es csatlakozó helyett C20-ast választottam. A két tápegység maximum 3kW-ot vehet fel, ezért úgy éreztem, hogy jobb a nagyobb csatlakozót választani.
Nagyjából egy év kihagyás után, újra beüzemeltem a 3D nyomtatómat. Így, 3D nyomtatott hátlapot kapott a tápegység:
Készítettem egy rövid videót, a két modul késleltetett bekapcsolásáról:
Tehát a szerkezet mostmár működik. Az egyetlen dolog, ami hiányzik, az a számítógépes vezérlés.
A két modul eredetileg két, optikailag leválasztott USB - Soros átalakítóval rendelkezik. Ezt én egy USB porttal akartam megoldani. Rendeltem egy kétcsatornás FTDI modult, ami sajnos még nem érkezett meg. Az USB csatlakozót már felszereltem a hátlapra. A teljes befejezéshez még ide kell érnie az FTDI modulnak, valamint terveznem és építenem kell egy optocsatoló modult hozzá. Ez lesz majd a project második fázisa.
Feliratkozás:
Bejegyzések (Atom)