www.InTouch.su

Добрый день!
Снова занимаюсь проектом на платформе.
Мне очень нужна подсказка: насколько я помню, в платформе нет понятия глобальных скриптов и функций. Но вот задача такая: почти для всего оборудования, на которое созданы шаблоны, должно быть окно ввода величин-уставок, набор и название абсолютно одни и те же. То есть, в другой скаде я реализовывала подобную задачу так: у меня есть функция, в которую я передаю имя устройства, и с помощью которой я заполняю окно данными, окно на весь проект одно, а нужные данные в него подставляются. В платформе я попыталась сделать подобное, но пока не очень успешно.
Можно просто добавить все это в каждый из шаблонов, но это трудоемко, как упростить?

Ну...
Можно было бы реализовать на платформе один объект (от отдельного шаблона) с окном ввода данных или доработать экземпляр платформы.
Первым вводится наименование оборудования (ID). У каждого экземпляра оборудование данное поле д. б. и д.б. уникальным.
Также на любом Engine есть перечень объектов, которые на него задеплоены и их кол-во. Наименование переменных Engine не помню, но в Obj View их найти не проблема. Т.о. можно организовать цикл по всем 100500 объектам Engine в поиске Tagname[i].ID == "искомое".
Ну и с найденным объектом делаем всё что угодно.
Ну а если Engine несколько, то несколько циклов.
Это если с разбегу решать.
У нас такое окно ввода уставок реализовано в корневом шаблоне-производном от A nalog Device, от которого уже реализованы все др. шаблоны. Точнее даже не так. У нас ВСЕ аналоговые шаблоны произведены от одного, который произведён от A nalog Device. Поэтому добавляя в него - добавляю везде. Вот.

Спасибо за ответ! Я тоже думала над шаблоном, в итоге я всё же "докрутила" вот так: в каждом шаблоне оборудования я завела теги-текущие уставки (мин, макс, реглам. мин и макс и т.д), указалы пределы (границы мин и макс), привязала их к нужным тегам скангруппы. Потом создала экземпляр от user-defined шаблона (для меня это инстанм-функция, назову его так), в этот экземпляре у меня есть перечень тегов: теги-текущие значения уставок изначально привязаны к некоторым константам, новые значения уставок (этот набор слов в проекте контроллера уникален, и используется как промежуточное поле для занесения новых значений и после посылки команды сохранения из этих слов значения переносятся в требуемые текущие значения уставок того или иного оборудования) привязаны сразу к тегам скангруппы. Когда я хочу вызвать окно уставок оборудования, я формирую скрипт, в котором передаю иерархическое имя экземпляра, пределы мин и макс, и номер команды, которой произведется сохранение, в соответствующие теги моего инстанса-функции и взвожу в 1 тег-условие, по которому выполнется скрипт перепривязки источника тегов-текущих значения уставок на конкретный инстанс в скриптах инстанса-функции. В графике этого инстанса-функции как раз лежит окно уставок, привязанное к тегам этого инстанса. И столбец новых уставок - это поля ввода значений. То есть, окно одно на проект, а теги в него подставляются то одни, то другие. Тут же и проверка на корректность ввода. Единственное, что мне не очень нравится - это задержка переписывания данных, то есть я открываю окно и прямо вижу, как значения меняются с одних на другие. Сначала сделала в одном скрипте и указание источника текущих уставок и сразу же присвоение новым значениям значений текущих, но вижу, что не успевает это отработать, текущие перепривязываются, а вот новые не успевают приравняться к текущим. Поэтому это присвоение я сделала в скрипте на на открытии окна уставок. Не знаю, как сократить задержки и от чего они зависят.
Скрин моего мучения, еще сырой, не до конца оформленный, покажу
http://radikal.ua/data/upload/4efc3/05615/84cadfa1bf.jpg

TEVAS писал(а):Не знаю, как сократить задержки и от чего они зависят.

Обычно они зависят:
- от "тяжести" окна (количество элементов вообще, динамизируемых в частности, всяких "рюшечек" в виде градиента цвета (видеокарта с InTouch практически не задействована, всё обрабатывает CPU), кол-во и размер скриптов в самом символе)
- от удалённости данных и качества связи (окно на АРМ-е, а данные - на WAS-сервере; при вызове окна данным ещё надо подтянуться с сервера на АРМ)
- от "железа" АРМ-а, многоядерность приветствуется, да и памяти 4 Гб мало не будет.
- от организационной структуры символа (его можно тупо нарисовать, а можно собрать из набора уже готовых и отлаженных подсимволов; но у каждого подсимвола могут быть свои скрипты и условия засветки и они также могут собираться из подсимволов, у которых ... {прямо как у мя в проекте }; соответственно при вызове символа начинается бурная деятельность - задержки)

У вас тоже такие задержки присутствуют, да? Я знаете как сделала - наложила поверх полупрозрачный прямоугольник и он видимый секунды 3, как раз пока там все переписывается, а потом он исчезает и данные готовы ))))))))))

TEVAS писал(а):У вас тоже такие задержки присутствуют, да?

Когда в окне 70-80 типовых эл-тов, каждый из которых состоит из десятка эл-тов, на каждом из которых есть анимация, задержки вполне объяснимы.

TEVAS писал(а):Я знаете как сделала - наложила поверх полупрозрачный прямоугольник и он видимый секунды 3, как раз пока там все переписывается, а потом он исчезает и данные готовы

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

Господа, и это мы обсуждаем продукт, который позиционируется как нечто инновационное и вообще продукт будущего.
Особенно понравилась фраза:

Генератор зла писал(а):Иногда задержки имеют свойство длиться дольше. Ничего, эксплуатация у нас не избалованная, и так терпит.

Заказчик при этом отвалил большую кучку денег за продукт и еще за разработку.

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

AirBus писал(а):Особенно понравилась фраза:
...

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

Можно создать базовый шаблон с атрибутами,скриптом, окном , которые являются одинаковыми для всех. Затем создать дочерние шаблоны - для каждого типа величин.
Например, нужно чтобы у давления,температуры,тока,расхода было окно с уставками min max. Создаём шаблон _ ,в него заносим min max и окно с уставками, также заносим нужные скрипты. Затем создаём шаблоны наследники Pressure , Temp и тд. Инстансы создаём от шаблонов - наследников. В итоге получим одинаковое окно и параметры для всех наследников. Сам сейчас так делаю, насколько это правильно- покажет практика.

Спасибо за идею! Я попробую еще по своему пути продвинуться, у меня работает, но напрягают задержки переписывания Возможно, потом буду переделывать. У меня уставки идут почти на каждую единицу оборудования свои. Например, есть шаблон конвейера, из него 5 инстансов создано, и у каждого из этих инстансов свои уставки, а не общие на все конвейера.. Короче, воюю. И с проектом, и с собой!