Author Archives: eFi

Home automation: építsünk detektívet!

Preface 2012 márciusában lecseréltük a hagyományos kazánt kondenzációsra és ha már lúd legyen kövér alapon telepítettünk mellé 5 m² váklumcsöves napkollektort is a hozzá való köcölékekkel (hőtároló puffer, hőcserélő, frissvíz modul, vezérlés, etc.) egyetemben. A választás némi kutatás után a Vaillant termékére esett. 2016 augusztus közepén egy meleg nyári napon forró etilénglikol szaga áradt a kazánházból. Elég volt egy pillantás a szabályzóra, hogy észrevegyük: a kinti hőség ellenére a kollektorokból egy csepp meleget sem szed le a rendszer. Ráadásul ekkor tűnt csak fel, hogy a baj már 2016 júniusában bekövetkezett, csak akkor nem vettük észre.

Melegcsináló HOWTO

Mielőtt a lényegre térnék, muszáj dióhéjban ideMórickázom, hogy működik a fűtésünk: r9-heating Gondolom rájössz magadtól, de azért: a rajzon a zöld az áramlási irányokat jelöli, a piros a meleg közeget, a kék a hideget. Az 1. napkollektoroktól a 2. szivattyú behúzza a hőszállító etilén-glikolt a 3. hőcserélőbe, aki a glikol melegét beletolja a 4. puffertartályba. Ha a háznak melegre van szüksége, akkor az 5. hőcserélővel a 6. szivattyú csinál a csapvízből meleget, vagy a 7. szivattyú a fűtési körökben levő folyadékokra melegít rá egy kicsit. Az egészhez persze csatlakozik még egy kazán is, de azzal most semmi dolgunk, úgyhogy ezért lehagytam a Mórickáról. A solar körön a 3. hőcserélő után van egy nyomásmérővel ellátott biztonsági szelep, amiből egy hosszú rézcső megy be egy nyitott puffertartályba. Erre azért van szükség, hogy ha valami hiba folytán a nyomás alatt levő solar kör belső nyomása elérné az 5 bar-t, akkor ez a biztonsági szelep egyszerűen leengedi a glikolt ahelyett, hogy hagyná felrobbanni a csöveket.

Nyomozás v1.0

