СПК110 опрашивает 35 модулей, взаимное влияние каналов опроса.

[ZPavel]

Проект под управлением СПК110. В проекте используется 4 последовательных канала связи с модулями ввода вывода, для четырех отдельных шкафов, которые могут быть обесточены. На первом канале опрашивается 13 модулей. На втором 7 модулей. На третьем 12 модулей. На четвертом 3 модуля. Итого опрашиваем 35 модулей ввода вывода ОВЕН. Модули прописаны в проекте через шаблоны модулей. То есть опрашиваем кучу лишней для нас информации. Считаю это не важно. В проекте установил счетчики ошибок не опросов для каждого модуля.
Столкнулся с интересной проблемой. При физическом отключении любого, особенно там, где много модулей, канала, начинает сбоить опрос других каналов по другим портам.
Даже создавал отдельные задачи для опросов каждого канала, эффект не исчезает, сбои продолжаются.
Заметил закономерность, когда все модули подсоединены, можно уменьшить время цикла задачи опроса модулей. Сейчас стоит 30 мс. Можно поставить и 10 мс, сбоев нет. Но стоит отключить какой-то к***** и пошли сбои и не опросы в оставшихся подключённых каналах. Что бы от этого избавиться, приходится увеличивать время цикла задачи опроса. Если поставить 50 мс, ошибки не опросов пропадают. Но и падает общее время перебора модулей, когда их подключить все обратно. Так сказать, падает время отклика всей системы. Пробовал для каждого порта делать свою задачу, не помогает. Как будто в контроллере реально один порт, который расходится коммутатором на пять. Подскажите, как сделать так, чтобы отключение одного канала связи, не влияло на опрос других каналов.

[Cs-Cs]

Всё так. Я ж на СПК110 делал щиты для умного дома, и набрался информации про все эти опросы (мне надо было максимально быстро опрашивать).
Мой опыт такой:

1. Шаблоны - это самый медленный способ опроса.
Лучше уж сделать Modbus Slave и руками набить туда нужные регистры (внимание: модули .8А иногда сбоят и не отвечают при большом групповом запросе; всю их карту регистров лучше бить на 3 звпроса).

2. CodeSys опрашивает каналы (отдельные запросы к одному модулю) подряд друг за другом с выдержкой таймаута.
Если модуль отвалился, то общий таймаут (и замедление работы остальных модулей) будет равен "Таймаут х Число Modbus-запросов".
Буквально, CodeSys 3.5 работает так:
* Запрос 1.
* Модуль не ответил.
* Таймаут.
* Запрос 2.
* Модуль не ответил.
* Таймаут.
...и так далее.

3. (вот это очень важно) Опрос штатными средствами (через элементы в дереве проекта - шаблоны или обычные Modbus Slave) ВСЕГДА тормозит задачу, в которой он выполняется!!! На время таймаута - тоже.
А вот опрос через библиотеку OCL или SysCom так не тормозит и работает одновременно с задачей, в которой выполняется, не мешая её работе.

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

Так что переходи на OCL - это самый удобный способ.

[Сергей0308]

Проект под управлением СПК110. В проекте используется 4 последовательных канала связи с модулями ввода вывода, для четырех отдельных шкафов, которые могут быть обесточены. На первом канале опрашивается 13 модулей. На втором 7 модулей. На третьем 12 модулей. На четвертом 3 модуля. Итого опрашиваем 35 модулей ввода вывода ОВЕН. Модули прописаны в проекте через шаблоны модулей. То есть опрашиваем кучу лишней для нас информации. Считаю это не важно. В проекте установил счетчики ошибок не опросов для каждого модуля.
Столкнулся с интересной проблемой. При физическом отключении любого, особенно там, где много модулей, канала, начинает сбоить опрос других каналов по другим портам.
Даже создавал отдельные задачи для опросов каждого канала, эффект не исчезает, сбои продолжаются.
Заметил закономерность, когда все модули подсоединены, можно уменьшить время цикла задачи опроса модулей. Сейчас стоит 30 мс. Можно поставить и 10 мс, сбоев нет. Но стоит отключить какой-то к***** и пошли сбои и не опросы в оставшихся подключённых каналах. Что бы от этого избавиться, приходится увеличивать время цикла задачи опроса. Если поставить 50 мс, ошибки не опросов пропадают. Но и падает общее время перебора модулей, когда их подключить все обратно. Так сказать, падает время отклика всей системы. Пробовал для каждого порта делать свою задачу, не помогает. Как будто в контроллере реально один порт, который расходится коммутатором на пять. Подскажите, как сделать так, чтобы отключение одного канала связи, не влияло на опрос других каналов.

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

[melky]

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

[Cs-Cs]

Многозадачности нет в этом чуде?

Именно в опросе Modbus - нет.
Штатный опрос синхронный и выполняется в задаче с самым меньшим временем цикла. И, пока идёт ожидание ответа, таймаута - задача встаёт.

[melky]

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

Это в принципе у CodySys или так реализовано у Овен?

[Cs-Cs]

melky Да, плохо. Я с этим намучился жесть. И потом перешёл на OCL (OWEN Communication Library), которая уже работает асинхронно как и нужно: ты ей дал команду на выполнение - и она не блокирует цикл задачи, а потом возвращает результат или ошибку.
И ещё можно написать свою логику обработки ошибок так, что если запрос Modbus на модуль IO отвалился по ошибке (если модуль сломался или отключен) - то можно не делать другие запросы к нему, а сразу опрашивать следующий модуль. Это я про то, когда к одному модулю у нас идёт несколько запросов на чтение-запись.
Я под OCL даже свою обёртку написал: сделал массив структур, где указываются адрес, команда Modbus, длина данных и указатели на буфер для ответа. И этот массив у меня красиво перебирается подряд.

У CodeSys 3.5 в штатных устройствах Modbus, которые в дерево проекта добавляются (от 3S).