Ötdimenziós tárgyak nyomtatása 3D nyomtatóval

Pontosan 5 évvel ez előtt ezen a napon vált online elérhetővé a British Journal of Psychology 49. évadának 1. száma, amelyben Lionel Penrose és fia, Roger Penrose Impossible Objects címmel publikált egy cikket olyan tárgyakról, amelyek szerintük nem létezhetnek. Ezek közül talán a Penrose-háromszög a legismertebb:

5d-penrose-triangle

A cikk eredetije jóval korábban, 1958-ban jelent meg, és az azóta eltelt több, mint 50 év alatt a tudomány sokat fejlődött. Mai tudásunkkal már kijelenthetjük, hogy Penrose-ék tévedtek, ezek a tárgyak igenis létezhetnek, a modern 3D nyomtatási technológia segítségével mi magunk is létrehozhatjuk őket.

Első lépésként egy modellre lesz szükségünk, amit ki tudunk nyomtatni. Itt jön az első probléma, ugyanis a hagyományos térbeli rajzoló alkalmazások maximum három dimenzióval tudnak megbirkózni, márpedig itt nekünk többre lesz szükségünk. Azaz felejtsük is el rögtön a SketchUpot, a Blendert, az AutoCADet, a Mayat, TInkercadet stb., hiszen ezek csak 3D-ben tudnak gondolkodni.

Az egyetlen lehetséges megoldás (legalábbis én másról nem tudok), hogy a modellünket kódban írjuk le, amire szerencsére létezik már bevált, és elterjedt megoldás, az OpenSCAD. Kiváló eszköz! Aki csak egy kicsit is vonzódik a programozáshoz, annak csak ajánlani tudom, hogy így írja le a 3D modelljeit. Mivel itt kóddal dolgozunk, nem korlátoz minket a háromdimenziós tér, bátran használhatunk olyan transzformációkat, amik további dimenziókba viszik a modellünket. Amire szükségünk lesz, az a to5d() metódus, ami az OpenSCAD CheatSheeten a Transformations csoportban található:

5d-openscad

Ha így sikerült elkészíteni az ötdimenziós modellünket, jöhet is a nyomtatás, aminek első lépése az STL modell szeletelése. Én ehhez leggyakrabban Curat szoktam használni, mert számomra nagyon átlátható a felülete. Sajnos talán pont az átláthatóság miatt számos opció nincs kivezetve az alap felhasználói felületre, hanem csak az Expert config ablakban érhető el:

5d-cura-expert-config

Sőt, az ötdimenziós nyomtatás még ide sincs alapból kivezetve, de a figyelmesebb szemlélők észrevehetik, hogy míg a legtöbb szöveg egymástól függőlegesen egészséges távolságra van elhelyezve, addig a Black Magic kategóriában nagyon össze vannak zsúfolva a sorok. Ennek az az oka, hogy ha bepipáljuk az első két opciót, akkor megjelenik egy harmadik Enable more dimensions néven, pipáljuk be ezt is:

5d-cura-black-magic-settings

Ez után már nem lesz gond az OpenSCAD-ből exportált 5D STL fájl megnyitása, amit azután a szokásos módon nyomtathatunk. Íme, nekem így sikerült a Penrose-háromszög:

5d-triangle

Íme egy másik fénykép, együtt egy 3D tárggyal:

5d-triangle-with-pencil

A képet a telefonommal, vaku nélkül készítettem, az élek egyenetlensége pedig a hobbi kategóriás nyomtatóm tökéletlenségének az eredménye.

Az első “lehetetlen” tárgyam létrehozása után következő lépésként a svéd Oscar Reutersvärd kockákból felépített háromszögét nyomtattam ki, amit ő eredetileg így képzelt el (Forrás: Wikipedia):

5d-reutersvard-triangle

Ennek az OpenSCAD modellje egyébként még egyszerűbb, hiszen csak kilenc darab kockát kell létrehozni. Miután ez megvan, megnyithatjuk a modellt Curaban:

5d-cura-preview

Az előnézeti képen jobb oldalon, alulról a második kockánál látszik egy világosabb sárga rész, amit nem tudok megmagyarázni. Szerencsére csak a kép renderelése hibás, a nyomtatás simán ment, íme az eredmény:

5d-cubes

A lehetetlen objektumok kapcsán eszembe jutott M.C. Escher híres képe a végtelen lépcsőházról, ezért elkészítettem annak is a modelljét, így mutat Curaban:

5d-cura-stairs

Amint elkészül vele a nyomtató, feltöltöm a fotót.

A fenti példákból is látszik, hogy a 3D nyomtató már nem csak háromdimenziós tárgyak nyomtatására használható, ne ragadjatok le a 3D-nél!

 

Technorati-címkék:

3D nyomtatás: 15 modell, 15 tapasztalat

Egy hónappal ez előtt a LogMeIn jóvoltából szerencsés tulajdonosa lettem egy 3D nyomtatónak. Mivel a konkrét típus kiválasztása is az én feladatom volt, vásárlás előtt alaposan körbejártam a témát, így azzal a gondolattal állhattam neki a 3D nyomtatásnak, hogy tudomány ide vagy oda, a sikeres nyomtatáshoz leginkább bizony szerencse kell. A 2D és a 3D nyomtatás egyszerűsége és megbízhatósága között ugyanis ég és föld a különbség. Minden nyomtatás tartogat magában nehézséget, meglepetést és tanulságot is. Rendszerint többet, mint amire számítanánk.

1. “Okay”

A gyártó útmutatásait követve elsőként azt a modellt nyomtattam ki, ami a nyomtatóval érkezett:

okay-hand

A dolog pofonegyszerűnek tűnt, mert a modellből készített GCODE fájl rajta volt a nyomtatóhoz kapott SD kártyán, nem kellett semmilyen paramétert állítani, gyakorlatilag csak a Print gombot kellett megnyomni. Gondoltam ha a nyomtató hardverileg rendben van és jól van betöltve a nyomtatószál, akkor ennek sikerülnie kell.

“Szinte” sikerült is, ez lett belőle:

okay-hand-printed

Hát majdnem ugyanaz. Történt ugyanis, hogy nagyjából félórányi nyomtatás után egy finom pattanást követően elmozdult a tárgy a tárgyasztalon, onnan kezdve pedig kuka az egész.

Tanulság:

  • A tárgyasztal tapadása az egyik legfontosabb tényező a sikeres nyomtatáshoz, mégis mindenki küzd ezzel. Vannak házi módszerek, drága felületek, de igazán 100%-os, egyszerűen használható, jól tapadó, de könnyen eltávolítható megoldás nincs (legalábbis én nem tudok róla).
  • A nyomtatóval együtt vásároltam a tárgyasztalra egy üveglapot, hogy biztosan sík legyen a felület, a szintezés ugyanis a másik kritikus tényező a sikeres nyomtatáshoz. Elméletileg ez a tapadáson is segíthet, ám azt nem szabad elfelejteni, hogy lefogja egy kicsit a tárgyasztal fűtését. Az én nyomtatómhoz üveglap nélkül másoknak bevált a 60°C-os tárgyasztal, nekem viszont biztos több kell az üveglap miatt. A későbbiekben 70°C-os tárgyasztallal nyomtattam, és jobbak lettek az eredmények.

2. Kalibrációs kocka

Második kísérletként a nyomtató precizitását próbáltam ki egy sima kalibrációs kocka segítségével, ami ilyen bonyolult:

calibration-cube

Egy pontosan 20×20×20 milliméteres kockát akartam nyomtatni, ami nem tűnik nehéz feladatnak. A nyomtatás igen jónak indult, ám végül csak ez lett belőle:

calibration-cube-printed

Az ok ugyanaz: a tárgy elmozdult a tárgyasztalon.