Az augusztus közepén detektált problémát a szerelő úgy korrigálta, hogy újratöltötte a glikolt a nyomás alatt üzemelő rendszerben. A szakember arra tippelt, hogy valószínűleg hosszabb ideig nem voltunk otthon, így nem volt hőelvétel a pufferből és a termelődött meleget a vezérlés már nem tudta hova rakni, így ennek megfelelően a túlmelegedő glikol nyomása elérte az 5 bar-t, a biztonsági szelep leeresztett és onnantól nem volt ami lehozza a meleget a tetőről. Ezt el is fogadtam, viszont nagyon nem hagyott nyugodni, hogy a problémáról a rendszer semmiféle módon nem tájékoztat. A dolgot úgy veszed észre, hogy a kinti hőség ellenére azt látod a vezérlő kijelzőin, hogy aznap semmi hőt nem termelt a solar kör, illetve a hosszabb időtartamú kiesés is megfigyelhető egy buta havi bontású oszlopdiagrammon. Nekem ez kevés. Én tudni akarom, hogy pontosan mi történik a solar körben, illetve elektronikusan akarom detektálni azt, amikor ismét előáll a probléma és erről push notificationt akarok küldeni a fiúknak, akik majd riasztják a szervizest. Persze az igazi az lenne, ha a solar kör nem hibázna, ám mint pár óra telefonálgatás után megtudtam, erre a nyomás alatt levő solar rendszerek nem alkalmasak, csak a mostanában gyártott, önmagukat leereszteni és újratölteni képes kollektoros installációk. A sajátom természetesen ezekkel nem kompatibilis. Azt találtam ki, hogy a glikolt szállító csőre hőcserélő bemeneténél és a biztonsági szelepnél is teszek fel egy-egy PT-1000-es hőmérőt, 10 percenként mérek velük egyet és a mért értékeket naplózom egy sql táblába. Ezen felül azt gondoltam, hogy talán jó indikátor lesz a meghibásodásra, ha a bizontsági szelepnél mért hőmérséklet elér egy határértéket (70 ℃-ra saccoltam), aminek hatására már küldhetem is a figyelmeztetést a gyerekeknek. Felszereltem a hőmérőket, beállítottam a homeaut serverben a naplózást, megcsináltam a vizualizáló interfészt, körbeteszteltem szépen mindent és úgy gondoltam kész vagyok, de persze tévedtem. A következő meghibásodás kb. 2 héttel az előző hiba kijavítása után következett be. Sajnos a biztonsági szelep utáni hőmérséklet teszt nem bizonyult hatásosnak: a cső nem melegedett 45 ℃ fölé. Ennek ellenére a hőmérő naplózás nem bizonyult hiábavalónak – mindjárt meg is mutatom! A biztonsági szelepnél levő hőmérővel most nem foglalkozunk, elég tanulságos lesz a solar kör hőcserélőjének bemeneti hőmérséklete. Az első grafikonon azt látod, amikor a rendszer normálisan működik két egymást követő, kb. egyformán meleg napon: solar-temp-log-OK Ezen pedig jól látszik, hogy a 2. napon 9:30 tájban pusztul meg ismét a rendszer: solar-temp-log-FAILURE Két egymást követő kb. egyforma napon a normál működést tanulmányozva nagyon jól látszik, hogy mi történik a rendszerben:
  • 6:10: az éjszaka után beindul a solar szivattyú. Az ezt követő 10 percben ~10 ℃-t esik a hőmérséklet, mivel az éjszaka során meghűlt a kollektorban levő glikol és a szivattyú épp ezt a hidegebb folyadékot hozza le a hőcserélőbe. A kollektor és a hőcserélő közti csőszakasz valamint a padlástér is vastagon szigetelt, ezért abban csak nagyon lassan hűl ki a hőszállító folyadék – ez láthatod az éjféltől kezdődő első szakaszon.
  • 7:20: felkel a nap, a kollektorok elkezdik termelni a meleget.
  • 15:00: a hőtermelés csúcsa, kb. ekkor süti optimális szögben a nap a kollektorokat. Innentől kezdve lassan csökken a glikol hőmérséklete, de még mindig van bőven hőmermelés.
  • 20:00: lemegy a nap, a hőmermelés megszűnik. A hőtároló pufferben már legalább 60 ℃ hőmérsékletű víz van, így az ennél hűvösebb glikolból a hőcserélő már nem vesz el meleget. A görbe simulása egyenletesebbé válik, ami azt is jelzi, hogy a szivattyú már nem keringtet, a csőben levő hőszállító folyadék magától hűl le lassan.
Ha ránézel a 2. ábrára, akkor arról a fentiek alapján a meghibásodás napján (=kék diagram) ugyanígy leolvasható a történet:
  • 9:00: A lassan hűlő glikolt 6:10 helyett 9:00-kor mozdítja meg a keringtető szivattyú. A hőcserélő visszahűlése jóval kevesebb ideig tart, mivel a kollektor ilyenkor már baromi meleg.
  • 9:30: a hőmérséklet ezerrel emelkedik.
  • 9:50: az utolsó mért meleg érték – a nyomás alatt levő csőrendszer itt éri el az 5 bar határértéket, a biztonsági szelep leereszti a glikolt. Innentől már csak a lassú kihűlés marad, mivel nincs hőszállító közeg.
