CompactLogix L35E EtherNet/IP kapacitástervezés
Tervezze meg a CompactLogix L35E EtherNet/IP kapacitását a konfigurált CIP-forgalom, az élő diagnosztikai adatok, a frissítési gyakoriságok és az életciklus kockázatai alapján – ne hagyatkozzon tév...
A CompactLogix 1769-L35E továbbra is gyakori az olyan gépekben, amelyek már túlélték eredeti hálózati tervüket. A bővítési problémák általában akkor kezdődnek, amikor az eszközlistát a kapcsolatok számának tekintik. Az EtherNet/IP kapacitása az egyes eszközök által létrehozott forgalom típusától, az adatcsere gyakoriságától és az alkalmazás által már használt vezérlő-erőforrásoktól függ. A biztonságos felülvizsgálat ezért az éles projekttel és a diagnosztikával kezdődik, nem egy általános, portonkénti eszközszám-szabállyal.
A kapcsolatok tervezésénél a konfigurált forgalmat, a frissítési gyakoriságot és az életciklus-kockázatot kell figyelembe venni, nem az Ethernet-csatlakozók számát.
Kezdje a vezérlő dokumentált korlátjával
A Rockwell Automation 1769 CompactLogix Controllers User Manual dokumentációja szerint az L35E 100 CIP-kapcsolatot támogat. Ez erőforráskorlát, nem pedig engedély 100 eszköz csatlakoztatására. Egyetlen eszköz egynél több kapcsolatot is igényelhet, miközben egyes kommunikációk megoszthatnak egy optimalizált kapcsolatot. A firmware-verzió, a modul konfigurációja, a létrehozott és felhasznált tagek, a gyorsítótárazott üzenetek, valamint a HMI- és felügyeleti kliensek mind befolyásolják a végső összesítést.
A vezérlő emellett megszüntetett termék. A Rockwell a 1769-L35E típust 2020. december 20. óta megszüntetettként tartja nyilván. Ez nem teszi használhatatlanná a működő rendszert, de megváltoztatja a mérnöki döntést: a kapacitásproblémát a pótalkatrészek elérhetőségével, a firmware-támogatással, a kiberbiztonsági kitettséggel és egy nem tervezett meghibásodás költségével együtt kell értékelni.
Készítsen kapcsolati leltárt a projektből
Nyissa meg az éles vezérlőnek megfelelő offline projektet, és soroljon fel minden konfigurált I/O-adaptert, hajtást, létrehozott vagy felhasznált taget, üzenetútvonalat, HMI-adatkiszolgálót, történeti adatgyűjtőt, átjárót és programozási kapcsolatot. Rögzítse, hogy az egyes adatcserék ciklikus I/O-ként, létrehozott adatként, explicit üzenetként vagy kliens általi lekérdezésként működnek-e. Ne kizárólag a gyártó neve alapján rendeljen hozzájuk rögzített kapcsolati igényt. A tényleges konfiguráció az irányadó.
Elosztott I/O esetén vizsgálja meg, hogy a kiválasztott kommunikációs formátum közvetlen modulkapcsolatokat vagy állványoptimalizált kapcsolatot hoz-e létre. MSG-utasításoknál azonosítsa a gyorsítótárazott üzeneteket, és ellenőrizze, hogy egyszerre több üzenet is aktív lehet-e. Felügyeleti rendszereknél számolja meg a független kommunikációs útvonalakat, és tekintse át a lekérdezési stratégiájukat. A táblázatban minden feltételezett kapcsolatot hozzá kell rendelni egy projektobjektumhoz vagy tesztelt klienskonfigurációhoz.
Válassza külön a kapcsolatok számát és a csomagterhelést
A vezérlő a kapcsolati korlát alatt maradva is gyenge hálózati teljesítményt nyújthat. A kért csomagintervallumok, az üzenetek gyakorisága, a csomagméret, a multicast viselkedése, a switch konfigurációja és több kliens egyidejű adatkitörései mind befolyásolják a csomagterhelést. A nagyon gyors RPI-ket a mechanikai folyamat és a szükséges vezérlési reakció alapján kell indokolni; attól, hogy minden eszközt gyorsabbra állítunk, a gép nem lesz jobb.
Állítson fel alapállapotot normál termelés közben. Rögzítse a kapcsolathasználatot, az Ethernet-hibaszámlálókat, a kimaradt vagy időtúllépett üzeneteket, az I/O-állapotot, a HMI reakcióidejét és a vezérlő szkennelési viselkedését. Ismételje meg a mérést indítás, receptletöltés, riasztási üzenetáradat, karbantartási hozzáférés és más reális csúcsterhelések alatt. Az átlagértékek elrejthetik azt a rövid időszakot, amely egy időszakos hibát okoz.
A menedzselt switching, a dokumentált topológia és a megismételhető mérések diagnosztizálhatóvá teszik az időszakos kapacitáshibákat.
Ne használjon 1769-AENTR-t második L35E-portként
A 1769-AENTR EtherNet/IP-adapter, amely egy hálózaton keresztül vezérelt, távoli Compact I/O-állványhoz használható. Nem olyan bővített Ethernet-interfész, amely növeli az L35E vezérlő kommunikációs erőforrásait, és nem csatlakoztatható második vezérlőportként sem a HMI- vagy üzenetforgalom beágyazott interfészről való áthelyezésére. Az erre a feltételezésre épülő tervezés olyan topológiát eredményez, amely nem képes az állítólagos funkciót ellátni.
Ha a távoli I/O megfelelő megoldás, az adapter egy másik helyszínen egyesítheti a fizikai I/O-t, de az ebből származó I/O-kapcsolat továbbra is a vezérlőnél végződik. Ha az alkalmazás nagyobb kommunikációs kapacitást, korszerű biztonsági funkciókat vagy hosszabb támogatási életciklust igényel, a megoldás egy újabb vezérlőcsaládra való migráció lehet egy újabb adapter helyett.
Csökkentse az elkerülhető terhelést a probléma elfedése nélkül
Az optimalizálásnak meg kell őriznie a folyamatkövetelményeket. Távolítsa el az elhagyott útvonalakat és a nem használt klienseket. Egyesítse az I/O-kapcsolatokat, ha ezt a platform és a modultípusok támogatják. Csak azokat az MSG-kapcsolatokat gyorsítótárazza, amelyeknek gyors, ismételt végrehajtásra van szükségük, a nem kritikus üzeneteket pedig ütemezze úgy, hogy ne egyszerre nyíljanak meg. Az RPI- vagy lekérdezési intervallumot csak annak megerősítése után növelje, hogy az észlelési idő, a reteszelések, a riasztások és a vezérlés minősége továbbra is elfogadható marad.
Használjon menedzselt ipari switcheket, és dokumentálja a VLAN-, multicast- és IGMP-beállításokat, ahol alkalmazhatók. A switch korlátozhatja a szükségtelen elárasztást és javíthatja a megfigyelhetőséget, de nem hoz létre új vezérlőoldali kapcsolati erőforrásokat. Hasonlóképpen, egy nem menedzselt switch hozzáadása a portok számát, nem pedig a vezérlő kapacitását módosítja.
Diagnosztizálja módszeresen a feltételezett kapacitáshibát
Először erősítse meg az éles projektet, a vezérlő katalógusszámát, a firmware-verziót és a hálózati topológiát. Ezután hasonlítsa össze a konfigurált kapcsolatokat az élő diagnosztikai adatokkal. Keresse azokat az I/O-modulokat, amelyek váltakozva futó és hibás állapotba kerülnek, azokat az MSG-utasításokat, amelyek csúcsterhelés alatt időtúllépnek, illetve azokat a HMI-értékeket, amelyek elavulnak, miközben a vezérlőlogika továbbra is végrehajtódik.
Egyszerre csak egy változót módosítson. Egy ellenőrzött karbantartási időablakban válasszon le egy jóváhagyott, nem alapvető klienst, függesszen fel egy nem kritikus lekérdezési szolgáltatást, vagy ideiglenesen ütemezze a küldött üzeneteket. Ha a tünet megváltozik, mérje meg a terhelést a módosítás előtt és után, ahelyett hogy egyetlen nyugodt óra alapján sikert hirdetne. Soha ne növelje az időtúllépéseket, és ne tiltsa le a kommunikációs riasztásokat pusztán a torlódás elfedésére.
Üzemelje be a bővítéseket hibatesztekkel
Egy eszköz hozzáadása előtt határozza meg a kapcsolat típusát, a frissítési követelményt, a felelőst és a hibakezelést. Tesztelje a normál termelést és a legrosszabb ésszerű egyidejű terhelést. Szakítsa meg az új eszköz kapcsolatát, állítsa helyre, kapcsolja ki-be a hálózati tápellátását, és ellenőrizze, hogy a vezérlő, a HMI és a riasztások megkülönböztetik-e a hibás vagy elavult adatokat az érvényes folyamatállapottól. Ellenőrizze azt is, hogy a helyreállás nem indítja-e újra váratlanul a berendezést.
Az ellenőrzési listát, a diagnosztikai pillanatképeket, a switch konfigurációját és az átvételi eredményeket őrizze meg a vezérléstechnikai biztonsági mentéssel együtt. Az aktuális hardverlehetőségekért tekintse meg a PLC- és PAC-rendszereket; menedzselt switchekhez és hálózati komponensekhez használja a kommunikációs és hálózati termékek gyűjteményét. A szerkesztőség álláspontja egyszerű: az L35E bővítése csak akkor védhető, ha a mért csúcsterhelés, a hibaviselkedés és az életciklus-terv egyaránt dokumentálva van.