Ошибки profibus соединений

Сообщение **Reinard** » 18 авг 2020, 12:38

Добрый день.

К резервированным серверам через внешнюю плату CP5711 подключены несколько контроллеров по profibus. В проекте ВинСС опрашиваются через сименсовский профибас драйвер. Некоторое время назад начали сыпаться системные сообщения: соединение пропадает (не установлено) - соединение установлено. Стабильно несколько раз в сутки. Причем длительность ошибки соединения не больше 1 секунды. То есть сообщение об отсутствии соединения, и через секунду сообщение, что соединение установлено. Причем выпадают все соединения на линии (штук пять) и через секунду все вместе восстанавливаются. Проблем непосредственно с данными нет - все параметры читаются без пропаданий показаний (нет ни зависаний, ни пропаданий показаний в трендах; ничего не видят подозрительного операторы), запись команд тоже идет без ошибок (каких-то заявок, что не удается что-то открыть или задать не поступает). Какие-либо манипуляции с физической линией сделать сейчас не можем, так как объект работает, а кроме сообщений никаких сбоев нет - естественно, что эксперименты никто не даст делать. Но вообще смущает сам факт, что пропадают все соединения одновременно и тут же одновременно восстанавливаются, причем практически моментально. Есть предположение, что, возможно, моросит сименсовский драйвер профибас в ВинСС - генерирует ошибки по своей диагностике, хотя по факту связь есть. Все настройки кроме адресов оставили по умолчанию в свое время, когда создавали проект. Может кто-то сталкивался с таким поведением профибас драйвера?

Сообщение **v0v** » 18 авг 2020, 17:01

Возможно много причин. Переключатели on/off на разъеме профибас, экранирование, обрыв питания на модуль с профибасом, если есть сервоприводы, то бывает экран силовой части провода идущий на двигатель плохо заземлен, что сказывается на профибас и т.д. На CP5711 лучше делать связь по MPI с контроллером на прямую и диагностику по профибас в WinCC, чтобы на экране PC связь с контроллером не прерывалась и то бывает трудно найти причину.

Сообщение **stesl** » 19 авг 2020, 02:40

Согласен, когда неисправность плавающая, а поковырять ничего нельзя, то и делать ничего не надо )
Пусть они совсем лучше отвалятся, тогда и останов будет и поковырять можно. Ну попи...., покричат ) Но не накажут, если сделаете.
А если сейчас наседают, то служебку-запрос останова.
По сути вопроса - нет, не сталкивался с подобным. Возможно просто окисленный контакт.

А то, что все валятся - не должно смущать. Они же все в линию собраны. И если тот же окисел допустим на Вашей коммуникационной плате, или как предположил коллега - проблема с переключателем на штекере (но 1го в линии ПЛК), то так и будет. Если бы у драйверов Simatic были бы проблемы, то Вы наверняка что либо нагуглили бы. Тут быстрее на ОС можно подумать.

Сообщение **POV** » 19 авг 2020, 08:03

5711 вроде по USB подключается? Я бы вот с него (USB) и начал. Может и не в профибасе дело.

Сообщение **Reinard** » 19 авг 2020, 13:18

Изучили фактически структуру сети. Реализовывали не мы, а схемы оказались не совсем корректные.
У нас профибас сеть идет не целиком rs485, а удлиняется оптикой через преобразователи. Получается следующая структура - сначала идет 485-й шлейфом до двух контроллеров, потом от них шлейфом на преобразователи, с преобразователей уходит в две стороны оптикой (уже выходит условная "звезда"), и затем каждая оптика снова через преобразователь становится 485-м, который шлейфом идет по контроллерам.
В связи с чем возник вопрос. Я уже сталкивался с профибасом полностью на 485-м интерфейсе. И там в целом достаточна понятна логика - ошибка с резистором в начале линии валит всю линию; если резистор сбоит в середине линии, то до него все может работать, после сбоить. А что в случае удлинения линии оптикой? Если я правильно понимаю, то в целом это становятся физически независимые сегменты. Значит, если будет проблема с линией конечной (после оптики), то линия первичная (до оптики) от этого не должна страдать?

Сообщение **VADR** » 19 авг 2020, 13:49

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

Сообщение **Reinard** » 31 авг 2020, 12:43

Выяснен еще один факт. Кроме того, что всех в сети теряют сервера (и тех, кто рядом по меди, и тех, кто далеко через оптику и преобразователи), также еще выяснили один факт. В удаленном медном сегменте с одного контроллера получает данные локальная станция. Эта станция и контроллер соединены в своем сегменте локально медью, участок короткий несколько метров в пределах одного помещения. И вот эта станция также время от времени теряет связь со своим контроллером. Выяснили это поздно, потому что станция в данный момент не используется и просто стоит без оператора. В буфере CP контроллера сообщения об ошибках на шине, выходе из маркерного кольца, невозможности обмена. Ну и потом сообщение, что все восстановилось связь восстановлена. Проверены другие CP в данной сети - больше ошибок ни на какой нет.
Выходит, что теряют связь все кто кого-то опрашивает в данной сети (как с преобразователями, так и локально). На драйвер уже не думаем, так как ситуация со станцией и контроллером дает понять, что все-таки реально дело в где-то в сети.
В связи с чем вопрос: если в качестве предположения взять, что CP просто выходит из строя (просто отработала свой срок - им там уже лет 10 где-то), то понятно, что данный контроллер будет выходить из сети, но может ли это в теории "ложить" всю сеть?