A fentieket megmutattam a szerelőnek, aki a rendszert ismét átnézve arra jutott, hogy a hőcserélő szivattyúja adta meg magát. Én továbbra is azt látom a diagrammokon, hogy az eltelt 2 hétben a szivattyú minden nap 6:10-kor indul, kivéve a meghibásodás napját, amikor 9:00-kor mozdította meg először a folyadékot. Szerintem inkább a vezérléssel nem stimmel valami. A második hiba után szeptember 5-én a csöveket trisóval átmosták, a hibásnak gondolt szivattyút kicserélték, majd 2 nappal ezután a következőt rajzolta nekem reggelire a log: solar-temp-log-WARNING A kék vonal megint azt mutatja, hogy a szivattyú egy órával később kapcsol. A vezérlésnek nincs internetkapcsolata, tehát nem tud az időjárásról, mindössze annyit ismer a környezetéből, hogy Magyarországra telepítették és hogy épp mennyi a pontos idő.

Nyomozás v2.0

A fentiek alapján azt feltételezem, hogy a rendszer hamarosan ismét megadja magát. A logok nekem már most is egyértelműek, viszont ettől lehetnének egy picit még precízebbek is, ezért a következő tuningot eszeltem ki:
  • A biztonsági szelepen levő hőmérő átkerül a hőcserélő kimeneti oldalára, így a két mért értékből jól látszik majd, hogy a puffer felvette-e a tetőről lehozott hőt.
  • A szivattyú tápellátására párhuzamosan rákötök egy 230 V AC-re kapcsoló relét, aminek a kapcsolt NO lábát odaadom egy digitális bemenetnek a homeaut buszon. Ezzel értesülni fogok arról, hogy mikor indult és mikor állt le a szivattyú.
  • Ha már tudom, hogy mikor megy a solar szivattyú, akkor elég lesz akkor megmérnem a két hőmérsékletet – illetve egész pontosan mondjuk 30 másodperccel a szivattyú indulása után, hogy biztosan a lehozott hőszállító folyadékot mérjem.
Amióta ern0vel összeraktuk a dataflow alapú homeaut servert, nincs az a probléma, aminek a megoldását ne lenne élvezetes implementálni homeaut oldalon egy kis dataflow script módosítással. Lényegében az egész terjengős posztot azért kellett végigrágnod, hogy meg tudjam mutatni neked, hogy csináltam!-) A fizikai adatbuszról a fenti probléma megoldásához kétféle adatra van szükségünk: egy digitális bemenetére (amire a keringtető szivattyú tápjával vezérelt 230 V AC-s relét kötöm) és a PT-1000-es hőmérők által mért analóg értékekre. A digitális inputokat 100 msec-enként lekérdezem egyben, úgyhogy az már kész, viszont a házban levő 8 darab PT-1000-es hőmérőt csak 10 percenként kérdeztem le eddig, mert a többit bőven elég ilyen lépesközzel naplózni, a két solar hőmérő naplózását viszont a szivattyú bekapcsolásának kellene vezérelni mostantól. A dolog azért problémás, mert a 8 darab hőmérőből 4-et csak egyszerre tudok lekérdezni a Wago MODBUS interface-en. Szerencsére itt van a kezem alatt a dataflow nevű rágógumi, amit a végtelenségig lehet nyújtani – nézzük meg, hogy hogyan csinálom!

Dataflow gyorstalpaló

Ha tudod, mi az a dataflow, akkor menni fog az is, ami lejjebb következik – ha viszont nem, akkor ern0 barátom eldarálja neked elképesztő sebességgel 10 percben (amiből a második ~5 perc már csak a kérdésekre adott válasz):

Dataflow from Budapest New Tech Meetup on Vimeo.

ern0 közben feltöltötte youtube-ra a tavalyi hosszabb dataflow meetup videót is – hardcore rajongóknak kötelező ez is:

Megoldunk