Ezzel együtt a nyomtatás nem volt teljesen hiábavaló, mert ebből is tanultam két dolgot:

  • Ez a nyomtató meglepően pontos. Hagyományos kézi sublerrel mérve a kocka alapjai 20,0 × 20,0 milliméteresek. A második tizedesjegynél biztosan van eltérés, de az már nekem belefér.
  • Nem élhetek hajlakk nélkül!

3. Kábelvezető

A 3D nyomtató tulajdonosok előszeretettel nyomtatnak 3D nyomtató alkatrészeket. Vagy azért, hogy tuningolják a nyomtatójukat, vagy azért, hogy valami problémát küszöböljenek ki. Az én esetemben az utóbbi fordult elő, a mozgó tárgyasztalhoz vezető kábel ugyanis előszeretettel akadt be a nyomtató vázának egyik merev sarkába. Persze nem én voltam az első, aki ezt tapasztalta, van már rá megoldás a Thingiverse-en:

cable-protector

Letöltöttem, és alig pár perc alatt sikeresen ki is nyomtattam:

cable-protector-printed

Ezen a képen, ilyen brutálisan felnagyítva (az eredeti kb. 3 × 1 cm) nem tűnik valami szépnek, a valóságban azonban egészen rendben van. Tökéletesen illeszkedik, és ami még fontosabb, tökéletesen működik is.

Ez volt az első sikeres nyomtatásom, és persze ebből is tanultam:

  • A 3D nyomtatással valóban meg lehet oldani valós problémákat, viszonylag gyorsan. Persze ezt a modellt valakinek el kellett készítenie, de már rengeteg modell érhető el a neten, és nagyon jó esély van rá, hogy a te problémádba más már belefutott, és rajzolt hozzá egy modellt. Lelőhelyekből nekem legjobban a Thingiverse jött be, de sokan a YouMagine-re esküsznek, míg mások az Instructablest preferálják. Persze rengeteg ilyen gyűjtemény oldal van.
  • A sikeres nyomtatás egyik oka, hogy végre nem volt gondom a tárgyasztal tapadásával. Egyrészt mert 70°C-ra fűtöttem, másrészt mert követve az egyik legjobb népi praktikát, hajlakkot fújtam rá nyomtatás előtt. Igen, kutya közönséges hajlakkot. Soha nem gondoltam volna korábban, de Garnier Fructis Extra Strong hajlakk van az asztalomon, és nem csak, hogy minden nap használom, de nem tudok nélküle élni! (Kérem ezt a mondatot senki ne ragadja ki a környezetéből.) Annyira jól működik, hogy meleg tárgyasztalról le se tudom vésni az eredményt, meg kell várnom, amíg lehűl a nyomtató, akkor viszont egy jól irányzott pofonnal simán lejön.

Na, itt tart ma a 3D nyomtatás: hajlakk és pofon kell a sikerhez (vö. a 2D nyomtatás mennyire sima ügy ehhez képest).

4. Szintező csavar

Megörülve a sikeres nyomtatásnak, és megmámorosodva a nyomtató tuning “képességeimtől”, következőként ezt a modellt nyomtattam ki:

thumbwheel

Ilyen lett az eredmény:

thumbwheel-printed

Ez egy kézzel tekergethető csavar anya, ami jelentősen egyszerűsítheti a tárgyasztal szintezését, különösen, ha önzáró anya kerül bele.

A nyomtatás a korábbiak alapján már sima ügy volt, de emlékezetes:

  • Azt hittem, szét fog esni a nyomtató, annyira rázkódott a modell szélén lévő apró kiszögellések nyomtatása közben. Elsőre nagyon meglepett, de azóta más modellnél is találkoztam vele, és eddig minden rendben van.
  • Az ennyire apró részletek nem lesznek tökéletesek, hiába állítom 0.1 mm-re a rétegvastagságot. Itt főként a felületből “vésett” számokra és rovátkákra gondolok, amiket a nyomtató nem kimar, hanem a következő réteggel körberajzol. Bár olvashatóan látszanak a számok és a jelölések, a számok vonalának a vastagsága nem egyenletes – de persze ez csak közelről megnézve látszik.
  • A modellnek a tárgyasztallal érintkező része igen minimálisan, de kicsit “szétfolyik”.
  • Ilyen rücskös szélű modellnél nem célszerű karimát (brim) nyomtatni, mert nem lehet szépen leválasztani.
  • A fém csavar tökéletesen illeszkedik a műanyagba, pontosabban alig tudtam belepasszírozni, de utána nagyon jól szorul. Ehhez biztosan a tervező kitartó kísérletezése kellett, de a végeredmény nagyon jó. Mindenféle ragasztó nélkül jól kombinálható a műanyag és a fém.

5. Lehetetlen fecskefarok csapolás

Ennyi tisztán praktikus nyomtatás után a választásom egy szórakoztató modellre esett, ami a hagyományos fecskefarok csapolásnak egy lehetetlennek tűnő változata:

impossible-dovetail

Nekem nem volt bátorságom nyomtatószálat cserélni, ezért egyféle anyagból nyomtattam ki a modell két felét:

impossible_dovetail_parts

Amik tökéletesen illeszkednek:

impossible_dovetail_assembled

Elégedett vagyok az eredménnyel, pontos, és pont annyira laza, amennyire kell.

De:

  • Majdnem letörtem a modell egyik sarkát, miközben próbáltam lefeszegetni a tárgyasztalról, annyira jól fogta a hajlakk. Azóta nem feszegetek semmit, inkább várok, amíg lehűl a tárgyasztal.
  • A felső képen látszik, hogy nem tökéletes a tárgy teteje. Úgy állítottam be a szeletelő programot, hogy 10% legyen a modell kitöltése, azaz ne legyen tömör, mert itt nem szükséges akkora szilárdság, viszont így gyorsabb lesz a nyomtatás, és kevesebb nyomtatószálat használ. Arra viszont nem gondoltam, hogy ha az üreges modellt nem fedem be elég vízszintes réteggel, akkor ott be lehet látni, nem lesz tökéletes a fedés. Ezt okozhatja az, hogy a nyomtatófej nem nyom elég nyomtatószálat (under extrusion), aminek a módosítása viszont a modell minden részére kihatna, ezért inkább azt a megoldást választottam, hogy a következő nyomtatásoknál emeltem az alsó és felső rétegek számát (Bottom/Top thickness beállítás Cura-ban).

6. Microsoft Band töltő

Ennyire kísérletezés után ideje volt valami mindennapi használati tárgyat is nyomtatni, így rögtön felcsillant a szemem, amikor megláttam ezt a modellt (a képet a Microsoft 3D Builderéből fotóztam, ami egy egészen jó program):

band-stand

Ez egy dokkoló, amibe beleteheti az ember tölteni a Microsoft Band típusú okosóráját. Mivel a modell hátulja tartalmaz közvetlen alátámasztás nélküli vízszintes felületeket, ezért úgy döntöttem, hogy támaszanyagot fogok nyomtatni. Ilyen lett az eredmény:

band-stand-printed

Tanulságok:

  • A támaszanyag lutri. Lehet, hogy nem is kellene (ennél a modellnél talán elhagyható lett volna), de ez sajnos csak nyomtatás után derül ki. Modelltől függően néha nagyon egyszerű eltávolítani, néha viszont nagyon macerás. Itt például nekem ezt az üreget teljesen meg kellett tisztítanom, hogy be tudja fogadni a töltő csatlakozóját, és ez a kicsi, íves felületek miatt nagyon nehéz volt, majdnem addig tartott, mint a nyomtatás.
  • A ferde felületek lépcsősek lesznek, még akkor is, ha nagyon kicsi rétegvastagsággal nyomtat az ember. Ezt lehet csiszolni, ABS-nél acetonozni, vagy csak simán el lehet viselni. Indusztriális dizájn. Ki tudja, a látszó beton és a dekor rozsda után lehet, hogy ez lesz a következő trend. A lényeg, hogy számítani kell rá. Ennél a modellnél elvileg meg lehet azt tenni, hogy elforgatom úgy, hogy ne az alja, hanem a teteje legyen párhuzamos a tárgyasztallal, így az aljára kerülnek a lépcsők (persze akkor sok támaszanyag kell alulra).

