HMI cMT2078x Ограничение на кол-во задач в Codesys

[dennis_asytp]

добрый день.
Коллеги никто не сталкивался с такой проблемой - ограничение количества задач(Task) не более 5!? При создании проекта в CODESYS при если кол-во задач больше 5, это ограничение всегда было?

[Jackson]

Доброго дня!
А мануал что про это пишет?

[dennis_asytp]

Доброго дня!
А мануал что про это пишет?

Я не нашел никаких ссылок на это в описании к панели, и более того я обратился к поставщикам, официальным дистрибьютерам этих панелей, они тоже были удивлены наличием такого ограничения... Если действительно нельзя создавать более 5 задач, что как мне кажется мало, для такой производительной системы( 1Гб ОЗУ, процессор 1,5ГГц) тогда надо пересматривать смысл использования ее как ПЛК.

[Jackson]

тогда надо пересматривать смысл использования ее как ПЛК.

Ну, вообще-то, это изначально и есть операторская панель, а не ПЛК. И про то что эти вещи лучше не смешивать - на форуме много разговоров найдёте (так что здесь мы это обсуждать не будем).
Поддержка потому и удивилась, наверное, что и им такое в голову ещё не приходило. Не знаю, с какой именно конторой Вы общались, а там, с кем общался я - ребята очень неглупые трудятся.

[leon78]

С какой целью вы плодите задачи? Может можно обойтись одной?

[dennis_asytp]

С какой целью вы плодите задачи? Может можно обойтись одной?

Раз такая проблема появилась это будет одним из вероятных решений... Уложиться в доступное кол-во задач. В системе 41 устройство, и далее предполагалось расширять до 60, каждое это поставщик данных, опрос по MODBUS(rs-485), плюс регулирование...

Отправлено спустя 33 минуты 49 секунд:

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

Неглупые не спорю, давно общаемся и много раз помогали и давали хорошие советы, но и они удивились тому, что такое ограничение существует, потому что у этого производителя так же есть ПЛК cMT-CTRL01, именно ПЛК, и обнаружилось что и у него есть такое ограничение в 6 задач... что наводит на мысль, что, возможно, это программная ошибка... На данном этапе отправили письмо производителю ждем ответа... Здесь я написал в надеже что кто-то сталкивался уже с этим, это бы сэкономило время...

Ну, вообще-то, это изначально и есть операторская панель, а не ПЛК. И про то что эти вещи лучше не смешивать - на форуме много разговоров найдёте (так что здесь мы это обсуждать не будем).

Я понимаю, и выбор решения выполнить все в панели был связан со следующим: стоимость - панель + ПЛК или просто панель с функцией ПЛК + лицензия - мы работаем в такой ценовой нише, что для нас это важно и стоимость дополнительного ПЛК сделает наши проекты не выгодными...; сам производитель и дистрибьютор позиционировали такое решение, не упоминая об ограничениях...;

[Jackson]

В системе 41 устройство, и далее предполагалось расширять до 60, каждое это поставщик данных, опрос по MODBUS(rs-485), плюс регулирование

Почему именно кодесис? В скриптах всё написать можно. Точнее в скрипте - в одном всего. Хотя можно и 60 скриптов.

Я понимаю, и выбор решения выполнить все в панели был связан со следующим: стоимость

Всё понятно. :)

сам производитель и дистрибьютор позиционировали такое решение, не упоминая об ограничениях

И про кодесис тоже производитель декламировал?

В одной задаче опрос всех 60 устройств разве нельзя сделать?

Хотя, я могу себе представить, сколько времени займёт опрос 60 устройств по единственному RS-485. :)

Производитель-то кто? Покажите его декларацию.

[dennis_asytp]

Почему именно кодесис? В скриптах всё написать можно. Точнее в скрипте - в одном всего. Хотя можно и 60 скриптов.

Честно говоря немного странно такое читать... Скрипт нельзя вызывать чаще чем 10 раз/сек для этой панели, с учетом кол-ва устройств, а значит и еще потери на время передача/прием, плюс управление/ регулирование... это слишком редко... Потом система написанная на скриптах не является системой управления и регулирования. Далее скудный запас встроенных функций и т.д. в CODESYS есть и обширные библиотеки, и куча всего для построения систему управления... ну т.е. это вообще нельзя сравнивать... скрипты и полноценную IDE... на мой взгляд.

И про кодесис тоже производитель декламировал?

Да, была приобретена лицензия позволяющая использовать панель и как ПЛК.... Т.е. это функционал декларируемый самим производителем...

В одной задаче опрос всех 60 устройств разве нельзя сделать?

