Az Allen-Bradley 1769-L35E a vezérlő előlapjára épített EtherNet/IP-porttal rendelkezik, így ez lesz az alapértelmezett csatlakozási pont minden HMI, hajtás, átjáró és adatgyűjtő számára egy alpanelen. Ez a kényelem azonban egy fontos elkülönítést rejt: a beépített port nem ugyanaz az erőforrás, mint a vezérlő teljes rendszerére vonatkozó CIP-kapcsolati készlet. Azok a telepítések, amelyek „évekig hibátlanul működtek”, gyakran akkor mondják fel a szolgálatot, amikor az ötödik PanelView vagy egy CIP Motion-tengely észrevétlenül kimeríti a port keretét, miközben a vezérlő teljes kapcsolatszáma továbbra is megfelelőnek tűnik.

A beágyazott port CIP-korlátai, nem pedig a váz marketingadatai döntik el, hogy egy újabb adapter problémamentesen üzembe helyezhető-e.

Két könnyen összekeverhető kapcsolati készlet

A CompactLogix kommunikációs specifikációi (a 1769-TD007 kiadványsorozat) szerint az L32E és az L35E rendszerszinten nagyjából 100 CIP-kapcsolatot támogat. A beépített EtherNet/IP-port azonban jellemzően körülbelül 32 CIP-kapcsolatra korlátozott. A fennmaradó kapacitás csak akkor hasznosítható, ha Ethernet-adaptert, például 1769-AENTR-t adunk a helyi vagy bővített buszhoz, és a forgalom egy részét levesszük az előlap portjáról. Ezen a platformon az a leggyakoribb tervezési hiba, ha a „100 kapcsolatot” úgy értelmezzük, hogy harmincnál több eszközt szabad az RJ45-portra csatlakoztatni.

A beépített port a webkiszolgálóval, a BOOTP/DHCP-klienssel és a kéretlen útválasztással is megosztja a sávszélességet. A nem CIP-alapú forgalom, például a nyers Modbus TCP vagy a böngészőkapcsolatok, nem fogyaszt CIP-kapcsolatot, de TCP-aljzatokat és PPS-kapacitást igen. Egy diagnosztikai oldalon hagyott mérnöki laptop egy nagy terhelésű HMI-lekérdezési időablakában nem ingyenes.

Mi fogyaszt valójában CIP-kapcsolatot?

A kapcsolatok számát az eszközkonfiguráció határozza meg, nem a táblázatban szereplő optimista becslés. A terepen jellemző kapcsolatigények:

• PanelView Plus / FactoryTalk View ME-állomás: általában 1–4 kapcsolat a témaköröktől és a riasztási feliratkozásoktól függően
• PowerFlex- vagy Kinetix-hajtások: 1–2 (implicit I/O, valamint opcionális explicit MSG; a CIP Motion további fogyasztót ad hozzá)
• Anybus- vagy Ethernet–RIO-átjárók: jellemzően szkennercélpontonként 1
• POINT I/O: modulonként 1, kivéve, ha a rackoptimalizálás egyetlen kapcsolattá vonja össze a vázat
• Létrehozott/fogyasztott tagpárok: páronként irányonként egy kapcsolat
• Aktív MSG-utasítások CIP-útvonalakkal: üzenetenként egy nyitott kapcsolat; a gyorsítótárazás számít

Négy vagy több modul közös adapteren való használata esetén erősen ajánlott a rackoptimalizált I/O. Ha minden 1734-es modult külön kapcsolatként hagyunk meg, könnyen elhasználhatjuk a 32-es keretet még az első VFD üzembe helyezése előtt.

Az IGMP-snoopingot használó menedzselhető kapcsolás megakadályozza, hogy a multicast I/O-forgalom elárassza ugyanazt a portot, amelyet védeni próbál.

Gyakorlati alpanelpélda

Vegyünk egy olyan panelt, amely már három UniOP HMI-t (~2 kapcsolat egyenként), egy Anybus kommunikátort, egy Quest Ethernet–RIO-átjárót, egy FactoryTalk View ME-klienst és egy Pilz PNOZmulti-csomópontot kezel. Már ez a leltár is megközelítheti a tizenegy CIP-kapcsolatot. Egy Kinetix 300 (implicit és explicit kapcsolatokat használ) és egy OPC-téma hozzáadása még hagyhat számszerű tartalékot a 32-es korlát alatt – egy 5–10 ms-os mozgási RPI azonban jóval azelőtt veszélyes PPS-tartományba emelheti a csomagszámot, hogy a kapcsolatszámláló pirosra váltana. A kapacitástervezésnek a CIP-kapcsolatok számát és a csomagsebességet egyaránt értékelnie kell.

Tervezési ellenőrzőlista
1. Vegyen nyilvántartásba minden Class 1, előállított/felhasznált, MSG- és HMI-témát az előlap portján
2. Állítsa be az RPI- és lekérdezési sebességeket; becsülje meg a PPS-t = f(RPI, kapcsolatok)
3. Modellezze a rendszert a Rockwell EtherNet/IP Capacity Tool eszközben (a nem Rockwell-eszközöket kézzel adja meg)
4. Új hardver hozzáadása előtt ellenőrizze az aktuális számokat a http://<controller-ip>/ címen
5. Ha a 32 CIP-kapcsolat vagy az 5k PPS közelében jár, helyezze át az I/O-t vagy a HMI-ket egy 1769-AENTR / EN2T osztályú útvonalra

A port túlterheltségének tünetei

A túlterhelés ritkán jelentkezik egyetlen egyértelmű hibaként. A tipikus folyamat:

1. Nő a Class 1 RPI-ingadozása; az I/O-frissítések késve érkeznek
2. A HMI-értékek rövid időre megfagynak; a riasztások időbélyegei elavultnak tűnnek
3. A 0x0304 / 0x0312 / 0x0100 CIP-állapotbejegyzések megjelennek az Ethernet-diagnosztikai oldalon
4. Az MSG-utasítások erőforrás-elérhetetlenségi vagy időtúllépési kódokat adnak vissza
5. A beágyazott webszerver nem válaszol, amikor elfogynak a TCP-foglalatok
6. Szélsőséges esetben az összes CIP-kapcsolat megszakad az áramellátás ki- és bekapcsolásáig vagy az újracsatlakozásig

CIP-kapcsolati keret új csomópontok hozzáadása előtt

Mielőtt újabb eszközt adna hozzá, nyissa meg a vezérlő webes diagnosztikáját, és rögzítse az aktuális kapcsolatszámot a táblázatában. Engedélyezze az IGMP-snoopingot azokon a menedzselhető kapcsolókon, amelyek multicast I/O-forgalmat továbbítanak. Ne próbáljon „javítani” egy túlterhelt cellát újabb nem menedzselhető kapcsoló beillesztésével – ez csak megsokszorozza a broadcast-tartományokat. Ha az alkalmazás tartósan több kapcsolatot igényel, mint amennyit az előlap képes kezelni, helyezze át a forgalmat egy adaptermodulra vagy újabb CompactLogix-platformra, ahelyett hogy addig ritkítaná az RPI-ket, amíg a mozgás minősége össze nem omlik.

A kapcsolatkezelés számításainak ugyanúgy szerepelniük kell a platformkiválasztási felülvizsgálatokban, mint a ciklusidőnek. Szerezze be az adaptereket és vezérlőket fegyelmezett PLC- és PAC-rendszer-tartalékterv alapján, hogy a következő bővítés ne egy fiókban heverő, felesleges, fogyasztói Ethernet-kapcsolóval kezdődjön.