Ezek után lássuk, hogy raktam mindezt össze: log_df_visualized Ha inkább a scriptet olvasnád, mint a vizualizált ábrát, az így néz ki (btw a fenti rajzot ern0 kódja generálja graphvizzel a lenti dataflow scriptből :)):
component Main {
	implementation {
		carpet log {
			// create pulsars
			p100ms: RTCPulsar
			p100ms.freq = 100000
			p1s: RTCPulsar
			p1s.freq = 1000000
			// create 10 min scheduler
			p100ms.out >> sched10min.clock
			sched10min: Scheduler
			sched10min.mask := "schedule={mi=0,10,20,30,40,50 se=0}"
			// feed Wago digital poll
			p100ms.out >> wdp.digipoll
			wdp: WagoPoll
			wdp.digibase = 0
			wdp.digipollsize = 96
			wdp.anabase = 0
			wdp.anapollsize = 4
			wdp.serout >> s1.in
			s1: Serial
			s1.device := "wago_ip:502"
			s1.out >> di4_1.serin
			di4_1: WagoDigiIn
			di4_1.base = 48
			// feed Wago analog poll
			p1s: RTCPulsar
			p1s.freq = 1000000
			p1s.out >> wap.anapoll
			wap: WagoPoll
			wap.anabase = 0
			wap.anapollsize = 4
			wap.serout >> s2.in
			// Wago bus
			s2: Serial
			s2.device := "wago_ip:502"
			// split Wago analog input msg
			s2.out >> ai1.serin
			ai1: WagoAnaIn
			ai1.base = 0
			ai1.size = 8 // 4 input, 2 byte/input
			// store temps in Value components
			ai1.out1 >> temp1.setvalue
			ai1.out2 >> temp2.setvalue
			ai1.out3 >> temp3.setvalue
			ai1.out4 >> temp4.setvalue
			temp1: Value
			temp2: Value
			temp3: Value
			temp4: Value
			// send measured temps to sql loggers from the first 3 thermometers
			sched10min.out >> temp1.in
			sched10min.out >> temp2.in
			sched10min.out >> temp3.in
			temp1.out >> sql1_1.in
			temp2.out >> sql1_2.in
			temp3.out >> sql1_3.in
			temp4.out >> sql1_4.in
			// define sql loggers for all 4 thermometers
			sql1_1: Shell
			sql1_1.command := "./log_temp.py r9_nagyhaz_nappali"
			sql1_2: Shell
			sql1_2.command := "./log_temp.py r9_solar_test"
			sql1_3: Shell
			sql1_3.command := "./log_temp.py r9_utca"
			sql1_4: Shell
			sql1_4.command := "./log_temp.py r9_napkollektor"
			// di4_1.out1 = solar pump power state change
			di4_1.out1 >> change4_1.value
			change4_1: Change
			change4_1.last = 0
			change4_1.zero >> log_solar_pump.in = 0    // log pump OFF state
			change4_1.nonzero >> log_solar_pump.in = 1 // log pump ON state
			change4_1.nonzero >> d30s_4_1.in           // log temp with delay after pump switched on
			// log solar pump state
			log_solar_pump: Shell
			log_solar_pump.command := "./log_di.py r9_solar_pump"
			// log thermometer wiuth a 30 sec delay
			p100ms.out >> d30s_4_1.clock
			d30s_4_1: Delay
			d30s_4_1.delay = 300
			d30s_4_1.out >> temp4.in // log temp with 30s delay after pump has started
		}
	}
}
Elmagyarázom a rajzot – a legjobb, ha kinyitod teljes méretben 🙂
Start
Kezdetben azt csináltam, hogy egy 10 perces scheduler (=sched10min) lökdöste meg az analog inputokat pollozó wap komponenst és az abból kiálló ai1 analóg poll értelmező meghívott négy darab, sql insertet elvégző scriptet (sql1_1..sql1_4), akik megcsinálták a naplózást. Ezzel az a baj, hogy a 4. hőmérőt csak akkor akarom naplózni, amikor a szivattyú beindul, a többi meg maradhat 10 percenként.
Flow detection
Első körben detektálni kellett a szivattyú indulását. Ehhez csak a solar vezérlőből a szivattyúnak adott 230 V AC tápra kell párhuzamosan rákötni egy 230 V AC által kapcsolt relét, aminek a másik végébe jön a 24 V DC kimenetünk, akit a buszon a di4_1 modul out1 lábára kötünk. Nekem akkor kell naplóznom a solar folyadék hőmérsékletét, ha a szivattyú megindul (egész pontosan kicsivel utána), így a di4_1.out1 láb 0-ról 1-re történő állapotváltozása kell, hogy kiváltsa a naplózást. Az állapotváltozás detektálására ott van a change4_1 komponensünk, aminek a zero illetve nonzero lábain csak akkor jelenik meg trigger, ha a bemenetén az előző inputhoz képest más adat jelenik meg.
Logging
Innentől már nincs nehéz dolgunk, csak be kell kötni a change4_1.nonzero kimenetet a d30s_4_1 30 másodpercre állított delay komponensbe, akinek az out kimenetével indíthatjuk a naplózást.
Analog poll
Az analóg input olvasásán is változtatni kellett. Egyrészt a 10 perces kérések helyett másodpercenként kérdezzük le a modult (ezért bökdösi a p1s 1 másodperces Pulsar komponens a wap analóg input poll generátort a korábbi sched10min 10 perces trigger helyett), másrészt az ai1 analóg input választ feldolgozó komponens lábait a közvetlen naplózás helyett a temp1..temp4 Value komponensekbe kötögettem. A temp1..temp4 value komponensek tárolják a mért értékeket, a kimenetük indítja meg a bennük levő érték naplózását, amit az sql1_1..sql1_4 Shell komponensek végeznek el. A temp1..temp4 komponensekből az első hármat a sched10min 10 perces időzítő triggereli, míg a negyediket (amiben a solar folyadék hőmérsékletét tároljuk) a di4_1.out1 komponens kimeneten megjelenő 0->1 érték változás indítja.
Extras
Ha már egyszer detektálom a szivattyú indulását (és leállását is, hiszen a change4_1 komponens mindkét állapotváltozást megadja), akkor ezt is simán lehet naplózni – erre való a change4_1 zero és nonzero lábaira kötött log_solar_pump komponens. Innentől a következő hibánál nincs vita, hogy mikor indította el a solar vezérlés a szivattyút.

