ООП: наследование методов

[Savelij]

Коллеги, здравствуйте, я продолжаю погружаться в пучины ООП для ПЛК. Сейчас пишу реальный проект и уже по принципам ООП. Столкнулся с проблемой, с которой не сталкивался в других языках программирования. Описание проблемы:
- Есть базовый класс "Силовой элемент", где есть определенный список входов/выходов
- Есть три класса, которые наследованы от "Силового элемента" (т.е. на бумаге они наследуют все переменные и методы от родителя)
- Изначально у меня была написана просто функция, через которую я прогонял все три экземпляра трех наследников и я получал необходимый результат. Эта функция принимала входные переменные каждого экземпляра и несколько сторонних переменных, которые к экземплярам не относятся.
- Затем я вспомнил, что есть методы, которые логичнее использовать, раз уж пишу в ООП. Я написал метод для "Силового элемента", который представляет ту же логику, что была у меня в функции. И раз метод у родителя, следовательно наследуется этот метод для моих трех классов, т.е. теперь нет необходимости дергать три раза одну и ту же функцию, а можно вызывать "личный" метод каждого наследника. Отличие от функции было только в том, что для функции в списке входных переменных были и переменные наследников, а теперь в методе входными являются только переменные, не относящиеся к наследникам, только внешние.
- Проблема: некорректно работают эти методы, при мониторинге переменные очень странно работают в методах, т.е. есть три переменные (которые есть во всех трех классах), при их активации две из них работают в двух классах и не работают в третьем, третья переменная не работает в первых двух классах, но работает в третьем классе. (кручу-верчуха какая-то)
В общем, чувствуется, что эти три наследника цепляются ругаются между собой из-за каких-то параметров, но не могу найти проблему, и в целом не могу понять, почему проблема вообще есть, так как правила и логику наследования я знаю и применял в других ЯП. Здесь же все не очень очевидно. Если кто-то сталкивался с подобным или имеет мысли по сей проблеме, прошу в комменты. Заранее благодарю!

[keysansa]

Как писал Николас Вирт, любой ООП можно переложить в простые функции (с первым аргументом на ссылку на структуру переменных экземпляра класса).
Мое личное мнение - писать автоматику в ООП и проще и сложнее одновременно.
Автоматика должна реагировать не по изменению входного сигнала, а по любому изменению состояния.
ООП заточен на изменения состояния ввода/вывода.
При программировании сущностями и классами - очень большая ответственность на ревизию get-set и событий.
ЗЫ. Это при том, что среда программирования полностью поддерживает ООП, а не "обрезками".

[VADR]

Не, нафиг-нафиг ООП из АСУТП. Есть у меня один объект, который проектировщик написал с применением ООП. Вернее - не совсем ООП: сделано на симатике 1500, на SCL - там прямой поддержки ООП нет, вот он и сымитировал что-то похожее из структур и функций. В итоге: проект с двумя типами механизмов, первых - 6 штук, вторых - 10 штук, состоит из более чем сотни FC-шек на SCL, разобраться в которых практически нереально. Если бы это делалось на FBD или LD - хватило бы 16 FC, по одному на механизм. Однако, со слов разработчика - "графические языки в принципе непригодны к серьёзным проектам" :).

[keysansa]

В итоге: проект с двумя типами механизмов, первых - 6 штук, вторых - 10 штук

При разработке одного проекта - нет особой выгоды, однако, когда разрабатывается куча однотипных проектов, или один проект с кучей однотипных устройств - там очевиднее. Я, например, использовал "наследование" в FB на сименсе. Базовый "класс", например, шнек. Потом, "шнек и транспортер", это FB, которая внутри содержит и вызывает 2 FB базового "класса", потом, "шнек, транспортер и заслонка", уже внутри 3 вызова FB.

Однако, со слов разработчика - "графические языки в принципе непригодны к серьёзным проектам" :).

Я с ним согласен, попробуйте сравнить реализацию 30 одинаковых конвейеров на графическом и текстовом языке (особо, если текстовый язык поддерживаем массивы и циклы).

ЗЫ. В одно время участвовал в разработке ЧПУ для станка (простенькой, интерполяция только по одной оси), там main выглядел так:
cnc = new CCNC(*params);
cnc.run();
Так же, выглядели все методы, красиво, но очень много кропотливой работы.

Отправлено спустя 13 минут 48 секунд:
Вот, например, я один раз написал код, и далее, мне не важно, сколько у меня линий 1 или 100... Причем, при внесении изменений, они отразятся на всех 1 или 100 экземплярах

