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

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

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

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

Цитата:

---

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

Не хотелось бьі совсем отсебятину творить, потому решил спросить у знатоков.
Есть ПЛК. Управляет какой-то машинкой, у меня - весовой дозатор. Снаружи ПЛК есть панель (ИП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 задач они будут выполнятся в соответствии с последовательной!!! логикой вызовов ,никогда параллельно .

Цитата:

---

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

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

---

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

Цитата:

---

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

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

---

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

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

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

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

Цитата:

---

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

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

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

---

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

Цитата:

---

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

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

---

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

Цитата:

---

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

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

---

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

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

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

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

Цитата:

---

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

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

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

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

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

---

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

Цитата:

---

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

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

---

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

Цитата:

---

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

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

---

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

Цитата:

---

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

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

---

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

Цитата:

---

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

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

---

Создаем POU(PRG). В нем вызываем нужные группы POU. Все локальные переменные данной prg будут доступны всем вызываемым в нем POU. Все что нужно вынести за пределы prg объявляем входами и выходами, доступ к ним из любого места через точку.

Цитата:

---

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

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

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

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

---

тудьі качель ... Товарищ , без подвоха и чего-то там еще ... Скажите - что есть уже клава с украинской раскладкой ???

А Вьі нам так об’ясняли http://www.owen.ru/forum/images/smilies/smile.png- ну ладно :
Россиский функциональный блок - Шарик(Собака) у него на входе суп , котлеты , объедки со стола ... , на выходе - Гав,Гав .
прибалтийский функциональный блок - Шарикас(Тож собака(с);)) у него на входе шпроты и...объедки со стола ..., на выходе -Гавс , Гавс .

Цитата:

---

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

Создаем POU(PRG)

---

Спасибо. То есть, для своих нескольких процессов, которьіе я хочу видеть более-менее изолированньіми друг от друга, я создаю несколько PRG. Сама по себе PRG, как особенньій POU, позволяет включать в свою группу другие POU. Так? Бьіло бьі чудненько.
К сожалению, у меня не получилось. Я на PRG кликаю ПКМ, вьібираю в контекстном меню Add Object - а новьій POU создается на том же уровне, что и єта PRG. Что не так?

2 SergeyXXX: Вот без подвоха, скажи, а зачем такой жуткий over citation? Правда интересно.
Украинская раскладка, да. Мне проще между двумя работать, чем между тремя. Уже и привьік. Могу временно включить, если тебя достает. Ща... ЫЫЫ, палучилось!

В картинке порожденный POU, он не видит parent_local

Цитата:

---

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

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

---

может как то так

Цитата:

---

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

может как то так

---

Да, это работает. В 10 байтах кода накручено так, что пришлось запустить проект, чтобы понять :)
Иначе говоря, это пример передачи в ФБ ссылки на структуру, в которой данные "для него, единственного". Потом уже в самом блоке идут обычные обращения к элементам структуры через ее адрес.
Это примерно то, что я думал сделать, чтобы не передавать всю структуру. Только еще добавлена НАДструктура в глобальных, что мне и в голову не пришло. Ну да, если перетянуть share в область локальніх переменных PLC_PRG, то программа будет работать, но третьим лицам данные будут недоступны. Ага. Ясно.
Но как отговаривают все от указателей! Хотя я без них, как без рук.
Спасибо! Буду думать. В любом случае придется пересмотреть все переменные, которые набросал (всегда с неохотой, да) в глобальные.

ну можно обойтись и без указателей, просто в область ввода-выводо ПОУ добавить не указатель а просто структуру, а на вход чтото_глобальное.чтото_персональное того же пользовательского типа, но это как мне кажется создает нагрузку, ведь надо в начале выполнения считать данные, а по завершении записать данные, причем всю структуру полностью, а не изменения

Эт все очень умно , даже сверх умно .
Только неудобочитаемо .
Тов. из Киева , само то что вы создаете ФБ подразумевает передачу на входы ФБ чего-либо , и подключение выходов к чему-либо .
Я ведь на показал на примере ФБ "Собака" чуть выше .
Притянуть данные из одной структуры , состоящей из нескольких массивов с разнородными данными другой структуре ч-з указатели - это гут , использование указателей в конструкциях типа Вася+Маша= Ванечка , это ...

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

Цитата:

---

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

то что вы создаете ФБ подразумевает передачу на входы ФБ чего-либо , и подключение выходов к чему-либо

