DP station állapotának lekérdezése S7 PLC-ben

Gyakran előfordul, hogy S7-300/400 PLC-s rendszerben nem csak a CPU-ra közvetlenül csatlakoztatott modulok vannak, hanem olyan CPU-t kell használnunk, amin van DP (distributed periphery) , vagyis profibusz csatlakozás.
A profibusz egy ipari busz rendszer, ami az RS485 szabványú fizikai rétegre épül. Nagy sebességű (max. 12MBPS) kommunikáció segítségével intelligens, távoli perifériák és a vezérlő PLC közötti kommunikációra szolgál. Profibuszra rengeteg különféle eszközt lehet rákötni, a választék nagyon széles. Kezdve a távoli analóg, digitális ki és bemeneti pontokkal, a távadókon keresztül a legkülönfélébb jeladókon át (ultrahangos vagy lézeres távolságmérők, enkóderek) egészen a hajtásvezérlőkig (Pl. frekvenciaváltók), HMI-t (megjelenítőt) vagy akár másik PLC-t is. Felsorolni is hosszú lenne.
Egy bonyolultabb vagy kiterjedtebb rendszer szinte mindig tartalmaz profibuszos eszközt. A profibusz és profbuszos eszközök jelenléte a PLC programozó számára plusz feladatokat jelent, bonyolítja a rendszert és így természetesen a PLC programot is. Az ilyen eszközök jelenléte nagymértékben kiterjeszti a rendszer lehetőségeit, ugyanakkor sok új problémát is felvet.

Nézzünk egy egyszerű példát.
Képzeljünk el egy olyan összeállítást, amikor az S7 PLC-re csatlakoztatva van közvetlenül néhány ki és bemeneti modul, de a vezérelt berendezés fizikai kiterjedése indokolja hogy egy távoli ponton (egy másik vezérlőszekrényben) további ki és bemeneti pontokat létesítsünk. A módszer előnye, hogy a PLC-hez közeli jeleket a PLC közvetlenül a helyszínen fogadja, a távoli jelek pedig szintén a jelek forrása közelében a PLC-től távol távoli I/O pontokra csatlakoznak. Így a távoli hely és a PLC között csak egy profibusz kábel lefektetése szükséges, nem kell minden egyes ki és bemeneti pontot külön kábel éren a PLC-hez továbbítani. Ez a módszer néha már akkor is kifizetődő, ha azok a távoli pontok nem is annyira távol, csak 10-20 méterre vannak.



A képen egy S7 315-2 DP PLC-vel felépített kis méretű profibusz hálózat HW konfig képe látható. A CPU 315-2 DP egy olyan S7-300-as PLC, ami tartalmaz egy beépített profibusz DP kommunikációs processzort, azaz van beépített profibusz csatlakozása.
A jobb oldalon, a buszra csatlakozó IM153 egy ET200M modul, amire távoli ki és bemeneti modulok vannak csatlakoztatva. Valamint két VLT5000 frekvenciaváltó is a buszonk eresztül kommunikál a CPU-val. A buszra csatlakozó minden eszköznek van egy címe (station address, vagyis állomás cím). Mindegyik eszköznek más címet kell adni (nem lehet két azonos című eszköz egy buszon). A station address alapján szólítja meg a CPU az eszközöket a kommunikáció során, a cím alapján dönti el a buszon lévő eszköz, hogy a CPU őt akarja-e olvasni, vagy nem.
Az ábrán látható konkrét esetben az IM153-as interfész modulra csatlakoztatott digitális ki és bemenetek I/O címeit (mert címe nem csak a profibuszos eszköznek van, hanem a ki és bemeneti pontoknak is) pontosan úgy határozzuk meg, mint ha azokat közvetlenül a CPU-ra csatlakoztattuk volna:



