|
Сообщение создано: 17. 03. 2021 [12:19]
|
|
dudanov
Sergey Dudanov
Создатель темы
Зарегистрирован(а) с: 14.08.2013
Сообщения: 26
|
Здравствуйте.
Заранее извиняюсь, если данный вопрос уже обсуждался на форуме, беглый поиск результата не дал.
Возникла необходимость получить доступ к архивным данным для их последующего анализа.
Не хотелось бы писать распаковщик файлового архива значений (именно такой используется в проекте), а хотелось бы, если таковая возможность имеется, с помощью любого API выполнять запросы к OpenSCADA и забирать запрошенные данные в формате, который читает pandas.
Благодарю.
[Сообщение редактировалось 1 раз(а), в последний раз 17.03.2021 в 12:22.]
# rm -rf /bin/laden
|
|
Сообщение создано: 25. 03. 2021 [14:53]
|
|
dudanov
Sergey Dudanov
Создатель темы
Зарегистрирован(а) с: 14.08.2013
Сообщения: 26
|
Задача решена. Всем спасибо.
Что хочу сказать. Я приятно удивлен производительности OpenSCADA! Скриншот с выводом клиента и производительности прилагаю. Был осуществлен запрос 10 параметров с датчиков за ГОД и интервалом 1 минута. Итого: почти 5.3 миллиона записей, сервер обработал в 60 раз больше (более 300 миллионов!).
При этом обнаружил пару досадных ошибок (недочетов) в OpenSCADA:
1. При запросе с нулевыми параметрами интервала "tm_grnd" и "tm" система должна, согласно документации, ответить одним последним значением. Да, это так, но она в этом случае игнорирует режим ответа (я использую "2" в base64) и отвечает числом в ASCII.
2. При использовании формата хранения отличных от "bool", "int64", "double", система не конвертирует EVAL значения. Например, при запросе архива параметра "float" (EVAL: -3.29E38) система преобразует в общий формат "double", но EVAL значение остается старым, а должно уже быть для "double": -1.79E308. Да, я без проблем могу обойти эту проблему в клиенте, выполнив запрос и выяснив реальный хранимый тип, но все же должна быть конверсия и EVAL тоже. На скриншоте видна проблема, самый крайний правый датчик имеет недопустимое EVAL значение (для хранимого типа "float"), клиент, на основании возвращаемого типа уже "double" (атрибут "vtp" = 4), ожидает EVAL -1.79E308, что не так.
Спасибо, Роман.
Скрин работы клиента:
[Сообщение редактировалось 7 раз(а), в последний раз 25.03.2021 в 20:03.]
# rm -rf /bin/laden
Вложенный файл
|
