OPC-szerver csatlakoztatva, de a tagek lefagytak: Kepware- és Allen-Bradley EtherNet/IP-megoldások terepi hibajavításhoz

Miért rejt egy zöld kapcsolat megszakadt adatútvonalat?

Az OPC-szerverek hidat képeznek a vezérlők és a felsőbb szintek között. Adatokat szolgáltatnak a SCADA-rendszereknek, a HMI-knek és az adatgyűjtőknek. A jellegzetes tünet az éjszakai műszakban jelentkezik. A szerver állapota szerint a kapcsolat létrejött. Ennek ellenére több tag az utolsó értékén marad. Először értse meg a hibatípust. Az átviteli kapcsolat él. Az adatútvonal azonban nem működik. Ezért ne siessen újraindítani a szervert. Az újraindítás elfedi a kiváltó okot, amely néhány napon belül ismét jelentkezik. Kepware- és Allen-Bradley-üzemeimben nyolc ok magyarázza az esetek szinte mindegyikét. Vizsgálja meg őket sorrendben.

Hogyan ellenőrizhető a PLC-címek hozzárendelése online módosítás után?

A címek elcsúszása az első számú ok. A mérnökök az üzembe helyezés vagy optimalizálás során módosítják a ControlLogix-logikát. Tagokat helyeznek át, tömböket méreteznek át és adattípusokat módosítanak. A Kepware tagadatbázisa lemarad. A meghajtó továbbra is egy olyan regisztert kérdez le, amelybe a logika már nem ír. A tag jó minőségi állapot mellett is befagy, és éppen ez a megtévesztő benne. A minőségi jelző azonban gyakran jó marad, mivel a regiszter továbbra is létezik. Ellenőrizze közvetlenül a hozzárendelést.

• 1. lépés — Exportálja a ControlLogix tagadatbázisát az RSLogix 5000-ből, majd hasonlítsa össze a Kepware-címkarakterláncokkal.
• 2. lépés — Online kényszerített olvasással olvassa ki a vezérlőben a pontos taget. Hasonlítsa össze az OPC Quick Clientben látható időbélyeggel.
• 3. lépés — Importálja újra a tageket a vezérlő szimbolikus fájljából. Soha ne gépelje be kézzel újra a címeket.

Hogyan hangolhatók az analóg szabályozási körök lekérdezési gyakoriságai és holtsávjai?

Az agresszív lekérdezés túlterheli a CIP-útvonalat. Minden Kepware-eszköz CIP-kapcsolatot nyit a ControlLogix-processzorhoz. Egy Logix-vezérlő korlátozott számú CIP-kapcsolatot támogat, a szabványos processzorok esetében gyakran körülbelül 40-et. Több kliens és a gyors lekérdezési ciklus együtt kimeríti ezt a keretet. A processzor késlelteti vagy eldobja a kéréseket. Emellett a holtsávszűrés elrejti a valós változásokat. Egy lassú hőmérséklet-szabályozási körben alkalmazott 2 százalékos holtsáv elnyomja a valódi kis változásokat. Az érték a PLC-ben változik, de a kliens soha nem értesül róla.

• 1. lépés — Állítsa a Kepware frissítési gyakoriságát 1000 ms-ra az analóg folyamat-tagek esetében. A 100 ms-os értéket csak gyors reteszelésekhez használja.
• 2. lépés — Kritikus analóg tageknél állítsa a holtsávot a mérési tartomány 0,5 százaléka alá. Összegzőknél teljesen tiltsa le.
• 3. lépés — Ellenőrizze a vezérlő CIP-kapcsolatainak számát. Ossza fel a nagy eszközcsoportokat, ha a szám megközelíti a korlátot.

Mit kell ellenőrizni az eszközcsoportokkal, a gyorsítótárral és az OPC UA-előfizetésekkel kapcsolatban?

