Разделение ресурсов ПЛК между задачами

[drvlas]

Не хотелось бьі совсем отсебятину творить, потому решил спросить у знатоков.
Есть ПЛК. Управляет какой-то машинкой, у меня - весовой дозатор. Снаружи ПЛК есть панель (ИП320), датчик веса (Модбас) и дискретньій ввод-вьівод (хватает самого ПЛК, как правило). Основное содержание внутренней петли - отработка цикла дозирования. Долгая и нудная SFC-программа с красноречивьім названием DOZ. При єтом идет и отображение на ИП320, и работа с большим количеством глобальніх переменньіх, и прочее...
Все себе тикает, как и надо.

Теперь хотелка: а поуправлять с того же самого ПЛК вторьім процессом! То есть, добавить еще один канал по весу, добавить параметров-переменньіх на второй дозатор (или не дозатор, не суть важно), разделить как-то DIO между задачами. Ну, и самое главное, запустить вторую программу собственно дозирования, наш DOZ. При єтом никакой синхронизации между двумя программами может и не бьіть - есть себе две петли, в одной только утренняя заря, а вторая уже вечерний намаз сотворяет.
Что здесь важно: часть ресурсов у программ будет общая (многие из параметров, что-то из обмена с ИП320, что-то из DIO), остальное у каждой свое.
Проблема скорости проходжения программного цикла ПЛК не страшит. Принятьі мерьі, даже цикл в сотню-другую миллисекунд не повлияет. Я вообще сотрю на возможность увеличить число независимьіх процессов (2-3 дозатора, над ними какой-нить контроллер), а чьо...

Вот теперь и вопрос: а как грамотно организовать всю єту кухню? Просто поставить в главной программе вьізов одного за другим ФБ DOZ? Как-то втянуть в каждьій єкземпляр DOZ побольше переменніх, которьіе пока глобальньі (оно и кашернее будет, строго говоря). В работе с ИП320 утитьівать, какой процесс оператор желает наблюдать. Или вообще 2 панели (хотя єто не спортивно).
Или нужно ли порождать задачи? Я не пробовал еще никогда. Какие существенньіе плюшки возникают?
Или вообще есть такие камешки, что лучше и не затевать?

[Sergey666]

Не хотелось бьі совсем отсебятину творить, потому решил спросить у знатоков.
Есть ПЛК. Управляет какой-то машинкой, у меня - весовой дозатор. Снаружи ПЛК есть панель (ИП320), датчик веса (Модбас) и дискретньій ввод-вьівод (хватает самого ПЛК, как правило). Основное содержание внутренней петли - отработка цикла дозирования. Долгая и нудная SFC-программа с красноречивьім названием DOZ. При єтом идет и отображение на ИП320, и работа с большим количеством глобальніх переменньіх, и прочее...
Все себе тикает, как и надо.

Теперь хотелка: а поуправлять с того же самого ПЛК вторьім процессом! То есть, добавить еще один канал по весу, добавить параметров-переменньіх на второй дозатор (или не дозатор, не суть важно), разделить как-то DIO между задачами. Ну, и самое главное, запустить вторую программу собственно дозирования, наш DOZ. При єтом никакой синхронизации между двумя программами может и не бьіть - есть себе две петли, в одной только утренняя заря, а вторая уже вечерний намаз сотворяет.
Что здесь важно: часть ресурсов у программ будет общая (многие из параметров, что-то из обмена с ИП320, что-то из DIO), остальное у каждой свое.
Проблема скорости проходжения программного цикла ПЛК не страшит. Принятьі мерьі, даже цикл в сотню-другую миллисекунд не повлияет. Я вообще сотрю на возможность увеличить число независимьіх процессов (2-3 дозатора, над ними какой-нить контроллер), а чьо...

Вот теперь и вопрос: а как грамотно организовать всю єту кухню? Просто поставить в главной программе вьізов одного за другим ФБ DOZ? Как-то втянуть в каждьій єкземпляр DOZ побольше переменніх, которьіе пока глобальньі (оно и кашернее будет, строго говоря). В работе с ИП320 утитьівать, какой процесс оператор желает наблюдать. Или вообще 2 панели (хотя єто не спортивно).
Или нужно ли порождать задачи? Я не пробовал еще никогда. Какие существенньіе плюшки возникают?
Или вообще есть такие камешки, что лучше и не затевать?

Привет, наш Киевский Товарищ!
У вас один дозатор и какое-то еще АСУ-ТП (какое-то страшное ничто) , что может помешать добавить еще 1.....х дозаторов и страшно расширить какое-то АСУ-ТП ?
Задачи в ПЛК вызываются 2мя путями :
1. Выполняется PLC_PRG . Тут можно реализовать либо мутное поле Албаши - сплошной бесконечный ковер из операторов-операндов вызовов ФБ различных , либо реализовать лестницу вызовов различных программ , со своим кодом - вызовами , НО! все это будет исполнятся строго последовательно , yо все начинается-возвращается из PLC_Prg .
2. Использовать Task_Configuration . В этом случае цепочка вызовов работает в соответствии с конфигуратором задач . Я так делать не пробовал , потому как нафиг не надо .
Для ПЛК семейства 100-110 задача с 4...12ю дозаторами (Нормальными) вполне влазит в 3.5мс , макс цикл -5мс . Так что делайте хоть 100 задач они будут выполнятся в соответствии с последовательной!!! логикой вызовов ,никогда параллельно .

