23. fejezet – Hibakeresés, diagnosztika, jelmonitorozás

Négyszintű módszertan, amely megakadályozza, hogy órákat töltsél a programban egy meglazult vezeték miatt.

Ebben a fejezetben
  1. 23.1 A diagnosztika négy szintje
  2. 23.2 1. szint — a LED-ek olvasása
  3. 23.3 2. szint — az I/O-leképezés
  4. 23.4 3. szint — jelmonitorozás
  5. 23.5 Töréspontok — és a kockázatuk
  6. 23.6 Write és Force — a fegyelem kérdése
  7. 23.7 4. szint — task-monitorozás
  8. 23.8 A hibatároló: a Log lap
  9. 23.9 Az AuditLog — ki és mit tett?
  10. 23.10 Tünet → ok táblázat
  11. 23.11 A hibakeresés folyamatábrája
  12. 23.12 Ellenőrzőlista
  13. Összefoglalás
  14. Gyakorlatok
  15. Ellenőrző kérdések
  16. Tudáspróba
  17. A fejezet forrásai

Ez a fejezet arról szól, ami a mérnöki munka nagyobbik felét teszi ki: megkeresni, mi nem működik, és miért.

A szakképesítés ezt így fogalmazza meg: „a PLC-n számítógépes hibadiagnosztikát futtat, monitorozza a ki- és bemeneti jeleket. Észlelt hiba esetén meghatározza annak kiváltó okát.” És a projektmunka egyik választható témája is ez: hibakeresés, jelmonitorozás, a hibatároló kiolvasása.

23.1 A diagnosztika négy szintje

A hibakeresés legfontosabb szabálya nem eszköz, hanem módszer: mindig a legalsó szinten kezdd.

A diagnosztika négy szintje — mindig alulról kezdd 4. Rendszerszint task-monitorozás, eszköznapló (Log) ciklusidő, jitter, kivételek, üzenetek 3. Programszint jelmonitorozás, figyelőlista, töréspontok a változók értéke, a végrehajtás menete 2. Jelszint I/O-leképezés online nézete (Current Value) a csatorna fizikai értéke és a változó 1. Hardveres szint LED-ek: SYS, RUN, DI1–8, DO1–4 van-e táp, fut-e, jön-e a jel a keresés iránya A leggyakoribb kezdő hiba A programban keresi a hibát — miközben a bemeneti LED sem világít, tehát a bekötés a hibás.
23.1. ábra. A diagnosztika négy szintje. A keresés alulról felfelé halad.
Szint Eszköz Mit mutat meg?
1. Hardveres LED-ek a vezérlőn (SYS, RUN, DI, DO) van-e táp, fut-e a program, jön-e a bemeneti jel, kapcsol-e a kimenet
2. Jelszint I/O-leképezés online nézete a csatorna fizikai értéke és a hozzárendelt változó6
3. Programszint jelmonitorozás, figyelőlisták, töréspontok a változók aktuális értéke, a végrehajtás menete3 2
4. Rendszerszint task-monitorozás és eszköznapló ciklusidők, jitter, kivételek, rendszerüzenetek4 5
⚠️ A leggyakoribb kezdő hiba

A programban keresi a hibát — miközben a bemeneti LED sem világít, tehát a bekötés a hibás.

Egy meglazult vezeték miatt órákat el lehet tölteni a logika átnézésével. Ezért van a módszertan: minden szint előfeltétele a következőnek. Ha a LED nem világít, teljesen mindegy, mi van a programban.

23.2 1. szint — a LED-ek olvasása

A legolcsóbb diagnosztikai eszköz a szemed. A CC100 LED-jei (7. fejezet):

LED Mit mond?
SYS rendszerállapot: bootolt-e, fut-e a futtatókörnyezet
RUN a PLC-program állapota
USR felhasználói LED — a programból vezérelhető
DI1–DI8 a digitális bemenetek pillanatnyi állapota
DO1–DO4 a digitális kimenetek pillanatnyi állapota

Amit ezekből azonnal meg lehet állapítani:

Megfigyelés Következtetés
semmi nem világít nincs táp, vagy nincs US+ az X4-en
SYS világít, RUN nem a vezérlő fut, de a program nem — STOP állás, vagy nincs letöltött alkalmazás
a DI LED nem gyullad ki, pedig az érzékelő aktív bekötési hiba, rossz érzékelőtípus, vagy hiányzó Uout+
a DO LED világít, de a beavatkozó nem működik hiányzik az Uin+ kimeneti táp (7. fejezet)
💡 A `USR` LED mint saját diagnosztikai eszköz

A USR LED „a WAGO könyvtárak funkcióblokkjaival programozható”. Használd ki: villogtasd például akkor, amikor egy adott programrész lefut, vagy amikor egy állapotgép egy bizonyos lépésbe ér.

Így PC nélkül is látod, hol jár a program — ami üzemi hibakeresésnél aranyat ér.

23.3 2. szint — az I/O-leképezés

Ha a LED-ek rendben vannak, a következő kérdés: eljut-e a jel a programig?

📗 I/O-leképezés (I/O mapping)

„Az I/O-térkép konfigurálása azt jelenti, hogy az eszköz be- és kimeneti csatornáit a projekt változóihoz kötjük.”6

Az I/O Mapping lap „táblázatos megjelenítése az eszköz be- és kimeneti csatornáinak, a címek és adattípusok megadásával”, és online módban kiegészül a Current Value és a New Value oszloppal.6

Ez a lap az a hely, ahol a jel útja láthatóvá válik: itt egyszerre látod, hogy a csatornán mi van, és melyik változóhoz tartozik.

Három szabály, amit a gyártó kimond:6

Szabály Szó szerint
Bemeneti változó nem írható „nincs írási hozzáférésed olyan változókhoz, amelyek bemenethez vannak leképezve”
Egy változó egy bemenet „egy meglévő változót csak egy bemenethez képezhetsz le”
Implicit változó létrehozható „az I/O-térképben közvetlenül létrehozhatsz új globális implicit változókat”
⚠️ A fixált cím csapdája

A címek módosíthatók az I/O-térképben — de a kézzel átírt címek fix szimbólumot kapnak, ami „megakadályozza az automatikus frissítést, ha az eszköz felépítése megváltozik”.6

Ez pontosan az a hiba, amely a modulbővítésnél (21. fejezet) elő tud fordulni: bővítesz egy modullal, a címek eltolódnának — de a fixált címek nem követik, és a jelek elcsúsznak.

Szabály: ne írj át címet kézzel, hacsak nincs rá nagyon jó okod. Ha mégis, dokumentáld.

23.4 3. szint — jelmonitorozás

„Futásidőben egy programozási objektum aktuális változóértékei a projekt különböző helyein monitorozhatók.”3

Három hely:3

Hol? Mit ad?
Inline monitoring — a szerkesztő online nézete az értékek közvetlenül a kód mellett jelennek meg
A deklarációs szerkesztő online nézete táblázatos áttekintés az adott POU összes változójáról
Figyelőlisták (watch lists) „objektumfüggetlen, konfigurálható” listák: bárhonnan összeválogatott változók egy képernyőn

Emellett az {attribute 'monitoring'…} pragmával „függvényhívások eredményei és property-típusú objektumok aktuális változóértékei” is monitorozhatók.3

💡 A figyelőlista a leghasznosabb

Egy összetett hiba jellemzően több POU-t érint: a bemenet az egyikben, a döntés a másikban, a kimenet a harmadikban. Az inline monitoring csak egy POU-t mutat.

A figyelőlistába összeválogathatod a jel útjának összes állomását, és egy képernyőn látod, hol szakad meg a lánc. Ez a leggyorsabb út a hiba helyének megtalálásához.

⚠️ Egy dolog, amit a könyv nem állít

A gyártói dokumentáció nem mondja ki, hogy a képernyőn látott értékek egyazon ciklusból származnak-e, és hogy a mintavételezés ciklusonként történik-e.

Hibakeresésnél ez félrevezető lehet: két összefüggő változó látszólag ellentmondó értéket mutathat, ha nem ugyanabban a pillanatban olvasta ki őket a rendszer.

A könyv ezt nem állítja, hanem méréssel vizsgáltatja meg (23.5. gyakorlat): figyelj két, egymással logikai kapcsolatban álló változót egy gyors ciklusú taskban, és nézd meg, látsz-e lehetetlen kombinációt.

23.5 Töréspontok — és a kockázatuk

A töréspontokat a 8. fejezet már bemutatta. Itt csak azt ismételjük meg, ami a hibakeresés szempontjából a legfontosabb.

⚠️ Töréspontnál a kimenetek nem frissülnek

A gyártói súgó szó szerint:2

„A »debug task« által hívott I/O-k nem frissülnek a töréspontnál történő megállás során, még akkor sem, ha a PLC-beállításokban bejelölöd a Refresh I/Os in Stop jelölőnégyzetet.”

Ez azt jelenti, hogy a beavatkozók az utolsó állapotukban maradnak: a motor forog tovább, a szelep nyitva marad, a hengert nem engedi el semmi.

Töréspontos hibakeresés valós berendezésen csak biztonságos állapotban — a mozgó részek lefékezése, a berendezés energiamentesítése vagy legalábbis felügyelet mellett.

Két további korlát:2

  • az adat-töréspont (amely egy változó értékének megváltozásakor áll meg) „csak a CODESYS Control Win esetén lehetséges” — tehát a CC100-on nem használható;
  • a feltételes töréspont viszont igen: megadható logikai feltétel vagy találatszám, például „minden 5. áthaladásnál álljon meg”.
💡 Amikor nem használhatsz töréspontot

Mozgó gépnél, folyamatos üzemben, biztonsági közelben — ilyenkor a töréspont kizárt. Mit használj helyette?

  1. Figyelőlista — nem állítja meg a programot;
  2. naplózás a programból — írj állapotváltozásokat egy tömbbe vagy egy struktúrába időbélyeggel, és nézd meg utólag;
  3. USR LED vagy egy szabad kimenet villogtatása egy adott programág lefutásakor.

Ezek mind nem invazív módszerek: a program fut tovább, te pedig figyelsz.

23.6 Write és Force — a fegyelem kérdése

A 8. fejezetből tudod a különbséget: a Write egyszeri, a Force tartós.1 Hibakeresésnél mindkettő nagyon hasznos — és a Force nagyon veszélyes.

⚠️ A kötelező ellenőrzőlista a hibakeresés végén
  1. Unforce All Values;
  2. a force-ikonok eltűnésének ellenőrzése;
  3. a kimenetek tényleges állapotának visszaellenőrzése a berendezésen.

Ha a Force benne marad, a gép a kényszerített értékkel jár, miközben a program mást gondol — és a képernyőn minden rendben lévőnek látszik. Ez a legalattomosabb hiba, amit hibakeresés közben okozni lehet.

A force feloldásának három módja:1 az Unforce All Values parancs; a force elvétele a Prepare Value párbeszédpanelen; vagy kijelentkezés — ilyenkor a rendszer rákérdez.

💡 Használd a Force-ot okosan

A Force nem ellenség, hanem eszköz. Két klasszikus, jó felhasználás:

  • egy bemenet szimulálása, amelyhez nincs érzékelőd (például egy végállás, amit nem tudsz megnyomni);
  • egy ág kizárása: egy engedélyezési feltételt igazra kényszerítesz, hogy megnézd, tényleg az akadályozza-e a működést.

Mindkettőnél: jegyezd fel, mit force-oltál, és oldd fel, mielőtt elmész.

23.7 4. szint — task-monitorozás

Ez a fejezet legfontosabb diagnosztikai eszköze, és sokan nem is tudnak róla.

A task-konfiguráció Monitoring lapja online módban a következőket mutatja:4

Oszlop Jelentés
Task a task neve
Status „Not created”, „Generated”, „Valid”, „Exception”
IEC-Cycle Count azon ciklusok száma, ahol az IEC-kód ténylegesen meghívódott
Cycle Count a bejelentkezés óta végrehajtott ciklusok száma, akkor is, ha a task STOP-ban van
Last Cycle Time (µs) az utoljára mért ciklusidő
Average Cycle Time (µs) átlagos ciklusidő az összes ciklusra
Max. Cycle Time (µs) a mért legnagyobb ciklusidő
Min. Cycle Time (µs) a mért legkisebb ciklusidő
Jitter (µs) a periodikus ingadozás aktuális értéke
Min./Max. Jitter (µs) a jitter szélsőértékei
Core processzormag száma; egymagos rendszeren -1