[+]

(***********************************************************************************
* Обработка линии и смесителя
***********************************************************************************)
FOR I:= 1 TO LINE_COUNT DO
LICycle.pBATicket:= ADR(BATicket);
LICycle.pMXTicket:= ADR(MXTicket);
LICycle.CheckState.MXDone:= MXCycle.State.TicketDone;
LICycle.CheckState.MXClosed:= MXCycle.HWStatus.Shiber.Closed;
LICycle.CheckState.MXEmpty:= MXCycle.Jobs.Empty;

LICycle[I]();
lSysOffSt[I].0:= LICycle[I].State.Enable;

vBaUlCountEqual[I]:= TRUE; // Число разгрузок дозаторов совпадает
vAllBaClosed[I]:= TRUE; // Все дозаторы закрыты
vAllBaUnloaded[I]:= TRUE; // Все дозаторы разгружены
vBADone[I]:= TRUE; // Все дозаторы завершили заявку
vMXEmpty[I]:= TRUE; // Смеситель пуст

MXCycle[I].Jobs.Mode.IsAuto:= LICycle[I].State.IsAuto;
MXCycle[I].Jobs.Mode.IsRun:= LICycle[I].State.IsMXRun;
// MXCycle[I].Buttons.RstShiftData:= LICycle[I].Buttons.RstSumm;
MXCycle[I].Jobs.EnableOnAdd:= TRUE;
MXCycle[I].Jobs.EnableOpen:= LICycle[I].State.Enable;// AND NOT (MXErrors.ShillSensors);
MXCycle[I].Jobs.EnableClose:= LICycle[I].State.Enable;
MXCycle[I].Jobs.EnableOn:= LICycle[I].State.Enable;
MXCycle[I].Jobs.Reset:= LICycle[I].Buttons.Reset;

#ifdef SIMULATE
LICycle[I].HWStatus.IsOn:= LICycle[I].oOn;
LICycle[I].HWStatus.CheckPhases:= TRUE;
LICycle[I].HWStatus.IsExist24v:= TRUE;
LICycle[I].HWStatus.IsExist220v:= TRUE;

MXCycle[I].HWStatus.On:= MXCycle[I].HWJobs.On;
MXCycle[I].HWStatus.CoverClosed:= TRUE;
MXCycle[I].HWStatus.Vibro:= MXCycle[I].HWJobs.Vibro;
// Симуляция воды в смеситель
IF (MXParams[I].AddWaterIPrice > 0) THEN
MXCycle[I].HWStatus.AddWaterPulse:= MXCycle[I].HWJobs.AddWater AND LICycle[I].State.Pulse05;
END_IF
#endif
END_FOR

[VADR]

попробуйте сравнить реализацию 30 одинаковых конвейеров на графическом и текстовом языке (особо, если текстовый язык поддерживаем массивы и циклы).

Я сравнил. В одном случае - на LD 3 десятка конвейеров, в основном - однотипных, в другом - те самые 10+6 механизмов. В первом случае - читаемая программа, во втором - какая-то каша. В первом случае структура программы видна невооружённым взглядом, во втором - структуру мне не смог объяснить сам разработчик.

Вот, например, я один раз написал код, и далее, мне не важно, сколько у меня линий 1 или 100...

Прекрасно. А потом пришёл я (эксплуатация) и мне надо отследить работу одной из этих линий. А возможно - внести в неё какие-то изменения.
Я совсем не против текстовых языков, но они хороши в свойм применении. Сделать какую-нибудь внутреннюю функцию, в которой нужна какая-то нестандартная математика - это да. А общая структура - только графические языки.

[petr2off]

В наладке, по крайней мере, графические языки значительно эффективней. Скажем для примера, я смотрю на кусок FBD Isagrafa, и по цвету сразу выделяю цепочку сигналов, приведших к блокировке исполнительного механизма. Потому что сама методология FBD ориентирована на такую группировку. Значимые сигналы группируются вокруг блока исполнительного механизма. В ST коде это не так очевидно. Это во-первых.
Во вторых, уровень датчиков и механизмов не предполагает использования очень навороченных алгоритмов, если это произошло - то скорей всего это архитектурная ошибка. Чем ближе к "полевому" уровню, тем проще алгоритмы, чем выше - тем больше интеллект. Скажем на уровне контроллера мне не разу не приходилось решать систему линейных уравнений. Хотя конечно бывают исключения, наверно.