7. Gombfoci

Erre azért vagyok büszke, mert ez volt az első, amikor nem csak letöltöttem valamit, hanem nulláról megalkottam, kinyomtattam, majd fel is töltöttem, hogy mások is használhassák. Ez az ultrabonyolult test egy gombfoci játékos:

button-soccer

A 3D modellt SketchUpban rajzoltam, amit már korábban is használtam asztalosmunkák modellezésére, mert pontosan lehet vele rajzolni (megadhatók a méretek). Letölthető hozzá egy SketchUp STL nevű plugin, ami képes a modellből STL fájlt generálni, amit már a 3D nyomtatós szeletelő programok ismernek, így a tervezéstől a nyomtatásig végigvihető a folyamat, és végül a folyamat minden fájlját fel lehet tölteni a Thingiverse-re.

Persze ez sem ment simán:

  • A SketchUp hátránya, hogy nagyon kis méreteknél néha bénázik. Ezt a programot eredetileg építészeknek tervezték, márpedig ők nagyon ritkán akarnak tizedmilliméteres pontosságot. Ennél a modellnél az lett volna az egyik feladat, hogy lekerekítsem a felső sarkot kb. fél milliméterrel, és bár ezt egy csiszolópapírral sokkal egyszerűbb megcsinálni, úgy gondoltam, hogy belerajzolom a modellbe, hogy dokumentálva legyen. Ezen a feladaton a SketchUp Follow Me eszköze látványosan elbukott, szétesett a modell. Fórumok szerint ilyenkor a bevált gyakorlat a modell ezerszeres felnagyítása, majd kicsinyítése.
  • Nyomtatás után a belső méretek, a lyukak némileg kisebbek lesznek. Ez ismert tény a 3D nyomtatás világában, olvastam már róla, hogy talán orvosolni is lehet, itt nekem annyira nem volt kritikus, hogy a belső és a külső méret is pontos legyen.
  • Rajzolni nagyon szeretek SketchUpban, de egy modellt módosítani nagyon nem, mert nehézkesnek találom. Bár már korábban is belefutottam az OpenSCADbe, Gömöri Zoli felhívta rá a figyelmemet, hogy lehet, hogy jobban járok, ha rajzolgatás helyett inkább programkóddal írom le a modellt. És valóban, rászánva egy fél napot a tanulásra, mára sok esetben az OpenSCAD tűnik jobb megközelítésnek az egyszerű módosíthatósága miatt. A modellek testreszabhatósága a Thingiverse-en pedig briliáns ötlet!

Időközben készítettem még egy gombfoci modellt, akinek kapusra van szüksége, innen tudja letölteni.

8. Nyomtatószál csipesz

Van 5 percem, mit is nyomtassak? Biszbaszt:

filament-clip

Persze meg tudom magyarázni: olvastam róla, hogy probléma lehet abból, ha a nyomtatószál fellazul a tekercsen, ez a kis mütyür pedig ezt segít elkerülni. Kinyomtatva ilyen lett:

filement-clip-printed

A végeredmény jó, működik, az anyag meglepően rugalmas.

A tanulság pedig az, hogy a képen is látható karima (brim) nem jó ilyen kicsi dolgokhoz, a tutaj (raft) sokkal könnyebben és szebben leszedhető.

9. Billog

A 3D nyomtató tökéletesen alkalmas felesleges dolgok nyomtatására, például készíthetünk vele Valentin napra nyomdát, amivel a pirítósunkat billogozhatjuk meg:

toast

Ezt viszonylag nagy, 0.3 mm-es rétegvastagsággal nyomtattam, arra számítva, hogy majd igen csúnya lesz (ami ennél a felhasználásnál belefér), de végül egészen jó lett az eredmény. Ez valószínűleg a modell egyszerűségének köszönhető, hiszen nincsenek benne hidak és ferde felületek.

10. Raspberry Pi doboz

A Thingiverse-en rengeteg dizájnt találhatunk kedvenc Raspberry Pi-nk becsomagolására, én végül ezt választottam a szerelhetősége és a felszerelhetősége miatt:

raspberry-pi-case

A modell több részből áll, külön kell nyomtatni az alját és a tetejét. Bele lehet csavarozni a panelt, és végül össze lehet csavarozni a két oldalt.

A “projekt” végére itt is okosabb lettem:

  • Rettenetesen sokáig tartott a nyomtatás, mivel gyakorlatilag tömör lett a végeredmény. Nem tanulmányoztam alaposan a modellt nyomtatás előtt, viszont a korábbiak alapján elég sok vízszintes réteget állítottam be. A nagy, egybefüggő vízszintes felületek nyomtatása sok időt vett igénybe. Simán lehetett volna kevesebb vízszintes réteget nyomtatni, ez a modell elbírta volna.
  • Amit viszont alig viselt el, az a falak feszegetése. Amikor ugyanis le akartam szedni az eredményt a tárgyasztalról, persze a függőlegesen álló falaknál fogtam meg, és ott kezdtem ráncigálni, ami kis híján a rétegek szétválásához vezetett. Az ilyen vékony falaknál erre vigyázni kell.
  • Legközelebb alaposan megnézem, hogy a modell tervezője milyen csavarokat ajánl. Ha nem metrikusakat, akkor inkább keresek másik modellt, mert nagyon nehéz az inchben megadott méretekhez hasonlót találni.

11. Malac

Ez az ülő röfi ajándékba készült:

piggy

Ilyen lett kb. 35 percnyi nyomtatás után, 0.3 mm rétegvastagsággal:

piggy-printed

Ezen a fotón megint csúnyábbnak tűnik az eredmény, mint a valóságban, hiszen ott sokkal kisebb a tárgy. A rétegek nem lettek ennyire zavaróak, bár az igaz, hogy a 0.3 mm ilyen íves tárgynál már túl sok. A malac elején látható bajusz és szakáll támaszanyag akart lenni az orra alá, de egyrészt nem sikerült rendesen kinyomtatni, másrészt feleslegesnek is bizonyult.

12. Imbuszkulcs tartó

A következő kísérlet majdnem teljes kudarc lett. Ezt a modellt akartam kinyomtatni, ami egy praktikus tároló imbuszkulcsok számára:

hex-key-holder

A korábbiakból tanulva itt már óvatosabb voltam, és alaposabban szemügyre vettem a modellt nyomtatás előtt.

Bár a Thingiverse-en számtalan fotó bizonyítja, hogy ez egy használható modell, amikor én Cura-ban megnyitottam, olyan aprónak tűnt, hogy rögtön gyanússá vált. A hozzászólásokat elolvasva hamar kiderült, hogy ez másnak is probléma, és az oka az, hogy a szerző amerikai mértékrendszerben dolgozott, azaz a modellben a méretek nem milliméterben, hanem inchben vannak. Szerencsére ezt könnyű orvosolni, a szeletelő programban simán felnagyítottam a modellt 25.4-szeresére, és máris jónak látszott a méret.

Ezután azonban tovább vizsgálódtam, és a rétegek ellenőrzésekor kiderült, hogy a Cura a modellen lévő lyukakból mindössze hármat vett észre. Betöltöttem a modellt más szeletelő programba, ám ott is hasonló eredményt kaptam. Mivel a fotók nagyon meggyőzőek voltak az oldalon, egy kicsit bíztam benne, hogy csak a szeletelő programok megjelenítése hibás, ezért próbaként kinyomtattam pár réteget, és így nagyon hamar egyértelművé vált, hogy nem a megjelenítéssel van gond, hanem a modellel.