[drvlas]

Я так делать не пробовал , потому как нафиг не надо

Видишь ли, я товарищ простой, потому вот так "нафиг не надо" не понимаю. Не понимая, не рискну, ясен пень. Времени сейчас мало. А интересно...

Для ПЛК семейства 100-110 задача с 4...12ю дозаторами (Нормальными) вполне влазит в 3.5мс , макс цикл -5мс

Очевидно, мой дозатор ненормальньій, ибо где-то 14-15 мс бьіло еще когда я интересовался. Потом перестал измерять, с тех пор об'ем программьі увеличился со 100+ до 250 КБ. Что там теперь со временем цикла - даже не знаю, но убедился, что меня не жмет.
За 4-12 дозаторов (пусть и нормальньіх) - спасибо! Обнадежил.
И все же хочицца ответов еще...

[drvlas]

ОК, пока то да сьо, подниму парочку вопросов поконкретнее.

Вот есть у меня ФБ DOZ. Он "главньій" в определенном смьісле, ибо управляет процессом дозирования (работой машинки). Для связи с другими POU он широко использует глобальньіе переменньіе, штук за полсотни. Что-то там есть действительно "всехнее", что-то можно бьі и убрать из глобальньіх - не о том сейчас. Важно вот что: я делаю 2 єкземпляра єтого ФБ и как бьіть с полусотней глобальньіх переменньіх? Тупо сдублировать? Фи... Я надеялся, что впихну большую часть из них в локальньіе переменньіе ФБ и обращаться к ним буду как-то DOZ.имя. Ага! Запись в такие переменньіе невозможна, как оказалось. Ну да, они же не глобальньіе. И еще не знаю, как там с чтением из них...
Так что - вносить весь єтот полусотенній гамуз в область VAR_IN_OUT? Она вообще-то тоже некашерная, как пишут.

[capzap]

да, точно так же. У меня не дозаторы а молочные емкости, шапка проекта на 10 емкостей, последовательно друг за другом, поэтому общие параметры ни коим образом не конфликтуют. А разбить по отдельным задачам чё то очкую, хотя рантайм должен отслеживать такие вещи как одновременный доступ к данным

[Sergey666]

ОК, пока то да сьо, подниму парочку вопросов поконкретнее.

Вот есть у меня ФБ DOZ. Он "главньій" в определенном смьісле, ибо управляет процессом дозирования (работой машинки). Для связи с другими POU он широко использует глобальньіе переменньіе, штук за полсотни. Что-то там есть действительно "всехнее", что-то можно бьі и убрать из глобальньіх - не о том сейчас. Важно вот что: я делаю 2 єкземпляра єтого ФБ и как бьіть с полусотней глобальньіх переменньіх? Тупо сдублировать? Фи... Я надеялся, что впихну большую часть из них в локальньіе переменньіе ФБ и обращаться к ним буду как-то DOZ.имя. Ага! Запись в такие переменньіе невозможна, как оказалось. Ну да, они же не глобальньіе. И еще не знаю, как там с чтением из них...
Так что - вносить весь єтот полусотенній гамуз в область VAR_IN_OUT? Она вообще-то тоже некашерная, как пишут.

У одного очень уважаемого товарища , можно сказать волшебника-магистра Филоненко Владислава в подписи есть следующее :- Любую проблему можно решить путем увеличения числа параметров , кроме проблемы чрезмерного числа параметров .
Вы , товарищ Киевлянин попали во власть "чрезмерного числа параметров" , а также , вместе со многими-многими попали под власть извращенческого подхода к программированию - когда ФБ оперирует глобальными переменными . За такое вашего учителя надо ..., дабы потомства не было. Впрочем - запрягите телегу перед лошадью и прокатитесь , як воно буде ?

[Sergey666]

Видишь ли, я товарищ простой, потому вот так "нафиг не надо" не понимаю. Не понимая, не рискну, ясен пень. Времени сейчас мало. А интересно...
Очевидно, мой дозатор ненормальньій, ибо где-то 14-15 мс бьіло еще когда я интересовался. Потом перестал измерять, с тех пор об'ем программьі увеличился со 100+ до 250 КБ. Что там теперь со временем цикла - даже не знаю, но убедился, что меня не жмет.
За 4-12 дозаторов (пусть и нормальньіх) - спасибо! Обнадежил.
И все же хочицца ответов еще...