Можно конечно, теперь это один из вариантов... но сдается мне будет мало 6 задач... регулирование... там еще много чего предполагалось добавить... и тренды и аварийные события, архив, журналирование...

Хотя, я могу себе представить, сколько времени займёт опрос 60 устройств по единственному RS-485. :)

Это основной момент - время...

Производитель-то кто? Покажите его декларацию.

Weintek HMI cMT2078x... Мы же в ветке форума Weintek, о нем и речь...

[Jackson]

Честно говоря немного странно такое читать...

А делать совсем не странно. И лицензия на кодесис не нужна, как и он сам. На кодесисе мир клином не сошёлся.

Скрипт нельзя вызывать чаще чем 10 раз/сек для этой панели

А зачем??? Если у Вас 60 устройств на единственном RS-485 - тут уложиться бы хотя бы в опрос за десять секунд, и то не факт что получится. Либо одно устройство (или хотя бы небольшая группа) - один экран, один скрипт для этого экрана, и таких экранов штук 10-15, тогда опрашивать можно не все, а только те что на этом экране. Период опроса явно сократится в разы.

это слишком редко

Опрос вы не сделаете быстрее интерфейса. Какие там милисекунды? А основной скрипт может в цикле непрерывно крутиться.
И вообще, я выше уже писал, что ждать от панели за максимум 300 долларов сумасшедшего быстродействия в части логики и тем более управления - бессмысленно, она на это не рассчитана.

Можно конечно, теперь это один из вариантов... но сдается мне будет мало 6 задач... регулирование... там еще много чего предполагалось добавить... и тренды и аварийные события, архив, журналирование...

60 скриптов для опроса каждого устройства, один скрипт который будет эти 60 вызывать. Мало? Это как максимум. Если опрос типовой (меняется только Slave ID) то и 60 скриптов не надо - достаточно одного и менять только Slave ID и адреса внутренних переменных. Это только некоторые способы "в лоб", а можно и ещё изящнее сделать.

Weintek HMI cMT2078x...

Так он Вам только про Вейнтек и декларировал. :) А про всю систему в целом - это уже Вы подумать должны были. Опрос возможен и 100 и 200 устройств, запросто. Но с какой скоростью и как организованный. Тут Вейнтек совершенно ни при чём, тут Ваша голова должна включаться.
А прямо в лоб без оптимизации, если их все 60 за раз опрашивать, то тут как минимум многопортовый сервер ещё покупать надо, и не один, чтобы приемлемую скорость опроса хотя бы получить. Но похоже и ПЛК попахивает, если эти 60 устройств надо не только опрашивать, но ещё и управлять ими по какой-то логике. Можно конечно и на панели сделать, но не знаю, устроит ли Вас в итоге быстродействие (не знаю, что Вам требуется). Будь хоть 3-ГГц-поцессор, а всё в связь упрётся, в единственный не самый быстрый порт и в кучу устройств на нём, которые имеют право ещё и по таймауту отваливаться.

Прикиньте: что будет, если 10 из 60 отвалятся по таймауту.

[Jackson]

Хороший вопрос: а Ваши устройства поддерживают ModBUS Slave ID больше 32? Это умеют не все. Порт RS-485 у Вас всего один. Если не поддерживают, то вот мы и приезжаем как минимум к многопортовому серверу (шлюзу) RS-485.

Надо для начала глянуть схему интерфейсов всей Вашей системы.

[leon78]

а Ваши устройства поддерживают ModBUS Slave ID больше 32

По протоколу Modbus Slave ID до 247. Ни разу не встречал ограничение 32 в Slave ID устройства. Есть физическое ограничение линии RS485 до 32 устройств из-за входного сопротивления приёмников, но оно решается использованием репитеров.

Отправлено спустя 4 минуты 41 секунду:

Уложиться в доступное кол-во задач. В системе 41 устройство, и далее предполагалось расширять до 60, каждое это поставщик данных, опрос по MODBUS(rs-485), плюс регулирование...

1. На сколько помню, опрашивать по Modbus RTU через порт панели Weintek из Codesys вы не можете, порт RS485 доступен только в Easy Builder.
2. Разбирвать на разные задачи следует в том случае, если для каждой задачи вам требуется существенно отличающийся цикл. Если цикл одинаковый, зачем разбивать? Лучше делать отдельные POU.

[Jackson]

По протоколу Modbus Slave ID до 247. Ни разу не встречал ограничение 32 в Slave ID устройства