Ez időnként előfordul, és szerencsére vannak javítási lehetőségek. A Microsoft 3D Builder programja megnyitás után automatikusan felkínálja a modell javítását, de használhatjuk a Netfabb által készített, és Microsoft Azure-ban futó Model Repair Service-t is. Sajnos ebben az esetben egyik sem segített, a modell hibás maradt, így nem maradt más lehetőségem, mint hogy szomorúan lemondtam a nyomtatásról.

Előtte azonban még megírtam a tapasztalataimat egy kommentben a szerzőnek, illetve a többi Thingiverse felhasználónak, hogy másnak ne kelljen ugyanezt az utat végigküzdenie. Alig telt el pár nap, és jött az alábbi válasz a szerzőtől:

“Fixed the issues many of you were speaking about. I was using a slicer software with a repair feature built in, so I was overlooking the issue. Everything should be good now. Uploaded the print in MM too. Thanks for all the feedback. Let me know if you have any more issues. ”

Azaz hallgatva a visszajelzésekre utánajárt a problémának, kijavította, és feltette a modellt olyan formában, hogy az többeknek hasznos legyen. Az is kiderül a hozzászólásból, hogy a szerzőnek azért nem tűnt fel a hibás modell, mert az ő szeletelő programja automatikusan javította azt. Tehát neki nem volt semmi gondja, hagyhatta volna az egészet úgy, ahogy neki jó, de ő mégis vette a fáradságot, és feltöltötte a javított verziót is, mert mások csak azt tudják használni. Ez a hozzáállás nagyon tetszik!

Ismét felcsillant a remény, hogy ezt is sikerül kinyomtatni!

13. Menő Manó

Gyerekkorom nagy kedvence, az olasz Osvaldo Cavandoli alkotása; amikor megláttam, nem tudtam ellenállni neki:

la-linea

Lekicsinyítettem a modellt, és alig 20 perc alatt el is készült:

la-linea-printed

Ennek a nyomtatásnak két tanulsága volt:

  • A PLA ilyen méretekben meglepően rugalmas.
  • Aki ezt meglátja az asztalomon, rögtön beleszeret a 3D nyomtatásba:)

14. Villáskulcs tartó

Ez a nyomtatás is a másik hobbimhoz kapcsolódik, ugyanis némi bosszankodás után arra jutottam, hogy kellene egy normális tartó a villáskulcsaim számára, és ehhez találtam ezt a modellt:

wrench-organizer-printed

Így néz ki a modell:

wrench-organizer

A nyomtatás gyönyörűen sikerült, minden részletével meg voltam elégedve. Aztán belepróbáltam a legnagyobb villáskulcsomat a legnagyobb helyre, és csodák csodája szépen bele is passzolt. Sőt, igazából még lötyögött is egy kicsit, ezért áttettem a mellette lévő helyre. Na ezt nem kellett volna. Ott ugyanis már feszült, és egy pillanat alatt el is tört a modell. A legkisebb erőltetéstől kitört a fésű foga.

A dolog nyitja igen egyszerű. Úgy nyomtattam a tárgyat, ahogy a modellben szerepelt, nem forgattam semerre. A 3D nyomtatásnál a rétegek közötti tapadás viszonylag gyenge, azaz ha van megfelelő erő, akkor a rétegek szétválaszthatóak. Ennél a modellnél a vízszintes alap és a függőleges “fogak” találkozásánál nagyon kicsi a felület (különösen, ha nem tömör a nyomtatás), és ahhoz képest nagyon nagy az erőkar. Mindenféle erőlködés nélkül, ujjal ki lehet törögetni a fogakat.

Így, ebben a formában ez a tárgy nagyon szép, ám teljesen használhatatlan lett. Amint lesz egy kis időm, újra meg fogom próbálni, ám ezúttal elforgatom majd a modellt, és az oldalára állítva fogom nyomtatni.

15. Könyök

Egy másik házi projekt kapcsán felmerült az igény, hogy össze kellene tudni kapcsolni három darab 16 milliméteres fém csövet, például műanyag sarkokkal, ezért megterveztem hozzá ezt a modellt:

elbow

A modell SketchUpban készült, és már ott sokat tanultam azzal kapcsolatban, hogy egy hengert milyen nehéz jó helyen megfogni, és a térben pontosan forgatni.

Számítottam rá, hogy a hengerek belső átmérője a nyomtatás után kicsit kisebb lesz, mint a modellben, ezért különböző méretű kicsi hengerek próba nyomtatásával kísérleteztem ki a megfelelő méretet. Ez a módszer bevált, merem ajánlani. Azt azonban elfelejtettem, hogy a modell sajátosságaiból adódóan a háromféle lyuk biztosan nem lesz azonos méretű. A függőlegesen álló hengert nagyon pontosan tudja nyomtatni a gép, hiszen az rétegenként egy fekvő kört jelent, ami nem probléma. Nem úgy a másik két hengert, ott ugyanis sok, pontosan pozícionált rétegnek kell kiadnia a henger álló kör metszetét, ami sikerülhet jól, de szinte biztosan nem lesz tökéletes. És akkor még arról nem is beszéltem, hogy a behajló részeken valamennyi anyag lógás is várható. Magyarul aki lyukakat ilyen helyzetben nyomtat, az számítson torzulásra.

Ráadásul ennél a modellnél is előjön a rétegek közötti tapadás problémája. Ha a vízszintes lyukak mérete nem tökéletes (például anyag belógás miatt), és valaki mégis beleerőlteti az eredetileg pontosan illeszkedő csövet, akkor előfordulhat, hogy ez a sarok idom eltörik, pontosabban a rétegek mentén szétnyílik. (Lehet tippelni, honnan tudom.)

+1 Sarok profil

Ezt a formát “megrendelésre” nyomtattam:

Cura-fail-1

Látszólag igen egyszerű modell, de itt is előjön ám az előbb említett pontos lyuk nyomtatás probléma. Azonban ami miatt idevettem a tapasztalatok közé, az nem is ez, hanem hogy még ez a nagyon egyszerű, nagyon sík modell is képes elromlani. Ez lett belőle ugyanis Cura-ban:

Cura-fail-2

Észreveszed-e a hibát?

Igen, ott a bal oldali függőleges részen van egy kis kitüremkedés. Nem sok, de az a fél milliméter pont elég ahhoz, hogy az a felület ne legyen sík, és esetleg ahhoz is pont elég, hogy túl nagy legyen a kinyomtatott tárgy. Fogalmam sincs, hogy az a dudor minek köszönhető, a Cura egyszerűen odateszi, szerinte az oda kell. A Slic3r jelen esetben jobb munkát végez:

Cura-fail-3

Alaposan meg kell tehát vizsgálni a szeletelés eredményét, még nyomtatás előtt, mert a legváratlanabb helyeken bukkanhatnak fel hibát.

 

A 3D nyomtatás érdekes dolog, nincs két egyforma feladat, és mindegyikből tanul az ember. Néha nagyon bosszantó, hogy valami nem sikerül se elsőre, se másodikra, az viszont remek érzés, amikor kezedbe veheted azt, ami az előbb még csak a képernyőn létezett.

 

Technorati-címkék:

BKK Futár Microsoft Bandre – service és webtile (3. rész)

A Microsoft Band programozási lehetőségeinek és a BKK Futár API-jának a megismerése után el kellett döntenem, hogyan is szeretnék menetrendi adatokat megjeleníteni a Banden. Végül a webtile mellett döntöttem, leginkább azért, mert az SDK-s megoldás egy folyamatosan futó mobil alkalmazást igényelt volna.

A webtile korlátja, hogy sajnos nem tudjuk befolyásolni, mikor frissüljön, ezért nem álmodozhatunk olyan megoldásról, ami relatív időpontokat használ. Le kell tehát mondanunk a “3 perc múlva indul” stílusú, azonnal érthető megjelenítésről, helyette abszolút időpontokat használhatunk, azaz például “indulás 11:23-kor”. Ez nem annyira szép, de nem óriási probléma, hiszen a Band elsődleges képernyője (Me Tile) mindig a pontos időt mutatja, egy ilyen bonyolult kivonást pedig rá merek bízni a felhasználóra.

