2018. július 12., csütörtök

A nagy multiméter robbantgatás (vagy nem)

Akik ismernek, tudják, hogy az elmúlt jó pár évben, csak minőségi (vagy legalábbis általam minőséginek tekintett) multimétert használok: Fluke, HP (Agilent, Keysight), Keithley, Sanwa. Ezek legalábbis biztonságtechnikai szempontból azt nyújtják, hogy a védelmük nem merül ki egy 5x20-as üvegcsöves robbanóbiztosítékban.
Különböző fórumokon elég sokat vitatkoztam különböző emberekkel arról, hogy egy 1-2 ezer forintos fekália multiméternek tekinthető vagy sem. A következő dolgokat hallom:
- "Kizárólag kisfeszültségre fogom használni" - ez egy hülyeség. Ha szükséged van rá, úgyis be fogod dugni a konnektorba
- "Még sosem volt vele bajom" - majd lesz
- "Mindíg odafigyelek" - aztán egyszer majd nem
Na szóval megelégeltem. Be akarom indítani a "torture" üzemmódot. Rendeltem egy adag nagyon trágya és féltrágya multimétert. Ezeket ha megjöttek:
1. Szétszedem és megnézem, milyen védelemmel rendelkeznek
2. Ellenállásmérés és árammérés üzemmódban mennek a konnektorba (szigorúan szabadtéren, távolról)
A mezőny:
DT9205A - $9.55
Uni-T UT120C - $18.99
Uni-T UT20B - $9.87
DT-830B - $3.15
XL830L - $4.68
ANENG AN8009 - $21.89
Uni-T UT136B - $19.50
Bónusz: A saját Fluke 117-em
Na szóval, a fentiek közül abban reménykedem, hogy legalább a $20 körüli darabok közül találok olyat ami elfogadható eredményt produkál.
Továbbá kommentben várnám, azon típusokat (a <5eFt kategóriából, melyek a magyar piac részei, nem gondoltam rájuk, vélhetően elterjedtek és a fentiektől különböznek - nem csak OEM átcsomagolásban).

2018. július 3., kedd

Tanulságos történet

Egy beszélgetés kapcsán eszembe jutott egy régi történet, amit azt hiszem még nem írtam meg. A dolog a saját, sorozatos hülyeségeim története, melynek minden része visszavezethető olyan alapvető elektromos/elektronikai dolgokra amiket tudnunk kell, és én nem gondoltam rá az eset kapcsán.
Volt egyszer egy CNC maróm (a "volt" állapot még ma is fenn áll, még mindíg nem javítottam meg).
Az eredeti Kínai vezérlőelektronikája sok sebből vérzik. Ezt mi sem bizonyította jobban mint amikor eltörtem vele egy marószárat, pusztán azért, mert a tápellátás elégtelensége miatt megszorult a motor.
Megnézve az elektronikát egyértelmű volt, hogy egy ránézésre maximum 150W-os toroid trafó nem fog elvinni egy 300W-os marómotort, a teljes elektronikát valamint négy NEMA23-as léptetőmotort.
Ezért kivágtam az egész marómotor vezérlést, tápot és beraktam helyette egy 600W-os tápegységet a motornak és egy 100W-ost az összes többinek.
Ez így működött is egy ideig-óráig, össz annyi volt a baja, hogy a motor végig maximális fordulaton ment.
Egyszer a 300W-os motor kimúlt és én beraktam egy 400W-ost helyette.
Első bekapcsolásra egy óriási csattanás volt a válasz. Biztosíték le a házban. Nagyjából csak az nem döglött meg ami nem volt ott. Tanulságok:
1. Az 5x20-as üvegcsöves olvadóbiztosíték egy vicc. Szerencsém volt, hogy itt egy zárt hálózati ajzatban volt. Ha azt hiszed, hogy csak elolvad a szál és ennyi, akkor tévedsz. Üvegmorzsává robbant az egész. Ha ez egy nyitott panelen lévő biztosíték foglalat lett volna, valószínüleg viszi a szemem.
2. Egy rakás alkatrész tönkrement a tápegységben. Miért? Mert a motorra nem tettem egy fordított irányú diódát ami megfogná a motor induktív visszarugását - ez KÖTELEZŐ induktív egyenfeszültségű cuccoknál.

Ezek után megpróbáltam megjavítani a tápot. Meg is találtam a hibás alkatrészeket, próbapadon láthatóan részei el is indultak. A MOSFETek gatejein multiméterrel mértem is valami 5 volt körüli feszültséget. Ekkor úgy gondoltam megnézem oszcilloszkóppal is, hogy ott valóban egy PWM négyszögjel van-e.
Óriási csattanás. Házbiztosíték le. A panelről két centi rézfólia lerobbant. A tápegység átment nem javíthatóba.
Tanulság:
3. A hálózatról üzemeltettet oszcilloszkópok mérő földjei a hálózati védőföldre vannak kötve, minden esetben. A kapcsolótáp MOSFET source lába a hálózati nullához kápest meg vagy 350V DC-n voltak.
Tehát oszcilloszkóppal nem mérünk közvetlenül hálózatra kötött eszközt.

Ennek a 3. pontnak volt a következménye, hogy építettem egy leválasztótrafót.

2018. május 31., csütörtök

Titan szívás

Csak halkan kérdem. Szabad ennek így kinéznie néhény hónap használat, vagy egy elakadt nyomtatás után? E3D Titan Extruder - eredeti angol verzió, az E3D-Online-ról rendelve.


2018. május 12., szombat

"Bőrvizsgáló" mikroszkóp

Szép sorban le fogom írni a szavazásra bocsáljtott projectekről, hogy mi micsoda. A házautomatizálás központ után jöjjön a
Bőr (Leather) vizsgáló mikroszkóp és nem a Bőr (Skin) vizsgáló mikroszkóp.

Ez a project a feleségemtől jött.
Van egy speciális mikroszkóp a piacon, aminek a tárgyasztala fűthető. Ez régi tárgyak restaurálás előtti vizsgálatához használható. Esetünkben bőrtárgyakról beszélünk, de másra is használható.
Az a cél, hogy meghatározzuk azt a pontos hőmérsékletet amikor bizonyos változások végbemennek a mintában.
Ez egy időigényes feladat és a jelenleg használt eszköz elég öreg, valamint korlátos a használhatósága.
Úgy döntöttem, hogy tervezek és építek egy újat.
"Ha az egyetlen szerszámod egy kalapács, akkor hajlamos vagy minden problémát szögnek nézni."
Tehát építsünk egy 3D nyomtatót!!!
A terv a következő:
Hardver (nagyrészt):
  • Építek egy fűtött platformot, amit egy Marlin firmware-el ellátott Arduino Mega-ról fogok vezérelni, a Marlin PID vezérlését használva, külső MOSFET-tel és a szokásos 100k-s NTC-vel mérve (aktuálisan Anettka eredeti MK8 fejéből szedtem ki)
  • Változtatható intenzitású világítás alulról (a Marlin doboz világítása)
  • Z tengely menetes szárral, Nema 17-es léptetőmotorral, DRV8825-ös vezérlővel, végálláskapcsolókkal. Erre felszerelve egy mikroszkópkamera. A tengely mozgása vezérli a fókuszt
  • A kamera és az Arduino egy PC-re kötve USB-n keresztül
Szoftver:
A következőt tervezem C#-ban megírni:
  • A fűtés vezérlése gcode-al, a megfelelő fűtési görbe elérése érdekében (A PID hangolása is közrejátszik)
  • A kamera képének rögzítése az időbélyeggel és a hőmérséklettel együtt
  • Az értékek (idő, hőmérséklet) beágyazása a kamera képébe
  • A Z tengely manuális vezérlése a gépről.
Később:
Autofókusz a kamera képe alapján, konvoluciós mátrix és hasonló "computer vision" vuduk felhasználásával.

A video és kamera kezeléshez az aforge.net könyvtárat tervezem használni, amit már korábban is használtam.

2018. május 6., vasárnap

Házautomatizálás - Docker építés