[Sergy6661]

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

Если вам "повезло" с сторонним разработчиком, не способным описать собственные структуры данных (и, таки да, таких ...удаков сейчас навалом), то это не означает что надо прям так все под одну графическую гребенку.
Я переписывал собственный код с ST на LD, так вот на ST был реализован прекрасный лаконичный командоаппарат Case...end_case, на LD это тоже получилось реализовать с помощью костылей, но...красоты уже не было. Также и по наглядности графических языков- более чем спорно, прокручивать стопитцот нетворков так себе наглядность. Все от "писателя- художника" зависит.

А по теме- внедрителям-энтузиастам ООП в АСУ-ТП: ребятки, почитайте внимательно руководства по среде, так понимаю это или кодесис или Тиа и уясните таки разницу между функцией и функциональным блоком!

[Savelij]

Коллеги, всем спасибо, вопрос решен. Решение было в том, что таймеры я использовал теперь не глобальные, добавил в базовый класс, то есть теперь у каждого наследника свои таймеры. Видимо наследники дрались из-за общих параметров.

[keysansa]

Прекрасно. А потом пришёл я (эксплуатация) и мне надо отследить работу одной из этих линий. А возможно - внести в неё какие-то изменения.

А в чем проблема, открыть, DB и смотреть, отлаживать?

Я сравнил. В одном случае - на LD 3 десятка конвейеров, в основном - однотипных, в другом - те самые 10+6 механизмов. В первом случае - читаемая программа, во втором - какая-то каша.

Попробую угадать )) Текстовая программа была чужой? ))

Я сравнил. В одном случае - на LD 3 десятка конвейеров, в основном - однотипных, в другом - те самые 10+6 механизмов.

А теперь, сколько времени займет внесение изменения в алгоритм всех конвейеров (или исправления ошибок)? И какова вероятность, что при внесении этих изменений не будут внесены новые ошибки?

Отправлено спустя 4 минуты 11 секунд:

ST был реализован прекрасный лаконичный командоаппарат Case...end_case

Это удар ниже пояса ))
Но я делал универсальный FB на 16 шагов (для каждого шага вход условия входа на шаг, вход условия выхода и выход состояния).
Да и у Mitsubishi есть STL (вроде) - заточка case для графики.

Отправлено спустя 2 минуты 13 секунд:

Решение было в том, что таймеры я использовал теперь не глобальные

Использование глобальных переменных внутри класса - очень, очень плохая практика. Сделайте лучше еще одну переменную в конструкторе и передавайте по ссылке.

Отправлено спустя 1 минуту 25 секунд:

функциональным блоком!

FB является аналогом класса. А его DB - объектом (экземпляром класса).

Отправлено спустя 12 минут 23 секунды:

Если вам "повезло" с сторонним разработчиком, не способным описать собственные структуры данных (и, таки да, таких ...удаков сейчас навалом), то это не означает что надо прям так все под одну графическую гребенку.

В "графической гребенке" то же есть такие разработчики. Например, основной код на Step (да и TIA), что я вижу (и у наших и у немцев и у итальянцев и у китайцев) - попытка использовать FC, как функцию управления одним механизмом (или каким-то сложным действием механизма). Но внутри FC - глобальные меркеры, таймеры и несколько DB. Меня конечно напрягает, что внутри функции все переменные - глобальные, но не это главное. Главное в том, что из за лени, при внесении нового кода, программист уже не ищет FC, в которой данный механизм описан, а пишет код в любую FC, которая в данный момент открыта. И при реверсе программы (особенно, если она скачана с контроллера, или не озаботились коментариями) - очень сложно понять, что же делает эти 3 нетворка?

[VADR]

А в чем проблема, открыть, DB и смотреть, отлаживать?

Да нет проблем. Особенно, если надо одновременно отслеживать десяток переменных из разных DB - совсем просто. Можно ведь даже Watch Table создать и всё нужное в ней прописать - это практически так же быстро и просто, как крутнуть колесо мышки, чтобы перейти к другому нетворку, чтобы в онлайне смотреть его. (это был сарказм, если что)

Попробую угадать )) Текстовая программа была чужой? ))

Угадали :). Более того - они обе чужие!

А теперь, сколько времени займет внесение изменения в алгоритм всех конвейеров (или исправления ошибок)? И какова вероятность, что при внесении этих изменений не будут внесены новые ошибки?

