MODBUS COM отслеживание записи в канал

[RomeoVar]

Добрый день
Пытаюсь разобраться с таймингами записи по каналу MODBUS. Прошу помощи и консультации
Суть задачи: в рамках проекта нужно гарантировать запись параметров в устройства подключенные по MODBUS COM.
Решил работать через стандартный функционал (о других не знал), настроил все каналы (смотрите во вложении).
Стал разбираться с опциями цикла шины и не совсем понятно как происходит чтение - запись в/из канала. В документации все туманно, четких временных границ по записи/чтению нет. В частности изложено так

 "...По умолчанию данный параметр имеет значение <не задано>. Это означает, что в качестве
задачи цикла шины используется задача проекта с наименьшим временем цикла (обычно такой
задачей является задача MainTask).
20
4. Задачи и коммуникационные драйверы
Таким образом, если в проекте есть задача с адекватными временем цикла (например,
для протокола Modbus – 10…20 мс) – то описанные выше настройки задач всех Modbusкомпонентов можно оставить в значениях по умолчанию, и при этом никаких проблем с обменом
не возникнет.
С другой стороны, если пользователь, например, увеличит время задачи MainTask до 100
мс (и при этом в проекте не будет задач с меньшим временем цикла) – то обмен будет работать
некорректно (с точки зрения пользователя опрос будет медленным, часть ответов slave-устройств
будет пропущена)."

А так как мне нужно определить время последней записи/чтения по каналу я решил создать отдельную задачу MODBUS_HANDLER, установить для него "адекватный" циклический вызов (18 мс). И приоритет где-то больше 15. При таких настройках я вообще ничего не отлавливаю. Время не фиксируется даже по тем каналам которые опрашиваются каждые 100мс, а по фронту не записываются с первого раза вообще. Нужно выполнить 2-3 попытки чтобы выполнить запись. Я уменьшил цикл вызова до 6мс с самым низким приоритетом, и "о чудо" все заработало. Пишется с первого раза и отлавливаются все события.
Теперь вопрос - насколько корректна такая реализация чтения/записи в/из шины?

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

Добрый день.

Теперь вопрос - насколько корректна такая реализация чтения/записи в/из шины?

Что вы вкладываете в понятие "корректность" и каковы ее критерии?

[RomeoVar]

Корректность использования ресурсов ПЛК согласно его технической спецификации. У меня возникли сомнения. Почему?
В документации указано что время цикла задачи к которой привязан обмен по MODBUS считается адекватным если его значение лежит в пределах 18-20 мс. А у меня так не получается.
Более того, чтобы получить информацию о том как прошел обмен по определенному каналу нужен программный обработчик, т.к. информация из переменных iChannelIndex xDone xError нигде не сохраняется. И если произошла ошибка при чтении/записи по одному из каналов, я этого никак не увижу.
Соответственно в моем понимании это нужно сделать так,:
1. Отдельная задача с циклом 4-6 мс и приоритетом 30 в которой будет обрабатываться результат обмена по каналу и результат записываться в массив
Что-то типа

RTRIG_RolDone(CLK := ROL_DORNA.xDone);
RTRIG_JawsDone(CLK := JAWS_DORNA.xDone);
RTRIG_PushDone(CLK := FR_D720.xDone);
IF RTRIG_RolDone.Q THEN
	GVL.ltD_ChLastRW[roller_drive][ROL_DORNA.iChannelIndex] := TargetVars.stRtc.ltSystemTick;
END_IF
IF RTRIG_JawsDone.Q THEN
	GVL.ltD_ChLastRW[jaw_drive][ROL_DORNA.iChannelIndex] := TargetVars.stRtc.ltSystemTick;
END_IF
IF RTRIG_PushDone.Q THEN
	GVL.ltFR_ChLastRW[FR_D720.iChannelIndex] := TargetVars.stRtc.ltSystemTick;
END_IF

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

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

Вот:

3. Не назначайте задачам тип Свободное выполнение или Статус.
4. Не изменяйте интервалы вызова и приоритеты задач, которые CODESYS добавляет
автоматически.
5. В проекте должна присутствовать хотя бы одна задача с адекватным в рамках вашей системы
управления интервалом вызова (обычно такой задачей является MainTask, которая вызывается с
интервалом не менее 20 мс).
6. Не редактируйте в компонентах Modbus задачу цикла шины

Т.е. я нарушил все рекомендации из документа, поэтому у меня возникает когнитивный диссонанс - с одной стороны у меня все работает (пока), но эксперты (а составители документа наверное эксперты) мне этого делать не рекомендуют.

Отсюда вопрос и сомнения

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

Корректность использования ресурсов ПЛК согласно его технической спецификации. У меня возникли сомнения. Почему?
В документации указано что время цикла задачи к которой привязан обмен по MODBUS считается адекватным если его значение лежит в пределах 18-20 мс. А у меня так не получается.

В этой статье еще, например, указано следующее:

1. Не добавляйте в проект задачи (используйте только задачи, автоматически создаваемые
CODESYS).
2. Если вы добавляете в проект задачу – то должны четко понимать, как именно реализована
обработка многозадачности в CODESYS для используемого вами ПЛК и уметь ясно ответить на
вопрос, зачем именно вы создаете эту задачу.

...

На вашем скриншоте видно, что в проекте есть 5 задач, созданных вручную.

Кроме того, на скриншоте видно, что как минимум для одного slave-устройства настроено ~20 запросов циклического чтения c периодом опроса 100 мс.
Учитывая другие устройства - вероятно, в проекте их еще больше.
Если прочитать спецификацию Modbus - то станет понятно, что уложиться в такие интервалы времени невозможно (*для драйвера Modbus, реализованного согласно спецификации).