VADR писал(а): ↑19 авг 2020, 13:49 Преобразователи в оптику небольшую задержку дают и это где-то в конфигурации учитывается.

Вот только в настройках драйвера profibus WinCC настроек особых нет, кроме того откуда тянуть данные.

Сообщение **VADR** » 31 авг 2020, 14:00

Reinard писал(а): ↑31 авг 2020, 12:43 В удаленном медном сегменте с одного контроллера получает данные локальная станция. Эта станция и контроллер соединены в своем сегменте локально медью, участок короткий несколько метров в пределах одного помещения. И вот эта станция также время от времени теряет связь со своим контроллером.

Это всё в той же сети или на отдельном сегменте? Не получилось ли так, что у вас в сети одновременно два мастера и изредка они друг с другом не ладят?

Сообщение **Reinard** » 31 авг 2020, 14:41

VADR писал(а): ↑31 авг 2020, 14:00 Это всё в той же сети или на отдельном сегменте

В той же сети.

VADR писал(а): ↑31 авг 2020, 14:00 Не получилось ли так, что у вас в сети одновременно два мастера и изредка они друг с другом не ладят?

В сеть никаких устройств новых не добавлялось уже давно. А ошибки появились только в этом году. Если какие-то устройства мешали бы друг другу, то непонятно как раньше тогда работало без ошибок. Адреса и настройки всех в сети проверили - в теории вроде конфликтов быть не должно, каких-либо ошибок явных не нашли (на уровне программы - адреса, настройки).

Сообщение **Reinard** » 23 сен 2020, 08:34

Добрый день.

Нашли решение проблемы. Удлинили локальную линию после оптики. Последним в линии локальной был компьютер, с него продлили линию в пустоту. На конце просто повесили коннектор, висит такой хвост. После этого в локальном сегменте после оптики связь пропадать перестала (компьютер по меди свой контроллер не теряет больше). Глобально во всей линии ошибок тоже меньше стало. Они еще иногда есть, но намного меньше. Если раньше ошибки сыпались десятками за сутки, то теперь несколько раз за неделю на серверах только выпадают. Предполагаю, что если от серверов сделать такие же хвосты пустые, то и на них все станет отлично (но это пока проверить невозможно).
Решение проблемы найдено, но вот сама причина непонятна. "Деградация" резисторов не подходит, так как еще до хвоста поменяли все коннекторы на новые, и это не помогло. А потом сделали тупиковый хвост и все исправилось. Полагаю, что и со старыми коннекторами такой хвост ситуацию бы исправил.

Сообщение **VADR** » 23 сен 2020, 11:42

Довольно странный и загадочный эффект. А, кстати, нигде в этом сегменте сети нет медного сегмента длиной менее метра? Если есть - попробуйте заменить на более длинный, 1.5 метра или более.

Сообщение **Reinard** » 23 сен 2020, 20:33

VADR писал(а): ↑23 сен 2020, 11:42 А, кстати, нигде в этом сегменте сети нет медного сегмента длиной менее метра?

Короткие есть. Вполне могут быть и менее метра. Но у нас коротких участков профибас вообще много. В шкафах расширения между соседними дин-рейками в одном шкафу явно меньше метра - а таких шкафов десятки. Я так понимаю, что короткий участок преставляет собой источник возможных проблем?

П.С.: И это же не первый раз, когда такое решение помогает. Несколько лет назад у нас была похожая ситуация, только отваливались модули расширения от контроллера 400-го. Тоже все работало, работало, а в один день один в одном шкафу одна сторона стала отпадать - пропадет, восстановится связь 400 с im. Тогда тоже пытались разобраться - ничего не помогало, пока не сделали такой же хвостик с последнего im-модуля. И все - с тех пор проблемы не было. Просто забылось немного. И тут то вспомнил об этом - решил, что и здесь же что-то подобное - вот сделали тоже самое и помогло опять. Тенденция получается.

Сообщение **VADR** » 24 сен 2020, 00:00

Не помню, откуда я это взял изначально, но в голове засела информация, что сегменты profibus менее 1 метра - не есть хорошо. Поиск дал, к примеру, такую ссылку: https://procentec.com/service-support/faq/profibus/

When the transmission speed is 1,5 Mbps or higher, it is highly recommended to have at least 1 m of cable between 2 devices. De input capacitance of both devices will be compensated by the cable in order to preserve the common impedance. When the devices would be very close together, there is a big chance the input capacitance causes reflections in the data communication (small short circuits). The effect is much less at transmission speeds lower than 1,5 Mbps.