Зависание связи по modbus rtu

Сообщение **VADR** » 23 мар 2021, 11:06

Приветствую, коллеги.

Есть две системы, сделанные на одной элементной базе одним проектировщиком.
Железо:
Контроллер ET200S IM151-7 CPU (6ES7 151-7AA13-0AB0), интерфейс RS485 1SI Modbus Master (6ES7 138-4DF11-0AB0). Ещё различный ввод/вывод, но к вопросу он отношения не имеет.
Слейвы одинаковые, в одинаковой конфигурации, в обоих случаях - по два частотника Altivar 71.
Настройки сети также одинаковые - 19200 8E1. Длина линии в обоих случаях - где-то порядка 5 метров.
Проекты сделаны на STEP7 V5.4, позже перенесён на V5.5.
Проекты делал один человек.
Реализация Modbus RTU - самопальная, авторство неизвестно. Возможно, делал автор проекта, возможно - у кого-то позаимствовал. На форумах саппорта сименсовского подобной реализации не нашёл.
На обеих системах изредка вылезает проблема. "Изредка" значит: уже года три проблема не возникала (и вот опять :) ), до этого - примерно раз в полгода.
Суть проблемы: перестают опрашиваться слейвы по modbus. На модбасовской плате при этом светодиоды не моргают, ни передача, ни приём. На одной из систем помогает перезапуск контроллера отключением/включением питания, но только временно: через несколько часов все повторяется, и через десяток таких перезапусков опрос слейвов прекращается совсем. На другой системе передёргивание питания проблемы не решает. Решается всё кардинальным методом: полной перезаливкой проекта через PLC - > Download. Отдельная перезаливка блоков не помогает, также как и отдельная перезаливка hardware.
Вопрос, собственно: тут могут быть какие-то глюки недокументированные функциональные особенности железа от Siemens или проблема исключительно в криворукости автора программы? В онлайне блоки S_SEND при зависании обмена по всем выходам (DONE, ERROR, STATUS) показывают по нулям. С S_RCV - то же самое, на всех выходах нули.

Сообщение **stesl** » 23 мар 2021, 11:12

О, великий Модбас )
Я все не могу успокоиться после дискуссии в соседней ветке, о величии Модбас и ОРС ))))
Altivar хорошо по Profibus-DP работает.
То что везде 0, наталкивает на мысль, что сам опрос не инициализируется. Может в эту сторону посмотреть? Что там, временная метка? Или какое то событие?

Сообщение **Sergy6661** » 23 мар 2021, 13:01

Очень похоже на то, что в область памяти для буфера приема попадает данных больше чем нужно и как-то что-то перекрывает по соседству потому-как:

VADR писал(а): ↑23 мар 2021, 11:06 Решается всё кардинальным методом: полной перезаливкой проекта через PLC - > Download. Отдельная перезаливка блоков не помогает, также как и отдельная перезаливка hardware.

А остальная система-периферия работает нормально при глюках с модбасом?

Сообщение **VADR** » 23 мар 2021, 21:55

stesl писал(а): ↑23 мар 2021, 11:12 О, великий Модбас )

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

Sergy6661 писал(а): ↑23 мар 2021, 13:01 Очень похоже на то, что в область памяти для буфера приема попадает данных больше чем нужно и как-то что-то перекрывае

Это вряд ли. Динамически память нигде не выделяется, указатели на лету не считаются, вылететь за границы заданных DB не могут. Да и вылетели бы - сработало бы прерывание.

Sergy6661 писал(а): ↑23 мар 2021, 13:01 А остальная система-периферия работает нормально при глюках с модбасом?

Да, всё остальное в порядке.

Сообщение **Sergy6661** » 23 мар 2021, 22:17

Slave какие, и сколько их?

VADR писал(а): ↑23 мар 2021, 21:55 Но тогда возникает вопрос обратный: как оно вообще работает, ведь там сам код так написан? Боюсь, скрины сюда нехорошо вставятся - размер блоков большой.

Вот и я о том же, как правило если код глючный, он глючит с постоянным периодом, или при периодическом условии(но тоже постоянно), а тут что-то не то...
если

VADR писал(а): ↑23 мар 2021, 11:06 В онлайне блоки S_SEND при зависании обмена по всем выходам (DONE, ERROR, STATUS) показывают по нулям. С S_RCV - то же самое, на всех выходах нули.

то типа блок не вызван...Х.З от чего это... порт отвалился, или еще что
И, к стати, насчет прерываний по ошибке, а они прописаны, или просто DB пустой?

Сообщение **VADR** » 23 мар 2021, 23:01

Sergy6661 писал(а): ↑23 мар 2021, 22:17 Slave какие, и сколько их?

В обоих случаях - по два Altivar 71.

Sergy6661 писал(а): ↑23 мар 2021, 22:17 И, к стати, насчет прерываний по ошибке, а они прописаны, или просто DB пустой?

Были пустые OB - удалил, чтобы по ошибке контроллер в стоп ушёл. Детально прописывать времени не было (ночной вызов и всё такое). Но контроллер в стоп не уходил.

Отправлено спустя 1 минуту 13 секунд:
Потом вернул, конечно, когда проект перезалил и всё заработало.

Сообщение **Sergy6661** » 23 мар 2021, 23:32

VADR писал(а): ↑23 мар 2021, 23:03 Потом вернул, конечно, когда проект перезалил и всё заработало.

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

Сообщение **VADR** » 24 мар 2021, 00:32

Sergy6661 писал(а): ↑23 мар 2021, 23:32 А при перезагрузке по питанию ПЛК альтивары тоже перезагружаются?

По-разному делали. Вообще, в этот раз (ранее года три проблем не было) всё началось с перезапуска одного из частотника дежурным электриком (двигатель вставал по перегрузке). Естественно, при оключении частотник перестал отвечать на запросы, а контроллер почему-то перестал их посылать вообще. Потом пробовали в разных вариантах: перезапускали частотники отдельно от контроллера, контроллер отдельно от частотников и всё вместе.

Сообщение **M3f** » 24 мар 2021, 09:59

Был похожи случай, правда с другим оборудованием. Контроллер S7-315-2 PN/DP, три модуля CP 341 RS422/485 (MODBUS RTU) и дюжина AI/AO/DI/DO модулей. Периодически (рандомно раз в 1-5 месяцев) один из модулей просто зависал (светодиоды переставали моргать), по диагностике никаких ошибок, программно реализовано аналогично как на остальных двух. Лечилось только отключением питания или перезаливкой проекта с полным сбросом. Программно пытался словить данный глюк, понял, что проблема не зависит не от устройства, не от программной реализации (зависания происходили полностью рандомно, на разных периодах опроса и при чтении с разных устройств). На линии висело около 20 устройств, а сама линия на данном модуле была короче чем на остальных двух (порядка 15-20 м), но к этому модулю был проброшен и подключен обычный сетевой кабель (докидывался в самом конце, другим подрядчиком). Как удалось выяснить на забугорных форумах, проблема не нова для CP 341 RS422/485, и как многие пишут (даже со ссылкой на офф. представителей), как-то связана с качеством самой кабельной линии (кабель, экран, наводки и прочее). На тот момент не было возможности экспериментировать с кабелем, поэтому проблему решил уменьшением скорости опроса до 9600, активацией режима подавления помех (Interference suppression) и увеличением коэф. задержки времени (Multiplier for character delay time).

Сообщение **VADR** » 24 мар 2021, 12:07

Спасибо, буду иметь в виду. Только когда и как удастся это проверить - пока неизвестно: после перезаливки проекта всё работает и когда заглючить - одному rnd известно.