A képen az IM153 csatlakozóhelyeire kapcsolt ki és bemeneti modulok listája látható. A második bemeneti modul első bemenetének címe tehát I12.0 lesz, a következő I12.1 és így tovább.
Tegyük fel továbbá, hogy a CPU-ra közvetlenül csatlakozó bemenetek címei az I0.0 címen kezdődnek
Egy ilyen összeállítás esetén a PLC programjában egyáltalán nem kell azzal törődni, hogy a I8, I9, I10, I11... I15  bemeneti byte címek egy profibuszos kapcsolaton vannak, egyszerűen berakjuk a programba pl. az I10.4-es bemeneti címet és ugyanúgy működik, mintha az I10.4-es bemenetet tartalmazó modul a CPU-n lenne. Az IM153-ra csatlakoztatott kimenetekkel pontosan ugyanez a helyzet.
A frekvenciaváltókkal más a helyzet. Azokat a beállított PPO típusnak megfelelően periféria be és kimeneteken keresztül (PI és PQ) és SFC rendszerhívások segítségével tudjuk elérni, mivel a frekvenciaváltóknál nagyságrendekkel több információ közlésére van mód.

Ez tehát nem bonyolult. A profibusz miatt csak annyi többletmunka akad, hogy a hardver konfigurációban pontosan meg kell határoznunk a busz felépítését és ismernünk kell a frekvenciaváltó kezelésének módját.
A problémák akkor jönnek, ha a buszon a kommunikáció valamilyen ok miatt megszakad. Egy helyi I/O-nál ilyen probléma nem fordulhat elő, a hasonló problémák valószínűsége is kisebb. A távoli modulok tápfeszültsége azonban megszűnhet, mivel az többnyire saját, a CPU tápegységétől független tápegységről üzemelnek, a kábel megsérülhet.
Az ilyen eseteket külön kezelni kell. Ha ezek kezelésére semmit nem teszünk és a kommunikációs probléma bekövetkezik, akkor a CPU STOP állapotba kerül, a program futtatását hibajelzés kíséretében leállítja. A kommunikáció megszakadásának pillanatában ugyanis az történik, hogy a CPU számára elérhetetlenné válik a buszon lévő frekvenciaváltóhoz tartozó periféria ki vagy bemenet. A DP eszköz leválásakor a CPU operációs rendszere a buszon történő következő hozzáféréskor detektál egy "Distributed I/O station failure" hibát és kísérletet tesz az említett hiba kezelésére szolgáló speciális organisation block, az  OB86 (Rack Failure) meghívására. Ha nincs OB86, akkor a CPU leállítja a program futtatását (STOP).





Ha ez az eljárás az adott technológiai követelményeknek megfelel, akkor a PLC programban továbbra sem kell tennünk semmit, a kommunikáció megszakadását okozó probléma elhárítása utána  CPU újraindítható és minden megy tovább.

Az esetek többségében azonban a program leállása nem kívánatos esemény, ezért a PLC programban foglalkoznunk kell ezzel az esettel, erről szól ez az írás.
A dolgot több oldalról is meg lehet közelíteni, köszönhetően az S7 PLC rendkívül fejlett hibakezelési lehetőségeinek. Egy lehetséges megoldást fogok leírni. Mivel azonban a hibakezelés a legtöbb rendszerben kényes (és nehéz) kérdés, érdemes más lehetőségeket is átgondolni, az adott feladatnak és biztonsági kockázatoknak legmegfelelőbbet alkalmazni!
Nos ha nem akarjuk, hogy a kommunikáció leállásakor a CPU STOP állapotba kerüljön, akkor írnunk kell egy OB86-os hibakezelő blokkot. A legegyszerűbb ilyen blokk teljesen üres. Mivel azonban már létezik a blokk (még ha üres is) a CPU a hiba bekövetkezésekor meg tudja majd hívni, így nem kerül STOP módba. Ettől persze a buszról levált ki és bemeneteket, frekvenciaváltókat még nem lesz képes elérni. Úgyhogy ha a program ennek ellenére megpróbálja (márpedig meg fogja, mert nem tud róla hogy baj van), akkor jön a következő probléma: A CPU nem létező periféria címet próbál írni vagy olvasni. Ez egy újabb hibát generál, nevezetesen az "I/O access error when writing" (vagy reading) hibát, aminek egy "STOP caused by I/O access error" lesz a vége. Tehát a CPU megint leállítja a program futását, amikor megpróbálja lefuttatni az I/O access error kezelésére hivatott, de nem létező OB122-es organisation block-ot.





