Шаблоны устройств и время опроса модулей

Добрый день!
Работал контроллер ОВЕН ПЛК160 [М02], опрашивал по RS-485 12 модулей. Полное время опроса составляло менее чем полсекунды. Специально не засекал, просто было зрительно видно, что лампа опроса моргает часто
Добавил в схему RS-485 ОВЕН ПЛК210, бывший контроллер при этом "переписал" как будто он модуль со своими выходами и входами. Теперь модулей стало уже 13 штук.

Все ОВЕНовские модули добавил через шаблоны
И теперь имею полное время опроса всех модулей 4-5(!!!) секунд
Я же правильно понимаю, что "шаблоны" - это когда с модуля спрашивается вообще ВСЁ (не только входы, но и счётчики, настройки и т.д.) - и время опроса проседает на порядок? Если это так, то можно отключать внутри шаблона все ненужные параметры? Или в этом случае нужно от шаблонов отказываться, т.к., это всё неоптимально по скорости?

P.S.1 ну да ну да, скорость всего 9600. Если поднять её до 57600 (115200 не рискую, помехи), то на глазок скорость вырастет в 5 раз, но этого всё равно будет недостаточно
P.S.2 список модулей:
01) MK110_8D_4R (добавлен через шаблон)
02) MV110_32DN (добавлен через шаблон)
03) MU110_8R (добавлен через шаблон)
04) PLC110_60_M (бывший контроллер, сейчас, как бы, модуль)
05) MV110_32DN (добавлен через шаблон)
06) MU110_8R (добавлен через шаблон)
07) MU110_8R (добавлен через шаблон)
08) MK110_8D_4R (добавлен через шаблон)
09) SLA_8_DIN_M
10) SLA_8_DIN_M
11) SLA_8_DIN_M
12) PLC110_30 (ещё один бывший контроллер, сейчас, как бы, модуль)
13) MU110_8R (добавлен через шаблон)

Добрый день.

Цитата:

---

Я же правильно понимаю, что "шаблоны" - это когда с модуля спрашивается вообще ВСЁ (не только входы, но и счётчики, настройки и т.д.)

---

Не совсем. Список запросов, формируемых шаблоном, приведен на вкладке Информация шаблона в дереве проекта со всеми необходимыми пояснениями.

Цитата:

---

Если это так, то можно отключать внутри шаблона все ненужные параметры?

---

Нет.

Цитата:

---

Или в этом случае нужно от шаблонов отказываться, т.к., это всё неоптимально по скорости?

---

Основная цель создания шаблонов - упрощение настройки обмена для начинающих пользователей.
"Ускорить" опрос они не могут.
В целом, отказ от шаблонов в вашем случае несколько улучшит ситуацию - но не думаю, что радикально.

Основная её причина причина заключается в том, что ПЛК160 [М02] обеспечивает меньшее время цикла задачи по сравнению с ПЛК210.

См. также информацию здесь: https://owen.ru/forum/showthread.php...l=1#post363206

Прежде чем я начну ломать проект, удалять из него шаблоны и заменять их уже обычными запросами, ещё пара вопросов...
В ссылках от Вас речь идёт всё же о времени цикла ПЛК, а не о времени опроса модулей (при использовании шаблонов). Мой цикл 100мс и быстрее мне работать не надо. Прямо сейчас загрузка ЦП не превышает 10%, время цикла при этом не превышает 10мс (из допустимых 100мс). По этой логике количество шаблонов не должно увеличивать цикл опроса модулей

Пока у меня 2 пути:
1) Увеличить скорость до 57600
2) Удалить все шаблоны и запрашивать/писать только нужные 1-2 регистра

Цитата:

---

Сообщение от aaaSashaMGGU

Прежде чем я начну ломать проект, удалять из него шаблоны и заменять их уже обычными запросами, ещё пара вопросов...
В ссылках от Вас речь идёт всё же о времени цикла ПЛК, а не о времени опроса модулей (при использовании шаблонов). Мой цикл 100мс и быстрее мне работать не надо. Прямо сейчас загрузка ЦП не превышает 10%, время цикла при этом не превышает 10мс (из допустимых 100мс). По этой логике количество шаблонов не должно увеличивать цикл опроса модулей

Пока у меня 2 пути:
1) Увеличить скорость до 57600
2) Удалить все шаблоны и запрашивать/писать только нужные 1-2 регистра

---

Не путайте время цикла ПЛК, он может быть 5-10 ms, и время на опрос, по умолчанию 100 ms на запрос.
Скорость лучше увеличить, если принять меры от помех, то и до 115200.
Шаблоны читают по 1-2 регистра, если в шаблоне 20 переменных, то 20*100ms=2 секунды на 1 блок, поэтому лучше читать 1-2 нужных переменных, либо читать все регистры массивом, те же 20 переменных можно прочитать группой за 100 ms, при условии, что адреса идут по порядку.
До 120 переменных можно читать группой за 1 раз.

