ФБ vs функция + тип

Добрый день, форумчане.

Обнаружил, что CodeSys не позволяет присваивать значения локальным переменным функционального блока (т.е. тем переменным, которые объявлены между ключевыми словами var ... end_var).

Так как привык к такой возможности программируя на Step7, решил заменить ФБ связкой "функция + тип".

Продемонстрирую это на простом примере.
Так выглядит реализация (упрощенная) в ФБ:
FUNCTION_BLOCK Motor

VAR_INPUT
Command : INT;
END_VAR

VAR
State : INT;
Mode : INT;
END_VAR

А так выглядит связка "функция + тип":
TYPE MotorType :
STRUCT
Command : INT;
State : INT;
Mode : INT;
END_STRUCT
END_TYPE

FUNCTION ServMotor : BOOL
VAR_IN_OUT
Mtr : MotorType;
END_VAR

Ввиду малого опыта программирования на CoDeSys не могу оценить все плюсы и минусы одного и другого подхода.
Буду благодарен за мнения.

Конкретно хотелось бы получить ответы на следующие вопросы:
1. Почему CoDeSys не позволяет присваивать значения локальным переменным вне ФБ?
При этом между прочим работа через OPC-сервер CoDeSys позволяет менять значения локальных переменных.

2. Какой вариант будет выполняться быстрее?

объяви переменные как var_input или как var_in_out и будет тебе счастье.. просто var - это приватные переменные и могут меняться только внутри ФБ...

Цитата:

---

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

2. Какой вариант будет выполняться быстрее?

---

а так попробуйте

Krollcbas, имеется ввиду присваивание из вне ФБ. Внутри него разумеется менять значения своих же локальных переменных можно.

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

Пожалуй, что объявление их как var_input решает проблему. Привычные программисту формы написания кода иногда мешают при освоении других языков.

иногда даже приходится делать var_input retain :) ну по логике если вам приходится делать такие обращения то ваш код написан не правильно... FC и FB должны быть как законченный логический блок с интерфейсом входных и выходных данных ... тогда все будет красиво и понятно

Цитата:

---

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

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

---

у того же семена есть целый курс посвященный указателям, что в этом такого плохого для промавтоматики?
А в приведенном мною коде можно обойтись и без смещения на байты, а просто указатель сделать на конкретную переменную типа ADR(tester.bar);

Цитата:

---

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

.Пожалуй, что объявление их как var_input решает проблему..

---

Какую ?

Цитата:

---

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

если вам приходится делать такие обращения то ваш код написан не правильно..

---

+100^500
Перед Вами рулевое колесо и пара-тройка педалек.
Вы еще поршня хотите дергать ?

Цитата:

---

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

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

---

Ваш.
Нежелательно тому - кто не умеет.


Если где-то в степе (?) можно извне напрямую писать в var как в var_input - грош цена авторам этого.
var_input это не для левых ножек у квадратиков, а для описания интерфейса. Var для скрытия релиза.

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

Цитата:

---

созданы для скрытия релиза, то их нельзя было бы читать. Но их читать можно. Проверьте.

---

Если бы капот и головка блока были прозрачными - я б мог что-то сделать с поршнями ? Это повлияло бы на гарантию ?

Цитата:

---

ООП в языках высокого уровня и программирование в области промышленной автоматики - это разные вещи.

---

ООП - это способ программирования. А пром.автоматика или айфоноделие - по барабану.

Цитата:

---

Указатели...
Код становится быстрее, легче?

---

Бывает и так

Цитата:

---

Какие выгоды у разработчика от использования указателей при разработке кода ПЛК?

---

Если разработчик не видит выгод - он их не применяет. См. выше

Цитата:

---

На мой личный взгляд кроме ограничения проекта в наследуемости - выгод нет.

---

Личный взгляд

Цитата:

---

Сам учил использование указателей на сименовских курсах, далее примеров - не пошло.

---

Просто не столкнулись с нужными примерами.
О том кому можно применять указатели уже сказал

Цитата:

---

Язык аккумуляторов IL тоже преподавали)

---

Это наверное что бы у преподов была лишняя строка в программе обучения ))

ООП - это способ программирования. С этим никто и не спорит.
Вот только реальных инструментов для его реализации в языках МЭК61131 нет.
Есть попытки тех кто привык к хорошему структурированию программ, реализовать свою программу на языках МЭК в стиле ООП.

