Конфигуратор vs modbus.lib

[Спорягин Кирилл]

Добрый день, уважаемые форумчане.

Предложенная мною тема уже ни раз обсуждалась на форуме. Например:
1. Преимущества работы с портом с помощью библиотек
2. Эксплуатация библиотеки modbus.lib
3. МВ110-16Д modbus.lib
4. Примеры работы с приборами ОВЕН имеющими интерфейс RS-485

Все же, как мне кажется, некоторые моменты остаются не определены.
Сразу оговорюсь, что я сейчас говорю о ситуации, когда контроллер выступает в роли Modbus Masterа.

1. В ссылках [1] и [2] говориться, что опрос с помощью библиотеки дает преимущества в случае, если количество опрашиваемых модулей велико. Но нигде нет количественных характеристик.

Вопросы:
1.1 При каком количестве модулей опрос через библиотеку будет заметнее быстрее, чем через конфигуратор?
1.2 Хотелось бы знать экспертную или опытную оценку периода опроса 10 модулей ввода/вывода через конфигуратор и через библиотеку. Для определенности пусть это будут: 4 модуля МВ110-8АС, 3 модуля МВ110-32ДН и 3 модуля МУ110-32Р (опрос только измерений).

2. Все найденные мною примеры использования библиотеки (например, [3, 4]) показывают как использовать функциональные блоки из библиотеки, но я нигде не смог найти описания или рекомендаций по организации структуры вызовов. Поясню более подробно.
Пусть у меня есть главная и единственная программа - PLC_PRG. В ней последовательно расположены вызовы ФБ для опроса модулей и за ними ФБ логики управления объектом (подразумевается язык ST). При вызове ФБ опроса модулей я проверяю выход Complite у библиотечных ФБ, который показывает, что опрос модуля завершен. Только после этого я могу переходить к опросу другого модуля. Фактически это означает, что для опроса 10 модулей мне нужно как минимум 10 циклов программы PLC_PRG. В этом случае может быть следующая неприятность. Если по результатам опроса первого модуля ФБ логики управления объектом выдал управляющие воздействия, которые должны быть переданы на исполнительные механизмы с помощью десятого модуля, то получиться, что 9 циклов управляющие воздействия будут выработанны, но не переданы на модуль вывода, что замедляет время реакции системы.
Поэтому представляется правильным вынести опрос модулей в отдельную программу (и задачу), исполнение которой осуществлять чаще, чем исполнение логики управления. Причем частота исполнения опроса модулей должна быть в N раз больше частоты исполнения логики объекта, где N - количество модулей.

Вопросы:
2.1 Приведите примеры организации опроса модулей ввода/вывода с использованием modbus.lib;
2.2 Как ведет себя конфигуратор при опросе модулей? С ним не получается такой неприятности как описана выше?

[Yegor]

1. Главная проблема конфигуратора по части тайминга — невозможность определить момент получения данных. Отсюда вытекает невозможность эффективно планировать опрос. И это вне зависимости от числа модулей.
С другой стороны, те же МВ110-8А (не знаю насчёт «АС») у меня начинали затыкаться когда я пытался опрашивать их с периодом менее 15 мс при помощи своей программы на компе (на базе NModbus, скорость вроде была 38400 RTU), поэтому в оптимизации опроса может просто не быть смысла из-за самих модулей.

Если планирование опроса вообще ограничить только выставлением периодов в конфигураторе и не использовать модули __state с ручным управлением (и прочие хитрости), то опрос получается сильно неравномерным уже в пределах дюжины слейвов.

2. 10 циклов не слишком загруженного ПЛК110 это совсем небольшая задержка на самом деле, если рассмотреть общее время реакции. К тому же вы всё равно пишете в буфер системы, а она сама решает, когда это отправить.

Я особо не пользовался modbus.lib. Больше приходилось поддерживать нестандартные протоколы, в том числе где читать надо как можно чаще. И естественно, быстрее всего отправлять очередной запрос сразу после получения ответа. Но с каждым новым устройством этот подход надо проверять, т.к. некоторым нужна пауза.

Конфигуратор довольно глупый. Он просто перебирает узлы составленного вами дерева по таймеру. Сильно запинается, если таких таймеров несколько. Смежные регистры один фиг читает по одному. Поэтому стоит попробовать вручную давать команды и читать регистры группами при помощи модуля string, например.

[Филоненко Владислав]

1. Главная проблема конфигуратора по части тайминга — невозможность определить момент получения данных. Отсюда вытекает невозможность эффективно планировать опрос. И это вне зависимости от числа модулей.

Странно, а мы как-то считали время опроса Х параметров N-модулей именно через конфигуратор. И момент прихода ответа там виден ясно, по адресу и статусу. (но не на глаз , а при обработке в ПО) Глаз 1 мс не улавливает
А для контроля порядка опроса можно использовать режим по команде.