Цитата:

---

Сообщение от aaaSashaMGGU

В ссылках от Вас речь идёт всё же о времени цикла ПЛК, а не о времени опроса модулей (при использовании шаблонов).

---

Это напрямую связанные вещи.

Цитата:

---

Сообщение от aaaSashaMGGU

Мой цикл 100мс и быстрее мне работать не надо. Прямо сейчас загрузка ЦП не превышает 10%, время цикла при этом не превышает 10мс (из допустимых 100мс).

---

Шаблоны - это код, вызываемый в цикле одной из задач ПЛК.
Чтобы обработать даже один запрос - нужно несколько вызовов задачи.
Чтобы однократно полностью опросить все шаблоны - нужно много вызовов.
Вы сами установили интервал вызова задачи = 100 мс.
Так что тут, на мой взгляд, какое-то противоречие в действиях и ожиданиях от их последствий.

Цитата:

---

Сообщение от Евгений Кислов

Это напрямую связанные вещи.



Шаблоны - это код, вызываемый в цикле одной из задач ПЛК.
Чтобы обработать даже один запрос - нужно несколько вызовов задачи.
Чтобы однократно полностью опросить все шаблоны - нужно много вызовов.
Вы сами установили интервал вызова задачи = 100 мс.
Так что тут, на мой взгляд, какое-то противоречие в действиях и ожиданиях от их последствий.

---

Значит, я неверно объясняю...
Есть у меня задача. MainTask на 100мс. В ней я проверяю условия, формирую выходы и т.д.
Есть у меня Modbus на RS-485. В какой тогда задаче он живёт? Как часто вызывается? По мне так - все опросы всех модулей должны происходить в ней независимо и параллельно от MainTask
Таким образом, время опроса модулей (в идеале) должно быть меньше 100мс. Затем уже работает MainTask, идёт обработка, программа и т.д.

P.S. В задаче цикла шины для Modbus Master, COM Port стоит "Использовать родительскую установку". Завести новый таск на 1мс и установить его здесь?

Цитата:

---

Сообщение от aaaSashaMGGU

Значит, я неверно объясняю...
Есть у меня задача. MainTask на 100мс. В ней я проверяю условия, формирую выходы и т.д.
Есть у меня Modbus на RS-485. В какой тогда задаче он живёт? Как часто вызывается? По мне так - все опросы всех модулей должны происходить в ней независимо и параллельно от MainTask
Таким образом, время опроса модулей (в идеале) должно быть меньше 100мс. Затем уже работает MainTask, идёт обработка, программа и т.д.

---

https://ftp.owen.ru/CoDeSys3/98_Book...kManagment.pdf
п. 4, п. 8

Цитата:

---

Сообщение от Евгений Кислов

https://ftp.owen.ru/CoDeSys3/98_Book...kManagment.pdf
п. 4, п. 8

---

Евгений, спасибо! Всё расписано по полочкам. Выходило, что неявный Task работы Modbus-а как раз и был равен 100мс
Завтра сделаю (теперь уже) 3 дела:
1) Завести отдельную задачу ModbusTask на 10мс, выбрать её в "Установки ПЛК", "Задача цикла шины"
2) Увеличить скорость до 57600
3) Удалить все шаблоны и запрашивать/писать только нужные 1-2 регистра

Цитата:

---

Сообщение от aaaSashaMGGU

Выходило, что неявный Task работы Modbus-а как раз и был равен 100мс
Завтра сделаю (теперь уже) 3 дела:

---

Отдельная задача не нужна, у вас по умолчанию вызывается PLC_PRG каждые 10 мс, так же и происходит опрос.
А вот поставить в соотнесении переменных надо Вкл 2 (Всегда в задаче цикла шины)

Цитата:

---

Сообщение от kondor3000

Отдельная задача не нужна, у вас по умолчанию вызывается PLC_PRG каждые 10 мс, так же и происходит опрос.
А вот поставить в соотнесении переменных надо Вкл 2 (Всегда в задаче цикла шины)

---

Так у меня нет PLC_PRG
Есть MainTask с циклом 100мс
Есть VisuTask (или как его там) с циклом 100мс
Есть TestTask с циклом 500мс
Есть OwenCloudTask (или как его там) с циклом 500мс

Я, кажется понял - Вы говорите про Codesys 2.3
Но у меня мои вопросы в 3.5

Цитата:

---

Сообщение от aaaSashaMGGU

Так у меня нет PLC_PRG

Я, кажется понял - Вы говорите про Codesys 2.3
Но у меня мои вопросы в 3.5

---

