PDA

Просмотр полной версии : ООП в CoDeSys 3.5



RV9WFJ
09.02.2015, 08:09
Кто-нибудь уже начал использовать классы в CS? Интересно кто для чего использует, может кто-то даже кодом поделится. А то пока на форумах можно найти только "ООП в контроллерах не нужно, ФБ наше все". Интересно собственно дает ли это какие-то плюсы по гибкости кода или не стоит заморачиваться?

Yegor
09.02.2015, 09:47
ООП в контроллерах не нужно, ФБ наше всеНу а как же? ООП нужно там, где:

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

Без этого получается ООП ради ООП — лишний код, создающий иррелевантную структуру и видимость упорядоченности.

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

RV9WFJ
09.02.2015, 10:51
Я например рассматриваю ООП как мощный инструмент для написания библиотек пока. Учитывая сложность это получится только для себя конечно. Но мне кажется это будет удобно. Например сейчас думаю написать класс обработки входов с аналоговых датчиков. У меня уже все это есть в структурном виде, но я уже вижу что неудобно копировать весь ФБ ради изменения в нем одной строки. Возможно кто-то еще идеи для развития подкинет :-)

ASo
09.02.2015, 10:53
Повторяю - ООП нужно только ради полиморфизма. Где полиморфизм в вашем классе?

RV9WFJ
09.02.2015, 11:23
Ну как же - коды ошибок у всех типов датчиков одинаковые, а вот пересчет в физические величины разные. Плюс к тому у меня еще "правильное округление" для INT есть для всех типов датчиков.
P.S. Я еще не написал этот класс, пока только говорю, что он вероятно имеет место быть для опробирования ООП в CS.

ASo
09.02.2015, 11:29
А тогда смысл реализовывать это через ООП? Разбейте существующий ФБ на несколько. Для ООП Вы будете делать ровно этоже.

RV9WFJ
09.02.2015, 11:39
Все верно, но в конечном счете года через 2 года когда мне придется вернуться к старому проекту то я гораздо быстрее отыщу что изменилось в каком-то экзотичном датчике относительно стандартного 4..20 например. Мне так кажется пока.
Надо попробовать. Я сам пока до конца не понимаю нафига в CS ООП, вот и решил попробовать. Для этого и тему эту открыл, думал кто-то уже понял ЗАЧЕМ... :-)

Yegor
09.02.2015, 11:42
Возможно кто-то еще идеи для развития подкинет :-)Выкладывайте, не стесняйтесь. Подумаем. Как мне лично видится, для пересчёта редко требуется поддержка сложных состояний, и я такие вещи делаю одной-двумя функциями с кейсом.

ASo
09.02.2015, 11:46
Я сам пока до конца не понимаю нафига в CS ООП, вот и решил попробовать. Для этого и тему эту открыл, думал кто-то уже понял ЗАЧЕМ... :-)
Вот когда в программе появиться что то типа:
PPlant^.Work
Именно через указатель - тогда это будет правильное использование ООП. Но работа с указателями, как и динамическая память - это поперек идеологии МЭК программирования.

Yegor
09.02.2015, 11:54
Но работа с указателями, как и динамическая память - это поперек идеологии МЭК программирования.Однократные вызовы вообще поперёк циклического исполнения (лучше стабильно вызываемый код, который не меняет состояние, чем куча ветвлений). А значит и конструирование объектов в рантайме. И если все объекты должны быть известны статически, то отпадает жирный такой пласт паттернов. Куцое какое-то ООП выходит.
Именно через указательТут не соглашусь. Обращение через ссылку PPlant.Work семантически эквивалентно.

RV9WFJ
09.02.2015, 12:16
Это все конечно вы правильно говорите оба :-) но ООП в CS такое какое есть. Возможно доработают лет через 5 :-) Тут меня больше интересует использование того что есть сейчас.

capzap
09.02.2015, 12:32
где то в специфических объеках можно применить и ООП, например разные технологические операции, совершают одинаковые действия с температурой,а вот клапана могут открыватся в зависимости от задачи, вот тут легче иметь общий класс для работы с пидом, а методы управления клапанами в расширяемых классах, но утверждать что это ускорит существенно разработку проекта я бы всёравно не стал

Yegor
09.02.2015, 13:16
Если бы я текущий проект в третьем кодесисе делал, то симулятор установки и настоящую установку под одним интерфейсом обобщил бы может быть (симулятор цепляется на отдельный COM-порт ПЛК, а настоящая установка — через железные входы-выходы). Других поводов применить ООП на ПЛК за 3,5 года работы на предприятии не припомню.