Массовое потеря связи с оборудованием

Сообщение **hypernom** » 05 июн 2019, 14:49

Здравствуйте, столкнулись с очень не приятной и странной ситуацией. Для начала, не много о том, что это за оборудование, и как оно связанно. Я нарисовал примерную схему соединения и связи. Где у нас имеется 4 оборудования, в которых установлены коммутаторы связи, которые в свою очередь управляются дистанционно по WiFi, они передают сигнал на точку доступа, а те в свою передают дальше по оптоволокну в подстанцию, где все 4 оборудования заходят в один Hirschmann, от которого идёт Ethernet в ПЛК контроллер s7-400, далее тот обрабатывает и передает уже на сервер. Надеюсь я смог вам обЪяснить принцип связи. Так вот, у нас была проблема с тем, что была потеря связи с один из оборудований, мы решили прогрузить те-же самые блоки в проекте, после чего, все 4 оборудования легли и перестали отзываться. После проверки, выяснили, что связь от Сервера до ПЛК есть, а так-же, от Оборудования до Точки доступа. Как я это выяснил? Пинговал от оборудования до точки доступа и возможного айпишника хиршманна. Вопрос следующий, что могло произойти после того, как были просто погружены блоки в проекте, мы естественно заливали уже бэкап, не помогло. Где смотреть именно эти конфигурации? Могли ли слететь настройки на самом хиршманне в подстанции? Буду очень сильно благодарен любой помощи, готовь предоставить любой скриншот.

Отправлено спустя 12 минут 47 секунд:
Если действительно проблема в Hirschmann, то как можно протестить его? Пытаюсь найти софт, но все как всегда печально :C

Сообщение **LexSL** » 06 июн 2019, 08:42

hypernom писал(а): ↑05 июн 2019, 15:02 Если действительно проблема в Hirschmann, то как можно протестить его? Пытаюсь найти софт, но все как всегда печально :C

Работал как-то давным давно с маршрутизатором Hirshmann RS20, использовал HiVision (настройка, контроль, управление), а также HiDiscovery (утилита для обнаружения и быстрой настройки). HiVision на 16 узлов можно скачать бесплатно с сайта производителя (если не ошибаюсь там есть даже на виртуальной машине ознакомительная версия).

Сообщение **MuadDib** » 06 июн 2019, 09:10

hypernom писал(а): ↑05 июн 2019, 15:02 мы решили прогрузить те-же самые блоки в проекте

Что означает "решили прогрузить"? Загрузили какие-то компоненты проекта Step7 (FC, FB, DB) в контроллер из существующего проекта? Если так, то что значит "те-же самые блоки"? Поподробнее плиз.

Пока все указывает на то, что ваша манипуляция сделала проект в контроллере неработоспособным. Причин такого может быть масса. Возможно, в контроллере была более новая (отлаженная) версия программы, а вы залили блоки из старой версии (или вообще перепутали проекты). Возможно, вы совершили какие-то неверные действия при загрузке. Бэкап может не помогать по тем же причинам: бэкап, предоставленный производителем, по недосмотру последнего тоже может быть устаревшим и при его заливке тоже можно накосячить.

По хорошему, прежде чем заливать что-то в контроллер, надо делать Compare online/offline и выяснять, какие изменения в поведении произойдут после вашей манипуляции.

Сообщение **hypernom** » 06 июн 2019, 10:21

MuadDib писал(а): ↑06 июн 2019, 09:10
hypernom писал(а): ↑05 июн 2019, 15:02 мы решили прогрузить те-же самые блоки в проекте
Что означает "решили прогрузить"? Загрузили какие-то компоненты проекта Step7 (FC, FB, DB) в контроллер из существующего проекта? Если так, то что значит "те-же самые блоки"? Поподробнее плиз.

Пока все указывает на то, что ваша манипуляция сделала проект в контроллере неработоспособным. Причин такого может быть масса. Возможно, в контроллере была более новая (отлаженная) версия программы, а вы залили блоки из старой версии (или вообще перепутали проекты). Возможно, вы совершили какие-то неверные действия при загрузке. Бэкап может не помогать по тем же причинам: бэкап, предоставленный производителем, по недосмотру последнего тоже может быть устаревшим и при его заливке тоже можно накосячить.

По хорошему, прежде чем заливать что-то в контроллер, надо делать Compare online/offline и выяснять, какие изменения в поведении произойдут после вашей манипуляции.

Да, загрузили все компоненты из существующего проекта, в которую входят FC,FB,OB,DB и прочее. Перепутать не могли, у нас всё подписано, и если бы загрузили бы другие блоки, то те оборудования которые входят, они бы сейчас вообще не работали, но в данный момент всё хорошо с ними, с датчиков имеем сигнал, что не сказать об оптике.

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

Отправлено спустя 3 минуты 1 секунду:

LexSL писал(а): ↑06 июн 2019, 08:42
hypernom писал(а): ↑05 июн 2019, 15:02 Если действительно проблема в Hirschmann, то как можно протестить его? Пытаюсь найти софт, но все как всегда печально :C
Работал как-то давным давно с маршрутизатором Hirshmann RS20, использовал HiVision (настройка, контроль, управление), а также HiDiscovery (утилита для обнаружения и быстрой настройки). HiVision на 16 узлов можно скачать бесплатно с сайта производителя (если не ошибаюсь там есть даже на виртуальной машине ознакомительная версия).

нашёл в сети hivision 7-й версии, но ещё не использовал, пока разбираемся с самим проектом.

Сообщение **MuadDib** » 06 июн 2019, 10:53

Да, скорее всего, в загруженных вами блоках была иная версия алгоритма, отвечающего за связь с проблемным оборудованием. Могут отличаться настройки (адреса и т.п.), а может быть и что-нибудь еще.

Поскольку у вас S7-400 есть небольшой шанс вернуть все как было небольшими усилиями. Если в контроллере установлен модуль EEPROM (именно ПЗУ, не RAM), есть надежда, что актуальная версия проекта хранится на нем. При загрузке проекта в контроллер EEPROM не перезаписывается автоматически, и, вероятно, вручную вы его тоже не перезаписывали. Если все так, можно попробовать сделать MRES. Только предварительно сделайте полностью Upload station to PG в новый пустой проект, на всякий случай.

Сообщение **hypernom** » 06 июн 2019, 11:07

MuadDib писал(а): ↑06 июн 2019, 09:10
hypernom писал(а): ↑05 июн 2019, 15:02 мы решили прогрузить те-же самые блоки в проекте
Что означает "решили прогрузить"? Загрузили какие-то компоненты проекта Step7 (FC, FB, DB) в контроллер из существующего проекта? Если так, то что значит "те-же самые блоки"? Поподробнее плиз.

Пока все указывает на то, что ваша манипуляция сделала проект в контроллере неработоспособным. Причин такого может быть масса. Возможно, в контроллере была более новая (отлаженная) версия программы, а вы залили блоки из старой версии (или вообще перепутали проекты). Возможно, вы совершили какие-то неверные действия при загрузке. Бэкап может не помогать по тем же причинам: бэкап, предоставленный производителем, по недосмотру последнего тоже может быть устаревшим и при его заливке тоже можно накосячить.

По хорошему, прежде чем заливать что-то в контроллер, надо делать Compare online/offline и выяснять, какие изменения в поведении произойдут после вашей манипуляции.

ещё такой вопрос, мы заливаем на плк бэкап путем соединения с ним через сервер, по идеи, это тоже самое, если подсоединиться к нему через адаптер юсб локально в подстанции, или жё все таки разница имеется? и стоит тогда попробовать залить все это, локально?!

Сообщение **MuadDib** » 06 июн 2019, 11:20

Если в процессе загрузки никаких ошибок не было, то разницы нет. Если сомневаетесь, можно убедиться, что содержимое контроллера соответствует содержимому проекта Step7, выполнив Compare Online/Offline.

Сообщение **hypernom** » 06 июн 2019, 15:57

MuadDib писал(а): ↑06 июн 2019, 11:20 Если в процессе загрузки никаких ошибок не было, то разницы нет. Если сомневаетесь, можно убедиться, что содержимое контроллера соответствует содержимому проекта Step7, выполнив Compare Online/Offline.

Перезалил бэкап рабочий. Всё тоже самое, открываю нетпро, жму на плк, и вижу, что связи с некоторым оборудованием нет. Всё это проходит через коммуникационный процессор CP 443-1. Открываю его через NCM S7 Diagnostics, но ничего особого не вижу. Во вкладке "Operating Mode" есть таблица, где "S7 communication - RUN", а "Send/Recv communication - STOP"

Возможно ли проблема исключительно с этим коммуникационным процессором? Если да, то просто заменив его, мне нужно будет перезаписывать блоки Net a?

Сообщение **MuadDib** » 07 июн 2019, 04:42

hypernom писал(а): ↑06 июн 2019, 15:57 Возможно ли проблема исключительно с этим коммуникационным процессором? Если да, то просто заменив его, мне нужно будет перезаписывать блоки Net a?

Сильно сомневаюсь, что у вас аппаратная проблема с CP. Проблема ведь началась с того, что связь пропала с одним устройством (то есть с остальными CP обменивался данными). А после перезаливки пропала связь со всеми устройствами, подключенными аналогичным образом. То есть проблема софтовая, и в состояние "нет связи только с одним устройством" можно вернуться без замены оборудования, залив в контроллер правильные блоки и/или поменяв конфигурацию.

hypernom писал(а): ↑06 июн 2019, 15:57 "S7 communication - RUN", а "Send/Recv communication - STOP"

Не приходилось работать с отдельными CP и с Send/Recv, но в сети наткнулся вот на это:

https://support.industry.siemens.com/tf ... ageSize=10

Надеюсь, поможет.

Сообщение **ASUTP_PLC** » 07 июн 2019, 08:29

Запускал большой проект с Send/Recv communication. После настройки он как-то хитро вел коммуникации...
У меня была ситуация что пинги не проходили, а связь была.