Про какой 2.3, я такие вещи не путаю, по умолчанию создаётся POU (PRG) с вызовом 10 мс Вложение 80218
Ничего больше не надо, для любого опроса в ПЛК в мастере или слейве.
Если вы сами нагородили огород, то и пожинаете плоды в виде тормозов в опросе.
Про Визу и Овен клауд, задачи тоже создаются автоматом.

Цитата:

---

Сообщение от kondor3000

Про какой 2.3, я такие вещи не путаю, по умолчанию создаётся POU (PRG) с вызовом 10 мс Вложение 80218

---

Ясно. Именно его я переименовал в MainTask и поменял ему интервал на 100мс :)
Внутрь этого таска и закинул все свои программы

Цитата:

---

По умолчанию данный параметр имеет значение <не задано>. Это означает, что по
умолчанию в качестве задачи цикла шины используется задача проекта с наименьшим интервалом
вызова (обычно такой задачей является задача MainTask).

---

Т.е., Modbus работает с задачей с наименьшим интервалом. У меня это - мой MainTask с циклом 100мс
Нужна новая задача с циклом 10мс (или можно ещё меньше?) - и проблема должна быть решена

Цитата:

---

Сообщение от aaaSashaMGGU

Ясно. Именно его я переименовал в MainTask и поменял ему интервал на 100мс :)
Внутрь этого таска и закинул все свои программы


Т.е., Modbus работает с задачей с наименьшим интервалом. У меня это - мой MainTask с циклом 100мс
Нужна новая задача с циклом 10мс (или можно ещё меньше?) - и проблема должна быть решена

---

И зачем вы сами тормозите свой контроллер?
Вы хотите из ПЛК сделать ПР200 ? Так и купили бы реле за 20 тысяч, зачем 70 тратить было?

Цитата:

---

Сообщение от kondor3000

И зачем вы сами тормозите свой контроллер?

---

100мс для основного кода - нормальное адекватное время реакции системы на (например) сработку высокого давления
10мс для Modbus-а при этом - нормальное время, чтобы (на глазок) за всё время цикла основной задачи 100мс успели опроситься все модули, чтобы основная задача работала уже с новыми данными. А вообще, чем быстрее будет обновляться Modbus - тем лучше. Пусть даже один модуль несколько раз опросится за время цикла основной задачи 100мс. Хуже точно не будет

Цитата:

---

Сообщение от aaaSashaMGGU

100мс для основного кода - нормальное адекватное время реакции системы на (например) сработку высокого давления
10мс для Modbus-а при этом - нормальное время, чтобы (на глазок) за всё время цикла основной задачи 100мс успели опроситься все модули, чтобы основная задача работала уже с новыми данными. А вообще, чем быстрее будет обновляться Modbus - тем лучше

---

Вы из ПЛК210 сделали ПР200, так и купили бы реле за 20 тысяч, зачем 70 тратить было? Даже ПР200 работает обычно быстрее.
Это абсолютно не верный подход к программированию контроллера.

Я от себя дополню (статью пока не могу написать). В CodeSys 3.5 работа драйверов Modbus примерно в 5-7 раз медленнее, чем в CodeSys 2.3.
Поэтому такого мгновенного опроса, как в CodeSys 2.3, в новом CodeSys достичь не получится.
В своих новых проектах я разделяю модули IO на критичные и обычные через два интерфейса RS-485.
Критичные опрашиваю через библиотеку SysCom или OCL, а обычные - через дерево конфигурации.

Цитата:

---

Сообщение от kondor3000

Вы из ПЛК210 сделали ПР200, так и купили бы реле за 20 тысяч, зачем 70 тратить было? Даже ПР200 работает обычно быстрее.
Это абсолютно не верный подход к программированию контроллера.

---

Если речь про то, почему я не оставил цикл 10мс и не морочил бы людям голову - то дело в том, что мой написанный код, содержащий в себе в том числе SQL-запросы, отправку писем по Email, отправку СМС на GPRS-модем, сохранение файлов на внешнем FTP-сервере (да-да, хвастаюсь чего уж :) ) не успевает в цикле 10мс
И приходится ему увеличивать цикл. Нет, реально цикл 9-10мс с подскоками до 20-30. В этом случае, если оставить всё это в 10мс-задаче - то загрузка будет добрые 100%, а оно мне надо?
Это тот случай, когда цикл нужно увеличить
А то, что за этим увеличением ещё и модбас тащится - я (да и не только я, давайте честно скажем) просто не знал

Так сделайте для долгоиграющих задач свои таски, зачем всё в один 10мс пихать?

Цитата:

---

Сообщение от МихаилГл

Так сделайте для долгоиграющих задач свои таски, зачем всё в один 10мс пихать?

---