---

Да вовсе нет. Я создаю FB, т.к. это POU, имеющий память. Другой такой - PRG, не копируется в экземплярах.
И нет такой цели - передать что-то на входы и именно в классическом синтаксисе.

Цитата:

---

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

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

---

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

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

Я намеренно усугубил. Может быть, как раз для надежности я бы и поставил обращение из ФБ по указателю на структуру, передаваемому на вход ФБ. Но хочу получить подтверждение от вас, что это принципиально не меняет факта, что мы нарушаем заповедь "не юзать глобальных из ФБ".
Или я перепил?

Цитата:

---

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

Спасибо. То есть, для своих нескольких процессов, которьіе я хочу видеть более-менее изолированньіми друг от друга, я создаю несколько PRG. Сама по себе PRG, как особенньій POU, позволяет включать в свою группу другие POU. Так? Бьіло бьі чудненько.
К сожалению, у меня не получилось. Я на PRG кликаю ПКМ, вьібираю в контекстном меню Add Object - а новьій POU создается на том же уровне, что и єта PRG. Что не так?

В картинке порожденный POU, он не видит parent_local

---

ПОУ создаем обычным образом. Для удобства создаем несколько папок (для каждой группы свою). "Особенный" ПОУ в котором вызываем все программы, которые относятся только к этой группе и все эти ПОУ перетаскиваем в эту папку (на самом деле нет разницы где они будут находиться).
Локальные переменные "особенного ПОУ" в ПОУ группы передаем через входы.

Если POU в виде prg, то к переменной можно обращаться через точку. То есть можно задать кучу разнородных входных переменных и использовать этот ПОУ как структуру. Доступ к нему будет из любого места проекта.

Цитата:

---

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

Я намеренно усугубил. Может быть, как раз для надежности я бы и поставил обращение из ФБ по указателю на структуру, передаваемому на вход ФБ. Но хочу получить подтверждение от вас, что это принципиально не меняет факта, что мы нарушаем заповедь "не юзать глобальных из ФБ".
Или я перепил?

---

Сейчас (не буду выкладывать) сделал ФБ с выходом и с действием с глобальной переменной и , странно , обычное Ctrl+Space не хочет показывать глобалку , но мы ее все равно вводим и все выполняется , только результат в симуляторе странный , в ПЛК другой будет .
Отсюда вывод : сама возможность каких-либо действий с глобальными переменными внутри! ФБ это есть "косяк" КДС2 , в КДС3 , по моему (блин могу ощибаться , а проверять неохота , может позже) так не забалуешь .

Лично для меня вопрос использования ФБ только из-за выделения его экземпляру оперативы - это вопрос "Сферического коня в кубе и еще и в вакууме , растворенном в растворителе марки 650".
Для чего вам это ? Или вы используете опыт и наработки программирования микропроцессоров на СИ ? ... По ходу да?

Цитата:

---

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

Если POU в виде prg, то к переменной можно обращаться через точку. То есть можно задать кучу разнородных входных переменных и использовать этот ПОУ как структуру

---

ОК, но я еще не въехал, чем это отличается от глобальной структуры.
Интересный пример. Подумаю.

Цитата:

---

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

Лично для меня вопрос использования ФБ только из-за выделения его экземпляру оперативы - это вопрос "Сферического коня".
Для чего вам это?

---

Лично я не понимаю, зачем ограничивать функциональность ФБ запертом ему работать ему с глобальными переменными. Вот в тех программах на 600К - все ФБ работают так? Сколько (штук) глобальных переменных в подобном проекте? И какова максимальная длина списка входных-выходных переменных ФБ в таком проекте? Мне интересно расширить кругозор, правда. Узнать кое-что о стиле программирования под КДС. Может быть у вас там все сплошь PRG и им "разрешено" пользовать глобалку?

Цитата:

---

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

Может быть у вас там все сплошь PRG и им "разрешено" пользовать глобалку?

---

Да .
Дозатор - функциональный блок - вызываются 4 экземпляра с индивидуальными !!! глобальными переменными на входах и выходах .
Функциональный блок "Дозатор" на входе порядка 20 переменных (даже массивы ) и выходов разных штук 5(тоже есть массивы) .
Это не важно сколько входов-выходов , тут само отличие от программы есть наличие входов-выходов , конечно можно и программу так организовать , но это тоже будет изврат .

Хорошо, я подумаю. Спасибо.