Az értékek a helyi menü Reset parancsával nullázhatók.4

Amit a task Monitoring lapja elárul ciklusidő ciklusok watchdog Max. Avg. Min. kiugró ciklus Az átlag megnyugtat, a maximum nem Az Average Cycle Time szépnek látszik, de a watchdogot a Max. Cycle Time váltja ki — egyetlen kiugró ciklus elég. Mindig a maximumot nézd. A jitter és a Status A Jitter a periodikus ingadozás mérőszáma — a valós idejű viselkedés minősítője. A Status = Exception azonnal jelzi, ha a task hibára futott.
23.2. ábra. Az átlag megnyugtat, a maximum nem. A watchdogot egyetlen kiugró ciklus is kiválthatja.
⚠️ Mindig a maximumot nézd

Az Average Cycle Time szép lehet — 8 ms egy 20 ms-os taskban —, miközben a Max. Cycle Time 45 ms. A watchdogot (8. fejezet) nem az átlag váltja ki, hanem az egyetlen kiugró ciklus.

Ha a Status értéke Exception, akkor ez már meg is történt: a task hibaállapotba került, és vele leállt az alkalmazás.

💡 A jitter mint minőségjelző

A jitter azt méri, mennyire pontosan tartja a rendszer a beállított ciklusidőt. Ha egy 20 ms-os task jittere 5 ms, akkor az „időzítéseid” valójában ±25%-os pontatlansággal működnek.

Tegyél mellé egy összehasonlítást a 19. fejezetből: az EtherCAT mért jittere ±20 nanoszekundum körül van. Egy általános PLC-task ettől nagyságrendekkel messzebb van — és ez rendben is van, csak tudni kell róla, amikor pontos időzítést vársz el.

23.8 A hibatároló: a Log lap

A szakképesítés „PLC-hibatároló kiolvasása” néven említi. A CODESYS-ben ennek megfelelője a Log lap.5

Súlyossági szintek:5 Warning, Error, Exception, Information, Debug message — mindegyikhez saját ikon.

Oszlopok:5

Oszlop Jelentés
Severity ikonos súlyossági jelölés
Time Stamp „a fejlesztőrendszer vagy a futtatókörnyezet dátuma és ideje”
Description „az esemény leírása”
Component „a futtatókörnyezet azon komponense, ahol a jelentett esemény történt”

Műveletek:5 Refresh (frissítés), Export („a lista tartalmát XML-fájlba exportálja”), Import, lapozó- és automatikus görgetőgombok, valamint kereső, amely a találatot sárgán kiemeli.

💡 Kész munkamenet a hibatároló kiolvasásához

Ez a projektmunka egyik választható témája — érdemes gyakorolni:

  1. Nyisd meg a Log lapot, és frissítsd a naplót.
  2. Szűrd ki az Exception és Error bejegyzéseket.
  3. Az időbélyeg alapján állítsd fel az események sorrendjét — mi volt előbb, mi következett belőle.
  4. A Component oszlopból állapítsd meg, melyik futtatókörnyezet-komponens jelezte a hibát: ez irányítja a további keresést.
  5. Exportáld a naplót XML-be — így a projektmunka dokumentációjához bizonyítékot csatolhatsz.
⚠️ Amit itt sem tudunk megígérni

A PlcLog naplónév a gyártói dokumentációban a CODESYS Control Win példája. Hogy a CC100 naplózója pontosan milyen néven jelenik meg, és hogy a WBM kínál-e a CODESYS Log lapján kívül külön, eszközszintű hibanaplót, azt a felhasznált források nem mondják ki.

Nézd meg a saját eszközödön — és jegyezd fel, mert a dokumentációdba is bele fog kelleni.

23.9 Az AuditLog — ki és mit tett?

A naplóválasztó legördülő listában elérhető egy másik napló is: az AuditLog, amely „minden felhasználói interakciót megmutat a PLC-vel. A felhasználónév is naplózva van.”5

💡 Üzemi hibakeresésnél gyakran ez a valódi válasz

„Tegnap még működött.” — Ez a mondat a hibakeresés leggyakoribb kiindulópontja, és az esetek jó részében a válasz nem műszaki, hanem emberi: valaki átírt valamit.