В данном проекте все мои задачи интуитивно и не должны сидеть в 10мс. 100мс для них вполне достаточно. Просто время сработки тех же датчиков предельного уровня измеряется секундами. Плюс-минус 100мс туда сюда роли не играет

Кроме того, если начать программы раскидывать в разные задачи, то начинаются коллизии (проходил, понимаю, о чём говорю) из-за рассинхронов потоков, т.к., POU перестают выполняться последовательно
Далее, цитата из руководства. Нет, я этого не знал заранее, просто неосознанно сделал именно так:

Цитата:

---

8. Рекомендации по работе с задачами
1. Не добавляйте в проект задачи (используйте только задачи, автоматически создаваемые
CODESYS).

---

В итоге, я не создавал новую задачу, а просто сменил время цикла у существующей
И по предыдущему заявлению - когда ПР200 научится показывать web-морду с 10-20 клиентами разом - я обязательно его попробую :p

Добрый день ещё раз!
Отписываюсь по результатам

Исходный цикл ~5 секунд на 13 модулей
1) Завёл отдельную задачу ModbusTask на 5мс, выбрал её в "Установки ПЛК", "Задача цикла шины". Цикл стал чуть менее секунды
2) Убрал все шаблоны, заменил их на нужные мне запросы. Цикл стал ~0.5 секунд
3) Скорость на 57600 сменить не удалось, т.к., ПЛК-110, как оказалось, в режиме Slave вообще работать не умеет (у него встроенные резисторы RS-485), но на 9600 всё работает стабильно. Ну, ладно. В любом случае, хуже чем было - не стало. Всё так и было изначально. Так что, вполне норм

Если бы делать без ПЛК-110 (в режиме модуля), то скорость выросла бы, думаю, ещё раза в 2-3
Всем спасибо за подсказки и идеи!

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

Емельянов Кирилл А почему последней по приоритету?
Мне в моих проектах было важно, чтобы нажатия на кнопки быстро отлеживались. Я поэтому ставил приоритет даже выше обычных, а время задачи 10-15 мсек. Но это не помогало, так как CDS 3.5 делал задержки 70-90 мсек между каждым запросом, гад. Помог только переход на SysCom.

Цитата:

---

Сообщение от Cs-Cs

Емельянов Кирилл А почему последней по приоритету?
Мне в моих проектах было важно, чтобы нажатия на кнопки быстро отлеживались. Я поэтому ставил приоритет даже выше обычных, а время задачи 10-15 мсек. Но это не помогало, так как CDS 3.5 делал задержки 70-90 мсек между каждым запросом, гад. Помог только переход на SysCom.

---

Просто если поставить её высший приоритет, то может не соблюдаться период вызова остальных задач

Цитата:

---

Сообщение от 1exan

Просто если поставить её высший приоритет, то может не соблюдаться период вызова остальных задач

---

Да

Цитата:

---

Сообщение от Cs-Cs

Емельянов Кирилл А почему последней по приоритету?
Мне в моих проектах было важно, чтобы нажатия на кнопки быстро отлеживались. Я поэтому ставил приоритет даже выше обычных, а время задачи 10-15 мсек. Но это не помогало, так как CDS 3.5 делал задержки 70-90 мсек между каждым запросом, гад. Помог только переход на SysCom.

---

У меня ещё не было задач где было бы критично время опроса по шине, наверное там было бы какое-то другое решение.
Сейчас ради интереса открыл один проект на ПЛК210. Задача опроса имеет джиттер 10мс, при добавлении клиента визуализации джиттер увеличивается примерно на 15мс. Навскидку с таким джиттером вполне можно соорудить опрос кнопок, создав свою очередь опроса клиентов на шине, где кнопочные клиенты будут опрашиваться в первую очередь.

Цитата:

---

Сообщение от Cs-Cs

Емельянов Кирилл А почему последней по приоритету?
Мне в моих проектах было важно, чтобы нажатия на кнопки быстро отлеживались. Я поэтому ставил приоритет даже выше обычных, а время задачи 10-15 мсек. Но это не помогало, так как CDS 3.5 делал задержки 70-90 мсек между каждым запросом, гад. Помог только переход на SysCom.

---

Речь про другой проект. Не тот, который в начале этой моей темы
Так вот, сейчас у меня на ветке 10 модулей. Время опроса всех ~200мс. Одного, соответственно, ~20мс
Для этого сделал задачу Modbus с интервалом 10мс, её же поместил как основную задачу цикла шины. 57600, 8, N, 1
Нет предела совершенству, но для кнопок как будто хватает
И будь у меня всего один модуль - уж точно хватало бы с головой
Так или иначе - никаких задержек "70-90мс" между запросами у меня точно нет
Всё делал через стандартные менюшки Codesys-а, а не через SysCom

aaaSashaMGGU Принято! Спасибо!