Nosza hozzunk létre egy OB122-t is, ami szintén üres, had hívogassa.
Ezután már nem fog STOP állapotba kerülni a CPU ha a buszon lévő akármilyen eszköz leválik vagy ha a CPU nem is létező periféria címre hivatkozik. De jó-e ez nekünk?
Általában nem, mert az üres hibakezelő blokkok berakása megint egy kellemetlen következménnyel jár. Azzal, hogy a program nem lesz képes észlelni azt, hogy a buszos eszközök elszálltak és ő már réges régen csak a levegőbe beszél, amikor a buszon parancsolgat nekik. Az ilyesmi roppant izgalmas tud lenni pl. a bemenetek olvasásakor. Ha ugyanis a buszról levált modul egyik digitális bemenetét olvassa a program, akkor nulla állapotot kap. Pontosan ugyanúgy, ahogy nulla állapotot kap akkor is, amikor a busszal semmi baj nincs, és a bemenet fizikailag is nulla állapotban van. Ez a két eset nem lesz megkülönböztethető, ami általában baj. Más szóval a PLC programja nem fogja tudni, hogy amikor egy bemenet nulla, akkor azért nulla-e, mert éppen nincs kommunikáció, vagy azért, mert tényleg nulla állapotban van. A berendezéstől nagyban függ ugyan a dolog, de ez általában nagyon nem mindegy. Persze feláldozhatunk egy bemenetet a hiba megkerülésének oltárán azzal, hogy fizikailag (dróttal) állandó 1 szintre kötjük, és a program ezt a bemenetet figyeli. Ha ez menet közben nulla lesz, akkor nincs kommunikáció és ennek megfelelően jár el. Nem épp korrekt megoldás, ráadásul az élet sosem ilyen egyszerű, itt van ugyanis az a két fránya frekvenciaváltó. Azoknak a hibakezelését nem tudjuk ilyen nagyvonalúan elintézni, mivel a CPU teljesen más módon éri el őket.
Persze ha a fent említett hibakezelő OB86 és OB122 nem üres, hanem egy olyan programrészt írunk bele ami pl. egy hibajelző merker bitet bekapcsol a hiba keletkezésekor és kikapcsol a hiba megszűnésekor, kicsit közelebb jutunk az üdvözítő megoldáshoz, mivel lényegében ezeket az OB-kat épp ilyesmire találták ki.

De ne örüljünk túl korán, mert a buszon nem csak egy periféria üldögél. Ez azonnal felveti annak az esetnek a lehetőségét, hogy ezek képesek lesznek és nem mindannyian egyszerre szakadnak le a majd a buszról, csak hogy minket bosszantsanak. Ekkor az egybites OB-nk is csődöt fog mondani, hiszen pl. a Rack failure OB86 bármilyen periféria leválásakor és visszacsatlakozásakor lefut, amikor is a jelzőbit szépen átbillen, de egy jelzőbitből bizony nem fog kiderülni hogy a három eszköz közül melyiknek támadtak problémái. Nos itt meg is állhatunk, ha ez nem is érdekel senkit, mert pl. a hibajelző bitünk csak egy kürtöt kapcsol be és leállítja a gépet (persze a programunk most már fut tovább ezután is).
Ha tudni akarjuk, hogy melyik eszközzel van a baj, esetleg azt is, hogy mi, akkor jönnek a bonyodalmak. Ilyenkor ugyanis mélyebben bele kell mászni a hibakezelő OB-k lehetőségeibe. Ki kell olvasni és meg kell vizsgálni az OB-k rendszerváltozóinak tartalmát, amik mindig pontosan megadják a választ arra, hogy az OB miért került meghívásra.
Az OB122-vel is nagyon kell vigyázni. Ha létrehozzuk, akkor a vállunkra vesszük azt a terhet, hogy onnantól nekünk kell törődni az összes elképzelhető írási és olvasási hibával, ami nem feltétlenül merül ki a profibuszról levált és ezért elérhetetlen eszközök perifériacímeinek elérési kísérleteiben!
Az egyik megoldás a probléma korrektebb kezelésére tehát egy átfogó hibakezelés az OB86-ba, ami az OB86 részletes ismeretét feltételezi. Az OB86-ban beállított jelző merkerekkel ezután feltételeken keresztül megakadályozható, hogy az éppen el nem érhető eszközhöz a program megpróbáljon hozzáférni, így az OB122-re nem lesz szükség.
A másik megoldás, hogy az SFC51-es rendszerhívással folyamatosan lekérdezgetjük a profibuszos eszközök állapotát.

