- Обязательно представиться на русском языке кириллицей (заполнить поле "Имя").
- Фиктивные имена мы не приветствуем. Ивановых и Пупкиных здесь уже достаточно.
- Не писать свой вопрос в первую попавшуюся тему - вместо этого создать новую тему.
- За поиск, предложение и обсуждение пиратского ПО и средств взлома - бан без предупреждения.
- Рекламу и частные объявления "куплю/продам/есть халтура" мы не размещаем ни на каких условиях.
- Перед тем как что-то написать - читать здесь и здесь, а студентам - обязательно здесь.
- Не надо писать в ЛС администраторам свои технические вопросы. Администраторы форума отлично знают как работает форум, а не все-все контроллеры, о которых тут пишут.
Зависание связи по modbus rtu
-
- администратор
- Сообщения: 4734
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 225 раз
- Поблагодарили: 396 раз
Зависание связи по modbus rtu
Приветствую, коллеги.
Есть две системы, сделанные на одной элементной базе одним проектировщиком.
Железо:
Контроллер 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 - то же самое, на всех выходах нули.
Есть две системы, сделанные на одной элементной базе одним проектировщиком.
Железо:
Контроллер 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 - то же самое, на всех выходах нули.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- эксперт
- Сообщения: 1010
- Зарегистрирован: 31 мар 2018, 12:05
- Имя: Вячеслав
- Благодарил (а): 94 раза
- Поблагодарили: 136 раз
Зависание связи по modbus rtu
О, великий Модбас )
Я все не могу успокоиться после дискуссии в соседней ветке, о величии Модбас и ОРС ))))
Altivar хорошо по Profibus-DP работает.
То что везде 0, наталкивает на мысль, что сам опрос не инициализируется. Может в эту сторону посмотреть? Что там, временная метка? Или какое то событие?
Я все не могу успокоиться после дискуссии в соседней ветке, о величии Модбас и ОРС ))))
Altivar хорошо по Profibus-DP работает.
То что везде 0, наталкивает на мысль, что сам опрос не инициализируется. Может в эту сторону посмотреть? Что там, временная метка? Или какое то событие?
-
- read only
- Сообщения: 577
- Зарегистрирован: 19 фев 2019, 22:38
- Имя: Сергей
- Страна: Россия
- город/регион: Краснодар
- Благодарил (а): 17 раз
- Поблагодарили: 77 раз
Зависание связи по modbus rtu
Очень похоже на то, что в область памяти для буфера приема попадает данных больше чем нужно и как-то что-то перекрывает по соседству потому-как:
А остальная система-периферия работает нормально при глюках с модбасом?
-
- администратор
- Сообщения: 4734
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 225 раз
- Поблагодарили: 396 раз
Зависание связи по modbus rtu
Великий или нет - у нас используется. Криво реализовать можно абсолютно любой протокол. Вот я и хочу понять, где кривизна: в софте или в железе. Если в софте - то почему так редко проявляется, а уж если проявляется, то по полной... Есть у меня некоторые сомнения в правильности формирования команды на отправку сообщения - там на входе REQ должен быть передний фронт, а приходит стабильная единица. Но тогда возникает вопрос обратный: как оно вообще работает, ведь там сам код так написан? Боюсь, скрины сюда нехорошо вставятся - размер блоков большой.
Это вряд ли. Динамически память нигде не выделяется, указатели на лету не считаются, вылететь за границы заданных DB не могут. Да и вылетели бы - сработало бы прерывание.
Да, всё остальное в порядке.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- read only
- Сообщения: 577
- Зарегистрирован: 19 фев 2019, 22:38
- Имя: Сергей
- Страна: Россия
- город/регион: Краснодар
- Благодарил (а): 17 раз
- Поблагодарили: 77 раз
Зависание связи по modbus rtu
Slave какие, и сколько их?
если
И, к стати, насчет прерываний по ошибке, а они прописаны, или просто DB пустой?
Вот и я о том же, как правило если код глючный, он глючит с постоянным периодом, или при периодическом условии(но тоже постоянно), а тут что-то не то...
если
то типа блок не вызван...Х.З от чего это... порт отвалился, или еще что
И, к стати, насчет прерываний по ошибке, а они прописаны, или просто DB пустой?
-
- администратор
- Сообщения: 4734
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 225 раз
- Поблагодарили: 396 раз
Зависание связи по modbus rtu
В обоих случаях - по два Altivar 71.
Были пустые OB - удалил, чтобы по ошибке контроллер в стоп ушёл. Детально прописывать времени не было (ночной вызов и всё такое). Но контроллер в стоп не уходил.
Отправлено спустя 1 минуту 13 секунд:
Потом вернул, конечно, когда проект перезалил и всё заработало.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- read only
- Сообщения: 577
- Зарегистрирован: 19 фев 2019, 22:38
- Имя: Сергей
- Страна: Россия
- город/регион: Краснодар
- Благодарил (а): 17 раз
- Поблагодарили: 77 раз
Зависание связи по modbus rtu
Ну по факту к рабочему состоянию возвращаемся после полной очистки памяти.
А при перезагрузке по питанию ПЛК альтивары тоже перезагружаются?
Я с 71ми не работал, но с 31ми при полном управлении по модбасу был геморрой, если альтивар ловит ошибку, то уходит в полный ступор и не отвечает, пока не перезагрузишь по питанию.
-
- администратор
- Сообщения: 4734
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 225 раз
- Поблагодарили: 396 раз
Зависание связи по modbus rtu
По-разному делали. Вообще, в этот раз (ранее года три проблем не было) всё началось с перезапуска одного из частотника дежурным электриком (двигатель вставал по перегрузке). Естественно, при оключении частотник перестал отвечать на запросы, а контроллер почему-то перестал их посылать вообще. Потом пробовали в разных вариантах: перезапускали частотники отдельно от контроллера, контроллер отдельно от частотников и всё вместе.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.
-
- не первый раз у нас
- Сообщения: 377
- Зарегистрирован: 31 янв 2017, 11:08
- Имя: Николай
- Благодарил (а): 8 раз
- Поблагодарили: 116 раз
Зависание связи по modbus rtu
Был похожи случай, правда с другим оборудованием. Контроллер 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).
EPLAN Electric P8 Professional+ 2.7 HF1 11496 | TIA Portal Professional V17 Upd1 | Creo Parametric 4.0 M070
-
- администратор
- Сообщения: 4734
- Зарегистрирован: 25 июл 2008, 07:12
- Имя: Диев Александр Васильевич
- Страна: Россия
- город/регион: г. Сегежа, Карелия
- Благодарил (а): 225 раз
- Поблагодарили: 396 раз
Зависание связи по modbus rtu
Спасибо, буду иметь в виду. Только когда и как удастся это проверить - пока неизвестно: после перезаливки проекта всё работает и когда заглючить - одному rnd известно.
Повторное использование кода не отменяет повторного использования мозга при его повторном использовании.