Но это все не предмет этой темы.

1. ФБ обращаются только к функциям и своим внутренностям.
2. Ничто не обращается ко внутренностям ФБ.
3. Функции обращаются только к своим внутренностям и другим функциям.
4. Программы состоят преимущественно из ФБ.
5. Гармония и реюзабельность.

Это не ООП. Это лишь его (но не только его) часть под названием инкапсуляция.

Вспомнил пример из собственной практики, когда в буквальном смысле пришлось использовать подход функция + тип, вместо ФБ.
Этот пример не совсем корректен здесь, так как случился на Сименсе. Но все же приведу. Мало ли кому пригодится где-то как идея.
В одном из проектов использовали S7-300. При написании кода был создан ФБ сушильная установка, код которого занимал где-то 60 Кб.
При отладке на PLCSim (имитатор контроллера в Сименсе) все работало отлично. Впоследствии, при наладке на реальном контроллере оказалось, что в контроллере блоки не должны превышать размера в 16 Кб.
Пришлось переменные ФБ сушильная установка сделать как тип, а весь код разделить на 4 функции (~ по 15 Кб), которые вызывать последовательно.

Цитата:

---

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

. был создан ФБ.., код которого занимал где-то 60 Кб..

---

За всю жизнь ни разу ни на чем не написал функции/процедуры/ф.блока/подпрограммы/ метода/свойства/прерывания.. более 2-4 визуальных страниц. Сейчас по возможности стараюсь укладываться в 10..20 строк. Старею.

да не, не стареете, у степа есть много особенностей, там если в инпутвар добавить указатель на структуру, ПОУ раздувается прилично, как только на вход такого ПОУ подать только нужные элементы структуры, объем сокращается, правда это касается языков кроме ST там размер не так сильно изменяется

Цитата:

---

Сообщение от Валенок

За всю жизнь ни разу ни на чем не написал функции/процедуры/ф.блока/подпрограммы/ метода/свойства/прерывания.. более 2-4 визуальных страниц. Сейчас по возможности стараюсь укладываться в 10..20 строк. Старею.

---

В контроллере обрабатывались 2 сушильные установки, т.е. фактически кроме вызова 2-х ФБ "сушильная установка" более ничего там не было.
Получается, что 60 Кб - это весь код контроллера. Разве это много?

Цитата:

---

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

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

---

А там точно именно указатель передается ? При передаче указателя неимеет значения размер структуры на какой он указывает.

Цитата:

---

ПОУ раздувается прилично,

---

Если раздувается конечный программный код, то допускаю что компилятор неявно генерит перед каждым обращением к указателю код с проверкой его на предмет указывания им на допустимую область памяти (и/или на null :p )

Цитата:

---

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

В контроллере обрабатывались 2 сушильные установки, т.е. фактически кроме вызова 2-х ФБ "сушильная установка" более ничего там не было.
Получается, что 60 Кб - это весь код контроллера. Разве это много?

---

Для всего проекта - норм. Туда ведь цепляются и системные вещи. Но если 60кБ это 1 программный блок, это не просто много, это п-ц.

Цитата:

---

Сообщение от Валенок

А там точно именно указатель передается ? При передаче указателя неимеет значения размер структуры на какой он указывает.



Если раздувается конечный программный код, то допускаю что компилятор неявно генерит перед каждым обращением к указателю код с проверкой его на предмет указывания им на допустимую область памяти (и/или на null :p )

---

я там на ST пишу, может и ошибаюсь, просто парень чтоб что то залить постоянно стопил плк, удалял ПОУ и только после этого загружал, кажется в объявлениях у него было имя UDT, это как бы не совсем указатель, но он мне показывал, что когда все элементы структуры отдельно заводил в аргументы, объем ПОУ сокращался на порядок

Что разрасталось - размер компилированого проекта / sizeof экземпляра / текст исходника ?

Цитата:

---

Сообщение от Валенок

Что разрасталось - размер компилированого проекта / sizeof экземпляра / текст исходника ?

---

в колонке size in the work memory отдельно взятого ПОУ на LAD, он на нем в основном пишет, но это не принципиально в степе

А изменяется ли этот размер при добавлении любого поля var но без изменения кода ?