This is topic Рассинхронизация времени в архиве in forum Архивирование в TRACE MODE / Data Logging in Trace Mode at Форум TRACE MODE: техническая поддержка.


To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/10/t/000102.html

Posted by sugar (Участник № / Member № 1198) on :
 
Прошу объяснить почему возникает следующая ситуация:с помощью архивного тренда просматриваем текущие значения каналов,но время на тренде не совпадает с реальным системным временем установленным на ПК ,на котором запущен МРВ,на несколько часов.При скачивании базы с помощью ODBC из МРВ время также рассинхронизивано.К примеру, реально 11:00,а показавается 17:00.Хотя при начальном запуске архивирование шло нормально,но через несколько минут по непонятным причинам произошла рассинхронизация времени.После уже не восстановилось.Что можно предпринять?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Все временные метки внутри сервера ТМ, а также СПАД-архива имеют формат Гринвича. Все преобразования при их отображении на трендах, экспорте по ODBC производятся согласно Региональным настройкам ОС Windows (согласно указанной зоне). Поэтому такой эффект Вы могли получить, если данные в архив отправлялись с источника (ПК или контроллера) на котором часовой пояс не совпадает с часовым поясом ПК, на котором Вы эти данные просматриваете, хотя их часы могут и показывать одно и то же время.
 
Posted by Смирнов С.В. (Участник № / Member № 57) on :
 
День добрый!
Столкнулись с аналогичной ситуацией. Время действительно сначала записывается правильно, а потом уходит на +4 часа. Удаляли старый спад, через некоторое время все повторяется.
Ответ данный на предыдущее сообщение на мой взгляд ниже всякой критики. Тех поддержка даже не приняла сообщение к сведению, и не затруднила себя поиском ошибки. только дали ссылку на Гринвича. А если отчет пишится и читается на одном и томже компьютере, откуда взяться Гринвичу? Временные метки делает ТМ,т.к. он записывает данные в ахив, а не контроллер.
С уважением
Смирнов С.В.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Относительно временных меток в архив - повторяюсь еще раз "внутри" сервера ТМ, архива, транспортных пакетов по сети I-NET - все метки времени обрабатываются в формате Гринвича, это означает, что не используется часовое смещение в принципе!
Если подобное происходит на одном и том же ПК, значит, что-то или кто-то меняет региональные настройки системы вместе с переводом часов реального времени.
Отсюда - визуально время вроде и не менялось, а на самом деле оно не то, что было до момента изменения: в ОС Windows (да и MS DOS тоже) система астрономических часов работает по приципу отсчет времени в формате Гринвича (то есть - без учета поясов), а вот отображение их в разного рода ПО, в том числе и на панели задач ОС производится в соответсвии с текущим часовым поясом, заданным в настройках ОС.
Вот и получается, иногда интересные ситуации, когда на панели задач Вы видите 13:30 Москвы, а на самом деле в системе по Гринвичу может стоять:
а) 3:30 ночи по Гринвичу и часовой пояс на Сидней, где GTM+10:00 часов
б) 7:00 утра по Гринвичу и часовой пояс на Рангун, где GMT+6:30
в) 16:30 дня по Гринвичу и часовой пояс на Бразилию, где GMT-3:00
И так далее - комбинаций море, но всегда 13:30 на панели, а в системе, архивах, протоколах время разное. И при попытке просмотреть его потом в одном часовом поясе начинается чехарда с несоответсвием поясового сдвига.
 
Posted by Смирнов С.В. (Участник № / Member № 57) on :
 
А как на счет отчета тревог?
В нем осталось нормальное время, которое и в панели задач, а в СПАД архиве временные метки сдвинулись.
С уважением
Смирнов С.В.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
У Вас есть эти файлы архива СПАД и ОТ? Пришлите их, пожалуйста, на адрес техподдержки вместе с проектом.
 
Posted by Смирнов С.В. (Участник № / Member № 57) on :
 
День добрый!
Проект выслал на адрес форума!
СПАД выслать не могу по причине объема 300 Mb
Благодарю за помощь.
Смирнов С.В.
 
Posted by Смирнов С.В. (Участник № / Member № 57) on :
 
Спад упаковал, порезал на части и отправил на адрес форума
С уважением
Смирнов С.В.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Чем файлы нарезали и как их теперь вместе собрать?
 
Posted by Смирнов С.В. (Участник № / Member № 57) on :
 
В Total (Windows) Commander в меню "Файл" выбираете пункт "Собрать файл" указываете *.crc файл.

С уважением
Смирнов С.В.
 
Posted by Смирнов С.В. (Участник № / Member № 57) on :
 
Добрый день!
Не могли бы вы сообщить, есть ли какие-либо результаты по вопросу рассинхронизации времени в архиве.
С уважением
Смирнов С.В.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Я проанализировал Ваш архив и ОТ, который Вы прислали - в СПАДе действительно наблюдается скачок по времени с 22.06.2005 15:40:15 на 22.06.2005 19:34:34, однако в файле ОТ за данный промежуток времени данные есть, также по точкам этих временных меток есть соответсвующие записи в ОТ. Похоже, что в этот момент времени архивация в МРВ вообще не работала - причины могут быть две:
1) Были отключены (сброшены) флаги "в СПАД" по всем каналам, у которых они были.
2) Был сбой при записи в СПАД - он мог быть как системным ТМ, так и системным в ОС Windows.

Достоверно восстановить картину более невозможно - помогло бы значение канала ДИАГНОСТИКА_СПАД типа intput, которое есть у Вас в проекте, однако оно у Вас ни в СПАД, ни в ОТ не направлено - поэтому код ошибки по архиву в этот момент времени определить никак не удастся.
Я больше склоняюсь к первому варианту - потому как в 22.06.2005 19:34:34 архивация продолжилась снова как будто ее снова включили. Но не исключен и второй вариант на уровне самой ОС при работе с HDD.
У Вас есть возможность повторить эксперимент с сохранением диагностики СПАД в ОТ, чтобы увидеть его значение?
 


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2