Az SFC51

Az SFC51 (RDSYSST) a rendszerállapot lekérdezésére szolgáló S7 rendszerhívás.
Rengeteg funkciója van, többek között képes arra, hogy egy általunk megadott buszon (mivel egy S7 rendszerben több busz is lehet) lévő eszközök készenléti állapotát lekérdezze.



Paraméterek:
REQ Logikai érték. Ha 1, akkor a többi paraméter által meghatározott kérés végrehajtásra kerül
SZL_ID WORD, általában konstans, ezzel mondjuk meg az SFC51-nek, hogy milyen információt szeretnénk kapni. Több mint 50 lehetőség közül választhatunk. Amire nekünk szükségünk van, a 692 hexadecimális konstans azonosítja:
"OK state of the expansion racks in a central configuration / of the stations of a DP master system connected via an integrated DP interface module"
Ez kb. annyit tesz, hogy a központi egységre csatlakoztatott bővítő fiókok, illetve a beépített DP interfészre csatlakozó DP állomások készenléti állapotának lekérdezése.
Ha a lekérdezendő DP eszközök nem a CPU-ba épített DP interfészre csatlakoznak, hanem egy külön DP bővítő interfészre, akkor itt a W#16#4692 számot adjuk meg. (lásd SFC51 help-je)
INDEX Ennek a paraméternek a jelentése az SZL_ID-ben megadott feladattól függ. W#16#692 mellett az INDEX paraméterben a DP master system számát kell megadni. Ha ez nulla, akkor a központi egységre közvetlenül csatlakoztatott bűvítők állapota kérdezhető le. Egyébként a HW config-ban megadott master system számát kell ide betölteni.
RET_VAL Integer, amiben a blokk a hibakódját adja vissza. Ha 0, nincs hiba
BUSY Logikai állapotkimenet, 1 értéked ad, amíg a korábban indított kérés be nem fejeződik.
SZL_HEADER Struktúra. Ebben adja vissza a blokk,  két WORD típusú adat formájában, hogy a DR kimeneti paraméter mennyi állapot információt tartalmaz. Erre azért van szükség, mert az SFC51 univerzális, az általa vissaadott adatok mennyisége a körülményektől és az SZL_ID-től függ. Mi most nem törődünk ezzel, mert az általunk kért infó ismert mennyiségű adatot ad vissza. Azonban a paraméter megadása kötelező, a struktúra szerkezete az alábbi:
SSL_HEADER: STRUCT
    LENTHDR:    WORD
    N_DR:        WORD
END_STRUCT

DR ANY: Adatrekord Egy mutató, ami arra a címterületre mutat, ahova az állapot információkat le kell rakni.
Amikor az SZL_ID W#16#692 vagy W#16#4692, akkor az SFC51 128 bit információt ad vissza (16 byte)

A hívást tegyük az OB1 elejére, hogy a periféria leválása még azelőtt kiderüljön, hogy a programunk a folyamatban lévő PLC ciklusban megpróbálná elérni. Az EN "bemenet" elé ne írjunk feltételt, hogy minden ciklusban lefusson. Ha azt akarjuk, hogy ne hajtsa végre az állapot lekérdezést, a REQ bemenet elé tegyük a megfelelő feltételt.
A fenti példa a DB1-es adatblokk 10-es byte címétől kezdődően 128 bit állapotát állítja be a lehetséges 128 profibuszos eszköz állapotának megfelelően.
A fenti megvalósításhoz szükség lesz a DB1-es adatblokkra, aminek 10-25-ös byte címeit a DP állomások hibajelzésének szenteljük és jól vigyázunk, hogy más programrészek ezt a területet véletlenül ne írják felül.



