Конвертирование TimeStamp в строку на Цели (sbRIO-9631)

Ответить
pavel_urkaev
beginner
beginner
Сообщения: 22
Зарегистрирован: 23 июн 2011, 12:15
Версия LabVIEW: NI LabVIEW 2012(x86)
Контактная информация:

Конвертирование TimeStamp в строку на Цели (sbRIO-9631)

Сообщение pavel_urkaev »

Добрый вечер! Приветствую всех участников портала. У Меня возник вопрос по конвертированию времени (Timestamp) в строку. Не мог ли бы Мне кто-нибудь помочь?

Есть простой ВП для преобразования времени из Timestamp в строковое представление по определенному шаблону и выполнения обратной операции - из полученный строки опять в Timestamp. Блок-схема - см. ниже...
Изображение

Так вот выполнение этого ВП на Цели (sbRIO-9631) и на ПК (Windows 7) отличается. Для сравнения привожу Лицевые панели ВП после выполнения на ПК и Цели, см. ниже...
Изображение

Изображение

Как видно, в обоих случаях исходное значение Timestamp Source равно новому, полученному из строки New (from string), и значение исходного времени в секундах Source (sec) тоже одинаково для обоих случаев. Однако, вопрос возник вокруг обработки исходного времени на Цели. Как видно значения TimestampString и TimestampeRec отличаются от исходного Source на -4 часа. Судя по всему ВП "Format Into String.vi" и "Seconds To Date/Time.vi" при преобразовании вычитают 4 часа из исходного времени, а ВП "Scan From String.vi" прибавляет 4 часа к результату. Подскажите пожалуйста, чем вызвано такое поведение и как избавиться от его влияния (исключить вычитание 4х часов при выполнении ВП "Format Into String.vi" и "Seconds To Date/Time.vi") ?

Часовой пояс на Цели менял через MAX, результатов ноль. Настройки времени в MAX см. ниже...
Изображение
Аватара пользователя
mark
beginner
beginner
Сообщения: 39
Зарегистрирован: 18 ноя 2010, 21:35
Версия LabVIEW: 2015

Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)

Сообщение mark »

Приветствую, pavel_urkaev,

Насколько я понимаю, это поведение обусловлено различными зонами времени. Самый простой способ - попробовать использовать Universal Time Container <%^< >T>.
pavel_urkaev
beginner
beginner
Сообщения: 22
Зарегистрирован: 23 июн 2011, 12:15
Версия LabVIEW: NI LabVIEW 2012(x86)
Контактная информация:

Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)

Сообщение pavel_urkaev »

Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)
Приветствую, pavel_urkaev,

Насколько я понимаю, это поведение обусловлено различными зонами времени. Самый простой способ - попробовать использовать Universal Time Container <%^< >T>.
Добрый вечер. Mark, это попробовал первым делом - результат тот же самый. Смещение именно на 4 часа
Аватара пользователя
kiparym
advanced
advanced
Сообщения: 178
Зарегистрирован: 06 сен 2011, 08:52
Версия LabVIEW: 8.2 & 2011
Откуда: г. Саров
Поблагодарили: 1 раз
Контактная информация:

Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)

Сообщение kiparym »

Попробуй отключить коррекцию времени.
Time.jpg
Time.jpg (7.85 КБ) 8469 просмотров
pavel_urkaev
beginner
beginner
Сообщения: 22
Зарегистрирован: 23 июн 2011, 12:15
Версия LabVIEW: NI LabVIEW 2012(x86)
Контактная информация:

Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)

Сообщение pavel_urkaev »

Попробуй отключить коррекцию времени.
Добрый день. К сожалению, последнюю неделю плата не на руках, как только получим к ней доступ, попробуем Ваше решение!
pavel_urkaev
beginner
beginner
Сообщения: 22
Зарегистрирован: 23 июн 2011, 12:15
Версия LabVIEW: NI LabVIEW 2012(x86)
Контактная информация:

Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)

Сообщение pavel_urkaev »

Добрый вечер. Предложение kiparym'мa не увенчалось успехом, аномалия с переводом времени в строку и обратно не исчезла. Однако, обнаружил, что при получении текущего времени цели ("Get Date/Time In Seconds.vi") к времени, указаному в MAX прибавляется 4 часа. С чем это может быть связано? Как видно, часовой пояс настроен на нулевое смещение (Гринвич)...
Аватара пользователя
Super Star
adviser
adviser
Сообщения: 228
Зарегистрирован: 07 фев 2013, 08:37
Версия LabVIEW: 2011

Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)

