Allen-Bradley 1769-L35E разполага с EtherNet/IP порт на лицевата страна на контролера, което го превръща в стандартната крайна точка за всеки HMI, задвижване, шлюз и събирател на данни в подтаблото. Това удобство прикрива твърдо разделение: вграденият порт не е същият ресурс като общия CIP пул на контролера. Инсталации, които „са работили безпроблемно години наред“, често отказват, когато пети PanelView или ос с CIP Motion незабелязано изчерпи бюджета на порта, докато общият брой на контролера все още изглежда нормален.

Таваните за CIP връзки на вградения порт, а не маркетинговите числа за шасито, определят дали следващият адаптер ще бъде успешно въведен в експлоатация.

Два пула от връзки, които лесно се объркват

Според спецификациите за комуникация на CompactLogix (серия публикации 1769-TD007) L32E и L35E поддържат приблизително 100 CIP връзки в рамките на системата. Вграденият EtherNet/IP порт обаче обикновено е ограничен до около 32 CIP връзки. Останалите са полезни само ако добавите Ethernet адаптер, например 1769-AENTR, към локалната или разширената шина и прехвърлите част от трафика извън лицевия порт. Приемането на „100 връзки“ като разрешение да свържете над тридесет устройства към RJ45 е най-честата грешка при планиране на тази платформа.

Вграденият порт споделя честотната лента и с уеб сървъра, BOOTP/DHCP клиента и непоисканото маршрутизиране. Некомпактен трафик като необработен Modbus TCP или браузърни сесии не консумира CIP връзка, но все пак изразходва TCP сокети и PPS. Инженерен лаптоп, оставен на диагностичната страница по време на интензивен прозорец за HMI запитвания, не е безплатен.

Какво всъщност консумира CIP връзка

Броят на връзките се определя от конфигурацията на устройствата, а не от оптимизма в електронната таблица. Типичните в практиката конфигурации включват:

• Станция PanelView Plus / FactoryTalk View ME: обикновено 1–4 връзки в зависимост от темите и абонаментите за аларми
• Задвижвания PowerFlex или Kinetix: 1–2 (неявен I/O плюс незадължителен явен MSG; CIP Motion добавя още един консуматор)
• Шлюзове Anybus или Ethernet-към-RIO: обикновено 1 за всяка цел на скенера
• POINT I/O: 1 за модул, освен ако оптимизацията за шкафове не обедини шаси в една връзка
• Двойки произведени/консумирани тагове: по една връзка за всяка посока на двойката
• Активни MSG инструкции с CIP пътища: по една за всяко отворено съобщение; кеширането е важно

Категорията I/O, оптимизирана за шкафове, е силно препоръчителна, когато четири или повече модула споделят един адаптер. Оставянето на всеки 1734 модул като отделна връзка е лесен начин да изчерпите бюджета от 32 връзки, преди да бъде пуснат в експлоатация и първият ЧП.

Управляемото превключване с IGMP snooping предотвратява наводняването на същия порт с multicast I/O трафик, който се опитвате да защитите.

Пример с изчисления за подпанел

Да разгледаме панел, който вече обслужва три HMI системи UniOP (~2 всяка), комуникатор Anybus, мост Quest Ethernet-to-RIO, клиент FactoryTalk View ME и възел Pilz PNOZmulti. Само този опис може да достигне близо до единадесет CIP връзки. Добавянето на Kinetix 300 (implicit плюс explicit) и OPC topic все още може да остави числен резерв под 32 — но RPI за движение от 5–10 ms може да повиши PPS до опасната зона много преди броячът на връзките да стане червен. Планирането на капацитета трябва да отчита както броя CIP връзки, така и честотата на пакетите.

Контролен списък за планиране
1. Направете опис на всеки Class 1, produced/consumed, MSG и HMI topic на порта на предния панел
2. Задайте RPI / честотите на запитване; изчислете PPS = f(RPI, connections)
3. Направете модел в Rockwell EtherNet/IP Capacity Tool (въведете ръчно устройствата, които не са на Rockwell)
4. Потвърдете текущия брой на http://<controller-ip>/, преди да добавяте хардуер
5. Ако сте близо до 32 CIP връзки или 5k PPS, преместете I/O или HMI системите към път от клас 1769-AENTR / EN2T

Симптоми при претоварен порт

Претоварването рядко се проявява като една ясно изразена повреда. Типичната последователност е:

1. Нараства трептенето на RPI при Class 1; актуализациите на I/O пристигат със закъснение
2. Стойностите на HMI замръзват за кратко; времевите маркери на алармите изглеждат остарели
3. На диагностичната страница за Ethernet се появяват записи за CIP статус 0x0304 / 0x0312 / 0x0100
4. Инструкциите MSG връщат кодове за недостъпен ресурс или изтичане на времето
5. Вграденият уеб сървър спира да отговаря, когато TCP сокетите се изчерпят
6. В крайни случаи всички CIP връзки прекъсват, докато не се изключи и включи захранването или не се осъществи повторно свързване

Проверете бюджета за CIP връзки, преди да добавяте възли

Преди да добавите още едно устройство, отворете уеб диагностиката на контролера и запишете текущия брой връзки спрямо данните в електронната си таблица. Активирайте IGMP snooping на управляваните суичове, които пренасят multicast I/O трафик. Не „отстранявайте“ претоварването на клетката, като поставите още един неуправляем суич — това само умножава broadcast домейните. Когато приложението постоянно се нуждае от повече връзки, отколкото може да поддържа предният панел, прехвърлете трафика към адаптерен модул или по-нова платформа CompactLogix, вместо да увеличавате RPI, докато качеството на движението се влоши.

Изчисляването на връзките трябва да бъде част от прегледите за избор на платформа по същия начин, както и времето за цикъл. Поддържайте резервни адаптери и контролери чрез стриктно планиране на резервните части за PLC и PAC системи, така че следващото разширение да не започва с резервен потребителски Ethernet суич, забравен в някое чекмедже.