Потеря связи между Siemens и Weidmuller

[AlexeyG]

Добрый день. Ситуация следующая: потеря связи PROFINET между ПЛК Siemens 1200 и модулем удаленного ввода вывода Weidmuller. Зависимости никакой нет. Может пропадать несколько раз в минуту может и 2-3 раза в день. Соединение ПЛК-неуправляемый коммутатор- неуправляемый коммутатор- модуль Weidmuller. Модуль Weidmuller меняли, коммутаторы Schneider меняли на EKF, кабель меняли, кран кабеля заземляли и с одной стороны и с двух сторон и без заземления, разъёмы RG45 меняли и просто пластиковые, и пластик с землёй и многоразовые Siemens ставили. Трасса метров 15. Может кто посоветовать что то или у кого была такая же проблема?

[Parliament74]

Помимо ПЛК и панели в сети что ещë находится?

Посмотрите трафик в сети, через тот же Wireshark, например.

Соедините напрямую без коммутаторов, как вариант)

[pike]

Ситуация следующая: потеря связи PROFINET между ПЛК Siemens 1200 и модулем удаленного ввода вывода Weidmuller. Зависимости никакой нет. Может пропадать несколько раз в минуту может и 2-3 раза в день. Соединение ПЛК-неуправляемый коммутатор- неуправляемый коммутатор- модуль Weidmuller. ?

Profinet IO по стандарту с неуправляемыми коммутаторами не дружит. Нужны управляемые с поддержкой функций PROFINET v2 класс B.

[Parliament74]

Profinet IO по стандарту с неуправляемыми коммутаторами не дружит. Нужны управляемые с поддержкой функций PROFINET v2 класс B.

Ну не знаю, в руководстве (Guideline PROFINET IO Conformance Classes) вполне себе и Conformity class A описан:

- CC-A provides basic functions for PROFINET IO with RT communication.
- CC-B extends the concept to include network diagnostics via IT mechanisms as well as topology information. The system redundancy function important for process automation is contained in an extended version of CC-B named CC-B(PA).
- CC-C describes the basic functions for devices with hardware-supported bandwidth reservation and synchronization (IRT communication) and is thus the basis for isochronous applications.

Да и сам Siemens для простых систем вполне себе неуправляемые коммутаторы серий XC-000 / XC-100 предлагает, у них как раз CC-A. В классе А просто диагностики никакой сделать практически невозможно.

[pike]

Осталось узнать у автора:
1) Есть ли на используемых коммутаторах пометка CC-A?
2) Зачем их 2 шт: для удлинение линии связи или для ветвления и подключения других устройств.

PS CC-A это если все от Siemens (одного производителя), чисто IO, не очень далеко и без заморочек с топологией, то есть в реальности очень на тоненького.

[AlexeyG]

Пометку посмотрю завтра
Топология во вложении

[Parliament74]

HMI Siemens наверное базовой серии? Если бы были Comfort, можно вообще два свитча шнайдеровских выкинуть из схемы, они не нужны. По-хорошему, на всë это хозяйство одного свитча достаточно, но учтите что базовые модели свитчей SE для Profinet не предназначены. Тот же Scalance XC005 и то более адекватно здесь смотрелся бы. Ну если по-нормальному делать, то да, L2 managed сюда просится вместо трëх неуправляемых.
Можно для эксперимента S7-1200 напрямую с UR20 соединить, а панели и линию на второй ПЛК через свитчи оставить (получится первый порт S7-1200 напрямую в UR20, второй порт - на свитч, от свитча - в две панели и ко второму контроллеру), так не пробовали?

Как вариант, попробуйте Profinet update time увеличить (если в S7-1200 оно настраивается): https://support.industry.siemens.com/cs ... 0&lc=en-AO

Ещë посмотрите настройки UR20, может быть ему в настройках можно увеличить Time out (но по опыту эти параметры обычно начинают работать, когда в сети десятки устройств). А с ПЛК SE обмен есть у S7-1200 по Modbus TCP? Какой цикл опроса? Панели каждая со своим ПЛК работает только или отовсюду данные тащат? По-хорошему, надо в сети посмотреть что с трафиком происходит, вполне может быть там просто какой-то лютый трэш творится.

[pike]

В таких схемах между контроллером и удаленным модулем должен стоять управляемый коммутатор, еще и правильно настроенный.
Profinet IO по другому использует уровни Ethernet ISO, чем обычный Ethernet TCP/IP и бегающие поверх него протоколы Modbus TCP, S7 Communication и т.п.

[Jackson]

В таких схемах между контроллером и удаленным модулем должен стоять управляемый коммутатор, еще и правильно настроенный.
Profinet IO по другому использует уровни Ethernet ISO, чем обычный Ethernet TCP/IP и бегающие поверх него протоколы Modbus TCP, S7 Communication и т.п.

В плане общего развития - а это Сименс зачем так сделал? Поддержка производителей промышленных коммутаторов?