Elkezdtem a Docker infrastruktúra felépítését a Hyper-V szervereimen a házautomatizálás (és más) rendszereimhez.
A komfort zónám, ha linuxról beszélünk elsősorban az Ubuntura és a Debianra terjed ki. Különböző forrásokból azt hallottam, hogy Alpine linux-ok kéne a Docker-hez használni. Tulajdonképpen már belefutottam néhány előregyártott Docker image-be amik Alpine-on alapulnak a munkám során. Szóval úgy döntöttem, hogy az új rendszert Alpine-ra építem, ez jó lehetőség a tanulásra.
Első:
Letöltöttem a virtualizált gépnek optimalizált telepítőt, gyártottam egy Gen2-es Hyper-V gépet és elindítottam.
Igen, virtualizációra optimalizált, csak épp nem a Hyper-V-re. El se indult.
Második:
Letöltöttem a standard telepítőt. Ez végre elindult a Hyper-V-ben így felraktam egy vhdx-re.
Miután általában másolom az alap vhdx-et, az újabb virtuális gépek előállításához, az Alpine itt kap egy plusz pontot tőlem, miután nem kell a boot folyamatot patkolni ehhez mint az Ubuntunál.
Felraktam a nano-t, miután pár konfig fájlt szerkesztenem kell a kész gépeken, és szétmásoltam a vhdx fájlokat, elkezdtem gépeket gyártani belőlük.
Harmadik:
Beállítottam az IP címet, a gép nevét, a DNS-t, átjárót, stb. Csak a szokásos dolgokat.
Újraindítás után nem indult el mégegyszer. Az ok a chronyd. Miután nem tudta az internetről az időt begyűjteni, megállította a boot folyamatot. Örökre. Se konzol, se SSH.
Ok, kinyírtam a gépet, újragyártottam az alap vhdx-ből. Körültéztem, nem találtam semmi megoldást. Végül megnéztem a chrony csomag tartalmát és kiderült, hogy a timeout opciót a /etc/conf.d/chronyd fájlban tudom beállítani. Az ARGS opcióba beírtam: -t 60
Negyedik:
Átkonfiguráltam az SSH-t, hogy nekem megfeleljen, hozzáadtam azt a repo-t ami a Docker telepítéséhez szükséges extra csomagokat tartalmazza.
Felraktam az összes x64-es gépen a Dockert, beállítottam, hogy boot-nál induljon el.
Ötödik:
Elindítva a Docker-t ezt kapom:


Jónéhány próbálkozással sem sikerült ezt a dolgot rendbeszedni, de közben találtam cikkeket arról, hogy az Alpine nem alkalmas a feladatra:
http://janhapke.com/blog/alpine-linux-sucks-for-hosting-docker-containers/
http://www.nathanbak.com/?p=37

Döntöttem. Elfelejtem ezt és megyek vissza az Ubuntura. A következő próbálkozásom a vadiúj Ubuntu 18.04 LTS-el lesz.

Házautomatizálás központ

2016-ban elkezdtem dolgozni egy házautomatizálási projecten amit végülis félreraktam.
Azóta egyre jobban érzem, hogy tennem kéne valamit az ügyben. Miután befejeztem a Robo3D nyomtatóm javítását, nem volt aktuális projectem, tehát kiraktam egy szavazást ide a bal oldalra, hogy mi legyen a következő projectem.
A házautomatizálás központ lett az egyértelmű nyertes. Elkezdtem gondolkozni, hogy mit csináljak és hogyan.
A döntéseim:


  • Modulárisan akarom felépíteni a rendszert a központtal kezdve (a jelenlegi project csak a központról szól)
  • OpenHAB-ot fogok használni központként (ez az ami támogatja a meglévő Conrad FHT/FS20 termosztátjaimat)
  • Hibatűrő megoldást akarok
  • Akkor is működjön, ha nincs internet
  • Valami egykártyás mikrogépre fogom rakni (SBC)
  • 64 bites rendszer legyen - kicsit a jövőnek építem
  • Lehetőleg meglévő dolgokat szeretnék használni

A meglévő IT infrastruktúrámról - ennek jelentős befolyása van a döntéseimre:
Két, VPN-el összekötött helyszínem van. Az egyik a házam, a másik az irodám. Jelenleg 4 MS Hyper-V szervert futtatok. 3 az irodában 1 itthon van.
A rendszer alapvetően Docker-re fog kerülni. Azt tervezem, hogy építek, egy 1U-s rack dobozt, beleteszek két Pine64 panelt, két 5V-os tápot és talán még két SSD-t.
Két Docker Swarm cluster épül:

  1. Egy x64-es Cluster: két Manager/Worker kombinált node-al amik az irodai Hyper-V-kre kerülnek és egy csak Manager node-al ami az itthoni Hyper-V-re kerül.
  2. Egy ARM Cluster: két Manager node amik az irodai Hyper-V-kre kerülnek, egy ami az itthonira kerül ésa Worker-ek a Pine64 panelek lesznek.

Az OpenHAB konténer(ek) menn(ek) a Pine64-ekre, plusz GlusterFS, plusz HAProxy mint hibatűrő megoldás
Az x64 Clusterre mennek a kiszolgáló dolgok:

  • Privát dokker registry
  • Zabbix, vagy Nagios monitoring
  • Egyéb konténerek amik a munkámhoz kellenek (nem kapcsolódnak a házautomatizáláshoz)

Az adatgyűjtés és az MQTT vezérlés elhelyezését/megvalósítását még nem találtam ki.
Ha a fenti rendszer összeállt, akkor fogok a szenzorok és beavatkozó szervek integrációjával foglalkozni.

És igen, mielőtt megkérdeznéd - Komplett idióta vagyok. :-D