Это по спецификации ModBUS до 247. Столько должен уметь адресовать мастер. Точнее - до стольки. А производители устройств имеют право внутри устройства вводить ограничение. И я видел нередко, что и 32 и даже 16 (это совсем редко) - максимум что можно задать в устройстве. В силу назначения конкретного устройства, может просто не быть смысла вешать их больше 32 на одну шину. Мастер, как правило, спокойно опрашивает любой адрес от 1 до 247 - не в каждом слейве можно задать такой адрес.

1. На сколько помню, опрашивать по Modbus RTU через порт панели Weintek из Codesys вы не можете, порт RS485 доступен только в Easy Builder.

Могу ошибаться, но по-моему тоже.

У панельки дискретность отрисовки, ЕМНИП, 2-3 раза в секунду, и производителю делать из неё ОСРВ нет ну никакого смысла. Он и не делает.

[+] аналогичная ситуация где упёрлись в интерфейс

Лет 10 назад одна военная контора автоматизировала корабельную электростанцию на наших контроллерах. Звонят, просят приехать помочь. Не поленился, съездил. Суть проблемы. На мостиках стоят пульты с экранами на QNX (операционная система реального времени), где всё очень круто и быстро отображается. Мультики красивые. На пульты выводится АПС и информация от электростанции. Дословно претензия звучала так: "Неприемлемая задержка при отображении АПС. Например, сигнал об обесточивании приходит только через полминуты-минуту после срабатывания АПС в электростанции"
Начинаем разбираться и выясняем. Семь контроллеров, разбросанных по всему кораблю, сидят на одной шине RS-485 ModBUS, общей протяжённостью метров 400-500 (по кабелю). Скорость обмена в них задана 9600 бод. Опрос организован незамысловато: читаются пачкой все 2000 регистров функцией 03 и две сотни - функцией 01. Включая тип контроллера, версию ПО и прочий сервисный мусор. Можно подумать что тип контроллера и его ПО на военном корабле может оперативно меняться. Обработка таймаутов: количество попыток опроса устройства = 10, время таймаута = 5 секунд. Т.е. одно устройство выпало - получите тормоз сразу на минуту.
- Собственно, а чего вы ждали при таком опросе?
- Ну у нас же ОСРВ! Боевой же корабль!
- Ага. И у Вас RS-485 на 9600 бод. Тут уже и без контроллера будет понятно, что корабль обесточился - когда свет погас на мостике и ИБП заверещали, не?
Некоторое время ушло на осознание этой ситуации. Опрос они оптимизировали, количество данных значительно уменьшили, но больше они не покупали у нас контроллеров, хотя могли просто переехать на Ethernet. Это при том что в электростанции все процессы медленные, на иные по несколько минут уходит чисто физически. Но им хотелось чуть ли не осциллограммы мгновенных значений всех измерений иметь (с дискретностью 1 мсек или лучше). На Модбасе. Через 9600 бод. Ну да, на обесточенном корабле осциллограммы в виде прямых на значении "0" будут очень полезны и информативны, и - главное - кому-то очень интересны.....

Здравый смысл.

Отправлено спустя 7 минут 16 секунд:
По личному опыту, когда панель нагружена логикой, у меня были проблемы со скоростью и при 30 устройствах на 100-мбитном езернете. А на 485м при 19200 бод можно и всего с одним устройством проблем поиметь. И я тут это подробно описывал.

[Velt]

Раз тут разговор зашел о панелях, то давайте и я историю про нестандартное применение панели расскажу. Панель HT-3000.

[+]

На первый взгляд, классическая ситуация. Имеется промышленный робот-манипулятор, с которым связь по Modbus TCP есть ПЛК, который этому роботу параметры работы в регистры пишет. Всё было бы хорошо, но робот использует порт 10502 (десять тысяч пятьсот два), а ПЛК разумеется работает через порт 502. В роботе можно задать и порт 502, но в мануале на робот, на простом китайском языке сказано, что поддержка портов номером меньше 10000 не гарантируется. Что я и ощутил на своей шкуре, когда не мог понять, почему модбас криво работает, регистры читает, но не пишет.
Выход нашелся через панель. Панель своими скриптами читает/пишет регистры робота через порт 10502, потом эти регистры читает/пишет в ПЛК через порт 502. Задержка примерно 1-2 секунды, но для той задачи это было приемлемо.
Таким образом, панель стала играть роль шлюза. При её поломке управление роботом будет потеряно. Но на тот момент это был единственный выход.

[dennis_asytp]

1. На сколько помню, опрашивать по Modbus RTU через порт панели Weintek из Codesys вы не можете, порт RS485 доступен только в Easy Builder.

Да все верно, прямого доступа нет, но это решается она умеет в режиме шлюза работать с внутренним сервером modbus TCP.