[pike]

В плане общего развития - а это Сименс зачем так сделал? Поддержка производителей промышленных коммутаторов?

Это у всех протоколов реального времени на базе Ethernet (EtherCAT CoE/SoE, Profinet IO/RT, Profinet IRT и т.п.) для обеспечения высокоскоростного и стабильного обмена небольшими пакетам (относительно TCP/IP) данных.
Давно было, но баловались на стенде, так на неуправляемом коммутаторе при попытке пропустить через него обмен с циклом 2 мс с несколькими устройствами срабатывала защита broadcast storm блокировавшая порты.

[AlexeyG]

Топологию вчера чуть чуть неверную начертил.
На коммутаторах не нашел нигде отметок про СС-А.
HMI да к сожалению Basic.
2 панели Siemens просто продублированы.
Обмен идет между S7-1200 и Weidmuller. Обмен между S7-1200 и Schneider под вопросом, скорее всего дискретный сигнал.
Попробую убрать Schneider коммутаторы, отключить одну панель. поставить коммутатор Siemens. Поверх всего перестали архивироваться все сообщения на панели HMI Siemens.(Надо сперва сообщения восстановить, что бы отвалы видеть)

[Jackson]

[+] Извините, я всё со своим оффтопиком

Это у всех протоколов реального времени на базе Ethernet (EtherCAT CoE/SoE, Profinet IO/RT, Profinet IRT и т.п.) для обеспечения высокоскоростного и стабильного обмена небольшими пакетам (относительно TCP/IP) данных.
Давно было, но баловались на стенде, так на неуправляемом коммутаторе при попытке пропустить через него обмен с циклом 2 мс с несколькими устройствами срабатывала защита broadcast storm блокировавшая порты.

Не вдаюсь в тонкости цифр, но видел на других контроллерах результат обмена по EtherCAT. В сети их было три штуки плюс устройство опроса. Не поручусь за частоту опроса, но синусоида сетевого напряжения по получаемым данным рисовалась очень точно - сравнивали с аналоговым осциллографом. Синхроноскоп, нарисованный на панельке по этим данным, тоже работал не хуже классического аппаратного, стоящего рядом - а это показатель того, что мы не опаздываем (иначе случалось бы не очень синхронное включение генераторов, а это не заметить невозможно). Это опрос как минимум двух устройств одновременно, плюс пересчёт, плюс отображение (которое тут и есть самое медленное звено), плюс все устройства ещё и друг с другом по тому же интерфейсу общаются.

В одном случае коммутатора не было вовсе - количество портов в контроллере позволяло без него обойтись и получить кольцевую топологию. Во втором случае гигабитный коммутатор был - промышленная мокса не из начальных серий, но неуправляемая. Защита от геошторма в нём молчала.

К сожалению, сейчас этот опыт не повторить - нет всего оборудования под рукой, да и незачем. Но факт - быстродействия хватало для этой задачи. А синусоиду отрисовать - много точек на период надо, а сеть 50 Гц, период 20мс соответственно.

Вот я и задумался: оправдано ли это всё у Сименса чем-то, кроме цели поддержать производителей финансово. Тем более что за Сименсом такие грешки водились.

Извините за оффтопик, если продолжим то унесу в отдельную тему.

[I_m]

Давно было, но баловались на стенде, так на неуправляемом коммутаторе при попытке пропустить через него обмен с циклом 2 мс с несколькими устройствами срабатывала защита broadcast storm блокировавшая порты.

А можно полюбопытствовать - откуда об этом (broadcast storm) стало известно, если коммутатор был неуправляемый? И откуда бы broadcast storm взяться в нормальном режиме работы коммутатора? Пакеты рассылки именно broadcast были? Т.е. вы принудительно заставили работать коммутатор постоянно в режиме обучения, т.е. фактически перевели его в режим хаба, а потом удивлялись, что оно нормально не работает?

Profinet IO по другому использует уровни Ethernet ISO

А какие такие загадочные "уровни Ethernet ISO" профинет использует, если сам эзернет - всего лишь 1 и 2 уровни модели OSI?

В общем, разговоры типа "у нас есть такие приборы...". Единственное внятное - требования по быстродействию самого коммутатора, вне зависимости от его управляемости.

[VADR]

А какие такие загадочные "уровни Ethernet ISO" профинет использует, если сам эзернет - всего лишь 1 и 2 уровни модели OSI?

Не "другие уровни", а "по другому использует". Например, номер ethertype там 0x8892, что несколько отличается от остального, что бегает по ethernet. Это если RT без IRT. Для IRT там ещё какие-то премудрости есть.

[I_m]

Например, номер ethertype там 0x8892

И всё? Это может быть использовано для приоритизации трафика. И наверняка используется. Вот не знаю - неуправляемы коммутаторы профинет используют или нет.

[pike]

