www.InTouch.su

Стоит InSQL 9.0. Архивируемые теги он получает из Archestra 3.0 SP2.

Вопрос1: Почему таблицы, в которых именно сохраняется информация по значениям тегов имеет суффикс OLEDB (пр. _, History_OLEDB),
и эти таблицы пустые (NULL), хотя значения в ActiveFactory у меня идут?

Вопрос2: Установил в Archestra в объекте у тега значение Force storage period равным 60000ms, а в InSQL они все равно пишутся
с намного большей частотой (1-5 сек), а в таблице Live в столбце wwRetrievalMode стоит вообще DELTA. Где вообще можно установить Storage Method?

Спасибо большое!

1. Информация по значениям тегов ни в каких таблицах SQL-сервера на самом деле не сохраняется, а пересылается через InSQL Server OLE DB Provider в процесс aahStoreSvc.exe для записи на диск в собственном формате блоков истории. Оттуда же они достаются процессом aahRetSvc.exe, опять же через InSQL OLE DB Provider. Снаружи выглядит как будто идёт работа с обыкновенными таблицами.

2. То что Вы видите в столбце wwRetrievalMode есть DELTA-режим запроса на выборку (delta retrieval mode). К тому в каком режиме данные были сохранены (delta, cyclic, or forced) это никакого отношения не имеет. Насколько я знаю, AppServer сохраняет данные в InSQL всегда в FORCED-режиме, что заставляет сохранять точку с новым временем даже если её значение не изменилось. Вы можете выбирать DELTA и CYCLIC режимы если собираете данные через IDAS.

beachbear
спасибо!
1. но в таблице live все равно можно посмотреть значения, но только мгновенные.. значит все таки sql все равно задействован.
2. insql сохраняет данные от ias в режиме forced. но сам appserver как я понял архивирует значения по delta и cyclic. причем естественно delta приоритетней.
значения с контролера приходят в формате 10 значений после точки (типа 1.0123456789) и потому значения меняются почти каждую секунду и сохраняются естественно каждую секунду по delta.

еще хочу уточнить. appserver использует mdas для архивирования данных. то есть когда в smc в настройках архивируемого тега я сменю текущий редактор ias на insql, то insql уже будет обрабатывать получаемые значения через idas? и еще когда я сменю редактора с ias на insql то настройки архивирования выставленные в appserver (типа force storage period, deadband) уже не будут влиять на значения переменной? то есть insql сам уже будет по своим собственным настройкам архивировать данные? :)

beachbear
еще раз спасибо!

1. Live показывает последние полученные значения с момента последнего старта системы. Они также достаются через InSQL OLE DB Provider aahRetSvc-сервисом, только не с диска, а из ActiveImage, который по сути есть кэш некоторого количества последних значений для каждого тэга и его метаданных.

2. Режимы сохранения DELTA, CYCLIC, и FORCED равноправны с точки зрения системы. Это просто разные правила обработки данных. Просто как-то в IAS решил, что IAS всегда будет использовать FORCED, который специально был для этого добавлен. DELTA по какой-то причине их не устроила. А в древних версиях InSQL Server вообще только один CYCLIC был.

3. "Текущий редактор" в свойствах тэга выполняет роль примитивной защиты от дурака. То есть если тэг был создан IAS-ом, то и редактировать его надо ТОЛЬКО через IAS. В этом вся его роль. Чтобы нельзя было просто открыть его в InSQL SMC и начать ковырять. Поскольку потом, когда придёт IAS использовать этот тэг, то можно огрести по полной программе. Конечно, желающие огрести проблем могут пойти напрямую в Runtime-базу и делать с теми тэгами что хотят.

beachbear
спасибо

удивляюсь такими вашими глубоким познаниям в процессах и алгоритме работы insql.
может поделитесь где вы почерпали столь большое количество информации. в разделе http://www.InTouch.ru/support/ про insql 7.x?

и еще пара вопросов - 1. что вообще есть режим forced в ias? для insql это понятно что принудительное сохранение полученных данных из ias.
2. и насчет защиты от дурака. если я могу зайти в свойства тэга в консоли и поменяв текущий редактор с ias на insql я могу делать с этим тегом что хочу. и показания все также будут сохраняться. где же тут защита?

еще раз спасибо!

Wonderware Historian Books Online, которые с продуктом идут, помноженные на многие годы ежедневных тренировок

IAS хочет САМ контролировать когда сохранять точку, и чтобы там InSQL не занимался самодеятельностью после того как точка ему отослана. Вот это и называеся forced.

Вот поэтому защита и примитивная. Если просто зайти в свойства тэга и редактор стоит IAS, то все поля заблокированы. Вроде как намёк юзеру - ничего не трогай. Ну а если любопытный юзер намёк не поймёт, редактор поменяет, начнёт менять свойства тэга, коммитить изменения в Runtime, то тут-то может начаться всё что угодно. Поскольку метаданные тэга на стороне IAS одни, а на стороне InSQL уже могут стать другими. Посылает IAS данные как 16-bit integer, а на сервере они уже не 16-bit integer, а 32-bit float. Где-нибудь да рванёт. Кроме того, если всё перезапустить, то IAS попытается переконфигуровать все свои тэги обратно как они у него в собственной базе описаны. Если подытожитть, то интерфейс с IAS-ом не то место, где я бы ставил эксперименты по живучести системы.

beachbear
спасибо :)

просто я завел этот разговор про выбор между idas и mdas редакторами из-за того, что в Объекте Автоматизации, из которого архивируются нужные тэги, я не мог ни где найти где сделать Description для каждого из этих тэгов. В TagList'e тренда Decription у всех моих тэгов имеет вид: The UserDefined object provides a starting point for creating custom built objects that include Discrete and _ Attributes, UDAs, Scripts, Extensions, or Contained objects.
А вот insql я спокойно нашел как заполнить этот Description. И настроек там куча. Не то что в Объекте Автоматизации.
Ну возможно я что-то не правильно делаю в ias :))