Глюки Modbus Master?!

Здравствуйте, уважаемая группа тех. поддержки фирмы Овен.

Прошу Вас помочь понять происходящее с контроллером. При запуске проекта контроллер некоторое время работает (около 8 секунд, может дольше), а затем перезагружается. И так без конца. Причём (!), не зависимо от того, находится он в Run или в Stop. Ради эксперимента я даже удалял свою программу, и ситуация повторялась один к одному. В контроллере сконфигурирован модуль Modbus Master. После некоторого количества экспериментов выяснилось, что перезагрузка контроллера происходит в том случае, если мастеру отвечают. Если ответов от ведомых нет, то перезагрузки не происходит. Обмен идёт через радиомодем. О качестве связи и задержках могу сказать следующее: на тестовой конфигурации через этот канал работала связь по Modbus RTU протоколу. Работало терпимо, но иногда проскакивали таймауты приёма, по этому перевёл связь на Modbus ASCII. К сожалению, не могу сейчас прислать файлы log.txt и debug.txt, если нужно, то пришлю позже.

Прошу Вас просмотреть проект и пояснить, что происходит и как с этим бороться.

Вложение 856

А в ответ тишина...
Видимо, суслик всё-таки есть. :cool:

1.Вероятнее всего, у Вас несовместимы таргеты и прошивка (они идут парой и в логе загрузки есть указание, какую версию таргет-файлов надо использовать).
2. Если версии совпадают, то попробуйте сделать "Standart Configuration" и загрузить на контроллер без программы (например стартовав его с удерживаемой кнопкой Пуск.

1). Прошивка и таргет вчера скачаны и сегодня установлены. Версия 2.05.чего-то-там. Результат - отсутствие результата. Контроллер стабильно отказывается работать и постоянно перезагружается. Если есть связь по Modbus ASCII. Если связи нет (никто не отвечает), то после очередного резета он просто нормально работает. Модуль Modbus Master показывает меняющиеся номера последнего запрошенного ведомого и, естественно, код ошибки 81. Подключаю коммуникационный кабель - через несколько секунд прощальный писк и опять грустное зрелище: контроллер делает рестарт, несколько секунд мигают светодиоды передачи-приёма на радиомодеме, затем жалобный писк и новый рестарт. И т.д.
2). А зачем эти манипуляции? Что бы получить возможность прошить контроллер новой программой? Так для этого, в данном случае, достаточно выдернуть шнур к радиомодему. Слейвы не отзываются и контроллер не глючит. Дальше что???!!!
Мне нужен обмен по Modbus ASCII протоколу! А не описание, как загрузить контроллер без программы...

P.S. Подожду ещё день, может услышу от Вас что полезное?
Проект не работает, моя репутация в глазах людей, нанявших меня на работу, подмочена, командировка просрочена и непонятно, когда закончится (крайний север, кстати). А весёлые ребята из тех. поддержки фирмы Овен учат, как загружать контроллер без программы...

P.S.2. Проект я для чего прикреплял?
Информация для размышления: если оставить только один Universal Modbus Device, то всё устаканивается и работает без глюков. Я оставлял самый верхний, который "ОВЕН ПЛК100 - CPU226", дополнительно перенеся туда "mdbCPU226_analog". Работает нормально.

P.S.3. IMHO - налицо дефект драйвера Modbus Master. Когда много ведомых, и у каждого свой период опроса и "Max timeout" - драйвер оказывается не работоспособен. :mad:

Очень похоже, что у Вас неверно подключено оборудование по интерфейсу RS-485. Проверьте. Если перепутать А и В на одном из опрашиваемых устройств, эффект можеть быть как раз таким, как у Вас - перезагрузки.

Если от наличия или отсутствия загруженной программы в контроллер ничего не меняется, то следующие предположения и предложения:

1. Два первых по порядку Universal Modbus Device имеют одинаковый адрес в сети. Не знаю есть ли в разделении какой-то смысл, но попробуйте слить в один.

2. Попробуйте вычислить при обмене с каким-то конкретным слейвом происходит сбой или не зависит от опрашиваемого адреса. (оставить в PLC Configuration по порядку каждый UMD, а не только поэкспериментировать с первым)