Az AuditLog ezt mutatja meg. Nem vádaskodásra való, hanem arra, hogy ne a rossz helyen keresd a hibát.

23.10 Tünet → ok táblázat

Ez a fejezet legpraktikusabb eleme. Minden sora egy korábbi fejezetben igazolt tényre épül.

Tünet Valószínű ok Hol ellenőrizd? Fejezet
A vezérlő nem érhető el a hálózaton gyárilag DHCP-kliens, nincs DHCP-kiszolgáló STOP + RST > 8 s → 192.168.1.17; a SYS LED narancsan villog 9.
A bemeneti LED nem világít, pedig az érzékelő aktív NPN érzékelő PNP-bemenetre kötve, vagy hiányzik az Uout+ bekötés, X12 kiosztás 3., 7.
A program fut, de a kimenet nem kapcsol az Uin+ kimeneti táp nincs bekötve X5 kiosztás 7.
A task Exception állapotba került watchdog-túllépés task Monitoring: Max. Cycle Time; Log lap 8., 23.
A gép „magától” működik a hibakeresés után a Force nem lett feloldva Unforce All Values 8., 23.
Töréspontnál a beavatkozó „beragad” megálláskor az I/O-k nem frissülnek a töréspont természete 8., 23.
Modulbővítés után elcsúsztak a jelek a kézzel módosított I/O-címek fixáltak I/O Mapping: fix szimbólum 21., 23.
A Modbus-kommunikáció szakadozik válaszidő-túllépés; RTU-nál sérül a 3,5 karakteridős keretezés Response Timeout; a soros átalakító minősége 20.
Az analóg érték „ugrál” 0–10 V-os bemenet, zavarvédelem nélküli hosszú kábel árnyékolás; áramhurok előnye 3., 7.
⚠️ Ez a táblázat a könyv saját összeállítása

A tünet → ok hozzárendelés a könyv indokolt következtetése, nem idézett gyártói tartalom. Minden sora igazolt tényre hivatkozik (a jobb szélső oszlop mutatja, hol találod), de a konkrét hibaképed lehet más okú is.

A táblázat kiindulópont, nem diagnózis.

23.11 A hibakeresés folyamatábrája

Fogjuk össze a módszertant egy folyamatábrába — az 5. fejezet jelöléseivel.

A hibakeresés folyamatábrája A rendszer nem működik Világít a SYS és a RUN LED? nem Táp, üzemmódkapcsoló, letöltött alkalmazás igen Reagál a bemeneti LED a jelre? nem Bekötés, érzékelő típusa (PNP/NPN), Uout+ igen Látszik az érték az I/O-leképezésben? nem Leképezés, fixált címek, eszközkonfiguráció igen A task állapota „Valid”? nem Max. Cycle Time, watchdog, Log lap igen A hiba a programlogikában van Csak ide eljutva érdemes monitorozni, töréspontot tenni és a logikát átnézni.
23.3. ábra. A hibakeresés folyamatábrája. Minden döntési pont egy szint; csak akkor lépünk feljebb, ha az alsóbb szint rendben van.

Figyeld meg a szerkezetet: minden „nem” ág kivezet a folyamatból egy konkrét ellenőrzéshez. Nincs olyan út, amely „gondolkodj rajta” végpontba fut.

A programlogika átnézése a legutolsó lépés — és csak akkor kerül rá sor, ha minden alatta lévő szint rendben van.

23.12 Ellenőrzőlista

Használd ezt a listát minden hibakereséskor:

Mielőtt elkezded:

  • [ ] Mi változott utoljára? (program, hardver, beállítás, kábel)
  • [ ] Mikortól nem működik? (mindig is így volt, vagy egyszer csak elromlott)
  • [ ] Reprodukálható-e? (mindig, néha, csak bizonyos körülmények között)

A négy szint:

  • [ ] 1. LED-ek: SYS, RUN, a releváns DI/DO
  • [ ] 2. I/O-leképezés: látszik-e a jel a Current Value oszlopban?
  • [ ] 3. Monitorozás: hol szakad meg a jel útja a programban?
  • [ ] 4. Task Monitoring: Status, Max. Cycle Time, jitter; Log lap: Exception, Error

