ProTool/Pro Runtime v5.2+SP3 лживый OPC сервер
Николай Михалев; 18.2.02

Здравствуйте,


Подключился к Protool как к OPC серверу. Создал группу с периодом обновления 1 сек. Вижу, что клиент получает данные с заданным периодом, но неправильным штампом времени. Вот реальные значения штампа времени за 10 сек.: 38.0; 39.999; 40.0; 41.0; 42.999; 43.0; 44.999; 45.999; 46.0; 47.999; 48.0.
Re: ProTool/Pro Runtime v5.2+SP3 лживый OPC сервер
Юрченко Владимир; 4.4.02

А цикл обновления этого тега в проекте ProTool у Вас какой? Скорей всего 2 секунды, что и показывает штамп.

Re: ProTool/Pro Runtime v5.2+SP3 лживый OPC сервер
Николай Михалев; 5.4.02

У меня нет исходника - цикл обновления тега не знаю. Но период обновления группы я задавал и 2 и 10 сек. В любом случае целая часть секунд в штампе времени тега - правильная, а дробная - 0 или 999 - случайным образом.

Re: ProTool/Pro Runtime v5.2+SP3 лживый OPC сервер
Юрченко Владимир; 5.4.02

OPC сервер ProTool дает штамп того времени , когда он отправил данные клиенту . К сожалению он не сохраняет и не передает штамп времени из контроллера или из другого OPC сервера (проверено на WinAC OPC). Впрочем также работает и OPC сервер WinCC

Так что если уж вам так важен точный штамп времени, то лучше использовать Net OPC сервер. Но это опять с какой точностью – на самом деле и там штамп времени будет ставиться сервером по мере чтения их сети, а не когда они изменились реально в контроллере. Разница я думаю небольшая, в зависимости от параметров и типа сети , но где то в пределах 10-100 мс, не меньше. Можно конечно заносить в буфер в контроллере данные с меткой времени и считывать их- есть специальная функция SFB 37 AR_SEND и соответствующие настройки в WinCC, но это уже отдельный разговор…

Re: ProTool/Pro Runtime v5.2+SP3 лживый OPC сервер
Николай Михалев; 8.4.02

Чтобы исключить влияние сети, запустил проект из под эмулятора FwSim.exe - картина та же.

Решил повнимательнее взглянуть на штамп времени архивных данных - для сравнения с штампом времени OPC тегов. Вот последние 4 цифры колонки с сотнями миллисекунд: 5080, 5196, 5312, 5430, 5546, 5661, 5778, 5894, 6010, 6126.
Получается, что Protool знает время получения тегом значения с точностью 100 мсек. но в штамп времени OPC тега ничего, кроме 0 и 999 мсек не пишет.
Мне важен штамп времени менее похожий на результат ошибки в программе - если OPC сервер показывает 0 и 999 мсек., значит разрешающая способность метки времени составляет 1000 - 999 = 1 мсек. Почему же хоть иногда не проскальзывают значения отличные от 0 и 999?
Кстати, разработчики проекта сказали, что период записи в архив задан 10 сек., но фактически время между моментами записи составляет в среднем 519,6 - 508,0 = 11,6 сек.