Проблема со связью с шлюзом Anybus AB7850-F (Modbus Slave - Profibus Slave)

Сообщение **Arist007** » 01 сен 2017, 10:35

Всем добра, здравствуйте!
Есть проблема - все изрыл, не могу никак понять - в чем причина.
Есть ПЛК Siemens S7-400, серии H. Есть ПЛК Yokogawa Centum. Необходимо передать 20 слов из Сименса в Ёкогаву. До этого использовался шлюз Anybus X Gateway - все было настроено (сам настраивал), все работало до тех пор, пока шлюз не сгорел (кабельные ввода были негерметичны - при дожде попала влага, замыкание).
На данный момент закупили шлюз из той же линейки Anybus X Gateway, только обновленная версия AB7850-F. И теперь я не могу настроить связь ПЛК Siemens с Anybus'ом. Как ни пытался - ничего не получилось. (суть предыстории - раньше все работало со старым шлюзом - поставили новый шлюз, настроить связь не могу).
Что я пробовал: на оф сайте скачал GSD файл, переконфигурировал HW Config, перезалил в оба ПЛК Siemens из H-системы (в стоп-режиме), посмотрел конфигурацию самого шлюза Anybus (и через Hyper Terminal и через родное ПО все с того же оф сайта) - конфигурация такая какая должна быть (20 слов на входе, 20 слов на выходе). Подсоединяю питание к шлюзу, запускаю ПЛК (из стоп режима в Run) - шлюз горит красным Offline (со стороны Profibus). Все терминаторы на разъемах проверил, все в норме. Единственное - Profibus-разъемы стоят не сименсовские, а Phoenix Contact, но, думаю, что в этом проблем не должно быть, так как "до этого все работало". Прогрузил со старым GSD файлом, эффект тот же.
Коллеги, помогите советами, пожалуйста, направьте на путь истинный. Как бы вы поступили в данной ситуации?

Сообщение **Serex** » 01 сен 2017, 18:50

Поскольку что-то там замыкало из-за влаги, я бы еще раз тщательнейшим образом проверил разъемы и линию. Или даже заменил разъемы. Если текущие исправны, то просто положите их в ЗИП.
Попробуйте взять какое-то заведомо исправное устройство и подключить к этим разъемам.

Сообщение **Arist007** » 06 сен 2017, 15:23

Serex писал(а): Попробуйте взять какое-то заведомо исправное устройство и подключить к этим разъемам.

Это попробовал - все в порядке. То есть разъемы все исправные. Попробовал заведомо исправный разъем подключить - тоже ничего
все линии связи прозвонил, переподключил (сами ножи разъемов), подтянул клеммы - все в порядке, ни к чему не придраться.
На всякий случай скрин HW Config'a

Со скрина видно, что соединяется Anybus по корявому - будет передавать только если мастером стоит Rack0 - ну не суть, такую пусконаладку принял заказчик, это другой совершенно вопрос.
Таким образом Anybus подключается напрямую к Rack0. На пути стоит только "Разделительный усилитель полевой шины" Stahl 9185/11-35-00 (Инструкция на русском). Сейчас "ERR" мигает красным цветом - в инструкции:

Мигать не прекращает - пишут, что причина такого результата в отсутствии передачи данных в канале.
И еще, подключился Modbus Master'ом к Anybus'у - считывать данные получается (все нули - ну оно и понятно), но все равно, на Anybus'е со стороны Profibus'a - горит индикатор Offline.
У меня уже никаких мыслей по этому поводу. Пробую самые разные варианты, пока безрезультатно. К сожалению, никак не могу проверить работоспособность шлюза в лабораторных условиях. Но что то мне подсказывает, что дело вовсе не в бобине. Какую-то мелочь упустил..

Сообщение **Serex** » 06 сен 2017, 15:37

Давайте уточним. Был старый сгоревший Anybus в средней (на рисунке) сети. Эта сеть была с мастером в виде ET некой.
После отгорания старого модуля, вы пытаетесь новый модуль впихнуть в новую сетку, где Мастер CPU4xx ?

Сообщение **Arist007** » 06 сен 2017, 17:57