A Kepware az eszközöket csatornákba és csoportokba szervezi. A hibás hátlaphely, hibás processzorhely vagy hibás IP-cím csak az adott csoportot állítja le. A többi csoport tagjei tovább frissülnek. Ezért a részlegesen befagyott képernyő gyakran egy hibás eszközobjektumra utal. A gyorsítótár újabb réteget jelent. A szerver a saját ciklusában olvassa a PLC-t, és a klienseket a gyorsítótárból szolgálja ki. Ha a meghajtó késleltetései megakasztják a gyorsítótár frissítését, a kliensek régi értékeket kapnak, miközben a kapcsolat olvasása megfelelőnek tűnik. OPC UA-kliensek esetében erősítse meg a végpontot. Használja az opc.tcp protokollt a 4840-es porton, megbízható alkalmazástanúsítvánnyal. Ellenőrizze, hogy az előfizetés közzétételi időköze legalább a mintavételi időközzel megegyezzen.

• 1. lépés — Nyissa meg a Kepware eseménynaplóját. Szűrjön az adott eszközre, és keressen CIP-hibákat vagy időtúllépési kódokat.
• 2. lépés — Ellenőrizze az eszköz tulajdonságaiban megadott helycímzést a tényleges hátlap-konfiguráció alapján.
• 3. lépés — Figyelje a diagnosztikai számlálókat. A növekvő kérési hibák mellett jelentkező elavult olvasások a gyorsítótár kiürülésére utalnak.

Hogyan befolyásolja a PLC-logika és a csomagtöredezés a tagek frissítését?

Egyes változók csak programfeltételek teljesülésekor frissülnek. A kötegelt folyamatok, reteszelések és állapotgépek sok írási műveletet feltételhez kötnek. Ha a feltétel soha nem teljesül, a regiszter az utolsó értékét tartja. Az OPC-szerver ezt hűen jelenti. Ez kommunikációs hibának tűnhet, de nem az. Ezért a hálózat módosítása előtt olvassa el a logikát. Végül ellenőrizze a töredezést. Az EtherNet/IP-n keresztüli nagy blokkolvasások torlódó hálózatokon meghaladhatják a keretméret-korlátokat. A későn érkező vagy sorrenden kívüli töredékek megszakítják az újraösszeállítási időablakot. Ossza kisebb olvasásokra a túlméretezett tagblokkokat. A blokkolvasásokat lehetőség szerint tartsa 480 bájt alatt.

• 1. lépés — Kövesse végig a befagyott taget író programsort. Erősítse meg, hogy az engedélyezési feltétel valóban teljesül.
• 2. lépés — Bontsa a nagy Kepware-blokkolvasásokat egyenként 100 tag alatti csoportokra.
• 3. lépés — A hiba időszakában figyelje a switchport CRC-hibáit és újraküldéseit.

Összegzés és gyakorlati tanácsok

A zöld OPC-kapcsolat mellett befagyott tagek konfigurációs vagy terhelési problémára utalnak, nem kábelhibára. Először minden vezérlőmódosítás után egyeztesse a tagadatbázist. Másodszor tartsa reális szinten a lekérdezési gyakoriságokat, és szűkre állítsa a holtsávokat. Emellett figyelje a CIP-kapcsolati kereteket és az eszközcsoportok állapotát, mielőtt a hálózatot hibáztatná. Ezért vezessen be heti rutint: exportálja a Kepware eseménynaplóját, és minden programverzióhoz archiválja a taghozzárendeléseket. Végül tanítsa meg a kezdő munkatársaknak, hogy minden beavatkozás előtt olvassák le a minőségi kódokat és az időbélyegeket. A fegyelmezett ellenőrzési sorrend a legtöbb befagyott-tag hibát egy órán belül, újraindítás nélkül elhárítja, és megbízhatóan tartja az adatgyűjtőt.

Szerző: Zhou Weiguo ipari automatizálási mérnök, több mint 10 éves PLC-, DCS- és irányítástechnikai tapasztalattal.