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

[Евгений Кислов]

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

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

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

[Cs-Cs]

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

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

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

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

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

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

[mva2204]

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

[kondor3000]

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

[Валенок]

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

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

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

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