3. Попробуйте чтобы не драйвер рулил опрос, а перейти на опрос устройств по вашей команде из программы (work mode - by command): обмен адрес 1 -> обмен адрес 2 -> обмен адрес 3.

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

1. У Вас в настройках стоит 7-битный режим работы порта, в то-же время ModBus подразумевает 8-битный режим. Кто и как осуществляет трансляцию 7->8 бит и обратно? В нашем мастере такой функции не предусмотрено.
2. Как соединены земли модема и нет ли гальванической связи между землёй Com-порта и нулём/фазой сети?
3. Программа у Вас интенсивно использует указатели и библиотеку SysLibMem. При ошибке их использования вероятность перезагрузки стремится к 100%. Также в 1 цикле ПЛК выполняются, на мой взгляд, слишком много инструкций, как следствие цикл ПЛК не выполняется. Рекомендую разбить на отдельные куски, которые будут выполняться в циклах по очереди. Тем более, что это сделать легко в Вашем случае.

P.S. для исключения влияния пункта 3 попробуйте удалить из проекта всю программу и задавать значения переменных в мастере вручную.

Цитата:

---

Сообщение от xScar2003

Очень похоже, что у Вас неверно подключено оборудование по интерфейсу RS-485. Проверьте. Если перепутать А и В на одном из опрашиваемых устройств, эффект можеть быть как раз таким, как у Вас - перезагрузки.

---

Это можно выяснить последовательно отключая ведомых. Завтра с утра проверю.
Очень прошу пояснить, на основании каких знаний Вы сделали такое предположение. Мои познания в этой области не велики, и я не улавливаю взаимосвязи.

Добрый вечер всем.
Есть проблемма с Modbus-Master.
По RS-485 к ПЛК100 подключены ИП320-slave и корректор ЕК-260. Контроллер видит и читает с обоих устройств нормально, но в программе периодически фиксируется ложные срабатывания кнопок панели. При изучении данного глюка было установлено, что Modbus-Master периодически отправляет данные , считанные с корректора в канал опроса регистров панели. Периодичность сбоя от нескольких секунд до десятка минут. Программку фиксации сбоев прилагаю.

PS. на 485 сидит еще ВКТ7, опрос сделан через UNM, в тесте этот модуль исключен, но физическое подключение осталось.

Нашел ответ в старых темахhttp://www.owen.ru/forum/showthread.php?t=942, действительно ЕК-260 пропускает запросы мастера, и если оставить только его на шине, то с опрсом регистров получается полный бардак, данные распределяются по каналам совершенно случайным образом. Непонятно другое: ИП320 и корректор имеют разные адреса , но Modbus-master не видит, что ответ приходит с другого устройства и не фиксирует ошибку.

Рекомендую для панели выставлять команду 0х04, а для корректора - 0х03

Уважаемый Владислав, год назад подобный вопрос подымался, и вот Ваш ответ

Цитата:

---

Рекомендация такова:
Если вы опрашиваете ряд регистров на 1 устройстве, то чтобы избежать "сдвига данных" желательно либо чередовать команды (например 0x03 и 0х04), либо чередовать опросы устройств. В этом случае при задержке ответа мастер по неверному адресу/команде может идентифицировать такую ситуацию и данные не попадут в соседнюю ячейку.

---

Я обратил внимание на то, что Modbus-master не фиксирует ошибочный адрес в ответе slave-устройства, и как быть в том случае, когда кроме перечисленных устройств на шине появятся еще модули ввода-вывода, у которых тоже будут свои адреса.

Да, адрес в нек-х случая может не детектироваться. В новой пошивке эту функцию реализуем в полном объёме.
Однако и в текущих версиях проблем не возникнет. Главное, чтобы чередовались коды команд при запросвх

У меня сложилось впечатление, что в Modbus-мастере чудес заложено больше, чем во всём остальном контроллере.