А можно полюбопытствовать - откуда об этом (broadcast storm) стало известно, если коммутатор был неуправляемый? И откуда бы broadcast storm взяться в нормальном режиме работы коммутатора?

Производителем коммутатор был заявлен как не управляемый, подключиться и настроить в нем ничего нельзя было.
На каждый порт было по 3 светоиндикатор, если один из них начинал мигать определенным образом по документации это означало, что коммутатор регистрирует broadcast storm и порт блокируется.

Не вдаюсь в тонкости цифр, но видел на других контроллерах результат обмена по EtherCAT.

EtherCAT то же бывает "немного" разный (в том числе и из-за приставочек CoE, SoE, EoE,AoE,EAP...), здесь еще внимательнее к тому, что заявлено в оборудовании надо относится, чем с Profinet IO. C EtherCAT еще пока все использовали только чипы бекхова было полегче, а сейчас много тараканов лезет.
Все сводится к двум вариантом: будет работать гарантировано или возможно будет работать.
Мне проще работать исходя из того все эти протоколы это специальные полевые шины со своими кабелями, разъемами и прочим, а обмен и сети Ethernet TCP и UDP это отдельно, пусть и в пром условиях.

[Jackson]

Мне проще работать исходя из того все эти протоколы это специальные полевые шины со своими кабелями, разъемами и прочим, а обмен и сети Ethernet TCP и UDP это отдельно, пусть и в пром условиях.

Что тут специального - поясните пожалуйста? Кабель FTP 6 категории с соответствующими разъёмами. Или есть ещё отличия?
В стендовых условиях я запускал EtherCAT даже на UTP 5 категории.

[pike]

Что тут специального - поясните пожалуйста?

Специальное - оно относительно того, что я вижу, что другие используют/монтируют.
У меня:
- Кабель "зеленый" CAT 5e "толстые" жилы AWG22/19, двойное экранирование SF/UTP.
- Разъемы соответствующие уже только с полностью металлическим корпусом.

Опять же у меня специфика с постоянными источниками помех: куча мощных серво и пч + бонусы в виде всякие магнитные столы, вч генераторы и т.п. И эксплуатирующий и обслуживающий персонал слабо понимающий зачем вообще заземление нужно.

[VADR]

Что тут специального - поясните пожалуйста? Кабель FTP 6 категории с соответствующими разъёмами. Или есть ещё отличия?

В основном на физическом уровне всё как обычный Ethernet. Разве что для случаев со сложной электромагнитной обстановкой повышены требования к экранированию и правильному заземлению экранов. И диаметр жил у кабелей "специально под Profinet" побольше. Не настолько побольше, чтобы из стандарта вылезать, но по верхнему краю.

[Jackson]

pike, VADR, спасибо! Да, понял. Помехозащищённость - да, понимаю, SF/UTP и разъёмы - "наш" производитель такие кабели и поставляет если заказать.

[+]

была история, по ошибке купили у СпецКабеля SF/UTP с увеличенным сечением жил, а разъёмы заложили обычные. В итоге жилы катастрофически не влезали в разъём. А по факту там и обычного UTP хватило бы - только внутри щита управления и 100-мегабитные линии, даже не гигабит. В итоге и перезакупили кабель попроще, а тот от СпецКабеля так и лежит на складе.

Ладно, извините меня за оффтопик, вопрос был другой. Я просто хотел прояснить про EtherCAT и прочие быстрые протоколы на базе IP.

[+]

Но кстати, когда сделали синхроноскоп на сенсорной панельке (тоже непростой конечно - с EtherCAT на борту) в резервированной сети - это впечатлило. На практике конечно бессмысленно, проще обычный синхроноскоп поставить с прямыми измерениями, но впечатляет. Особенно учитывая то, что эти контроллеры применяются в системах управления спец.судов с динамическим позиционированием (удержание на точке с точностью +-метр), там отказ позиционирования может помножить на ноль весь глобальный проект - трубу будущего газопровода например сломают, или бур при глубоководном бурении. А по сегодняшним реалиям там ещё и зелёные технологии вмешались, будь они неладны - и они там ещё "свои 5 копеек" вносят. Вот там я столкнулся на практике с EtherCAT и его резервированием в полный рост. Ну как "столкнулся" - видел что должны были сделать разработчики, но не сделали из-за СВО: железо поставили, смонтировали, а софт уже нет, в итоге суперпароход стоит кирпичом, мы его как раз оживить пытаемся. Хорошо хоть проектная документация кое-какая нашлась.

[AlexeyG]

Убрал два шнайдеровских коммутатора и одну панель, поставил коммутатор Siemens. Посмотрим как полет будет

[AlexeyG]

Убрал два шнайдеровских коммутатора и одну панель, поставил коммутатор Siemens. Посмотрим как полет будет

не помогло

Отправлено спустя 3 минуты 28 секунд:
В итоге вылечили. Достали проект, там в сети оказалось больше 10 ПЛК и разных модулей. Просто убрали связь с ненужными ПЛК физически.