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

[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 секунды. Вот как-то так.