УкраїнськаEnglishmRussian
Вход/Новый
В теме нет новых постов

Доступ к архивам по сети


Автор Сообщение
Сообщение создано: 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, что не так.

Спасибо, Роман.

Скрин работы клиента:

https://i.ibb.co/gZhQ3k0/data-extractor.png

[Сообщение редактировалось 7 раз(а), в последний раз 25.03.2021 в 20:03.]

# rm -rf /bin/laden
Вложенный файл

data_extractor.png (Тип файла: image/png, Размер: 21.88 килобайт) — 984 загрузок



12502