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

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

Да бы не отвлекаться на филосовские дискуссии о "событиях" попробую конкретизировать рассуждения. А опытные пользователи ПЛК и разработчики пусть укажут на ошибки, неточности и слабые места в них.

Условия задачи оставим прежними - опросить 10 модулей ввода/вывода: 4 модуля МВ110-8АС, 3 модуля МВ110-32ДН и 3 модуля МУ110-32Р (опрос только измерений). Для определенности примем, что опрос ведется на скорости 115200 бит/сек.

Рассмотрим возможный вариант опроса через modbus.lib.
Создадим некие ФБ для каждой разновидности модулей. В этих ФБ используем блоки MB_RD_HOLD_REGS и MB_WR_REGS для записи и чтения регистров. Для каждого модуля в системе создаем свой экземпляр. Вызов этих экземпляров осуществляем последовательно в некоторой программе, назовем ее Module_PRG, которую поместим в задачу, выполняющуюся циклически с неким периодом.
Первое, что хочется понять каков должен быть период вызова Module_PRG? Как я понимаю он должен быть таким, чтобы между 2-мя последовательными вызовами система успевала отправить запрос модулю и получить ответ. Для этого рассчитаем время требуемое для пересылки запроса и ответа на него по сети Modbus при скорости 115200 кбит/сек. Будем исходить из потребностей аналогового модуля. Запрос включает: адрес уст-ва (1 байт) + номер функции (1 байт) + адрес регистра (2 байта) + кол-во регистров (1 байт) + CRC (2 байта) = 7 байт. Ответ включает: адрес уст-ва (1 байт) + номер функции (1 байт) + данные в int (16 байт) + CRC (2 байта) = 20 байт. Итого передать по сети туда-обратно нужно 27 байт. На скорости 115200 бит/сек для этого необходимо: 27*8/115200 = 0,0019 секунды или 1,9 мс. Добавим к этому времени возможные неучтенности (пауза, стоповые биты и прочее) в размере 2 мс. Или даже еще более осторожно - в руководстве по эксплуатации ПЛК 110-160 диапазон значений Pooling Time 10 - 1000 мс - примем за достаточную (с большим запасом) величину периода опроса одного модуля - 10 мс. Тогда получается период вызова программы Module_PRG должен составлять 10 мс. А весь цикл опроса 10-ти модулей 100 мс.
Главную программу PLC_PRG в этом случае следует вызывать раз в 110 мс, например.
Возможно ли достижения таких скоростей опроса с использованием библиотеки Modbus.lib?

Опрос через конфигуратор.
Теперь умозрительно создадим аналогичную сеть в конфигураторе. Для опроса аналоговых модулей будем использовать, уже указанный мною выше, прием с переменными String.
Создадим для каждого физического модуля соответствующий Universal Modbus Device и зададим им Pooling Time = 10 мс.
Какой период опроса должен получиться в этом случае в конфигураторе?

[capzap]

Запрос включает: адрес уст-ва (1 байт) + номер функции (1 байт) + адрес регистра (2 байта) + кол-во регистров (1 байт) + CRC (2 байта) = 7 байт. Ответ включает: адрес уст-ва (1 байт) + номер функции (1 байт) + данные в int (16 байт) + CRC (2 байта) = 20 байт. Итого передать по сети туда-обратно нужно 27 байт. На скорости 115200 бит/сек для этого необходимо: 27*8/115200 = 0,0019 секунды или 1,9 мс.

https://ru.wikipedia.org/wiki/Modbus ознакомтесь сколько байт нужно передать в запросе и ответе, а прогу вызывайте хоть каждую миллисекунду, пока комплит не покажет положительный фронт, запрашиваемые данные не пришли. При 110 мс если данные пришли на 111 минуте, Вы будете ждать еще 109мс чтоб их получить и обработать

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

Capzap, Вы не внимательно читаете, то что я пишу. Программу с обработкой ФБ модулей я предлагаю вызывать каждые 10 мс, т.е. с промежутком времени достаточным для запроса и ответа к одному модулю. Раз в 110 мс обрабатывать основную программу. Мысль моя такова - за 100 мс обрабатываю все модули, затем имея свежие данные исполняю логику управления, затем снова обрабатываю все модули и так далее.

[capzap]

Capzap, Вы не внимательно читаете, то что я пишу. Программу с обработкой ФБ модулей я предлагаю вызывать каждые 10 мс, т.е. с промежутком времени достаточным для запроса и ответа к одному модулю. Раз в 110 мс обрабатывать основную программу. Мысль моя такова - за 100 мс обрабатываю все модули, затем имея свежие данные исполняю логику управления, затем снова обрабатываю все модули и так далее.

если честно, я хотел написать одним словом ответ - бред, а теерь еще больший бред, какая разница для основной программы изменились данные или "застыли" на месте, почему она должна работать так медленно, от того что каждую цикл( в районе миллисекунды) неизмененное значение не привысит какой нибудь порог логика программы не нарушится

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