2. Разбирвать на разные задачи следует в том случае, если для каждой задачи вам требуется существенно отличающийся цикл. Если цикл одинаковый, зачем разбивать? Лучше делать отдельные POU.

Ну в сложившихся обстоятельствах это вариант, я конечно был немного удивлен обнаружив ограничение в 5 задач о котором нигде не было упомянуто(у ОВЕНА в их ПЛК ограничение в 100 потоков) и конечно не рассчитывал на такое ограничение, все таки иметь возможность при необходимости задействовать дополнительные потоки это плюс, с учетом того что предполагалось систему развивать добавлять функционал... что теперь под вопросом... Да и потом, задачи логично выделять не только под опрос, но и есть еще достаточное количество внутренних задач... управление, формирование аварий...

[Sergy6661]

у ОВЕНА в их ПЛК ограничение в 100 потоков

Что такое "поток" в ПЛК? Не бывает многопоточных ПЛК, все выполняется поочередно, даже прерывание в некоторых просто выполняется задача прерывания и...продолжается выполнение текущей задачи. Задача в КоДеСис это Task, мне в любом ПЛК всегда достаточно 1-й. Если в ПЛК на КоДеСис несколько задач, то диспетчерировать их запуск надо с помощью "Менеджера задач" и там или запуск по периоду или по событию, НО! Все равно ни какой многозадачностью (многопоточностью) и не пахнет.
Вопрос конкретный- где вы читали про многопоточность в ПЛК Овен???
Второй вопрос опционный- для чего вам более одной задачи???

[se_sib]

Есть ПЛК Codesys с поддержкой лицензии Multicore, где можно на разных ядрах(если оно не 1) ЦПУ выполнять выбранные задачи, но редко такие попадаются.
Делить программу на куски, выполняющиеся в разных задачах, вытесняющих друг друга по приоритету, бесполезное занятие.
Хотя иногда бывают нужны 1-2 задачи с более быстрым циклом.

MultiCoreCodesys.png

[dennis_asytp]

Что такое "поток" в ПЛК?

Имелись ввиду конечно задачи(Task) по моему аналогия вполне схожая...

Второй вопрос опционный- для чего вам более одной задачи???

Что бы была более гибкая программа...

[Sergy6661]

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

Согласен полностью! И добавлю- мало того, что бесполезное, но еще и опасное.

Что бы была более гибкая программа...

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

Отправлено спустя 3 минуты 48 секунд:
И вопрос- а какого типа гибкость и в чем она заключается?
И предположение, возможно вы прошли онлайн курсы от Овен, если это так, то вы просто зря потратиои время, выбросьте из головы весь этот бред про многозадачность в ПЛК.

[se_sib]

Что бы была более гибкая программа...

Вот так будут выполняться 2 задачи.
Например с N-1(цикл 10мс) 2 раза прервет задачу с N (цикл 25мс) за ее цикл.

PlcTaskPriorities.jpg

[dennis_asytp]

Вот так будут выполняться 2 задачи.
Например с N-1(цикл 10мс) 2 раза прервет задачу с N (цикл 25мс) за ее цикл.

Я это понимаю, но не совсем понимаю что вы этим пытаетесь сказать?

[SBeaRM]

Я это понимаю, но не совсем понимаю что вы этим пытаетесь сказать?

Вам пытаются сказать, что вы занимаетесь ерундой, разделяя проект на кучу потоков.
Собственно всё что вам нужно это один поток с фиксированным временем цикла для ПИД-регуляторов и основной поток, в котором будут крутится все остальные процедуры. Поэтому пяти задач вам должно хватить с избытком.

[petr2off]

В постановке задачи заложено противоречие. С одной стороны - изпользование Weintek как контроллера для бедных, с другой стороны замах на мультизадачную систему. Скажем у того же ICP-DAS в линейке контроллеров есть нижние в линейке (специализированная ОС - аналог MS-DOS - только файловой системы нет) и верхние в линейке - на Linux, Windows CE и т.д. Соотвественно в верхних линеках ISAGRAF мультизадачный, причем задачи можно даже по разным контроллерам распихивать, механизм обмена есть. Но ценник совершенно не бюджетный. Есть у них и совмещенная модель (панель + контроллер), но она в низу линейки - нет там мультизадачности никакой.
Тут как говаривал мой знакомый другу в бане - ты либо трусы надень, либо крестик сними. В конце концов, связка Кинко + Delta DVP по ценнику в тоже и выйдет. А если захочется задачи добавлять - то можно вешать на веревку дополнительно DELTA DVS SS на каждый новый комплекс задач. Правда, как любит напоминать Jaксson - усложнение системы - усложнение программирования - дополнительные деньги, причем не только на создание но и на обслуживание.
Т.е. сложность задачи и ценник все равно связаны. Сколько пива - столько песен.

