A Profibus DP-re köthető eszközök alapvetően két csoportba oszthatóak:
- Master (mester)
- Slave (szolga)
Bár ez nem általános, egy buszon több master is lehet. Minden egyes slave-et hozzá kell rendelni egy és csakis egy master-hez. A buszra kötött elemeknek buszcíme van, a hozzárendelést ezek használatával, a PC-n futó Step7, vagy más fejlesztőrendszerrel kell elvégezni. Jobb DCS-ek rendszerszoftverébe is be van építve a DP konfigurálás.
A fejlesztési munka előtt győződjünk meg arról, hogy a fejlesztőrendszerünkbe be van töltve minden, a rendszerben felhasználni kívánt eszköz (PLC, I/O, hajtás) eszközleírója, azaz GSD file-ja. Ha ez megvan, a fejlesztő rendszerben elérhetőek lesznek azok a felületek, melyekben az eszközt fel lehet paraméterezni. Ha a GSD file mellett ott van az eszköz ikon file-ja is (BMP formátum) akkor a menükben ezzel jelenik meg.

Térjünk vissza a topológiához!



Ez az ábra elméleti lehetőséget mutat, a DP-t alapvetően nem PLC-PC kapcsolatra találták ki (Erre a Siemens-eszközöknél inkább Ethernet-et ill. Profibus FMS-t szokás alkalmazni.) de az elv működik. A képen pl. a piros master csak a piros slave-eket írhatja. Figyeljük meg, hogy a feketével rajzolt PC-k egyetlen slave-et se írhatnak. Ez nem törvényszerű, de eléggé általános (Hacsak nem PC-alapú a kontroll is.) Olvasni persze minden master jogosult minden slave-ből.

Látható, hogy a DP szigorú, németes logikát követ. Ez azzal is együtt jár, hogy nem lehet üzem közben elemeket a rendszerhez adni. Ha erre van szükség, leállítjuk a rendszert, bekötjük és felprogramozzuk az új eszközt, majd újraindítunk. Általánosságban is elmondható, hogy a DP-re épülő rendszerek eléggé konfigurálásigényesek. Sok-sok paramétert kell beállítani, mielőtt a rendszert elindítanánk. Utána viszont gyorsan fut.

A master-ek egymással egy token ring-et alkotnak. Ez azt jelenti, hogy a címeik által meghatározott sorrendben, és az előre konfigurált ideig megkapják a buszt. Ez így megy folyamatosan körbe- körbe. (A 2. ábra négy master-t mutat, semmi köze az 1. ábrához:)



Míg a master a buszt birtokolja, a következő kommunikációkra van módja:
- Peer-to-peer:
A master-ek közötti kommunikáció. Pl. a PC-ről adatbeadás a PLC-kbe.
- Master-slave:
A PLC az I/O-val kommunikál.
- Broadcast:
Mindenki aki a buszon van, köteles venni ezt az adást. Nyugtázni nem kell.
- Multicast:
Az erre programozott "vevők" kötelesek venni ezt az adást. Nyugtázni nem kell.

Hibakezelés:
Mi történik akkor, ha eltűnik mondjuk egy slave?
Ez megeshet mondjuk azért, mert kihúztuk a DP csatlakozóját. Ebben az esetben a slave-ben futó idő-őr észreveszi a kommunikáció kiesést és az összes kimenetét az előre konfigurálandó (!!!!) biztonságos állapotba kapcsolja. Mit csinál a master-e ilyenkor? Két eshetőség van: Ha a master "auto-clear" paraméterét 1-be állítjuk, a master az összes slave-jének a kimenetét az előre konfigurálandó (!!!!) biztonságos állapotba kapcsolja, majd "Operate" azaz üzemel üzemmódból átkapcsol "Clear" azaz töröl üzemmódba, és saját fizikai kimeneteit is az előre konfigurálandó (!!!!) biztonságos állapotba kapcsolja.
Ha a master "auto-clear" paraméterét 0-ba állítjuk, a master "operate" módban marad, és fut tovább. Ebben az esetben a hibakezelést nekünk kell megírni.

Mi történik akkor, ha eltűnik mondjuk egy master?
Ebben az esetben a hozzá tartozó minden slave-ben futó idő-őr észreveszi a kommunikáció kiesést és az összes kimenetét az előre konfigurálandó (!!!!) biztonságos állapotba kapcsolja. Az összes többi master akkor értesül az esetről, mikor az eltűnt master nem jelzi vissza a token kézhezvételét. Ekkor a következő sorszámú master-hez kerül a token.

A jövő héten a DP szolgáltatásokkal foglalkozunk. Visszavárjuk!