Szummárium

Hétvégén megcsinálom a hardveres részt is, aztán még készül hozzá egy olyan diagram, ami a solar kör hőmérő által mért értékeket együtt mutatja a keringtető szivattyú állapotváltozásával és onnantól már kellőképpen felvegyverkezve várom a következő hibát.]]>

3D nyomtatás: miért ne vegyél indirekt extruderrel szerelt printert?

direct-extrusion Image source: fabbaloo.com Ezzel szemben az indirekt extrudereknél az extruder és a hotend között egy teflon bovdenben halad a műanyagszál, így a továbbító mechanika és a nyomtatófej között 50-70 cm-nyi távolság van: indirect-extrusion Image source: fabbaloo.com Az indirekt extrudereknek az az értelme, hogy az extruder tömegét leválasztják a hotendről és így a nyomtatófejet gyorsabban lehet mozgatni, némi sebességnövekedést elérve ezáltal. Ez egész addig hangzik jól, amíg megveszed az indirekt extruderes printert, elkezded használni, majd minden filament tekercs végén tapasztalod, hogy az indirekt extruder miatt 50-70 centi műanyagszál megy a kukába, mert ezt az utolsó 50-70 centit már nem tudja betolni a fejbe az indirekt extrudered. Ez a kupac a nálam keletkezett filament hulladék egy része: indirect-extrusion-filament-waste Emellett az indirekt extruderes megoldásnál jóval kevésbé lehet precízen visszarántani a fejből a nyersanyagot nyomtatás közben (=retraction), ami aztán külön extra kalibrációs macerát jelent csak. Summa summarum, ~4 év 3D print tapasztalatával mondhatom, hogy az FDM nyomtatóknál nem érdemes a sebességet hajszolni, mert az a minőség rovására mehet. Inkább spórolj nyersanyagot és válassz egy direkt extruderes nyomtatót.]]>