Serex писал(а):Давайте уточним. Был старый сгоревший Anybus в средней (на рисунке) сети. Эта сеть была с мастером в виде ET некой.
После отгорания старого модуля, вы пытаетесь новый модуль впихнуть в новую сетку, где Мастер CPU4xx ?

Немного не так.. тот что посередине модуль - это не Anybus - это другой сгоревший модуль (сгорел по другой причине)
А новый Anybus я ставлю на место старого, не меняя монтаж, не меняя ничего (кроме GSD файла, скаченного с оф. сайта)

Сообщение **Serex** » 06 сен 2017, 19:51

Еще я обратил внимание, что у вас резервированная конфигурация. Сам такую не обслуживал ни разу, но думаю там есть свои особенности, как прогружать конфигурацию. Возможно тут какой-то затык.
Еще в GSD я проверил бы адресацию. Не зря же он новый. Вполне возможно адресное пространство изменилось.
Еще несколько раз сталкивался, что с адресным пространством (c Hardware) работают на уровне программы. Т.е. есть свои FB для диагностики, DB с какими-то адресами. И чтобы все заработало, нужно внести устройство туда.

Сообщение **Arist007** » 07 сен 2017, 14:52

Serex писал(а): Еще я обратил внимание, что у вас резервированная конфигурация. Сам такую не обслуживал ни разу, но думаю там есть свои особенности, как прогружать конфигурацию. Возможно тут какой-то затык.

Тут я вроде как все учел (уже работал с такими системами). По теории можно прогрузить на 1 контроллер, а другой должен сам ссинхронизироваться. Но я для пущей уверенности прогружал в оба контроллер по очереди (сначала HWconfig потом NetPro).

Serex писал(а):Еще в GSD я проверил бы адресацию. Не зря же он новый. Вполне возможно адресное пространство изменилось.
Еще несколько раз сталкивался, что с адресным пространством (c Hardware) работают на уровне программы. Т.е. есть свои FB для диагностики, DB с какими-то адресами. И чтобы все заработало, нужно внести устройство туда.

По поводу GSD, кстати говоря, в Anybus можно забить отдельно входные/выходные адреса, которые можно вызвать элементарно PIW или PQW (прямо из программы), а можно и использовать "Универсальный модуль" данных. Вот с этим самым универсальным модулем надо работать через стандартные функциональные блоки SFC14, SFC15. Точно, надо будет и так попробовать! Спасибо! Буду пытаться!
Отпишусь как что сделаю - единственное на рабочем оборудовании не дадут сделать, а освободится только скорее всего ближе к середине/концу следующей недели.

Сообщение **ASUTP_PLC** » 12 сен 2017, 07:15

Arist007 писал(а):
Serex писал(а):Давайте уточним. Был старый сгоревший Anybus в средней (на рисунке) сети. Эта сеть была с мастером в виде ET некой.
После отгорания старого модуля, вы пытаетесь новый модуль впихнуть в новую сетку, где Мастер CPU4xx ?
Немного не так.. тот что посередине модуль - это не Anybus - это другой сгоревший модуль (сгорел по другой причине)
А новый Anybus я ставлю на место старого, не меняя монтаж, не меняя ничего (кроме GSD файла, скаченного с оф. сайта)

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

Я б такие вещи пробовал на тестовом контроллере. Можно абсолютно на любом контроллере, хоть 300 симатик типа 312 с самым минимумом памяти. Настроенная связь подтвердит что на правильном пути. А из подобного - ну очень часто встречается, что GSD файл рассчитан на не актуальную конфигурацию.

Сообщение **Arist007** » 13 сен 2017, 09:38

ASUTP_PLC писал(а): Больше похоже на то что вы пытаетесь на место старого прибора с его же адресом по шине забить конфигурацию другого нового прибора.
Возможно в этом грабли. Надо попробовать конфигурацию контроллера обновить. Или попытаться сесть на другой адрес.
Я б такие вещи пробовал на тестовом контроллере. Можно абсолютно на любом контроллере, хоть 300 симатик типа 312 с самым минимумом памяти. Настроенная связь подтвердит что на правильном пути. А из подобного - ну очень часто встречается, что GSD файл рассчитан на не актуальную конфигурацию.

