PDA

Просмотр полной версии : МВА 8. Максимальная задержка ответа?



Владимир Чекин
31.03.2009, 17:15
Кирилл, названная Вами цифра 50мс в теме http://www.owen.ru/forum/showpost.php?p=10787&postcount=9 требует более официального исследования и уточнения. Я прекрасно понимаю, что не Вы сами её придумали, а Вам она была названа специалистами. Но звучили её Вы и поэтому к Вам я и обращаюсь персонально. Неточность этой цифры привела к интересному подводному камню при эксплуатации системы.

Далее очень долго и нудно. Сорри, по-короче не удалось.

Состав системы: контроллер собственного производства, два МВА8, два МВУ8. Шина RS-485, скорость 19200, Modbus RTU. Датчики давления и термосопротивления тоже ОВЕН. Контроллер - мастер, остальные - слейвы. С МВУ8 проблем нет. А вот о входах чуть подробнее. Контроллер циклически опрашивает входные модули по-канально, т.е. в одном запросе к МВА8 читаются 4 байта (2 байта результата и 2 байта код ошибки). Внутри одного модуля каналы читаются последовательно. Модули опрашиваются поочерёдно. Приём посылок в программе контроллера обвешал контролем максимально: контроль CRC пакета, контроль количества байт в пакете ответе, сравнение адреса модуля в ответе с адресом из запроса, сравнение значения регистра "Число байт" в информационной части самой посылки. Только после прохождения всех проверок результат измерения канала признаётся достоверным и переписыается из приёмного буфера во внутренние регистры программы. Для каждого канала заведён счётчик ошибок связи, при возникновении ошибки счётчик инкрементируется, при положительном результате декрементируется. При превышении определенного числа ошибок генерится авария по связи. Т.е. однократные нерегулярные ошибки не приводят к затыканию системы.

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

В момент аварии система фиксирует код ошибки и величину параметра, вышедшего за диапазон.
Собрал статистику "аварийных" случаев и стал анализировать. Результат анализа: значения "сбойных" параметров равны результату соседнего канала. Естественно, первым делом проверил саму программу контроллера, контроль приёма пакетов - всё чисто. А потом осенило: алгоритм общения с модулями у меня построен так: запрос, ожидание ответа 3.5Т + 60мс (я сознательно увеличил названную мне цифру), если нет ответа, счётчик ошибок +1, и после паузы 3.5Т делается следующий запрос и т.д. И теперь подводный камень: в структуре ответа слейва на команду 03 и 04 в Modbus RTU нет информации об адресе регистра присланных данных, а только адрес модуля. Поэтому при "перехлёстывании" ответов при опросе соседних каналов в пределах одного модуля проблем не будет никогда: число байт ответа сходится, CRC сходится, адрес модуля в запросе и ответе одинаков. Как этот "перехлёст" может происходить? Прихожу к заключению, что если величина задержки ответа от слейва составляет более 50мс и этот задержавшийся ответ попадает во временной слот ожидания ответа от уже запрошенного следующего канала, то вот тут-то и происходит этот "перехлёст".

Я переделал последовательность опроса модулей, т.е. поочерёдно опрашиваю канал с одного модуля МВА8, отсылаю данные в канал на МВУ8 и т.д., чтоб в соседних ответах принципиально были разные адреса модулей и разное число байт в пакетах. И если описанный "перехлёст" произойдёт, то при проверке пакета это должно не сойтись по двум критериям. Вроде зажило, "аварии" перестали появлятся.

Так что вот... очень жажду ответа от фирмы ОВЕН :) Вопрос, а почему этот довольно принципиальный для построения канала связи параметр отсутствует в документации прибора?

Kirill
01.04.2009, 11:11
Так что вот... очень жажду ответа от фирмы ОВЕН :) Вопрос, а почему этот довольно принципиальный для построения канала связи параметр отсутствует в документации прибора?

Не совсем ясно, какой же параметр вы имели в виду? Rs.dL - задежку ответа по сети?

Владимир Чекин
01.04.2009, 13:25
Не совсем ясно, какой же параметр вы имели в виду? Rs.dL - задежку ответа по сети?
Нет, не её. Забыл упомянуть в предыдущем послании, что в приборах стоит Rs.dL=1мс.