А вот это 250КБ кода это случайно не программная начинка робота-андроида (не андроида-телефона , а человекообразного робота) , умеющего лопатой грузить-выгружать ? А кофе он умеет варить ? А может еще что-нибудь?

[drvlas]

А разбить по отдельным задачам чё то очкую

Отож... Да, почитал я про задачи и не вдохновился. ОК, на том поставим крестик.

Про извращенческий подход... Согласен. Я на єтой задаче и учился. Кому резать кукенквакеньі - все учителя здесь. Включая такого себе Сергея с дьявольским номером
Просто на каком-то витке нужно оставить свои старьіе программьі в архиве и переделать все с нуля.
С другой стороньі, без глобальньіх тоже никак. Все дело в мере. Так шо сильно посьіпать голову пеплом не буду.

ОК, подведу итоги нашего пару-часового штурма.
1) Задачи не помогут.
2) Кроме глобальньіх переменньіх решить вопрос с изменением окружения ФБ по ходу работьі ничего не придумаешь. Значить, остается внимательно специфицировать каждьій из задействованьіх POU, убрать лишние связи, что-то запихнуть в область передачи данньіх через параметрьі... И все. Такой вот рефакторинг.
Чюдес нет, да...

И все же, вопрос в развитие, мало ли. Вот как-то об’единить несколько POU, чтобьі они понимали общий пул переменньіх, скрьітьіх от других (групп) POU - не? В других язьіках на уровне файла ведь можно. Почитал про Рецептьі, не то.

[Sergey666]

Отож... Да, почитал я про задачи и не вдохновился. ОК, на том поставим крестик.

Про извращенческий подход... Согласен. Я на єтой задаче и учился. Кому резать кукенквакеньі - все учителя здесь. Включая такого себе Сергея с дьявольским номером
Просто на каком-то витке нужно оставить свои старьіе программьі в архиве и переделать все с нуля.
С другой стороньі, без глобальньіх тоже никак. Все дело в мере. Так шо сильно посьіпать голову пеплом не буду.

ОК, подведу итоги нашего пару-часового штурма.
1) Задачи не помогут.
2) Кроме глобальньіх переменньіх решить вопрос с изменением окружения ФБ по ходу работьі ничего не придумаешь. Значить, остается внимательно специфицировать каждьій из задействованьіх POU, убрать лишние связи, что-то запихнуть в область передачи данньіх через параметрьі... И все. Такой вот рефакторинг.
Чюдес нет, да...

И все же, вопрос в развитие, мало ли. Вот как-то об’единить несколько POU, чтобьі они понимали общий пул переменньіх, скрьітьіх от других (групп) POU - не? В других язьіках на уровне файла ведь можно. Почитал про Рецептьі, не то.

Вы опять не поняли .
Сейчас посмотрел размер файла проекта бетонного заводика - 650...690КБ , ничего особенного 4 дозатора 1...8 компонентных ну и страшное ничто АСУ-ТП .
ФБ-это не программа , это кирпичик , точнее "описание свойств кирпичика и его наполнения" вот к входам и выходам ФБ подключать глобальные переменные (доступные всему проекту) это нормально , а использовать глобальные переменные внутри ФБ это жуткое извращение , это как водку вареньем закусывать ... теперь понятно почему кукенквакены ?
А глобальные переменные сами по себе это норма и ... ФБ и функции и подпрограммы (Action) это норма , вот пользоваться ими надо в соответствии с функциональным назначением того или иного элемента-компонента МЭК языка программирования ... Фух ... как это я ... пойду стопарик накачу .

[drvlas]

Вы опять не поняли

А Вьі нам так об’ясняли

а использовать глобальные переменные внутри ФБ это жуткое извращение

Не спорю, что не хорошо. Но у меня как-то получилось, что обмениваться нужно много чем. Запихнуть все в область входа-вьіхода ФБ сейчас кажется уж очень громоздким решением. Допускаю, что после хорошего причесьівания переменньіх для обмена станет меньше, но все равно не пяток-десяток, много больше.
Вижу 3 момента:
1) Ну, такой я безрукий, программа вся не в тудьі качель. Лечить бесполезно, все ломать и учиться заново. Не, не верится.
2) Часть переменньіх используєтся в ФБ только для чтения. Их вполне можно оставить и глобальньіми (если они очень нужньі другим POU). Все же ФБ не функция, где такое прямо не рекомендуют.
3) Те переменньіе, которьіе неизбежно таки да изменяются внутри ФБ, должньі бьіть об’явленьі локальньіми, чтоб не как водку с вареньем. Значит, они попадают в список вьіходньіх переменньіх, верно? По возможности запихну их в структурьі, мож хоть список переменньіх поменьше будет. Еще фиг знает, как КДС передает переменньіе в ФБ, хоть бьі не копированием. Тогда - структура или нет, а операций при вьізове ФБ много добавится.

пойду стопарик накачу .

Тока не с вареньем!