Объектная модель в MasterScada 4D

[petr2off]

Добрый день.
Сформировал я наконец то для себя принципы построения объекта в MS4D в рамках об]ектного инструментария MS4D.
Сразу определимся с объектом (минимально) в MS4D. Объект это инкапсулированная сущность (т.е. библиотечный элемент), состоит из окон, параметров, процедур (методов) и других объектов. Теоретически доступ к объекту (точнее к его экземпляру) должен осуществлятся либо через атрибуты (объект.атрибут) либо через метод (объект.процедура(параметры)). Но тут вылазят 2 неприятных ограничения MS4D:
1) В экземпляре объекта MS4D параметры процедур становятся недоступными. Т.е. работа через методы (напрямую через параметры процедуры) невозможна.
2) Атрибуты окна, нельзя связывать с атрибутами в дереве объекта.
В результате, схема получается такая - создаются 3 реинкарнации атрибута:
a) Параметр окна, который связывается с атрибутами окна
b) Параметр процедуры, который связывается с параметрами окна.
с) параметр объекта, который связывается с параметрами процедуры.
Далее на основе библиотечного модуля, создается нужное количество экземпляров, и вот там уже параметры или теги проекта вяжутся с атрибутами экземпляра. Когда это все заработало, сильно удивился сам.

[keysansa]

Согласен, но ограничения по вызовам методов экземпляров объекта, характерны для всех SCADA. В основном, они работают со "свойствами" объекта. Свойства от параметров отличаются скрытыми методами доступа (при установке значения свойства - вызывается связанный метод, параметры устанавливаются напрямую, по ссылке). Это связано, как я понимаю, в основном, с экономией ресурсов.
Чистые методы, лучше не использовать в визуализации, а выделять их в отдельный объект.

[petr2off]

Есть исключения. Например WinCC OA. Но теперь то я наверно точно ее не попробую. :)

[keysansa]

Например WinCC OA. Но теперь то я наверно точно ее не попробую. :)

Почему? Сименс перестал принимать платежи в пиастрах?

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

Есть исключения. Например WinCC OA. Но теперь то я наверно точно ее не попробую. :)

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

[petr2off]

Да просто Сименс пока ничего не поставляет, мы с этим уже столкнулись.
Внутри объекта у меня есть процедуры которые занимаются, в том числе и упаковкой и распаковкой.
Дело в том, что я начинал с OpenScada - у которой довольно продвинутый инструментарий, с развитыми механизмами
для построение объектной модели. Поэтому, когда я столкнулся потом с WinCC и другими Скадами - было легкое неудобство.
Но если ты работаешь в этой сфере - будь готов работать с любыми инструментами, что конечно не отменяет их заточку под
твое понимание работы.

[keysansa]

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

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

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

Полностью с Вами согласен.

Поэтому, когда я столкнулся потом с WinCC

В TIA 16 объектную прадигму допилили вполне прилично.

[petr2off]

У меня только контроллер и сервер приложений, т.е. выносить некуда. И так все крутится на сервере приложений.

[petr2off]

Кстати, довольно интересное решение у Intouch в его System Platform. Там для системы состоящей из нескольких узлов, один узел объявляется репозиторием, и все обновления накатываются на него, а он потом распостраняет их по всем остальным узлам, но не огульно все - а то, на что они "подписаны". Т.е. узел имеет локальные копии того, с чем он работает и временное отключение сервера приложений, на его работу не влияет. Появилась сеть - синхронизировались. Правда администрирование все этого становится ужже не совсем тривиальной задачей.

[keysansa]

Там для системы состоящей из нескольких узлов, один узел объявляется репозиторием, и все обновления накатываются на него

У B&R в APROL похожая технология. Один из серверов выступает в качестве "сервера разработки". С него же и происходит обновление и панелей и SCADA и контроллеров. У меня не было настолько масштабных проектов, что бы APROL применить, но они давали свой сервер разработки на "пощупать" на пол-года. Это самая масштабная система, из того, что лично щупал.