А зачем в эксплуатации одновременное изменение алгоритмов работы всех конвейеров или большого их количества? Это из разряда системных проблем, которые должны решаться на ПНР. В эксплуатации чаще бывает необходимость решить какую-то локальную проблему, которая проявилась не сразу. К примеру (реальный случай) - один из конвейеров в некоторых условиях после остановки понадобилось чуть-чуть дёргать в обратную сторону. Зачем это было надо - уже не помню. Но вот как-то совсем нет желания ковыряться в наследовании методов, чтобы сделать этот один конвейер не таким, как все остальные.

[keysansa]

Да нет проблем. Особенно, если надо одновременно отслеживать десяток переменных из разных DB - совсем просто.

Это беда графики. Точнее, отсутствия ООП. В ООП - отлаживается узел. Если он отлажен и проверен, про него можно забыть. 1000 переменных нужно отлаживать как раз если написано безструктурно (а графические языки не умеют в структуру).

Угадали :). Более того - они обе чужие!

Тогда попробую еще раз угадать. Вы пишете на графических языках, на текстовых - опыт у вас меньше года.

А зачем в эксплуатации одновременное изменение алгоритмов работы всех конвейеров или большого их количества?

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

[VADR]

Это беда графики. Точнее, отсутствия ООП. В ООП - отлаживается узел. Если он отлажен и проверен, про него можно забыть. 1000 переменных нужно отлаживать как раз если написано безструктурно (а графические языки не умеют в структуру).

Напомню :)

(это был сарказм, если что)

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

Тогда попробую еще раз угадать. Вы пишете на графических языках, на текстовых - опыт у вас меньше года.

Опять мимо. С графическими языками работаю 22 года, с текстовыми - 34.

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

И что? Каждый новый аварийный грибок надо как минимум установить по месту, проложить кабель, прописать входной канал, проверить прохождение сигнала (в идеале, конечно, ещё в документацию его врисовать). После этого на каждый такой грибок в одном нетворке вставить один элемент - это проблема? К тому же, "с вероятностью чуть более 100% :)" времени на такую доработку не дадут от слова совсем. Агрегат должен работать и приносить деньги владельцу бизнеса. Поэтому - работу придётся делать фрагментами во время планово-профилактических ремонтов. Поэтому сделать всё это за один раз не получится и дорабатываться будет один-два конвейера за каждый подход.

[ZuElecRu]

И что? Каждый новый аварийный грибок надо как минимум установить по месту, проложить кабель, прописать входной канал, проверить прохождение сигнала (в идеале, конечно, ещё в документацию его врисовать). После этого на каждый такой грибок в одном нетворке вставить один элемент - это проблема? К тому же, "с вероятностью чуть более 100% :)" времени на такую доработку не дадут от слова совсем. Агрегат должен работать и приносить деньги владельцу бизнеса. Поэтому - работу придётся делать фрагментами во время планово-профилактических ремонтов. Поэтому сделать всё это за один раз не получится и дорабатываться будет один-два конвейера за каждый подход.

Поддержу: даже если в родителе прописывается нововдругпонадобившийся грибок, потом в вызовах каждого экземпляра все равно конкретный грибок прописывать. Быстро и элегантно конечно с точки зрения программирования, но это если ты "в курсе", а когда у тебя завод с зоопарком с 5-м и 7-м симатиками, тиапорталом, и еще парочкой омронов и ален бредли, что то как то нет времени вникать в наследование...Нет нам ремонтникам нафик этот ООП не нужен.

А вот тому, кто делает станки, машины и линии, ООП позволяет гнать серии с модификациями, собирая программу как из кубиков. Хорошо когда производитель машин доступен для модификации. Обычно он или самобанкротится или цену ломит.

[Sergy6661]

ООП позволяет гнать серии с модификациями, собирая программу как из кубиков

Только не ООП это, а "концепция" экземпляров функционального блока с выделенной памятью экземпляра и это часть "концепции" пресловутого ООП и этого вполне достаточно, чтобы использовать во всех МЭК языках и это нормально и правильно.
Но когда вот это происходит

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

получается полная хренотень, потому что это просто не правильно и языки тут не при чем, как впрочем и ООП.

[keysansa]

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

Такое постоянно. К узлу есть требования, он их должен выполнять. А для того, что бы при изменении узла с целью исправления, не пропустить внесение ошибок в логику работы - придуман NUnit (класс после изменения подвергается критическим тестам в автоматическом режиме, по результатам которых, решается судьба изменений).

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