Сообщение Super Star »

на своем контроллере замечал такую же вещь, что MAX показывает настройки времени одни и время одно, а в программе - совсем другое. Просто руками в коде +- делал 3 года.
я люблю свою работу.... Я приду сюда в субботу ...
pavel_urkaev
beginner
beginner
Сообщения: 22
Зарегистрирован: 23 июн 2011, 12:15
Версия LabVIEW: NI LabVIEW 2012(x86)
Контактная информация:

Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)

Сообщение pavel_urkaev »

Ситуация стала еще интереснее. ВП, представленный выше, был изменен для отображения текущего времени Цели в часовом поясе - CurrentTimeOnTimeZone и текущего времени цели по Гринвичу - CurrentTime (GMT+0). Блок-схема представлена ниже (новый участок кода выделен зеленым)...
Изображение
Было проведено несколько экспериментов для разных часовых поясов и времени, установленных в MAX. Изменение текущего времени и часового пояса в Системе - ПК, как и следовало ожидать, на результаты не оказало никакого влияния.

Результат эксперимента для GMT+9...
Изображение
1) Смещение при конвертации времени в строку: +5 часов,
2) Смещение текущей временной зоны от Гринвича: +9 часов,
3) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: -5 часов,
4) Смещение текущего времени Цели в текущем часовом поясе относительно того же времени по Гринвичу: +9 часов.

Результат эксперимента для GMT+10...
Изображение
1) Смещение при конвертации времени в строку: +6 часов,
2) Смещение текущей временной зоны от Гринвича: +10 часов,
3) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: -6 часов,
4) Смещение текущего времени Цели в текущем часовом поясе относительно того же времени по Гринвичу: +10 часов.

Результат эксперимента для GMT+10 (как и во 2м случае, но через MAX изменено текущее время на Цели)...
Изображение
1) Смещение при конвертации времени в строку: +6 часов,
2) Смещение текущей временной зоны от Гринвича: +10 часов,
3) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: -6 часов,
4) Смещение текущего времени Цели в текущем часовом поясе относительно того же времени по Гринвичу: +10 часов.

Прослеживается зависимость: ВРЕМЯ В СТРОКЕ - ИСХОДНОЕ ВРЕМЯ = ТЕКУЩЕЕ ВРЕМЯ В MAX - ТЕКУЩЕЕ ВРЕМЯ ЦЕЛИ (Get Date/Time In Seconds) = СМЕЩЕНИЕ ЧАСОВОГО ПОЯСА - 4 часа.

Кто-то может пояснить причину существования данного смещения времен (СМЕЩЕНИЕ ЧАСОВОГО ПОЯСА - 4 часа)?
pavel_urkaev
beginner
beginner
Сообщения: 22
Зарегистрирован: 23 июн 2011, 12:15
Версия LabVIEW: NI LabVIEW 2012(x86)
Контактная информация:

Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)

Сообщение pavel_urkaev »

Добрый вечер, приветствую участников портала. Выявлена причина описываемого смещения времени (СМЕЩЕНИЕ ЧАСОВОГО ПОЯСА - 4 часа). Системное время, а именно часовой пояс системы (UTC+04:00) формирует компонент выражения в -4 часа. Раньше Я утверждал, что настройки системного времени не оказывают влияния. Однако, чтобы зафиксировать изменение часового пояса системы в результатах выполнения кода необходимо перезапустить среду LabVIEW (закрыть проект, закрыть стартовое окно LV, запустить LV - стартовое окно, открыть проект). Так же результат выполнения чувствителен к системной настройке - автоматическому переходу на летнее время и обратно. Привожу доказательства ниже...

Результат эксперимента для MAX GMT+0, PC GMT+0, без автоматического перехода на летнее время и обратно
Изображение
1) Смещение текущей временной зоны от Гринвича в Системе (PC_TZ_Offset): +0 часов,
2) Наличие автоматического перехода на летнее время и обратно в Системе: НЕТ,
3) Смещение текущей временной зоны от Гринвича в MAX (MAX_TZ_Offset): +0 часов,
4) Смещение при конвертации времени в строку: +0 часов (MAX_TZ_Offset - PC_TZ_Offset = 0 - 0 = 0),
5) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: +0 часов (PC_TZ_Offset - MAX_TZ_Offset = 0 - 0 = 0).

