Вид для печати
Кто-нибудь уже начал использовать классы в CS? Интересно кто для чего использует, может кто-то даже кодом поделится. А то пока на форумах можно найти только "ООП в контроллерах не нужно, ФБ наше все". Интересно собственно дает ли это какие-то плюсы по гибкости кода или не стоит заморачиваться?
Ну а как же? ООП нужно там, где:Цитата:
ООП в контроллерах не нужно, ФБ наше все
- много объектов для обобщения;
- есть вероятность замены этих объектов на структурно отличающиеся, но похожие (либо тип объектов заранее неизвестен)
- объекты структурно сложные.
Без этого получается ООП ради ООП — лишний код, создающий иррелевантную структуру и видимость упорядоченности.
В кодесисе с ООП разве что многослойные протоколы обмена писать, но такие вещи обычно уровнем ниже поддерживаются. Ну или в серийных изделиях может пригодиться.
Я например рассматриваю ООП как мощный инструмент для написания библиотек пока. Учитывая сложность это получится только для себя конечно. Но мне кажется это будет удобно. Например сейчас думаю написать класс обработки входов с аналоговых датчиков. У меня уже все это есть в структурном виде, но я уже вижу что неудобно копировать весь ФБ ради изменения в нем одной строки. Возможно кто-то еще идеи для развития подкинет :-)
Повторяю - ООП нужно только ради полиморфизма. Где полиморфизм в вашем классе?
Ну как же - коды ошибок у всех типов датчиков одинаковые, а вот пересчет в физические величины разные. Плюс к тому у меня еще "правильное округление" для INT есть для всех типов датчиков.
P.S. Я еще не написал этот класс, пока только говорю, что он вероятно имеет место быть для опробирования ООП в CS.
А тогда смысл реализовывать это через ООП? Разбейте существующий ФБ на несколько. Для ООП Вы будете делать ровно этоже.
Все верно, но в конечном счете года через 2 года когда мне придется вернуться к старому проекту то я гораздо быстрее отыщу что изменилось в каком-то экзотичном датчике относительно стандартного 4..20 например. Мне так кажется пока.
Надо попробовать. Я сам пока до конца не понимаю нафига в CS ООП, вот и решил попробовать. Для этого и тему эту открыл, думал кто-то уже понял ЗАЧЕМ... :-)
Выкладывайте, не стесняйтесь. Подумаем. Как мне лично видится, для пересчёта редко требуется поддержка сложных состояний, и я такие вещи делаю одной-двумя функциями с кейсом.Цитата:
Возможно кто-то еще идеи для развития подкинет :-)
Вот когда в программе появиться что то типа:Цитата:
Сообщение от RV9WFJ
PPlant^.Work
Именно через указатель - тогда это будет правильное использование ООП. Но работа с указателями, как и динамическая память - это поперек идеологии МЭК программирования.
Однократные вызовы вообще поперёк циклического исполнения (лучше стабильно вызываемый код, который не меняет состояние, чем куча ветвлений). А значит и конструирование объектов в рантайме. И если все объекты должны быть известны статически, то отпадает жирный такой пласт паттернов. Куцое какое-то ООП выходит.Цитата:
Но работа с указателями, как и динамическая память - это поперек идеологии МЭК программирования.
Тут не соглашусь. Обращение через ссылку PPlant.Work семантически эквивалентно.Цитата:
Именно через указатель
Это все конечно вы правильно говорите оба :-) но ООП в CS такое какое есть. Возможно доработают лет через 5 :-) Тут меня больше интересует использование того что есть сейчас.
где то в специфических объеках можно применить и ООП, например разные технологические операции, совершают одинаковые действия с температурой,а вот клапана могут открыватся в зависимости от задачи, вот тут легче иметь общий класс для работы с пидом, а методы управления клапанами в расширяемых классах, но утверждать что это ускорит существенно разработку проекта я бы всёравно не стал
Если бы я текущий проект в третьем кодесисе делал, то симулятор установки и настоящую установку под одним интерфейсом обобщил бы может быть (симулятор цепляется на отдельный COM-порт ПЛК, а настоящая установка — через железные входы-выходы). Других поводов применить ООП на ПЛК за 3,5 года работы на предприятии не припомню.
Есть, оказывается, такая тема на форуме. Аж 2015 года:eek:
Короче пытаюсь разобраться.
1. Есть два насоса - один основной, второй резервный.
2. Есть интерфейс itfPump, в котором есть методы Start, Stop и разные свойства (готовность, в работе, превышение давления, сухой ход и т.д).
3. Создан ФБ classSupplyPump, который реализует этот этот интерфейс.
4. Созданы два экземпляра данного ФБ (по кол-ву насосов).
Теперь я создал ФБ, в который хочу передаю экземпляр нужного мне насоса (который сейчас выбран основным) и оперирую его методами.
Собственно вопрос. В чем будет разница между такими определениями входных переменных:
Вариант 1
На входе указываем объект, унаследованный от интерфейса
Вариант 2Код:FUNCTION_BLOCK FB_PUMP
VAR_INPUT
refPump: itfPump;
END_VAR
VAR_OUTPUT
END_VAR
VAR
END_VAR
На входе указываем ссылку на ФБ
Код:FUNCTION_BLOCK FB_PUMP
VAR_INPUT
refPump: REFERENCE TO classSupplyPump;
END_VAR
VAR_OUTPUT
END_VAR
VAR
END_VAR
Работает вроде и так и так. Но чую в чем-то все-таки есть разница, опыта пока не хватает понять в чем.
https://content.helpme-codesys.com/e...interface.html
"A variable of the interface type (itfPump) is a reference to instances of function blocks (classSupplyPump)"