После горячей замены CPU на линии розлива мастер ProfiNet показывает все удалённые модули красным: Not Available, Deactivated, иногда «Module mismatch». Старый контроллер сняли с питанием, новый поставили на ту же DIN-рейку, проект загрузили из архива - логика вроде на месте, а полевые устройства «не видны». Наладчик открывает TIA или CODESYS Device Repository и видит пустую диагностику вместо привычной топологии.
ProfiNet не прощает расхождения между тем, что записано в проекте, и тем, как устройство представилось в сети. Device Name, IP, GSDML, порядок слотов - всё должно совпасть. Замена CPU часто меняет MAC, сбрасывает назначение имён через DCP или оставляет в сети «призрак» старого имени на другом железе. Статья разбирает восстановление связи после замены CPU: GSD, Compare Name, пересканирование, топологию. Урок по отличию ProfiNet от Modbus TCP в общих чертах - только там, где нужно для диагностики; полное сравнение протоколов - в отдельной статье.
Короткий ответ
После замены CPU ProfiNet-устройства уходят в Not Available, когда в проекте остались старые Device Name, IP или версия GSDML, а в сети контроллер и модули не совпадают с конфигурацией. Проверьте: тот же GSDML и порядок модулей в конфигурации; Device Name каждого устройства через DCP или встроенную диагностику (Compare Name); IP и маску в той же подсети, что до замены; выполните пересканирование шины / Update Topology / Assign Device Name по процедуре среды. Новый CPU - новый MAC: если имя не назначено или конфликтует с другим узлом, мастер не поднимет циклический обмен. Modbus TCP после замены контроллера часто «оживает» по одному IP; ProfiNet требует явного согласования имени и GSD.
Чем ProfiNet отличается от Modbus TCP при замене железа
Modbus TCP клиент обычно знает IP и порт. Поменяли ПЛК, выставили тот же IP в настройках Ethernet - карта регистров снова работает, если проект загружен. ProfiNet мастер опирается на Device Name (DNS-подобное имя в сети PN), GSD-описание модулей, Expected Configuration и реальную конфигурацию из поля. Имя привязано к устройству через DCP; при замене CPU имя может остаться у старого MAC в кэше коммутатора или не назначиться новому.
В сравнении ProfiNet, EtherNet/IP и Modbus TCP это ключевое отличие для пуска: не только «достучаться до IP», но «узнать правильное устройство с правильными слотами». Ошибка GSD - лишний или пропущенный модуль в rack - даёт Not Available даже при живом ping.
GSDML: версия, слоты, подмодули
GSD (General Station Description) в формате GSDML описывает, какие модули может нести устройство, их ширину в слотах, входы/выходы, параметры. В проекте вы собираете виртуальный rack: CPU, power supply, DI, DQ, AI. В поле физически стоят те же модули - или нет.
Типовые промахи после замены CPU:
Загрузили проект со старым GSDML, а на складе модуль новой ревизии с другим Order Number. В конфигурации слот 3 - 8 DI, в железе 16 DI другого артикула. Заменили только CPU, но заодно «подсунули» другой компактный модуль в слот - проект не обновили. Импортировали GSD от другого семейства с похожим именем файла.
В среде разработки откройте Properties устройства, сравните Order Number и версию GSD с шильдиком на модуле. Функция Compare / Plug compare в некоторых IDE показывает расхождение по слотам до выхода в поле.
Если после замены CPU вы обновили прошивку IO-модулей, иногда требуется новая строка GSDML - старая помечает модуль как несовместимый.
Device Name: почему «тот же IP» не спасает
В ProfiNet Device Name - обязательный идентификатор для назначения IP (в классическом DCP) и для привязки в проекте. Имя вида plc-line1-cpu задаётся при первом пуске. В проекте мастера указано это имя. Новый CPU из коробки может иметь заводское имя или пустое; старый CPU лежит на столе, но если его не отключили от сети, в сегменте два устройства борются за одно имя.
Процедура после замены:
Отключить старый CPU от ProfiNet (питание и кабель), иначе конфликт имён. На новом CPU через DCP (утилита производителя, PRONETA, встроенный web) назначить то же Device Name, что в проекте. Назначить тот же IP или использовать DHCP с резервацией по имени - как было на объекте. В проекте: Online → Assign device name / Connect to network → выбрать устройство по MAC нового CPU и записать имя из конфигурации.
Compare Name: если в диагностике «expected name X, actual name Y» - мастер намеренно не стартует IO. Это не баг, а защита от подмены устройства.
Замена CPU: что переносится, что нет
Проект логики на новый CPU загружается. Аппаратная идентичность в сети PN - нет. MAC новый. DCP-таблица коммутатора с ProfiNet awareness может кэшировать старую привязку port ↔︎ device. IP мог быть привязан к старому MAC в DHCP-сервере IT-отдела.
Чек-лист на объекте:
Старый CPU обесточен и отключён от PN. Новый CPU: прошивка не ниже требуемой GSD. Device Name и IP совпадают с as-built документацией. Кабель PN в тот же порт коммутатора или известный порт с правильной VLAN. После назначения имени - Reset to factory на IO только если документация требует; иначе модули сохраняют конфигурацию.
В CODESYS или MasterSCADA 4D при ProfiNet IO конфигурация живёт в дереве устройств; после замены CPU переподключите Online и выполните «Scan network» / «Connect» с правильным интерфейсом ПК.
Пересканирование и Update Topology
После исправления имени и IP мастеру нужно пересканировать устройства и согласовать топологию. В зависимости от среды: Update Topology, Scan for devices, Adapt topology. Без этого модули остаются в серой зоне «configured but not reachable».
Порядок действий обычно такой: физическая связь зелёная на коммутаторе; ping до IP CPU (если IP статический и известен); DCP - имя совпало; в проекте Online, Assign name если нужно; Update Topology; Download hardware configuration если изменились только слоты в проекте (осторожно на работающей линии).
На линии с частичным резервированием RT или S2 имя и роль (primary/backup) задаются отдельно - замена CPU может затронуть redundancy; это отдельный регламент, но симптом тот же - Not Available на всех IO.
Диагностика в IDE: на что смотреть
В Online diagnostics устройства ProfiNet:
Not Available - нет циклического обмена, причина в списке ниже. Wrong module - GSD не совпадает с фактом. No resource - не хватает памяти или лицензии PN на CPU (редко после замены на меньшую модель). Cable diagnostic - обрыв порта (не путать с GSD).
PRONETA или аналог показывает все PN-устройства в сегменте с MAC, IP, Name - сравните с проектом до клика Download. Полезно снять скрин «до» и «после» замены для паспорта объекта.
Связь с отладкой ПЛК: после аппаратной замены сначала железо и сеть PN, потом логика и force переменных.
Топология: линия, кольцо, коммутатор
ProfiNet на коммутаторе требует правильной настройки портов: иногда запрет STP на порту PN, иногда MRP для кольца. Замена CPU не меняет топологию, но если кабель перепутали при монтаже, один порт уходит в blocking - часть устройств Not Available выборочно.
Проверьте: все PN-устройства в одной broadcast-домене L2; нет ли случайного роутинга между VLAN без PN support; коммутатор не режет multicast/broadcast, нужный для DCP (в гостевых VLAN режут).
Типовая ошибка: проект от другой ревизии шкафа
Заменили CPU после аварии, а проект взят с резервной копии месячной давности - в нём ещё старый состав модулей. Имя и IP совпали, GSD в проекте не совпадает с железом на DIN-рейке. Решение - актуализировать конфигурацию IO по факту, сверить с электрической схемой и шильдиками, затем download hardware config с остановом технологического процесса по наряду.
Регламент замены CPU: что записать в паспорт
До снятия старого CPU сохраните скрин из PRONETA или диагностики: Device Name, IP, MAC, список IO с Order Number. После установки нового - те же поля до первого Download. В журнале объекта: дата, серийный номер нового CPU, кто назначил имя, версия проекта. Это сокращает ночные простои при повторной замене.
Если проект хранится в git, отдельный tag релиза «до замены CPU_3» и коммит после успешного пересканирования - интегратору проще откатить конфигурацию IO, не трогая логику ST. Отладка ПЛК напоминает: после hardware download проверьте force и retain, не только PN.
Отличие от Modbus TCP при приёмке после ремонта
На том же объекте Modbus-устройства после замены шлюза часто проверяют одним ping и опросом регистра. ProfiNet требует отдельного чек-листа: имя, GSD, topology, только потом циклический IO. Смешанные объекты (PN для IO, Modbus для счётчиков) путают команду ремонта: «пинг есть» по Modbus-шлюзу не означает, что PN-мастер поднялся. В сравнении протоколов это разграничение полезно при сдаче после замены CPU.
Ошибка в диагностике, причина и действие
| Сообщение / состояние | Вероятная причина | Действие |
|---|---|---|
| Not Available, все IO | CPU не в RUN; нет PN имени; неверный IP | DCP: имя и IP; режим RUN; кабель PN |
| Compare Name mismatch | Имя в сети ≠ проекту | Assign device name по MAC нового CPU |
| Wrong module slot 3 | Другой модуль или GSD | Сверить шильдик; обновить GSDML; переконфигурировать слот |
| Deactivated | Устройство выключено в конфиге или FT | Activate в конфигурации; проверить F-опции |
| Duplicate device name | Старый CPU в сети | Обесточить старый CPU; очистить кэш коммутатора |
| Ping OK, PN Not Available | Другой VLAN; не PN устройство | L2 сегмент; не путать с Modbus TCP на том же IP |
| После Download всё красное | Download без assign name | Сначала имя, потом topology, потом логика |
| Только один удалённый IO серый | Обрыв линии после CPU | Кабель к IO; порт коммутатора; MRP status |
| GSD import failed | Версия файла / IDE | Скачать GSD с сайта вендора IO; версия PNIO |
Вопросы с пуска
Можно ли клонировать MAC старого CPU на новый?
Обычно нет и не нужно. Правильный путь - назначить Device Name и IP новому устройству по регламенту DCP.
Достаточно ли выставить тот же IP в настройках Ethernet?
Для PN недостаточно без совпадения Device Name и конфигурации GSD. IP без имени в проекте PN часто не подхватится.
Нужно ли перепрошивать все IO после замены CPU?
Не всегда. Если ревизии совместимы - только assign name и topology. Прошивка IO - по сообщениям диагностики и release notes.
CODESYS и MasterSCADA по-разному работают с ProfiNet?
Среды взаимозаменяемы на одном железе; стек PN определяется контроллером и импортированным GSD. Процедура Online/Scan зависит от интерфейса IDE, принцип один.
Сколько времени занимает восстановление PN после замены CPU?
При готовом as-built с именами и IP - от 15 минут до часа с проверкой топологии. Без документации - поиск конфликтов имён и слотов может занять смену.
Обсуждение