К очень большому сожалению тестового ПЛК нет.
А вот на счет смены адреса - точно, надо попробовать!
Только на счет "не актуальной конфигурации" не понял - это имеется в виду firmware ПЛК? И если получается именно так, то как в этом случае поступать? Перешивать ПЛК на актуальную конфу и заново попытаться GSD цеплять и связь поднимать?
Я пробовал поднимать со старым GSD файлом - ничего.

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

ASUTP_PLC писал(а): Надо попробовать конфигурацию контроллера обновить

И да, кстати говоря, при обновлении firmware ПЛК - будет ли уверенность в том, что у меня не откажутся работать другие устройства с "не обновленными" GSD-файлами?

Сообщение **Serex** » 13 сен 2017, 14:52

Arist007 писал(а): И да, кстати говоря, при обновлении firmware ПЛК - будет ли уверенность в том, что у меня не откажутся работать другие устройства с "не обновленными" GSD-файлами?

Так такие вещи надо на тестовом стенде вначале обкатывать. Собрать из ЗИП наверняка что-то можно.

Сообщение **ASUTP_PLC** » 13 сен 2017, 15:32

firmware на контроллере обновить это другое. Здесь именно вопрос касательно конфигурации. А как она компилирована, что в ней есть,
это тоже важно. Сейчас она хранит все приборы. Если контроллер чистить, с нуля прогружать может и не так пойти.
Я б поискал даже как обычно - в долг, другой контроллер. От любой стороны, абсолютно любой, даб попробовать.
firmware из опыта приходилось обновлять для разных аппаратных штучек, типа высокоскоростного входа.
Здесь не могу утверждать, но профибас это внешняя сеть, контроллеру важно ее видеть, работать с ней он обязан полюбому.
Это не работа аппаратного счетчика которая перераспределение вычислительных ресурсов контроллера будет затрагивать.
Но, это все мое мнение... Вы можете его принимать, можете иметь свое.

Сообщение **Arist007** » 13 сен 2017, 17:21

Serex писал(а):Так такие вещи надо на тестовом стенде вначале обкатывать. Собрать из ЗИП наверняка что-то можно.

ЗИПа, как раз таки нет. Вообще нет. Никакого. Неоднократно говорил заказчику про необходимость ЗИПа - до сих пор ничего нет

ASUTP_PLC писал(а): firmware на контроллере обновить это другое. Здесь именно вопрос касательно конфигурации. А как она компилирована, что в ней есть,
это тоже важно. Сейчас она хранит все приборы. Если контроллер чистить, с нуля прогружать может и не так пойти.
Я б поискал даже как обычно - в долг, другой контроллер. От любой стороны, абсолютно любой, даб попробовать.
firmware из опыта приходилось обновлять для разных аппаратных штучек, типа высокоскоростного входа.
Здесь не могу утверждать, но профибас это внешняя сеть, контроллеру важно ее видеть, работать с ней он обязан полюбому.
Это не работа аппаратного счетчика которая перераспределение вычислительных ресурсов контроллера будет затрагивать.
Но, это все мое мнение... Вы можете его принимать, можете иметь свое.

Хм, а я подумал про firmware ..) Обновил Firmware на обоих ПЛК (пока все работает) была 4.5.4, стала 4.5.5 (последняя 4.5.7). Не помогло. Шлюз горит Offline и все тут.
Кстати про конфигурацию - при компилировании конфигурации постоянно вылетало окно с темой "Не могу сгенерировать, так как в вашей системе установлен язык, отличающийся от того, что установлен в программе". Иными словами - у меня в Windows установлен язык Русский, а в программе забит Немецкий. Что было сделано - я переделал в программе язык - добавил Русский. Теперь при генерировании ошибок не выдает, но завершается таким окном:

Картинка в полном объеме
То есть в строке состояния пишет Generation is not executed. При том никаких ошибок не выдает. Пробовал компилировался не через HW Config (через Simatic Manager: правой кнопкой мыши щелкаем на проекте: PLC --> Compile and Download Objects и там ставим галку "Compile Only"). Тут прошло без ошибок. Но не знаю идентичны ли эти процедуры. Но не суть - может ли "Generation is not executed" являться всему причиной? Если может, то как сделать так, чтобы было "Generation is successfully executed"?
P.S. Пробовал после загрузки конфигурации в ПЛК прогружать NetPro. Тоже не помогало.

