You are here

VISUAL Thinking - LabVIEW programozó verseny középiskolásoknak


 

LabVIEW verseny főoldal

Verseny szabályai

Fordulók és feladatok

Csapatok és pontszámok

Grafikus programozás

Regisztráció

 

 

A verseny ütemezése


  • § 

    Regiszráció lezárása: 

    2017. február 28.

    § 

    Első feladat kiküldése 

    2017. máricus 3.

    § 

    Első feladat beérkezésének határideje 

    2017. március 13.

    § 

    Továbbjutók kihirdetése, második feladat kiküldése 

    2017. március 24.

    § 

    Második feladat beérkezésének határideje 

    2017. április 2.

    § 

    Döntősök kihirdetése 

    2017. április 10.

    § 

    Döntő 

    2017. április 21.

National Instruments

LabVIEW grafikus fejlesztői környezet

A National Instruments LabVIEW fejlesztői környezet már 1986. óta forradalmasítja a tesztelési, mérési és vezérlő alkalmazások fejlesztését. A mérnökök és fejlesztők tapasztalattól függetlenül rövid idő alatt, költséghatékonyan hozhatnak létre illesztőfelületeket a mérési és vezérlő hardverekhez, elemezhetik a mért adatokat, megoszthatják az eredményeket, és terjeszthetik a rendszereket.

A LabVIEW szoftver az iskolai tervezéstől egészen a világ legbonyolultabb gépeinek vezérléséig használható.

NI LabVIEW Student Edition


Még nem tudsz programozni? Ne aggódj!

Mi segítünk elsajátítani a versenyhez szükséges alapokat!

Az egyes feladatokat a LabVIEW szoftverrel lehet majd megoldani, melyet mérnökök nap mint nap használnak világszerte a munkájuk során. Ha még nem ismered a grafikus programozást, akkor se aggódj, ez a verseny egy jó alkalom arra, hogy most kipróbáld. A honlapunkról könnyedén letöltheted a LabVIEW szoftver 6 hónapos próbaverzióját és online szemináriumi anyagainkkal hipp-hopp elsajátíthatod a versenyhez szükséges alapokat. A linkekre kattintva először regisztrálnotok kell, hogy elérjétek a videókat, valamint hogy le tudjátok tölteni a szoftver próbaváltozatát. A versenyzőket tájékoztatni fogjuk arról, hogyan tudják a verseny végéig meghosszabbítani a próbaverziót. Probléma esetén vegyétek fel velünk a kapcsolatot.

 

LabVIEW próbaváltozat letöltése

LabVIEW verseny 2014 - I. forduló feladata

Az iskolában két asztalitenisz csapat van. A játékosok nevei adottak, és ezeket egyetlen fájlban tárolják az edzők.[1] A csapatok létszáma mindig megegyezik, de összetétele változhat. Ennek a fájlnak a karbantartása a mostani szoftvertől független.

Egy foglalkozásirányító rendszert kell most létrehozni, amely kisorsolja az aznap együtt játszó párokat.
 
Az eszköz hangfájlok segítségével pedig ki is hirdeti, kik játszanak aznap együtt, azaz a PC hangszóróján
egy szoftver vezényli a játékosokat.

 

  • A foglalkozásokon minden játékos játszik. Az egyik csapat egy játékosa a másik csapat valamely sportolójával. Mindenki csak egy mérkőzést játszik, de hogy kivel, az véletlenszerűen alakul ki. Tehát ha az A csapat tagjai Fruzsi, Feri, Vali és a B csapat tagjai Laci, Zoli, Teri akkor 3 mérkőzés lesz aznap, pl.: Fruzsi-Zoli, Vali-Laci, Feri-Teri.
  • Az edző minden foglalkozás előtt aktualizálhatja a csapatok névsorát, akár bővítheti is, ez alapján fog a program dolgozni. Most éppen adott az a csapatlista, amit mindannyian megkaptatok, tehát a programozási versenyünkön induló csapatok ugyanazokkal az adatokkal fognak dolgozni. Négy-négy fő mindkét csapatban, de a csapatok összetétele, létszáma természetesen később változhat. Erre nektek is fel kell készíteni a programotokat!

 

  • A program tehát induláskor beolvassa az edzők által karbantartott fájl tartalmát, összesorsolja a játékosokat és ezt egy táblázatba rendezi. Az edző ezt átolvassa, majd megnyomva egy gombot a program kimondja[2] a párok neveit, úgy, hogy a lista hallgatása „ne sértse a fülünket”. Tehát ha az előző példa valósulna meg, akkor az alábbi mondatot mondaná ki a program: „A mai napon Fruzsi Zolival, Vali Lacival, Feri pedig Terivel fog megmérkőzni.

 

A játékosok nevein kívül tehát el kell hangozni úgymond állandó szavaknak, mint itt a „pedig” szónak, valamint a párok esetén a megfelelő ragokat a programnak ki kell mondania. Vigyázz! Fentebb olvashattad, hogy az edzők átrendezhetik a csapatokat. Egy másik lehetséges összeállítás szerint egyáltalán nem biztos, hogy Teri mindig másodiknak lesz kimondva[3]. Lehetséges, hogy egy másik esetben majd ennek a mondatnak kell elhangoznia: „A mai napon Fruzsi Zolival, Feri Lacival, Teri pedig Valival fog megmérkőzni.” 

 

