Работа MODBUS-RTU через библиотеку OwenCommunication

Вид для печати

Показывать 40 сообщений этой темы на одной странице

30.04.2021, 12:01
_Pavel_

Работа MODBUS-RTU через библиотеку OwenCommunication

Здравствуйте!
Пытаемся внедрить библиотеку OwenCommunication для организации обмена через интерфейс RS485 по протоколу MODBUS-RTU на ПЛК210.
Заметили, что при выполнении запроса чтения параметра скорость опроса зависит от количества вызовов соответствующего функционального блока запроса (MB_SerialRequest).
То есть: если вызывать MB_SerialRequest один раз за цикл ПЛК - то при цикле 5мс - частота опроса получалась 40 мс, при цикле ПЛК 10 мс - частота опроса - 80 мс.
Потом провели эксперимент (костыль): стали вызывать MB_SerialRequest несколько раз подряд в одном цикле ПЛК - и (О, чудо!) время опроса уменьшилось.
Сделали вывод: библиотека работает не оптимально, то есть появление флага завершения транзакции xDone - требует обязательно определённого количества вызовов ФБ MB_SerialRequest, независимо от того что физически ответ от SLAVE устройства был уже был получен.
Подскажите, пожалуйста, либо мы где-то ошибаемся (подскажите где?), либо можно как-нибудь оптимизировать работу библиотеки?
30.04.2021, 12:04
Евгений Кислов

Добрый день.

Цитата:

Потом провели эксперимент (костыль): стали вызывать MB_SerialRequest несколько раз подряд в одном цикле ПЛК - и (О, чудо!) время опроса уменьшилось.

Сделайте, пожалуйста, простейший тестовый проект с обоим вариантами опроса (с одним вызовом ФБ в цикле и несколькими).
30.04.2021, 14:19
_Pavel_

Отправил вам на почту проекты. Надеюсь она примет 120 мб...
30.04.2021, 14:26
Евгений Кислов

Цитата:

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

Отправил вам на почту проекты. Надеюсь она примет 120 мб...

Спасибо, протестирую после праздников.
01.05.2021, 10:50
Cs-Cs

О! Интересная мысль. Подпишуь на тему.
У меня по 70 мсек получались задержки опросов на этой либе. Но я вызывал по разу за цикл. Вот тут расписывал: https://owen.ru/forum/showthread.php...l=1#post345831

_Pavel_ А можно чуток подробностей? Сколько модулей IO опрашивается?
Как были сделаны костыли? А то мне видится что-то типа FOR ... 1 TO 10... =)
11.05.2021, 07:46
Евгений Кислов

Цитата:

Подскажите, пожалуйста, либо мы где-то ошибаемся (подскажите где?), либо можно как-нибудь оптимизировать работу библиотеки?

Я бы не сказал, что вы где-то ошибаетесь. Ваш вариант использования (с вызовом ФБ в цикле FOR) в определенной степени "подавляет" асинхронную модель выполнения библиотеки.
За счет этого вы, с одной стороны, получаете "более быстрый" обмен, а с другой - увеличиваете время цикла вашей задачи (особенно ярко это будет проявляться при обрыве линии связи, когда начнут срабатывать таймауты).

Цитата:

библиотека работает не оптимально

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

В тех специфических задачах, где нужна очень высокая частота опроса (когда принципиальны десятки или даже единицы миллисекунд) - можно использовать синхронную библиотеку SysCom.
12.05.2021, 13:06
_Pavel_

Цитата:

Сообщение от Cs-Cs

О! Интересная мысль. Подпишуь на тему.
У меня по 70 мсек получались задержки опросов на этой либе. Но я вызывал по разу за цикл. Вот тут расписывал: https://owen.ru/forum/showthread.php...l=1#post345831

_Pavel_ А можно чуток подробностей? Сколько модулей IO опрашивается?
Как были сделаны костыли? А то мне видится что-то типа FOR ... 1 TO 10... =)

Да, сперва мы именно так и поступили: FOR ... 1 TO 10... но благодаря многочисленным экспериментам удалось выявить наиболее оптимальный способ использования ФБ MB_SerialRequest, а именно: после того как предыдущий запрос выполнен, то есть MB_SerialRequest установил флаг xDone, необходимо в этом же цикле ПЛК трижды продёрнуть ФБ MB_SerialRequest с новыми параметрами запроса, или с теми же, если это поллинг одного устройства. Таким образом получается максимальная скорость опроса, сравнимая с ПЛК 110 М02. Например, удалось достичь периода опроса одного модуля на скорости 115200 - 15 мс, при времени цикла ПЛК 5 мс.
12.05.2021, 13:15
_Pavel_

Цитата:

Сообщение от Евгений Кислов

Я бы не сказал, что вы где-то ошибаетесь. Ваш вариант использования (с вызовом ФБ в цикле FOR) в определенной степени "подавляет" асинхронную модель выполнения библиотеки.
За счет этого вы, с одной стороны, получаете "более быстрый" обмен, а с другой - увеличиваете время цикла вашей задачи (особенно ярко это будет проявляться при обрыве линии связи, когда начнут срабатывать таймауты).

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

В тех специфических задачах, где нужна очень высокая частота опроса (когда принципиальны десятки или даже единицы миллисекунд) - можно использовать синхронную библиотеку SysCom.

Я с Вами не могу согласиться. Насколько показывают наши испытания - библиотека работает именно неоптимально. Какой смысл в 3-х кратном продёргивании запроса в одном цикле ПЛК? И разве скорость опроса не является одним из главных критериев оптимальности работы библиотеки, да и и контроллера в целом? А если количество модулей на RS485 будет большое? Причём при срабатывании таймаутов мы не заметили каких-либо проблем (при использовании нашего, вышеизложенного способа применения библиотеки)
Да, она достаточно удобна в использовании - вопросов нет.
Я в свое время потому и не перешёл на ПЛК210, потому что увидел слишком высокие тайминги опроса по сравнению с ПЛК110 М02. Однако, как оказалось ПЛК может больше)
12.05.2021, 13:39
Евгений Кислов

Цитата:

Какой смысл в 3-х кратном продёргивании запроса в одном цикле ПЛК?

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

Цитата:

А если количество модулей на RS485 будет большое?

Т.е. проектировщик системы, понимая, как важна в рамках конкретной задачи скорость опроса использовал для обмена последовательный интерфейс.
Вероятно, стоит переадресовать этот вопрос ему.
12.05.2021, 19:34
_Pavel_

Цитата:

Сообщение от Евгений Кислов

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

Евгений, я могу доказать что дело не в "зайти попозже", то есть не во времени, а именно в количестве вызовов ФБ. Вот только что ещё раз проделали эксперимент: один slave, 115200, читаем один регистр, время цикла 10 мс, один вызов ФБ за цикл - результат период обмена 80 мс. Далее - все те же условия, но продёргиваем ФБ по три раза в каждом цикле - результат - 30 мс. Вы считаете это нормальное поведение? Вычитывание в цикле буфера занимает несравнимо малое время, меньше 0,5 мс.

Цитата:

Сообщение от Евгений Кислов

Т.е. проектировщик системы, понимая, как важна в рамках конкретной задачи скорость опроса использовал для обмена последовательный интерфейс.
Вероятно, стоит переадресовать этот вопрос ему.

Вы говорите всё правильно, но тут вопрос в другом: какой смысл намеренно замедлять свою железку?

Показывать 40 сообщений этой темы на одной странице