Сообщение **Arist007** » 14 сен 2017, 10:04

и еще, попробовал сменить адрес устройства - также безрезультатно

Сообщение **Dfcz** » 14 сен 2017, 10:29

То что вы обновили прошивку ПЛК и все заработало, вам ОООчень крупно повезло.
Язык не нужно было добавлять, можно было указать, что использовать тот, который в Винде по умолчанию.
Изначально не нужно было ничего делать кроме как закачать GSD и в конфигураторе железа настроить устройство, точно так же как и сгоревшее. Тут главное слово ТОЧНО.
Если новое устройство не заработало, то значит не было ТОЧНО настроено.
Больше ничего не надо было делать. Все ваши другие действия только усугубляют ситуацию.

Сообщение **Arist007** » 14 сен 2017, 11:05

Dfcz писал(а):Изначально не нужно было ничего делать кроме как закачать GSD и в конфигураторе железа настроить устройство, точно так же как и сгоревшее. Тут главное слово ТОЧНО.
Если новое устройство не заработало, то значит не было ТОЧНО настроено.
Больше ничего не надо было делать. Все ваши другие действия только усугубляют ситуацию.

Последовательность моих действий (может я что-то не так делал):
1) удалил "сгоревшее" устройство из конфигуратора
2) добавил GSD файл
3) добавил новое устройство (по новому GSD файлу)
4) изменил profibus адрес устройства на такой же, который был у сгоревшего
5) добавил модули ввода/вывода данных
6) изменил адресацию данные (на ТЕ ЖЕ самые, что были в "сгоревшем" модуле)
7) Save And Compile
8) Загрузка конфигурации сначала в Rack0, затем в Rack1
Всё. Я что-то упустил? Вроде как все по рецепту.

Сообщение **ASUTP_PLC** » 14 сен 2017, 14:16

Не знаю почему, по идее в двух разных конфигурациях которые будут меж собой обмениваться данными, прогрузка нередко проводится несколько раз с перекомпиляцией.
Я кстати несколько подзабыл уже про redundancy режим работы ЕТ станции. Контроллер имеет доступ через один или другой модуль
IM 153-2. Считаю это основополагающим принципом, два контроллера - имеют выход на станцию, далее оперируют с одной шиной.
Все переключения /через 1 или 2 модуль/ идут на аппаратном уровне контроллера.

Вы ставите прибор на одну из профибас DP шин, и спрашиваете, почему прибор не видится?
Будь один контроллер и шина профибас одна, да согласен, все будет и должно работать.
Не не так как тут... Один контроллер имеет прямое соединение с вашим прибором.
А маршрут для второго соединения, тож самое но с контроллера который будет тянуть Redundancy - у вас отсутствует.
Поэтому я считаю ошибка в первую очередь в топологии. И конфигурация как раз таки не проходит.

Сообщение **Arist007** » 14 сен 2017, 15:19

ASUTP_PLC писал(а):Поэтому я считаю ошибка в первую очередь в топологии. И конфигурация как раз таки не проходит.

С этим полностью согласен. Топология логически не правильна. Так пусконаладчики сделали. Пока руки не доходят до перемонтажа.
Но надо признать что практически схема работает, при условии, что система будет пахать только на Rack0. Она так и пахала до этого.
Технические специалисты поставщика оборудования сказали, что все стандартные методы решения данной проблемы перепробованы, осталось выяснить рабочее оборудование или нет. Буду пробовать выяснять это с помощью осциллографа (проходит ли вообще какой нибудь сигнал). О результатах потом отпишусь.

Сообщение **Dfcz** » 14 сен 2017, 16:11

Arist007 писал(а): Всё. Я что-то упустил? Вроде как все по рецепту.

