WinCC 5. Таблицы
Павел
Берляков; 27.12.01
Здравствуйте.
Подскажите, кто знает, почему в таблицах (элемент WinCC online
table control) шрифт - перечеркнутый.
Font сконфигурен (в свойствах таблицы) без подчеркивания. Может
быть, где-то еще оговаривается это свойство ?
Интересно, что часть колонок в таблице - то с подчеркиваниемя, то
без. Цикл обновления Picture objekt 2 секунды. Цикл
Arhiving/Display cycle в TagLogginge - 5 c.
Заранее благодарен.
Re: WinCC 5. Таблицы
Dr. Kren; 29.12.01
А вот это - отдельная тема.
И не на один вопрос-ответ.
Я сам нарвался на подобную ситуацию, но у меня цикл архивирования
НЕ МЕНЕЕ 300 секунд !!!
Я так понимаю, что разработчики WinCC если и думали о чем-то, то не
о разработке действительно промышленной системы HMI, т.к. уже оно
только определение "промышленный процесс" подразумевает ведение
статистики результатов работы процесса с высокой точность,
надежностью и долговечностью.
Проблема не в "WinCC online table control", а в TagLoggin. А точнее
не в нем самом, а в способе организации структуры архива.
----------------------------------
ТАКОГО БРЕДА я еще не встречал !!!
----------------------------------
Пример: сохраняем в чении 300 секунд с частотой в 1 секунду в архив
три тега с целочисленными значениями (тип тега не важен - важно
время записи и интервал записи). Можно подобрать и другой пример
(это "товарищам" из Siemens).
Для этого создаем архив для хранения этих самых тегов.
Что делает WinCC?
Имея в своем составе достаточно мощный SQL сервер "Sybase Adaptive
Server Anywhere" (на www.sybase.com проходит как ASA, ASE -
Adaptive Server Enterprise) и не особенно напрягая мозги WinCC
формируе ТРИ таблицы для хранения этих самых тегов.
Структура у этих таблиц следующая.
1-е поле "Т" - дата и время записи в архив.
2-е поле "V" - значение тега.
3-е поле "F" - что оно дает - так и не понял. В нем только два
значения - 0 или 64. Логики появления того или иного значения я не
нашел.
Для каждого из тегов можно назначить свое событие для записи. Да,
это удобно.
НО АБСОЛЮТНО БЕССМЫСЛЕННО!
Гораздо удобнее разбить все теги по событиям архивирования на
группы, из этих групп создать архивы, А ДЛЯ АРХИВА НАЗНАЧИТЬ
СОБЫТИЕ ЗАПИСИ.
Мы ведь записываем не три несвязных параметра, а три логически
неразрывных значения, например вес (самая сложная и довольно частая
задача). Вес пустой емкости перед заполнением, вес полной емкости
после заполнения, вес пустой емкости после опорожнения (это
реальный случай, цикл архивирования не менее 300 сек). Так как
емкость проходит все три процедуры, то мы назначим одно событие для
архивирования написав UserFunction и привяжем к этим трем тегам
дабы иметь в одной строке все три веса. Это логически, а физически
в параллельных строках трех разных таблиц.
Я не использую циклическую запись по той простой причине, что в
реальной жизни в 95 случаях из 100 (не берем значения датчиков для
последующего отображения в трендах) запись нужно производить по
событию, т. е. заранее нельзя сказать когда наступит условие. Вот
эту ситуацию мы и моделируем.
Итак, с частотой в одну секунду мы производим запись в архив. И вот
тут-то мы и попадаем в капкан. Видимо, "товарищам" из Siemens чуждо
понятие реляционных моделей баз данных, и далее логики "dBase III+"
у них мозгов не хватает. Не даром они рекомендуют для обработки
больших массивов данных преобразовывать архивы в формат dBase.
Что получается? Событие для записи в архив как-бы одно. Но
результат разный.
1-й тег.
В момент создания записи в таблице WinCC заносит дату и время ее
созданиия + заполняет остальные поля.
2-й тег.
В момент создания записи в таблице WinCC заносит дату и время ее
созданиия + заполняет остальные поля.
3-й тег.
В момент создания записи в таблице WinCC заносит дату и время ее
созданиия + заполняет остальные поля.
И как результат сам WinCC разрывает логику между записями в
таблицах. Разрыв в 1 секунду между появлениями записей в трех
таблицах (одно архивирование трех тегов) если не норма, то уж
явление ОЧЕНЬ ЧАСТОЕ.
Теряется всякая корреляция между данными. Если вдруг по каким-либо
причинам в одной из таблиц (тегов) значение не будет записано
(система имеет высший приоритет перед другими процессами, а
дисковые операции высший приоритет в системе, а они-то как раз как
правило самые длительные), либо записано с опозданием (основание
выше), получаем что
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
НИКТО И НИКОГДА НЕ СМОЖЕТ С УВЕРЕННОСТЬЮ СКАЗАТЬ, ЧТО ТРИ РАЗНЫХ
СТРОКИ В ЭТИХ ТРЕХ ТАБЛИЦАХ ПОЯВИЛИСЬ ПО ОДНОМУ И ТОМУ-ЖЕ СОБЫТИЮ И
ЯВЛЯЮТСЯ ЧАСТЯМИ ОДНОГО ЦЕЛОГО
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Если кто против - поспорим.
Пример вышлю без проблем !!!
Все сделано ТОЛЬКО СРЕДСТВАМИ WinCC.
Как WinCC выкручивается из этого - не представляю.
Но как вариант могу предложить следующее объяснение (в моей
ситуации эта логика просматривалась четко).
WinCC выбирает из трех таблиц данные за диапазон времени.
Если количество отобранных строк из трех таблиц совпало - на экране
все красиво. Видим нормальную таблицу.
Но если количество разное - выбирает колонку с максимальным
количеством строк и отрисовывает, а остальные колонки (где меньше)
просто перечеркивает.
Почему? Да все потому-же. WinCC сам не может точно сказать, где
достоверные данные, а где нет. И если значение какого-либо тега
выпало из архива - то к какой именно строке это значение
относилось.
Вылечить эту болезнь нельзя. Если только разработчики Siemens не
соизволят пошевелить-таки мозгами, наложить некоторые ограничения
на архивы, но зато сделать значения в архивах достоверными.
Извините за такое длинное письмо - короче никак не объяснить.
А если кому не нравится тон или содержание - НУ ИЗВИНИТЕ.
Так воспитан.
ЧТО ДУМАЮ - ТО И ГОВОРЮ.
С уважением ко всем...
В том числе и "товарищам" из SIEMENS.DE
Re: WinCC 5. Таблицы
Павел
Берляков; 3.1.02
Я в добавление к сказанному.
Сделал таблицу из 2-х колонок - 2 тега типа Floating point 32 +
время - текст нормальный.
Глюк наблюдался в случае таблицы с 5-ю процессными тегами.
Что до меня, я понял, что средствами WinCC надо пользоваться очень
осторожно. Базу данных делаю в Sybase. Надо еще разобраться с
перебросом данных. Скорей всего, для ликвидации наших проблем,
нужно перебрасывать данные из Short - Term архива из ОЗУ, а не с
HDD. Тогда, может быть не будет заморочек с полями timestamp.
И еще одно. Вызрело такое решение: чтобы нормально работать с
большими объемами данных (у меня задачка где-то всего лишь на 100
внешних переменных была) нужен OPC - сервер. А с данными,
приходящими с Симатика как-нибудь разберемся. На то есть Borland C
(упаси меня Бог от изделий Microsoft !).
Всех с Новым Годом.
O'k, теперь все ясно.
Павел
Берляков; 3.1.02
Перечеркнутый текст в таблице возникает, когда оптичено свойство
Common Time column. Как только птицу снял - все хорошо.
Но проблема с primary key для моих таблиц остается.
Мораль - архивировать не все значения, полученные из тегов опросом
upon change, а только усредненные по некоторому промежутку времени
(который можно сделать достаточно коротким). Сейчас попробую. Как
только появистя результат - сообщу. Думаю, для таких, как я
"чайников" это будет полезным (только без обид - ведь и я не
слишком опытен в WinCC !)
Хотя для Сименса это харроший вопрос!
Всякая уважающая себя фирма, хотя бы в целях поддержания репутации,
выложила бы (бесплатно) в И-нет fix для таких вот вещей. Или я чего
не понимаю ?
Все было просто
Павел
Берляков; 3.1.02
Взял и в TagLogging'е назначил "параллельные" теги (Also in
tag).
Теперь, даже если времена обновления исходных тегов не совпадают -
ничего страшного.
Re: WinCC 5. Таблицы
Dr. Kren;
4.1.02
Всех с НОВЫМ ГОДОМ !!!
Удачи и больших побед в неравной борьбе с разработчиками SIEMENS.DE
!!!
Беда в том, что экранное отображение данных для заказчика -
"филькина грамота", и не более.
Всякий уважающий себя конечный продукт имеет хотя-бы минимальный
набор отчетов о работе процесса.
Возвращаемся к весу (см message № 2).
Требование - выдать отчет за прошедшие сутки с разбивкой и
подведением итогов за каждый час.
Форма отчета примерно следующая
+-------------+-------------------------+--------+----------+----------+
! № цикла ! Дата/время ! Пуст ! Полн ! Выгр !
+-------------+-------------------------+--------+----------+----------+
! 1 ! 01/12/01 0:05:15 ! 380 ! 2600 ! 2220 !
! 2 ! 01/12/01 0:11:10 ! 380 ! 2700 ! 2320 !
! 3 ! 01/12/01 0:17:22 ! 380 ! 2750 ! 2370 !
! 4 ! 01/12/01 0:22:12 ! 380 ! 2650 ! 2270 !
! ! Итого ! 1520 ! 10700 ! 9180 !
+-------------+-------------------------+--------+----------+----------+
! 1 ! 01/12/01 1:05:15 ! 380 ! 2600 ! 2220 !
! 2 ! 01/12/01 1:11:10 ! 380 ! 2700 ! 2320 !
! 3 ! 01/12/01 1:17:22 ! 380 ! 2750 ! 2370 !
! 4 ! 01/12/01 1:22:12 ! 380 ! 2650 ! 2270 !
! ! Итого ! ! 2600 ! 2220 !
+-------------+-------------------------+--------+----------+----------+
Ну и так далее.
Попробуйте теперь построить такой отчет в WinCC !!!
При всем этом, отчет нужно выдать за ЛЮБЫЕ прошедшие сутки (не
обязательно с 0 до 24, но и допустим с 18 до 18 след дня). Еще
круче - запросить отчет за неизвестное заранее количество часов -
допустим за 50 прошедших.
Логичное решение - Microsoft Excel. Там такие вещи деляются левой
ногой.
НО !!! Нужно ведь вытащить данные из базы.
ODBC драйвер есть - уже легче. Да вот беда - данные из внешнего
источника независимо от его происхождения в Excel (да и в любую
другую программу на чем-угодно писанную) из базы данных
"Sybase Adaptive Server Enywhere 7" можно вытащить лишь при помощи
выражений SQL. Ведь сам "Sybase ASA 7" по определению -
SQL-сервер.
Вот вам и проблема!
Как вытащить корректные данные, если мы знаем что в архиве между
ними не гарантируется жесткая корреляция ?
SQL - выражение
==================================================
SELECT CHour.T,
CHour.V,
DoseBunker1_Empty.V,
DoseBunker1_Full.V,
DoseBunker1_Out.V
FROM DBA."PDE#HD#ArcBunker1#CurrentHour" CHour,
DBA."PDE#HD#ArcBunker1#DoseBunker1_Empty" DoseBunker1_Empty,
DBA."PDE#HD#ArcBunker1#DoseBunker1_Full" DoseBunker1_Full,
DBA."PDE#HD#ArcBunker1#DoseBunker1_Out" DoseBunker1_Out
WHERE CHour.T = DoseBunker1_Empty.T
AND CHour.T = DoseBunker1_Full.T
AND CHour.T = DoseBunker1_Out.T
AND ((CHour.T>'2001-12-01 00:00:00') AND (CHour.T<='2001-12-01 00:59:59'))
==================================================
Это выражение в корне не работоспособно (в силу организации
логической структуры архива). И как теперь быть?
Я пришел к следующему решению:
1. Установил InterBase SQL server 6.0 (абсолютно халявный, а по
мощности мало чем уступающий многим более именитым серверам)
2. Создал базу данных, а в ней таблицу из 4-х полей (дата, вес
пустого, полного, и разница веса)
3. Написал DLL на Delphi, выполняющую запись данных в архив.
4. По мере необходимости из WinCC вызаваю библиотечную функцию с
параметрами.
5. Microsoft Excel - средство создания отчетов.
И ВСЕ !!!
Все проблемы с достоверность сняты с повестки дня.
TagLoggin - лишь средсво для хранения показаний датчиков.
Естественно есть и другие способы решения этих проблем.
Все зависит лишь от фантазии разработчика.
Но тогда один вопрос (маленький, но очень вонючий)
ЗАЧЕМ ПРИОБРЕТАТЬ "WinCC" И ДОВЕШИВАТЬ НА НЕГО ВСЯКИЕ ПРИМОЧКИ,
ЕСЛИ ИСПОЛЬЗУЯ ПОЛНОЦЕННЫЙ ЯЗЫК ПРОГРАММИРОВАНИЯ И СООТВЕТСТВУЮЩИЙ
OPC-server КОНЕЧНЫЙ ПРОДУКТ НА ГОЛОВУ ВЫИГРЫВАЕТ У АНАЛОГИЧНОГО
ПРОЕКТА, РЕАЛИЗОВАННОГО В "WinCC".
И ПО СКОРОСТИ, И ПО ФУНКЦИОНАЛЬНОСТИ.
Да, есть доводы в пользу WinCC - малое время разработки, открытая
архитектура. Типа грамотный разработчик WinCC взяв чужой проект
разберется и доведет его до кондиции.
Но извините ребята, если грамотный разработчик на Delphi или
C-Builder возьмет чужой проект - он его так-же точно доведет до
кондиции.
Основное - понимать логику автоматизируемого объекта.
А вот чего очень хотелось-бы - так это приобретая WinCC и пользуясь
ТОЛЬКО встроенными возможностями решать практически любые задачи
при разработке проекта.
"И не грешно умному послушать дурака" - как говорили древние
мудрецы - "Ибо даже дурню открыта доля мудрости".
Я (естественно) не претендую ни на первое звание, ни на второе.
Но очень, знаете ли, хочется узнать мнение разработчиков SIEMENS о
путях и способах решения вышеописанных проблем.
С уважением ко всем...
В том числе и "товарищам" из SIEMENS.DE
Re: WinCC 5. Таблицы
Юрий
Оганесян; 16.1.02
С любопытством почитал про попытки заархивировать четыре разных
тэга, логически связанных и относящиеся к одному событию. Поднята
проблема, что потом невозможно это понять, анализируя архив, и
приведено решение этой проблемы. Но мне хотелось бы поднять еще
один вопрос. Он касается аналогичной проблемы, но не на участке
связи WinCC-архив, а на участке связи PLC-WinCC! Работаю по S7-
протоколу. Если я правильно понимаю, то установление одинаковой
частоты обновления для 4 тэгов (например 1 сек) еще не означает,
что эти данные будут переданы на компьютер в едином пакете и за
одну «дырку» между работой OB1. Т. е. можно получить 3 тэга, потом
20ms работы OB1, и оставшийся тэг.
Но вот в чем перец – за время работы OB1 данные могли поменяться
совершенно объективно (быстро меняющиеся процессы)!
Если непонятно перечитайте еще раз – мне лень писать подробнее
:)
Таким образом, я вижу общее решение проблемы составлением одного
большого ROW-тэга. Это решит также проблему совместной архивации
нескольких тэгов.
Если я чего-то не понимаю – поправьте
Re: WinCC 5. Таблицы
Чистяков Дмитрий ОАО
СеверСталь; 17.1.02
Уважаемый Юрий Оганесян, я с Вами абсолютно согласен! Только хочю
добавить, что ко всему прочему WinCC берёт данные асинхронно по
отношению к циклу программы в контроллере.
Т.е. Если значение переменной изменяется несколько раз на
протяжении программы, то при отображении его на WinCC будет
замечено "мельтешение" значения. Сей факт нами был получен
практическим путём - то бишь на реальном проекте.
Re: WinCC 5. Таблицы
Юрий
Оганесян; 17.1.02
Чистякову Дмитрию:
Ваше замечание (по поводу того, когда WinCC берет данные по
отношению к циклу работы контроллера), очевидно, относится или к
S7-400 или НЕ к S7 протоколу, потому что я такой вопрос задавал на
этот форум года 1.5 – 2 назад (к сожалению, не смог его сейчас
найти) и мне ответили, что для S7-200 и S7-300 связь с HMI может
осуществляться ТОЛЬКО после завершения работы OB1 (и перед
следующим его началом), что, кстати, подтверждается manual-ами, а
для S7-400 есть специально обученные функции.
Re: WinCC 5. Таблицы
Alexis; 17.1.02
Привет Всем!
Dr. Kren, на счет третьего поля «F», в ODK дается следующее
описание:
dwFlags - For each value written to the archive, Tag Logging sets a
flag which indicates tag status. In order to analyse the flags, the
value must be converted into hex format! The "left" word (HighWord)
indicates Data Manager or Quality Code flags (depending on whether
the PDE_RT_QUALITYCODE bit has been set or not), while the "right"
word (LowWord) represents Tag Logging status flags.
TagLoggingStatusFlags (LowWord):
PDE_RT_DAYLIGHT (Value:0x0001) Daylight saving time
PDE_RT_SUBSTITUTION (Value:0x0002) Substitute value
PDE_RT_TIME_BEVOR_JUMP (Value:0x0004) Value before a time jump
PDE_RT_TIME_BEHIND_JUMP (Value:0x0008) Value after a time jump
PDE_RT_TIME_OVERLAPPED (Value:0x0010) Values during a time
overlap
PDE_RT_LOAD_SYSTEM (Value:0x0020) Value saved to archive for the
first time after the archive has been created
PDE_RT_RELOAD_SYSTEM (Value:0x0040) First value after activation of
RT
PDE_RT_CMPCOPY (Value:0x0080) Compressed value
PDE_RT_TIME_CHANGED (Value:0x0100) Time has been changed
PDE_RT_HAND (Value:0x0200) manual tag assignment
PDE_RT_ONCHANual tag assignment
PDE_RT_ONCHAN)
PDE_RT_ONCHANGEBACKUPVALUESTOP (Value:0x0800)
PDE_RT_QUALITYCODE (Value:0x1000)
Теперь о перечеркнутом времени – я сталкивался с этим в сообщениях
AlarmLogging-а, там время перечеркнуто когда установлен флаг
MSG_FLAG_TIMEINVALID, но у dwFlags TagLogging-a подобной фишки
вроде нет. Так что попробуйте проанализировать значение флага когда
время будет перечеркнуто, и если нетрудно, то сообщите в форум.
Best regards, Alexis.
Re: WinCC 5. Таблицы
Соколов
Влексей (ЗАО "АСК" Екатеринбург); 18.1.02
Здравствуйте!
По поводу отчетности в WinCC, хотел бы сообщить информацию, которая
возможно будет вам интересна.
Все TagLogging гарфики и таблицы для отчетов я формирую из
программы, написанной на CBuilder. Благо в новой версии WinCC
реализовано корректное обращение к обоим базам данных WinCC через
ODBC. Для этого Есть ODK-функция, которая возвращает ODBC-ссылку на
запущенный проект. Обращение к архивам TagLogging возможно,
например с помощью компоненты CBuilder ADOQuery, посредством
SQL-запроса. Единственное неудобство, что архивация данных в
TagLogging-таблицы производится по внутренним событиям из буффера
памяти, поэтому в реальном времени данные в таблице не всегда можно
увидеть.
Насчет же ActiveX фирмы Siemens, который отображает TagLogging -
графики, хочу сказать, что глюков, особенно раньше он содержал
много.
Немного философии...
Павел
Берляков; 22.1.02
Речь шла не о "перечеркнутом" времени (звучит как-то слишком
мистически...), хотя, спасибо Alexis'у, теперь я и об этом знаю.
Состояние флагов - посмотрю завтра.
Знаете, я не слишком опытен в программировании, но по простоте
душевной скажу - хвала Microsoft'ам, Сименсу и иже с ними !
Когда мы получили Win95 с его глюками - волей-неволей потихоньку
приобщились к программированию. Я, например, начал писать на Watcom
C. Под QNX, конечно.
WinCC в мире автоматизации - примерно то же самое, что и Windows в
мире операционных систем. Для меня общение с WinCC превратилось в
один хороший урок...
Как-то надоело жаловаться на всевозможные глюки.
Удачи всем.
Re: WinCC 5. Таблицы
Dr. Kren; 25.1.02
Привет всем !
Удачи и больших побед в неравной борьбе с разработчиками SIEMENS.DE
!!!
To [Alexis; 17.1.02]
За информацию - большое спасибо!
PDE_RT_TIME_CHANGED (Value:0x0100) Time has been changed
PDE_RT_TIME_CHANGED (Value:0x0100) "Время изменялось"
Да вот только проблему это не решает...
Что произошло изменение времени при записи - и так известно.
Проблема в том, что бы связать записи разных таблиц в единое целое,
при том что время записи у них разное.
С уважением ко всем...
Re: WinCC 5. Таблицы
Юрий
Оганесян; 25.1.02
Уважаемый Dr. Kren!
Прочтите, пожалуйста, мое предыдущее замечание. С учетом того, что
там сказано, задача, над которой Вы бьетесь, изначально неверно
поставлена!
Re: WinCC 5. Таблицы
Чистяков Дмитрий ОАО
СеверСталь; 25.1.02
Как то прочитал вот такой прикол:
"90% глюков Windows вызваны не знанием пользователем как пользовать
им. И надеждой пользователя на то, что Windows сам должен
догадаться о том, что хочется пользователю"
:-)
Re: WinCC 5. Таблицы
Dr. Kren; 25.1.02
Привет всем !
Удачи и больших побед в неравной борьбе с разработчиками SIEMENS.DE
!!!
To [Юрий Оганесян; 25.1.02]
За информацию - большое спасибо!
Корректнее будет "RAW-tag".
Да вот только и такой подход проблемы не решает.
Как вариант - тэги берутся из разных контроллеров. Объективно уже
невозможно объединить их в один.
С уважением ко всем...
Re: WinCC 5. Таблицы
Юрий
Оганесян; 30.1.02
Если логически взаимосвязанные тэги берутся из разных контроллеров,
то задача становится порядка на два сложнее (но это в том случае,
когда эти устройства действительно самостоятельные контроллеры, а
не децентрализованная периферия, которую было бы более логично
использовать в данном случае) Что нужна синхронизация времени
контроллеров – это само собой разумеется - а вот все остальное…
даже думать страшно…:)
Я бы все-таки программно передавал данные в один контроллер,
формировал там таблицы или еще чего-нибудь подобное и оттуда
забирал их WinCC-ой
Re: WinCC 5. Таблицы
Костенич Дмитрий; 3.2.02
Привет всем!
К вопросу о получении достоверных архивов по логически связанным
тегам. Таки да, в TagLogging это сделать невозможно, т.к. на каждый
тег заводится своя таблица, со всеми вытекающими отсюда
последствиями вроде рассонхронизации циклов архивирования.
Однако, в WinCC Options есть такая вещь как UserArchives, которая
как раз и служит для архивирования логически связанной информации
(и помещается эта информация в ОДНУ таблицу!!!). Я глубоко с ней не
разбирался, но понял про нее две вещи:
1. Есть возможность получать и архивировать данные непосредственно
от контроллера (через RAW-теги)
2. Создавая элемент View можно выбирать для просмотра необходимые
поля архива, а так же объединять поля из нескольких архивов.
Для отображения заархивированной информации в GraphicsDesigner есть
специальный ActiveX в виде таблицы (как его зовут сейчас не
помню).
Единственно что, - я не разобрался как (по какому событию)
происходит архивирование, т.к. циклов там вроде бы нет. Есть
скриптовые функции, но их применять не хочется.
Буду благодарен если кто растолкует.
Re: WinCC 5. Таблицы
Павел Берляков; 5.2.02
А вы почитайте, какую производительность обеспечивает этот User
Archives. Чем больше записей, тем хуже. Единственное, для чего его
можно использовать - это хранить всевозможные рецепты. Ну это так,
к слову.
А теперь вопрос. Что мешает нам посредством ISQL, или еще как
вытянуть данные из разных таблиц ? Время там ставится до 3-го
знака. Что мешает обработать эти таблицы (назначить квант времени
больший, чем интервал поступления данных из тегов, которые должны
быть логически связанными)? Все упирается в величину этого кванта
времени и возможность коллизии между данными. Но если грамотно все
прописать в SQL, проблема может быть решена.
Ясно одно. WinCC никогда не претендовала на роль система real-time.
И ею не будет, пока не произойдет кардинальной переработки. Кому
нужна real-time - используйте QNX + написанное в PhAb (почти все
делается ручками, зато работает быстро и на компах где-то 32 Мб RAM
- большой опыт по этой части у словацкой фирмы Procesna
Automatisazia, Кошице).
Удачи всем
Re: WinCC 5. Таблицы
Alexis; 6.2.02
To Dr. Kren
Кстати на счет твоей проблемы с записью взаимосвязанных данных,
может тебя устроит следующее решение:
Предположим тебе надо сохранять три переменных. Создаешь в
TagLogging три циклических архива на необходимое кол-во длинны и
лочишь их. Далее отлавливаешь перую переменную и запоминаешь время
и значение, ловишь остальные и запоминаешь значения, а затем
записываешь в соответствующие таблицы через TLGInsertArchivData с
одинаковым временем. Ну и получаешь связь данных через одинаковое
время.
Re: WinCC 5. Таблицы
Dr. Kren; 6.2.02
Привет всем !
Удачи и больших побед в неравной борьбе с разработчиками SIEMENS.DE
!
To [Юрий Оганесян; 30.1.02]
----------------------------------------
Я бы все-таки программно передавал данные в один контроллер,
формировал там таблицы или еще чего-нибудь подобное и оттуда
забирал их WinCC-ой
----------------------------------------
Проект уже более полугода как реализован и сдан. Программированием
контроллеров занималась другая фирма. Так что даже собрать данные в
один контроллер - проблема. Такой вариант уже рассматривался.
Но все равно спасибо.
To [Костенич Дмитрий; 3.2.02]
----------------------------------------
Однако, в WinCC Options есть такая вещь как UserArchives, которая
как раз и служит для архивирования логически связанной информации
(и помещается эта информация в ОДНУ таблицу!!!).
----------------------------------------
Проверялось. Быстродействие оставляет желать лучшего.
Но за совет спасибо.
To [Павел Берляков; 5.2.02]
----------------------------------------
Но если грамотно все прописать в SQL, проблема может быть
решена.
----------------------------------------
В каком SQL - SQL-выражении или SQL-базе данных?
В стандарте ANSI SQL нет вообще такого понятия как "установка
времени с точностью до 3-го знака" по той простоя причине, что
время не есть Real, Double или Float значение.
К алгоритму записи данных в TagLogging (на сколько я знаю) нет
доступа из WinCC. Так что ч какой точностью WinCC запишет время -
одному SIEMENS известно.
В придачу ко всему обсуждается вопрос не как вытянуть данные из
базы ASAnywhere, а как в случае разрыва по времени записи корректно
отразить их "WinCC Table on-line" с показом времени записи данных в
одной колонке, а не во всех.
За совет спасибо (но толком не понял "грамотно все прописать в
SQL").
To [Alexis; 6.2.02]
----------------------------------------
Кстати на счет твоей проблемы с записью взаимосвязанных данных,
может тебя устроит следующее решение:
----------------------------------------
А вот на счет "TLGInsertArchivData" как-то даже и не подумали.
Проверим.
Большое спасибо!
С уважением ко всем...
Re: WinCC 5. Таблицы
А. Туманов; 12.2.02
"Перечёркивание" может быть связано и с ошибкой при отображении -
достаточно лишь изменить (увеличить) диапазон времени для
отображения.