A képen egy példa látható a DB1 belső felépítésre. A kép a teljes DB1-et mutatja, amiben a számunkra most fontos 10. byte cím előtti definíciók mibenléte közömbös. Mivel az SFC51-nek azt mondtuk, hogy a DP státus biteket a a DB1 10. byte-jától kezdődően rakja le, fontos hogy az ennek szánt terület is itt kezdődjön, vagyis a terület előtt kell lennie 10 byte "valaminek".
Engedve az emberbe genetikai szinten kódolt lustaság erős kényszerének a 128 bit számára szükséges hely létrehozása egy laza ARRAY[1..16] defínícióval lett megvalósítva. Akinek végtelenül sok ideje van, az megteheti, hogy 128 darab boolean típusú változót hoz létre egyenként, és mindegyik Comment mezőjébe beírja hogy konkrétan melyik DP eszköz állapotát jelzi.
Az adatblokkban tehát így vagy úgy, a DB1.DBX10 tartalmazza 1-8 DP című eszközök állapotát, 0. bit az 1-es című, 1-es bit a 2-es című stb.
DB1.DBX11-ben lesz a 9-18-as című eszközök állapota, és így tovább. A DB1.DBX26 bitjeiben tehát a 120-128-as eszközök állapota.
Mivel az IM153-as modul DP címe 8, így annak állapotát a DB1.DBX10.7 bit fogja tükrözni, a 9-es című frekvenciaváltóét a DB1.DBX11.0, a 10-es frekvenciaváltóét pedig a DB1.DBX11.1-es bit.
A buszon összesen lehetséges 128 eszköz mindegyikéhez tartozik tehát egy bit, ami az adott eszköz állapotát jelzi. Ha a bit 1-ben van, akkor az egy olyan eszköz, ami a HW config-ban szerepel, de nem elérhető, nem üzemkész, levált a buszról, stb. Ha a bit 0, minden rendben vele. Természetesen a nem használt DP címekhez tartozó biteket figyelmen kívül hagyjuk, nem törődünk velük.
Azok a bitek, amelyekhez nem tartozik eszköz (a HW config-ban sem), mindig 0 állapotban maradnak.



A képen egy online VAT tábla (változótába) látható. A tábla úgy lett beállítva, hogy a DB1 10-25-ig terjedő byte-jainak az állapotát jelenítse meg binárisan, vagyis azt a 128 bitet, ami a 128 lehetséges DP eszköz címéhez tartozó állapot bit. A pirossal jelölt DB1.DBB10 és DB1.DBB11 byte-okban látható két 1 állapotú bit. Ha utána számolunk, ez a 8-as című IM153-as bővítő és a 10-es című egyik VLT5000 frekvenciaváltó problémáját jelzi.

Az üres OB86-ra így is szükség lesz, mert az eszköz elvesztésekor vagy visszatérésekor mindig megpróbálja meghívni, és ha nincs -> CPU STOP.
Az OB122 azonban nem kell, mivel minden eszköz állapota ismert a programban, vagyis meg tudjuk akadályozni hogy a levált eszközhöz megpróbáljon hozzáférni.
Ennek egyik módja, ha a DP periféria kezelését külön blokkba helyezzük és a blokk hívását a hozzá tartozó készenléti bit állapotától tesszük függővé, valahogy így:



Érdemes még figyelni az SFC51 RET_VAL paraméterben visszaadott hibakódját. Ha nem nulla, akkor hiba történt és a blokk nem lett végrehajtva, tehát az állapot bitel nem az eszközök aktuális állapotát mutatják.

Természetesen a program hibára futásának kerülgetése mellett az eszközök leválásakor így már leprogramozhatjuk a probléma felmerülésekor teendő egyéb lépéseket is (pl. hibajelzés a kezelő számára, üzenet megjelenítése az HMI-n, illetve a technológiai lépéseket: a gép egyes részeinek leállítása, vagy éppen elindítása, a teljes berendezés leállítása, stb).

A busszal kapcsolatos problémákról a CPU előlapján lévő LED-ek is adnak valamennyi tájékoztatást:

BUSF LED Leírás
Nem világít A busz rendben. Minden konfigurált eszköz elérhető.
Világít Busz hiba (hardver hiba), A DP interfész meghibásodott, vagy eltérő sz adatsebesség multi master módban
Villog Egy vagy több konfigurált DP állomás nem elérhető



Megjegyzés: A busz hibákat egy újonnan fejlesztett berendezésen konfigurálási hibák is okozhatják!


  
Szirty