Ну да, так по рецепту и надо.
Если же не работает, то или не точно также настроили, как я уже писал, или, если есть обмен данными с этим устройством, то нужно конфигурировать это устройство "с его стороны". Применительно к текущей ситуации (проекта-то нет и не могу точно сказать) вопрос: конфигурируется это устройство своей программой-конфигуратором?
П.С. Про осциллограф это юмор?

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

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

А где тут две разные конфигурации, которые обмениваются между собой данными? На рисунке ОДНА конфигурация.

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

Serex писал(а): ....
Еще несколько раз сталкивался, что с адресным пространством (c Hardware) работают на уровне программы. Т.е. есть свои FB для диагностики, DB с какими-то адресами. И чтобы все заработало, нужно внести устройство туда.

Такое бывает, но проверять конфигурацию нужно, когда процессор в стопе, тогда и программа и адресное пространство не будут "вмешиваться".

Сообщение **Arist007** » 14 сен 2017, 17:11

Dfcz писал(а): П.С. Про осциллограф это юмор?

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

Сообщение **ASUTP_PLC** » 15 сен 2017, 06:38

Dfcz писал(а):
Arist007 писал(а): Всё. Я что-то упустил? Вроде как все по рецепту.
Ну да, так по рецепту и надо.
Если же не работает, то или не точно также настроили, как я уже писал, или, если есть обмен данными с этим устройством, то нужно конфигурировать это устройство "с его стороны". Применительно к текущей ситуации (проекта-то нет и не могу точно сказать) вопрос: конфигурируется это устройство своей программой-конфигуратором?
П.С. Про осциллограф это юмор?

Отправлено спустя 4 минуты 45 секунд:
ASUTP_PLC писал(а): Не знаю почему, по идее в двух разных конфигурациях которые будут меж собой обмениваться данными, прогрузка нередко проводится несколько раз с перекомпиляцией. .

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

Я думал что конфигурация на шлюзе тоже проливаемая. Это я из предыдущего опыта, когда надо было много контроллеров дружить на сименсе.Так то, если менять нужно только тут, значит да, конфигурация одна.

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

Любой анализатор того творится на profibus будет стоить дороже осциллографа. Можно использовать хоть цифровой, хоть древний ламповый. На результате одинаково скажется... Может разве что только с экрана фотографировать картинку не придется с нового прибора.
Можно вообще усилитель использовать. Через конденсатор к линии подцепить, послушать на динамике. Экран общий сделать.
Как проверка пойдет /для себя убедится/. Как доказательство третьим лицам - нет.

Сообщение **Dfcz** » 15 сен 2017, 08:27

У нас есть анализаторы Профибуса, лежат уже давно. Как показала практика, они не нужны - той диагностики, которая есть уже на платформе Степ7, вполне достаточно.
П.С.
Был у нас давно начальник, который все заставлял нас с осциллографом бегать, ну дибил. Так что не надо осциллограф - ничем он вам не поможет. Пусть осциллограф останется шуткой.

Сообщение **Arist007** » 01 окт 2017, 23:55

Dfcz писал(а):

ASUTP_PLC писал(а):

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

Arist007 писал(а):Технические специалисты поставщика оборудования сказали, что все стандартные методы решения данной проблемы перепробованы, осталось выяснить рабочее оборудование или нет.

ВСЕМ КТО ПОМОГАЛ И ДАВАЛ СОВЕТЫ!!!
Правда - спасибо преогромнейшее.
На всякий случай потом в теме отпишусь что сказал поставщик оборудования. И если пришлют новое, то после его установки тоже отпишусь.

Сообщение **Dfcz** » 02 окт 2017, 16:10

Вот это действительно правильное решение.

Сообщение **Prosto_chel** » 01 ноя 2017, 15:04

Проверили данный шлюз на стенде с двумя разными Profibus Master устройствами: шлюз оказался полностью исправным.
Т.е. проблема не в шлюзе.

Сообщение **Prosto_chel** » 02 ноя 2017, 08:34

Dfcz писал(а): Про осциллограф это юмор?

Совсем не юмор. Многократно бывало, что на конце линии RS485 у сигнала нет четких фронтов (завалы или помехи). Вроде все работает, а данные не проходят. И с кабелем косячили, и с терминаторами, бывает и микросхема драйвера RS485 оказывается полудохлой.