Результат эксперимента для MAX GMT+0, PC GMT+4, без автоматического перехода на летнее время и обратно
Изображение
1) Смещение текущей временной зоны от Гринвича в Системе (PC_TZ_Offset): +4 часов,
2) Наличие автоматического перехода на летнее время и обратно в Системе: НЕТ,
3) Смещение текущей временной зоны от Гринвича в MAX (MAX_TZ_Offset): +0 часов,
4) Смещение при конвертации времени в строку: -4 часов (MAX_TZ_Offset - PC_TZ_Offset = 0 - 4 = -4),
5) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: +4 часов (PC_TZ_Offset - MAX_TZ_Offset = 4 - 0 = 4).

Результат эксперимента для MAX GMT+3, PC GMT+4, без автоматического перехода на летнее время и обратно
Изображение
1) Смещение текущей временной зоны от Гринвича в Системе (PC_TZ_Offset): +4 часов,
2) Наличие автоматического перехода на летнее время и обратно в Системе: НЕТ,
3) Смещение текущей временной зоны от Гринвича в MAX (MAX_TZ_Offset): +3 часов,
4) Смещение при конвертации времени в строку: -1 часов (MAX_TZ_Offset - PC_TZ_Offset = 3 - 4 = -1),
5) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: +1 часов (PC_TZ_Offset - MAX_TZ_Offset = 4 - 3 = 1).

Результат эксперимента для MAX GMT+0, PC GMT+0, с автоматическим переходом на летнее время и обратно
Изображение
1) Смещение текущей временной зоны от Гринвича в Системе (PC_TZ_Offset): +0 часов,
2) Наличие автоматического перехода на летнее время и обратно в Системе (F): ДА,
3) Смещение текущей временной зоны от Гринвича в MAX (MAX_TZ_Offset): +0 часов,
4) Смещение при конвертации времени в строку: +0 часов (MAX_TZ_Offset - PC_TZ_Offset = 0 - 0 = 0),
5) Смещение текущего времени Цели в текущем часовом поясе относительно указанного в MAX: +1 часов (F -> +1).

Как видно, прослеживаются определенные закономерности (указаны в примечаниях к рисункам). Исходя из данной ситуации, можно сделать вывод, что системные настройки вносят ошибки:
1) При указании времени на Цели средствами MAX. То есть, значение указанное в MAX отличается от реального (получаем при помощи ВП "Get Date/Time In Seconds.vi") установленного на Цели на (PC_TZ_Offset - MAX_TZ_Offset).
2) В результаты преобразований времени при использовании: ВП "Format Into String.vi" - время, полученное в строке, будет отличаться от исходного на (MAX_TZ_Offset - PC_TZ_Offset); а ВП "Scan From String.vi" - наоборот, полученного время будет отличаться от исходного в строке на (PC_TZ_Offset - MAX_TZ_Offset). Причем, если "прогнать" время через последовательные вызовы ВП "Format Into String.vi" и ВП "Scan From String.vi", то исходное значение времени и конечное будут равны, но промежуточная строка будет отличаться.

Самое интересное, что если получить текущее время Цели вызовом ВП "Get Date/Time In Seconds.vi" (Target_Time_TS = MAX_Time + (PC_TZ_Offset - MAX_TZ_Offset)) и передать его для преобразования ВП "Format Into String.vi" (Target_Time_String = Target_Time_TS + (MAX_TZ_Offset - PC_TZ_Offset)), то полученная строка будет равна значению времени MAX (Target_Time_String = MAX_Time + (PC_TZ_Offset - MAX_TZ_Offset) + (MAX_TZ_Offset - PC_TZ_Offset) = MAX_Time).
Изображение
И все бы ничего, но если работать со временем в виде строк и численном (например, UNIX Time) одновременно, то соответствия между значениями нет из-за смещения, вызванного настройками времени в Системе ПК.

Описанное поведение считается нормальным? Кто-нибудь сталкивался с подобными ситуациями или мог бы посмотреть, как дело обстоит на его RIO-системе?
pavel_urkaev
beginner
beginner
Сообщения: 22
Зарегистрирован: 23 июн 2011, 12:15
Версия LabVIEW: NI LabVIEW 2012(x86)
Контактная информация:

Re: Конвертирование TimeStamp в строку на Цели (sbRIO-9631)

Сообщение pavel_urkaev »

Добрый вечер. mark был прав - проблема решена путем отключения автоматической поправки на часовой пояс (<%^< >T>) в элементах управления, индикации и константах TimeStamp, а также в строке формата для вызова ВП "Format Into String.vi".
Изображение

Благодарю всех за содействие в поиске решения!
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Real Time / FPGA / Embedded»