Страница 1 из 4 123 ... ПоследняяПоследняя
Показано с 1 по 10 из 37

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

  1. #1

    По умолчанию MODBUS COM отслеживание записи в канал

    Добрый день
    Пытаюсь разобраться с таймингами записи по каналу MODBUS. Прошу помощи и консультации
    Суть задачи: в рамках проекта нужно гарантировать запись параметров в устройства подключенные по MODBUS COM.
    Решил работать через стандартный функционал (о других не знал), настроил все каналы (смотрите во вложении).
    Стал разбираться с опциями цикла шины и не совсем понятно как происходит чтение - запись в/из канала. В документации все туманно, четких временных границ по записи/чтению нет. В частности изложено так
    Код:
     "...По умолчанию данный параметр имеет значение <не задано>. Это означает, что в качестве
    задачи цикла шины используется задача проекта с наименьшим временем цикла (обычно такой
    задачей является задача MainTask).
    20
    4. Задачи и коммуникационные драйверы
    Таким образом, если в проекте есть задача с адекватными временем цикла (например,
    для протокола Modbus – 10…20 мс) – то описанные выше настройки задач всех Modbusкомпонентов можно оставить в значениях по умолчанию, и при этом никаких проблем с обменом
    не возникнет.
    С другой стороны, если пользователь, например, увеличит время задачи MainTask до 100
    мс (и при этом в проекте не будет задач с меньшим временем цикла) – то обмен будет работать
    некорректно (с точки зрения пользователя опрос будет медленным, часть ответов slave-устройств
    будет пропущена)."
    А так как мне нужно определить время последней записи/чтения по каналу я решил создать отдельную задачу MODBUS_HANDLER, установить для него "адекватный" циклический вызов (18 мс). И приоритет где-то больше 15. При таких настройках я вообще ничего не отлавливаю. Время не фиксируется даже по тем каналам которые опрашиваются каждые 100мс, а по фронту не записываются с первого раза вообще. Нужно выполнить 2-3 попытки чтобы выполнить запись. Я уменьшил цикл вызова до 6мс с самым низким приоритетом, и "о чудо" все заработало. Пишется с первого раза и отлавливаются все события.
    Теперь вопрос - насколько корректна такая реализация чтения/записи в/из шины?
    Изображения Изображения

  2. #2

  3. #3

    По умолчанию

    Корректность использования ресурсов ПЛК согласно его технической спецификации. У меня возникли сомнения. Почему?
    В документации указано что время цикла задачи к которой привязан обмен по 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 задачу цикла шины
    Т.е. я нарушил все рекомендации из документа, поэтому у меня возникает когнитивный диссонанс - с одной стороны у меня все работает (пока), но эксперты (а составители документа наверное эксперты) мне этого делать не рекомендуют.

    Отсюда вопрос и сомнения
    Последний раз редактировалось RomeoVar; 25.06.2021 в 10:27.

  4. #4
    Супер Модератор Аватар для Евгений Кислов
    Регистрация
    27.01.2015
    Адрес
    Москва
    Сообщений
    12,064

    По умолчанию

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

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

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

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

  5. #5

    По умолчанию

    Цитата Сообщение от Евгений Кислов Посмотреть сообщение
    В этой статье еще, например, указано следующее:

    Гарантия записи параметров - после записи сделать чтение и сравнить значения. Всё остальное - это надежда на что-то.
    Именно так я и делаю - после записи читаю и сравниваю. НО! Это мне непонятно:
    Цитата Сообщение от Евгений Кислов Посмотреть сообщение
    Кроме того, на скриншоте видно, что как минимум для одного slave-устройства настроено 20 запросов циклического чтения c периодом опроса 100 мс.
    Вы говорите о периоде опроса 100мс. А в настройках канала указано что это таймаут ответа. Нужно ли понимать что ответило - ли устройство, нет-ли пока не истекут 100мс. следующий запрос отправлен не будет? Если да, то зачем такое? И в документации опять-же об этом ни слова. Я для себя, ввиду отсутствия информации, опытным путем предположил следующий алгоритм. По выбранному каналу идет обмен, если в течении 100мс ответ не получен, переходим к следующему каналу, а если ответ получен, переходим к опросу следующего канала не дожидаясь окончания таймаута.
    Кстати измерения показывают нечто подобное. В моей задаче, неважно какой, происходит запись в каналы устройства по триггерной переменной. в задаче цикла шины, с периодом 6 мс. я отслеживаю время последней записи в канал и в массив. Результаты на скрине, в каналы с 6 по 23, а это как минимум 17 каналов, происходит в промежутке с 32.641 мс до 33.865 мс, это равно 1,224 секунды, т.е. в среднем 72 милисекунды. На самом деле была запись в большее количество каналов, (часть запросов идет циклически через 100 мс.) поэтому эта цифра еще меньше. А интервалы между записью в каналы фактические лежат в пределах 10 - 20 мс. Значит таймаут все-таки применяется только при отсутствии ответа от устройства.
    Но если опираться на Ваше утверждение получается цикл должен занимать 2,6 секунды. Вот как-то так.
    Изображения Изображения
    Последний раз редактировалось RomeoVar; 25.06.2021 в 11:58.

  6. #6

    По умолчанию

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

  7. #7
    Супер Модератор Аватар для Евгений Кислов
    Регистрация
    27.01.2015
    Адрес
    Москва
    Сообщений
    12,064

    По умолчанию

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

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

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

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

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

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

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

  8. #8

    По умолчанию

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

  9. #9

    По умолчанию

    Т.е. вы не следуете рекомендациям из документа и ваш вопрос в том, почему наблюдаемое вами поведение не соответствует некоторым оценкам, приводимым в документе.
    Понятно.
    О каком поведении Вы говорите?
    Если о том что не происходит запись в канал? Тут я думаю уже разобрался - я слишком рано сбрасываю триггерную переменную записи в FALSE. Это я в принципе устранил

  10. #10

    По умолчанию

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

Страница 1 из 4 123 ... ПоследняяПоследняя

Похожие темы

  1. Триггер на чтение Modbus канал
    от Пьер в разделе СПК1хх [М01]
    Ответов: 17
    Последнее сообщение: 03.02.2023, 06:49
  2. Канал ModBus Slave
    от ВладимирВ в разделе Мх110
    Ответов: 1
    Последнее сообщение: 26.02.2020, 15:02
  3. Канал Modbus Slave
    от Sklyar в разделе СПК1хх
    Ответов: 2
    Последнее сообщение: 20.12.2018, 08:56
  4. Буфер записи по modbus
    от Егор_Егор в разделе ПЛК1хх
    Ответов: 9
    Последнее сообщение: 24.08.2018, 09:36
  5. ТРМ200 теряется канал связи RTU Modbus
    от РиссаТС Андрей в разделе Эксплуатация
    Ответов: 5
    Последнее сообщение: 05.03.2015, 17:29

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •