A. függelék – 08. fejezet: megoldások és megoldókulcs

Gyakorlatok — megoldások

8.1. feladat — Telepítsd az eszközleírást

Értékelési szempontok

A jó válasz megnevezi a fájl nevét és kiterjesztését (a WAGO eszközleírásai jellemzően .devdesc.xml vagy tömörített .zip/csomag formában érkeznek), és megmondja, melyik kategóriába került az eszköz a Device Repository fájában (PLC-k, illetve gyártó szerinti csoport).

A feladat lényege nem a fájlnév, hanem az, hogy megtapasztald: a kábel önmagában kevés. A CODESYS addig nem tud mit kezdeni a vezérlővel, amíg nem ismeri a képességeit (8.3).

⚠ Gyakori hiba: a Device Repository-ba telepített leírás után a régi projektet megnyitni, és csodálkozni, hogy nem látszik az eszköz. Új projektet kell nyitni, vagy az eszközt cserélni (Update Device).

8.2. feladat — Építsd fel az eszközfát

Mintamegoldás

Device (CC100)                 ← te választottad ki
├── PLC Logic                  ← automatikusan jött létre
│   └── Application            ← automatikusan
│       ├── Library Manager    ← automatikusan
│       ├── PLC_PRG (PRG)      ← automatikusan (a projektvarázsló szerint)
│       └── Task Configuration ← automatikusan
│           └── MainTask       ← automatikusan, benne a PLC_PRG hívása
└── (I/O, buszcsatolók)        ← eszközfüggő

A task-konfiguráció az Application alatt található; itt állítható a task típusa, intervalluma, prioritása és a watchdog (8.6–8.7).

8.3. feladat — Számold ki a watchdog-időt

Megoldás

A kioldás feltétele a Time × Sensitivity szorzat:

50 ms × 3 = 150 ms

• 12 ms-os átlagos futásidő: semmi baj, bőven a korlát alatt.
• 160 ms-os kiugrás: a ciklus túllépi a 150 ms-ot, tehát a watchdog kiold, a task hibaállapottal (kivétellel) megáll — és vele az alkalmazás is. Ez üzemleállás, nem figyelmeztetés.

A helyes reakció a program átalakítása, nem a watchdog-idő növelése. Az indoklás:

1. A watchdog tünetet jelez, nem okoz: egy 160 ms-os ciklus egy 20 ms-os taskban azt jelenti, hogy a program nyolcszorosan túllépi a saját ütemét — a vezérlés ezalatt nem reagál.
2. A watchdog-idő felemelése elrejti a problémát, de a reakcióidő így is romlik: a gép a kiugrás alatt vak és süket marad.
3. Keresni kell, mi okozza a csúcsot: hosszú ciklus (FOR), lassú kommunikációs hívás, nagy adatmozgatás. A megoldás jellemzően a művelet több ciklusra szétosztása vagy alacsonyabb prioritású külön taskba tétele.

⚠ Gyakori hiba: a watchdog kikapcsolása. Akkor egy végtelen ciklus észrevétlenül fagyasztja meg a vezérlőt — ez rosszabb, mint a szabályozott leállás.

8.4. feladat — Írj és futtass szimulációban

Mintamegoldás

PROGRAM PLC_PRG
VAR
    bGomb    : BOOL;
    rtGomb   : R_TRIG;
    iSzamlalo : INT;
END_VAR

rtGomb(CLK := bGomb);
IF rtGomb.Q THEN
    iSzamlalo := iSzamlalo + 1;
END_IF

A várt tapasztalat: a Write Values paranccsal TRUE-ra állított bGomb hatására a számláló pontosan eggyel nő — akkor is, ha a változó több cikluson át igaz marad. Ez az élfigyelés lényege (18.2).

⚠ Gyakori hiba: az R_TRIG példány elhagyása és közvetlenül az IF bGomb THEN használata. Ekkor a számláló ciklusonként nő, azaz másodpercenként több százzal.

8.5. feladat — Tapasztald meg a Force-ot

Értékelési szempontok

A várt tapasztalat: a kényszerített változó értéke minden ciklusban visszaáll a kényszerített értékre, a program írása ellenére. Az Unforce All Values után a számlálás onnan folytatódik, ahová a kényszerítés állította.

A záró mondatnak ezt kell tartalmaznia: egy valódi gépen bent felejtett Force azt jelenti, hogy a program egy része hatástalan — a gép „megmagyarázhatatlanul” viselkedik, és a programban keresve soha nem találod meg, mert a kód helyes. Ezért kell a kényszerítést dokumentálni, és a munka végén ellenőrizni (8.11, 23.6).

Tudáspróba — megoldókulcs