Суть задачи: в рамках проекта нужно гарантировать запись параметров

Гарантия записи параметров - после записи сделать чтение и сравнить значения. Всё остальное - это надежда на что-то.

[RomeoVar]

В этой статье еще, например, указано следующее:

Гарантия записи параметров - после записи сделать чтение и сравнить значения. Всё остальное - это надежда на что-то.

Именно так я и делаю - после записи читаю и сравниваю. НО! Это мне непонятно:

Кроме того, на скриншоте видно, что как минимум для одного slave-устройства настроено 20 запросов циклического чтения c периодом опроса 100 мс.

Вы говорите о периоде опроса 100мс. А в настройках канала указано что это таймаут ответа. Нужно ли понимать что ответило - ли устройство, нет-ли пока не истекут 100мс. следующий запрос отправлен не будет? Если да, то зачем такое? И в документации опять-же об этом ни слова. Я для себя, ввиду отсутствия информации, опытным путем предположил следующий алгоритм. По выбранному каналу идет обмен, если в течении 100мс ответ не получен, переходим к следующему каналу, а если ответ получен, переходим к опросу следующего канала не дожидаясь окончания таймаута.
Кстати измерения показывают нечто подобное. В моей задаче, неважно какой, происходит запись в каналы устройства по триггерной переменной. в задаче цикла шины, с периодом 6 мс. я отслеживаю время последней записи в канал и в массив. Результаты на скрине, в каналы с 6 по 23, а это как минимум 17 каналов, происходит в промежутке с 32.641 мс до 33.865 мс, это равно 1,224 секунды, т.е. в среднем 72 милисекунды. На самом деле была запись в большее количество каналов, (часть запросов идет циклически через 100 мс.) поэтому эта цифра еще меньше. А интервалы между записью в каналы фактические лежат в пределах 10 - 20 мс. Значит таймаут все-таки применяется только при отсутствии ответа от устройства.
Но если опираться на Ваше утверждение получается цикл должен занимать 2,6 секунды. Вот как-то так.

[RomeoVar]

На вашем скриншоте видно, что в проекте есть 5 задач, созданных вручную.

Я об этом тоже упомянул, я сознательно не последовал рекомендациям. Т.к. мне непонятно почему нельзя (если конечно я понимаю зачем я это делаю), если такая возможность есть?
Но это к сути вопроса по обмену не относится.

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

Вы говорите о периоде опроса 100мс. А в настройках канала указано что это таймаут ответа.

У вас на скриншоте видно "цикл., t#100ms". Это период опроса и он не имеет никакого отношения к таймауту.
Но я ошибся в числе запросов - на скриншоте их видно 10, а не 20. Сколько у вас их всего в проекте - я, конечно, не знаю, но предполагаю, что больше.

Нужно ли понимать что ответило - ли устройство, нет-ли пока не истекут 100мс. следующий запрос отправлен не будет? Если да, то зачем такое?

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

И в документации опять-же об этом ни слова.

Не соглашусь.

2021-06-25_12-00-05.png

Но если опираться на Ваше утверждение получается цикл должен занимать 2,6 секунды.

Процитируйте мое "утверждение", пожалуйста, из которого вы сделали такой вывод.

Т.к. мне непонятно почему нельзя (если конечно я понимаю зачем я это делаю), если такая возможность есть?

См. п. 2 в процитированном тексте.

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

Т.е. вы не следуете рекомендациям из документа и ваш вопрос в том, почему наблюдаемое вами поведение не соответствует некоторым оценкам, приводимым в документе.
Понятно.

[RomeoVar]

Ну вобщем Вы перевернули с ног на голову. Я изложил суть задачи, и спросил мнения эксперта о ее корректности.
По поводу этого:

Кроме того, на скриншоте видно, что как минимум для одного slave-устройства настроено ~20 запросов циклического чтения c периодом опроса 100 мс.

Если Вы обратите внимание это циклический опрос ТОЛЬКО НА ЧТЕНИЕ, и меня ЭТИ таймауты не интересуют. Меня интересует проверка записи, а запись осуществляется по триггерной переменной. И меня интересовала обработка, т.е. проверка записи. Я ее реализовал так, как описал, через отдельную задачу и поинтересовался, насколько такой подход корректен? А Вы ответили вопросом на вопрос.

[RomeoVar]

Просто Вы как-то раздраженно отвечаете. Я ведь пока не экперт, я только изучаю контроллер.

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

Просто Вы как-то раздраженно отвечаете.

Это не так. Мне искренне жаль, если вам так показалось.

Если Вы обратите внимание это циклический опрос ТОЛЬКО НА ЧТЕНИЕ, и меня ЭТИ таймауты не интересуют.

Меня, честно говоря, таймауты тоже не интересуют, и я не написал про них ни слова (до момента, пока их не упомянули вы).
Я просто обратил ваше внимание, что заданный период опроса не соответствует реально достижимому периоду.
Этот фактор, соответственно, может повлиять в том числе и на наблюдаемые вами эффекты.

А Вы ответили вопросом на вопрос.

К сожалению, не на все вопросы (особенно сложные) удается ответить сразу - иногда требуется сначала что-то уточнить.

Тут я думаю уже разобрался - я слишком рано сбрасываю триггерную переменную записи в FALSE. Это я в принципе устранил

Тогда давайте определимся - какой вопрос у вас сейчас остался?
Почему "вообще ничего не отлавливается" в задаче с периодом вызова 18 мс и отлавливается всё - в задаче с периодом вызова 6 мс?
Если я правильно интерпретировал вопрос - то выложите ваш проект, пожалуйста, и инструкцию, как с его помощью определить, отлавливаются ли события или нет.