A nagyobb probléma, hogy ezzel megszűnik a “következő indulás” fogalma, hiszen a frissítési időközön belül akár több indulás is lehet, és előfordulhat, hogy egy vagy több már múltbeli lesz, mikor a felhasználó rápillant a csempére. Erre nem tudtam jobb megoldást kitalálni, mint hogy több indulási időpontot jelenítek meg, amiből majd a felhasználó némi humán komparálással kiválasztja, hogy melyik a legközelebbi. Egyébként is terveztem, hogy célszerű lenne több időpontot megmutatni, hiszen előfordulhat, hogy a nem a következő buszt, hanem csak a következő utánit szeretném elérni, mert túl messze van a megálló. A sajnálatos szépséghiba, hogy a listában jó eséllyel lesz múltbeli időpont is.

Az adatforrás

A leendő webtile-t természetesen el kell látni adatokkal, azaz szükséges hozzá egy GET-en elérhető szerviz. Bár ahogy az előző részben láttuk, létezik BKK Futár API, az sajnos nem tudja az adatokat pont olyan formában szolgáltatni, amire nekünk szükségünk van. Az eltérések:

  • A Futár API az indulási időpontokat epochtól eltelt másodpercben adja meg, azaz egy bazi nagy, igen barátságtalan számként. Ezt sajnos a webtile nem tudja emberileg fogyasztható formátumra konvertálni.
  • Az API-ban van predictedArrivalTime, arrivalTime és departureTime mező is, és változó, hogy mikor melyik van kitöltve, vagy melyiket érdemes használni. Dokumentáció híján csak tippelni tudok, melyik mit jelent, de a tapasztalat az, hogy a predicted csak a már közeledő járműveknél van kitöltve (tipikusan a következő vagy esetleg a következő kettő), és ez a legpontosabb. A sima arrivalTime szinte mindig ki van töltve, kivéve végállomásoknál, ahol csak a departureTime jelenik meg.
  • Az API hívás sikerességét nem (vagy nem csak?) a HTTP status code, hanem a HTTP válaszban lévő több mező értéke együttesen írja le, amit webtile esetén nem tudunk vizsgálni.
  • A Futár API-tól a következő indulások objektum tömbként kérhetők le, azonban egyik lehetséges webtile layout sem tudja azokat praktikusan megjeleníteni. Sokkal jobb lenne egy vesszővel elválasztott string, például “10:45, 10:56, 11:07”, de ilyen adat átalakításra a webtile nem képes.

Ezen problémák miatt végül úgy döntöttem, hogy készítek egy saját webszervizt, ami adatokkal fogja táplálni Bandit. Tekintve, hogy viszonylag primitív logikáról van szó, ellenben van benne JSON matatás rendesen, és mostanában elsősorban JavaScriptben dolgozom, egy Node.js-es szolgáltatást készítettem. Webszerver frameworkként Hapi-t, a Futár API hívásához pedig a request-promise NPM package-et választottam, mert ezeket már ismertem korábban.

Mivel a webtile nem paraméterezhető, nem láttam értelmét olyan szolgáltatást készítésének, amit bárki, bármilyen járat indulásainak lekérésére használhat. Ez nagyban egyszerűsítette a dolgomat, mert így a KoviBuszból kikeresett megálló azonosítókat én bizony simán beledrótoztam a forráskódba. Az én szervizem, az én megállóim. Persze a forráskódot kitettem Githubra, hogy bárki barkácsolhasson magának hasonlót, vagy még jobbat:

github-logo

 https://github.com/balassy/band-futar-tile

Íme néhány érdekesebb pont a kódból:

  • A webszerviz kódja az src mappában található, a webtile által hívott végpont pedig azon belül a next-ride mappában.
  • Azon belül a service.js hívja a Futár API-t a paraméterként kapott megálló azonosítóval.
  • A service.js-t a controller.js hívja, átadva neki a keresett megállók azonosítóit.
  • A gulpfile.js az urbanjs-tools nevű NPM package-t használja statikus kódelemzésre, ami nagyon kényelmessé teszi az ESLint és az ES6 használatát.
  • A forráskódot Visual Studio Code-dal írtam, erre utalnak a .vscode, typings mappák és a tsd.json fájl. (Igen, a typings mappát nem kellene betenni a repoba, de így sokkal kényelmesebb volt.)
  • A projektet pillanatok alatt sikerült bekötnöm Travisbe és AppVeyorba, ezek beállításai találhatók a .travis.yml és az appveyor.yml fájlokban. Ezek az ingyenes online build környezetek segítettek a forráskód folyamatos karbantartásában, mindkettőt csak ajánlani tudom.

Hosting környezetnek természetesen Azure-t választottam, mert piszkosul egyszerű egy Githubon tárolt web alkalmazás continuous deploymentjét összelőni. Most amint felküldök egy kód módosítást a Githubra, lefut a build Travisben és települ is ki automatikusan az Azure-os webszerverre. Ez az automatizmus még egy ilyen egyszerű alkalmazás esetén is óriási segítség fejlesztés közben.

A webtile

A webtile elkészítéséhez az első részben is említett varázslót használtam. Úgy döntöttem, hogy ez egyes járatok adatait külön page-en fogom megjeleníteni (Multiple page tile), azon belül egy a Scrolling text wrap (MSBand_ScrollingText) elrendezés bizonyult legpraktikusabbnak az ismeretlen hosszúságú szöveg megjelenítésére. Ezt így mutatja a varázsló (az 59-es villamos következő indulásai a Vas Gereben utcai megállóból):

band-webtile-wizard-preview-1

Jelenleg a szerviz az engem leginkább érdeklő három járat adatait adja vissza, ezek mind külön page-et kaptak, utánuk pedig egy negyedik oldalra az utolsó frissítés időpontját tettem. Ez hibakereséshez lehet jó, a szerviz a válasz JSON egyik property-jében visszaadja, hogy mikor kérte le utoljára az adatokat a Futár API-tól, így könnyű volt megjeleníteni:

band-webtile-wizard-preview-2

A varázsló által generált webtile-t nem közvetlenül telepítettem Bandira, hanem letöltöttem, kicsomagoltam (mert valójában egy ZIP fájl), és módosítottam rajta (a végeredmény megtalálható a a webtile/manifest.json fájlban):

  • Kijavítottam azokat az apró hibákat, amiket a webes varázslóban egyszerűen nem sikerült.
  • Beállítottam a refreshIntervalMinutes tulajdonság értékét 15-re, ami negyedórás frissítési időközt jelent, ennél sűrűbben nem is lehet.
  • Beállítottam a version és a versionString tulajdonságokat, és minden újabb kísérletnél inkrementáltam őket, hogy biztosan észrevegye a Microsoft Health alkalmazás, hogy újabb verziót akarok telepíteni.
  • Beállítottam a name, description, author, organization és contactEmail tulajdonságok értékeit, hogy azok kulturáltan jelenjenek meg telepítéskor.

Jelenleg a webszerviz HTTP 500 status code-dal tér vissza, ha valami nem sikerül szerver oldalon, de erősen gondolkodom rajta, hogy hibakeresési célzattal minden ilyen esetben HTTP 200 OK-val térjek vissza, és a hiba leírását adjam vissza a válaszban, hogy azt könnyen meg lehessen jeleníteni a Banden.

A végeredmény

Örömmel tölt el, hogy az elkészült megoldás működik, a Futár API-tól kapott adatok megjelennek, és a megoldás nem bonyolult.

band-futar-tile

band-futar-page

band-futar-update-page