Emberek, akiktől többet nem rendelek munkát: Dr. Kérchy Judit és hivatala – Casarecce edition

Preface: tényleg nyitnunk kéne egy kifőzdét… Kb. három héttel ezelőtt megírtam itt a blogon egy velünk megesett sztorit. A történet főszereplője Dr. Kérchy Judit közjegyzői hivatala, akitől ma az alábbi személyiségi jogi perrel fenyegető bejegyzést kaptam:

Dr. Kérchy Judit közjegyző levele a blogbejegyző és mindazok részére, akik a közjegyzői iroda jóhírnév sérelmét másoló megjelenéseket közzé tették. „Az Ön által 2016. július 12. napján az fns.pappito.com internetes oldalon közzétett, az 51012/H/567/2016. ügyszámú tanúsítvány kapcsán előadott tényállítások alkalmasak a közjegyzői iroda, valamint a saját jóhírnevem megsértésére. Ön a valós tényt hamis színben tüntette fel akkor, amikor dr. Müller Ágnes közjegyzőhelyettes által kiállított tanúsítványra vonatkozóan azt állította, hogy „Egy irat vagy hiteles, vagy nem hiteles – nincs benne fuzzy logic típusú „talán”. A közjegyzőhelyettes ezzel szemben a jogszabályok teljes mértékben történő betartásával járt el, ugyanis a tanúsítvány kiállítása kapcsán a közjegyző annak a felmutatott irattal való egyezőségéért felel. A közjegyző által készített másolatnak az eredeti okiratéval kizárólag akkor azonos a bizonyító ereje, ha a közjegyző a hitelesített másolatot az eredeti okiratról készítette. A tanúsítvány ezzel szemben csak azt igazolja, hogy a közjegyző a másolatot összehasonlította a felmutatott okirattal, és azok egyezőségét megállapította. A felmutatott okirat eredetiségét azonban nem tanúsítja. (BDT 2016/6/94.) Ön megjelent a közjegyző előtt egy fénymásolattal, amelyet az egyetem által kiadott hiteles másolatnak titulált. Tekintettel arra, hogy a közjegyző az eredeti dokumentumot nem látta, így csak az Ön által elmondottakra hagyatkozhatott a hiteles másolat készítésénél, amelyet a tanúsítványban az „állítólag” szóval jelzett is, mint számára aggályos körülményt. Az Ön vélekedésével ellentétben a közjegyző nem a felmutatott irat eredetiségét vizsgálja, hanem arról állít ki tanúsítványt, hogy az általa kiállított másolat a felmutatott okirattal megegyező. Ezt a tanúsítvány tartalmazza is. Az Ön által leírtakból kikövetkeztethetően az Országos Fordító és Fordításhitelesítő Iroda csak a ténylegesen eredeti iratról készített hiteles másolatot fordította volna le, ennek elmaradása azonban az Ön terhére esik, hiszen a közjegyőhelyettes előtt nem az eredeti okiratot, hanem arról csak egy másolatot mutatott be, amiről a közjegyzőhelyettes nem adhatott ki olyan másolatot, amely azt tanúsítja, hogy az az eredetinek felel meg, mivel arról ő személyesen nem győződhetett meg. Ön tehát a valós történteket hamis színben tünteti fel azáltal, hogy az Offi általi fordítás hiányát a közjegyzőhelyettesnek rója fel, amellyel szemben a valóság az, hogy saját felróható magatartásának következtében nem sikerült hiteles fordítást szereznie. Kérem a fentiek tudomásulvételét és a jóhírnevemet sértő blogbejegyzés azonnali eltávolítását! Amennyiben jelen kérelmemnek nem tesz eleget, úgy peres eljárást indítok személyiségi jogom megsértésének megállapítására és sérelemdíj megfizetésének kötelezésére.” Dr. Kérchy Judit közjegyző
Megbeszéltük a családdal a történetet és arra jutottunk, hogy mivel nem hiányzik egy személyiségi jogi per, így eleget teszek a közjegyző asszony kérésének és eltávolítom az eredeti bejegyzést, az ahhoz írt olvasói megjegyzésekkel egyetemben. Persze a fejemből nem tűnik el, így a közjegyző asszonynak továbbra sem fogok munkát adni és erről az ismerőseimet is le fogom beszélni. Jól felqrtam az agyam az egészen és ilyenkor mit tud csinálni a 130 kilós, 4 fal között dühöngő medve, na mit? Hát otthagyja a gépet és nekiáll mondjuk… ööö… főzni, ez az!-) Csináltam is gyorsan egy erdei gombás casareccét, mert Era (akit mindenkinél jobban szeretek a világon) remélem nemsokára hazaér és ő ezt enne vacsorára. Ilyen lett e: gombas-casarecce Jó chilis lett, isteni illata van a tetején a parmezánnak, hidrofóniás friss kakukkfüvet tettem bele és mivel Tibi barátom megjegyzésein röhögtem a legjobban, az ő tiszteletére kapott egy kis Fernway Sauvignon Blanc-t is a szaftba. Tibb, esküszöm gyártok neked ilyet! ]]>