Mielőtt elmész:

  • [ ] Unforce All Values és ellenőrzés
  • [ ] a töréspontok eltávolítása
  • [ ] a napló exportálása, ha dokumentálni kell
  • [ ] a javítás dokumentálása: mi volt a hiba, mit tettél, mit ellenőriztél (25. fejezet)
⚠️ A „néha működik” tünet

A 20. fejezet már kimondta, és itt megismételjük, mert ez a leggyakoribb elhanyagolt hiba:

A „néha működik” veszélyesebb, mint a „soha nem működik”. Egy nem működő rendszert mindenki megjavít. Egy időnként hibázót üzembe helyeznek — és hónapokkal később, a legrosszabb pillanatban áll le.

Ha ilyet tapasztalsz, ne örülj annak, hogy általában jó. Keresd meg az okát.

Összefoglalás

  • A hibakeresés négy szintje: hardveres (LED-ek) → jelszint (I/O-leképezés) → programszint (monitorozás) → rendszerszint (task-monitorozás, napló). Mindig alulról kezdd.
  • Az I/O-leképezés online nézetében látszik a csatorna Current Value értéke. Bemeneti változó nem írható; egy változó egy bemenethez képezhető le.
  • A kézzel átírt cím fixálódik, és nem követi az eszköz felépítésének változását — ez a modulbővítés klasszikus csapdája.
  • A monitorozás három helye: inline, deklarációs szerkesztő, figyelőlista. Összetett hibánál a figyelőlista a leggyorsabb.
  • Töréspontnál a kimenetek nem frissülnek — valós gépen csak biztonságos állapotban. Az adat-töréspont a CC100-on nem használható.
  • A Force hibakeresés végén kötelezően feloldandó (Unforce All Values).
  • A task Monitoring lapon mindig a Max. Cycle Time-ot nézd, ne az átlagot. A Status = Exception azt jelenti, hogy a watchdog már kioldott.
  • A Log lap a hibatároló: súlyosság, időbélyeg, leírás, komponens. XML-be exportálható — használd bizonyítékként a dokumentációhoz.
  • Az AuditLog megmutatja, ki és mit tett a vezérlőn.
  • A „néha működik” tünetet soha ne hagyd annyiban.

Gyakorlatok

🛠️ 23.1. feladat — Mérd meg a ciklusidőt és a watchdogot

Írj egy programot, amely egy FOR ciklusban feltölt egy tömböt. Nyisd meg a task Monitoring lapját, és jegyezd fel a Last, Average, Max és Min Cycle Time értékeket. Növeld a ciklus hosszát fokozatosan, és minden lépésnél jegyezd fel az értékeket. Mikor lép be a watchdog? Mi lesz a Status értéke? Mit ír a Log lap?

🛠️ 23.2. feladat — Kövesd a jel útját

Köss be egy érzékelőt a CC100-ra. Kövesd végig a jel útját mind a négy szinten: (1) a DI LED; (2) az I/O-leképezés Current Value oszlopa; (3) a hozzárendelt változó a monitorozásban; (4) a program azon pontja, ahol felhasználod. Készíts figyelőlistát, amely mind a négy állomást tartalmazza, ahol lehetséges.

🛠️ 23.3. feladat — Az oktató által generált hiba

Kérj meg valakit, hogy vigyen be egy hibát a rendszerbe (bekötés, program, beállítás), és ne mondja meg, mit. Keresd meg a hibát a 23.11. ábra folyamatábrája szerint, és jegyezd fel minden lépésnél, mit ellenőriztél és mit tapasztaltál. A végén hasonlítsd össze a jegyzeteidet azzal, hogy mi volt a valódi hiba: hány lépéssel korábban lehetett volna megtalálni?

🛠️ 23.4. feladat — Olvasd ki a hibatárolót

Idézz elő szándékosan egy kivételt (például watchdog-túllépéssel a 23.1. gyakorlat alapján). Nyisd meg a Log lapot, keresd meg az Exception bejegyzést, jegyezd fel az időbélyeget, a leírást és a komponenst. Exportáld a naplót XML-be, és nyisd meg egy szövegszerkesztőben. Nézd meg az AuditLog-ot is: mit rögzített a saját tevékenységedről?

🛠️ 23.5. feladat — A monitorozás konzisztenciája