Érdemes tehát a neveket tartalmazó hangfájlokat ragok nélkül mikrofonnal felvenni és eltárolni egy-egy-egy mono, wav kiterjesztésű hangállományba, valamint a két előforduló ragot is külön felvenni.  A program maga rakja össze a neveket, valamint minden pár esetén a második nevet a hozzá megfelelő raggal[4].

    • Az edzők változtathatják a csapatok összeállítását[5], ezért nem kell foglalkozzanak azzal, hogy az alapadatokat tartalmazó fájlt mindig ABC sorrendbe szedjék. Ugyanakkor nagy segítség nekik, ha a program - miután beolvasta az alapadatokat -, a játékosok neveit a felhasználói felületen mindig rendezve mutatja. Az első példánál maradva egy ilyen felépítést kell lásson a felhasználó:

     

    A csapat

    B csapat

    Feri

    Laci

    Fruzsi

    Teri

    Vali

    Zoli

      • Tehát az A csapat tagjait is ABC alapján rendezi, illetve a B csapat listáját is. 
      • Megoldandó feladat az is, hogy minden edzés végén generálódjon egy txt naplófájl. Ennek első sora legyen egy úgynevezett címsor, adatai pedig az, hogy a foglakozás mikor kezdődött, (dátum- és időadatokkal), majd az, hogy ki kivel játszott ekkor. A generált naplófájlok nevét logikusan építsétek fel, hiszen egy tanév alatt sok ilyen fájl keletkezik majd.

       

       A kidolgozott programotokkal küldjetek el nekünk is egy ilyen naplófájlt!

       

      • Természetesen az is a rugalmas használhatóságot, a program elterjesztését segítheti, hogy ne kössük meg a felhasználó kezét, hogy hová másolja majd a programotokat. Bármilyen nevű főkönyvtár esetén is a programnak jól kell működnie. Ebben a főkönyvtárban azonban mindig rend legyen: a fő VI (Virtual Instrument) és az alapadatokat tartalmazó fájl van itt, valamint alkönyvtár a hangfájloknak, és külön alkönyvtár a naplózott állományoknak, dokumentációknak, subVI-oknak.

       

      Törekedjetek a lehető legegyszerűbb kódra, ugyanakkor teremtsétek meg a bővíthetőség lehetőségét (például: most ugyan háromfős csapatok vannak, de a csapatok létszáma és összetétele változhat).

       

       

      LabVIEW verseny 2014 - II. forduló feladata

      Az igazgatónak megtetszett a sportfoglalkozások gördülékeny rendje. A vezetőségi ülésen felmerült az igény a régi iskolacsengő modernizálására is. A csengő megbízhatatlan volt és a beállítása is nehézkesnek bizonyult. Ezzel a régebbi rendszerrel nem tudták megoldani például azt a problémát sem, hogy rövidített órákat tartson az iskola. Ebben az esetben a pedellus bácsira volt bízva a csengetés.

      A második forduló feladata egy szabadon paraméterezhető csengető óra programozása normál, illetve rövidített órákkal. 

      • Minden tanítási napon legfeljebb tíz óra lehet.
      • A csengetési rendeket igazgatói utasítás szabályozza, amit egy-egy txt fájlban rögzítenek.
      • A működést tekintve ugyanazon hanggal kell jelezni a tanórák elejét, illetve azok végét, továbbá egy rövidebb jelzést 
        kell adni az óra vége előtt öt perccel, illetve szintén ez a rövidebb jelzés hangzik el az óra kezdete előtt két perccel.

       

      Külön fájl tartalmazza a rendkívüli eseményeket (yyyy. mm. dd napon csak ez első x óra lesz megtartva). 
      Kérjük, hogy tanulmányozzátok át figyelmesen a megadott felépítésű txt fájlokat! 

      • A rendkívüli helyzetekben az igazgató ad utasítást arra, hogy adott napon nem tanítunk (igazgatói szünet esetén).
      • Mindamellett, hogy tanítás általában csak hétköznapokon van, bizonyos esetekben mégis tanítanak hétvégén 
        (munkanap áthelyezés miatt), illetve akár szünetben is (ha az év során túl sok tanítási nap maradna el).
      • Az igazgató továbbá egy hosszabb délutáni tanári értekezlet miatt egy adott napra rövidített órák tartását rendelheti el.
      • Az igazgató dönthet úgy is, hogy adott napon csak néhány óra lesz megtartva. Ez utóbbi minden esetben úgy fog kinézni, 
        hogy az első néhány óra meg van tartva, és az utána lévők maradnak el. Ekkor az eseményt az igazgató E betűvel kezdi, 
        majd szóköz nélkül egy tíznél kisebb szám áll. Például E5 jelenti, hogy csak az első 5 óra lesz megtartva.

       

      Jelenleg az alább felsorolt négyféle eseményt jelölheti meg az igazgató rendkívüli helyzetként

      • szabadnap
      • tanítunk
      • rövidített
      • E…  (ez lehet akár E3, E4, stb.)

       

      Ezen utasítások kombináltan is érvényesek lehetnek. Például rendkívüli tanítást rendel el szombatra, de erre a napra 
      rövidített órákat ír elő az iskolavezetés: 

      • 2014.02.15 rövidített
      • 2014.02.15 tanítunk

       

      Nyílván akkor lenne a legkedvezőbb a diákoknak, ha ezen a napon csak az első három óra lenne megtartva. Amennyiben ezt is leírja egy külön sorban az iskolaigazgató (például: 2014. 02. 15., E3), akkor már három feltétel határozza meg az aznapi csengetést. Kérünk benneteket, hogy a programotokat erre az eshetőségre is készítsétek fel!

       

      Példa:

      • 2014.02.15 rövidített
      • 2014.02.15 tanítunk
      • 2014.02.15 E3

       

      Üzemmódok a csengetésvezérlő PC-n:

      A csengetésvezérlő PC a portán van elhelyezve, más feladatot is ellát, de a VI (Virtual Instrument) minidig fut 24 órás üzemben.

      A portás a csengetési rendbe négy gombbal, kapcsolóval (ezt rátok bízzuk) manuálisan is beavatkozhat a Front Panelen.

       

      • Válthat tűzjelzésbombariadó, illetve órajelzés üzemmódok között (ezek közül csak egy lehet aktív), továbbá kézzel 
        átválthat rövidített órákra. Ez utóbbi funkció éjfélkor automatikusan álljon vissza normál csengetési rendre, ha esetleg 
        a portaszolgálat figyelmét elkerülné.
      • Minden egyes kézi váltást a programnak egyetlen folyamatosan bővülő txt fájlban naplóznia kell. Naptári évenként 
        egyetlen naplófájlt gondoz a rendszer. A naplófájl felépítését ti határozzátok meg és ezt a feladat beküldéskor mellékeljétek is!
      • Nyilván amíg bármilyen riadó van, addig csengetés nincs. Ezek az üzemmódok azonban automatikusan nem állnak vissza 
        csengetési rendbe, ezen eseteket manuálisan kell majd visszakapcsolni a fenyegetettség elmúltával.
      • A rendszer működését meghatározó utolsó fájlban (tanév rendje.txt) rendelkezik az igazgató az őszi, téli, tavaszi szünetek rendjéről, illetve a nyári szünetről is (pl.: nyári szünet 2014.06.15-től 2014.09.01-ig). A fájl tartalmát tekintve az első megadott nap 
        már a szünetet jelöli, illetve a dátumtartomány utolsó megadott napja szintén a szünet része még.

       

      Minden csapat, aki a második fordulóba jutott az említett négy txt állományt egységes tartalommal kapja meg, de most is 
      készítesétek fel a programot arra, hogy ezen fájlok tartalma az év során változhat. Különösen a rendkívüli események, de akár 
      a csengetési rend is! A fájlok most is tabulátorral tagolt txt állományok. A dátumokban a hónapokat sorszámaikkal jelölik, 
      továbbá mind a dátum, mind az óra, perc adatok esetén a 10 alatti értékek nullával kezdődnek (pl.: 11:5 esetén a 11:05 lesz eltárolva)

       

      Megkapjátok tehát a txt fájlok felépítését az egységes minta adatokkal. Azonban

      • az órák végét illetve elejét jelző hangfájlt,
      • a rövidebb jelzések hangját, valamint
      • külön fájlt a tűzjelzésre és egy másikat
      • a bombariadó jelzésére nektek kell elkészítenetek!

       

      Mind a négy hangfájl wav kiterjesztésű legyen, és a jelzéseket a kívánt időpontokban PC felhasználásával kell realizálni, 
      a PC hangszóró kimenetének segítségével.

       

      Törekedjetek a lehető leginformatívabb és legkényelmesebb felhasználói felületre. Alkalmazzatok subVI -okat a kód olvashatóságának, újrahasznosíthatóságának, tömörségének és egyszerűségének az eléréséhez, illetve alkalmazzatok kommenteket a forráskódban. 

      Szükséges dokumentumok és segédanyagok:

      Normál csengetési rendet tartalmazó file

      Rövidített órákat tartalmazó file

      Rendkívüli eseményeket tartalmazó file

      Tanév rendjét tartalmazó file

       

      LabVIEW verseny 2014- Döntő feladata

      Idén is beindult Ákos fantáziája: csapatával az előző években különféle fejlesztéseket végzett. Ákos hamarosan végez tanulmányaival, és természetesen érdekli a jövője. Ezért a csapattal úgy gondolják, hogy megpróbálnak saját lábukon megállni: egy start-up projektben gondolkodnak. Ötletük természetesen bőven van.

      Most, az újonnan hőszigetelt iskolájuk energiafelhasználása kapcsán, további megtakarításokat szeretnének elérni. A csapat már korábban is gondolkozott egy intelligens alkonykapcsoló létrehozásán. Ha ezt sikerülne hardver illetve szoftver oldalról is megvalósítani, akkor alkalmazni lehetne az iskolában, hiszen az energia-megtakarítás ott hatványozottan jelentkezne.

      Ákos csapata most Ti vagytok, tehát a ti feladatotok lesz az alapkoncepció elkészítése. Mi is az Ákossal felvázolt tervetek? Alkonykapcsolót kell definiálni, amely funkcióit tekintve a következőképpen működik:

      a.) Egy előre megadott fényerősség alatt, a kívülről belépni szándékozó személy esetén az ajtó felé haladót érzékelve (lásd: d. pont), az ajtó feletti külső világítás még az ajtóhoz érkezés előtt önműködően bekapcsol. Így a felhasználó az ajtót a kulccsal könnyen kinyitja, és ezt követően be tud menni a lakásba. Amíg a felhasználó az ajtót be nem zárja, addig folyamatosan világít a lámpa.

      b.) Az ajtó kinyitását és becsukását követően még 10 másodperccel tovább világít az ajtó feletti külső lámpa (az ajtó becsukását követően indul a 10 másodperces késleltetés). Ennek a célja az, hogy például az ablakon visszanézve a felhasználó nyugtázhassa: nem hagyott kint semmit, vagy a kapu zárva van. Ugyanakkor kényelmi funkcióként nem kell a világítás lekapcsolással foglalkozzon: 10 másodperccel az ajtó becsukása után a lámpa automatikusan lekapcsol.

      c.) A feladat működése során fontos a felhasználó haladási irányának a detektálása, mert csak az ajtóhoz közelítő irányban indul be a késleltetett kikapcsolású alkonykapcsoló (természetesen továbbra is csak „sötétben”). A házból kifelé tartó személynek a fejlesztés jelenlegi stádiumában nem világítunk sem rövid időre, sem pedig késleltetett kikapcsolással. Detektálni kell ezt a haladási irányt is, de nem kell a világítás felkacsolásával foglalkozni, tehát ebben az esetben most nem fontos a sötét vagy világos környezet sem.

      d.) A haladási irány meghatározásához, kültéri, „árnyékolt” és megfelelő hatótávolságú infra sorompók formájában, a házhoz vezető járda mellett két optikai érzékelő megfelelő magasságban van felszerelve. Ezek úgy vannak elhelyezve, hogy alaphelyzetben az infra sorompók nincsenek kitakarva („A” illetve „B” az ábrán látható jelölésekkel). A figyelt személy teste a bejárati ajtóhoz közeledve először az „A”, majd mindkettő („A” valamint „B”), végül pedig csak a „B” jelű szenzort takarja ki. Elhaladás után természetesen egyik infra sorompó sincs kitakarva, jelet ekkor nem adnak.

      e.) Ezt a környezetet a megkapott VI Front Panel felületén is láthatjátok, a VI fejlesztéséhez egy vízszintes csúszkát mozgatva a szimulált személy képe mozgatható az optikai érzékelők előtt. Fontos azonban, hogy a csúszka, amivel a személy mozgatható csak az „A” illetve „B2” jelű ledek kapcsolására szolgál. A program logikáját már ezeknek a ledeknek az állapotára és az állapot változására kell kidolgozni (hiszen a valós környezetben is csak egy-egy logikai értéket kap majd a vezérlő és nem „személy távolságot”). Tehát nem helyes az a megközelítés, ha a csúszka által meghatározott numerikus érték közvetlen hatására kapcsol fel vagy le a lámpa.

      f.) A feladatotok tehát a Front Panelre egy bejárati ajtó képét elhelyezni a jobb oldalon, amely felé haladhat a felhasználó, az ajtó felett pedig egy ledet kell elhelyezzetek, melynek működését az a.), b.), c.), d.) pontokban taglalt logika határozza meg.

      g.) Az ajtó nyitását, majd az ezt követő bezárást nem kell leszimulálni, ezt most a program felületén csak egy kapcsolóval jelezzük. A VI felületén elhelyezett egyetlen kapcsolóval a nyitott, illetve a zárt ajtó tényét adhatjuk meg. Ezt a feladatot a valóságban természetesen egy, az ajtóra szerelt nyitásérzékelő látja majd el, miután a saját kulcsával a felhasználó kinyitotta a bejáratot. Jelen fejlesztési stádiumban nem vizsgáljuk az illetéktelen behatolás kísérletét. A nyitott vagy zárt állapotot jelző (egyetlen) kapcsolót a programozók egérkattintással kezelik, annak érdekében, hogy a helyes programlogikát tesztelhessék.

      h.) Az esetek többségében tehát a felhasználó közeledhet a ház bejárati ajtajához, majd az ajtót kulccsal megnyitja, ezt követően bezárja. Szintén üzemszerű az az eset, amikor az ajtó kinyílik, majd bezárul és az optikai érzékelők távolodó személyt detektálnak. Az életben azonban előállhat az a helyzet, hogy az érzékelők által detektáltan a bejárati ajtóhoz közeledő személy az ajtó felé tartva visszafordul és nem folytatja a hazamenetelt (visszafordul a boltba). Ekkor a lámpa az a.) pont miatt bekapcsol, azonban a késleltetett kikapcsolás nem indul be, hanem amint érzékeli a vezérlő a „KI” haladási irányt, a lámpa azonnal le is kapcsol, mert a felhasználó visszafordult. Több körülményre is készüljön fel tehát a program, hogy minden, fentebb vázolt esetben helyesen működjön.

      A fejlesztés jelenlegi állapotában egyetlen felhasználóra tesztelünk. Tehát nem kell azt az esetet kezelni, ha például ketten is közelednek és egy ajtón mennek be, vagy valaki éppen a lakásban marad, míg egy lakótárs éppen elment. Jelen esetben egy ember lakik a házban és mindig egyedül jön haza. Befele történő haladás esetén ajtónyitás nélkül visszafordulhat a felhasználó (pl.: visszafordul a boltba), viszont kifele történő haladás esetén nincs visszafordulás, a felhasználó biztosan kimegy. A szenzorok megkerülésére nincsen lehetőség.

      Programozáskor ügyeljetek a tiszta, áttekinthető kód felépítésére, vizsgáljátok meg, milyen lehet a legtömörebb, leghatékonyabb program. A kód legyen olyan, hogy egy később belépő fejlesztő is hamar bekapcsolódhasson a munkába. Az áttekinthetőség érdekében hasznos lehet SubVI-t is használni. Mind a főprogramban, mind pedig a SubVI-ban az egyértelmű, funkciójukra utaló elnevezések, mind a helyesen megválasztott subVI ikonok nagyon fontosak a későbbi program-gondozás szempontjából. Figyeljetek a kommentek fontosságára, a SubVI-nak legyen úgynevezett Context Help tartalma is! Fontos továbbá az áttekinthető Front Panel, a felhasználóbarát felület. Figyeljetek arra, hogy a programozást megtervezzétek, ügyeljetek a helyes időbeosztásra. Nem csak a teljes megoldást fogadjuk el, részpontok is szerethetőek a javítás során. A megszerzett pontokból áll össze a csapatok végpontszáma, ami eldönti a rangsort a továbbjutáshoz.

      További elvárások a beadandó megoldással kapcsolatban: 

      A feladatkiíráshoz tartozó VI a megoldandó feladat programváza, melyet itt találtok. Ebben kell dolgozni, ennek a végleges formáját kell kialakítani. Ezt a vázat minden nevezett csapat egységesen kapja meg.

      A programváz kinézetén változtathattok. A Block Diagramot természetesen Ti építitek fel; a Front panelen a csúszkákat (fényerő, kapcsolási határ, „ember mozgatása”), az „A” és „B” jelű ledeket, a kapcsolót, a lámpát át lehet helyezni. A Front Panelra újabb vizuális elemeket lehet elhelyezni, meg lehet változtatni az ember „képét”, a méreteket, színeket és érdemes csapatlogót is elhelyezni.

      Nem szabad azonban a programvázon általunk elhelyezett úgynevezett alapelemeket törölni, vagy a főprogram VI termináljait megváltoztatni/törölni. Ez utóbbit azért kérjük, mert minden beérkezett munkát egy tesztelő szoftver fog javítani és ezen terminálok segítségével valósul meg a megoldásotok tesztelése, az elvárt funkciók ellenőrzése. Nagyon fontos tehát, hogy a programotokat és minden SubVI-t elküldjetek, ezek egyetlen könyvtárban legyenek. A főprogram neve az alábbi felépítésű legyen: alkony_csapatnév.vi. Minden SubVI neve „sub_” karakterekkel kezdődjön. Teszteljétek le akár egy másik PC-n is, hogy a beküldendő munkátok egy másik könyvtárba átmásolva is helyesen működik-e. Mi ugyanis a beérkezett munkákat egy főkönyvtárba másoljuk, melynek alkönyvtárai a csapatnevek alapján készülnek el, és ezekbe másoljuk a kapott megoldásokat. A javítás innen már automatikus lesz.

       

      Figyelem! Kérjük, hogy a javítás megkönnyítése érdekében csak 2010-es, vagy attól újabb LabVIEW fejlesztői környezetben dolgozzatok.

       

       

      LabVIEW verseny 2015 - II. forduló feladata

      Az első fordulóra nagyon sok szép és jó megoldást küldtetek be. Ákosnak azonban volt néhány momentum, ami fejtörést okozott az elmúlt héten, mert a beépíteni szándékozott érzékelő nem mindig működött helyesen. Arra a következtetésre jutott, hogy újragondolja a funkcionális felépítést, a felhasználás során gyűjtött tapasztalatokat, és csapatával készít egy saját intelligens szenzort.

      Lefektették a követelményeket, a tervezést a prototípus elkészítése követi. Még egyszer átnézte a csapat az áramköri terveket és elküldték a megfelelő fájlokat gyártásra. Amíg azonban a megtervezett áramkört legyártják, elindul a fejlesztés. A LabVIEW egyik erőssége a gyors prototípus gyártás, a fejlesztési idő lerövidítése. Ez jelen esetben úgy jelentkezik, hogy a leendő szenzor tesztprogramjának megírásához nem szükséges a tényleges hardver megléte. Elkezdhetik a fejlesztést VI szinten, amíg a tényleges hardver el nem készül. Az alkalmazott elektronikai elemeknek Ti is nézzetek utána, a döntőben találkoztok velük. A mellékelt áramkör képe alkatrészekkel beültetve látható itt. Az értelmezéshez kérjétek tanárotok, ipari szakember segítségét. Az áramkör csatlakozóinak kiosztása illeszkedik a National Instruments iskoláknak szánt innovatív eszközéhez, a myDAQ-hoz.

      Az áramkör az Eagle áramkörtervezővel készült, felülnézetben látható. A kék része a NYÁK hátoldala, ezért látszanak visszafelé a feliratok.

       

      A felhasznált alkatrészek:

      • 1db csatlakozó sor
      • 4db led
      • 4db ellenállás a led-ekhez
      • 1db ellenállás az analóg fényérzékelőhöz
      • 1db fotoellenállás a megvilágítás érzékelésére
      • 1db nyomógomb a teszt üzemmódhoz

       

      1)      Gomb, fényérzékelő és ledek elhelyezése a Front Panelen

       

      a.       Az elkészítendő szenzor modulon ténylegesen beforrasztott gombot (Boolean palettáról egy gomb) és a fényérzékelőt (numeric értéket adó csúszka) mint egy-egy Control-t helyezzétek el a Front Panel-en. b.      Az összesen 4db led-et szintén a kész áramkörnek megfelelően helyezzétek el a Front Panel-en, mint egy-egy Boolean Indicator-t. c.       A szimulált megjelenés, a Front Panel képe a lehető legjobban hasonlítson a gyártásra kiadott modulhoz!  

      2)      Egyetlen VI-t készítsetek két funkcióval:

      a.       A működést tekintve egyetlen VI-t kell készíteni a szenzor modul teszthez (gyártás után, a felhasználásra kiadás előtt alapos tesztre van szükség) illetve a működtető programhoz. Ez a VI tehát két funkciót teljesít. b.      Ahhoz, hogy a szakemberek tesztelhessék magát a hardvert, illetve a működést is kipróbálhassák, helyezzetek el a Front Panel-en egy kapcsolót, amellyel a két üzemmód közül választhat majd Ákos és csapata. c.       A szenzormodult és a PC-n futó VI-t tervek szerint az NI myDAQ eszközzel kapcsolják majd össze (a döntőben myDAQ-ot is fogtok használni, ezért nézzetek utána és ismerkedjetek az eszközzel) A fizikai kapcsolat létesítése után kell elindítani az általatok fejlesztett VI-t, majd a szakember a kapcsoló segítségével kiválasztja, hogy szenzor modult kíván tesztelni vagy pedig működtetni az intelligens szenzort. Ezután a mérés gombot megnyomva indul a megfelelő üzemmód, ezért ezt az újabb gombot is helyezzétek el a VI felületén.  

      3)      Szenzor modul teszt követelményei

      a.       Amennyiben a szenzor modul tesztet választja a szakember, úgy azt dokumentálni is kell. A teszt során a VI-ban sorra be kell kapcsolni a négy led-et. Nem kell gombot nyomni, automatikusan egymás után bekapcsolódnak a led-ek. Mindegy milyen sorrendben, de mindegyiket egy másodpercre be kell kapcsolni és a következő led bekapcsolás fél másodperc múlva következhet. Egyszerre tehát csak egy led-et kapcsolunk be.b.      A tényleges fizikai megjelenésnél vizuálisan fogja vizsgálni a tesztet végző szakember a sorban felkapcsolt led-eket. Amennyiben a valós teszt során nem a megfelelő led kapcsol be, vagy egy sem, esetleg egy led helyett több is, akkor áramköri hibát kell keressen. Például zárlatot, vagy szakadást. Most csak be kell kapcsolni a ledek-et, döntést azok helyes működését illetően nem kell hoznotok.c.       A négy led felkapcsolását követően a VI egy üzenetet kell, hogy kiadjon a tesztet végző szakembernek, arra szólítva fel, hogy nyomja meg az áramkörön lévő gombot. A fizikai megjelenésben ezt a tényleges nyomógombot, mint feszültség jelet fogja majd olvasni a VI, most csak a már Front Panel-en elhelyezett a valós alkatrészt szimbolizáló gombot kell megnyomni. Amennyiben a felkérést követően 4 másodpercen belül a gomb megnyomását érzékeli a VI, egy az áramkör részét nem képező, de a Front Panelen megjelenő zöld led kell bekapcsoljon és egy zöld színű „PASS” felirat kell megjelenjen a Front Panel-en. Ezt a plusz zöld színű led-et és a PASS feliratot is el kell tehát helyezzétek a VI felületén, de a felirat csak akkor legyen látható, ha a teszt ezen része sikeres, azaz 4 másodpercen belül megnyomta a felhasználó a Front Panelen az áramköri megfelelőjét szimbolizáló gombot. A megjelent PASS felirat a VI leállításáig látható marad.

       

      d.      Amennyiben a gomb jelét nem sikerült a nevezett 4 másodperc alatt detektálni, úgy a zöld színű PASS felirat helyén egy pirossal írt FAIL felirat jelenik meg, a kapcsolódó zöld színű led pedig nem kapcsol be. Ez a FAIL felirat sem látható a mérés előző szakaszaiban, de ha megjelent, a mérés további szakaszában látható marad a VI kikapcsolásáig.

       

      e.      A következőkben a tesztet végző szakembert a VI arra kell kérje, hogy mozgassa a csúszkát (ami a valós reprezentációban a fény érzékelését jelenti majd). Ennek a csúszkának a mozgását egy Waveform Chart-on kell megjeleníteni, valós esetben ez fogja mutatni a fényérzékelőn beolvasott feszültség értékét. A csúszkát úgy állítsátok be, hogy a tesztelés során 0 és 5 közötti sávban tetszőleges értéket állíthasson be a felhasználó, mert a valós eszköznél a megvilágítással arányosan mért feszültség is ebbe a feszültségtartományba fog esni.

       

      f.        A led-ek, a gomb és a csúszka tesztje után a mérés véget ér, ezt a tényt az egyetlen naplófájlt bővítve egy újabb sor bejegyzésével dokumentáljátok, majd ezt követően a VI automatikusan álljon le. A bejegyzés tehát az egyetlen naplófájlban annak utolsó soraként fog megjelenni. Felépítését tekintve:

       

      „Teszt sorozat dátum: időpont1 és időpont2 között. Gombteszt: sikeres

       

      Természetesen a dátum szó helyén az aktuális dátum álljon, az időpont1 helyén a mérés indításának óra:perc értéke áll majd, az időpont2 helyén pedig a mérés végének óra:perc értéke. A sikeres szó akkor jelenik meg, ha a fentebb említett PASS feltétele teljesült, ellenkező esetben a sikertelen szó jelenjen meg. A naplófájl egyszerű txt állomány legyen, a feladatban csak a kiemelés miatt jelent meg a félkövér formázás. A txt fájlban természetesen formázás nem fordul elő.

       

      g.        A teszt üzemmód szerint működő VI-t bármelyik lépésénél le kell tudja állítani a szakember. Erre a célra egy STOP gomb szolgál a Front Panel-en. Tehát amennyiben az egyik lépésnél a kártya hibásnak minősül, a felhasználó a további teszteket megszakíthatja. Ez utóbbi esetben a VI leállásakor az alábbi naplófájl bejegyzés keletkezik: „Teszt sorozat dátum: indítva időpont1-kor. Felhasználói megszakítás időpont2-kor”

       

      h.       A VI tehát egy teszt után mindenképpen leáll, újabb méréshez, teszthez a VI-t újra kell indítani.

       

      4)      Működtető üzemmód követelményei:

      A fentebb taglalt VI-t elindítva a szakember a két említett üzemmód közül választhatja a működtető programot is. A választást követően a teszt üzemmódnál már említett mérés gombot megnyomva egy szintén dokumentált vizsgálat, a működtető logika indul el, amit az alábbiakban ismertetett módon fogalmazott meg Ákos csapata:

       

      a.       Ebben az üzemmódban ugyanazokat a Front Panel elemeket kell használni, mint a teszt üzemmód során. Amennyiben a fényérzékelőt helyettesítő csúszkát úgy állítják be, hogy értéke 3 és 4 közötti, akkor a három led-ből álló csoportban a zöld led kapcsol be. Amennyiben a beállított érték 3 alatti, úgy a sárga led világít, míg ha 4-nél nagyobb a csúszka értéke, akkor a piros színű led kell világítson. Ez a valós esetben az optimális, a túl alacsony, illetve a túl magas fényértékeknek fog megfelelni. A csúszka értékének változása a Waveform Charton természetesen most is megjelenik.

       

      b.       A működtető program részeként a gomb melletti zöld led folyamatosan villog (fél másodpercig bekapcsolva, fél másodpercig pedig kikapcsolt állapot) ezzel jelezve a szenzormodul üzemkész állapotát. Ezt az iparban is gyakran alkalmazzák, jelezve, hogy az intelligens eszközünk normál módon működik, nem „fagyott le”, nincs üzemzavar. Program üzemmódban a gombot most nem kell használnotok.

       

      c.       Amíg a teszt üzemmód során lépésről lépésre haladt a vizsgálat, addig program vizsgálat üzemmódban a villogás illetve a led csoport kapcsolása párhuzamosan történik, előre nem meghatározott ideig. A csúszka értéke bármikor és többször is változtatható egy vizsgálaton belül, mint ahogy valós esetben is változik a fényerősség.

       

      d.       A teszt üzemmód leírásában említett STOP gomb most is a vizsgálatok lezárására szolgál. Ebben az üzemmódban a vizsgálat tehát nem áll le automatikusan, de naplóbejegyzés kell megjelenjen a STOP gomb által leállított VI kapcsán: „Működtető program teszt dátum: időpont1 és időpont2 között” A félkövérrel kiemelt szövegelemek jelentése megegyezik a teszt üzemmódnál említett tartalommal.

       

      Amit be kell küldenetek a II. fordulóban:

      • A második fordulóban ezt a VI-t, a hozzá tartozó subVI-okat, és egy általatok már generált naplófájlt kell beküldenetek.
      • Úgy állítsátok össze a beküldendő fájlokat, hogy mi azt az ellenőrzéshez bármelyik könyvtárba másolhassuk. Célszerű a beküldésre szánt állományokat egy másik PC-n még a küldés előtt felmásolnotok és kipróbálni, hogy hiánytalanul mindent meg tudunk-e majd mi is nyitni, nálunk is le tud-e futni a VI.

      Jó munkát és hatékony kódolást kívánunk!

       

      LabVIEW verseny 2015 - Döntő feladata

      Sok feladatelem lesz leírva, így, ha valaki néhány feladatot nem tud megoldani, még tud részpontokat szerezni. Nem probléma, ha nem oldjátok meg az összes felsorolt feladatot, a lényeg, hogy nyugodtan, tervezetten haladjatok. Ügyeljetek a kommentelés fontosságára, az áttekinthető kód felépítésére, az informatív Front Panel felületre. SubVI-t most nem kell készítenetek! A feladathoz egy áramkör fog tartozni, amelyet a myDAQ-kal kell használnotok! A myDAQ csatornáinak eléréséhez már kaptatok segítséget, ezt az ismeretet kell felhasználnotok most. A feladatban megfogalmazott működést tehát a fizikai környezetben kell megvalósítanotok, nem csak Front Panel működést várunk tehát!

      Emlékezzetek, az egész ötlet abból indult ki, hogy már az első fordulóban Ákos egy optikai érzékelőt alkalmazott a járdán való haladás detektálására. A második fordulóban ennek a szenzornak a tesztelése már lezajlott, előttetek tehát most egy tesztelt és jól működő szenzor van. Ezen kell dolgoznotok!

      Nézzük tehát mi is a feladat. Maga az eredeti feladatnak megfelelő működés kódolása hosszabb időt venne igénybe, mint amennyi most a döntőben rendelkezésetekre áll, ezért ennek csak egy részfeladatát kell elvégeznetek!

      Első lépésként csatlakoztassátok a myDAQ-ot egy USB vezetékkel a PC-hez és az NI MAX segítségével ellenőrizzétek, hogy létrejött-e a kapcsolat!

       

      Csak a kapcsolat meglétét kell most ellenőriznetek, , ezután az NI MAX programot be is zárhatjátok, erre pontot egyik csapat sem kap. A továbbiakban a LabVIEW környezetben kell dolgoznotok! A működéshez szükséges sötétedést és világosodást a kezetekkel, a szenzor takarásával érhetitek el.

       

      A kapott áramkör egy optikai érzékelőből, egy nyomógombból és négy LED-ből áll. A myDAQ megfelelő sorkapcsait felhasználva (ezek beazonosítása a Ti feladatotok) az alábbi feladatok elvégzésére kaphattok pontokat:

      Sorszám

      Feladat leírása

      Elérhető pontszám

      1.

      Be kell olvastatni az áramkörön lévő nyomógomb digitális jelét, például a Block Diagramon elhelyezett DAQ Assistant segítségével. 

      1 pont

      2.

      A gomb hosszú nyomásával (lenyomás, majd az azt követő felengedés) indul a mérés! Tehát a VI elindításával a mérés nem indul el automatikusan. A mérés csak akkor indulhat el, ha a felhasználó legalább 2 másodperc időtartamig nyomva tartotta a nevezett áramkörön lévő gombot, majd felengedte azt. 

      2 pont

      3.

      Ezt követően a Front Panelen bekapcsol egy zöld LED, amely a mérés tényét jelzi. 

      1 pont

      4.

      Ez a bekapcsolt állapotot jelző LED fizikailag is megjelenik az érzékelő áramkörén, tehát a nyomógomb melletti LED-et, mint digitális jelet, például egy DAQ Assistant segítségével ténylegesen be kell kapcsoljátok a kapott áramkörön.

      1 pont

      5.

      Az optikai érzékelő beolvasott analóg jelét a Front Panel-en grafikusan jelenítsétek meg.

      1 pont

      6.

      Ezen a megjelenítőn fehér vonallal az optikai érzékelő jele látható, de egy másik (konstans) értékként piros vonallal jelenjen meg egy vízszintes vonal 2V magasságában[1], ez utóbbi fogja jelezni a kapcsolási határt.

       

      1 pont

      7.

      A három LED-ből álló csoportban az alsó zöld LED most a működtető szoftver üzemmódját jelzi. Sötét esetben a mérés során gyorsan villog (0,2 másodperc tartamig bekapcsolt állapot, 0,2 másodperc hosszan pedig kikapcsolt állapot), amennyiben azonban az áramkör világos állapotot detektál, úgy lassabban villog (0,5sec tartamig bekapcsolt állapot, 0,5sec hosszan pedig kikapcsolt állapot). Ez a villogás a mérés során folyamatosan látható az aktuális állapotnak megfelelő sebességgel. A sebessége természetesen a fényérzékelő beolvasott analóg jelétől függ, de a villogás csak a myDAQ-hoz kapcsolt áramkörön jelenik meg. 

      2 pont

      8.

      A mérés leállításával (lásd a továbbiakban) a villogás a LED sötét (kikapcsolt) állapota mellett természetesen abbamarad.

       

      1 pont

      9.

      A programotok a villogáson túl a mérési folyamat alatt folyamatosan olvassa és a Front Panel-en kijelzi az optikai érzékelő jelét. Amikor a VI világos állapotot detektál[2], az áramkörön lévő piros LED-et bekapcsolja, sötét állapot esetén ez a piros LED nem világít. A mérés során meg kell számlálni, hogy hányszor érzékelte a szoftver azt, hogy elhaladt egy objektum. Azaz hányszor érzékelt sötét állapotot!

      Figyelem! Azokat az eseményeket kell megszámlálni, amikor világos állapotot követően sötétet érzékelt[3] a VI, tehát nem a sötét állapotok hosszát kell mérni.

      3 pont

      10.

      Amennyiben a  számláló értéke meghaladta az ötöt, a mérés tovább folytatódik, de az áramkörön lévő sárga LED be kell kapcsoljon és végig úgy is marad. A mérés befejeztével egyedül a sárga LED maradhat bekapcsolt állapotban, amennyiben a működés során a számláló értéke meghaladta az ötöt!

      1 pont

      11.

      A mérést elsősorban az áramkörön lévő nyomógombbal lehet leállítani. A VI-t elindítva a program már futott, de hosszan nyomva lehetett magát a mérést elindítani. A mérési folyamat alatt bármikor bekövetkezett újabb hosszú nyomással[4] a mérés leáll, és a VI sem fut tovább. 

       

      2 pont

      12.

      Felkészülve azonban arra, hogy a szenzor meg is hibásodhat, a Front Panelen el kell helyeznetek egy STOP gombot, így a Front Panelről is leállítható lesz a mérés és ez a mérő VI.

       

      1 pont

      13.

      A mérés leállítását követően természetesen a mérés tényét jelző LED (lásd fentebb) mind a Front Panel-en, mind pedig a myDAQ-hoz csatlakoztatott áramkörön kikapcsolt állapotában látható 

      2 pont

       

      A feladat során összesen 25 pontot tudtok elérni, a kommentek érthetősége, a LabVIEW kód és a Front Panel megfelelő rendezettsége további 2-2 pontot ér.

       

      A győztes csapat megoldását, mellyel maximális, 25 pontot értek el, az oldal alján található FazekasA23_donto_megoldas.vi file-ban tekinthetitek meg.

       


      [1] Nektek kell leolvasni a szenzor takart állapota mellett az egyik szélső értéket, valamint a teljesen szabad szenzor esetén mérhető másik szélsőértéket és ezek között nektek kell meghatározni , szabadon felvenni egy köztes értéket, ez lesz most a sötét és világos határa, egy konstans adat a programotokban.

      [2] …átlépve a piros vonal által jelzett határt

      [3] Erre a célra szolgált tehát a már nevezett piros vonal. Ezen átlépve a világos tartományából a sötét tartományába, ezeket az átlépéseket kell megszámlálni.

      [4] A leállás nem az áramkörön lévő gomb lenyomásakor következik be, hanem a nevezett gomb megnyomását követő felengedés hatására

       

       

       

      Kérdés esetén keressetek minket!

      Minden versennyel kapcsolatos kérdést az alábbi e-mail címre várunk:

       

       labview.verseny@ni.com

       

       

       

      Az igazgatónak megtetszett a sportfoglalkozások gördülékeny rendje. A vezetőségi ülésen felmerült az igény a régi iskolacsengő modernizálására is. A csengő megbízhatatlan volt és a beállítása is nehézkesnek bizonyult. Ezzel a régebbi rendszerrel nem tudták megoldani például azt a problémát sem, hogy rövidített órákat tartson az iskola. Ebben az esetben a pedellus bácsira volt bízva a csengetés.

      A második forduló feladata egy szabadon paraméterezhető csengető óra programozása normál, illetve rövidített órákkal. 

      • Minden tanítási napon legfeljebb tíz óra lehet.
      • A csengetési rendeket igazgatói utasítás szabályozza, amit egy-egy txt fájlban rögzítenek.
      • A működést tekintve ugyanazon hanggal kell jelezni a tanórák elejét, illetve azok végét, továbbá egy rövidebb jelzést 
        kell adni az óra vége előtt öt perccel, illetve szintén ez a rövidebb jelzés hangzik el az óra kezdete előtt két perccel.

       

      Külön fájl tartalmazza a rendkívüli eseményeket (yyyy. mm. dd napon csak ez első x óra lesz megtartva). 
      Kérjük, hogy tanulmányozzátok át figyelmesen a megadott felépítésű txt fájlokat! 

      • A rendkívüli helyzetekben az igazgató ad utasítást arra, hogy adott napon nem tanítunk (igazgatói szünet esetén).
      • Mindamellett, hogy tanítás általában csak hétköznapokon van, bizonyos esetekben mégis tanítanak hétvégén 
        (munkanap áthelyezés miatt), illetve akár szünetben is (ha az év során túl sok tanítási nap maradna el).
      • Az igazgató továbbá egy hosszabb délutáni tanári értekezlet miatt egy adott napra rövidített órák tartását rendelheti el.
      • Az igazgató dönthet úgy is, hogy adott napon csak néhány óra lesz megtartva. Ez utóbbi minden esetben úgy fog kinézni, 
        hogy az első néhány óra meg van tartva, és az utána lévők maradnak el. Ekkor az eseményt az igazgató E betűvel kezdi, 
        majd szóköz nélkül egy tíznél kisebb szám áll. Például E5 jelenti, hogy csak az első 5 óra lesz megtartva.

       

      Jelenleg az alább felsorolt négyféle eseményt jelölheti meg az igazgató rendkívüli helyzetként

      • szabadnap
      • tanítunk
      • rövidített
      • E…  (ez lehet akár E3, E4, stb.)

       

      Ezen utasítások kombináltan is érvényesek lehetnek. Például rendkívüli tanítást rendel el szombatra, de erre a napra 
      rövidített órákat ír elő az iskolavezetés: 

      • 2014.02.15 rövidített
      • 2014.02.15 tanítunk

       

      Nyílván akkor lenne a legkedvezőbb a diákoknak, ha ezen a napon csak az első három óra lenne megtartva. Amennyiben ezt is leírja egy külön sorban az iskolaigazgató (például: 2014. 02. 15., E3), akkor már három feltétel határozza meg az aznapi csengetést. Kérünk benneteket, hogy a programotokat erre az eshetőségre is készítsétek fel!

       

      Példa:

      • 2014.02.15 rövidített
      • 2014.02.15 tanítunk
      • 2014.02.15 E3

       

      Üzemmódok a csengetésvezérlő PC-n:

      A csengetésvezérlő PC a portán van elhelyezve, más feladatot is ellát, de a VI (Virtual Instrument) minidig fut 24 órás üzemben.

      A portás a csengetési rendbe négy gombbal, kapcsolóval (ezt rátok bízzuk) manuálisan is beavatkozhat a Front Panelen.

       

      • Válthat tűzjelzésbombariadó, illetve órajelzés üzemmódok között (ezek közül csak egy lehet aktív), továbbá kézzel 
        átválthat rövidített órákra. Ez utóbbi funkció éjfélkor automatikusan álljon vissza normál csengetési rendre, ha esetleg 
        a portaszolgálat figyelmét elkerülné.
      • Minden egyes kézi váltást a programnak egyetlen folyamatosan bővülő txt fájlban naplóznia kell. Naptári évenként 
        egyetlen naplófájlt gondoz a rendszer. A naplófájl felépítését ti határozzátok meg és ezt a feladat beküldéskor mellékeljétek is!
      • Nyilván amíg bármilyen riadó van, addig csengetés nincs. Ezek az üzemmódok azonban automatikusan nem állnak vissza 
        csengetési rendbe, ezen eseteket manuálisan kell majd visszakapcsolni a fenyegetettség elmúltával.
      • A rendszer működését meghatározó utolsó fájlban (tanév rendje.txt) rendelkezik az igazgató az őszi, téli, tavaszi szünetek rendjéről, illetve a nyári szünetről is (pl.: nyári szünet 2014.06.15-től 2014.09.01-ig). A fájl tartalmát tekintve az első megadott nap 
        már a szünetet jelöli, illetve a dátumtartomány utolsó megadott napja szintén a szünet része még.

       

      Minden csapat, aki a második fordulóba jutott az említett négy txt állományt egységes tartalommal kapja meg, de most is 
      készítesétek fel a programot arra, hogy ezen fájlok tartalma az év során változhat. Különösen a rendkívüli események, de akár 
      a csengetési rend is! A fájlok most is tabulátorral tagolt txt állományok. A dátumokban a hónapokat sorszámaikkal jelölik, 
      továbbá mind a dátum, mind az óra, perc adatok esetén a 10 alatti értékek nullával kezdődnek (pl.: 11:5 esetén a 11:05 lesz eltárolva)

       

      Megkapjátok tehát a txt fájlok felépítését az egységes minta adatokkal. Azonban

      • az órák végét illetve elejét jelző hangfájlt,
      • a rövidebb jelzések hangját, valamint
      • külön fájlt a tűzjelzésre és egy másikat
      • a bombariadó jelzésére nektek kell elkészítenetek!

       

      Mind a négy hangfájl wav kiterjesztésű legyen, és a jelzéseket a kívánt időpontokban PC felhasználásával kell realizálni, 
      a PC hangszóró kimenetének segítségével.

       

      Törekedjetek a lehető leginformatívabb és legkényelmesebb felhasználói felületre. Alkalmazzatok subVI -okat a kód olvashatóságának, újrahasznosíthatóságának, tömörségének és egyszerűségének az eléréséhez, illetve alkalmazzatok kommenteket a forráskódban. 

      Szükséges dokumentumok és segédanyagok:

      Normál csengetési rendet tartalmazó file

      Rövidített órákat tartalmazó file

      Rendkívüli eseményeket tartalmazó file

      Tanév rendjét tartalmazó file

      LabVIEW próbaverzió és online szemináriumok