Может я путанно изъясняюсь... Другой вариант:

Параметр Rs.dL - это фиксированная пауза, программируемая через конфигуратор, которую слейв обязан выдержать перед выдачей ответа, а затем должен начать выдавать ответ. Но это в теории, это описано в документации и соответсвенно такой информацией обладает служба поддержки. Но практика показывает, что эпизодически МВА8 в независимости от значения параметра Rs.dL задерживает ответ на 50 и более мс. Описанный мной случай - частное проявление этого явления.

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

PS: Кстати, кстати... Речь об этом мной уже подымалась http://www.owen.ru/forum/showthread.php?p=10861, но ответа тогда, увы, я так и не получил. Но в том эксперименте я игрался только с одним модулем и не оценивал содержание ответов, поэтому не сразу понял опасности, которую несёт недокументированная задержка ответа.

Малышев Олег
01.04.2009, 13:39
Параметр Rs.dL - это фиксированная пауза, программируемая через конфигуратор, которую слейв обязан выдержать перед выдачей ответа, а затем должен начать выдавать ответ.
На самом деле не затем должен начать выдавать ответ а не позже 50 мс ответить. Т.е. таймаут = Rs.dl+50 - Это таймаут начала ответа. После окончания запроса можно выдавать следующий

Владимир Чекин
01.04.2009, 13:50
На самом деле не затем должен начать выдавать ответ а не позже 50 мс ответить. Т.е. таймаут = Rs.dl+50 - Это таймаут начала ответа. После окончания запроса можно выдавать следующий

Прошу прощения, Вы разработчик Овен или пользователь? Это важно для понимания достоверности приводимой Вами информации.

Вы написали тоже самое, что мне отвечал Кирилл в том году. На основании этой инфы я реализовал опрос и напоролся на проблему.

Ещё раз, на практике установлено, что МВА8 задерживает ответ более чем на "Rs.dl+50".

Владимир Чекин
06.04.2009, 13:24
Кирилл, вопрос по Вашей (надеюсь не ошибся) статье в АиП №2 (2008) - "Подключение модулей к ПЛК".

Цитата из раздела "Конфигурация ОВЕН ПЛК": "Настроим параметр максимальной задержки ответа от модуля. Для этого необходимо выделить Owen (Master)[VAR] (рис. 3), в окне слева выбрать вкладку Module Parameters. В колонке Value для параметра Max Response Delay ms задайте значение не менее 200 мс."

Вопрос: на основании каких соображений дана эта рекомендация?

Малышев Олег
06.04.2009, 15:14
Еще раз, после беседы с разработчиком, rs.dl = таймаут ответа НЕ МЕНЕЕ. Это необходимо для медленных приборов. Которые не могут воспринять ответ быстрее заданного времени.

Ещё раз, на практике установлено, что МВА8 задерживает ответ более чем на "Rs.dl+50".

По итогам тестирования среднее время ответа =rs.dl+5 ms.

Владимир Чекин
06.04.2009, 17:49
Еще раз, после беседы с разработчиком, rs.dl = таймаут ответа НЕ МЕНЕЕ. Это необходимо для медленных приборов. Которые не могут воспринять ответ быстрее заданного времени.

По итогам тестирования среднее время ответа =rs.dl+5 ms.
Ясно. В качестве резюме: радует, что всё таки по сигналу юзера "разбор полётов" был сделан. Спасибо. То что не подтвердилась моя гипотеза - это тоже информация. Хотя мои решения, сделанные на основе этой гипотезы, решили проблему. Будет передышка между проектами, сваяю стендик, поиграюсь поплотнее. Вопрос: с кем связаться напрямую?

PS: Олег, не обижайтесь по поводу моего вопроса "ху из ху". Я не сижу в конфе постоянно и действительно этого не знаю, в статусе написано "Пользователь", а пользователи бывают разные.

В качестве предложения: может официальных людей Овена как-то выделить в конфе отличным от "Пользователь" статусом, чтоб статус их ответов был понятен изначально.

Малышев Олег
06.04.2009, 20:54
Есть смутное подозрение, что многие помеченные здесь скромным словом "пользователь" в высшей степени компетентные люди :) :) :).
Что касается меня - какие обиды - рад был помочь :)
Насчет обратной связи - желательно все же через тех.поддержку.