Írj egy programot, amelyben két változó logikailag összefügg (például bB := NOT bA;), és mindkettő gyorsan változik egy rövid ciklusidejű taskban. Figyeld mindkettőt egy figyelőlistán. Látsz-e olyan pillanatot, amikor a két érték lehetetlen kombinációt mutat? Írd le a tapasztalatot, és fogalmazd meg, mit jelent ez a hibakeresésre nézve.

Ellenőrző kérdések

  1. Mi a diagnosztika négy szintje, és miért kell alulról kezdeni?
  2. Mit állapíthatsz meg abból, ha a SYS LED világít, de a RUN nem?
  3. Mit jelent az I/O-leképezés, és mit mutat a Current Value oszlop?
  4. Írható-e a programból egy bemenethez leképezett változó?
  5. Miért veszélyes a kézzel átírt I/O-cím?
  6. Hol monitorozhatók a változóértékek, és melyik módszer a leggyorsabb összetett hibánál?
  7. Miért veszélyes a töréspont valós berendezésen?
  8. Melyik töréspontfajta nem használható a CC100-on?
  9. Mi a Force három feloldási módja?
  10. Miért a Max. Cycle Time-ot kell nézni, és nem az átlagot?
  11. Mit jelent a Status = Exception?
  12. Mit mér a jitter?
  13. Milyen oszlopai vannak a Log lapnak, és mire jó a Component oszlop?
  14. Mire való az AuditLog?
  15. Miért veszélyesebb a „néha működik” tünet, mint a „soha nem működik”?

Tudáspróba

Válaszd ki az egyetlen helyes választ!

1. A hibakeresést ezen a szinten kell kezdeni: a) hardveres szint b) rendszerszint c) programszint d) jelszint

2. Az I/O-leképezésben online módban megjelenő oszlop: a) Cycle Time b) Current Value c) Severity d) Jitter

3. Bemenethez leképezett változó a programból: a) írható; b) csak force-szal írható; c) nem írható; d) csak szimulációban írható.

4. A kézzel átírt I/O-cím: a) automatikusan frissül; b) hibát okoz; c) törlődik újrafordításkor; d) fix szimbólumot kap, és nem frissül automatikusan.

5. Töréspontnál történő megálláskor a debug task I/O-i: a) nem frissülnek; b) frissülnek; c) csak a bemenetek frissülnek; d) nullázódnak.

6. Az adat-töréspont: a) minden vezérlőn működik; b) csak a CODESYS Control Win alatt; c) csak szimulációban; d) csak IL nyelven.

7. A watchdog kioldását ez jelzi a task Monitoring lapján: a) Status = Valid b) Core = -1 c) Status = Exception d) Cycle Count = 0

8. Melyik értéket kell figyelni a watchdog szempontjából? a) Average Cycle Time b) Min. Cycle Time c) IEC-Cycle Count d) Max. Cycle Time

9. A Log lap nem tartalmazza ezt az oszlopot: a) Jitter b) Time Stamp c) Component d) Severity

10. Az AuditLog azt mutatja meg: a) a ciklusidőket; b) a felhasználói interakciókat a PLC-vel, felhasználónévvel; c) az I/O-értékeket; d) a fordítási hibákat.

A megoldókulcs a B függelékben található.

A fejezet forrásai

  1. CODESYS Online Help: Forcing Values (V3.5.22.0). CODESYS GmbH. (2026-07-29) ↩↩

  2. CODESYS Online Help: Using Breakpoints (V3.5.22.0). CODESYS GmbH. (2026-07-29) ↩↩↩

  3. CODESYS Online Help: Monitoring of Values (V3.5.22.0). CODESYS GmbH. (2026-07-29) ↩↩↩↩

  4. CODESYS Online Help: Tab: Monitoring (task-monitorozás, V3.5.22.0). CODESYS GmbH. (2026-07-29) ↩↩↩

  5. CODESYS Online Help: Tab: Log (eszköznapló, V3.5 SP22 és újabb). CODESYS GmbH. (2026-07-29) ↩↩↩↩↩↩

  6. CODESYS Online Help: Configuring Devices and I/O Mapping (V3.5.22.0). CODESYS GmbH. (2026-07-29) ↩↩↩↩↩

Mennyire volt hasznos ez a fejezet?

Még nincs értékelés.