[Jackson]

Что бы была более гибкая программа...

А зачем? Что это даст?

И вопрос- а какого типа гибкость и в чем она заключается?

Вот-вот.

В постановке задачи заложено противоречие.

Да и не одно... :)

Собственно всё что вам нужно это один поток с фиксированным временем цикла для ПИД-регуляторов и основной поток, в котором будут крутится все остальные процедуры.

Не забудьте ещё что 60 устройств на модбасе по витой паре надо опросить.
Только мне одному кажется что итоговое быстродействие (а точнее - медленнодействие) будет такое, что оно устроит, разве что, если управлять какой-то крупной большой тяжёлой печью, или наливом ёмкости тонн на 500 (с огромной постоянной времени) ?
И всё это с единственной панельки, которая имеет право умереть, её могут разбить и т.п.
Только мне кажется что что-то тут не так?

Фундаментальный же постулат: кривой хард никаким софтом не исправить. Тут изначально, по-моему, кривое структурное решение (это и есть хард), а вы рассуждаете о том как софт оптимизировать. Рассуждаете правильно, но, по-моему, бессмысленно. Насколько кривое - а шут его знает. Я попросил структурную схему посмотреть, dennis_asytp пока не показал.

[+] для Velt

Таким образом, панель стала играть роль шлюза. При её поломке управление роботом будет потеряно. Но на тот момент это был единственный выход.

Аналогично тоже делал в похожей ситуации, вносили это решение в документацию и уведомляли заказчика (будущего владельца комплекса). Отдельный шлюз ставить заказчик не захотел, поэтому формально всё в порядке, хотя и структурно неправильно. А в Вашем случае, возможно, вообще всё в порядке, потому что отказ панели = отказ локального управления. А у Вас робот. Работа дистанционного управления при отказе локального, возможно, должна быть и невозможна. Если это так то почему бы и нет.

Только описание ваших китайцев звучит странно. Что значит "работа по 502 порту не гарантируется" ? Связь либо работает, либо нет, 502й TCP-порт либо предусмотрен, либо нет. А "не гарантируется" - они сами не знают чтоли? :) Хотя, от китайцев всего можно ожидать.

[Jackson]

Собственно всё что вам нужно это один поток с фиксированным временем цикла для ПИД-регуляторов и основной поток, в котором будут крутится все остальные процедуры.

А возможно ли это на панельке с кодесисом за 300 долларов - вопрос открытый. Мы задачи-то не знаем.

В конце концов, связка Кинко + Delta DVP по ценнику в тоже и выйдет. А если захочется задачи добавлять - то можно вешать на веревку дополнительно DELTA DVS SS на каждый новый комплекс задач. Правда, как любит напоминать Jaксson - усложнение системы - усложнение программирования - дополнительные деньги, причем не только на создание но и на обслуживание.

Так надо структуру всего комплекса продумывать, а не структуру только софта - чтобы оно получилось расширяемым с наименьшими затратами. По задаче сейчас 45 абонентов, будет 60.
В целом да, закон сохранения работает. Чтобы прибыло что-то хорошее, должно убыть что-то хорошее, например деньги и время. Деньги можно потратить на раздумья (время-то тоже денег стОит) чтобы потом не разоряться. А если сначала сэкономить - ждите трат потом. Но это всё лирика. Задачу надо знать. Без неё нет большого смысла в этих разговорах.

[Velt]

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

[+]

Только описание ваших китайцев звучит странно. Что значит "работа по 502 порту не гарантируется" ? Связь либо работает, либо нет, 502й TCP-порт либо предусмотрен, либо нет. А "не гарантируется" - они сами не знают чтоли? :) Хотя, от китайцев всего можно ожидать.

Я долго не мог понять, почему ПЛК регистры читает, но не пишет. Отключаю чтение - пишутся. Связь есть, робот показывает успешный коннект. ПЛК Delta AS228, модбас настраивается элементарно, проблем никогда не было. Какой-то непонятный баг с поддержкой модбасных функций....
Потом нашел такой текст в мануале, переведенного с китайского гуглопереводчиком:
"The Modbus port number in the teaching box is set to 10502, and the port
number of the network debugging assistant also needs to be set to 10502
(Note: The port number setting must be within the range of 10000~20000,
otherwise some system BUG may occur. If there is an abnormality in
communication, please Check the port number first)"