Не удивлюсь уже, если возможно возникновение такой ситуации:
Мастер посылает запрос на чтение строки длиной в 200 байт и ждёт ответ. Ответ не пришел в допустимое время. Мастер посылает другой запрос чтения, на этот раз одного регистра. И тут начинает поступать ответ на предыдущий запрос. Мастер принимает его и, т.к. не проверяет адрес отвечающего (CRC хоть проверяет?), то записывает всю 200-байтовую строку в область ввода, начиная с адреса регистра, который он запросил второй командой. Затирая тем самым ячейки памяти, лежащие за этим регистром...
Оценивая свой опыт борьбы с этим чудом, совсем не удивлюсь, если так и будет. Кстати, таким образом можно ведь и содержимое системной памяти повредить (если регистр последний в модуле, а модуль последний в конфигураторе)?

Теперь опишу, как я победил проблему с постоянными перезагрузками контроллера, описанную в начале ветки.
Всё просто. Против лома нет приёма. Модуль Modbus-мастер был удалён из конфигурации контроллера. А затем в течении пяти дней была написана и отлажена библиотека, реализующая команды 3 и 16 Modbus ASCII мастера. И всё.
Вся аппаратная конфигурация осталась прежней. Абсолютно. Те же радиомодемы. Те же ведомые. Те же физические подключения.
Более того. После завершения отладки библиотеки я продолжил дорабатывать основную программу. И она выросла ещё где-то на треть. И никаких проблем. Никаких резетов по watchdog. Стреляет очередями запросов и не спотыкается.
Так что ищите суслика в своём драйвере. А то и не одного.

P.S. А для себя пришлось сделать вывод: модуль Modbus Master для ПЛК100 не существует. То что имеется на данный момент - это не продуманное и не прошедшее тестирования НЕЧТО, способное работать лишь в самых простых конфигурациях.
P.S. А про надёжность модуля Modbus Slave плохого сказать нечего. Нормально работает. Быстрее бы ему доработали конфигуратор. Очень много времени отнимает нынешний, если переменных много.

Цитата:

---

Сообщение от Serj_N

У меня сложилось впечатление, что в Modbus-мастере чудес заложено больше, чем во всём остальном контроллере.

Не удивлюсь уже, если возможно возникновение такой ситуации:
Мастер посылает запрос на чтение строки длиной в 200 байт и ждёт ответ. Ответ не пришел в допустимое время. Мастер посылает другой запрос чтения, на этот раз одного регистра. И тут начинает поступать ответ на предыдущий запрос. Мастер принимает его и, т.к. не проверяет адрес отвечающего (CRC хоть проверяет?), то записывает всю 200-байтовую строку в область ввода, начиная с адреса регистра, который он запросил второй командой. Затирая тем самым ячейки памяти, лежащие за этим регистром...
Оценивая свой опыт борьбы с этим чудом, совсем не удивлюсь, если так и будет. Кстати, таким образом можно ведь и содержимое системной памяти повредить (если регистр последний в модуле, а модуль последний в конфигураторе)?

Теперь опишу, как я победил проблему с постоянными перезагрузками контроллера, описанную в начале ветки.
Всё просто. Против лома нет приёма. Модуль Modbus-мастер был удалён из конфигурации контроллера. А затем в течении пяти дней была написана и отлажена библиотека, реализующая команды 3 и 16 Modbus ASCII мастера. И всё.
Вся аппаратная конфигурация осталась прежней. Абсолютно. Те же радиомодемы. Те же ведомые. Те же физические подключения.
Более того. После завершения отладки библиотеки я продолжил дорабатывать основную программу. И она выросла ещё где-то на треть. И никаких проблем. Никаких резетов по watchdog. Стреляет очередями запросов и не спотыкается.
Так что ищите суслика в своём драйвере. А то и не одного.

P.S. А для себя пришлось сделать вывод: модуль Modbus Master для ПЛК100 не существует. То что имеется на данный момент - это не продуманное и не прошедшее тестирования НЕЧТО, способное работать лишь в самых простых конфигурациях.
P.S. А про надёжность модуля Modbus Slave плохого сказать нечего. Нормально работает. Быстрее бы ему доработали конфигуратор. Очень много времени отнимает нынешний, если переменных много.

---

Спасибо за замечание. Такое поведение возможно, стандарт не определяет поведение мастера в таком случае. Добавим доп. проверку.

