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

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

Добрый день.

Цитата:

---

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

---

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

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

Цитата:

---

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

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

---

Спасибо, протестирую после праздников.

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

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

Цитата:

---

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

---

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

Цитата:

---

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

---

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

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

Цитата:

---

Сообщение от 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 мс.

Цитата:

---

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

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



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

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

---

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

Цитата:

---

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

---

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

Цитата:

---

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

---

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

Цитата:

---

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

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

---

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

Цитата:

---

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

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

---

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

Цитата:

---

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

---

"Замедление" вызвано использованием внутри OwenCommunication низкоуровневой асинхронной библиотеки CAA SerialCom, которая входит в дистрибутив CODESYS (т.е. это не наша разработка).
По моему опыту - большая часть пользователей в проектах использует что-то еще помимо обмена по Modbus - например, работу со входами-выходами, web-визулизацию, работу с файлами, алгоритмы управления и т.д. Какой смысл разрабатывать библиотеку, которая тормозит все остальные задачи, выполняемые ПЛК - мне не очень понятно.
Но в тех редких случаях, когда это действительно надо (я понимаю, что такое иногда бывает) - можно использовать синхронную SysCom.
Да, для нее нет готовой надстройки с Modbus - нужно будет реализовать протокольную часть самому.
Но специфические задачи часто требуют определенных усилий для их решения.

Выше уже прозвучала фраза про ПЛК110 [М02] - и, думаю, лучше сразу ее прокомментировать (так как рано или поздно, думаю, эта отсылка еще прозвучит) - там низких таймингов удается добиться за счет использования встраиваемой ОС реального времени, в которой реализован только необходимый минимум сервисов.
Поэтому пользователям, которым нужна web-визуализация, OPC UA, работа с HTTP(S)/FTP(S) и т.д., архивация данных - этот контроллер не подойдет.
С другой стороны, если нужен период обмена 30 мс - действительно, лучше использовать его.
Для конкретной задачи подходят конкретные инструменты - это естественно.

Я понемногу вылезаю из комы работы и возвращаюсь к исследованиям. Очень-очень медленно.
И вот ща поигрался со способом, про который пишет Автор темы. Обращение к FB зацикливал по разному.

Вот мои данные:
* Время выполнения задачи опроса - 10 мсек, приоритет = 0
* СПК107, визуализация есть, задействовано все три порта для опросов

Если дёргать вызов FBшки один раз за цикл задачи, то интервалы между опросами получаются 90-100 мсек (даю разброс просто так, по цифрам = 95 мсек)
Загрузка процессора = 60...62%, опрос раз в 5 секунд
Вложение 55416

Если дёргать вызов FBшки десять раз за цикл задачи, то интервалы уже становятся 33 мсек, загрузка проца = 62...64%.
Вложение 55417

Если дальше дёргать по 30 раз, то уже творится ерунда: зафиксировал интервал в 37 мсек, загрузка процессора поднялась до 64...66%.
Вложение 55418

Для меня эти мелочи важны, так как с SysCom я ни фига не понимаю как должно работать и боюсь её напрочь - не работает у меня по ней опрос, хоть упрись.
И исследования показывают что фраза про "Да такое дёрганье OCL поднимет загрузку процессора" не совсем страшная - на 2-4% - это ничего! Ура?

Согласен. ПЛК ОВЕН до сих пор не хватает скорости опроса модулей входов\выходов. Надо все таки подумать, возможно добавить сопроцессор или подобное. Это мешает применять ПЛК для больших и довольно быстрых процессов АСУ ТП. Тот же Segnetics уже создал MTBus, да у них есть свои тонкости, но нужно двигаться в направлении увеличения скорости опросов модулей.

Вопрос как вы читаете, записываете регистры, по одному или по 120 штук разом, во втором случае и 60 мс нормально будет

Цитата:

---

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

Согласен. ПЛК ОВЕН до сих пор не хватает скорости опроса модулей входов\выходов. Надо все таки подумать, возможно добавить сопроцессор или подобное. Это мешает применять ПЛК для больших и довольно быстрых процессов АСУ ТП. Тот же Segnetics уже создал MTBus, да у них есть свои тонкости, но нужно двигаться в направлении увеличения скорости опросов модулей.

---

3 года. Сообщение ниочем. Конкретика?

Цитата:

---

Надо все таки подумать, возможно добавить сопроцессор или подобное.

---

Нафиг не нужно. Здесь про com-порт