если честно, я хотел написать одним словом ответ - бред, а теерь еще больший бред, какая разница для основной программы изменились данные или "застыли" на месте, почему она должна работать так медленно, от того что каждую цикл( в районе миллисекунды) неизмененное значение не привысит какой нибудь порог логика программы не нарушится

Я думаю, Вы просто не вчитываетесь в идею. Могу сказать, что выполнять логику программы зная, что у меня не изменились значения входов и выходов не имеет особого смысла. Если свести пример до элементарного, то представть себе код:
if IX0.0 then
делай что-то
end_if;
Исполнять его заведомо зная, что IX0.0 не мог измениться бессмысленно.

Насколько я могу судить по темам в форуме, Вы пользуетесь библиотекой modbus.lib. Расскажите как Вы организуете обмен в плане архитектуры. Какие времена циклов и периоды опроса у Вас получаются.

[capzap]

Исполнять его заведомо зная, что IX0.0 не мог измениться бессмысленно.

не забывайте что это система реального времени, следуя Вашим умозаключениям здесь 90% кода бессмыслены

а опрос у меня как у всех, регулярное чтение оперативных параметров, один раз загрузка/выгрузка рецептурных параметров, при наступлении события приоритетная запись.
период опроса меня устраивает и 50мс на одно устройство

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

не забывайте что это система реального времени, следуя Вашим умозаключениям здесь 90% кода бессмыслены

Речь идет не о бессмысленности кода, а о бессмысленности его исполнения в некоторых случаях. Так, например, выше был разговор о том, что модули МВ110-8А обновляют данные своих регистров раз в 600-900 мс на канал. Опрашивать их чаще бессмысленно, потому что мы будем получать старые значения с модуля. Здесь логика таже. Нет смысла выполнять логику управления чаще, чем изменяются входные сигналы и выдаются управляющие воздействия. Другое дело, что еще нужно учитывать общение с уровнем оператора. Но для него 110 мс выше крыши.

а опрос у меня как у всех, регулярное чтение оперативных параметров, один раз загрузка/выгрузка рецептурных параметров, при наступлении события приоритетная запись.
период опроса меня устраивает и 50мс на одно устройство

Это чтение не вынесено в отдельную задачу?
Как реализована приоритетная запись. Хотелось бы конкретней, если возможно.

[capzap]

как Вас конкретизировать, если Вы не приемлете бессмысленный код. Может Вы и будете получать старые значения, но тогда и об аварийной ситуации Вы узнаете не своевременно
по приоритетности изучите полезный блок семафор, выходы разных семафоров через IF...ELSIF будут распределять что выполнить в первую очередь и ни каких отдельных задач не нужно

[Yegor]

МВ110-8А обновляют данные своих регистров раз в 600-900 мс на канал. Опрашивать их чаще бессмысленно

Бессмысленно с точки зрения общей реакции системы — да. С точки зрения простоты и стабильности опрашивающего кода — нет, не бессмысленно. Покуда хватает пропускной способности, экономить на такой ерунде не стоит. Лучше равномерный опрос с «бессмысленными» чтениями, чем быстрый опрос с запинками.

Другое дело, если не хватает времени на опрос остальных модулей. Допустим, есть один 8АС и пять штук 8А, при этом с 8АС надо читать как можно быстрее. Естественно, в этом случае уже принимаем во внимание период обновления 8А и выстраиваем очередь вот так: 8АС - 8А_1 - 8АС - 8А_2 - 8АС - 8А_3 <...> 8А_5. Эта очередь будет проходить быстрее 500 мс, но нас это не волнует — мы просто добиваемся стабильной частоты опроса самого быстрого модуля.

Не надо бояться лишний раз что-то вызвать на ПЛК. Он под это заточен. Те же функции чтения/записи порта сделаны так, что можно обходиться вообще без таймеров и нигде ничего не выжидать. Отправили запрос, поменяли состояние автомата, на следующем проходе программы уже начинаем делать SysComRead способом накопления в буфер — пофигу, что данные ещё не пришли. Как только счётчик буфера достиг нужного значения, интерпретируем данные в буфере и сразу переводим автомат в режим отправки запроса. На очередном проходе уже вызывается SysComWrite и дальше снова всё то же самое. Быстро, просто, надёжно, пусть и не экономно в каком-то смысле.

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

Ожидать, что ожидаемые 10 байт ответа придут и как только придёт 10 байт- это ответ а не мусор - это очень опасно.
Надо принимать байт, сразу его логически обрабатывать (заголовочный символ, адрес и т.п.) И когда звезды в машине разбора сошлись - проверять CRC и новый запрос.
А не набираем 10 байт - вот он ответ. Возможен мусор на линии.