3D nyomtatás: G1WH dashcam mount 2009-es Subaru Legacy és 2015-ös Subaru Forester modellekbe

G1WH dashcamet. Most jutottam el odáig, hogy a kamera saját, undorító mountja helyett gyártsak egy megfelelőbbet a két autóba – a Legacyban így néz ki: G1WH-custom-dashcam-mount-in-2009-Subaru-Legacy Erről a dashcamről van szó: Éles szemű olvasóink már megfigyelhették az ojjektumo(ka)t a 12-es naEzMi posztban, amiért Petinek lógok egy sörrel. Csináltam hozzá szexi assembly HOWTO videót is: A modelleket most is viheted a youmagine-ről.]]>

Mac workflow: Alfred translate-shell CLI translation

a dict.cc szótáraihoz csináltam Alfred workflowt. Nemrég szembejött a csodás shell-ben való fordításhoz írt translate-shell, amely használja a Google Translate, Bing Translator és a Yandex online service-eket, ráadásul a fejlesztők naprakészen tartják az alkalmazást, így ha a Google teker egyet az API-n, csak a translate-shellt kell frissíteni és már működik is újra minden. Ez kell nekem, ebből csináltam is gyorsan egy Alfred workflow-t (a workflowban szerepel egy, az Alfred 3 által bevezetett var/arg manipulator widget, így Alfred 2-vel nem lesz kompatibilis, de mivel az Alfred 3 már kijött a bétából, így ez nem lehet gond). A trans workflow “trans” keywordjét a translate-shell szintaxissal kell használni: trans-keyword trans-output trans-multilang trans-multilang-output A nyelv-specifikus keywordöknél a target language előre definiált és a kifejezéseket nem kell idézőjelbe tenned: thu-keyword trans-output A trans workflow-t viheted innen, vagy a packal.org-ról.]]>

3D nyomtatás: expectation vs. reality

iPhone6s-arca-swiss-mount-render iPhone6s-arca-swiss-mount-IRL-fail Szakértsünk:

  • vagy túlmelegszik a stepper driver
  • vagy megszorul valamelyik bronz bushing az X tengelyeken
  • vagy törött / csúszik az X tengely és a léptetőmotor közötti rugós Al coupler
  • vagy megzakkant az X irányért felelős NEMA 17
Summarium: a 3D print még nem mindig tart ott, hogy megnyomom a gombot és kijön a termék.]]>