Также поделюсь своим опытом последнего общения с Modbus.
ПЛК154 (Master) - ИП320 (Slave) - МДВВ - МВА.
Прошивка 2.06.3.
Загружаю проект в контроллер. Смотрю в online на PLC Configuration, всё хорошо, Modbus master работает с подчиненными, ошибки обмена возникают редко, в основном при работе с ИП320. Период опроса 400мс, 100-150мс время ожидания ответа, естественно чередуем команды 0x03, 0x04 при опросе регистров ведомых, в общем, все для надёжности из лучших рекомендаций форума.
Запускаю выполнение программы. Обмен с подчиненными останавливается, мастер выдает код ошибки 81 (нет ответа), лампы индикации обмена по интерфейсу на МВА и МДВВ не моргают. Ну, думаю, залепуха какая-то в программе, все гляделки проглазел, с областью конфигурации ввода/вывода никаких непотребных действий не выполняю. Программа написана на LAD со своими маленькими ФБ на ST, приблизительно 100 строк, где самые тяжелые позиции - это 4 ФБ ПИДа.
Останавливаю выполнение программы и все становится в порядке с обменом.
С программой в режиме СТОП каши не сваришь, поэтому рассудил так.
Отчего-то сам факт выполнения программы мешает нормальной работе элементов, заложенных в конфигурации. Может ядро с новой прошивкой, в котором "существенно уменьшен цикл выполнения программы" стало меньше выделять времени на элементы конфигурации. Посмотрел -цикл выполнения программы 0,7-1,1 мс. Короче, решил разгрузить процессор контроллера от бесконечно быстрого выполнения моего алгоритма, мне достаточно будет 20мс. Полез в Task configuration, зарядил выполнение моей программы через задуманный интервал и спустя минутку всё заработало без проблем.

Может кто-нибудь из разработчиков сделать предположение, почему проект не заработал в своем исходном исполнении без сконфигурированной в Task configuration задачи на 20мс?

Добрый день.
Столкнулся с такой проблемой: на ПЛК100 при попытке связаться по Модбас RTU с МДВВ(да и вообще с любым слэйвом) контроллер перезагружается. Если в "Конфигурации ПЛК" Подключить модуль модбас мастер и оставить его пустым (не добавлять никаких опрашиваемых регистров) то контроллер исправно работает, но если добавить хотя бы один регистр, то контроллер после загрузки программы перезагружается, секунды, этак, через полторы. Это происходит при любых настройках протокола, скорости, наличии/отсутствия слэйва(тобишь ответа от него), за исключением режима Work mode: если врок мод By command, то перезагрузка наступит, соответственно по команде.
Перед перезагрузкой контроллер выдаёт необъяснимый запрос по указанному каналу связи, например при подключении готового модуля OWEN_MDVV контроллер пишет (хекс) 10 03 00 49 00 01 56 9D. Собственно пытается получить данные десятого счётчика входа.

Версия прошивки 2.10.9
таргет файл версии 2.10

у вас, вероятно, контроллер с аппаратной ошибкой. надо допаять резистор. описание как и куда допаивать - есть на форуме.
если это не так - пришлите проект, посмотрим.

если я правильно понял, то речь идёт про подтягивающий резистор к Adm485?

но проблема не изчезает при использованнии 232го.

Допаял резистор между 1 и 8 ногой Adm485, сначала 10 кОм, ситуация не изменилась, потом 5 кОм, и опять же, ничего не изменилось.

Цитата:

---

если это не так - пришлите проект, посмотрим

---

Ну проэкт например такой. С ним контроллер перезагружается через некоторое время (секунды).Вложение 2467

жду ответа

Вы точно уверены что стоит таргет 2.10? удалите его и поставьте заново при выключенном CoDeSys.
И сделайте проект заново.

Точно уверен

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

PLCInfo
PLC model MODEL PLC 100
Binary VERSION 2.12.4
Need Target version 2.10
Compiled: 17:53:12 Jun 4 2010
MAC 6A:77:00:00:4E:A0
IP 10.0.6.10
GATE 10.0.6.1
MASK 255.255.255.0
PIC upper version is 07
Licence unlimited
No DAC
PIC lower version is 0a

НИЧЕГО НЕ ИЗМЕНИЛОСЬ
что делать?