A Futár igazi értéke abban van, hogy nem csak egy sima menetrend, hanem (elméletileg legalábbis) valós idejű adatokat tartalmaz, azaz az aktuális forgalmi helyzetet tükrözi. Sajnos a webtile legjobb esetben is negyedórás frissítési időköze ezt a remek lehetőséget tökéletesen megöli, ami már kevésbé örvendetes, hiszen így az esetek nagy részében “csak” a menetrendi adatokat látom, ami Tokióban minden bizonnyal tökéletesen működne, Budapesten még nem 100%-os. Mivel engem leggyakrabban egy villamosmegálló és egy buszvégállomás indulási időpontjai érdekelnek, számomra egészen jól használható a végeredmény.

Te milyen adatokat látnál szívesen az órádon?

 

Technorati-címkék: ,

BKK Futár Microsoft Bandre – a BKK Futár API (2. rész)

Ahogy az előző részben említettem, azt tűztem ki célul, hogy a BKK Futártól kapott aktuális tömegközlekedési információkat okosórán, konkrétan Microsoft Banden jelenítem meg. A Band programozási lehetőségeinek áttekintése után ebben a részben először nézzük meg azt, hogy a BKK Futár adatait hogyan érhetjük el.

A BKK Futár API

A Budapesti Közlekedése Központ honlapján igen haladó módon létezik egy Fejlesztőknek szóló oldal, ahol gyorsan kiderült, hogy nem rám gondoltak. A BKK megközelítése az, hogy a menetrendi információkat bizonyos időközönként publikálják az oldalukon egy kb. 28 MB-os ZIP fájlban. Értem én, hogy a ZIP-ben GTFS, azaz General Transit Feed Specification formátumban vannak az adatok, ami igen elterjedt, hiszen a G csak udvariasságból General és nem Google, meg hogy így könnyű feltölteni a Mapsre és hogy sűrűn frissítik, ez tényleg szép, csak nekem éppen most pont nem jó.

A következő utam a BKK Futár oldalára vezetett, ahol minden bevezető nélkül egy interaktív térképet találhatunk, ami már sokkal érdekesebb, hiszen ez teljesen friss adatokkal dolgozik. Irány a fejlesztőknek szóló leírás: F12. Nem is kellett sokáig keresgélni a Firebugban, hogy ráleljek erre a kérésre (kattints a teljes méretű képért):

ms-band-4-futar-api

Ebből az egyetlen kérésből több dolog is kiderült:

  • Létezik API, sőt már az URL-jét is tudom. Kellene dokumentáció, amiből kiderül, hogy milyen végpontok vannak.
  • Az API verziózottnak tűnik, ami általában jó hír. Kellene dokumentáció, amiből kiderül, hogy milyen verziók léteznek.
  • Az API hívásához lehet, hogy kell API kulcs. Kellene dokumentáció, amiből kiderül, honnan lesz API kulcsom.
  • Lehet, hogy van throttling, legalábbis a data.limitExceeded mező erre utal. Kellene dokumentáció, amiből kiderül, hogy mennyi az annyi.
  • Státusz információ van bőven: a HTTP státusz kódon kívül a válaszban is van egy status, egy code, és egy text mező, sőt (és ez a fenti képen nem látszik) a szerver még egy X-BKK-Status fejlécet is visszaküld “OK” értékkel. Kellene egy dokumentáció, amiből kiderül, hogy melyik kell nekem.

Ez elég volt ahhoz, hogy elinduljak, de minden jel arra utalt, hogy nagy hasznát venném bármiféle további dokumentációnak.

Neki is álltam óriási lelkesedéssel, keresgéltem a BKK oldalán, a Bingben, de sajnos az összes Google-fu tudásom is kevésnek bizonyult, nem találtam hivatalos leírást. (Aki ismer ilyet, kérem küldje el nekem, köszönöm.)

Találtam viszont több nem hivatalos forrást is:

  • Létezik egy Index Fórum “A BKV GTFS adatbázisa” címmel, ahonnan számomra az derült ki, hogy a nép szenved a GTFS-től és egy barátságosabb API-t szeretne.
  • Az Apiary oldalán találtam egy dokumentációt BKK FUTÁR Utazástervező API címmel. Sajnos nem tűnik hivatalosnak, használhatónak viszont annál inkább.
  • Nádai Gábor (alias Mefi) nevén találtam egy Github repót KoviBusz néven, ami egy adott busz következő indulási idejét mutatja az API-t felhasználva. A kód Node.js-ben készült, és egy barátságos fájlban JSON formátumban tartalmazza a megállókat.

Járatinformációk

Az Apiary dokumentáció és a Firebug böngészése közben világossá vált, hogy nekem az Arrivals and Departures for Stop (nem is olyan nehéz egy API-t jól elnevezni, igaz?) API-ra van szükségem, amit így kell meghívni:

GET http://futar.bkk.hu/bkk-utvonaltervezo-api/ws/otp/api/where/arrivals-and-departures-for-stop.json?stopId&onlyDepartures&minutesBefore&minutesAfter

Ahol:

  • A stopId a megálló azonosítója, például BKK_F00945.
  • Az onlyDepartures paramétert true-ra állítva megadhatjuk, hogy csak az indulások érdekelnek.
  • A doksi szerint a minutesBefore-ral lekérdezhetjük a korábban elment járatokat, ami Marty McFly számára kétségkívül egy hasznos funkció, nálam 0 lesz, az biztos.
  • A minutesAfter-rel pedig azt állíthatjuk be, hogy hány percre előre szeretnénk lekérni az érkező és induló járatokat.

Következő lépésként megálló azonosítóra volt szükségem. Ehhez legjobb forrásnak a Mefi KoviBusz oldala bizonyult, ami térképen kirajzolja az összes megállót, csak rá kell bökni valamelyikre, és Firebugban máris látszódik az azonosítója. A József Nádor tér például F00979.

GET-es API-ról lévén szó, ezt könnyen ki is próbálhatjuk, csak tegyük a megálló azonosítója elé a BKK_ előtagot, és írjuk be a címet a böngésző címsorába:

http://futar.bkk.hu/bkk-utvonaltervezo-api/ws/otp/api/where/arrivals-and-departures-for-stop.json?stopId=BKK_F00979

Íme a szervertől kapott válasz, ahogy azt a Chrome mutatja:

ms-band-5-futar-api-response

Kiemeltem néhány érdekességet:

  • A dátumok és időpontok igen barátságtalanok: nem csak hogy epochtól számított számként jönnek, de hol másodpercben, hol milliszekundumban vannak kifejezve. És akkor az időzónákról még nem is beszéltünk.
  • A következő indulásoknál megjelenik a predictedArrivalTime tulajdonság, sőt létezik predictedDepartureTime is. Végállomásoknál indulási oldalon egyik sincs, csak departureTime.
  • Ebben a megállóban két járat is megáll, a 16-os és a 105-ös. Mi a stop azonosítóját tudjuk, ahhoz tartoznak stopTime-ok, ahhoz trip-ek és végül ahhoz route-ok.

Erős nézés módszerével meglett tehát az API, amiből kinyerhetőek az adatok, már csak össze kell kötnünk a Banddel.

 

(Folytatás következik…)

 

Technorati-címkék: ,

BKK Futár Microsoft Bandre (1. rész)

ms-band-1Nem rég szerencsés tulajdonosa lettem egy Microsoft Bandnek, és természetesen legjobban arra voltam kíváncsi, hogyan készíthetek rá saját alkalmazást. Első célul azt tűztem ki, hogy a BKK Futártól származó információkat fogom rajta megjeleníteni, hiszen milyen jó lenne, hogy amikor kilépek a lakásból csak ránézek az órámra, és rögtön látom, hogy mikor jön a következő buszom. Bandiban van GPS, a telefonon keresztül kilát az internetre, így első körben ez a feladat megvalósíthatónak látszott.

Korlátlan lehetőségek fejlesztőknek

A Microsoft Band “For Developers” oldalára ellátogatva gyorsan fel tudjuk mérni, hogy fejlesztőként háromféle irányból támadhatjuk meg ezt az eszközt.