Это вы пишете только "на себя" - для одного предприятия. Мне же завтра может поступить от одного из клиентов, совершенно не совместимая со всеми другими клиентами задача (ну, например, их директор где-то что-то прочитал или услышал). Дал бюджет, почему не попробовать? Но аварийные ситуации класс должен отработать. NUnit позволит это, плюс, можно написать проверку важных рабочих ситуаций. Да, это занимает кучу времени (раз в 10 больше, чем, просто написание логики работы), однако при наличии нескольких "одинаковых" проектов - существенно экономит время.
Написал, перечитал, и подумал, что вы не поймете ООП, если всю жизнь обслуживаете 5-10 проектов.. Когда у вас их будет под 50 - тогда придет понимание )

Отправлено спустя 1 минуту 23 секунды:

Отслеживать нужно столько переменных, сколько участвуют в процессе.

Полностью согласен. Вопрос их (переменные) найти. Если они все локальные - они все в заголовке.

Отправлено спустя 7 минут 53 секунды:

Насчёт структуры - вернусь из отпуска, сделаю нсколько скриншотов для сравнения: кто в структуру умеет, а кто - нет.

Всегда нравилось смотреть чужой код, с удовольствием посмотрю!

Опять мимо. С графическими языками работаю 22 года, с текстовыми - 34.

По моему - это первый раз мимо ))

И что? Каждый новый аварийный грибок надо как минимум установить по месту, проложить кабель, прописать входной канал, проверить прохождение сигнала (в идеале, конечно, ещё в документацию его врисовать). После этого на каждый такой грибок в одном нетворке вставить один элемент - это проблема?

Не в одном, а в каждом, в вашем случае. При использовании ООП - в одном месте. И при том, вы написали еще кучу работы, которую надо сделать. И НИЧЕГО НЕ ЗАБЫТЬ И НЕ ПРОПУСТИТЬ. А когда работы меньше - она менее утомляет.

К тому же, "с вероятностью чуть более 100% :)" времени на такую доработку не дадут от слова совсем. Агрегат должен работать и приносить деньги владельцу бизнеса.

Тут как раз спасает NUnit (точнее его ядро - тесты). И чем больше работаешь над проектом, тем больше тестов можно сделать, а потом, по результатам, отслеживать, какой гемор предстоит из-за "новых хотелок".

Поэтому - работу придётся делать фрагментами во время планово-профилактических ремонтов.

Но да, все равно, даже уверенный в том, что код работает как надо, я все равно изменения вношу только тогда, когда машина остановлена. Есть еще и БД, графика, и железо ))

ЗЫ. Это все применимо и для графического языка и для текстового. Однако, все тесты занимают память в графических языках. В текстовых есть препроцессор (ifdef TEST), который исключает тесты из кода, если это релиз программы.

[VADR]

Написал, перечитал, и подумал, что вы не поймете ООП, если всю жизнь обслуживаете 5-10 проектов.. Когда у вас их будет под 50 - тогда придет понимание )

И опять мимо. Уже за 50 :)

По моему - это первый раз мимо ))

Первый раз - предположение, что одна из программ не моя.

Не в одном, а в каждом, в вашем случае. При использовании ООП - в одном месте. И при том, вы написали еще кучу работы, которую надо сделать. И НИЧЕГО НЕ ЗАБЫТЬ И НЕ ПРОПУСТИТЬ. А когда работы меньше - она менее утомляет.

В одном месте? Я напомню, что времени на работы толком не дадут, поэтому делать придётся фрагментами. Поэтому - в одном месте прописываем общую для всех обработку новой аварийной кнопки, и сразу - во всех местах, где она пока физически не установлена, ставим какие-то заглушки, которую потом, когда кнопки всё-таки расставят, надо будет переключать на физические сигналы. Так? Как бы количество работы получаеся нифига не меньше...

[keysansa]

И опять мимо. Уже за 50 :)

Ок, снимаю шляпу.

Первый раз - предположение, что одна из программ не моя.

Вы за "мимо" предположения считаете? ))

В одном месте? Я напомню, что времени на работы толком не дадут, поэтому делать придётся фрагментами.

Нет, в вашем случае в N местах, я про это написал. Вы похоже не прочитали перед коментированием, или не поняли...
ЗЫ. Заглушки... Вам же противоречат:
"Надо использовать все переменные, участвующие..."