Hirdetés

Keresés

Új hozzászólás Aktív témák

  • Szirty

    őstag

    válasz rsf #3402 üzenetére

    Helló rsf!

    A diag buffer úgy működik, hogy bizonyos hibáknál van incoming meg otgoing esemény. Tehát amikor a hiba keletkezik, meg amikor megszűnik.
    Pl. egy rack leválása a terepi buszról ilyen incoming esemény, a visszacsatlakozása pedig outgoing esemény.
    Az ilyen hibáknál a beérkező esemény létrehozza a hibaállapotot, a kimenő esemény meg megszünteti azt.
    Ebben az esetben tehát a BF LED hibát fog jelezni az állomás leszakadásakor és a hibajelzés megszűnik amikor sikerül neki újracsatlakozni.
    Ez akkor is így van, ha a két esemény között napok vagy hónapok vagy akár évek telnek el (de újraindításkor az esemény újra létrejön).
    Vannak azonban olyan hibajelzések is, amelyeket programozási hibák okoznak. Az ilyennek nincs incoming meg outgoing eseménye. Ilyen pl. egy BCD konverziós hiba vagy a mellékelt képen látható I/O access error is.
    Ilyen hibánál az SF LED hibát jelez. Ha csak egyetlen egyszer volt hozzáférési hiba akkor a LED egy idő múlva kialszik. Ezzel ad esélyt arra,hogy a hibát észrevedd (különben csak 1 ms-ra villanna fel egyszer.
    Ha azonban a hiba minden egyes PLC ciklusban megismétlődik, annak két következménye van:
    Egyrészt az SF LED folyamatosan hibát fog jelezni, másrészt a diag bufferben minden egyes hiba bejegyzésre kerül.

    Na most a periféria leválása a buszról és az I/O access error nem ritkán járnak kézen fogva, mert a programban a hibakezelés trehányul van megvalósítva (vagy sehogy, lásd üres hibakezelő OB, hogy ne legyen CPU STOP).
    A te eseted szerintem éppen ilyen.

    Működik szépen a program távoli IO-k rendben működnek, a PLC program minden ciklusban írja és olvassa ezeket a távoli IO-kat a saját címűkön. Egyszercsak leszakad a távoli I/O, erre kerül egy üzenet a diag bufferbe, hogy ez és ez az I/O leszakadt. Mivel a programozó frappánsan rakott egy üres OB*t, hogy emiatt ne legyen CPU stop, a program rója tovább a köröket és egyszer csak oda ér, ahol ezeket a leszakadt I/O-kat olvassa vagy írja.
    Erre mi történik? Hát nem más, mint I/O access error, hiszen olyan periféria címekhez szeretne hozzáférni, amik a leválás miatt pillanatnyilag nem is léteznek. Ettől lenne ugye egy CPU STOP, de a fejlesztő egy második huszárvágással valószínűleg erre is rakott egy üres OB-t ezért ettől sem lesz CPU stop. Lesz azonban egy I/O access error bejegyzés a diag bufferben, de nem baj, mert a program fut tovább. Aztán egyszer szeretné elérni a másik leszakadt perifériát aminek az eredménye újyabb access error, és újabb bejegyzés a diag bufferben.
    Amikor a PLC újrakezdi a ciklust az egész kezdődik elölről és a diag buffert telefossa I/O access errorokkal.
    Másodpercenként belerak pár százat ami jól látszik a mellékelt képen mert az időbéjegek között 2-20ms különbség van.
    Igen ám, de a diag buffer hossza sem végtelen, ezért amikor az megtelik a legrégebbi üzenetet kiejti.
    No és mi volt az az üzenet, hát az, amikor a távoli I/O leszakadt és elkezdődött az access error áradat.

    Aztán szépen visszacsatlakoznak a távoli IO-k, ezért elérhetővé válik az összes periféria és immáron a program hozzáférési kísérlete is iskeres lesz így nem kerül be több bejegyzés a diag bufferbe.

    Tehát ha a CPU error státusban van de a diag bufferben hónapokkal azelőtti bejegyzések vannak, akkor valószínűleg van egy hiba ami azóta is fennál, de már nem látod a diag bufferben mi is az a hiba, mert 300 másik hiba miatt telefirkálta a diag buffert és a régi üzenet elveszett.

    "Nem régóta foglalkozok siemens-el és nagy csalódás volt."

    Az ismerkedést nem hatalmas programmal kell kezdeni ahol terepi busz van, ezer analóg mérés, hajtásvezérlők operátor panelek, stb. Hanem alacsonyabban és lépésről lépésre. Akkor lesz siker élmény és még az is kiderülhet, hogy nem is olyan rossz ez. Összetett és sokat tud, csütörtökre ezt nem lehet megtanulni :-)
    Kitartás! Sok sok kitartás (nagyon sok kitartás!)

Új hozzászólás Aktív témák