A Band SDK-t felhasználva készíthetünk egy Windows, Android vagy iOS alkalmazást, ami képes kommunikálni a Band-del. Van szép PDF dokumentáció sok példakóddal, sőt még design guidelines-t is kapunk. A telefonon futó alkalmazás eléri a szenzorokat, új csempéket, azon belül pedig oldalakat és UI vezérlőket tud megjeleníteni.

Készítethetünk Web Tile-t, amihez még különösebb fejlesztői tudás sem kell. Egy böngészőben futó varázsló segítségével kiválaszthatjuk, hogy milyen URL-ről érkező adatokat milyen formában szeretnénk megjeleníteni. A web tile JSON vagy RSS adatokat tud letölteni és megmutatni, sőt még arra is képes, hogy ha a letöltött adatok megfelelnek az általunk megadott feltételnek, akkor a Band megjelenít egy értesítést. Ezek a lehetséges elrendezések:

ms-band-2-tile-layouts

Az elkészült Web Tile-t a készítő feltöltheti egy galériába, ahonnan bárki két kattintással letöltheti azt a telefonjára, majd onnan a Bandjére.

A harmadik lehetőség a Microsoft Health Cloud API használata, ahol egy szép REST API-n keresztül kérhetünk le adatokat a felhasználóról és edzéseiről. Az API kevés végpontot tartalmaz, de ezek sok adatot tudnak visszaadni:

ms-band-3-swagger

A korlátlan lehetőségei korlátai

Első körben tehát el kell döntenünk, hogy hogyan akarjuk megközelíteni a problémát: SDK-val, Web Tile-lal vagy felhős API-val.

SDK

Az első lehetőség az SDK, ami a dokumentáció alapján nagyon izgalmasnak tűnik, de fontos megérteni, hogy

nem a Bandre írjuk az alkalmazást.

Készítünk egy telefonos vagy Windowsos alkalmazást, ami használja a Bandet, de nem a Banden fut. Nincs új projekt típus a Visual Studioban, sőt még azt sem mondhatjuk el, hogy a Banden is Windows 10 futna, mert nem (még). Az alkalmazásunk szempontjából a Band leginkább egy érintőkijelzőre hasonlít, amiben vannak egyéb szenzorok is.

Ez sajnos rögtön magával hozza azt a korlátozást is, hogy a telefonos alkalmazás tudja elérni a Bandet, nem pedig a karperec a telefonos alkalmazást. Tehát készíthetünk egy olyan mobil appot, ami elkéri a Bandtől a pulzusszámunkat vagy a napi kalória fogyasztásunkat, de azt nem lehet megoldani (még), hogy az óránkon kezdeményezzünk bármit, mert a telefonos alkalmazás nélkül a Banden sem történik semmi. Azaz a telefonos alkalmazásnak mindig futnia kell, ami például Windows Phone-on egyelőre csak elég korlátozottan oldható meg (ebben a Windows 10 és a DeviceUseTrigger tud segíteni). Kivétel ez alól a Cortana, mert a Bandről indított hangvezérléssel lehet alkalmazást aktiválni a telefonon, de nálunk ugye nincs Cortana.

A második erős korlátozás a UI. Nem elég, hogy kicsi a képernyő, a felhasználható vezérlők  listája is elég rövid:

  • Egyszerű vezérlők:
    • TextBlock
    • WrappedTextBlock
    • Icon
    • Barcode
    • TextButton
    • FilledButton
  • Konténer vezérlők:
    • FlowPanel
    • ScrollFlowPanel
    • FilledPanel

A jó hír, hogy van gomb, de ne feledjük, hogy csak akkor ér valamit, ha a hozzá tartozó eseménykezelőt tartalmazó telefonos alkalmazás fut éppen.

A rossz hír, hogy gyakorlatilag nincsenek input vezérlők, se szövegdoboz, se lista, semmi. Pedig a Banden még mini billentyűzet is van, hiszen SMS-ekre tudunk onnan válaszolni, ez azonban jelenleg nem érhető el más alkalmazások számára. Arról se álmodjunk, hogy akkor majd mi megoldjuk egyszerű vezérlőkből, ugyanis azokból maximum 10 lehet egy oldalon (page-en).

Ezek után az, hogy a vezérlőkre a számukkal kell hivatkozni, és a gomb eseménykezelőt nem is a gombhoz, hanem az egész csempéhez (lényegében az alkalmazáshoz) kapcsoljuk, és a kódban kell megvizsgálni, hogy melyik gombra nyomott a felhasználó, már nem is tűnik komoly korlátozásnak.

A szenzorok között vannak olyanok (nem mind, de például a szívritmus), amit a felhasználó tudta nélkül nem lehet kiolvasni. Ez a gyakorlatban azt jelenti, hogy az alkalmazásnak először egy GetCurrentUserConsent() függvényt kell hívnia, ami feldob egy engedélykérő ablakot, ahol a felhasználó eldöntheti, hogy az app olvashatja-e azt a szenzort vagy nem. Ez rögtön meghatározza, hogy olyan alkalmazást kell írnunk, amihez tartozik felhasználói felület, azaz háttérben futó windows service-ek és headless IoT alkalmazások kizárva. Nem barkácsolhatunk olyan ventillátort, ami Bluetooth-on keresztül közvetlenül a Bandről olvassa a szívverésemet, és ha magas szívritmust érzékel, bekapcsol, mert a kijelző nélküli ventillátor nem tud engedélyt kérni a HeartRate szenzor olvasásához. Mindenképpen szükségünk van a telefonra az engedélyezés miatt.

Web Tile

A Web Tile egyszerűen elkészíthető és praktikus megoldás például hírportálok információinak megjelenítésére: csak rákötöm a meglévő RSS feedre és már készen is van. Érdemes azonban átgondolni, hogy valóban a meglévő JSON-os végpont vagy RSS feed a legoptimálisabb-e a Band számára, mert a kijelző mérete korlátos, és a web tile nem képes a letöltött adatokon semmilyen formázást elvégezni. A varázslóban csak azt tudjuk megmondani, hogy a szervertől kapott JSON válasz egyes property-jei melyik TextBlockokban jelenjenek meg. Ha a szöveg túl hosszú, nem fog kiférni (kivéve a görgethető elrendezés esetén), hanem egyszerűen levágódik. A legbonyolultabb művelet a sztring összefűzés (több property megjelenítése egy TextBlockban), de arról ne is álmodjunk, hogy számot fogunk dátummá konvertálni, vagy kiszámoljuk az eltelt időt két időpont között.

Ahogy a fenti képen is látszik, a varázsló felkínálja, hogy válasszunk a 6 előre definiált oldalrendezés közül. Más lehetőségünk nincs, ezek valamelyikén (vagy több oldalon) kell elrendeznünk a megjeleníteni kívánt információkat. A hatból 3 elrendezés képes képet megjeleníteni, ezek azonban csak kis méretű, átlátszó hátterű, fehér ikonok lehetnek, amik már a tile telepítésekor rendelkezésre állnak. Arra például nincs lehetőségünk, hogy fotót vagy szerverről letöltött képet jelenítsünk meg (például árfolyamok alakulása on-demand rajzolva). Jó hír viszont, hogy a csomagba tehetünk több ikont, és meghatározhatjuk, hogy feltételtől függően melyik jelenjen meg (például különböző időjárás ikonok).

Érdemes egyébként elolvasni a web tile specifikációt, mert a varázsló csak a fontosabb paramétereket állítja be, nem kérdez rá mindenre. Az egyik ilyen kimaradó paraméter a refreshIntervalMinutes, amivel azt állíthatjuk be, hogy milyen gyakran frissüljön a csempe. Ennek az értéke alapértelmezés szerint 30 perc, de akár 15 percre is állíthatjuk (sűrűbbre nem). Ehhez nevezzük át a varázsló által generált .webtile fájlt .zip-re, csomagoljuk ki, majd módosítsuk a benne található manifest.json fájlt.