[Спорягин Кирилл]

Странно, а мы как-то считали время опроса Х параметров N-модулей именно через конфигуратор. И момент прихода ответа там виден ясно, по адресу и статусу. (но не на глаз , а при обработке в ПО) Глаз 1 мс не улавливает
А для контроля порядка опроса можно использовать режим по команде.

Владислав, а можно уточнить величины Х и N?
Правильно ли я понимаю, что опрос указанного количества модулей был у Вас в районе 1 мс?

[Scream]

Владислав, а можно уточнить величины Х и N?
Правильно ли я понимаю, что опрос указанного количества модулей был у Вас в районе 1 мс?

Про глаз перебор. Еслиб захотел увидеть Владислав, то и не смог т.к. codesys не обновляется с такой частотой не через usb не через ethernet.
---------------
Вот и у меня претензия к конфигуратору.
Если я опрашиваю модуль с 2мя регистрами с частотой 100 мс, то фактически получается каждый регистр обновляется раз в 200мс, хотя если они стоят рядом друг с другом то можно былоб преминить функцию модбас группового запроса на что ушло намного меньше времени, в даном случае в 2 раза и регистры обновлялись раз в 100 мс. Конфигуратор туп.

[Спорягин Кирилл]

Вот и у меня претензия к конфигуратору.
Если я опрашиваю модуль с 2мя регистрами с частотой 100 мс, то фактически получается каждый регистр обновляется раз в 200мс, хотя если они стоят рядом друг с другом то можно былоб преминить функцию модбас группового запроса на что ушло намного меньше времени, в даном случае в 2 раза и регистры обновлялись раз в 100 мс. Конфигуратор туп.

Эту проблему можно отчасти решить используя для опроса string переменные см. тут - http://www.owen.ru/forum/showthread.php?t=21799

[Sashokxxx]

Я особо не пользовался modbus.lib. Больше приходилось поддерживать нестандартные протоколы, в том числе где читать надо как можно чаще. И естественно, быстрее всего отправлять очередной запрос сразу после получения ответа. Но с каждым новым устройством этот подход надо проверять, т.к. некоторым нужна пауза.

Сейчас присматриваюсь к СПК, чтобы перевести на него контроль некими устройствами, в том числе и с нестандартными протоколами обмена. Вы написали что имеете опыт в этом. Не могли бы поделится примером опроса подобных устройств?

[Спорягин Кирилл]

1. Главная проблема конфигуратора по части тайминга — невозможность определить момент получения данных.

Если я правильно понимаю, такая же проблема и при использовании библиотеки. Я ведь должен на каждом скане проверять переменную Complite. У меня нет возможности создать событие, которое вызовет мой обработчик, когда придут данные. Поэтому и нужно, на мой взгляд, выносить опрос модулей в отдельную задачу, которая будет циклически вызываться как можно чаще.

С другой стороны, те же МВ110-8А (не знаю насчёт «АС») у меня начинали затыкаться когда я пытался опрашивать их с периодом менее 15 мс при помощи своей программы на компе (на базе NModbus, скорость вроде была 38400 RTU), поэтому в оптимизации опроса может просто не быть смысла из-за самих модулей.

Здесь мне не понятно, почему модули начали затыкаться? Какая им разница с какой частотой их опрашивают? Другое дело, что если у МВ110-8А внутренний период обновления данных в районе 600 - 900 мс на канал (согласно руководства по эксплуатации модулей), то эти модули опрашивать чаще нет смысла (под внутренним периодом опроса я подразумеваю время с какой частотой физические измерения на входах преобразуются в данные, располагающиеся в регистрах Modbus модуля). И это можно учесть при организации опроса. Но вот для модулей МВ110-8АС внутренне время опроса одного канала - 5 мс. А для модулей дискретного ввода/вывода, частота обновления данных измеряется долями мс. Поэтому их опрашивать имеет смысл чаще. Это все можно и нужно учитывать при организации опроса.
Для этого в конфигураторе есть величина Polling time. В случае работы с библиотекой за этим нужно следить самостоятельно.

[capzap]

Если я правильно понимаю, такая же проблема и при использовании библиотеки. Я ведь должен на каждом скане проверять переменную Complite. У меня нет возможности создать событие, которое вызовет мой обработчик, когда придут данные.

так положительное состояние Complite это и есть условно время окончания периода,затраченного на опрос одного устройства.
Вопрос почему это у Вас нет возможности создать событие?

[Спорягин Кирилл]

так положительное состояние Complite это и есть условно время окончания периода,затраченного на опрос одного устройства.

Разница только в том, что не меня зовут, сообщая что работа сделана, а я каждый раз спрашиваю: "Как закончил?".

Вопрос почему это у Вас нет возможности создать событие?

Тут поподробней. Я кажется что-то пропустил? Не знаю как создать событие в CDS.
Настроить конфигуратор задач - не предлагать - это не то.