Sajnos a gyakorlatban azt tapasztaltam (és a StackOverflow szerint nem vagyok ezzel egyedül), hogy az adatok néha a megadottnál jóval ritkábban frissülnek, nálam volt olyan, hogy 3 óra is eltelt két frissítés között. A sikeres frissítéshez a HTTP válasznak 200 OK-val kell visszatérnie, és a szokásos kliens oldali gyorsítótárazási módszerek itt is bezavarhatnak.

A web tile által hívott URL fix és csak GET lehet, tehát ne is álmodozzunk például arról, hogy majd így küldjük fel az UV szenzor által mért értékeket.

 

Ezek alapján szerintetek hogy lenne a legpraktikusabb megvalósítani a BKK Futárt Microsoft Bandre?

 

(Folytatás következik…)

 

Technorati-címkék: ,

Kedvencek és bookmarkletek Microsoft Edge-ben

A Windows 10 megjelenése óta a Microsoft Edge az elsődleges böngészőm, és alapvetően meg vagyok vele elégedve. A pluginek nem hiányoznak, a minap viszont egy bookmarkletet próbáltam menteni és macerásabb volt, mint gondoltam.

Példaként vegyük a Pinterest bookmarkletet, a Pin It Buttont. Bármelyik másik böngészőben elnavigál az ember az adott weboldalra, megfogja a JavaScript kódot tartalmazó hivatkozást az oldalon, és feldobja a kedvencei közé. Ez Edge-ben biztonsági okokból nem megy, de körül lehet táncolni.

A 2015. novemberi nagy frissítés előtt egyszerűbb volt a helyzet, a kedvencek ugyanis közvetlenül a fájlrendszerben ültek, ebben a mappában:

C:\Users\{FELHASZNÁLÓNÉV}\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\MicrosoftEdge\User\Default\Favorites

Az interneten fellelhető források szerint most viszont már a spartan.edb ESE adatbázisban laknak, itt:

C:\Users\{FELHASZNÁLÓNÉV}\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\MicrosoftEdge\User\Default\DataStore\Data\nouser1\120712-0049\DBStore

Ezt sajnos macerás szerkesztgetni, de úgy tűnik, hogy szerencsére a böngésző a registry-t is használja, ezen az útvonalon megtaláltam az elmentett kedvenceket:

HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\FavOrder\FavBarCache

Ezt kihasználva a következő módon tudtam magamnál Pinterest bookmarkletet menteni:

  1. Ellátogattam a Pinterest bookmarklet oldalára, majd a “Pin It” gombra jobb egérrel kattintva, és a megjelenő menüből a Copy Link menüpontot választva elmentettem a vágólapra a bookmarklet JavaScript kódját.
  2. Ezután felvettem a kedvencek közé ezt az oldalt csak azért, hogy a Pinterest ikonja jelenjen meg a böngészőben a bookmarkletem mellett.
  3. Megnyitottam a Regeditet, és elnavigáltam a fenti útvonalra.
  4. A legnagyobb számú mappa volt az utoljára létrehozott, azon belül az url kulcsba bemásoltam a vágólapról a JavaScript kódot.
  5. Újraindítottam a böngészőt.

bookmarklet-regedit

Ez abszolút nem hivatalos, nem támogatott és nem is tuti megoldás, nálam működik.

 

Chocolatey és a biztonság

Úgy döntöttem, hogy a Windows 10-zel frissen újratelepített gépemre Chocolatey-vel fogom feltelepíteni az alkalmazásokat. Valójában az első ötletem az volt, hogy OneGet-et fogok használni, ami a Windows 10-ben megjelent csomagkezelő-kezelő, és aminek van egy előzetes Chocolatey providere, de mivel ezzel rövid kísérletezés után nem sok sikerélményem volt, maradtam közvetlenül a Chocolatey-nél.

Az első lépés a Chocolatey telepítése, aminek legegyszerűbb módja admin parancssorban annak az egysoros szkriptnek a futtatása, ami megtalálható a chocolatey.org honlapon:

C:\> @powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((new-object net.webclient).DownloadString(‘https://chocolatey.org/install.ps1’))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

Ezzel a paranccsal három dolgot érünk el egy csapásra:

  1. Letöltünk egy PowerShell szkriptet.
  2. Futtatjuk a letöltött szkriptet a saját gépünkön rendszergazdai jogosultságokkal.
  3. Kiegészítjük a PATH környezeti változónkat.

Nem tudom, ki hogy van vele, a 2. lépéstől kiráz a hideg. És ha már itt tartunk, álljunk meg egy pillanatra és gondoljuk végig, mire vállalkozunk: gyakorlatilag ismeretlen forrásból származó alkalmazásokat fogunk telepíteni a gépünkre, hiszen amikor kiadjuk mondjuk a

choco install adobereader

parancsot, akkor fogalmunk sincs, hogy honnan mi fog letöltődni és települni a gépünkre.

Mit tehetünk?

Először is csak olyan choco csomagokat telepítsünk, amiket moderátorok jóváhagytak. A moderálás egy manuális folyamat, csúszhat bele hiba, de mégis egyfajta ellenőrzés. Egy moderált csomag, például az Adobe Reader oldalán ez jelenik meg felül nagy zöld keretben:

This package was approved by moderator gep13 on 6/11/2015.

Egy moderátori ellenőrzésen nem átesett csomag, például a Notepad2 esetén ugyanott piros keretben ezt találjuk:

This package was submitted prior to moderation and has not been approved. While it is likely safe for you, there is more risk involved.

Ha már a csomag részletes oldalán vagyunk, érdemes elolvasni mindent, amit ott találunk. Például a 7-zip csomag oldalán ezzel a figyelmeztetéssel találkozhatunk:

NOTE: The installer for 7-Zip is known to close the explorer process. This means you may lose current work.

Ugyanitt találkozhatunk hasznos opciókkal is, például Firefox esetén megadhatjuk, milyen nyelvű verziót szeretnénk telepíteni:

choco install Firefox -packageParameters "l=en-US"

Ha pedig egy kicsit lejjebb görgetünk, a kommentek között találhatunk olyan utalásokat, amik eltántoríthatnak minket egy-egy csomag telepítésétől. A CDBurnerXP csomag kommentjei között megemlítik az OpenCandy nevű szemetet, amiről eszembe jutott, hogy bizony nem egy olyan telepítővel találkoztam már, amin ha ész nélkül next-next-finish-sel megyünk végig, kapunk “ajándékba” egyéb programokat is.

Az oldal közepe táján sok esetben megtaláljuk a telepítő PowerShell szkriptet, érdemes lehet átnézni, mert abból kiderülhet, hogy milyen telepítőcsomagot tölt le és honnan. Az Adobe Reader csomagjánál ez a szkript mindössze 6 sor, a közepén ott virít az URL és könnyen érthető, hogy mi történik. De ugyanezt nem lehet elmondani a Firefox csomag 117 soros szkriptjéről, vagy a Node.js csomag egyetlen soros szkriptjéről, ami két másik csomagra hivatkozik.

Összességében a Chocolatey használata véleményem szerint egy jókora lutri. Elvégezhetjük ezeket a manuális ellenőrzéseket, frissíthetjük az operációs rendszerünket, beüzemelhetünk egy víruskeresőt, kiszűrhetjük a csibész hostokat, de a végeredmény az, hogy ismeretlen szerző ismeretlen kódját futtatjuk a gépünkön, ami sehogy sem tűnik jó ötletnek.

Én ezeket a csomagokat telepítettem fel, egyelőre nem égett le a ház tőlük:

adobereader
7zip
emet
fiddler
filezilla
firefox -packageParameters "l=en-US"
gitextensions
google-chrome-x64
join.me
keepass
nodejs
paint.net
silverlight
skype
sysinternals
vlc

Ti mit gondoltok, használtok ilyet, meritek használni, és ha igen, milyen csomagokat szoktatok még feltenni?

 

Technorati-címkék: ,,